Requirements Management
Once the requirements have been agreed with the customer, it is essential to preserve their integrity. This is the subject of requirements management.
An agreed set of requirements needs to be baselined, i.e. frozen. A version number is associated with a baseline. Note that although baselined requirements may be extended and modified, a given baseline is never destroyed. Changes are in effect applied to a copy of the baseline and will eventually be baselined themselves, each baseline having a unique version number. This topic may be referred to as version control.
Note that changes to baselined documents cannot be allowed to happen in an uncontrolled manner. Typically a requested change will be reviewed by a panel often referred to as a change control board. The formality of such a board will very considerably between projects and organisations. The board should assess the impact and desirability of a requested change, considering for example whether the change is appropriate to the defined objectives, scope and business case of the project. This topic is referred to as change control and is intimately associated with version control.
At any time during and after a project, it must be possible to specifiy the status of a given requirement. A range of status values needs to be defined. An appropriate value will then be applied to a requirement at each stage of its development through to implementation.
Requirements seldom if ever exist in isolation. Functional requirements have associated quality requirements, two or more requirements may conflict or one may supercede another. Requirements should be traceable back to project objectives and forward to implemented products. These and other relationships between requirements need to be captured and maintained. These topics may be grouped under the heading requirements traceability.
Requirements management is generally facilitated by the use of purpose built requirements management tools. In large projects such tools may be considered to be indispensible. It is important to remember however, that prior to obtaining a tool, your requirements process(es) should be fully defined and implemented – a tool will not do your requirements work for you.