Our configuration management is borne out of our requirements.  In our earlier blog post, we discussed how the project scope must be traceable to the requirements. In the case we present below, the project scope is a particular function or need to be met, for example a new feature or function for an automobile.  We want to integrate this new feature into our existing architecture.   To show how all of these are linked we show a snippet from an excel table (which could be how we trace our requirements).   

The top level scope is the left most column. We subsequently breakdown the product scope (our WBS will help us disaggregate) into systems requirements, and ultimately the individual component or subsystem requirements. In the case below we see that for Product Requirement 1.1 we have two systems requirements, and three component requirements.

This is a very crude table to illustrate the concept.  From here we can define our iterative and incremental deliveries based upon our priorities. This will result in defining the number of releases we must produce to achieve the project objectives.  We know what each package will contain and we are able to efficiently test the iterative and incremental packages that are produced.  This traceability makes it possible for the test cases to trace to the scope and detailed assessment of the impact of a test failure.  By showing the links to the scope, specifically from project scope, to systems level and supporting component level requirements, we are prepared to efficiently develop the product. We also have a “checklist” for our project closure activities.