Requirements Management Plan

Overview of the Requirements Management Plan

[This is a summary of the information below designed to meet the needs of a casual reader.]

Purpose of the Requirements Management Plan

[The purpose of most requirements management plans – that can be adopted here for your own customization – is to elicit, write and validate requirements so customers’ needs are met and developers have the necessary information to proceed to design.]

Scope of the Requirements Activity at this Time

[Reference the business requirements in the charter. If the project is scheduled in phases or according to releases, note only those business requirements that apply to this phase or release.]

Process

[Reference the requirements methodology from your organization if you have one, and the more detailed sample process shown in the flowchart below that also references the roles and rules/procedures for this requirements activity.]

Roles and Responsibilities

[Describe who will be involved in the requirements gathering process. Insure that the participants have decision making authority. What roles and teams are required? What is their role of the vendor, if one has been retained? Typical roles are Sponsor, Business Owner, Business Analyst, End User/Customer and Project Manager. These roles are referenced in the sample process shown below.]

Rules/Procedures

[Describe what rules or procedures the team must follow when logging, managing and assessing requirements. Should all requirements be submitted to the project manager? What are the points of approval? Who decides what’s in and what’s out. What mechanism must be used to log requirements? Will there be monetary or time thresholds that trigger certain levels of review or escalation or clarification from customers (if this, then that)? Rules can be associated with steps in the requirements process using annotation, such as those in the sample process below.]

Prioritizing and Tracking Requirements (Attributes)

[Some alternatives: Criticality (H/M/L); Stability (Volatile, Neutral, Unlikely to Change); Level of Effort (1-3, 4-7, 8-10 weeks or months); Impact (H/M/L); Target Release Deployment (1, 2, 3, 4); Dependency – Number requirements and identify relationships]

[Describe the attributes you will assign to each requirement that will enable you to sort requirements according to each attribute. Typical attributes will include Status (approved, not approved) and Criticality (very important, somewhat important).]

Requirements Management Tools

[Describe what tools will be used to log requirements. Will MS Word or Excel be used? Will a database such as MS Access or IBM RequisitePro be used? Where will the logging mechanism be stored? How will version control be handled? Use the Requirements Matrix for developing your own tracking tool.]

Schedule

[Be sure to update the existing Work Breakdown Structure and schedule with any additional tasks or more time for already planned tasks. A high level schedule can be inserted here for informational purposes.]