1 Introduction
By this point in your education, you probably have a good idea of what requirements are. If you ever wrote a program, you probably read requirements to know what the program should do. Requirements are the most difficult part of whatever software development methodology you may use. It is truly the document that bridges communication between technical people and non-technical people. This is no easy task.
We are engineers. So our opinion is that non-technical people use words incorrectly. Words like “never”, “are”, and “always” mean something different to non-technical people. Michael once built a system for a government agency. A field in the system was called “case number”. The customer told the requirement team “Case numbers are ten digits.” The system was built and it went live. Then Michael got a call from the customer saying that they couldn’t put in cases. They showed him an example of a case number that started with the letter “A”. He explained that the requirements stated that case numbers were 10 digits, and asked if that was a correct statement. They responded “Yes, case numbers are ten digits, unless it is a letter and nine digits.” As engineers, we would claim that the first statement is wrong, because it is incomplete. The customer didn’t see it that way. But it is not just the definitions of words that cause issues.
The English language is ambiguous. In fact, all human languages are ambiguous. Consider this sentence: “Fruit flies like grapefruit.” What does that mean? There are two ways to understand that sentence. The first is that there is an animal called “fruit flies”, and they like to eat grapefruit. The second is that there are objects called “fruit”, and that they know how to fly. How they fly is similar to how grapefruit flies. For humans, this example is easy to figure out, because we know that fruit cannot fly, so we eliminate that option. But we can’t always eliminate possibilities. Consider this sentence: “Be careful; those chicken wings are hot.” In this sentence, are you being warned that the wings have a high temperature, or that they are very spicy? You don’t know.
Normally as the quantity of information on a topic increases, ambiguity decreases. As you are given more information, ambiguous options are eliminated. In the example above, we would say “Fruit flies like grapefruit. In fact, fruit flies can eat a grapefruit in only a few hours.” But sometimes, as the amount of information increases, it becomes more difficult to understand. Consider this requirement:
Assume that there is an invisible grid across the screen with 100 rows and 100 columns. We number the rows 1 to 100 and the columns 1 to 100. Rows and columns are of the same size. On the screen, fill in each cell of the grid that falls within a direct line between the following ordered pairs. In each ordered pair, the first number indicates the row and the second number indicates the column: (33, 1) and (33, 100); (66, 1) and (66, 100); (1, 33) and (100, 33); and (1, 66) and (100, 66).
This is a very detailed requirement. What does it do? We can all see that it draws some lines, but what is the “big picture”? Now let’s rewrite the requirement a different way:
Draw two horizontal lines and two vertical lines across the screen to make nine equal size squares, assuming that the borders of the screen count as lines.
Ok, this has a lot less detail. But it makes it easier to understand. We clearly know that we are drawing four lines. Now we are going to write the requirement again:
Draw a Tic-Tac-Toe board across the entire screen.
Which of these three requirements is the easiest to understand?
These exercises demonstrate some of the difficulties faced by requirements analysts. How do you make a requirement document unambiguous and easy to understand? Much of this book will focus on this.
1.1 Why Requirements Engineering and Specs are Important
The obvious answer to this question is that we cannot build anything if we don’t know what it needs to do. But more broadly this answer has deep meaning to all of engineering. Without requirements we have no defects. Without requirements we do not know when we have finished. Without requirements we cannot judge quality.
1.2. Who are the Stakeholders?
You’ll hear the term “stakeholders” a lot. But who are the stakeholders? A stakeholder is anyone who has a stake in the outcome of the project, whether or not they are paying for the project, and whether or not you or anyone else reports to them. For instance, if there is a defined customer, then the customer is a stakeholder. If there is a proposed class of customers, then that class, collectively, are stakeholders. Any proposed user is a stakeholder. Everyone you report to, your coworkers, and everyone who reports to you are stakeholders. The stockholders, too, are stakeholders, but in a purely economic sense. Bear in mind that you can’t keep all of the stakeholders completely happy.
1.3. Do They Even Know They’re Stakeholders?
You’ve no doubt heard that you’ll be getting input from the stakeholders. When the stakeholders are external, there’s no problem. The customers have come to you. There are only two stakeholders involved — the customer and the service provider or vendor. However, if the project is internal, then determining who stakeholders are is not as easy as you’d like. There are major stakeholders, minor stakeholders, people who are clearly not stakeholders, and pretenders to a stakehold. In many cases, people who are major stakeholders will know that they are, but some of them may think that they’re minor stakeholders. Many minor stakeholders think that they’re major stakeholders, or at least want to be treated as if they are. Some think that they are not stakeholders. Some people want their opinion heard, even if they have no connection to the project. Don’t take their demands seriously, but at the same time, don’t let a good suggestion go unheard or unheeded. One way to deal with uncertainty in the situation is to get an organizational chart (often called an “org chart”) and to see how everyone fits in.
1.4 Certification
There is a certification that some requirements engineers choose to earn. The certification is called the Certified Professional for Requirements Engineering, or CPRE. However, many requirement engineers never obtain the certification for their entire career. But some employers see value in it, and it might give people looking to get into requirement engineering the edge that they need to get their first job.
The certificate is given by the International Requirements Engineering Board. They have a series of exams, starting with the Foundation Level exam.
1.5. An Example
In one of Sheldon’s consulting assignments, he was working for a client company that has a “code first” philosophy. No design, no plan, not even flushed-out requirements. Just one user story. They use a one-size-fits-all philosophy. They code everything in one specific language, and use one specific database, even when neither is the optimal way to go. Sheldon could have done the project by himself in two days. But it was a 9 man-month schedule (meaning that they planned on paying 9 months’ salary to get it done). Why? Because they used layer upon layer of abstraction, and experimented and redesigned as they went, and used a 4-tier distributed architecture. This system costs $100,000 per year to run, even though it could have been wedged into a server that rents for $15 a month. The morals of this story: (1) Know what you need to do before you start; (2) If you handle a cheap job like it’s an expensive job, it will be an expensive job; and (3) Use the right tools for the job.
1.6. How Things Can Go Wrong
Getting requirements engineering right is pretty-much required to have a project be a success, and in industry, most projects are reported to be failures in one way or another. Most projects are not 100% successful in everything they do or 100% failures, although there are some of each. There tend to be varying degrees of success. The goal of this book is to help you get to 100% success, or very close to it. We’re not going to claim that there is one right way to get a project done right, or even that there is a best way. The claim is that there are a hundred ways to do any endeavor right, and a thousand ways to do it wrong.
1.7. Discussion Questions
- Can you provide an example of ambiguity in written and/or spoken language?
- Are all stakeholders created equally? Can you think of examples in which one stakeholder needs to have more influence on requirements?
