Guidelines: Requirements Management Plan

The Requirements Management Plan contains information which may be covered to a greater or lesser extent by other plans.

Organization, Responsibility, and Interfaces

Requirements errors are also likely to be the most common class of error, and are the most expensive to fix.

Having the right relationships with stakeholders can help with these problems. The stakeholders are a key source of input for defining requirements and understanding priorities of requirements. Many stakeholders, however, lack the insight into the cost and schedule impacts of requested features, and therefore the development organization must manage stakeholders expectations.

Identifying Traceability Items

Specifying Traceability

In addition to identifying the traceability links, you should specify the cardinality of the links. Some common constraints are:

Sample Attributes

Stakeholder Need

Features, Supplementary Requirements, and Use Cases

Use Case

In addition to the above, it is also useful to track the following use case attribute:

Test Case

General Attributes

Selecting Attributes

Attributes are used to track information associated with a traceability item, typically for status and reporting purposes. Each organization may require specific tracking information unique to their organization. Before assigning an attribute, you should consider:

The essential attributes to track are Risk, Benefit, Effort, Stability and Architectural Impact, in order to permit prioritizing requirements for scope management and to assign requirements to iterations. These should be tracked initially on Features, and later on all Use Cases and Supplemental Requirements.

Consider Derived Information

In addition to directly using requirements attributes, you may wish to derive information from these requirements attributes via traceability to other requirements types. Some typical patterns of derivation are:

Thus, in order to assign requirements attributes to requirements types, you should consider:

Dependency of Attributes

Some attributes may only be applicable to a certain level of development. For example, an estimated effort attribute for a use case may be replaced by effort estimates on the design elements once the use case is fully represented in the design.

Reports and Measures

The following are examples of requirement-related reports and measures. By selecting the required/desired set of reports and measures for your project, you can derive the necessary attributes for the Requirements Management Plan.

Report/Measure Description	Used For
Development Priority of Use Cases (list of Use Cases sorted by Risk, Benefit, Effort, Stability, and Architectural Impact).	This may be separately sorted lists, or a single list sorted by a weighted combination of these attributes. Used for Activity: Prioritize Use Cases.
Percent of Features in each Status Category.	Tracks progress during definition of the project baseline.
- classified by Target Release	- tracks progress on a per release basis
- weighted by Effort	- provides a more precise measure of progress.
Features sorted by Risk	- identifies risky features. Useful for scope management and assigning features to iterations.
- classified by Target Release, with Development Risk summed for each Target Release	- useful for assessing whether risky features have been scheduled early or late in the project.
Use Case Sections sorted by Stability	- used for deciding which use case sections need to be stabilized.
- weighted or sorted by Affects Architecture	- useful for prioritizing architecturally significant and/or high effort use cases to be stabilized first.
Requirements with Undefined Attributes	When requirements are first proposed, you may not immediately assign all the attributes (e.g. by using a default "Undefined" value). The Checkpoints: Software Requirements Specification uses this report to check for such undefined attributes.
Traceability Items with incomplete traceability links	A report of incorrect or incomplete traceability links is used for the Checkpoints: Software Requirements Specification.

Requirements Change Management

Baseline the Requirements

Toward the end of the elaboration phase, the System Analyst should baseline all known requirements. This typically is performed by ensuring there is version control on the requirements artifacts, and identifying the set of artifacts and their versions that form the baseline.

The purpose of the baseline is not to freeze the requirements. Rather it is to enable new and modified requirements to be identified, communicated, estimated, and controlled.

Establish a Single Channel to Control Change

A stakeholder's wish for a change cannot be assumed to officially change the budget and schedule. Typically a negotiation or budget reconciliation process must be initiated before a change can be approved. Often changes must be balanced against one another.

It is crucial that every change go through a single channel, the Change Control Board (CCB), to determine its impact on the system and to undergo official approval. The mechanism for proposing a change is to submit a Change Request, which is reviewed by the CCB.

Maintain a Change History

It is beneficial to maintain an audit trail of changes to individual requirements. This change history allows you to view all prior changes to the requirement as well as changes to attribute values, and the rationale for the change. This can be useful in assessing actual stability of requirements, and identifying cases where the change control process may not be working (e.g. identifying requirements changes that were not properly reviewed and approved).