Example: Requirements Management Process Description
Illustrate an example of what a Requirements Management Process Description can do for an organization.
Relationships
Main Description

Revision History

Date

Version

Description

Author

Creation

1.0


Molly Brown













Table of Contents

1.1 Purpose
1.2 Scope
1.3 References
1.4 Overview

2. Requirements Management

2.1 Roles within the Organization which interact or influence system requirements

2.1.1 Customer
2.1.2 User
2.1.3 Stakeholder
2.1.4 Project manager
2.1.5 Tester
2.1.6 Developer
2.1.7 Administrator
2.1.8 Business Analyst

2.2 Tools, Environment, and Infrastructure

3. Requirements Artifacts

3.1 Requirements, Attributes and Documents
3.2 Attributes Values
3.3 Traceability and Hierarchy

3.3.1 Traceability Criteria for Requirement Types
3.3.2 Traceability Guidelines
3.3.3 Hierarchy Guidelines

4. RequisitePro Requirement Repository

4.1 RequisitePro Package Structure

5. Queries and Reports

5.1 View Descriptions

5.1.1 Attribute Views
5.1.2 Traceability Matrices
5.1.3 Traceability Trees

6. Requirements and Change Management Process Workflows

6.1 Workflow for Creation and Management of Requirements
6.2 Workflow for Requirements Change Management
Please refer to the Requirements Management Practice in RMC. This process is defined there.

Sample Requirements Management Process Description for XYZ

Introduction

1.1 Purpose

The purpose of this process description is to establish and document a systematic approach to eliciting, organizing, and documenting the requirements of IT systems developed at XYZ. his plan also establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

1.2 Scope

This process provides guidelines for the management of projects at XYZ for large projects. A large project is defined as a project with over 160 estimated development effort hours.

The document details how requirements are organized and administered within these projects. It also describes how requirements will be identified, assigned attributes, traced, and modified.

For small software projects (under 160 development-effort hours) a separate requirements management process.

1.3 References

Kruchten, Philippe. 1999. The Rational Unified Process. Menlo Park, CA: Addison Wesley

Leffingwell, D. and Don Widrig. 2000. Managing Software Requirements. Menlo Park, CA: Addison Wesley.

Spence, I. and L. Probasco. 1998. Traceability Strategies for Managing Requirements with Use Cases. Cupertino, CA: Rational Software Corporation.

Rational Unified Process®, Version 2003 Copyright © 1987 - 2003. Rational Software Corporation

1.4 Overview

This document contains specific details and strategies for managing the requirements of typical software development projects at XYZ . The document details how requirements are organized and administered within our project. It also describes how requirements will be identified, assigned attributes, traced, and modified.

2. Requirements Management

2.1 Roles within the Organization which interact or influence system requirements

2.1.1 Customer

A person or organization, internal or external to the producing organization, who takes financial responsibility for the system. In a large system this may not be the end user. The customer is the ultimate recipient of the developed product and its artifacts.

2.1.2 User

A person who will use the system that is developed.

2.1.3 Stakeholder

An individual or organization that is materially affected by the outcome of the system. Stakeholders usually include both the customer and users.

2.1.4 Project manager

The role with overall responsibility for the project. The Project Manager needs to ensure tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements.

2.1.5 Tester

The Tester is responsible for ensuring that the system meets the stated requirements, is defect free, and meets the performance, security, reliability and other system-wide requirements.

2.1.6 Developer

A person responsible for developing the required functionality in accordance with project-adopted standards and procedures. They will need read and some limited write access to the requirements of the system.

2.1.7 Administrator

The administrator is responsible for setting up the project structure in the Requirement Management system, for maintaining security and performing necessary backups. The administrator is also responsible for any tool configuration that may be necessary.

2.1.8 Business Analyst

The business analyst details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases and other supporting software requirements. The business analyst may also be responsible for a use-case package, and maintains the integrity of that package. It is recommended that the business analyst responsible for a use-case package is also responsible for its contained use cases and actors.

2.2 Tools, Environment, and Infrastructure

Tool Description License
Info
Technical Support Website
Rational
RequisitePro
Tool for managing
requirements
  support@rational.com www.rational.com
ClearQuest Tool for managing issues and changes to requirements integrates with RequisitePro   support@rational.com www.rational.com

3. Requirements Artifacts

3.1 Requirements, Attributes and Documents

Requirement Type

Description

Attributes

Where Documented

Stakeholder Need(STN)

High-level requests from key stakeholders

Stakeholder Priority, Origin, Deleted

Vision Document

Feature
(FEAT)

Conditions or capabilities of this release of the system

Priority, Status, Difficulty, Stability, Cost, Risk, Rank, Planned Iteration, Actual Iteration, SME, Request Type (Defect, New, Enhancement),  Deleted

Vision Document

