2008-Nov-30 - Requirements: An introduction

throughout an organization have a vested interest in producing solid requirements. Whether you're a client or involved in procurement, finance and accounting, or IT, you are a major stakeholder in the requirements management process. Many project teams...
 Requirements: An introduction  
Requirements: An introduction
Scott McEwen ()Metasys Technologies, Inc.
from The Rational Edge: Accurate requirements are an essential part of the formula for software project success. This article explains why, and describes a three-fold approach to effective requirements documentation.
A Fortune 100 company embarked on a project to design and build a sophisticated software package that it would ultimately deploy to its offices throughout the world. Two years and about $10 million later, the field offices refused to use the software because it didn't do what it was intended to do. Instead of helping to streamline an important business process, the software actually hindered it.
In another case, a leading software integrator was awarded a contract by the procurement organization for a major utility company. Later, that organization was shocked when the integrator informed it that, based on"true" client requirements, the project's scope had increased twofold.
Do these stories sound familiar? Why do things like this happen? According to a recent survey by the Standish Group1 of more than 352 companies reporting on more than 8,000 software projects:
31 percent of all software projects are canceled before they are completed (a waste of $81 billion). 53 percent of projects cost 189 percent of their original estimate. In large companies, 9 percent of projects are on time and within budget. In small companies, 16 percent of projects are on time and within budget. The Standish Group survey also asked respondents to identify the causes of these failures. Table 1 shows the top three reasons why projects are "impaired."

Table 1: Top three project impairment factors (Standish Group survey)

As this table shows, poor requirements are the biggest problem. If it isn't clear what you are supposed to build, how can you estimate the cost of building it? How can you create a project plan, assign resources, design system components, or create work orders? You need accurate requirements to perform these activities. Of course, requirements evolve as a project proceeds, but carefully worded basic requirements provide a starting point. Then, as the project progresses, you can fill in details and update planning documents as the requirements evolve.
So what is a requirement? This article attempts to explain this commonly misunderstood term. Rather than supplying a definition up front, we will discover one by understanding first why we need requirements, and then examining the content of the different documents we use to capture them.

Why do we need requirements?
We use requirements for a variety of purposes, including:
Project scoping Cost estimating Budgeting Project scheduling Software design Software testing Documentation and training manuals Individuals throughout an organization have a vested interest in producing solid requirements. Whether you're a client or involved in procurement, finance and accounting, or IT, you are a major stakeholder in the requirements management process.
Many project teams treat requirements as a statement of purpose for the application and express them in very general terms, such as: "The system should have the ability to create problem tickets for outage notifications." But is this a solid requirement?To answer this question, let's look at how we document requirements.

Classifying and documenting requirements
Requirements are not requirements unless they are written down. In other words, neither hallway conversations nor "mental notes" constitute requirements. We typically capture requirements in three separate documents:
Stakeholder Needs Software Features Software Requirements Specification At my organization, we associate about a half dozen attributes (e.g., priority, status, etc.) with each requirement to help with decision making, scheduling, and so on. The information contained in one requirement document should be referenceable in the others. For example, the information recorded in the Software Features document should support and be traceable to one or more items listed in the Stakeholder Needs document.
To better understand the relationships among these documents, let's return to my earlier question about whether the statement, "The system should be able to create problem tickets for outage notifications" is a valid requirement. The answer is, "Not yet." What this statement expresses is a need. Capturing this need is a step toward formulating a solid requirement, but the statement cannot stand alone; you must first translate it into one or more features that you capture in a Software Features document. Those features, in turn, must then be detailed in the Software Requirements Specification document.
Using these three separate documents also helps to simplify the process of requirement reviews. Although an executive manager might be a reader/approver for the Stakeholder Needs and Software Features documents, he/she may delegate responsibility for reading and approving the more detailed Software Requirements Specification. Maintaining separation among these different documents allows specific readers to understand specific parts of the system. It also promotes better accountability -- a key element for a successful software development process.

