Example: Requirements Management Process Description |
Illustrate an example of what a Requirements Management Process Description can do for an organization.
Relationships
Related Elements | Plan Requirements Management Strategy Requirements Requirements Management Process Description Requirements Management Process Description
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.
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.