Use Case
(UC)

Use case description - used for functional requirements

Priority, Status, Difficulty, Stability, Cost, Risk, Rank, SME, Assigned To, Planned Iteration, Actual Iteration, Deleted

Use Case Document

Data Glossary
(DG)

.Data Definitions

Origin, SME, Deleted

Data Glossary Document

System-Wide
(NF)

System requirements not readily captured by the use cases, usually do not represent functional requirements. They can further be classified into the following categories:

Events, Security, Reliability, availability, Performance, Capacity,Standards, Protocols, Environment, External Interface,Usability, Global Functionality

Priority, Status, Subtype, Difficulty, Stability, Cost, Risk, Rank, SME, Assigned To, Planned Iteration, Actual Iteration, Deleted

System-Wide Requirements Document

User Interface
(UI)

User Interface prototypes

Priority, Status, , Stability, SME, Assigned To, Planned Iteration, Actual Iteration, Deleted

User Interface Document

Business rule
(BR)

Requirements  such as constraints, formulas, calculations, etc

Priority, Status, Stability, SME, Assigned To, Origin, Planned Iteration, Actual Iteration, SME,  Deleted

Business Rule Document

Report
(RPT)

Report prototypes

Priority, Status, Stability, SME, Assigned To, Planned Iteration, Actual Iteration, Deleted

Report Description Document


3.2 Attributes Values

Attribute Description Data Type List Values Requirements Type
Priority Business priority List Critical
High
Medium
Low
STN, FEAT, UC, NF, UI, BR, RPT
Status Status of requirements in approval process List Proposed
Approved
Inspected
Implemented
Tested
STN, FEAT, UC, NF, UI, BR, RPT
Planned Iteration Iteration where this requirement is planned on being implemented Integer N/A FEAT, UC, NF, UI, BR, RPT
Actual Iteration Iteration where this requirement is actually implemented. Integer N/A FEAT, UC, NF, UI, BR, RPT
Difficulty Estimated technical difficulty for implementation. List High
Medium
Low
FEAT, UC, NF
Stability Likelihood of this requirements to change.
(High likelihood means low stability)
List High
Medium
Low
FEAT, UC, NF, UI, BR, RPT
Cost Estimated cost of implementing this requirement. Real N/A FEAT, UC, NF
Origin Where this requirement
originated from
(group, user, dept, customer, etc)
Text N/A STN, DG, BR
SME Subject Matter expert for this requirement. Text N/A FEAT, UC, DG, NF, UI,
BR, RPT
Risk Is there any technical/architectural risk involved in implementing this requirement. List High
Medium
Low
FEAT, UC, NF
Request Type Is this a new feature, an enhancement to an existing one or one resulting from defect discovery. List Defect
New
Enhancement
FEAT
Assigned To Analyst responsible for detailing out the requirements Text N/A FEAT, UC, NF, UI, BR, RPT
Rank The order in which this requirement ranks based upon other attributes. This will determine the order in which it is implemented Integer Recommended 1..10
1- High
10 - Low
FEAT, UC, NF
Deleted Logical delete field. Indicates that this requirement is no longer part of the scope List Yes
No
STN, FEAT, UC, DG, NF, UI, BR, RPT
Subtype Category of system-wide
requirement
List

Events,
Security,
Reliability,
Availability,
Performance,
Capacity,
Standards,
Protocols,
Environment,
External Interface,
Usability,
Global Functionality

NF

3.3 Traceability and Hierarchy

3.3.1 Traceability Criteria for Requirement Types

Setting up a trace between two requirement indicates a dependency, (in this case due to a higher-level requirement evolving into a more-detailed one) This will cause a suspect link if one requirement changes, indicating that the other might have been impacted.  The list below depicts the recommended traceability.  Each requirement type "traces to" those indented directly below it.

Stakeholder Need (STN)
      Feature (FEAT)
            Non-functional (NF)
            Use Case (UC)
                 User Interface (UI)
                 Business Rule (BR)
                 Report (RPT)
                 Data Glossary (DG)

3.3.2 Traceability Guidelines


Requirement Type

Guidelines

Stakeholder Need (STN)

Every STN requirement must trace to one or more FEAT requirements.

Feature (FEAT)

Every FEAT requirement with an "Approved" status must have a trace to one or more UC requirement or to one or more NF (system-wide)  requirements and must be able to be traced from at least one  STN.

Use Case (UC)

Every UC requirement must be able to be traced from one or more FEAT and may be traced to a BR,UI, RPT or DG requirement, if applicable

System Wide (NF)

A NF requirement must be able to be traced from one or more FEAT requirements (some exceptions may apply)

Business Rule (BR)

A BR requirement must be able to be traced from one or more UC requirements

User Interface (UI)

A UI requirement must be able to be traced from one or more UC requirements

