Workflow Detail: Manage
Changing Requirements
|
The purpose of this workflow detail is to assess the impact of requested changes to the requirements, and manage the downstream impact of the changes approved to be actioned |
|
|
|
Description
This workflow detail addresses:
- Evaluating requested changes and determining their impact on the existing requirement set.
- Structuring the use-case model.
- Setting up appropriate requirements attributes and traceability relationships.
- Verify that the results of the requirements work conform to the customer's view of the system.
Changes to requirements naturally impact downstream artifacts. For example the models produced in the course of analysis & design work, the tests developed to validate that the requirements have been met, and the end-user support materials. The Traceability relationships identified in the manage dependency activity of this discipline, identify the relationships between requirements and other artifacts. These relationships are the key to understanding the impact of requirements change.
Another important consideration is the tracking of requirement history. By capturing the nature and rationale of requirements changes, reviewers (in this case the role is played by anyone on the software project team whose work is affected by the change) receive the information needed to respond to the change properly.
Regular reviews, along with updates to the requirement attributes and dependencies, should be done whenever the requirements are updated.
Related Information
This section provides links to additional information related to this workflow detail.
- Whitepaper: Applying Requirements Management with Use Cases
- Whitepaper: Traceability Strategies for Managing Requirements with Use Cases
Timing
This work is normally addressed throughout each iteration.
Optionality
Should be performed in each iteration where the requirements will be further refined.
How to Staff
Involve the extended team (stakeholders: customer representatives, domain experts, and others). Be careful to manage your reviewing resources effectively-do not include the entire extended team unless you can ensure it adds value to the project.
The extended team should incorporate good knowledge of the problem domain, the technical difficulties of the project, as well as skills in requirements management and use-case modeling .
Work Guidelines
The core development team should conduct a few rounds of internal reviews: walk-throughs to clean up unnecessary inconsistencies before their work is more formally inspected and reviewed by the extended team.
You should divide the material up so that the team does not review everything at once. A review meeting shouldn't take more than a day. For example, you might conduct separate reviews of the user interface and the behavioral scenarios, or you might review all of the requirements artifacts related to a given subsystem.
See the Related Information section for additional guidance that will help you in performing this work.
