Requirements Management Plan Template

Introduction

The Requirements Management Plan is a necessary tool for establishing how requirements will be collected, analyzed, documented, and managed throughout the lifecycle of a project. Depending on the type of project there may be both project and product requirements. It is easy to unintentionally omit requirements, fail to document them, or leave requirements incomplete without a tool to properly manage them.

The purpose of the BrightStar Requirements Management Plan is to establish a common understanding of how requirements will be identified, analyzed, documented, and managed for the BrightStar fiber optic cable project.

Requirements will be divided into two categories: project requirements and product requirements. Project requirements are the requirements identified to meet the needs of the project and ensure its completion and readiness to hand over to operations. These consist mostly of non-technical requirements. Product requirements are the requirements identified to meet the technical specifications of the product being produced as a result of the project: the BrightStar fiber optic cable. These will consist of requirements to ensure that performance specifications are met, cable properties are properly documented, and manufacturing thresholds are identified and documented.

The inputs for the requirements management plan include the BrightStar Project Charter and Stakeholder Register.

Requirements Management Approach

The requirements management approach is the methodology the project team will use to identify, analyze, document, and manage the project’s requirements. Many organizations use a standard approach for all projects, but based on the characteristics of each project, this approach may require some changes. The PMBOK® defines this approach as “How requirements activities will be planned, tracked, and reported.” Complete this section of the Requirements Management Plan with the approach you will take to managing requirements.

The approach we will use for requirements management for the BrightStar project will be broken down into four areas: requirements identification, requirements analysis, requirements documentation, and ongoing requirements management.

Requirements Identification: The BrightStar project team will facilitate various methods to collect requirements which may include: interviews, focus groups, facilitated workshops, group creativity techniques, questionnaires and surveys, or product prototypes. These will be conducted among the project stakeholders to ensure all requirements are captured.

Requirements Analysis: The BrightStar project team will analyze requirements to determine if they fall into project or product categories. Additionally, this analysis will determine where in the WBS the requirements will fall or what work activities correspond to particular requirements. Accountability and priority for each requirement will also be determined as part of the analysis. Finally, metrics and acceptance criteria must be determined for all requirements in order to provide a baseline for understanding when a requirement has been fulfilled to an acceptable level.

Requirements Documentation: Once requirements have been identified and analyzed, they will be documented and assigned to accountable personnel. These requirements will be added to the BrightStar project plan and the project team will determine what methodology the accountable personnel will use to track and report on the status of each requirement. All requirements will also be added to the project requirements checklist which must be completed before formal project closure is accepted by the project sponsor.

Ongoing Requirements Management: Throughout the project lifecycle, the project manager will ensure all team members are reporting requirement status and raising any issues or concerns with their assigned requirements as appropriate. As the project matures there may be situations in which requirements must change or be altered in some way. The project team must follow the established change control process in order to propose any changes to requirements and receive approval from the change control board. Ongoing requirements management also includes receiving approval of all requirements by all vested parties as part of project closure.

Configuration Management

In order to effectively manage a project, communication must be managed and controlled. Additionally, every effort must be taken to identify requirements thoroughly during project initiation and planning. However, there are often situations which require changes to a project or its requirements. In these situations it is important to utilize configuration management to consider proposed changes, establish a process to review and approve any proposed changes, and to implement and communicate these changes to the stakeholders. As stated in the PMBOK®: “Configuration management activities such as how changes to the product, service or result requirements will be initiated, how impacts will be analyzed, how they will be traced, tracked, and reported, as well as the authorization levels required to approve these changes.” Use this section of the Requirements Management Plan template to outline your configuration management process.

For the BrightStar Project, the Requirements Management Plan will utilize the configuration management activities outlined in the Configuration Management Plan. Key items include documentation/version control and change control:

Documentation and Version Control: All project documentation will be loaded into the Configuration Management Database (CMDB) as the central repository for the BrightStar Project. Appropriate permissions will be granted to the project team for editing and revising documentation. Any proposed changes to project requirements must be reviewed by the Configuration Control Board (CCB) and have written approval by the project sponsor before any documentation changes are made. Once these proposed changes are approved and the documentation is edited, the project manager will be responsible for communicating the change to all project stakeholders.

