Describes the requirements artifacts, requirement types, and their respective requirements attributes, specifying the information to be collected and control mechanisms to be used for measuring, reporting, and controlling changes to the product requirements.
Role:  System Analyst 
Optionality/Occurrence:  Developed during the Inception phase and is updated at each major milestone.
Templates and Reports: 
  • Requirements Management Plan

  •  
    Examples: 
  • CSPS Requirements Management Plan V1.0
  • Examples
  •  
    UML Representation:  [Begin brief description here (if applicable) of UML representation here] 
    More Information:   
    Input to Activities:    Output from Activities:   

    Purpose To top of page

    A Requirements Management Plan should be developed to specify the information and control mechanisms that will be collected and used for measuring, reporting, and controlling changes to the product requirements.

    The purpose of the Requirements Management Plan is to describe how the project will set up and manage the requirement artifacts, associated requirement types , and their respective requirement attributes. The plan also addresses how traceability will be managed.

    Timing To top of page

    The Requirements Management Plan is developed during the Inception phase and is updated at each major milestone.

    ResponsibilityTo top of page

    The System Analyst is responsible for creating the Requirements Management Plan.

    Tailoring To top of page

    Tailoring should, at a minimum, include defining the traceability items, constraints, and attributes applicable to your project. Other significant traceability concerns include:

    • relationship to other plans
    • tool considerations

    Relationship to Other PlansTo top of page

    The Requirements Management Plan contains information that may be covered to a greater or lesser extent by other plans. The following approaches can be used to handle this potential overlap:

    • Reference the content in another plan.
    • Provide the overview in another plan and provide greater detail in this plan. References from these other plans to the Requirements Management Plan may be useful. This often works well on large projects with a separate organization that is responsible for managing requirements.
    • Tailor the document sections to cover only those areas that are not covered elsewhere.

    The following is a mapping of Requirements Management Plan sections to artifacts that may contain complementary information:

    Requirements Management Plan Section  Complementary Artifact 
    Definitions, Acronyms, and Abbreviations  Glossary 
    Organization, Responsibilities, and Interfaces  Software Development Plan 
    Tools, Environment, and Infrastructure  Development Case, Software Development Plan (Infrastructure Plan) 
    Requirements Identification   Configuration Management Plan 
    Traceability  Development Case, Measurement Plan 
    Attributes  Development Case, Measurement Plan 
    Reports  Development Case, Measurement Plan 
    Requirements Change Management  Configuration Management Plan 
    Workflows and Activities  Development Case 
    Milestones  Software Development Plan, Iteration Plan 
    Training and Resources  Software Development Plan 

    Tool ConsiderationsTo top of page

    Rather than document the traceability attributes and their intended values separately, you may choose to enter this information directly into the tool that you use for managing requirements. This would leave only their usage to be documented in the Requirements Management Plan.

    Note that the Requirements Management Plan is sometimes used to document more than just the direct requirements management items. For example, users of Rational RequisitePro often use this document to capture other items managed by the tool, such as glossary terms, requirements action items and so forth. However, while RequisitePro can also be used to manage items such as risks and issues, these are treated as separate artifacts in RUP—the management of which is not covered in the Requirements Management Plan.



    Copyright © 1987 - 2003 Rational Software Corporation

    Rational Unified Process