Activity: Manage Dependencies

Purpose To manage attributes and traceability of project requirements to assist in managing the scope of the project and manage changing requirements.
Steps Choose Requirements Attributes Using Requirements Attributes Establish Traceability
Input Artifacts: Requirements Management Plan Requirements Attributes Vision Change Requests Use-Case Model Supplementary Specifications Design Model Test Model Risk List Stakeholder Requests	Resulting Artifacts: Requirements Attributes, updated Requirements Management Plan, updated Vision, updated
Worker: System Analyst
Tool Mentors: Managing Dependencies Using Rational RequisitePro

Workflow Details:

Core Workflow: Requirements

Understand Stakeholder Needs

Define the System

Manage the Scope of the System

Manage Changing Requirements

Choose Requirements Attributes

Choosing the appropriate attributes and traceability for your project requirements will assist you to:

Assess the project impact of a change in a requirement
Assess the impact of a failure of a test on requirements (i.e. if test fails the requirement may not be satisfied)
Manage the scope of the project
Verify that all requirements of the system are fulfilled by the implementation.
Verify that the application does only what it was intended to do.
Manage change.

Requirements and other related elements of the models can be given attributes to help keep track of their general status. Each project may come up with their specific set of attributes, and attributes may differ depending on the type of element you are tracking. Following is a suggested standard list of attributes.

Name of attribute	Explanation
Rationale	Reason for the requirement
Development Priority	Order/priority of development
Status	Proposed, approved, incorporated, validated, rejected
Risk	Probability of adverse project impact (schedule, budget, technical)
Safety/Criticality	Ability to affect user health, welfare, or economic consequence of failure
Responsible Party	Who is responsible for the requirement
Origin	Source of the requirement
Stability	Probability whether the requirement will change

What kind of types of requirements would you then want to give these type of attributes? We suggest the following:

Features of the system as listed in the Vision document.
User requests and requirements as captured in the Stakeholder Requests.
Use cases, scenarios, and steps of use cases.
Requirements as captured in the Supplementary Specifications.
Test cases.

The goal of having these attributes is to have something that helps you in:

assigning resources,
assessing status,
calculating software metrics,
managing project risk,
estimating costs,
assuring user safety, and
managing project scope.

Document your list of requirements attributes in Artifact: Requirements Management Plan.

Using Requirements Attributes

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. We have used a 1-5 grading scale, to show the value of each attribute (1 means low, 5 means high). Priority refers to customer opinion, and difficulty is input from the developers.

Features	Priority	Difficulty	Risk	Stability
FEATURE1: Save and restore sort and filter criteria	Med High	Low	Low	High
FEATURE2: Ability to save a RequisitePro document as a Microsoft^« Word^«document.	Med High	Low	Low	High
FEATURE3: Ability to see deleted requirements in a view window.	Medium	Med High	Medium	Medium
FEATURE4: Support for Currency datatype attributes.	Medium	Medium	Med Low	Medium
FEATURE5: Support the "All" document type (provides an easy way to define common attributes across multiple document types).	Med High	Medium	Medium	Med High
FEATURE6: Ability to select requirement in a view and GoTo in Word document.	Med High	Medium	Medium	Med High
FEATURE7: Display a requirementÆs attribute in the text of the requirementÆs document.	Medium	Medium	Medium	Med High
FEATURE8: New project wizard	Med High	High	Med High	Medium
FEATURE9: Fast creation of a requirement (avoid the requirement dialog on creation).	Med High	Med Low	Med Low	High
FEATURE10: AutoSave of a project (project archive).	Medium	Med Low	Medium	Medium
FEATURE11: Change one or more attributes for a selected set of requirements.	Medium	Med High	Medium	Medium
FEATURE12: Ability to clone a projectÆs structure to allow users to easily create new projects from old projects.	High	Medium	Medium	Low
FEATURE13: Performance enhancements for printing, requirement identification.	High	Med High	Medium	Med High
FEATURE14: Microsoft^« Windows95^« Port.	High	Medium	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 also know that it is critical that you can deliver something at your deadline, so you want to avoid unnecessary technical risk and difficulty, especially if combined with instability. This would exclude features 3, 8, 11, and 12. We do not exclude feature 14, even though the risk is high. This is a feature with both the highest priority and highest stability, so it appears it has to be done. In such a case, it is probably wise to try mitigate the risks of this feature as early as possible.

Establish Traceability

Establish traceability links between elements in models and requirements. Consider the following connections:

An item in the Stakeholder Requests	A feature in the Vision document
An item in the Stakeholder Requests	A use case
An item in the Stakeholder Requests	A section or sections in the Flow of events of a use case
An item in the Stakeholder Requests	A section in the Special Requirements of a use case
An item in the Stakeholder Requests	An item in the Supplementary Specifications
A feature in the Vision document	A use case
A feature in the Vision document	A section or sections in the Flow of events of a use case
A feature in the Vision document	A section in the Special Requirements of a use case
A feature in the Vision document	An item in the Supplementary Specifications
A feature in the Vision document	An element in the design model
A section in the Flow of events of a use case	An element in the design model
An item in the Special Requirements of a use case	An element in the design model
An item in the Supplementary Specifications	An element in the design model
A section in the Flow of events of a use case	An element in the test model
An item in the Special Requirements of a use case	An element in the test model
An item in the Supplementary Specifications	An element in the test model

For more information on traceability, see Concepts: Traceability.

The result is documented in a set of requirements traceability matrices, which are part of the Requirements Attributes artifact.