Mastering Requirements: 10 Key Steps to Deliver Winning Products
Why do so many organizations struggle with requirements? There seem to be two paths that organizations follow for requirement definition and management. Some organizations rush through the requirement phase to get to design and implementation while others have invested in the panacea of requirement tools and processes. Yet many of these organizations appear to be doomed to the schedule slips and budget overruns caused by the iterative rework cycles of poor and incomplete requirement sets.
But all organizations do not have these requirement problems. Some projects go smoothly and provide the customer with what they want, when they want it, with the desired quality. We call that delivering a winning product. What is it that differentiates organizations that produce winning products from those that struggle with requirements?
Introduction
We all want to be members of a project team that produces a winning product. A winning product is one that is delivered on time, with the desired functionality, at the agreed upon cost, with the required quality attributes. In 1995, the Standish Group surveyed U.S. government and business software projects and reported that seventeen percent were successful or produced a winning product. Thirty-three percent of the projects surveyed failed to deliver and the remaining fifty percent were challenged. Challenged meant that they did not deliver all of the desired functionality and had significant cost and schedule overruns. In 2002 those numbers are thirty-four, fifteen, and fifty-one percent respectively. The percentage of winning projects has doubled, while the percentage of failed projects has decreased to half its earlier value. Remarkably, the percentage of challenged projects has remained relatively constant at fifty-one percent! If you recognize your project as one of the challenged, how do you break out of the middle of the pack?
The single factor that seems to consistently distinguish projects that lead the pack from all others is the quality of the project’s requirement set. Projects with a complete and consistent requirement set are most likely to produce a winning product. This paper describes ten steps that lead to better requirements. Incorporating these steps into a requirement definition process improves a project’s chances of creating a winning product. The first five steps describe techniques and data elements that form the foundation for a good requirement set. Once the foundation has been established, the remaining five steps help to ensure the requirements are clear and consistent. These techniques help requirement writers compose requirements that guide the reader to their intended interpretation and help the project produce a winner.
Building the Foundation
Defining product or service requirements is hard work. Many of the product development steps have been automated. There are tools to automate the requirement management process, computer-aided design tools, better compliers, debuggers, and automated test tools. But automation has not been realized for the requirement definition process. Requirement definition requires clear thinking. To get the requirements right the first time, projects need a common vision and product knowledge so they can stay on track. The first five steps create that vision and capture the necessary knowledge.
Step 1: Define the Need, Goals and Objectives
The need is a succinct statement that captures the compelling reason for undertaking the project. It establishes the focus of the project team. Everything the team accomplishes should be directed at meeting the need. The need should not change. If the need does change, it is time to start over, not try to work around a complete change in scope. Goals are what the project team must accomplish to meet the need. Objectives tell team members how they will recognize that the goals have been achieved.
Step 2: Identify the Stakeholders
A stakeholder is anyone who has an investment in the project or can upset the applecart by poking a stick into the wheels. They include members of the development and customer organizations, as well as end-users. Quality assurance personnel, including testers, are also stakeholders. All stakeholders exert some influence over the project requirements.
Every stakeholder group has a specific body of knowledge. This knowledge comes in three types. Common knowledge is understood by all stakeholders. Shared knowledge is understood by two or more stakeholder groups but not by all groups. Unique knowledge is available to only one stakeholder group. Left to work on their own unique knowledge, each stakeholder group will develop their own set of priorities and agendas. This will cause problems and conflicts.
Understanding each stakeholder’s perspective, priorities, and agendas will help evolve a common vision. Instead of reacting to problems and conflicts as they arise later on, the issues get identified upfront, so they are diffused and resolved early. The next three steps will raise the awareness of unique shareholder knowledge pertaining to the project and move it to the common knowledge level. The more complete or thorough the project is in identifying and communicating with all of the stakeholders, the higher the probability of producing a high quality requirement set.
Step 3: Recognize the Project Drivers
Drivers are external to our product. Drivers include regulations, customer schedules, existing platforms and equipment, or other interfacing applications. We can not change or work around them. Because drivers affect the product requirements by imposing restrictions or limiting potential solutions, the project must identify them. Known drivers can be handled. Unknown drivers spell trouble.
Step 4: Create Operational Concepts
An operational concept is a story or scenario that describes an operation or interaction with the product. These concepts are captured in the language of the stakeholders. The beauty of this step is that it is intuitive. Stories have been used to store and disseminate information for a very long time. It does not require much training to improve stakeholder storytelling skills.
To capture the data and knowledge needed, every stakeholder group or their designated representative must prepare one or more operational concepts for each phase of the entire product lifecycle in which they are involved. The accumulation of data, the precursor to the requirements, helps to reduce requirement omissions, expose assumptions, assess interfaces, and evaluate “what if” scenarios. This shared knowledge increases understanding and domain knowledge between all stakeholders. Operational concepts ease the transition from needs and stakeholder priorities to verifiable requirements. They also form the basis for testing scenarios, thereby facilitating verification planning.
Step 5: Determine the External Interfaces
External interfaces are the points where the product interacts with an outside element. These are the points where data flow in and out of the product. The points where support services such as power or cooling are obtained. External interfaces include access points for end-users to input or view information. As such, the external interfaces define the boundaries of the product. Determining the external interfaces early helps the project team understand what is within their purview and what is not.
Any tester knows that problems tend to congregate at transition points. Transition points are places where things change. For example, negative to positive, hot to cold, or accelerating to decelerating. External interfaces are transition points. At the interface things transition from one system’s point of reference to another and can be problematic. Care should be exercised to ensure the project team understands the interfaces and the worst that can happen during transitions from the external elements to the product or from the product to external elements.
Writing Good Requirements
A product requirement is a statement of something the product must do or a quality the product must have. Using the five steps discussed previously, the need for the product, which will serve to maintain team focus, was established. The stakeholders who will provide the necessary information were identified. Operational concepts were used to elicit and capture the information required from all stakeholders. The product boundaries were determined using external interfaces. The next five steps will use this foundation to develop and organize a good set of requirements.
It is a Communications Issue
The goal is to document requirements that each reader or requirement user will interpret in exactly the same way. Achieving this single interpretation is not easy! One problem is people tend to think in pictures. If the word apple is displayed on a blank screen in front of a group, some will “see” a red apple while others will see a green or yellow apple. Some in the group may imagine a computer and some will picture a rainbow-colored apple with a bite out of it.
All of us come from different backgrounds. Our cultural, regional, and educational differences create filters and priorities that we apply to everything we consider. These filters account for the divergent interpretations of an innocent word like apple. How can requirement writers overcome these filters and priorities to achieve the desired single interpretation? This is largely a communications issue the next five steps will help overcome.
Step 6: Create a Simple Format
A simple format allows the requirement writer to organize their thoughts in a straightforward manner. A highly recommended format is simply subject verb object. The subject describes the part of the product that is responsible for providing the action or quality desired. The object is the desired action or the quality the responsible component must provide or have. The verb is the correct connecting term.
Products are developed in levels starting at the customer and system level, perhaps moving to subsystems, and continuing to flow down until the team is dealing with components. Thus, if we are at the system level, every requirement should start with “The system…” Do not fall into the trap of believing that the responsibility is implied based on the document or section it is in. The requirement writer may have been thinking about something else at the time. The incorrect assignment of responsibility will cause rework. Explicitly assigning responsibility for every requirement will make it easier for reviewers to catch these errors.
The object should be as simple and concise as possible. The object should also be grammatically correct and stated positively. Adjectives, adverbs, and clauses are grammatical constructs designed to free the reader’s imagination. This is not the desired response. Guiding the reader to the desired interpretation can be easier to achieve by minimizing the use of these constructs.
There are three internationally recognized connecting terms or verbs to use in requirement documentation. They are shall, should, and will. The term shall is used to indicate that the statement is a requirement. The term should indicates that the statement is a goal. Finally, the term will indicates that the statement is a fact. These terms are widely recognized by the requirement community and have gained precedence in the legal community as well.
Consistently applying the format step allows the document reader to recognize a statement as a requirement before they even read it. Some examples include:
- The system shall operate at a power level of 5 watts.
- The software shall acquire data from the online database.
- The structure shall support a weight of 250 pounds.
This instant recognition is a distinct advantage.
Step 7: Watch Your Terminology
The requirement writer should strive to avoid ambiguous terminology. Ambiguity is another opportunity for the requirement reader’s imagination to soar. Writers should avoid terms with multiple definitions whenever possible. Use industry-accepted standard terminology. Do not use more than one term to refer to the same thing. Organizations should develop a list of terms and phrases to avoid. Add terms and phrases that cause difficulty to the list as they are discovered. Make searches for items on the list part of requirement reviews. As seen in the apple example above, even seemingly innocent terms can evoke different images.
Step 8: Capture Requirement Rationale
The need to include explanation in or with requirements seems to be overpowering. It is probably a result of trying to ensure the reader interprets the requirement as it was meant. Unfortunately, adding this additional information to the requirement frequently has just the opposite effect. The true meaning of the requirement or even the requirement itself is hidden or lost in the ensuing confusion. Multiple requirements, explanations, facts, and a goal or two captured in a single paragraph can be very difficult to sort through.
Rationale is a technique to organize this data and attach it to a specific requirement. The rationale can include the need for the requirement, information on trade studies, what assumptions were made, or the design effort that affects the requirement. Rationale can capture any information the writer feels is necessary to help understand or maintain the requirement.
Rationale gets attached to its requirement to improve understanding of the requirement. If the requirements are being captured in a requirement management tool, create a field called rationale. If the requirements are being maintained in a document, place the rationale, labeled and in italics, immediately following or below the requirement. With either method, reviewers and readers should become accustomed to seeing requirements with accompanying rationale.
Step 9: Think About Verification
All requirements must be verified. Understanding this, sometimes one can only wonder what the requirement writer was thinking. A proposed verification method is another piece of data the requirement writer should record along with the requirement. If the requirement writer thinks about how they would verify the requirement when they write it, the quality and verifiability of their requirements will improve. This will make requirement reviews and verification easier. Of course, the verification team is not bound by the requirement writer’s choice of verification method. The verification team has methodologies for optimizing verification.
Step 10: Employ a Standard Template
An organization should develop a standard requirement template and use it consistently. Sample templates are readily available from standards organizations such as IEEE and ISO. An organization can also develop their own from the many examples available on the web.
The template should include format guidance and examples. Include all of the types of requirements that typically appear in the organization’s products. The template will serve as a checklist to ensure that there are no requirement omissions. The exclusion of a particular requirement type should be based on conscious decision, not due to an error of omission.
Conclusion
This paper has discussed ten steps designed to improve the quality of an organization’s requirements. The first five steps address obtaining the information necessary to develop a good requirement set and the remaining five steps describe how to present and organize requirements. The steps presented are not a magic formula, but they aren’t rocket science either. Writing requirements is hard work and there is still no substitute for clear thinking to produce quality requirements. Applying the techniques covered in this paper will improve the quality of the requirements an organization produces. Better requirements result in less rework, thereby reducing or eliminating schedule and budget problems. Better requirements will also increase the chances of producing a winning product.
About the Author
At the time this paper was presented, Larry A. Fellows was the Director of Process Management and Assessment Services at Compliance Automation Inc. Larry provided process definition consulting and mentoring, conducted systems and software process assessments, and taught training seminars covering requirement definition, requirement management, requirement reviews, and inspections.
Paper by Larry Fellows presented at the International Conference on Practical Software Quality Techniques (PSQT)and Practical Software Testing Techniques (PSTT) 2003 North, Minneapolis, MN, on September 10, 2003.