The Essential Guide toRequirements Management and Traceability
Chapters
- 1.Requirements Management
- Overview
- 1What is Requirements Management?
- 2Why do you need Requirements Management?
- 3Four Fundamentals of Requirements Management
- 4Adopting an Agile Approach to Requirements Management
- 5Conquering the 5 Biggest Challenges of Requirements Management
- 6Three Reasons You Need a Requirements Management Solution
- 2.Writing Requirements
- Overview
- 1Functional requirements examples and templates
- 2Product requirements document template and examples
- 3How to write system requirement specification (SRS) documents
- 4Adopting the EARS Notation to Improve Requirements Engineering
- 5Jama Connect Advisor™
- 6Frequently Asked Questions about the EARS Notation and Jama Connect Requirements Advisor
- 7How to Write an Effective Product Requirements Document
- 8Functional vs. Non-Functional Requirements
- 9What Are Non-Functional Requirements and How Do They Impact Product Development?
- 10Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 118 Do’s and Don’ts for Writing Requirements
- 3.Requirements Gathering and Management Processes
- 4.Requirements Traceability
- Overview
- 1What is Traceability?
- 2Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3What is Requirements Traceability and Why Does It Matter for Product Teams?
- 4How to Create and Use a Requirements Traceability Matrix
- 5Traceability Matrix 101: Why It’s Not the Ultimate Solution for Managing Requirements
- 6Live Traceability vs. After-the-Fact Traceability
- 7How to Overcome Organizational Barriers to Live Requirements Traceability
- 8Requirements Traceability, What Are You Missing?
- 9Four Best Practices for Requirements Traceability
- 10Requirements Traceability: Links in the Chain
- 11What 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
- Overview
- 1Understanding ISO Standards
- 2What is ISO 13485? Your Comprehensive Guide to Compliant Medical Device Manufacturing
- 3A Guide to Automotive Safety Integrity Levels (ASIL)
- 4What is DevSecOps? A Guide to Building Secure Software
- 5Compliance Management
- 6What is FMEA? Failure Modes and Effects Analysis
- 7What’s a Design History File, and How Are DHFs Used by Product Teams?
- 8.Project Management
- 9.Measuring Requirements
- 10.Systems Engineering
- Glossary
How Long Do Requirements Take?
Business analysts and managers sometimes ask how long it will take to “do requirements” on their next project.
As with so many issues in software and product development, the correct answer to this question is “it depends.”
Multiple variables contribute to this issue. Various industry averages have been published to suggest what percentage of a typical project’s effort should be devoted to requirements development, which includes activities such as requirements gathering (also known as requirements elicitation).
Data from different benchmarks don’t agree very well, though, and whether these “typical” projects are similar to your own is questionable. In this article, adapted from my book, “More about Software Requirements,” I’ll offer some suggestions about how you can determine an appropriate amount of time and effort to invest in things like requirements gathering.
Industry Benchmarks
Here’s an illustration of how benchmarks may or may not be helpful. Table 1 (below) presents some industry benchmark data for the average percentage of total effort and the average schedule time that projects in several different categories devote to requirements elicitation and prototyping (data from Capers Jones’ “Software Assessments, Benchmarks, and Best Practices”). These benchmarks are for very large projects of 10,000 function points in size (approximately one million lines of code). How similar are your projects to these benchmarks?
There’s another problem with using industry benchmarks such as these. The data doesn’t indicate how successful those projects were or define what “success” means for each project. Nor does this data indicate whether the more successful project teams devoted more of their effort to requirements elicitation activities than the less successful teams — they’re just averages of actual performance.
Whereas typical project teams devote perhaps 10% or less of their effort on things like requirements gathering, investing more has a big payoff, provided the team doesn’t get trapped in analysis paralysis. Contrary to what many people believe, spending more effort in improving your requirements development process can actually accelerate development.
RELATED ARTICLE:INCOSE Systems Engineering Handbook
While working on small projects when I was employed at Kodak, my team would typically devote 15%-to-18% of our total effort on requirements activities. We found this investment reduced the amount of post-delivery rework. It’s difficult to link causes and effects with certainty, but I believe the greatest contributing factor to our low maintenance level was the extensive user participation we cultivated.
我无法告诉你你应该多久expect to spend on requirements gathering foryournext project. However, Figure 1 identifies some of the conditions that can accelerate your requirements process and several other factors that lengthen the time needed for developing effective requirements.
Your Own Experience
首先,你最好收集一些data on how much of your own project effort is spent on requirements gathering. That’ll help you judge how well your requirements development process has worked for you in the past. Use this historical data when estimating the requirements effort needed for future projects. Adjust your initial estimate by using the considerations in Figure 1 to compensate for differences between your next project and the benchmark projects. Consider any additional factors that would influence your own project. You might weight each of the factors shown in Figure 1 on a scale of 0 (no effect) to 5 (major impact). This analysis can help you spot risk factors that could prolong your requirements development work.
Another factor to consider is the development life cycle that the project is following. Not all the requirements elicitation effort should be allocated to the early stages of the project, as is the case in the sequential or waterfall life cycle (dotted line in Figure 2). Don’t think in terms of a discrete “requirements phase,” but rather about a set of requirements-related activities that span the project’s life cycle. In particular, requirements management will be performed on an ongoing basis once a set of requirements baselines emerge for the System Requirements Specification (SRS) and change requests begin to appear.
Figure 2. The distribution of requirements effort over time varies for projects that follow different development life cycles.
Iterative and Incremental Approaches
Projects that follow an agile development approach, such as Scrum, take an incremental approach, rapidly building small portions of the product. This puts potentially useful functionality in the users’ hands quickly so that users can refine their needs and developers can keep up with changing business demands. Agile projects will have frequent but small requirements gathering efforts (solid line in Figure 2).
而不是前端装载和传统al projects, the requirements effort on an agile project is threaded throughout the project. Initial requirements explorations lead to a backlog of intended functionality of various priorities. When a particular feature or function is allocated to a specific iteration, the team will then refine the requirements for that functionality to whatever level of detail is needed to enable development and testing to proceed with confidence.
Many years ago, one of my software development group’s successful projects took just such an incremental approach. This project released useful functionality to the internal corporate user community every three weeks. The first part of each three-week cycle was spent on project planning, developing, and gathering requirements for that increment. The team did just enough requirements development for that increment, quickly implemented it, and provided new functionality to the users a piece at a time. The users provided feedback on those increments that helped steer the rest of the project toward delivering maximum value.
Not all projects are amenable to such fine-grained incremental delivery. When reengineering an existing application, for instance, the new system needs a critical mass of functionality before users can switch to it. Regardless of how large an increment your team tackles on each project cycle, they need to understand the requirements for that increment to avoid extensive rework of designs, code, and tests.
Planning Requirements Elicitation
As with so many aspects of projects, there’s more to requirements gathering than initially meets the eye. As you’re identifying the tasks your analysts might need to perform, consider whether activities such as the following will be necessary:
- Negotiating commitments with product champions.
- Holding elicitation workshops and conducting interviews.
- Reviewing existing documents and products.
- Preparing, distributing, and analyzing surveys.
- Creating and evaluating prototypes, analysis models, and other requirements views.
- Performing feasibility, risk, safety, failure, and hazard analyses.
- Entering requirements information into a database.
- Reviewing requirements specifications.
- Developing test cases from requirements and walking through the test cases.
- Revising requirements specifications following review or test analysis.
Your team might not perform all these activities on each project, and they might have to do other tasks as part of requirements elicitation, analysis, specification, and validation. Anything you learn about the tasks the analysts actually perform and how long those tasks take will improve your ability to estimate the requirements development effort needed for future projects.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached atProcessImpact.com.
RELATED ARTICLE:Best Practices Guide for Writing Requirements
In This Webinar, Learn More About Requirements Traceability
Traceability:relationships between items to show evidence of requirement decomposition and verification coverage.
Ready to Find Out More?
Our team of experts is here to answer any questions and learn how we can help enable your continued success. Get started by filling out this form so we can connect!