| Activity: Manage Changing Requirements |
|
 |
| This activity manages changes to requirements and assesses their overall impact. |
|
Purpose
| The purpose of this activity is to assess the impact of requested changes to the requirements, and manage the downstream
impact of the changes approved to be actioned. |
Relationships
Description
|
This activity addresses:
Changes to requirements naturally impact downstream artifacts (e.g., analysis and design work products, test work
products, deployment artifacts, etc.) The  Traceability
relationships identified and documented during Manage Dependencies explicitly define the relationships between the requirements and the other work products. These
relationships are the key to understanding the impact of requirements change.
|
Properties
| Event Driven |  |
| Multiple Occurrences |  |
| Ongoing | |
| Optional | |
| Planned | |
| Repeatable | |
Staffing
|
Involve the extended team (stakeholders: customer representatives, domain experts, and others).
Include as a Technical Reviewer anyone on the software project team whose
work is affected by the change). 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.
|
Usage
| Usage Guidance |
This activity should be performed in whenever requirements are refined.
Regular reviews, along with updates to the requirement attributes and dependencies, should be done whenever the
requirements are updated.
It is recommended that you arrange one review of the Use-Case Model per iteration in the Inception and Elaboration phases, where you review the work in progress; this is
initially done and signed off by the users prior to developing any of the Use Cases
in detail, and is a very important milestone so that resources are not spent on developing incorrect use cases. Then,
at the end of the Elaboration phase, you should arrange a detailed review of the use-case model. Remember that at the
end of the Elaboration phase, you should have a use-case model, and possibly a domain model representing the Glossary, that is 80% complete. You should also arrange one review of
the use-case model per iteration in the Construction and Transition phases when the use-case model is refined. The
review should concentrate on the part of the use case model being developed for the iteration.
|
Key Considerations
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.
Another important consideration is the tracking of requirement history. By capturing the nature and rationale of
requirements changes, reviewers receive the information needed to respond to the change
properly.
|
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
|
