- 1. Requirements Management
- 1 What is Requirements Management?
- 2 Why do you need Requirements Management?
- 3 Four Fundamentals of Requirements Management
- 4 Adopting an Agile Approach to Requirements Management
- 5 Status Request Changes
- 6 Conquering the 5 Biggest Challenges of Requirements Management
- 7 Three Reasons You Need a Requirements Management Solution
- 2. Writing Requirements
- 1 Functional requirements examples and templates
- 2 Identifying and Measuring Requirements Quality
- 3 How to write system requirement specification (SRS) documents
- 4 Adopting the EARS Notation to Improve Requirements Engineering
- 5 Jama Connect Advisor™
- 6 Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
- 7 How to Write an Effective Product Requirements Document (PRD)
- 8 Functional vs. Non-Functional Requirements
- 9 What Are Non-Functional Requirements and How Do They Impact Product Development?
- 10 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 11 8 Do’s and Don’ts for Writing Requirements
- 3. Requirements Gathering and Management Processes
- 1 Requirements Engineering
- 2 Requirements Analysis
- 3 A Guide to Requirements Elicitation for Product Teams
- 4 Requirements Gathering Techniques for Agile Product Teams
- 5 What is requirements gathering?
- 6 Defining and Implementing a Requirements Baseline
- 7 Managing Project Scope — Why It Matters and Best Practices
- 8 How Long Do Requirements Take?
- 4. Requirements Traceability
- 1 What is Traceability?
- 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3 Change Impact Analysis (CIA): A Short Guide for Effective Implementation
- 4 What is Requirements Traceability and Why Does It Matter for Product Teams?
- 5 Key Traceability Challenges and Tips for Ensuring Accountability and Efficiency
- 6 How to Create and Use a Requirements Traceability Matrix
- 7 Traceability Matrix 101: Why It’s Not the Ultimate Solution for Managing Requirements
- 8 Live Traceability vs. After-the-Fact Traceability
- 9 How to Overcome Organizational Barriers to Live Requirements Traceability
- 10 Requirements Traceability, What Are You Missing?
- 11 Four Best Practices for Requirements Traceability
- 13 What Are the Benefits of End-to-End Traceability During Product Development?
- 5. Requirements Management Tools and Software
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- 8. Systems Engineering
- 9. Automotive Development
- 10. Medical Device & Life Sciences Development
- 1 The Importance of Benefit-Risk Analysis in Medical Device Development
- 2 Software as a Medical Device: Revolutionizing Healthcare
- 3 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 4 What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 5 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know
- 6 Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT)
- 11. Aerospace & Defense Development
Why do you need Requirements Management?
Not every manager is convinced that his team needs to do a better job on requirements development and management, or that such an investment will pay off. Numerous industry studies, however, indicate that requirements issues are a pervasive cause of project distress. The often-quoted CHAOS Reports from The Standish Group indicate that three of the biggest contributors to projects that fail or are “challenged” are lack of user input, incomplete requirements and specifications, and changing requirements and specifications.
Why Do You Need Requirements Management? An Economic Argument
The case for implementing better requirements practices is an economic or business argument, not a philosophical or technical position. Think about how your company’s bottom line is affected by requirements-related problems. Then use that understanding to justify investing in better requirements practices that can pay off for the long term.
A recent case study of requirements failure was the Federal Bureau of Investigation’s new case management software system, called VCF. This project was abandoned after $170 million had been spent because the delivered software was full of defects and off-target functionality. As one investigator wrote:
I suspect what happened with the VCF is that in the rush to put in place a system, you think you got your requirements nailed, but you really don’t. It was a classic case of not getting the requirements sufficiently defined in terms of completeness and correctness from the beginning. And so it required a continuous redefinition of requirements that had a cascading effect on what had already been designed and produced. (Goldstein, Harry. 2005. “Who Killed the Virtual Case File?” IEEE Spectrum 42(9): 24–35).
Numerous studies have examined the effects of errors in requirements on software projects. They consistently find that nearly half of the discovered defects originated as requirement errors. The typical outcome of errors in the requirements is an expectation gap, a difference between what developers build and what customers really need. Clearly, any domain that is the root cause of approximately half of the problems on software projects deserves our attention.
The main reason errors in requirements are so damaging is that they force the development team to perform extensive rework to correct the errors. It’s well-established that the cost of correcting a software error increases dramatically the later it is discovered, as shown in Table 1. An error, omission, or misunderstanding in the requirements forces developers to redo all the work they’ve already done based on the incorrect requirement. Therefore, any technique that can reduce requirement defects and prevent some of this wasted effort is a high-leverage investment indeed. One analysis of the potential return on investment from better requirements suggested that requirement errors can consume between 70 and 85 percent of all project rework costs.
Table 1. Relative Cost to Correct a Requirement Error
|Stage Error Is Discovered||Relative Cost to Correct|
|System or Acceptance Test||8–20X|
RELATED ARTICLE: Requirements Management Tools and Software
What Better Requirements Can Do for You
In addition to avoiding some of the negative consequences described above, better software requirements provide numerous benefits. These include selecting the right projects to fund, facilitating estimation, enabling rational prioritization, developing higher quality designs, and testing more effectively.
Selecting projects to fund. Good preliminary requirements enable senior managers to make effective business decisions as organizations decide which among a set of potential projects to fund. Better requirements allow more accurate projection of business returns. Once a project is funded, better requirements allow project managers to more sensibly partition tasks among their teams and even among individual team members.
Facilitating estimation. Well-understood requirements can help your team estimate the effort and resources needed to execute a project. Reliable estimation requires some historical correlation between requirements size and effort.
Enabling prioritization. Documented requirements allow the team to prioritize its remaining work. Most projects need to make compromises to ensure that they implement the most critical and most timely functionality. A prioritized requirements baseline helps the team incorporate those changes that will deliver the maximum customer value. One study revealed that just 54 percent of the originally defined features were delivered on an average project. If you can’t implement all of the requested functionality, make sure the team implements the right portion.
Developing designs. Requirements are the foundation for design. Therefore, well-understood and well-communicated requirements help developers devise the most appropriate solution to the problem. High-quality requirements also ensure that the development team works on the right problem. Many developers have experienced the frustration of implementing functionality that someone swore they needed, only to find that no one ever used it. One survey indicated that fully 45 percent of the delivered software product features were never used. Wasting less time implementing the wrong functionality accelerates the project and maximizes its business return.
Testing effectively. Well-defined and testable requirements allow testers to develop accurate test procedures to verify the functionality. Prioritizing requirements tells testers which ones to concentrate on first. Assessing requirement difficulty and risk helps testers know which functionality should receive the closest scrutiny.
Tracking project status. A comprehensive, traced set of requirements helps the stakeholders know when the project is done. A body of work is complete when all of the requirements allocated to it are either verified as being correctly implemented in the product or deleted from the baseline. Defined business requirements also allow the stakeholders to determine whether the project has met its goals.
Accelerating development. Believe it or not, investing more effort in developing the requirements can actually accelerate software development. This seems counterintuitive, but it’s true. Defining business requirements—the expected business outcomes the product will provide—aligns the stakeholders with shared vision, goals, and expectations. Effective user involvement in establishing the requirements reduces the chance that users will reject the new system upon delivery. Following are some published illustrations.
- In a study of 15 banking and telecommunications projects, the most successful projects spent 28 percent of their resources on requirements engineering, whereas the average project in the study devoted just 15.7 percent of its effort to requirements.
- Increasing the fraction of the total budget devoted to requirements on a group of NASA projects led to substantially lower overrun of both cost and schedules; see Table 2 (Hooks, Ivy F., and Kristin A. Farry. 2001. Customer-Centered Products: Creating Successful Products Through Smart Requirements Management. New York: AMACOM).
- In a European survey, the fastest project teams spent about twice as much of their schedule (17 percent versus nine percent) and effort (14 percent versus seven percent) on requirements activities as the slower teams.
Table 2. Cost and Schedule Overruns on Some NASA Projects
|Percent of Budget Spent on Requirements||Number of Projects||Average Project Cost Overrun|
|5 to 10%||7||83%|
Accurate requirements ensure that the functionality built will let users perform their essential business tasks. The requirements also establish achievable quality expectations. This lets the team implement both the capabilities and the product characteristics—the nonfunctional requirements—that will make users happy. Additionally, emphasizing requirements development is cheaper than relying on beta testing to find requirements problems. Fixing problems that late in the game is far costlier than correcting them earlier.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
In This Webinar, We Discuss the Benefits of Modern Requirements Management
Requirements Gathering is the process of understanding what you are trying to build and why you are building it.