Example: Requirements Management Process Description
Illustrate an example of what a Requirements Management Process Description can do for an organization.
Relationships
Description
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 administrated 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 administrated 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, Avalalibility, 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 hierarchal 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, for example,
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 uers.

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

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