Requirements Management Plan

<Company Name> <Project Name> Requirements Management Plan
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process and the RequisitePro Use Case Project Template. It contains certain framework and content provided by Rational Software to help you develop your Requirements Management Plan.] [Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. Text typed below blue, bracketed text will automatically be set to normal (style=Body Text).] [To customize automatic fields in Microsoft Word (which display a gray background when selected), select File > Properties and replace the Title, Subject, and Company fields with the appropriate information for this document. After you close the dialog, automatic fields may be updated throughout the document by selecting Edit > Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Press Alt-F9 to toggle between the field names and the field contents. See Word help for more information on working with fields.] [This template is partially populated with content adapted from the Rational Unified Process, intended to speed your development of a Requirements Management Plan in accordance with the best practices for requirements management. In some areas the template supplies content that applies to any requirements management project using the Rational Unified Process. In other areas the template leaves the content to you. You should change, add, or otherwise customize the content of this document as needed. If you do not want to use this content, you may remove this document and create a new, empty Requirements Management Plan.]
<Project Name> Requirements Management Plan <document identifier>
Version: <1.0> Date: <dd/mmm/yy>
Revision History
Date <dd/mmm/yy> Version <x.x> <details> Description <name> Author
Confidential
<Company Name>, 2012
Page 2 of 20
Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 2. Requirements Management 2.1 Organization, Responsibilities, and Interfaces 2.1.1 Customer 2.1.2 User 2.1.3 Stakeholder 2.1.4 Project manager 2.1.5 Quality assurance (QA) 2.1.6 Developer 2.1.7 Team leader 2.1.8 Configuration manager 2.1.9 Requirements specifier 2.2 Contact Table 2.3 Tools, Environment, and Infrastructure 3. Requirements Artifacts 3.1 Artifact Description 3.1.1 Document Types 3.1.2 Requirement Types 3.1.3 Attributes 3.1.4 List Values 3.2 Traceability 3.2.1 Traceability Criteria for Requirement Types 3.3 Reports and Measures 4. Requirements Change Management 4.1 Change Request Processing and Approval 4.1.1 A Change Request, Enhancement Request, or Defect is proposed by a stakeholder. 4.1.2 The CCB reviews impact on artifacts, costs, and schedule. 4.1.3 Responsibility for implementing changes is assigned to appropriate workers. 4.1.4 Changes are incorporated into a build and tested. 4.1.5 The change requests are validated and closed. 4.1.6 Change Control Board (CCB) 4.1.7 Change Control Manager [name, title, organization, contact information] 4.1.8 Project Manager [name, title, organization, contact information] 4.1.9 Configuration Manager [name, title, organization, contact information] 4.1.10 Stakeholders [name, title, organization, contact information] 4.1.11 Project Baselines 4.2 Workflows and Activities 4.2.1 Change Request Management (CRM) Process Activity Descriptions 5. Milestones Confidential <Company Name>, 2012 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 7 7 7 7 8 9 11 13 13 13 15 15 15 15 15 15 15 16 16 16 16 16 16 16 17 18 Page 3 of 20
<Project Name> Requirements Management Plan <document identifier> 5.1 Inception 5.1.1 Evaluation Criteria 5.1.2 Artifacts 5.2 Elaboration 5.2.1 Evaluation Criteria 5.2.2 Artifacts 5.3 Construction 5.3.1 Artifacts 5.4 Transition 5.4.1 Evaluation Criteria 5.4.2 Artifacts 6. Training and Resources
18 18 18 19 19 19 19 19 20 20 20 20
Confidential
Page 4 of 20
Requirements Management Plan

