Activity: Manage Changing Requirements








var defaultQueryStr = '?proc=_MiAAUSJaEdqQipbmJ0SDbw&path=_MiAAUSJaEdqQipbmJ0SDbw,_kcnw8CJbEdqQipbmJ0SDbw';
var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=null;
contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);










Activity: Manage Changing Requirements















This activity manages changes to requirements and assesses their overall impact.


Extends: Manage Changing Requirements








DescriptionWork Breakdown StructureTeam AllocationWork Product Usage








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



Parent Activities


Ongoing Management and Support






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  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.







contentPage.onload();