Requirements Management Plan Requirements Management Plan Version [Note The following template is provided for use with the Rational Unified Process and the Requisi[.]
Requirements Management Plan Version [Note: The following template is provided for use with the Rational Unified Process and the RequisitePro Composite 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 not want to use this content, you may remove this document and create a new, empty Requirements Management Plan.] Requirements Management Plan Version: Date: Revision History Date Confidential Version Description , 2023 Author Page of 20 Requirements Management Plan Version: Date: Table of Contents Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 4 4 4 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 5 5 5 5 5 6 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 6 11 12 12 12 Requirements Change Management 4.1.1 Change Request Processing and Approval 4.1.2 Change Control Board (CCB) 4.1.3 Project Baselines 4.2 Workflows and Activities 4.2.1 Change Request Management (CRM) Process Activity Descriptions 14 14 15 15 16 16 Milestones 5.1.1 5.1.2 5.1.3 5.1.4 17 17 18 19 19 Inception Elaboration Construction Transition Training and Resources Confidential 20 , 2023 Page of 20 Requirements Management Plan Version: Date: Requirements Management Plan 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 2002.05.00 Copyright â 1987 2001 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 Confidential , 2023 Page of 20 Requirements Management Plan Version: Date: Requirements Management 2.1 Organization, Responsibilities, and Interfaces [Describe who is going to be responsible for performing the various activities described in the 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 who 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 Confidential , 2023 Page of 20 Requirements Management Plan 2.2 Version: Date: Contact Table [Use this table for quick reference to contact information.] Role Name Title Organization Contact customer user stakeholder project manager quality assurance team leader requirements specifier 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 Rational RequisitePro For managing requirements Requirements Artifacts 3.1 Artifact Description Licens e Info Technical Support Website support@rational.co m www.rational.com [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 Confidential , 2023 Page of 20 Requirements Management Plan Version: Date: requirement types You should add your custom document types to this table as you create them.] Document Type 3.1.2 Description Default Requirement Type Stakeholder Requests (STR) Key requests from stakeholders Stakeholder Request (STRQ) Vision (VIS) Conditions or capabilities of this release of the system Feature (FEAT) Use-Case Specification (UCS) Use case description and elaboration Use Case (UC) Glossary (GLS) Used to capture common vocabulary Glossary Item (TERM) Supplementary Requirements Specification (SUP) This document type describes system requirements not readily captured by the use cases Supplementary Requirement (SUPL) Requirements Management Plan (RMP) This document type describes requirements and strategies specific to the management and development of the Requirements Management Plan Requirements Management Plan (RMP) [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.] 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 Description Attributes Stakeholder Request (STRQ) A request of any type—for example, Change Request, enhancement request, request for a requirement change, defect—from a stakeholder Priority, Status, Cost, Difficulty, Stability, Assigned to Feature (FEAT) An externally observable service provided by the system which directly fulfills a stakeholder need Priority, Status, Planned Iteration, Actual Iteration, Difficulty, Stability, Assigned to, Origin, Rationale, Cost, EnhancementRequest, Defect 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 Property, Affects Architecture, Planned Iteration, Actual Iteration, Assigned to, Rank, Test, Priority, Status, Difficulty, Stability, Cost, EnhancementRequest, Defect Confidential , 2023 Page of 20 Requirements Management Plan Version: Date: Glossary Item (TERM) A term used in the project’s common vocabulary Supplementary Requirement (SUPL) A description of a requirement not readily described by a Use Case Confidential , 2023 Priority, Status, Difficulty, Stability, Assigned to, Cost, EnhancementRequest, Defect, Test Page of 20 Requirements Management Plan 3.1.3 Version: Date: 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 Must Priority list Should Could FEAT, UC,SUPL, RMP, STRQ Won't Proposed Status list Approved Incorporated FEAT, UC,SUPL, RMP, STRQ Validated Planned Iteration integer n/a FEAT, UC Actual Iteration integer n/a FEAT, UC High Difficulty list Medium FEAT,RMP,SUPL,STRQ Low High Stability list Medium FEAT,RMP,SUPL, STRQ Low Assigned to text n/a FEAT,RMP,SUPL,STRQ Hot Line Origin list Partners Competitors FEAT Large Customers Rationale text n/a FEAT Cost real n/a FEAT,RMP, SUPL,STRQ Confidential , 2023 Page of 20 Requirements Management Plan Version: Date: EnhancementRequ est text Defect text n/a n/a FEAT,SUPL FEAT, SUPL Name Brief Description Basic Flow Property list Alternate Flow UC Special Requirement Pre-Condition Post-Condition Affects Architecture Boolean Rank integer n/a UC Test Boolean True/False UC, SUPL Confidential True/False , 2023 UC Page 10 of 20 Requirements Management Plan 3.1.4 Version: Date: List Values [Use this table to define and elaborate on the list values of the requirement attributes in your project.] Value for Attribute Must Priority Should Priority Could Priority Won't Priority Proposed Status Approved Status Incorporated Status Validated Status High Difficulty Medium Difficulty Low Difficulty High Stability Medium Stability Low Stability Hot Line Origin Partners Origin Competitors Origin Large Customers Origin Brief Description Property Basic Flow Property Alternate Flow Property Special Requirement Property Pre-Condition Property Post-Condition Property Confidential , 2023 Description [define each attribute value] Page 11 of 20 Requirements Management Plan Version: Date: 3.2 Traceability 3.2.1 Traceability Criteria for Requirement Types [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 Guidelines Stakeholder Request (STRQ) Every stakeholder request with “Approved” status must trace to one or more Features Feature (FEAT) Every Feature with “Approved” status or greater must trace to one or more Use Cases or to one or more Supplementary Requirements Notes Use Case (UC) 3.3 Glossary Item (TERM) Every Glossary term must have a unique and consistent definition throughout all project documents and artifacts Supplementary Requirement (SUPL) 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 RequisitePro’s Requirements Metrics tool For more information refer to RequisitePro online help] For reports and measures on this project, use the Requirement Metrics tool, which is available from the Tool menu In Requirement Metrics, create reports based on requirement types or saved views and query on the following filters: Attribute Value: An Attribute Value filter returns the requirements whose attributes have values that matches your criteria The choices you make depend on the data type of the attribute you select in the Attributes drop-down list Attribute Value Change: An Attribute Value Change filter returns the requirements with a changed attribute value that matches your BEFORE and AFTER selections The choices you make depend on the data type of the attribute you select in the Attributes drop-down list If several changes have been made to the attribute value, your BEFORE selection must specify the value which immediately preceded the current (AFTER) value To report any change in an attribute value of the selected requirement type, use the Select All buttons for the BEFORE and AFTER selections Base Filter: Confidential , 2023 Page 12 of 20 Requirements Management Plan Version: Date: The Base filter defines the requirement type for a query Every query is specific to a single requirement type When you use a saved RequisitePro view defined in the Views Workplace, the Base filter serves as the first filter for requirements The Base filter cannot be deleted, and is only changed by selecting a new view from the Choose a Requirement View drop-down list Children: A Children filter returns the requirements that have the number of direct children that matches your selection criteria You must choose which operator to use and enter at least one numeric value If you choose the "Between" or "Not Between" operator, you must also enter a second numeric value The default setting (> 0) reports all requirements of the selected type that have any children Parent Change A Parent Change filter returns the requirements whose parent relationship has changed from your BEFORE selection to your AFTER selection The selections allow you to report requirements that were changed from or to any parent, no parent, or one or more selected parents which you choose When reporting changes to selected requirements, if a requirement had several changes of parent assignments, your BEFORE selection must specify the value which immediately preceded the current (AFTER) value Requirement Creation: The Requirement Creation filter returns all requirements of the specified requirement type Typically, this filter is used with the Time Period option to determine which requirements have been created in a specified time period Requirement Text Change: A Requirement Text Change filter returns the requirements whose text has changed the number of times you specify The filter allows you to choose comparison operators, such as "equal to" (=), "greater than" (>), etc., when specifying the number of times that the text has changed Traceability Change: A Traceability Change filter returns the requirements that had a trace relationship either removed or added, depending on your selection View Descriptions: [use this section to describe views you have created for your project] Query Name Description Requirement Type Attributes Attribute Value Range Features displays all requirements of the Feature Type FEAT all all Glossary Terms displays all requirements of the Glossary Term Type TERM all all Confidential , 2023 Page 13 of 20 Requirements Management Plan Version: Date: Supplementary Requirements displays all requirements of the Supplementary Requirements Type SUPL all all Stakeholder Request displays all requirements of the Stakeholder Request Type STRQ all all Use Case Survey displays all requirements of the Use Case Type UC all all Requirements Change Management 4.1.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.1 A Change Request, Enhancement Request, or Defect is proposed by a stakeholder [Elaborate on your proposal process here.] 4.1.1.2 The CCB reviews impact on artifacts, costs, and schedule [Elaborate on your CCB approve/reject decision-making guidelines here.] 4.1.1.3 Responsibility for implementing changes is assigned to appropriate workers [Elaborate on how responsibilities for changes are assigned here.] Confidential , 2023 Page 14 of 20 Requirements Management Plan Version: Date: 4.1.1.4 Changes are incorporated into a build and tested [Elaborate on how changes are delivered to a build and tested here.] 4.1.1.5 The change requests are validated and closed [Elaborate on the validation process here.] 4.1.2 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.2.1 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.2.2 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.2.3 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.2.4 Stakeholders [name, title, organization, contact information] Propose change requests 4.1.3 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 Confidential Primary Role Description , 2023 Deadline Page 15 of 20 Requirements Management Plan 4.2 Version: Date: Workflows and Activities [Describe the workflows and activities that apply to managing requirements Describe review activities, including review objectives, responsibilities, timing, and procedures.] 4.2.1 Change Request Management (CRM) Process Activity Descriptions Activity Description Responsibility Corresponding Requirement Status 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 Submitter Proposed Review CR 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 CCB Proposed Confirm Duplicate or Reject 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 CCB Delegate Proposed Update CR 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 Submitter Proposed Confidential , 2023 Page 16 of 20 Requirements Management Plan Version: Date: Assign & Schedule Work 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 Project Manager Approved Make Changes 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 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 Assigned Team Member Incorporated 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 Tester Incorporated Verify Changes in Release Build 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 CCB Delegate (System Integrator) Validated 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.1 Inception 5.1.1.1 Evaluation Criteria Stakeholder concurrence on scope definition and cost/schedule estimates Agreement that the right set of requirements have 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 Confidential , 2023 Page 17 of 20 Requirements Management Plan Version: Date: 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.1.2 Artifacts Tasks/Artifacts Description Start Date End Date [Describe new tasks and artifacts here Click the Tab button to create new rows for new tasks.] 5.1.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.1.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 are acceptable The project may be aborted or considerably re-thought if it fails to reach this milestone 5.1.2.2 Artifacts Tasks/Artifacts Description Start Date End Date [Describe new tasks and artifacts here Click the Tab button to Confidential , 2023 Page 18 of 20 Requirements Management Plan Version: Date: create new rows for new tasks.] 5.1.3 Construction 5.1.3.1 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.1.3.2 Artifacts Tasks/Artifacts Description Start Date End Date [Describe new tasks and artifacts here Click the Tab button to create new rows for new tasks.] 5.1.4 Transition 5.1.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.1.4.2 Artifacts Tasks/Artifacts Description Start Date End Date [Describe new tasks and artifacts Confidential , 2023 Page 19 of 20 Requirements Management Plan Version: Date: here Click the Tab button to create new rows for new tasks.] Training and Resources [Describe the software tools, personnel, and training required to implement the specified Requirements Management activities.] Confidential , 2023 Page 20 of 20