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. |
Description
This activity addresses:
-
Evaluating requested changes and determining their impact on the existing software requirements.
-
Structuring the use-case model to improve the overall management of the requirements documented in the use
case.
-
Managing changes to the requirements attributes and traceability relationships.
-
Once the changes have been implemented, verifying that the results of the requirements work conform to the
customer's view of the system.
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 Organize Requirements explicitly define the relationships between the
requirements and the other work products. These relationships are the key to understanding the impact of requirements
change.
|
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 Case 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.
|
Work Breakdown
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1987, 2012. All Rights Reserved.
|
|