Requirements Management Plan Template

REQUIREMENTS MANAGEMENT PLAN TEMPLATE CONTENTS 1OVERVIEW1 1. 1Purpose1 1. 2Scope1 1. 3Applicability1 1.

4Document Organization1 1. 5Applicable Documents1 1. 6Changes and Revisions1 1. 7Issues1 2ROLES AND RESPONSIBILLITIES2 2. 1Organization Overview2 2.

1. 1Role A2 3REQUIREMENTS PROCESSES2 3. 1Overview2 3. 1. 1Phase One2 4TOOLS2 5REQUIREMENTS DOCUMENTATION AND ORGANIZATION2 5. 1Requirements Documentation2 5.

1. 1Breakdown Structures3 5. 1. 2Associated Information3 . 2Organization3 5.

2. 1Numbering Convention3 5. 2. 2Traceability Strategy3 5. 2. 3Repository Structure3 6MEASURES3 7REPORTS3 8APPENDICES1 A.

Definitions, Acronyms, Abbreviations2 B. Forms3 C. Requirements Evaluation Checklists4 D. Requirement Report Examples6 E. Quality Standards7 Exhibits A.

ROLES AND ORGANIZATION2 B. List of Tools2 C. Associated Information3 D. Checklist for Individual Requirements4 E. Checklist for All Requirements5 Revision History DATE |Version |Description |Author | | | | | | | | | | | | | | | | OVERVIEWProvide a brief description of the project or organization, its purpose, and history.

Describe the system that will be built, modified, or maintained. 1 Purpose The purpose of requirement management is to establish a common understanding of the technical and non-technical requirements that will be addressed by the project or organization between the customer and project or organization, within the project or organization, and throughout the lifecycle. The goals of requirements management are to ensure that requirements are controlled to establish a baseline for development, acquisition, or management; and to ensure plans, work products, and ctivities are consistent with the requirements. The RM plan establishes an orderly method by which the goals of requirements management will be achieved. The plan also communicates essential information to project participants and helps newcomers get up to speed.

Consequently, the plan is a living document, which needs to be updated and supplemented throughout its life. 2 Scope The scope of the plan includes: • What must be done • How it shall be done • Who will perform various activities • When they must be performed What level of requirement quality must be achieved 3 Applicability Describe who and what is affected by the plan. 4 Document Organization Overview of the document contents. 5 Applicable Documents Identify documents controlling RM plan contents. 6 Changes and Revisions Tell what organization is responsible for controlling changes to the RM plan and related information.

7 Issues Describe issues that affect implementation of the requirements management plan (training, tool selection, geographic distribution of the team, etc. )ROLES AND RESPONSIBILLITIES 1 Organization Overview Provide an overview of the organization from a requirements perspective. Use graphics and/or a table showing project organization for easy reference. Contact information may also be included. |ROLE |NAME |ORGANIZATION | |Project Manager |Joe S.

|Project Management Office | |Project Sponsor |Jane T. Client Upper Mgmt Office | |SME |Jack Z. |Client Office A | A. Roles and Organization 1 Role A Provide the responsibilities and duties of each party or group during the lifecycle. REQUIREMENTS PROCESSES This section describes the approach to identifying, developing, maintaining, and managing requirements. Discuss inputs, processes, outputs, timing, entrance and exit criteria, events, and other information.

Describe how participants will interface with each other. 1 OverviewProvide an overview of the processes relative to the lifecycle; structure the processes or activities and phases by the model you are following (CMMI, PMP, etc. ) 1 Phase One Describe the phase. 1 Process or Activity A PROVIDE THE DETAILS OR WORKFLOW OF THE PROCESS, ACTIVITY, OR PROCEDURE; DEPICT IT GRAPHICALLY. TOOLS Describe the tools that will be used for requirements.

Tools may include commercial software packages for the requirements repository, CASE tools, test tools, project planning tools, issue management tools, estimating tools, as well as non-automated tools such as diagrams and storyboards.If a tool has not been selected, provide the requirements for selecting it. |Tool |Version |Use | | | | | | | | | B. List of ToolsREQUIREMENTS DOCUMENTATION AND ORGANIZATION 1 Requirements Documentation Discuss the requirements documents that will be produced. 1 Breakdown Structures Provide a diagram showing the requirements levels.

Provide the standard for how requirements will be organized and decomposed; describe the relationship of the levels to the development phases and the requirements documentation. 2 Associated Information Describe the information that will be associated with each requirement and who is responsible for collecting the information. Associated Information |Use |Captured By | |Change history |Change control and audit |RM Tool | |Priority |Implementation planning |Analyst | |Unique ID |Traceability matrix |RM Tool |C. Associated Information 2 Organization 1 Numbering Convention Describe the requirements numbering convention that will be used. Do not use the outline organization numbering of the requirements document as the unique ID.

2 Traceability Strategy Describe the traceability strategy. Depict the traceability strategy graphically. 3 Repository Structure Describe how the requirements will be structured in the requirements management tool or repository and the relationship, interface, or dependency on data in other tools.The repository structure is based on the traceability strategy. MEASURES Describe the measures that will be used for managing requirements.

Put details of the measures in the appendix. REPORTS Describe the reports that will be generated and their purpose. Put examples of the reports in the appendix. APPENDICES Appendices contain details not included in the plan. A. Definitions, Acronyms, Abbreviations |ASSOCIATED INFORMATION |INFORMATION ASSOCIATED WITH A REQUIREMENT, INCLUDING TRACEABILITY INFORMATION.

