The Phases of Requirements Engineering

sheldonlinker

2 The Phases of Requirements Engineering

Requirements engineering is not a monolithic task. There are phases and they often repeat in a repeated process. Here are the phases of requirements engineering. As requirements engineers gain experience they begin to develop an understanding of when a phase is completed or needs to be revisited.

2.1. The Need

Before anything else can happen, there needs to be a perceived need for something. It could be a new product, some sort of research, or something the business needs to do.

2.2. Elicitation

Elicitation is extracting the need from the stakeholders. This may sound easy. It might sound obvious, but it is not. Elicitation is one of the hardest tasks in requirement engineering. Good requirements engineers must be clever. There are a number of obstacles that hinder elicitation.

Many stakeholders are not technical people and do not have the communication skills to explain what the system needs to do. Others have never defined formal business rules, so creating systems to implement those rules cannot even begin until they are defined. In some cases stakeholders have hidden agendas and may want a system built for selfish reasons that adversely impacts the organization as a whole. Oftentimes, stakeholders know something that you don’t. Be sure to glean that knowledge when you can. Sometimes, stakeholders believe something to be true, but it’s not. Test whatever theories that you can. And sometimes stakeholders’ opinions conflict. That’s when you really need to get things sorted out.

All of these obstacles make elicitation very difficult.

There is a perception that automation eliminates jobs. Studies often prove this is not true. Automation lowers costs, which eventually drives up revenue and often adds to the labor force. But the perception that automation eliminates jobs makes some stakeholders want to sabotage the project. Very often, automation frees people up from the rote-work to do their real jobs.

2.3. Analysis

The elicitation step gives you the raw data, but not the “cooked” or processed data. After the elicitation stage, you’re going to have a lot of data. It won’t necessarily be complete. There will be a lot of duplicate data, and likely there will even be conflicts. Some of the items elicited will be worth the effort, and some will not be. Some may not even be feasible. Yet others may have already been implemented.

In the analysis phase, your job is to translate a jumble of ideas into a coherent story that makes sense to the prospective users, and which makes business sense. It’s generally in this phase that the requirements specification is first written.

2.4. Negotiation

It is especially true in large projects that not all of the stakeholders agree on the requirements. Too often it is up to the Requirements Analyst to resolve this conflict through negotiation. While effective negotiation is an entirely other body of knowledge, here are some basic tactics that can be employed.

It is better to build a system that is flexible than inflexible.

Stress to stakeholders the importance of sticking to the requirements that they agree upon. This often minimizes the importance of requirements that they do not agree upon which increases the chance that one side will give in on a disagreement.

In projects where it is likely that there will be requirements disagreements, organizations often define voting power. When disagreements arise that cannot be resolved through negotiation, the decision is left to a vote. On some projects, there could be multiple stakeholders, but one person has all of the decision- making power. Often this is the person that is writing the check. To avoid issues in the middle of the project, it is best to define these powers early.

Oftentimes stakeholders need the system to meet some objective. They believe that the objective can only be met through one specific requirement. Often in requirements disputes, asking each stakeholder why that requirement is important can clarify the root objective. Identifying this root objective can lead to other methods to meet the objective.

2.5. Documentation

Although we started the requirements documentation in the analysis step, we can’t really say that the documentation is complete until after the negotiation step. Documentation might be in the form of a requirements specification, a collection of users stories, “cards” on a KanBan board, a user manual, or a host of other forms — whatever is appropriate for your project and customers, be they internal or external. Various forms of documentation will be discussed in more detail in the following pages.

2.6. Validation

Once the documentation is complete, you’re almost ready to go on to the next step, which will be the development stage (often starting with internal design), the next “sprint”, the “backlog”, or maybe even the “further refinements backlog”. But before we can say we’re done, there should usually be some form of validation. Usually this is done in proofing the documentation, but more importantly in going through whatever documentation was sent us, including requests, meeting transcripts or recordings, and whatever else we have to make sure that we have the truth (we don’t want any conflicts between what we agreed to and what we documented), the whole truth (we want to make sure we haven’t left anything out), and nothing but the truth (we want to make sure we’re not just making some requirements up, and we want to make sure that whatever requirements we’re listing are within the planned scope and budget of the project.). Lastly, we want to check that what we’re planning is within the planned schedule and budget. If not, plans, schedule, or budget have to change. See the Engineering Triangle section for more on that.

In general, the person who wrote the requirements document should not be the one checking it. The requirements document, like everything else in the project, should go through a formal quality assurance (QA) process when possible.

2.7. Use

These requirements documents would be worthless if they were not used. That’s why we’re doing them in the first place. The requirements document is going to be used in four places:

First, they’ll be used as a final gate or go-ahead (or “go/no-go”) point. Given that we’re going to build this, are we really going to proceed? This is the first place a project will succeed or fail based on the requirements. If the requirements are valid, and the work looks like it will fulfill need, ability, budget, and calendar, the project will proceed. Having a well-written document is important here, in that one grammatical error or typo can be the first chink in the armor that leads to lack of confidence in the project. So be careful there.

