Activity: Manage Dependencies

Purpose Understanding attributes of the requirements help in managing the scope of the project and the application.
Steps Choose Requirements Attributes Using Requirements Attributes Establish Traceability
Input Artifacts: Requirements Attributes Guidelines Use-Case Model Supplementary Specifications Design Model Test Model Risk List	Resulting Artifacts: Requirements Attributes Requirements Attributes Guidelines Vision
Worker: System Analyst
Tool Mentors: Using RequisitePro to Manage Dependencies

Choose Requirements Attributes

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 elements 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 needs and requirements as captured in the Stakeholder Needs document.
Use cases, scenarios, and steps of use cases.
Requirements as captured in the Supplementary Requirements document.
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 Attributes Guidelines.

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 Requisite 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 Needs document	A feature in the Vision document
An item in the Stakeholder Needs document	A use case
An item in the Stakeholder Needs document	A section or sections in the Flow of events of a use case
An item in the Stakeholder Needs document	A section in the Special Requirements of a use case
An item in the Stakeholder Needs document	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.