The selection of configuration items is the most important decision in configuration management. It is usually recommended by the software process group (those that define the configuration management process for the organization) and tailored by each project by the project manager.

To restate, a configuration item (CI) is a stand-alone, test-alone, use-alone element. So, with all the formats requirements take, what should be managed? What happens when a format contains requirements within requirements?

In configuration management terms, the individual requirements must be managed as well as their association with other requirements. So, this creates a baseline within a baseline. The higher (requirement relationship) configuration item can only be baselines, when all other individual requirements are in the same state.

So, if we look at a car engine ... The engine is a CI along with all the parts that make op the engine and the relationship each part has with other parts as well as with the engine. Then, of course, each configuration state the engine is in creates additional baselines.

The simplest way to manage a requirement set is by each specification. However, if you change a small piece of the requirement specification, a product of a product, you will be re-approving the entire requirement specification on a rapid and increasing rate. If you manage the smallest product you will have a lot of configuration items for the smallest piece as well as its relationship to other products (the engine parts are managed as well as the relationship to its function it performs in the engine).

Managing requirements will occur in multiple tools: Requirement Specification Tools, Requirement Management Tools and Configuration Management Tools. It is important to have someone skilled in configuration management assist in setting up the process to manage the requirements.

Future Tips will discuss the different Requirement related roles and the needed skill set.
Pat Ferdinandi