Second, the document will be used by the developers, and this is the key point. The document must be sufficient to code from. You don’t want the developers coming back to you and asking what you had in mind. On an Agile project that’s bad enough, but on a Waterfall project, you’re probably off on another project by then. There must be enough info to get the job done right, and the info must be unambiguous. You also want to make sure that you don’t have too much there. For instance, if you were to put in a requirement that Oracle be used when the system was already running on DB/2, that might end up in the installation of extra software and conversion code. If a project fails because of a bad requirements document, it is most likely to happen here, because they’ll build what you told them to build, or failing that they’ll build what they think you told them to build.

Third, the document will be used by the QA staff to verify that the programmers have done their work correctly. Again, your description of the work to be done needs to have been clear, concise, and unambiguous, or there will be arguments between the programmers and QA. An in such an argument, it’s hard to tell who’s right, but it’s very easy to tell that the spec-writer was wrong. If a project fails because of bad requirements in the QA phase, it’s typically because (a) QA things you told people to build one thing, and the developers thought you wanted something else, or (b) because you used the word “all” in some requirement, and the testing phase takes ten times as long as it should. For instance, “This must work with all browsers”, instead of a list of browsers that would constitute passing.

Last, various IDs in the document will be used for project tracking purposes. This is logically last, but it happens throughout the project. In a use-case document, you’ll generally have user stories known by number and name, or date and name, or number and date, or just number. Within those, you’ll have primary and first and second alternate paths, and step numbers within those paths. In IEEE-830 format (and other formal formats), every single requirement will have some sort of ID. For instance, some §3.4.5 might have one requirement in it with no ID of it’s own. That requirement would use the section number as an ID. But if there is more than one requirement in a section, then each requirement will have an ID, such as UI-1 or REQ-2.3 or some such, and each one will be tracked, typically as Blocked (meaning that something else has to be done before that one can be started), Development, QA, Failed, Reworking, Retesting, or Done.

2.8. The Step that’s Not a Step: Managing Expectations

Throughout the project, you have to make sure that the stakeholders know what to expect, and expect something reasonable. For instance, let’s say that you’re working for a car company that makes a car that gets 50 MPG. They want a car that gets “better” MPG. You and your team design an equivalent car that gets 60 MPG. The project is a great success, right? Well, maybe. If they expected you to product a car that get 55 MPG and you delivered 60, then you exceeded expectations and were wildly successful. If they expected 60 and you delivered 60, then you and the project were successful. If they expected 65, then the project was only partially successful, and if they expected 100 MPG, whether that’s a reasonable expectation or not, then the project was a colossal failure. So, the trick here is to manage expectations, making sure that everyone is in the loop, knows what the plan is, and knows what to expect. Make sure that they know what the risks are, especially in R&D. There may be small setbacks, experimental paths that don’t yield results, and broken parts or bugs to be fixed. Make sure that they know that although particulars can’t be predicted, some amount of parts will fail, bugs will happen, and sick time will be taken. Keep the communications channels open. Promise as little as possible as late as possible, and deliver as much as possible as soon as possible.

2.9. Acceptance

No project is ever a success unless the “customer” (internal or external) accepts the work. What acceptance means and how it works depends on the type of project you’re doing.

If it’s an internally funded project for internal use with a user interface, then it’s only a success if the users accept and use it.
If it’s an internally funded project for internal use that will function autonomously, then it’s only a success if it does what was planned.
If it’s an internally funded project producing a product that will be sold, then it’s only a success if people actually buy it, such that the total value of sales exceeds the combined cost of producing the product and of marketing it.
If it’s an internally funded project producing a product that will be leased or otherwise licensed over time, then it’s only a success if the outside customers not only buy in, but continue to use the product.
If it’s an internally funded project that is producing some sort of adware, such as a web-site that’s free to its users but which carries ads and makes its money that way, then it’s only a success if it delivers the audience week after week, in a demographic that the advertisers are willing to pay for. In this case, both the technology must be sound, and the content must be interesting.
If it’s an externally funded project (bespoke software), and it’s a time-and-expenses contract, then the customer is likely paying by the sprint or on deliverables, and the project is likely Agile. In this case, you have to keep the customer happy along every step of the way. That means that you have to make steady progress, and have something to show at every “dog and pony show” or “show and tell” with the customer, and the product has to fulfill that customer’s needs.
If it’s an externally funded project, and it’s a fixed-price contract, then the customer is likely paying on deliverables or milestones, or just some up front and the rest on delivery. In this case, every depends on the customer “signing off”. That means that you will have to prove (not just claim) that every requirement has been met.

In each of these circumstances, you have to prepare for that final success case from Day 1. You have to know what the win conditions are, so that you can plan for them. In the last case, there is extra work, because each specific requirement item is a separate contractual item, and any one of them can cause project failure, which can in turn cause a huge payout and possibly a lawsuit.

From Sheldon: Trust me on this one; I’ve been to court on this as an expert witness. People can get very unhappy, and then their lawyers want a lot of money from the other party.

2.10. How Things Can Go Wrong

Obviously, skipping a step can get you into trouble. Getting them out of order can be a minor problem. Note that there are a number of software development methodologies, each with its own sequence of requirements gathering steps. However, don’t be a slave to a list. If you need to do something, don’t just ignore it because it’s not on the list. The two items here that carry the most risk are managing expectations (where the “customer” thinks they’re going to get something other than what they’re going to get, when they’re going to get it, at whatever it’s going to cost them; and the acceptance phase. If you don’t have an acceptance plan, the entire project can be counted as a failure just because it never gets officially accepted.