1. Introduction
This document describes the guidelines used by the project to establish standard requirement documents, requirement types, requirement attributes, and traceability. It defines a general strategy for managing requirements and serves as a resource for all persons participating in this project. 1.1 Purpose
The purpose of this plan is to establish and document a systematic approach to eliciting, organizing, and documenting the requirements of the system. This plan also establishes and maintains agreement between the customer and the project team on the changing requirements of the system. 1.2 Scope
This plan provides guidelines for the management of [project name(s)] 1.3 Definitions, Acronyms, and Abbreviations
For common vocabulary for this project, please refer to the Glossary document. 1.4 References
[This subsection provides a complete list of all documents referenced elsewhere in the Requirements Management Plan. Identify each document by title, report number if applicable, date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document. The list includes two recommended books and one white paper published by Rational Software Corporation that deal specifically with Requirements Management. It also refers to the Rational Unified Process itself.] 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.5 Overview
[This subsection describes what the rest of the Requirements Management Plan contains and explains how the document is organized.] This document contains specific details and strategies for managing the requirements of the [project name(s)]. 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. The document describes the change management processes for requirements. It describes the workflows and activities associated with maintaining control of our project requirement. It specifies milestones to be reached and standards to be adhered to so that we can ensure and evaluate fulfillment of the requirements we specify.
2.
Requirements Management
2.1 Organization, Responsibilities, and Interfaces [Describe who is going to be responsible for performing the various activities described in the
Confidential
Page 5 of 20
requirements workflows. Basic roles are described below. If your project involves many individuals sharing roles, you may use the table below to fill out appropriate names, roles, and contact information.] 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. 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 Quality assurance (QA)
The function of Quality Assurance is the responsibility of (reports to) the Project Manager and is responsible for ensuring that project standards are correctly and verifiably followed by all project staff. 2.1.6 Developer
A person responsible for developing the required functionality in accordance with project-adopted standards and procedures. This can include performing activities in any of the requirements, analysis & design, implementation, and test disciplines. 2.1.7 Team leader
The team leader is the interface between project management and developers. The team leader is responsible for ensuring that a task is allocated and monitored to completion. The team leader is responsible for ensuring that development staff follow project standards, and adhere to project schedules. 2.1.8 Configuration manager
The configuration manager is responsible for setting up the product structure in the Change Management system, for defining and allocating workspaces for developers, and for integration. The configuration manager also extracts the appropriate status and metrics reports for the project manager. 2.1.9 Requirements specifier
The requirements specifier 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 requirements specifier may also be responsible for a use-case package, and maintains the integrity of that package. It is recommended that the requirements specifier responsible for a use-case package is also responsible for its contained use cases and actors. 2.2 Contact Table
[Use this table for quick reference to contact information.] Role Name Title Organization Contact
Confidential
Page 6 of 20
<Project Name> Requirements Management Plan <document identifier> Customer User Stakeholder Project manager Quality assurance Team leader Requirements specifier Configuration manager
2.3
Tools, Environment, and Infrastructure
[Describe the computing environment and software tools to be used in fulfilling the Requirements Management functions throughout the project or product lifecycle. Describe the tools and procedures used to version control requirements items generated throughout the project or product lifecycle.] Tool Description License Info Technical Support Website
Rational RequisitePro
For managing requirements
support@rational.com www.rational.com
3.
Requirements Artifacts
3.1 Artifact Description [Describe requirements artifacts (documents, requirement types, and requirement attributes) and define how they are to be named, marked, and numbered.] 3.1.1 Document Types [This table describes the default document types included in this template, and their associated default requirement types. You should add your custom document types to this table as you create them.]
Document Type
Stakeholder Requests Confidential
Description
Key requests from stakeholders <Company Name>, 2012
Default Requirement Type

