Activity: Manage Dependencies
| Input Artifacts: - Change Request - Design Model - Requirements Attributes - Requirements Management Plan - Risk List - Stakeholder Requests - Supplementary Specifications - Use-Case Model - Vision | Resulting Artifacts: - Requirements Attributes - Requirements Management Plan - Vision |
Assign Attributes
The Requirements Management Plan defines the attributes to be tracked for each type of requirement. The most important attributes are Benefit (from the stakeholders’ perspectives), the Effort to implement, the Risk to the development effort, the Stability (likelihood to remain unchanged), and Architectural Impact (is it architecturally significant) of each requirement.
The Benefit and Stability are set by the System Analyst, in consultation with the stakeholders. Effort and Risk are set by the Project Manager, in consultation with the Software Architect. Architectural Impact is set by the Software Architect.
Unstable requirements with high risk, high effort, or high benefit should be flagged for more analysis. Low benefit requirements with high effort, risk, or instability should be flagged for potential removal.
Below is an example of a set of features of the RequisitePro tool as found in the Vision document, together with requirements attributes for each feature. Benefit refers to customer opinion, and effort is input from the developers.
| Features | Benefit | Effort | Risk | Architecture Impact | Stability |
|---|---|---|---|---|---|
| FEATURE1: Save and restore sort and filter criteria | Med High | Low | Low | Low | High |
| FEATURE2: Ability to save a RequisitePro document as a Microsoft® Word® document. | Med High | Low | Low | Low | High |
| FEATURE3: Ability to see deleted requirements in a view window. | Medium | Med High | Medium | Low | Medium |
| FEATURE4: Support for Currency datatype attributes. | Medium | Medium | Med Low | Low | Medium |
| FEATURE5: Support the “All” document type (provides an easy way to define common attributes across multiple document types). | Med High | Medium | Medium | Low | Med High |
| FEATURE6: Ability to select requirement in a view and GoTo in Word document. | Med High | Medium | Medium | Low | Med High |
| FEATURE7: Display a requirement’s attribute in the text of the requirement’s document. | Medium | Medium | Medium | Low | Med High |
| FEATURE8: New project wizard | Med High | High | Med High | High | Medium |
| FEATURE9: Fast creation of a requirement (avoid the requirement dialog on creation). | Med High | Med Low | Med Low | Low | High |
| FEATURE10: AutoSave of a project (project archive). | Medium | Med Low | Medium | Low | Medium |
| FEATURE11: Change one or more attributes for a selected set of requirements. | Medium | Med High | Medium | Low | Medium |
| FEATURE12: Ability to clone a project’s structure to allow users to easily create new projects from old projects. | High | Medium | Medium | Low | Low |
| FEATURE13: Performance enhancements for printing, requirement identification. | Med Low | Med High | Medium | Low | Med High |
| FEATURE14: Microsoft® Windows95® Port. | High | Medium | High | High | High |
Say that based on what you know about resources, you have determined that only two-thirds of these features can be included in a first iteration. You need to stabilize the architecture, so features 8 and 14 must be implemented early. However, feature 8 has only Medium stability - so you need to work with the stakeholders to reduce this to Low as soon as possible.
Feature 13 is only Med Low benefit, but has Med High effort, so this may be flagged for potential removal.
You also know that it is critical that you can deliver something at your deadline, so you want to avoid high effort features, especially if combined with instability. Thus you may decide to exclude features 3, 11, and 12.
Establish and Verify Traceability
The Requirements Management Plan defines how requirements types are traced to other artifacts. The System Analyst must establish the required traceability, and periodically use traceability reports to ensure that traceability is maintained in accordance with the Requirements Management Plan.
Manage Changing Requirements
Requirements changes are managed in accordance with the Requirements Management Plan. Some additional guidelines are as follows:
Re-assess Requirements Attributes and Traceability
Even if a requirement hasn’t changed, the attributes and traceability associated with a requirement can change. The System Analyst is responsible for maintaining this information on an ongoing basis.
Manage Change Hierarchically
A change to one requirement may have a “ripple” effect that affects other related requirements, design, or other artifacts. To manage this effect, you should change the requirements from the top down. Review the impact on the Vision, then the Use Case Model, Design Model, and End-User Support Material. To manage the impact of requirements change on the test effort, review the related information in Activity: Define Traceability and Assessment Needs. Traceability reports are useful in determining the potentially affected elements.