Writing requirements is the most crucial aspect of systems engineering (SE) . In this book, you will learn the best way to accomplish this. You will explore the requirements world, you will use the best tools, and you will learn to employ these tools. This book is intended for those of you who consider yourselves as beginners or maybe advancing to an intermediate level. You will acquire a good foundation that you can use throughout your career. Even if you never plan to write a requirement, use case, or user story yourself, you will learn what a good requirements engineer will do for you. Think about it. As a project manager, you need to know the capability of everyone on your team. Requirements are the most important part, as you will soon learn. Get it wrong, and you will have problems—significant problems. You will be exposed to the most likely problems and how to prevent them.
You may have read some survey of development methodologies before reading this book (or taking a system development course). If you haven’t, it might be useful, but it certainly is not required. The traditional method used in lifecycle development is the waterfall method. The waterfall method consists of several major functional areas, where you perform one after completing the previous functional area.
Figure 1-1. Waterfall methodology
Notice that the requirements function occurs first, appropriately, given its importance in development. Much of this book examines requirements—covered in much more detail later or this would be a very small volume indeed.
You may now begin your exploration of the advances in requirements engineering.
Requirements have moved along with the advances in systems engineering over the last several decades, as engineers tried to improve the process of SE as technology and demands of the marketplace influenced it, especially in software development (but not totally divorced from hardware). The waterfall methodology moved first to the V-method and then Spiral; then Rapid Application Development (RAD) and also eXtreme Programming (XP) came into vogue; and finally the last land to explore is agile, the latest and arguably the best methodology yet. Again, you will learn more on these various methods later in the book.
Note
You will see the use of acronyms and abbreviations in this book. If you are new to the systems engineering environment , this use is indicative of the industry, so please get used to it. Chapter 3 will spend more time on this topic, where the “Language and Jargon” section expands on this usage.
Not only will you learn about requirements for software development, but also you will use these same skills for hardware development. As you will see in this book, the distinction within a project becomes blurred, as many projects have both a software segment and a hardware segment.
In this book, you will spend time reading about why you write requirements, how best to collect and document them, and how to maintain them. Basically, this does not change appreciably with the previously mentioned methodologies. This skill may go out of fashion. That said, the emphasis of agile has added user stories to the requirements function, which you will spend some time on, but you will also examine how requirements and user stories can and will complement each other.
There may be some proponents within the SE community who advocate that requirements are no longer necessary. Just as other people stand behind their beliefs, this book will defend the position presented here, which is that currently requirements are still necessary. Does that mean the approach presented here fits every situation you will encounter in your career? No, but what this book will also present are the conditions under which requirements work best. That way, you, as the requirements engineer, can determine the best way to control the requirements for your project. To quote Indiana Jones’ father: “I want to teach you self-reliance.”
The importance of requirements to a project will be discussed in this chapter. First, you need some introductory topics to help you with the focus of this book and its chapters, along with some conventions used throughout the book. Basically, you need a foundation before you build a house. The same applies to any endeavor—like learning about requirements.
Requirements Conventions Used in the Book
You will see references to BOSS. This is a system name used throughout the book to help write sample requirements, where BOSS means big organization’s suite of services—just a name to use that shortens to BOSS for convenience. It will look like this:
1-1 The BOSS Access Control Function shall allow an authorized user to access the system.
Notice a number appears in front of the statement, the format used consistently throughout the book. First, you always need to identify a requirement uniquely. For this book, the number format starts with the chapter number, a hyphen, and then the sequential number for each requirement in the chapter. Second, this allows referencing requirements earlier in the book during discussions throughout this book. You will also see some requirements that have another number beside the n-m format. These numbers are being used to illustrate some aspect of the project and will more likely represent what you might consider in a requirements set, especially if done in a hard-copy document.
In some cases, you will see DRAFT in front of the requirement’s shall statement . It will look like this:
1-2 DRAFT—The BOSS Access Control Function shall allow users to access anything on the system.
That means it may or may not be a good requirement. Thus, if you work in the future, you may not want to consider it as a good example, without reading the text surrounding it.
There will be additional situations where requirements will have a parent and child relationship. The first requirement has PARENT after the requirements number, indicating it is the parent. The subsequent requirements with CHILDREN after the number are subordinate to the parent requirement . They will look like this:
1-3 PARENT—The BOSS Audit Function shall allow system administrators to generate an audit report.
1-4 CHILD—The BOSS Audit Report shall include all login attempts, all failed login attempts, and who attempted the login.
1-5 CHILD—The BOSS Audit Report shall include who added, changed, or deleted database records.
In some situations (e.g., a format required by an organization for its hard-copy requirements document), these may be numbered 1-3, 1-3.1, or 1-3.2 to show the parent-child relationship. The use of the words PARENT and CHILD are just an aid to learning in this text. They are not recommended on the job, unless you find there is benefit for doing it that numbering alone does not alert people to it. It is your call.
You may also see the following:
1-6 (1-1) The BOSS Access Control Function shall allow an authorized user to access the system.
Why are there two numbers here to reference a requirement? This means that the next sequential number, 1-6, happens to be a repeat of one earlier in the book (in this case requirement 1-1). In many cases in this book, there is a need to refer to requirements from a previous chapter, so it might look like this:
12-73 (5-27) The BOSS shall…
Projects Used in This Book
Throughout this book, two projects will be examined to emphasize elements of importance to you. Not every example will use these two projects, but the vast majority of them will. Some examples may not fit the following two projects, but they will be invoked whenever it is most appropriate.
This book, as is used in the SE industry, follows the convention related to abbreviations and acronyms. In the previous sentence, you have seen the abbreviation SE for systems engineering. The convention dictates the first time an abbreviation or an acronym is used, you must spell it out and show its abbreviation or acronym in parentheses after it—like systems engineering (SE) in the first paragraph of this chapter. Then the next time you use systems engineering, you only need to write SE. This is a shorthand method that is used extensively in the industry, and you need to become proficient in it.
FBI Record Management Project
The first project mentioned earlier is the Federal Bureau of Investigation (FBI) Records Management System for the primary software-based project in this book. The federal government has to follow the dictates of the National Archives and Records Administration (NARA), which spells out the rules for how long temporary records are maintained. You will see various requirements dealing with the FBI’s records management that expand on this project.
Remember, in most software-based projects, there may be some hardware aspects related to this system. That said, the primary hardware-based project in this book comes next.
Radiation Dosimetry Project
The second project will be a radiation dosimetry project for the United States Army. The purpose of dosimetry is to measure the radiation a person is exposed to, either in a laboratory, in a nuclear power plant, or in a nuclear battle field. The primary emphasis here is to examine radiation exposures to U.S. Army soldiers in a nuclear battlefield. There are five basic devices that make up the entirety of the system. They are the following:
Individual radiation dosimeter
Unit radiation dosimeter
Dosimeter archive laptop
Radiation dose rate meter
Radiation dose rate mapping laptop
The Individual Radiation Dosimeterwill be a small, portable device that will capture what one person, a soldier, is exposed to while in a nuclear environment. This device will be like a small watch that the person wears all the time and that stays with them regardless of what unit they are assigned to during their career .
The Unit Radiation Dosimeteris the device that will read the individual soldiers’ Individual Radiation Dosimeters to collect all the readings. This can then be used to determine the effectiveness of the unit based on how much radiation they have been exposed to collectively.
The Dosimeter Archive Laptopcollects all the information from the various Unit Radiation Dosimeters and consolidates them for archive/backup purposes as well as allowing higher-level roll-up of information reporting.
The Radiation Dose Rate Metercollects all the radiation information from various vehicles in a unit. Unlike an Individual Radiation Dosimeter, which collects what radiation that soldier experiences, whether or not shielded in a vehicle or shelter, the Radiation Dose Rate Meter collects the raw, unshielded radiation exposure. This can be the raw data to collect the dangerous areas for military operations. This is a snapshot in time, where the dosimeter captures the total exposure.
The Radiation Dose Rate Mapping Laptopcollects all the information from the various Radiation Dose Rate Meters, plots the radiation data onto a map, and displays the designated radiation contours as an overlay. This allows commanders to modify their military operations based on the radiation remaining in their areas of operations.
Basic Definitions
Before going further, you need to understand some language that will be used extensively throughout this book. There are many more definitions throughout this book, but these are the foundations for your understanding.
Definitions of Requirements-Related Terms
Here are some foundational terms. First, let’s start with what requirements are.
The definition of a requirement:
Define a need, desire, or want to be satisfied by a product or service .
That sounds reasonable. You will find service is used extensively to talk about service-oriented architecture (SOA) , but again, you’ll learn more about that later in the book. Think of a service as a function within a software application, (e.g., cut, copy, and paste in a word processer) and you have the idea. A product would be like a mouse, a printer, a scanner, or even your cell phone. Obviously, any of these products would take more than one requirement to define it fully. There is not a situation where only one requirement would ever define a product or service.
The definition of a system:
Meriam–Webster Online defines it as a group of related parts that move or work together.
Now think of this definition with respect to the samples used previously. You see that it applies to not only the mouse, printer, scanner, and cell phone but also to the cut, copy, and paste functions in a word processer. A system applies to both software and hardware. In fact, most systems these days combine both software and hardware.
The definition of an application:
Meriam–Webster Online defines it as a program (as a word processor or a spreadsheet) that performs one of the major tasks for which a computer is used.
An application is a collection of one or more functions, ranging from something as sophisticated as software running a nuclear power plant to something as small as a cell phone app, like the game Angry Birds.
The definition of a stakeholder:
Meriam–Webster Online defines it as one that has a stake in an enterprise.
You will spend a significant amount of time learning about stakeholders, especially in Chapter 9, as they are the people who will help define the requirements for the system. Keep in mind, though, one stakeholder rarely represents all the users of the system. For example, the people who enter health information in a Medicare system may not represent the people responsible for fraud detection, and neither stakeholders will understand system monitoring and steps necessary to keep the wide area network (WAN) working.
What role defines someone who works with requirements? That someone is called a requirements engineer (RE) . Again, how do you define that role ?
The definition of a requirements engineer:
Someone who collects, coordinates, advocates, and manages requirements.
Tip
Did you notice that there now are two different definitions for RE, requirements engineering first and now requirements engineer? This can and will happen on your project, as it will happen again in this book. You will have to learn to handle this. Usually, you can see from the context what meaning makes sense. If not, ask to find out what meaning is correct.
While the requirements definition is quite self-evident, the terms used in the definition of the requirements engineer may not be well understood in this context. That means you are reading the proper book. By the time you are finished reading this complete text, not only will you understand all the functions an RE does, but also you will be able to perform those functions. Each of these terms will be examined in detail throughout the book, so do not worry. In addition, the reason the role of RE was mentioned versus the RE is because the role covers one engineer or a team of engineers. You will work both ways, as a one-person team and as one person on a team, and you may even lead a team of engineers doing nothing but requirements engineering. The size of the project drives the role of the RE.
How Long Does It Take Requirements Engineers to…
No, this is not a joke about REs. Are you kidding? The most important engineers on the project are the REs (and do not let anyone else tell you differently). However, that is a slight digression.
But seriously, folks…. You might logically ask how many engineers does each project need? The correct answer is that it depends. As you move through the various systems development methodologies throughout this book, you will see how it differs. For example, in the traditional waterfall method mentioned earlier, you would start with a significant team and spend nothing but months and even some cases years defining requirements.
Real-World Note
Yes, I have done RE for three years on a ten-year project. Whereas with the agile methodology (more on that later), I have supported two dozen or more implementation team members by myself. Of course, that system was already deployed, with significant policy changes that kept me busy. It might not always have been that size, as that project had about 4 to 5 percent of the team as REs while I was there.
Does the size of projects affect what REs do? Yes, as the project size grows, one RE becomes insufficient, and you will need more. Your first reaction might be to say the following:
When the project grows beyond one person, the answer depends on too many factors to discuss here or to give concrete guidance. Part of it depends on experience, and in fact, many times you do not know until you see it growing beyond the size of your team. This will be examined more later in the book.
However, the industry has some data on this. Capers Jones performed an industry survey in 2000, which he documented in the book Software Assessments, Benchmarks, and Best Practices (Addison-Wesley Professional, 2000). Jones discusses “very large projects of 10,000 function points in size (approximately one million lines of code).” Loosely, think of function points as a feature, say on a menu, just to give a reference. Specifically, Jones looked at the following types of projects:
Management information systems
Systems software
Commercial products
Military software
Outsourced projects
On the low end, the percentage of “total effort on requirements development” for management information systems was 3.7 percent. The others ranged from 7 to 10 percent of total effort. The time involved in developing requirements was significant, ranging from 4.4 months for management information systems to 22.7 months for commercial products. Jones’ book is an excellent resource if you want to dig more deeply into this (and other) topics. However, this shows roughly how much time requirements definition can take.
The first question that should pop into your head is, “How successful were these projects?” Alas, the author did not provide that data. The averages are for all teams regardless of how successful each project was. This is how you have to analyze data to understand truly what it means. At least there is an estimate for how much time a project should invest. As you will see with some of the defects that requirements generate, spending more time on requirements definition is better—provided you do not get trapped in analysis paralysis. What is that? Excellent question. Paralysis occurs when you spent so much time getting everything precisely right that you lose sight of what you’re trying to collect. If you question every point of all stakeholders, then you take too much of their valuable time and they become reluctant to talk with you. (Remember, they have a day job to do—more about this in Chapter 9.) You will spend more time on how to enhance requirements definition when you get to the user story material in Chapters 12 and 13.
What Makes a Good RE?
This section will focus on two major areas, good communication skills and the attributes a good RE should have. We will examine each in detail with the various items a good RE should have. Not having one or more of these is not going to doom your chances to be a good RE. You have to exploit the strengths you have. Experience working requirements for years will more than compensate for a lacking in a particular attribute.
Personality Traits
Now you will examine the traits a good requirements engineer should have. Keep in mind, none of these is an absolute. It’s more like the Pirates’ Code, kind of like guidelines (although do not ask Captain Jack Sparrow’s father). The point is, you need to have some aspects of these to be reasonably successful.
Patience
This process can take some time, as you saw earlier. Not every stakeholder or every user will know all aspects of a process. Sometimes it will take various techniques to tease their real needs from them. You will learn more about these in Chapter 9 to help with that. Other times, the participant may not be the best fit. You will search for better ones or spend more time with some you already have. In fact, asking people for suggestions can work. Showing you value their opinion goes a long way in establishing a rapport with people. Remember, nothing is more satisfying when a stakeholder recommends you to do requirements work for another person’s project because, as they say, “He (or she) does excellent requirements work. Use him (or her) for your project.” (I speak to that first hand, as it happened to me.)
Another aspect of patience deals with the time it takes to collect all the information needed. For example, you will run meetings that can run into hours. After an hour or two of meetings where you exchange information, you may feel mentally drained. It is hard work doing this. Obviously, this kind of work is not physical in a manual labor sense, but it can be taxing. When you have to focus hard listening very intently, you will lose energy. Think of those two three- or four-hour exams you may have had; you probably felt it then .
Real-World Note
My record here in the United States is a solid two weeks in the same meeting. Yes, about 80 hours. In addition, my all-time record is overseas where I was essentially in the same meeting for three weeks. Think of how draining those meetings can be.
Meetings this long are exceptions. It was not that I sat in the same room, with the same people, for two or three weeks straight. In the two-week one, I was involved exchanging information only for my block for a day and a half. In the three-week meeting, it was actually several different meetings, with different groups of people. Also, I did not run the entire three weeks of meeting. The first day was a kickoff meeting where both the American and foreign representatives spoke. Then there was one meeting that talked about the interfaces between the respective systems. One of the developers ran that meeting. I also had one of my requirements engineers lead one day of meetings where I sat and advised as the purpose was to train this engineer to do customization of the system whereas she had become proficient in collecting requirements for the standard system up to that point. This gave me relief from having to ask questions, take notes, ask for clarifications, summarize what was said, and so on, for the entire 15 days.
Unlike the previous Real-World Note, usually you measure meetings in hours, not days. You need to know that it can happen. Having a team where you can take turns gathering the requirements certainly helps, but you do not always have that opportunity.
The exception for me occurred on many of my overseas trips. I was the only one collecting requirements. Granted, I was a senior engineer at that point. Nevertheless, you do not always control the number of people performing requirements analysis.
Again, you will improve with practice and experience. Just like World of Warcraft, you gain experience points as you play the game longer.
For one of my projects’ meetings with stakeholders, I took an engineer to teach her how to collect customization requirements to our standard project. During the meeting, I could tell she was frustrated with how long it was taking to get what she needed. Part of the challenge was that we were overseas, and the language barrier contributed. After that meeting, I gently pointed out how challenging the process was and explained how getting the requirements on a particular schedule may not be practical in every case.
Clarity of Thought
This is one of the most important aspects of an RE. You always have to think and analyze what you hear. Understanding everything the stakeholders say is essential. This is so you can capture the “what” of their business process. In fact, you might want to consider writing what is called the Business Process Description (BPD) document. In this, you listen to what the stakeholders say and write it all down. However, you write the major and minor steps of what they do, not how they do it. Their steps could be done by hand, written on paper, or on a computer system, whatever they do, just not precisely how. Is this an exact science? No. Is this something you have to provide to people? No. You do it for your use. That said, sometimes you may want to check it with the stakeholders to ensure the steps are correct. Also, some organizations may create this document formally. If so, follow the required process.
Are you the person who has to capture it all? Not if you don’t have to. This does not mean you should not have all the information, far from it. Instead, do not reinvent the wheel. Find out whether the stakeholders have something already that describes this. For example, do they have some documentation for a new person coming into their organization? It is usually good to start from this document. Naturally, you will have a lot of “how” they do it. However, you will have to think how that translates to “what.” Sometimes they just have a document they have used to brief upper management. Do some digging and you will be surprised how much may be available.
User manuals may give some clues, but remember its primary focus is to describe how a system works, so you will have all the “how” and you will have to think about the “what.”
Tip
Many user manuals may just list a description of everything that is in the system without showing how a person will use it, like having a workflow or a scenario. The latter is important, whereas the former may not be.
Here is an example from a personal project I am working on:
Transfer
This is how you take candidate coins into your collection:
Androida will say, “Please select which denomination you want to transfer coins.” She points to a pop-up menu that lists each denomination that includes coins you own. Click which of the denominations you want.
After you click, Androida will say, “Please click which specific coins by years and their associated mintmarks you want to transfer from Circulation List to Own List. Then click the Ready to Transfer button on the bottom.” She points to all the coins in the denomination you own. Check the boxes of the one or more coins you wish to transfer. Then click the Ready to Transfer button.
After the transfer occurs, the denomination list reappears. You can continue to select coins to transfer until you click the Done with Transfer button at the bottom of the list. Then you return to the pull-down menu.
Hitting the Esc key clears the submenu.
Notice all the implementation here that says thing like “click” this or “select” that. This is not a user requirement. The essence of what the user really needs is more like the following statement that you could use to write requirements from:
The user had indicated all they wanted was a way to select some coins they had and put them into a coin collection. She did not specify all these steps—just the one function of moving some candidate coins into this designation of a coin collection.
Test procedures may also have some useful information. Again, these are specific steps without the reason why it is done. Keep in mind, however, they are testing some wrong conditions on purpose to check range limits and other error conditions. One advantage is that test procedures should test all possible paths that a user may skip over, maybe because they do not remember something that rarely happens.
There is one additional aspect to clarity of thought, as you learn some of the limitations of requirements definition. Once you learn these limitations later in this book, you need to understand why something is a limitation. The reason is that when a new approach is available to fix the limitation, you will need to discern whether this improvement truly eliminates or at least reduces the problem. You will have to compare to the current limitation and see whether their fix is better or not by analyzing the before and after requirements.
Flexibility
No, this does not refer to being a gymnast but being flexible in your attitude. You must be adaptable to the situation. This is complemented by thinking, in that you have to understand the situation so that you can change when the situation demands it.
Real-World Note
On a recent project, I had begun capturing the requirements the traditional way. In six to eight months, I had managed to capture the requirements for only the search function of the system. We had about a dozen major functional areas like this. The program manager was extremely frustrated by the lack of cooperation from the stakeholders, which was epitomized when she had said, “It’s going to take us five years at this rate!” Thus, we needed a new approach. We decided to capture user stories (see part IV) with the stakeholders, but only capture shall statement requirements for the development and test teams. In the same amount of time as it had taken to capture requirements for search, we captured all the user stories for items that did not work well and areas that could be our ideal approach for all the remaining functional areas. In the next six to eight month, we performed gap analysis to cover the user stories for everything that was missing and then completed the requirements definition, with tracing between the user stories and requirements. By analyzing what was not working and thinking about alternate approaches, we came up with a better way. This worked because the customer was flexible.
Extrovertism
Extroverts are more comfortable working with people, and in fact, they can be energized by talking and working with people. Introverts are less inclined to be so energized. In some cases, exposure to people can be draining.
I know an Olympic gymnast who found meeting a dozen people in a social setting draining. Yet, performing in front of 30,000 people at the Olympics did not phase her. She blocked out the audience and focused on her small little world where she was queen. This approach worked for her as she has five Olympic medals.
Much of your work will occur in meetings. Sometimes they are just one-on-one; other times they have a dozen or more participants. If you are maintaining requirements for an existing project, you might not have a great deal of people to deal with. Alternatively, you will have worked with the people for a long time and feel comfortable with them.
Yes, extrovertism is not a requirement of all REs, but it certainly helps. If you are more introverted, working with people you know and are already comfortable with helps. Ask those you have a rapport with to assist in working with people or at least gather advice on dealing with people to help raise your confidence in dealing with certain people. It may be as simple as having more than one person from your team be involved to share exposure.
Confidence
Confidence flows both ways. You need to have it. So believe in yourself. Also, people will need to have confidence in you. Once you have experience, you will gain that confidence, both in yourself and others in you as you gain a reputation.
How do you gain that reputation? You need to be prepared, by covering the right subjects, by not wasting time by digressing, and by listening. As will be talked about in Chapter 9, asking clarification questions to help understand the subject discussed and summarizing what you have heard helps them gain confidence in you.
This isn’t always about you coming across as knowing everything. If you give the impression that you know something and you do not, people will lose confidence in you quickly.
It also includes helping the stakeholders feel confident about themselves.
Real-World Note
Once when I was overseas, one of the stakeholders mentioned how they did something in their manual process that we were going to automate for them. I told them how that was an improvement over how we did it. I went on to add that we had included improvements that other countries had provided, because we American do not have a lock on being the most intelligent in the world. Many people have excellent ideas. I explained that the development team had already incorporated some, and they were planning others. What this did was establish a rapport between our two countries.
In this example, I demonstrated that I had confidence in those I was working with, both their country and others my team had dealt with. They know what they do and why. I trusted their understanding and knowledge.
Confidence does not equate to arrogance. When someone comes across as a know-it-all, people are less likely to have confidence in that person, from my experience. How you word a response can help establish confidence or not. For example, saying, “Let me check for understand,” helps to establish confidence rather than saying, “Yeah, I got that!” as you wave your hand to dismiss the stakeholder’s point.
Negative Traits
Of course, there certainly are more traits, but you need to avoid the negative ones. For example, impatience will inhibit your abilities. Naturally, being short-tempered will be disastrous.
Thus, even temperedness and calmness are desirable qualities for you to embrace.
Ego can certainly get in the way, so check it at the door. These are not your requirements; you are just the vehicle by which they are captured. The stakeholders and users really own them. When someone suggests a change to something you have captured, remember that they are clarifying what they need, and they are working hard to ensure proper communications. If you attempt to own the requirements, you will be a reason some of the things that can go wrong will, as you will see next.
Remember in the “Patience” section, where I talked about the engineer who was frustrated about not maintaining her perceived schedule? I could see on her face that she was impatient. Knowing her, she was a short way from losing her temper, which would achieve nothing. Sometimes, fixing it may be a matter of taking a break. If need be, defer to another meeting so you can talk with some other people to get their assistance in clearing up any impediments to success. Ask people more seasoned what you should do. Do whatever you can to defuse a situation.
One minor point to be aware of is that you may not get to see the results of your work. You rarely will work on a project from initiation to the end.
Real-World Note
At least that has been my experience. Maybe it is a manifestation of working on government projects where people move around a lot. I probably spent an average two years on a project, sometimes as long as four, but not often. Sometimes it was even shorter, but that was usually for other reasons, such as projects being canceled or delayed for things totally unrelated to anything I could control.
Maybe in the commercial arena, you may stay longer. That said, if people find you are a good requirements engineer, you will be in demand. When the next new and high-priority item comes along, they will want you. Thus, you may not see a project to completion. Alternatively, as in other cases, you are brought in to fix something that someone else did, and they did not do it so well. Again, this has happened. Don’t let your ego keep you on a project longer than you should. Anyone (well, almost everyone) can maintain a well-established program. However, not everyone can start a project and turn it into a well-run program. Strive to be that person that people want. It probably won’t be your very first project. Yet, it will come with time. In addition, this book should help you get there. This way you will not be one of those REs that cause requirements problems.
Good Communications Skills
We will examine the following aspect of good communication skills :
The ability to respond to people’s needs
The ability to translate ideas
A capacity for moderating different views or differences of opinion
Persuasiveness
Of course, you will need to be able to write good requirements, user stories, use cases, and every other piece of documentation needed to capture requirements. This book will go a long way to help you get there for requirements specifics. However, if your grasp of English (or whatever language is appropriate for your project) is not so good, then maybe you need to rethink doing requirements engineering. This is not to say you need to create literary masterpieces, but you need to be able to write an understandable sentence. You will need to present your information to others so they understand it. For example, you may need to present requirements at a requirements review, so you will need to get up in front of people to explain not only your process but also your results. In addition, you must populate your requirements document or requirements database with everything you have created. You must write them well enough to be comprehensible. If your grasp of language is not up to the standards needed for the project, then take whatever steps necessary to ensure you can listen and write to the appropriate level.
Throughout my career, communication has been the source of the most problems. Some people have said that is not true because technology is the main challenge. However, I have seen communication problems repeatedly affect projects involving different types of technology and many different people on various teams. Communication failure is the common thread. Communication issues can be the fault of the RE, other people may be the cause, or both. Establishing a common language, as you will see in Chapter 3, will help immensely. One other part of the problem is that some people do not listen well. Back to the original point, some of those people felt that technology fixes all problems, so they stop listening to what other, more experienced people had seen. Listening is one significant aspect of communications.
Responsiveness
Because you must understand the full needs of the stakeholders, you have to put yourself in their shoes, so to speak. You need to understand how issues affect them and capture those needs. Some stakeholders may not get much visibility; for example, the people who administer the system may not have representatives in stakeholder meetings. Nevertheless, they have needs. What kinds of information and capabilities do they have? If you cannot find a good representative, you need to capture their needs somehow. How about the people who monitor the system, get the audit logs, track the system resource usage, and so on? They have needs as well. If you are in an information technology shop, you should have people like this around you. Talk with them. Or database administrators. Remember, if you talk to them about their needs, you will ingratiate yourself with them. (Well, most of them. Occasionally, you will meet the crusty old curmudgeon, but they are the exception rather than the rule.)
Translator
You are a translator of what the users and stakeholders say they need into words that the information technology (IT) department in your organization (or whatever it is called) needs. Basically, you are writing a contract between the two. Think of yourself as a lawyer for the two parties involved, without having to go through law school. Oh, and what you will write will be much more readable and understandable than the “conspiracy of obfuscation” that real lawyers perform.
Note
Yes, I have opinions, and I will express them here. Most of the time I will be demonstrating the passion for requirements, but sometimes I use it to reinforce a point, like now.
Now, examine an example of translation (and you will see more examples in the next chapter and in Chapter 9). A stakeholder says, “When this specific error happens <insert their error here>, I need a red flashing button up in the upper-right corner of the screen.” As you will see in the next chapter, they are telling you how to implement what they think they need. What they really mean is, “When an error condition happens, I need a message of what is wrong and how to proceed.” This is not only getting rid of the implementation (the how) but also making it in what they need and, in this particular case, making it general enough to address all error conditions. This is a good point to generalize for groups of errors whenever you can. For example, if you have operating system (OS) errors, you might need a different requirement. Again, you’ll learn more about that later in the book.
Communications goes two ways. Just as important as speaking and writing is listening. Some may argue that listening is the more important aspect of communications. Listening is at least equal in importance. When you are collecting requirements, you must listen intently. By that, you have to understand everything the person says but also the implications of what they say. For example, someone may say they need to export query results to a spreadsheet. Naturally, you will capture the statement, but then you need to ask the one question you will ask more than any other during your career—why? Why do you need to do that? It turns out that the user says they need the spreadsheet because the current query results tool does not provide the ability to manipulate the query results in the query tool (yes, this is an actual instance). They wanted to be able to move columns around and expand or contract the column sizes—maybe because the column does not display fully. Here are additional requirements that they may not have identified. That is why questions like, “What does not work for you?” or “What can be improved in, say, search?” are very useful questions .
Moderator
There are two aspects to this attribute. First, you must be able to run meetings, whether one-on-one meetings or groups of people. As an RE, you will have many of these. This is where you collect many requirements. They can be informal or formal. A workshop may be more structured than a face-to-face meeting, where that latter meeting may be just question and answer. With time, if you are not as comfortable with being a moderator at first, you will get very good at it with experience.
Second, you need to be able to moderate disagreements between people. Not that you are going to get into major controversies that splash across the headlines, but you will encounter people whose opinions or understanding do not match. It is your job to moderate those discussions. Sometimes it is nothing more than not speaking the same “language,” but you’ll learn more about that in the discussion about language and jargon in Chapter 3. Other times, the needs are very different, and you’ll need to work with people to get to the heart of the matter. Maybe upper management needs to resolve it, so you must aid that process. In other cases, you may have someone who tries to dominate the conversation, not letting others speak. You will need to ensure everyone gets a chance, maybe going around the table, calling on each person so no one is left out, and not allowing the “dominator” to grab the floor much of the time.
Persuasiveness
This is a corollary to moderator. You will need to be the proponent for the requirements. You will need to sell what you have captured, whether on paper, in a database, or during a presentation. In addition, you will need to be able to convince people in positions of authority when they initially may not initially accept them. For example, it may require them to make some minor modification to their current system to save a significant amount of time when they convert to a new system. How do you do that? The best way is to show what is in it for them. If, in the long run, it is better for them, they generally will accept it.
Summary
You have learned about many good personal traits and some to avoid along with needing excellent communications skills to make you a good requirements engineer. Naturally, you will get better as you gain experience. Nevertheless, you should have some insight into what it takes to become a better RE as of a result of this discussion.
Of course, just because you are reading this book does not mean you will absolutely become a requirements engineer. Instead, you may be reading this so you know what an RE will do on a team you work on, or maybe you are managing the requirements team. Regardless, you need to know what REs can and should be able to do.
With that segue…
Challenges for Writing Effective Requirements
There are risks to writing requirements that can severely impact the system being developed or even while it is in operation. You will learn about these potential problem areas and general solutions that will then be expanded upon during the course of this book, with the intent of overcoming these challenges.
Insufficient Requirements
Insufficient requirements means that you are missing some or even all of the requirements. If you are missing requirements, when the system is deployed, the users or a subset of users will not have the functions you have.
Before analyzing this topic, a differentiation must be made from the agile methodology where you do just-in-time requirements. With agile, you must have all the requirements you need, when you need them. Insufficient requirements means that all the requirements needed are not provided when they are needed. You will learn more about agile in Part IV .
Real-World Note
When I was teaching myself to use a new programming language, I wrote my first real program to manage my book collection. Yes, I could have found a program to do that, but this was a learning technique. After I had defined all my needs, I built a database with a user interface to perform CRUD. That is the standard IT term to represent Change, Read, Update, Delete. These were all the functions I needed. I had defined all the fields that I wanted maintained for my collection. Then I showed it to my wife who said it was missing the International Standard Book Number (ISBN) . Now this number is used track the published versions of books around the world. If others would use these programs, that is a valid requirement. However, my wife said she wanted it, so I accepted that as a valid requirement (even though I believed she would never use it). I put that under the “Marriage Maintenance” section of requirements. Trust me, if you are married, you will understand. However, even I am not perfect when it comes to crafting requirements.
Insufficient requirements means there are gaps in the full description of the system. For example, maybe you forgot to include auditing of the user access function. If this is captured later and the function is added, without capturing the data associated with the people prior to that time, you will not have full auditing of the system.
Approaches to mitigate this problem are the following:
You should come up with preliminary requirement areas.
You should research if working in a new area.
You should go through the full process for gathering requirements covered in the rest of the book.
Insufficient requirements are more likely because #3 isn’t done well than #1 or #2. As a result, you will spend extensive time learning how to perform good requirements gathering.
One way to look at insufficient or wrong requirements is to look at the cost to fix a problem with a requirement .
The Davis book states that fixing requirements left until after deployment is 100 to 200 times more than fixing the requirements during requirements definition phase. Thus, it is imperative to get requirements correct. Bear in mind, people will review (validate) the requirements so that you have the ability to correct them early. There are other techniques you will see throughout the book that will help to improve your requirements. The point is that you should get each requirement correct from the beginning to significantly reduce the cost of error fixing.
There is a variation on an insufficient set of requirements—no requirements. There is a joke where a programmer says to the requirements engineer, “I don’t need any requirements; just let me code.” To which the response should be, “Code what?” How would the coder know what to code? They coded what they thought the stakeholders needed. How do you think that went? You are correct if you said not well.
Tip
Programmers do not think like users. This is not meant in a disparaging way. It is true that a good coder must think in computer language terms with a very special logic to be successful. Most users of systems are good at what they do, but they are not programmers. Thus, REs become the translator between users and coders.
Clearly, having no requirements is a recipe for disaster. No one—users, programmers, designers, testers, or even managers—know what to expect. Thus, any development effort must have some requirements .
Scope
Understanding the scope of a project is critical to establishing requirements for it. In some cases, it may be simple and clearly defined. However, in other cases, a project’s boundaries can be vague or poorly defined, and this is one of the biggest sources of problems for writing effective requirements.
Real-World Note
In my first foray into commercial software, I wrote a card game to run on PCs. You played against the computer only. You did not play with other players or over the internet. Simple and well-defined boundaries. My next effort that I am still working on is a game that is multiplayer and playable over the Internet. Here, the beginning and ending points are less well-defined.
Think of a personnel system that defines everything about a new employee when hired for the company. You define all their information about the person: name, address, phone numbers, and e-mail addresses. Does it include salary? Maybe. Maybe not, as that may fall under the payroll system. Does it include next of kin? Maybe that falls under the Benefits system as that deals with beneficiaries. Alternatively, maybe it falls under the Security group, which needs a list of the person’s family because the person needs to checked out.
Any time there is a “maybe” answer, the boundary between systems, between services, between functions, or between applications must be defined. To reiterate, in most cases, that is not something you can do yourself. You must work with others to come to a common agreement. If it is between functions within your project, it is relatively easy since it is someone you probably work with regularly, and you have a project manager who can help make any decisions. If, however, your project interfaces with another organization or major project that you have no real connection with, the management chain up to the common manager may come into play. These negotiations become more complex, as budgetary constraints, schedules, and other factors complicate the process.
Note
When having to work across organizational boundaries or with those working on other projects, competing egos can be another factor. This is why a good RE must have some of the attributes described earlier and be able to facilitate communication and cooperation.
The point is, define the boundaries of your scope precisely. This definition is necessary for establishing clear project requirements and thus helps ensure that resources are distributed efficiently. You need the definition to know what you need to be working on to begin with. It will also prevent two (or more) people or projects duplicating work or, worse, working in opposite directions .
Requirements Creep
Requirements creep, also called scope creep, means that the requirements change significantly from when they are initially defined until the system is completed.
We all have heard about an aircraft, weapons system, building, or other project that was planned to cost $X million but ended up costing twice that amount or more by the time it was finally completed. A significant factor in many of these cases is requirements creep (or scope creep). This requirements creep occurs in hardware, software, or both. Defining requirements expecting that nothing will change with time is unreasonable. Nothing stays the same. Later, some people realize they need those inevitable requirements. Then, they say, “While we are here, we need to add….”
To combat this scope creep, the agile methodology was developed based on the Toyota production system founded between 1948 and 1975. This lean approach to requirements is to craft them just before they are needed (using the analogy of “just-in-time” production).
In this approach, you define functional needs near the beginning of the project. Then designers and stakeholders prioritized what functions they want (and can do) when. Then you craft requirements as they are needed.
Volatility
Volatility is different from scope creep (i.e., added requirements). Volatility means that already existing requirements change; requirements have not been added. For example, the original requirement for availability says this:
1-6 The BOSS system shall be available 99% of the time.
Then someone realizes that this system will become a probe that will travel to Pluto. Oops, that availability is not sufficient so they change it to the following:
1-7 The BOSS system shall be available 99.999% of the time.
Trust me, this later requirement will cost a lot more than the original estimate. You will see this more in Chapter 9.
Stove-Piped Requirements
Stove-piped requirements mean this project is done in a vacuum. I don’t mean in a physical vacuum like outer space, but the team works in a vacuum compared to the rest of the organization. This is more likely to happen in large organizations where it may be difficult to communicate every project throughout the organization. Or think of the Department of Defense, where security issues or classified projects limit the access to information; it can be even harder for people to know what everyone else is doing. Thus, the possibility could exist that duplication of effort occurs. Note that siloed projects mean the same thing as stove-piped.
Think of every project designing its own security access portion of the application. The user is required to enter a user ID and a password. The security team has deemed that the person can try three times, and if they fail, then they are locked out. How much time and cost are associated with defining the requirements, developing the code, testing it, and implementing it for each project? Rather, one approach should be developed and tested and then used by all of them.
This is something you may not run into on your first effort. In fact, you may never encounter it. Why? Because many, if not most, organizations have fixed this issue.
Recently, the federal government continued to shrink IT budgets. One of the benefits is that they were forced to see the light for standardizing approaches for their IT projects. By that, they had to not only share code, by reusing services that had been already developed and worked well, but also share things like requirements, architecture, coding standards, and so on.
Why do things more than once, when one time will do? You would think that people would have done this decades ago. However, there are factors that have worked against it. Because of environments that fostered restricted communications such as security access, people did not necessarily know what people in adjacent offices and organizations were doing. Only when they had to be creative did they begin the steps toward standards and sharing. That’s not to say it was easy.
I attempted to reuse the solutions for addressing existing similar needs by finding requirements on a large document retrieval project that was already in production. I had little success. In part, I found the reason was that while the organization was using a service-oriented architecture (SOA) , there were no real requirements defined for it. At first I assumed that I could not access the requirements for the document retrieval system. Once I did find the requirements, I found they had documented very few of the requirements, especially for the SOA portion of the system. I was the one who created these requirements, and then my project shared them with others, so other projects did not have to re-invent the wheel.
The preceding example illustrates the kinds of clues to look for. If you are going to write requirements for common items, like a report generator or access control or searching capabilities, you might want to ask around to see what other people have done.
How do you overcome not being able to find out what other projects are doing? Very carefully. This is not something you can do yourself, in most cases. Work with your supervisor, say the requirements lead, or if this is you, work with your program/project manager. Without their buy-in, it will prove daunting because as a team you must go to the other projects and convince them to share their requirements. If the other team is not on board with the approach, you will not get their requirements, and there will be no way to share requirements between the teams.
Assuming you get cooperation, you need to compare your needs. Find the common ground. Then articulate your particular differences. Those are the ones you need to define. You will see more detail later how best to accomplish that.
Users Are Not Sure What They Need
The challenge here is the users you are talking with are not certain what they need. Sometimes they have not been thoroughly informed why they are participating in your effort. Other times, they are totally unfamiliar with how new systems or improved replacement systems are developed. While they do not need to understand all the details of how a system is conceived until it is delivered to them, they will at least need to know what the requirements process should be.
You will definitely learn much more about this when you get to Chapter 9. That said, if your users/stakeholders do not know what they need, that is going to put you at risk. If they do not know, who will? You will learn more about how to find the right people to interview, techniques like structured questions, group interviews, brainstorming, and so on.
Therefore, you need to find the right people, which may not always be easy or even possible. In that case, you need to help the users find out what they need. Earlier in the chapter, you read about how you need to be a translator from what they say they need to what they really need. You also need to guide them to help them to find what they need.
Back when I was a graduate student, running labs to supplement the lectures, the students would come to me asking questions how to find an answer. To ensure that they would understand how to find answers in the future, what I generally did was ask a series of guided questions that led them to find the answer themselves. I could generally tell when they figured it out, as their face would light up, so to speak, when they discovered it. They felt engaged because they had done it.
You can do the same also. If you said, “I understand their process is X, Y, and Z. Is that right?” They would have an answer. Maybe yes, maybe no, but it would not be enlightening for them and would provide little value added to you. Instead, follow the approach provided here and guide them with questions that start at the general level and work down more detailed, engaging them in the process. Again, this will be emphasized later.
User Needs Not Satisfied
All your work has been implemented, and it’s the big day of the delivery of the system, and the first team of users sits down at their computer and use it. Then the open revolt happens. They do not like it and demand that the old system be returned to them.
Think this will not happen? Trust me, I have heard of it happening more than once. Fortunately, it had not happened on one of my projects.
If the outcome of a project is that users’ needs are not satisfied, it means you have missed requirements or that you wrote them insufficiently to focus on the real need. If you leave requirements out, you missed some aspects that the users need. This will cause people to reject the system, or at best, they may be slow to embrace the system. This could be as bad as work stoppage or people being reluctant to use the new system. There are ways to mitigate this. For example, have the users review your requirements work. It may not need to be the detailed requirements, but it should the business process description that helped generate the requirements, or better yet, the user stories. As you will see later, you write user stories in terms of what a user understands, rather than as requirement “shall statements.”
Missing the focus is slightly different. For example, you write a series of requirements describing the system monitor functions for the system. However, when you deliver it, they say, “Wait a minute, I do not know who changed what records are saved in the system. That’s what I need to know.” What you had heard and described in requirements and what the developers coded was “tracking how many records were added.” In reality, the users were trying to determine when storage needed to be added over time. That is not what you heard. So you completely missed the mark.
A way to help prevent this is to rephrase what the user stated in different words. What this does is force you to think about what the user said, convert it to terms you understand, and validate their need. The users will be glad to correct you if you miss your mark. Moreover, do not take offense, as you are trying to capture what they want.
Multiple Interpretations Cause Disagreements
Every statement you write should have only one meaning, or interpretation. If there is the possibility of multiple interpretations, then there is likely to be disagreements among the people who interpret those statements .
If the language used in the requirements is incorrect or not understood by everyone, then someone may not interpret it (and design it) the way the stakeholders and ultimate users may want. You will find out more about this in Chapter 3. You will learn the importance of word interpretation.
For example, there was a project with two different groups involved in the development effort. Those people who had a history of developing large systems within the organization used the word recall to mean removing a bad record from the database. However, the people who would use the new system used recall to mean calling for a group of hard-copy documents from an archive to be given to someone. Neither definition was incorrect. However, because of people’s background, they meant different things and initially caused confusion.
Other times you use a word, but just not precisely enough. For example, look at the following requirement:
1-10 DRAFT The BOSS record function shall capture the time that the record is added to the database.
That looks OK on the surface. However, time can be interpreted multiple ways. For example, most people might figure that is just the local time that the transaction took place. OK, if that is what is meant. What if this is a system that is for a nationwide company that has offices in four time zones? Then which is it? You must specify one time so the system compares like times. Now, assume this need exists for a bank system in one time zone, so local time is satisfactory. Well, is it, say, Central Standard Time or Central Daylight Time or both? If the latter, when does it change over?
A requirement engineer must be very precise.
Are the Requirements Verifiable ?
If you cannot verify that a need has been met, what good is that need? How will you know when it is done? The point is that you must have a means of verifying or validating the accuracy and efficacy of the requirements that you write. There can be various ways of doing this, such as having the test team validate them or, as discussed in preceding sections, having users verify that the requirements actually describe what is needed.
You must be able to envision some verification method for the requirement. There is more later about the various forms besides actually testing it. Suffice to say, you or someone else on your team should be able to say, “Yes, I can verify this.” Having your test team validate your requirements is an excellent technique. Moreover, as you gain experience, you will continue to improve in your own ability to check your work.
However, examine the following example:
1-11 DRAFT The BOSS user interface shall be so easy to use that my great-great grandfather will be able to use it.
For the time being, ignore whether this is a worthwhile goal. Look at the criteria you need to test—my great-great grandfather.
When I was young, I met two great-grandfathers, and one lived until I was a late teen. However, I never met one of my great-great grandfathers because he had died before I was born.
Therefore, that brings up a real issue for verifying the statement. You cannot verify it. Yes, this is a ludicrous example, but it does make a point. You cannot validate some statements. The following is another example:
1-12 DRAFT The BOSS software shall operate on the surface of Jupiter.
Since humans currently have no hardware that can operate on Jupiter, there is no way to test it. This is a little more representative, but not a great deal, but at least you are getting the idea of the kind of issue identified here.
Wasted Time and Resources Building the Wrong Functions
Sometimes a system is built, and the first reaction from users is, “Where is the search function? That’s what I need the most.” This is not limited to search but any number of functions the users want but did not get.
This problem could indicate some requirements are missing. On the other hand, too much emphasis was placed on items that do not have the same importance. The implied importance of each requirement is that they carry the same weights unless you specify otherwise. By that, if you have 100 requirements for the system administrator and only 10 for the other 80 percent of the users, you will spend about 89 percent of your time working the requirements for only 20 percent of the users. If the system is not primarily focused on system administration functions, they you may have captured too many requirements for system administration rather than the rest of the function. You must assign priorities to fix this issue. You must really examine the importance of each requirement. Then if most of your high-priority areas do not have many requirements, you may need to spend more time defining those areas. Another way is to look at each function and see how important it is. How many requirements define it? The more time you have spent defining this function may dictate the number of requirements associated with the function. However, something that is very complex will take more time to define, potentially skewing its importance. You will see more focus on this as you examine requirements throughout the rest of this book.
There are shortcuts, as will be talked about in user interface design, architecture, and so on, where the use of standards can significantly change the importance.
Regarding the missing requirements, the elicitation phase presentation will help to prevent this.
There is also a potential source caused by the developers who include functions that users did not ask for. They may think it is a neat improvement. Alternatively, it is something they have wanted to do for a long time. There are some elegant items coders like to add, which cost time and money at the expense of important functions. This is why developers need to have their proposed changes approved, regardless if it is waterfall, agile, or any other development methodology. Developers are not the only ones who have things added. Some managers, whether part of the development team or managers in charge of users, can decide they want functions added at the expense of the functions users need. Another technique you will hear more about later may help reduce this by getting people to state how often a particular function is used. Granted, legal or policy reasons may demand it. However, if such justifications do not exist, that is an indication that a function is not necessary.
As you can see, controlling this is important. Also, the distinction between this problem and scope or requirements creep can be blurred. The important point is to understand the challenge to overcome it.
Summary
You have been introduced to the most common and most important challenges in writing effective requirements, insufficient requirements, scope, requirements creep, volatility, stove-piped (siloed) requirements, users who are not sure what they need, user needs are not satisfied, multiple interpretations causing disagreements, whether the requirements are verifiable, and wasted time and resources building the wrong functions. The goal is to teach you how to mitigate these problems. You have seen some general solutions to these challenges. The rest of the book will dive into the details of how to eliminate each of these or significantly mitigate the impact of the challenges. In addition, in the last chapter, these problems will be examined against what was presented to see whether the addressed techniques helped to prevent them.
An early study cited in B.W. Boehm’s Software Engineering Economics found that “approximately 60 percent of errors occur during the requirements definition.” Yes, this is an older study, yet there doesn’t appear to be more recent studies or evidence to suggest that this has changed. The point is, the problems listed in this chapter do occur. This book will present ways to help prevent them. Keep in mind, if there are missing requirements or misinterpreted requirements, they may not manifest themselves until much later in the project’s lifecycle, possibly when it gets deployed. That is problematic as it can cost much more to fix them then. You need to vigilant to help prevent this.
Now, you will see what good requirements can accomplish.
Will this book teach you to manage all aspects of RE such that you can immediately become a manager of a team? This book can give some guidance. There are many other good sources that can help with that. This book will give you the foundation for your first job as an RE; it’s basically an excellent introduction to crafting good requirements. The most important element to help with higher responsibility is experience doing the job. You learn by doing.
That said, in the right person’s hands and in a startup project where almost everyone is new, you might be able to use this text as a guide, but that is the exception rather than the rule. You will see throughout this book, there are rules and there are guidelines, and many times the distinctions are blurred. Remember, earlier in this chapter I stated that you need to think. Well, you are going to learn how to do that when going through the requirements process. It is left to you to implement it—to gain your needed experience.
References
Boehm, B.W. Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, 1981.
Davis, Alan M. Software requirements: Objects, Functions, and States. Prentice-Hall, Inc. Upper Saddle River, NJ, 1993, p25–26.
Jones, Capers. Software Assessments, Benchmarks, and Best Practices. Addison-Wesley Professional, 2000.
Exercises
We are going to do something out of the ordinary here. Rather than ask for specific questions and answers for this chapter, we will do something differently. You will do the two exercises for this chapter, based on the limited information you have from Chapter 1 (and if you have any experience as a requirements engineer). Then, put your responses aside, as you will look at it again at the end of Chapter 15 to see if you have the same answers. There is no right or wrong answer; just see whether your understanding changes with time.
Exercise 1
Examine the problems that can happen as described in the “Challenges for Writing Effective Requirements” section in this chapter and rank which ones you think are the most critical to fix and why.
Exercise 2
Examine the problems that can happen as described in the “Challenges for Writing Effective Requirements” section in this chapter and rank which ones you think occur most frequently and why.