IF A REQUIREMENTS MANAGEMENT | | |TOOL IS USED, THE REQUIREMENTS DATABASE OR REPOSITORY USUALLY HAS MORE ASSOCIATED INFORMATION THAN HARDCOPY | | |DOCUMENTS SUCH AS THE SRS. | |CHILD |CHILD REQUIREMENTS ARE DECOMPOSED FROM PARENT REQUIREMENTS. FOR EXAMPLE, A IS THE CHILD OF THE REQUIREMENT | | |ABC. |COMPLIANCE MATRIX |RTM | |CONSTRAINT |BOUNDARY CONDITIONS ON HOW THE SYSTEM MUST BE CONSTRUCTED AND IMPLEMENTED, FOR EXAMPLE, HOW A COTS PACKAGE | | |MIGHT BE SELECTED. | |DERIVED |NEW REQUIREMENTS IDENTIFIED DURING THE DEVELOPMENT PROCESS THAT TRACE BACK TO A DRIVING REQUIREMENT. | |GOAL |STATES THE DESIRED RESULT, NOT THE WAY TO REACH IT.

FOR EXAMPLE, THEY SYSTEM SHALL REDUCE OPERATING COSTS BY| | |10% OF 2001 COSTS. ALL CHANGES IN REQUIREMENTS AND DESIGN SHOULD BE PASSED THROUGH STATED GOALS. IF THEY | | |ARE OUTSIDE THE GOALS, THEY SHOULD BE REJECTED. | |INFORMATION |ANY COMMUNICATION OR REPRESENTATION OF KNOWLEDGE SUCH AS FACTS, DATA, OR OPINIONS IN ANY MEDIA OR FORM. | |NON-FUNCTIONAL REQUIREMENT |RELATE TO CHARACTERISTICS OF A SYSTEM SUCH AS PERFORMANCE, RELIABILITY, SECURITY, ACCURACY, AND SO FORTH.

|NON-TECHNICAL REQUIREMENTS |AGREEMENTS, CONDITIONS, OR CONTRACTUAL TERMS THAT AFFECT AND DETERMINE THE MANAGEMENT ACTIVITIES OF A | | |PROJECT. | |PARENT |CHILD REQUIREMENTS ARE DECOMPOSED FROM PARENT REQUIREMENTS. SEE CHILD REQUIREMENT. | |PMO |PROJECT MANAGEMENT OFFICE | |REQUIREMENT |A CONDITION OR CAPABILITY THAT IS WANTED OR NEEDED. |REQUIREMENT REPOSITORY |COTS PROVIDING A DATABASE OR SPREADSHEET IN WHICH THE REQUIREMENTS AND ASSOCIATE INFORMATION ARE STORED. | |RM |REQUIREMENTS MANAGEMENT | |RTM |REQUIREMENTS TRACEABILITY MATRIX | |SME |SUBJECT MATTER EXPERT IN ONE OR MORE AREAS OF THE CLIENT’S BUSINESS.

| |SRS SYSTEM REQUIREMENTS SPECIFICATION. | |SYSTEM FUNCTIONAL REQUIREMENTS |INCLUDE FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS ON THE SYSTEM. | B. Forms INCLUDE FORMS THAT WILL BE USED. C.

Requirements Evaluation Checklists ENTER THE UNIQUE ID OF THE PROBLEM REQUIREMENT(S). EXPLAIN IN REMARKS THE REASON IF “NO” IS CHECKED. ATTACH ADDITIONAL SHEETS IF NEEDED. |Evaluation Criteria |Yes |No |ID |Remarks | |A test case is associated with the requirement. | | | | |The requirement can be understood by affected parties (e.

g. , SME, | | | | | |developers, testers). | | | | | |Unacceptable words and phrases are absent (e. g. , adverbs, adjectives, as | | | | | |appropriate, at a minimum).

| | | | |Adheres to defined terms in the requirements glossary. | | | | | |Requirement conforms to standard format. | | | | | |Requirement is at the appropriate level of detail for its position in the| | | | | |hierarchy. | | | | |Requirement has the associated information required by the RM plan. | | | | | |Requirement is within scope. | | | | | |Requirement is terse.

| | | | | |Requirement avoids specifying design. | | | | | |Requirement is feasible. | | | | |Requirement is written in the imperative (shall). | | | | | |Cross-references are specific so the information can be easily located; | | | | | |the reference is located in the project document library if it is | | | | | |external to the requirement. | | | | |Requirement can be traced to its parent or driver.

| | | | | |Requirement is unrestrictive; it can be implemented by more than one | | | | | |solution or design. | | | | | |Requirement contains no TBD. | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | D. Checklist for Individual Requirements |Evaluation Criteria – All Requirements |Yes |No |IDs |Remarks | |Requirements are consistent with each other. | | | | | |Requirements are complete: every case or scenario is addressed.

| | | | | |Requirements address user interfaces. | | | | | |Non-functional requirements are addressed. | | | | |Assumptions and dependencies for requirements are stated. | | | | | |Requirements address system and user error conditions. | | | | | |All requirements are traced to their parent or driver (no dropped | | | | | |traceability).

| | | | | |Interfaces are specified (internal/external). | | | | | |Inputs and outputs are specified. | | | | | | | | | | | | | | | | | | | | | | | | | | | | E. Checklist for All Requirements D. Requirement Report Examples Some requirement reports are listed below.

Examples should be generated from the tool when possible. • Traceability Matrix • Unallocated Requirements • Requirements by Risk • Requirements by Priority • Requirements by Qualification Method • Requirements Status • Cumulative Changes • Other Requirement Metrics Reports E. Quality Standards DESCRIBE THE CHARACTERISTICS OF REQUIREMENTS OF GOOD QUALITY.