Stakeholder Request (STRQ) Page 7 of 20
<Project Name> Requirements Management Plan <document identifier> (STR) [If you use a Change Request Management tool, such as Rational ClearQuest, then stakeholder requests are often stored in that tool and not duplicated in the requirements management tool.] Conditions or capabilities of this release of the system Use case description and elaboration. Used to capture common vocabulary. This document type describes system requirements not readily captured by the use cases. This document type describes requirements and strategies specific to the management and development of the project.
Vision (VIS) Use-Case Specification (UCS) Glossary (GLS) Supplementary Requirements Specification (SUP) Requirements Management Plan (RMP)
Feature (FEAT) Use Case (UC) Glossary Item (TERM) Supplementary Requirement (SUPL)
Default for documents without requirements (NONE)
3.1.2
Requirement Types
[This table describes the default requirement types included in this template. You should add your custom requirement types to this table as you create them.]
Requirement Type
Stakeholder Request (STRQ)
Description
A request of any typefor example, Change Request, enhancement request, request for a requirement change, defectfrom a stakeholder. An externally observable service provided by the system, which directly fulfills a stakeholder need.
Attributes
Stakeholder Priority, Origin
Feature (FEAT)
Priority, Type, Status, Difficulty, Stability, Risk, Planned Iteration, Actual Iteration, Origin, Contact Name, Enhancement Request, Defect, Obsolete Property, Priority, Status, Difficulty, Stability, Risk, Affects Architecture, Contact Name, Planned Iteration, Actual Iteration, Enhancement Request, Defect, Obsolete
Use Case (UC)
A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A term used in the projects common vocabulary. A description of a requirement not readily described by a Use Case.
Glossary Item (TERM) Supplementary Requirement (SUPL)
Priority, Status, Difficulty, Stability, Risk, Enhancement Request, Defect, Contact Name, Obsolete
Confidential
Page 8 of 20
3.1.3
Attributes
[For each requirement type you have identified, list what attributes you use and briefly explain what they mean. For example, the following attributes might be specified for a traceability item of feature.]
Description Attribute
[Describe your criteria for setting attribute values]
Type
List Values
Requirement Type
High Priority list Medium Low FEAT, UC, SUPL, STRQ
Proposed Status list Approved Incorporated Validated Planned Iteration Actual Iteration integer integer n/a n/a High Difficulty list Medium Low High Stability list Medium Low Hot Line Origin list Partners Competitors Large Customers Contact Name Enhancement Request Defect Text text text n/a n/a n/a FEAT, SUPL, UC FEAT, SUPL, UC FEAT, STRQ FEAT, SUPL FEAT, SUPL FEAT, UC FEAT, UC FEAT, UC, SUPL
Confidential
Page 9 of 20
<Project Name> Requirements Management Plan <document identifier> Name
Brief Description Basic Flow Alternate Flow Property list Special Requirement Pre-Condition Post-Condition Extension Point Affects Architecture list True/False Functional Usability Reliability Performance Supportability Type list Design Constraint FEAT Implementation Requirement Physical Requirement Interface Requirement Schedule-High ScheduleMedium Risk list Schedule-Low Technology-High TechnologyMedium Technology-Low Obsolete list True/False FEAT, UC, SUPL FEAT, SUPL, UC UC UC
Confidential
Page 10 of 20
3.1.4
List Values
[Use this table to define and elaborate on the list values of the requirement attributes in your project.]
Value
High Medium Low Proposed Approved Incorporated Validated High Medium Low High Medium Low Hot Line Partners Competitors Large Customers Name Brief Description Basic Flow Alternate Flow Special Requirement Pre-Condition Post-Condition Extension Point True False Functional Confidential Priority Priority Priority Status Status Status Status
For Attribute
Description [define each attribute value]
Difficulty Difficulty Difficulty Stability Stability Stability Origin Origin Origin Origin Property Property Property Property Property Property Property Property Affects Architecture Affects Architecture Type <Company Name>, 2012 Page 11 of 20
<Project Name> Requirements Management Plan <document identifier> Usability Reliability Performance Supportability Design Constraint Type Type Type Type Type
Implementation Requirement Type Physical Requirement Interface Requirement Schedule-High Schedule-Medium Schedule-Low Technology-High Technology-Medium Technology-Low True False Type Type Risk Risk Risk Risk Risk Risk Obsolete Obsolete
Confidential
Page 12 of 20
3.2 3.2.1
Traceability Traceability Criteria for Requirement Types
Stakeholder Request
Feature
Use Case
Supplementary Requirement
[For each requirement type you have identified, list any additional rules or guidelines that apply to traceability links. Describe any applicable constraints, such as every approved feature must trace to one or more Use Cases or to one or more Modern Software Requirement Specifications.]
Requirement Type
Stakeholder Request (STRQ) Feature (FEAT) Use Case (UC) Glossary Item (TERM) Supplementary Requirement (SUPL) .
Guidelines
Notes
3.3
Reports and Measures
[Describe the content, format, and purpose of the requested reports or measures. Use the table templates to describe the reports you generate using RequisitePros Requirements Metrics tool. For more information refer to RequisitePro online help] View Descriptions: [Use this section to describe views you have created for your project] Query Name Description Requirement Type Attributes Attribute Value Range
Confidential
Page 13 of 20
<Project Name> Requirements Management Plan <document identifier> Features Not Traced to Stakeholder Requests Supplementary Requirements Not Traced to Features FEAT, STRQ n/a
Not Traced
SUPL, FEAT
n/a
Not Traced
Use Cases Not Traced to Features
UC, FEAT
n/a
Not Traced
All Features
FEAT
all
all
Features Traced to Stakeholder Requests
FEAT, STRQ
n/a
all
All Glossary Terms
TERM
all
all
Features Impacted by Stakeholder Request Changes Supplementary Requirements Impacted by Feature Changes Use Cases Impacted by Feature Changes
FEAT, STRQ
n/a
suspect only
SUPL, FEAT
n/a
suspect only
UC, FEAT
n/a
suspect only
All Stakeholder Requests
STRQ
all
all
Confidential
Page 14 of 20
<Project Name> Requirements Management Plan <document identifier> All Supplementary Requirements SUPL all
all
Supplementary Requirements Traced to Features Use Case Survey
SUPL, FEAT
n/a
all
UC
name, brief description
name, brief description
Use Cases Traced to Features
UC, FEAT
n/a
all
4.
Requirements Change Management