Documenting stakeholder needs
Let's look at what each of these documents contains (see Figure 1). We'll start with the Stakeholder Needs document.
As we describe what to capture in each document, keep in mind that whatever needs and requirements you formulate at the outset of your project will evolve as your project proceeds. If you are using an iterative development approach, you should assess your requirements after each iteration, and if you make changes in one document, you should update the others as well to maintain consistency.

　Figure 1: Requirements categories
Stakeholder needs, which are part of the problem domain, describe what stakeholders require for a successful project. In other words, needs describe what the application should do to help improve or lower the cost of a business process, increase revenue, or meet regulatory or other obligations.
Documenting stakeholder needs involves identifying, understanding, and representing different viewpoints. Often, users and stakeholders don't know how to solve the entire problem but are experts at explaining what they need to do their job better. Each stakeholder sees the problem from a different perspective. Therefore, you must understand the needs of all stakeholders in order to understand the entire problem domain.
The first step is to identify all stakeholders. Users represent a class of stakeholders, but by no means do they represent the interests of the whole organization. Other classes of stakeholders may come from finance and accounting, procurement, and IT, as well as from other departments or organizations that directly or indirectly support or benefit from the project.
You should identify (and recruit) at least one representative from each stakeholder class who will speak for the entire class. Also, document your list of stakeholders so that everyone knows who is representing each class.
You can elicit needs from stakeholders using various techniques, including one-on-one meetings, questionnaires, storyboarding, and Joint Application Development (JAD) sessions. Explanations of these specific techniques would be beyond the scope of this article, so for now, just be aware that how you ask questions and the format you use are important aspects of the process.
Let's look at a hypothetical project aimed at streamlining a help desk application for a major corporation's IT department; we'll use this project as an example throughout the remainder of this article. Imagine that you, a project team member, have met with the help desk manager and formulated a requirement that says, "He needs to be able to increase the number of support calls his team can handle by 30 percent, without increasing headcount."
Note that this need requirement provides little detail, but it clearly conveys what the client wants at a high level. Ambiguity is expected at this stage; you will capture more detail later.
But not all the needs you gather will describe system functionality. For example, a stakeholder from procurement or finance might say, "The budget for the initial implementation of the application help desk project cannot exceed $350 thousand." Of course, this perfectly valid need might conflict with other stakeholders' needs that might cause the budget to exceed $350 thousand; resolving conflicting needs is a normal part of the requirements management process. However, in the beginning, you should focus on eliciting and recording the perspective of each stakeholder; conflict resolution can come later in the process.

Documenting software features
After you have defined stakeholder needs, you must translate them into a set of distinct system features. What's the difference between needs and features? Needs do not indicate a particular solution; they simply describe the business need. For example, if a stakeholder says, "We need to streamline the help desk's application support process because we can't keep up with the calls," that person is expressing a need that the development team can translate into a feature.
However, if the stakeholder says, "We need a Web-enabled system so that customers can enter their own support requests," the stakeholder has already translated the need into a feature. It is perfectly fine for stakeholders to express themselves in any way they wish; often, you will want to ask additional questions to clearly understand both needs and features. I'll explain why in a moment. For now, let's define what a feature is.
A feature is a service that the system provides to fulfill one or more stakeholder needs.

　 It is important for the development team to understand the distinction between needs and features and to record them in separate documents. Why must they separate needs from features? Needs are part of the problem domain, and features are part of the solution domain. It is critically important to fully understand the problem domain before deciding on a solution; often, you will find opportunities to generalize the solution once you fully understand the problem. In other words, by separating needs from features, you can find a common set of features that will meet multiple needs. Like the Stakeholder Needs document, the Software Features document should be available to all team members throughout the process. And it is important to maintain traceability from each feature to its corresponding need(s).

Let's return to our example of a help desk support application. Table 2 shows three stakeholder requests expressed as needs.
Table 2: Stakeholder needs

　Table 3 shows the corresponding features mapped to these needs.
Table 3: System features mapped to stakeholder needs

　 Keep in mind that this is a highly simplified example. Complex systems can involve lots of stakeholders, external system interfaces, complex workflows and analytics, and other elements that make translating needs into features far more difficult.