2.1.3.3P Create Requirements Management Plan

(2.1.3.3P.P1)

The Requirements Management Plan describes how you will elicit, analyze, document and manage the requirements of the project. This plan will cover the up-front gathering of high-level project and product requirements, as well as the more detailed product requirements that you will collect during the project lifecycle. This plan should especially focus on how you will manage changes to the requirements after they have been originally approved. Adhering to a Requirements Management Process helps the project team focus on the requirements that have been developed and maintains the integrity of the requirements throughout the lifecycle of the project. Sections of the plan could include the following information:

  • The requirements gathering process.  In this section you will describe the process that you will use to elicit, analyze and document the requirements.

  • Roles and responsibilities. This section lists the roles that will be involved with managing the requirements through the rest of the project lifecycle. Roles could include the project manager, lead analyst, clients, etc. The project manager, for instance, should have the overall responsibility for scope change management of the requirements. Someone, perhaps the lead analyst, should have overall responsibility for the integrity of the requirements throughout the rest of the lifecycle.

  • Tools. Describe any automated tools that will be used to manage the requirements. There are a number of tools that can be used to document, manage and track requirements throughout the lifecycle.

  • Change control. There should be a formal process to manage changes to the requirements. Hopefully, the entire project is using a formal scope change process. If so, then this overall scope change process should be specifically applied to the changes in requirements. If there is no formal overall scope change process, a specific change control process should be documented here.

  • Requirements traceability. If your project team is tracking (tracing) requirements from Analysis to Design and through the rest of the lifecycle, the overall process should be described here. This process should then be added to the schedule to ensure the proper tracking of requirements occurs throughout the rest of the project.

  • Reports. Comment here on the types and names of reports you are using to define and manage the scope, who will receive them, the frequency, etc.

  • Expected Scope Stability. This section describes the expectations regarding scope stability, i.e. whether scope is expected to change significantly during the course of the project or is expected to remain as initially defined.  For example, if the scope definition is ambiguous and clarification is not possible, you can state that you expect the defined scope to be subject to many revisions, which will add more risk to the project.