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