your estimation process. You have a history of who worked on what parts of the release. It forms a basis for moving from CMM/CMMI level 4 to level 5.
Some Requirements Management CM Guidelines
Here are a few of the Requirements Management guidelines I consider important from a Configuration Management perspective.
- Requirements need full version control, both by revision within a product development stream and branching into other product development streams.
- Requirements, perhaps even more that source code, need change control and traceability. Requirements should not be changed ad hoc and the reasons for the changes need to be documented.
- A related set of changed requirements due to a single request, for example, should be grouped together in a requirements change set, just as related files of a source code change should appear in a change package.
- Requirements are different than files so they should be treated differently. Normally, a requirement is expressed as a paragraph or a few paragraphs. There shouldn't be the overhead of having to manage a file and a workspace in order to change such a paragraph. So version and change control of these requirements should be possible without the need for a file to do the revisioning. Of course files should be permitted as well, especially as references, attachments, diagrams, etc. and these themselves may need to be under separate version and change control.
- Requirements don't need to be named in the same way that files are. It is far more convenient to give them titles and to let the CM/RM tool generate the unique id for the requirement.
- Requirement numbering should not be at the mercy of it's position in the requirements tree. It should be easy to identify a requirement through all revisions of the requirements document.
- Requirements need to be organized into a tree. It's fine to let the tree identify paragraph numbering, but this should be different from the identifier of the requirement, as the position will change over time.
- Requirements trees need version control just as directories do in the source code world. It is not sufficient to simply generate the Requirements Document and to revision control that. If you do, all of your questions such as "what's different between these two releases of the requirements document" become textual responses, as opposed to data responses which can be used to further extend your query and data navigation.
- Requirements trees need to be baselined, just like source code. However, release of a baseline to the development environment needs to be much more clearly controlled. Visibility is one thing, marching orders is another, especially if you're changing directions.
- You need to be able to trace from changes made to the source code back to the requirements that have been addressed. From a testing perspective, you want to trace test cases back to requirements, but you also want to trace test results back to requirements. This is why it's really critical, I feel, that your end-to-end data reside in a common repository, and ideally is accessible through a single tool.
I've not really tried to introduce a lot of new concepts here. Instead, I've tried to focus on making product development a "stream-based" process and on using the WBS for more than a simple project management tool. It's not necessarily an easy process to move to such an all-inclusive WBS capability, but it's a target to be reaching for if you want to improve your process maturity.