4.1 Change Request Processing and Approval [Describe the process by which problems and changes are proposed, reviewed, and dispositioned. This should include the process for negotiating requirements changes with customers, and any contractual processes, activities, and constraints.] [Note: the content included in the description of the Requirements Change Management section is adapted from the Rational Unified Process. You should customize it to describe your Change Management policies as accurately as possible. Note also that the following items introduce activities, roles, and attributes, which are similar but not identical to the activities, roles, and attributes in preceding sections of this plan. We recommend that you develop a separate document to elaborate your Change Management system more fully.] 4.1.1 A Change Request, Enhancement Request, or Defect is proposed by a stakeholder.
[Elaborate on your proposal process here.] 4.1.2 The CCB reviews impact on artifacts, costs, and schedule.
[Elaborate on your CCB approve/reject decision-making guidelines here.] 4.1.3 Responsibility for implementing changes is assigned to appropriate workers.
[Elaborate on how responsibilities for changes are assigned here.] 4.1.4 Changes are incorporated into a build and tested.
[Elaborate on how changes are delivered to a build and tested here.] 4.1.5 The change requests are validated and closed.
[Elaborate on the validation process here.]
Confidential
Page 15 of 20
<Project Name> Requirements Management Plan <document identifier> 4.1.6 Change Control Board (CCB)
[Describe the membership and procedures for processing change requests and approvals to be followed by the CCB.] The CCB is a group composed of various technical and managerial stakeholders. The CCB assesses the impact of changes, determines priorities, and approves changes. 4.1.7 Change Control Manager [name, title, organization, contact information]
The change control manager role oversees the change control process. This role is usually played by a Configuration (or Change) Control Board (CCB) and consists of representatives from all interested parties, including customers, developers, and users. In a small project, a single team member, such as the project manager or software architect may play this role. The change control manager is also responsible for defining the Change Request Management Process, which is documented in the CM Plan. 4.1.8 Project Manager [name, title, organization, contact information]
Responsible for the configuration management plan, one of the components of the overall software development plane. The project manager is also the recipient and use of the status and measurement reports. 4.1.9 Configuration Manager [name, title, organization, contact information]
Responsible for setting up the product structure in the Change Management system, for defining and allocating workspaces for developers, and for integration. The configuration manager also extracts the appropriate status and metrics reports for the project manager. 4.1.10 Stakeholders [name, title, organization, contact information] Propose change requests. 4.1.11 Project Baselines [Baselines provide an official standard on which subsequent work is based and to which only authorized changes are made. Describe at what points during the project or product lifecycle baselines are to be established. The most common baselines would be at the end of the Inception, Elaboration, Construction, and Transition phases. Baselines could also be generated at the end of iterations within the various phases or even more frequently. Describe who authorizes a baseline and what goes into it.]
Iteration
Primary Role
Description
Deadline
4.2
Workflows and Activities
[Describe the workflows and activities that apply to managing requirements. Describe review activities, including review objectives, responsibilities, timing, and procedures.] <Company Name>, 2012
Confidential
Page 16 of 20
<Project Name> Requirements Management Plan <document identifier> 4.2.1
Change Request Management (CRM) Process Activity Descriptions
Activity
Description
Responsibility
Corresponding Requirement Status

