Requirements Management
There are a number of objectives to Requirements Management. These include:
- Managing the scope of the project (or iteration)
- Managing changes to requirements
- Managing risk
- Validating requirements
I begin with a brief overview of how I do Requirements Management, and then explain how the approach meets the above objectives.
The first step is to define a heirarchy of requirement types, which become progressively more detailed. This allows you to start with broad-brush requirements initially, and progressively get more detailed. I like the simple heirarchy defined in RUP:
- Stakeholder Needs - Define the problems which the project must solve from the stakeholder's perspective. In an enterprise context, I call replace these with business needs. These are requirements in the problem space.
- Features - Broadly describe the features the software must have to fulfill the business or stakeholder needs. The level of detail here is much as you would expect to find in a detailed features list included in the marketing material for a software product. These are high-level requirements in the solution space.
- Use-cases - The names of the use cases as described in my Requirements Analysis page.
- Use-case Requirements - Each use case will contain a number of discrete requirements describing one step the software performs in the use case.
- Supplementary Requirements - Those detailed requirements that are common to multiple use-cases.
Use cases are really a vehicle for grouping a set of (use-case) requirements, and presenting them from the perspective of the actor(s). As such, we often do not give them the same emphasis as the other requirement types, but rather focus directly on their constituent use-case requirements. We refer to supplementary requirements and use-case requirements collectively as "detailed requirements".
It is important to record how the various detailed requirements relate to the higher-level requirements. We call this traceability. In general, each feature traces to (supports or fulfills) one or more business or stakeholder needs. If a feature is not fulfilling a need, then why are we building it? Similarly, detailed requirements are traced to one or more features.
For each requirement, we record a number of properties or attributes, which describe the relative importance, priority, and estimated effort for the requirement, its impact on the architecture, and it status.
Managing Scope
Managing the scope of a project involves balancing the business value of the delivered functionality against the project's resource constraints (time, cost, people). This is particularly effective when using Iterative Development, where business value is delivered iteratively, and each iteration has particular objectives. Each project will tailor the attributes used to manage the requirements to reflect the criteria that they wish to use to manage the scope of the iterations or the project. Generally, these will be centered on relative importance, value, related risk, and architectural impact. These attributes can then be used to assign individual requirements to particular iterations where they will be implemented, in accordance with the iteration objectives.
Managing Change
It is important for the project team to develop policies governing the change management process for requirements. During the early stages of a project, frequent change to requirements is expected and generally allowed to proceed with little restriction. However, once a requirement has been implemented, any change needs to be carefully considered and approved via some appropriate process. It is useful to have a requirements attribute called "Stability" which describes the degree of certainty that the requirement will not undergo any significant change for the remainder of the project. Examples of useful policies which are given below. Each project team is different, and these policies may need modification or not be applicable at all to your project.
- No requirement shall be implemented until its stability is high, unless done so in order to mitigate a significant risk (particularly a requirements risk).
- Once a requirement's stability is marked as high, any subsequent changes must be approved by [appropriate person(s)]. This may be used in isolation, or in conjunction with baselining (see below).
- Any change to requirements should start with high-level requirements (needs) and then be cascaded down to the detailed requirements.
The traceability we have recorded allows us to gauge the impact of changes. It allows us to determine those needs that may be impacted by a change to a detailed requirement, or to determine which detailed requirements may be impacted by a change to a need or feature.
It is useful to identify a set of requirements that have all been detailed and are roughly consistent with each other and give the current version of each requirement a label called a baseline label. The collection of those specific versions of those requirements is called a baseline. Having done this, the design and implementation teams can work off the baselined versions of the requirements, whilst any changes are made to another set of the same requirements which is not currently visible to the design and implementation teams. This allows the changes to be introduced to the design and implementation teams at defined points in the project, and allows them to get on and work on the current baselined requirements without worring about changes. It can be useful to only include requirements whose stability is high in the baseline. Once a new baseline is created, the changes from the previous baseline can be identified and listed.
Managing Risk
Many risks have mitigation strategies that are based on building something. This ties in to my requirements management approaches in the following way:
- Identify the requirement(s) that will mitigate the risk when implemented.
- Assign the requirements to the the iteration whose objectives include the mitigation of that risk.
Each and every requirement has some level of requirements risk associated with it. It is impractical to list every one on the risk list. Hence, the detailed management of requirements risks is undertaken using the requirements management attibutes, particularly the "Stability" attribute.
Validating Requirements
The best way to validate requirements is to build an executable product and give it to a group of stakeholders to use and review. If this first time this is done is with the finished product, then you can be certain that lot of rework will be required. This is a risk mitigation problem. The challenge is to build a small subset of the product early, and get detailed feedback on that subset. This is done by identifying those requirements which will best mitigate the overall requirements risk, and then assign them to early iterations.
Another tool to help validate requirements is traceability. The requirement to trace all detailed requirements to features and all features to needs helps us ensure that the detailed requirements are consistent with the overall business objectives, and that there are no frivolous requirements.
Requirements Management as described here is quite difficult without support from a special-purpose requirements management tool. See Additional Resources below for such tools.
Additional Resources
Online
- Kean, L 1998, 'Requirements Tracing--An Overview', Carnegie Mellon Software Engineering Institute.
- Leafingwell, D. 2002, 'Agile Requirements Methods', The Rational Edge, July 2002
- Leafingwell, D. & Widrig, D. 2002, 'The Role of Requirements Traceability in System Development', The Rational Edge, September 2002
- Tattersall, G. 2002, 'Supporting Iterative Development Through Requirements Management', The Rational Edge, October 2002
Other
- Leafingwell, D. & Widrig, D. 2000, Managing Software Requirements - A Unified Approach, Addison-Wesley.
