- Agility Guide
- Requirements Process in Context
- The Process
- A Case Study
- Trawling for Requirements
- Prototyping the Requirements
- Scenarios
- Writing the Requirements
- The Quality Gateway
- Reusing Requirements
- Reviewing the Specification
- Iterative and Incremental Processes
- Requirements Retrospective
- Your Own Requirements Process
- In Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Reusing Requirements
Requirements for any product you build are never completely unique. We suggest that before starting on any new requirements project, you go through the specifications written for previous projects and look for potentially reusable material. Sometimes you may find dozens of requirements you can reuse without alteration. More often you will find requirements that, although they are not exactly what you want, are suitable as the basis for some of the requirements you will write in the new project.
For example, in the IceBreaker project, the rules for road engineering do not change between products, so the requirements analysts do not have to rediscover them. They also know that the business of vehicle scheduling does not radically change every year, so their trawling process can take advantage of some requirements from previous projects. Similarly, on many projects within an organization, the nonfunctional requirements are fairly standard, so analysts can start with a specification from one of the previous projects and use it as a checklist.
The point about reusing requirements is that once a requirement has been successfully specified for a product, and the product itself is successful, the requirement does not have to be reinvented. In Chapter 13, we discuss how you can take advantage of the knowledge that already exists within your organization and how you can save yourself time by recycling requirements from previous projects.