Change Control: Any proposed changes in project requirements must be carefully considered before approval and implementation. Such changes are likely to impact project scope, time, and/or cost, perhaps significantly. Any proposed changes to project requirements will be reviewed by the CCB. The role of the CCB is to determine the impact of the proposed change on the project, seek clarification on proposed change, and ensure any approved changes are added to the CMDB. The project sponsor, who also sits on the CCB, is responsible for approving any changes in project scope, time, or cost and is an integral part of the change review and approval process.

Requirements Prioritization Process

Prioritizing requirements is an important part of requirements management. Developers or service providers do not always know what requirements are most important to a customer. Conversely, customers do not always understand the scope, time, and cost impacts of their requirements on a project. Collaboration among all stakeholders is a necessary part of establishing project requirement priorities. If cuts need to be made to scope, time, or cost, this list of priorities will provide a better understanding of where a project can or cannot focus to deal with the constraints placed upon it. One way to do this is to group requirements into priority categories such as high, medium, and low priority based upon the importance of the requirement. There may be hundreds of requirements in a large project so this type of categorically-based method would be helpful. NOTE: there are many methods by which priorities are determined and these should be explored based on the size and complexity of the project.

The BrightStar project manager will facilitate stakeholder meetings in order to establish priorities for all project requirements. This project will use a three-level scale in order to prioritize requirements. The chart below illustrates these levels and defines how requirements will be grouped:

Product Metrics

Product metrics are an important part of determining a project’s success. There must be some quantitative characteristics to measure against in order to gauge the progress and success of the project. Product metrics are usually technical in nature though not always. Such metrics may consist of performance, quality, or cost specifications. Metrics may also be based on the product requirements identified for a given project.

Product metrics for the BrightStar project will be based on cost, quality, and performance requirements as outlined in the project charter. In order to achieve project success, the BrightStar product must meet or exceed all established metrics.

Cost:

• BrightStar cable product must cost less then $6,000 per linear kilometer for fiber counts of 12-72 fibers; less than $8,000 per linear kilometer for fiber counts of 84-180 fibers; less than $10,000 per linear kilometer for fiber counts of 192-288 fibers.

Quality:

• BrightStar cable product must achieve less than 10% attenuation in temperature cycle testing
• BrightStar cable product must achieve a minimum bending radius of less than 10 feet
• BrightStar cable product must weigh less than 1.0 lb per linear foot for fiber counts of 12-180 fibers and less than 2.0 lbs for fiber counts greater than 180

Performance:

• BrightStar cable must achieve an average attenuation of less than 0.1% per linear kilometer at 1550nm
• BrightStar cable must achieve an average attenuation of less than 0.5% per linear kilometer at 1610nm
• BrightStar cable must have a diameter of less than 1.0” for 12-72 fiber cables; less than 1.5” for 84-180 fiber cables; and less than 2.0” for 192-288 fiber cables

Requirements Traceability Matrix

The Requirements Management Plan should include a requirements traceability matrix. The requirements traceability matrix is a tool to ensure that deliverables meet the requirements of the project. The matrix provides a thread from the established and agreed upon project requirements, through the project’s various phases, and through to completion/implementation. This ensures that the product specifications and features satisfy the requirements on which they were based. Any interim project tasks associated with the requirements should be included. An example of this are test cases which will utilize metrics, based on the product requirements, which are linked to the project charter and design document. This allows a team member or stakeholder to follow a requirement through all tasks required for its completion.

Below is the requirements traceability matrix for the BrightStar project. The purpose of the requirements traceability matrix is to ensure all product requirements are completed in accordance with the project charter. This matrix provides a thread from all product requirements through design, testing, and user acceptance. Design document and charter references are contained in the BrightStar Project Configuration Management Plan. Any approved changes in project scope or requirements will result in changes to the traceability matrix below. Based on impacts of the approved changes, the Project Manager will make the necessary changes to the matrix and communicate those changes to all project stakeholders.