How do I know which requirements should be retained for reuse?
We are wrapping up the project and reviewing the material we've created. How do I know which requirements materials should be retained for use on future projects?
It isn't easy to guess which of your requirements will be useful for future projects. Some people may want to retain them, while others won't care. The team supporting the solution after implementation will benefit from holding onto the requirements package and the technical design, as an aid for managing issues and changes along the way. But the business may not show much interest in retaining the requirements for future use. Still, it's good for everyone to be aware of the ways in which requirements documents can have value beyond the immediate project. Here are some tips for deciding what to keep.
Requirements template library: Keeping a repository of the final versions of all requirements documents can be a good way to build a library of templates that have worked for projects in your area. However, there's no need to retain earlier, non-final versions, especially if the change management process was documented.
Business needs: Suggest to the business that they hang on to any documents that show the business needs, goals, and requirements at the highest level.
Process models: The business may want to retain certain process models, especially of the new state of the processes affected by this project. Beyond their usefulness as examples of different flavors of process modeling, the next time this process needs changes, the as-is process will already be documented, saving the new project a great deal of time.
Alternatives and decisions: Retain decision documents that describe why an option was chosen, in case someone questions the decision later, needs to review it, or even wants to overturn it. Decision documents can also be a useful reference for projects that face similar decisions.
Business rules: Building a business rules repository is a great idea, because it's very likely that the business rules will be required again for projects that affect the same area.
Non-functional specifications: Non-functional specification documents often include features or constraints that apply across the organization regardless of the project, and can be pasted into new requirements documents with little or no editing required.
In general, examine all your requirements-related documentation for items that can be re-used in future projects' requirements documents or requirements analysis efforts, as well as material that could be useful to a future team for reference purposes. Even if an item is unlikely to be incorporated as-is into a future project's requirements, it may provide excellent guidance for their requirements work and save them time and costly oversights.