Proposed
Submit CR
Any stakeholder on the project can submit a Change Request (CR). The Change Request is logged into the Change Request Tracking System (e.g., Rational ClearQuest) and is placed into the CCB Review Queue, by setting the Change Request State to Proposed. The function of this activity is to review Proposed Change Requests. An initial review of the contents of the Change Request is done in the CCB Review meeting to determine if it is a valid request. If so, then a determination is made if the change is in or out of scope for the current release(s), based on priority, schedule, resources, level-of-effort, risk, severity and any other relevant criteria as determined by the group. If a Change Request is suspected of being a Duplicate or Rejected as an invalid request (e.g., operator error, not reproducible, the way it works, etc.), a delegate of the CCB is assigned to confirm the duplicate or rejected Change Request and to gather more information from the submitter, if necessary. If more information is needed (More Info) to evaluate a Change Request, or if a Change Request is rejected at any point in the process (e.g., confirmed as a Duplicate, Rejected, etc.), the submitter is notified and may update the Change Request with new information. The updated Change Request is then re-proposed to the CCB Review Queue for consideration of the new data. Once a Change Request is Opened, the Project Manager will then assign the work to the appropriate team member depending on the type of request (e.g., enhancement request, defect, documentation change, test defect, etc.) and make any needed updates to the project schedule. The assigned team member performs the set of activities defined within the appropriate section of the process (e.g., requirements, analysis & design, implementation, produce user-support materials, design test, etc.) to make the changes requested. These
Submitter
Review CR
CCB
Proposed
Confirm Duplicate or Reject
CCB Delegate
Proposed
Update CR
Submitter
Proposed
Assign & Schedule Work
Project Manager
Approved
Make Changes
Assigned Team Member
Incorporated
Confidential
Page 17 of 20
<Project Name> Requirements Management Plan <document identifier> activities will include all normal review and unit test activities as described within the normal development process. The Change Request will then be marked as Resolved. Verify Changes in Test Build After the changes are Resolved by the assigned team member (analyst, developer, tester, tech writer, etc.), the changes are placed into a test queue to be assigned to a tester and Verified in a test build of the product. Once the resolved changes have been Verified in a test build of the product, the Change Request is placed into a release queue to be verified against a release build of the product, produce release notes, etc. and Close the Change Request. Tester
Incorporated
Verify Changes in Release Build
CCB Delegate (System Integrator)
Validated
5.
Milestones
[Identify the internal and customer milestones related to the Requirements Management effort. This section should include details on when the Requirements Management Plan itself is to be updated.] 5.1 Inception
5.1.1 Evaluation Criteria Stakeholder concurrence on scope definition and cost/schedule estimates Agreement that the right set of requirements has been captured and that there is a shared understanding of these requirements. Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate. All risks have been identified and a mitigation strategy exists for each.
The project may be aborted or considerably re-thought if it fails to reach this milestone. 5.1.2 Artifacts
Tasks/Artifacts
[Describe new tasks and artifacts here. Click the Tab button to create new rows for new tasks.]
Description
Start Date
End Date
Confidential
Page 18 of 20
<Project Name> Requirements Management Plan <document identifier> 5.2 Elaboration
At the end of the elaboration phase is the second important project milestone. At this point, you examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks. 5.2.1 Evaluation Criteria
The product Vision and requirements are stable. The architecture is stable. The key approaches to be used in test and evaluation are proven. Test and evaluation of executable prototypes have demonstrated that the major risk elements have been addressed and have been credibly resolved. The iteration plans for the construction phase are of sufficient detail and fidelity to allow the work to proceed. The iteration plans for the construction phase are supported by credible estimates. All stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture. Actual resource expenditure versus planned expenditure is acceptable.
The project may be aborted or considerably re-thought if it fails to reach this milestone. 5.2.2 Artifacts
Tasks/Artifacts
Description
Start Date
End Date
5.3 Construction Evaluation Criteria The evaluation criteria for the construction phase involve the answers to these questions: Is this product release stable and mature enough to be deployed in the user community? Are all the stakeholders ready for the transition into the user community? Are actual resource expenditures versus planned still acceptable? Transition may have to be postponed by one release if the project fails to reach this milestone. 5.3.1 Artifacts
Tasks/Artifacts
Confidential
Description
Start Date
End Date
Page 19 of 20
<Project Name> Requirements Management Plan <document identifier> [Describe new tasks and artifacts here. Click the Tab button to create new rows for new tasks.]
5.4
Transition
5.4.1 Evaluation Criteria The primary evaluation criteria for the transition phase involve the answers to these questions: Is the user satisfied? Are actual resources expenditures versus planned expenditures acceptable?
At the Product Release Milestone, the product is in production and the post-release maintenance cycle begins. This may involve starting a new cycle, or some additional maintenance release. 5.4.2 Artifacts
Tasks/Artifacts
Description
Start Date
End Date
6.
Training and Resources

[Describe the software tools, personnel, and training required to implement the specified Requirements Management activities.]
Confidential
Page 20 of 20

Requirements Management Plan

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Requirements Management Plan

Diunggah oleh

Hak Cipta:

Format Tersedia

<Company Name> <Project Name> Requirements Management Plan

<Project Name> Requirements Management Plan <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

<Company Name>, 2012

<Project Name> Requirements Management Plan <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

Version: <1.0> Date: <dd/mmm/yy>

<Company Name>, 2012

<Project Name> Requirements Management Plan <document identifier>

Version: <1.0> Date: <dd/mmm/yy>