Report (RPT)

A UI requirement must be able to be traced from one or more UC requirements

Data Glossary (DG)

A DG requirement must be able to be traced from one or more UC requirements

3.3.3 Hierarchy Guidelines

All requirement types can support hierarchy, the concept of a parent/child relationship.

This should be used for organizational purposes, when the parent is used to group together several related, more detailed requirements of the same type.

The following hierarchical structure is recommended for capturing use case requirements and their flows of events.

 Use Case Name
      Main Flow
      Alternate Flow1
      Alternate Flow2
      ...
      Alternate FlowN 

4. RequisitePro Requirement Repository

4.1 RequisitePro Package Structure

There is a basic package structure for managing the XYZ requirements in a RequisitePro project. It is part of the structure of the standard RequisitePro template to be used for all XYZ requirement management projects. There are two main packages: the Docs package for containing all the documents and the Views package for containing database views.
The Docs package contains nested packages, one for each document type, as defined in section 3.1.

The Views package contains three nested packages, for the three different view types, Attribute Views. Traceability Matrices and Traceability Trees.

In each one of these packages, another layer of nested packages can be created as needed to represent functional groupings.

All requirements should be document-based, and they will live in the same package as their owning document.

5. Queries and Reports

5.1 View Descriptions

The following tables depict the views (queries) that are part of the structure of the standard RequisitePro template for XYZ. Additional views can be created as required by the users.

5.1.1 Attribute Views

View Name Description Requirement Type Filter
All Data Glossary Terms List of all data glossary terms DG  
All Business Rules List of all business rules BR  
All Features List of all features FEAT  
All System Wide Requirements List of all system-wide requirements, grouped by subtype. NF  
All Report Requirements List of all report requirements RPT  
All Stakeholder Needs List of all stakeholder needs STN  
All Use Cases List of all use cases UC  
All User Interface Requirements List of all UI requirements UI  
Features Not Traced from Stakeholder needs. List of all Features that do not evolve from stakeholder needs. FEAT Not traced from STN
Unfulfilled Features

List of features which do not trace into use cases or system-wide requirements.

FEAT Not traced to (UC, NF)
Unfulfilled Stakeholder Needs List of all Stakeholder Needs which evolve into features. STN Not traced to FEAT
Orphaned Use Cases List if Use Cases which do not evolve from a feature. UC Not traced from FEAT

Orphaned Non Functional Requirements.

List of system-wide requirements which do nor evolve from a feature. NF Not traced from FEAT
Orphaned Business Rules List of Business Rules which are not associated with a use case. BR Not traced from UC
Orphaned Data Glossary Terms List of Data Glossary terms which are not associated with a use case. DG Not traced from UC
Orphaned User Interface Requirements. List of UI requirements which are not associated with a use case. UI Not traced from UC
Orphaned Reports List of all Report requirements which are not associated with a use case. RPT Not traced from UC


5.1.2 Traceability Matrices


View Name Description Requirement Type
Features Traced to System-wide
Requirements
A matrix of features and system-wide requirements with arrows depicting the traces between them. FEAT, NF
Features Traced to Use Cases A matrix of features and use cases requirements with arrows depicting the traces between them. FEAT, UC
Stakeholder Needs to Features A matrix of stakeholder needs and features with arrows depicting the traces between them. STN, FEAT
Use Cases to Business Rules A matrix of uses cases and business rules with arrows depicting the traces between them. UC, BR
Use Cases to Data Glossary Terms

A matrix of uses cases and data glossary terms rules with arrows depicting the traces between them.

UC, DG
Use Cases to Report Requirements A matrix of uses cases and report requirements  with arrows depicting the traces between them. UC, RPT
Use Cases to User Interface Requirements. A matrix of uses cases and UI requirements with arrows depicting the traces between them. UC, UI

5.1.3 Traceability Trees

View Name Description Requirement Type Filter
Requirements Traced from Features. Traceability tree derived from all features. FEAT  
Requirements Traced from Stakeholder Needs. Traceability tree derived from all Stakeholder Needs. STN  
Requirements Traced from Use Cases. Traceability tree derived from all use cases. UC  
Requirements Traced into Business Rules. Traceability tree depicting requirements business rules trace from. BR  
Requirements Traced into Data Glossary. Traceability tree depicting requirements data glossary terms link into. DG  
Requirements Traced into Report Requirements. Traceability tree depicting requirements reports trace from. RPT  
Requirements Traced into User Interface Requirements Traceability tree depicting requirements user interface requirements trace from. UI  


6. Requirements and Change Management Process Workflows

6.1 Workflow for Creation and Management of Requirements

Please refer to the Requirements Management Practice in RMC. This process is defined there.

6.2 Workflow for Requirements Change Management

Please refer to the Requirements Management Practice in RMC. This process is defined there.