Requirements Management Planning: A Guide for Product Teams

Jama Software


Requirements Management Plan 

Product success depends upon the successful project management of the product’s requirements. Effective requirements management, in turn, requires thoughtful planning. 

 A requirements management plan describes how you will gather, analyze, document and manage the requirements of the project. It should describe how you intend to gather the high-level project and product requirements from project stakeholders, industry standards and governmental regulations, as well as the more detailed product requirements you will collect and develop over the project lifecycle. Your requirements management plan should also specify how you will manage changes to requirements after they have been approved. 

Your requirements management plan is a tool for communication. It provides all your project’s stakeholders with a common understanding of how the product’s requirements will be managed to ensure success. 

In this article, we’ll describe the requirements management planning and the recommended components of a requirements management plan. 

What is Requirements Management Planning 

Requirements Management Planning is the process of documenting how you will gather, analyze, document and manage the requirements of a project, manage changes to requirements once they have been approved, manage the configuration of the requirements documentation, and track verification of the project’s requirements. 

Components of a requirements management plan 

A solid requirements management plan will be composed of several components. Here, we’ll describe our recommended sections. Depending upon your industry and organization, not all of these sections may be applicable to your situation. 

Project overview 

Briefly describe the purpose of the project. Explain the need the product will fill for the customer or target market and how its development will benefit your company. Mention important goals for the project and any notable constraints that may have been imposed upon it.  

Roles and responsibilities 

This section lists the roles of those who will be involved with managing the requirements through the rest of the project lifecycle, along with the responsibilities of each role. 

Typical roles include: 

  • Project manager 
  • Lead analyst / lead requirements engineer 
  • Analyst / requirements engineer 
  • Stakeholder 

The project manager typically has overall responsibility for managing the scope of the requirements for the project.  

The lead analyst / lead requirements engineer may also be a lead systems engineer or lead developer. This role is generally given overall responsibility for requirements development and integrity.  

Analysts and requirements engineers assist the lead analyst / lead requirements engineer and are typically tasked with following the specified procedures for managing the subset of the project’s requirements for which they have been given responsibility. 

Other project stakeholders who provide input to the requirements base are generally given responsibility for reviewing the requirements at specified milestones. 

Tools 

In this section of your plan, describe any automated tools that will be used to manage the requirements. Provide a brief overview of how those tools will be used during the requirements management process, and reference any documented procedures governing the use of the tools.  

More detailed descriptions of how the tools shall be used in the various steps of the process should be provided in the sections of the plan that describe those steps. 

Requirements gathering 

Describe the process that you will use to elicit, analyze and document the requirements. Then, describe the requirements gathering techniques you will use and with what groups you will use them. 


RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams


Categorization and assignment 

Here, you will describe your process and procedures for dealing with various types of requirements. 

Describe how requirements will be categorized within your requirements management system. Typical categories include:  

  • Functional 
  • Non-functional 
  • Internal 
  • External 
  • Regulatory 
  • Performance 
  • Quality 
  • Training 
  • Support 
  • Maintenance 

 The difference between functional and non-functional requirements—what the product must do versus any constraints on how the product must be constructed—normally impacts how the requirement will be verified. For more information on non-functional requirements and their impact on product development, click here. 

Internal requirements will generally be driven by the needs of stakeholders within your organization. External requirements will include those driven by customers, market forces, government regulations industry standards, etc. 

A requirement’s category will dictate, in part, how it is assigned for development, implementation and verification. Your plan should describe your policies and procedures for assigning requirements to subsystems or components or by work breakdown structure (WBS). 

Prioritization 

Companies will prioritize the fulfillment of some requirements over others. Reasons for high prioritization may include market demand, regulatory compliance, contractual obligation, or internal stakeholder need. 

That’s why it’s important to plan and document how you will prioritize requirements for development and release. Keep in mind that you will likely describe in detail your rules for prioritizing requirements in your Product Requirements Document. 

Traceability 

Describe your overall process for tracing requirements throughout the product lifecycle: from gathering, through decomposition, development, implementation and verification. Mention the tools to be used to accomplish the traceability process. 

Requirements and their attributes need to be tracked throughout the project lifecycle to ensure fulfillment. Attributes to be tracked may include: 

  • Name
  • Type 
  • Project unique identifier 
  • Source (stakeholder, document, parent requirement, etc.) 
  • Children (lower level requirements derived from the requirement) 
  • Assigned element of the WBS where it will be addressed 
  • Verification method (if your project requires a variety of methods) 
  • Verification reference (to the procedure that will verify the requirement) 
  • Compliance reference (applicable regulations/paragraphs) 

RELATED POST: What Is Requirements Traceability and Why Does It Matter for Product Teams


Change management 

As a project evolves, requirements will need to be added or modified. Therefore, your requirements management plan should include a section that describes your policies and procedures for change control. 

Change management (or change control) generally involves documenting each proposed requirements change in a change request. Once written, the change request is analyzed by affected stakeholders for any possible impact on project objectives or other requirements. The change request then goes before a change control board where it is either accepted (to be implemented) or rejected (and either revised or dropped). Your procedures for change control (raising, reviewing, tracking and approving change requests) should be described or referenced in this section. 

Configuration management 

Describe how you will monitor and control changes to your requirements documentation. Configuration management deals primarily with how documents will be revised and released during a project. 

For many projects, depending upon your organization, this section may be combined with the Change Management section just described. For very large projects, you may want a separate Configuration Management section. If you have a separate Configuration Management Plan you’ll probably want to reference it and keep this section brief. 

Verification 

Finally, describe the methods and metrics you will use to verify requirements. Specify how their achievement will be measured, tested, etc.  

If you use a variety of verification methods to verify different types of requirements, you will likely want to give a brief explanation of the procedures for each and how each type of verification is documented.  

Benefits of requirements management planning 

As mentioned earlier, your requirements management plan is a tool for communication. It helps your analysts, systems engineers and developers get up to speed and stay on the same page when it comes to managing your project’s requirements. Plus, it gives higher-level stakeholders a warm, fuzzy feeling that your product’s requirements will be properly managed to ensure your product’s success. 

For more in-depth information… 

Requirements management and requirements management planning can be greatly simplified through the use of a state-of-the-art requirements management tool like Jama Connect. For a deeper dive, visit our Essential Guide to Requirements Management

requirements-management-hub



Previous Flipbook
Jama Connect® Companion MBSE Quickstart Guide
Jama Connect® Companion MBSE Quickstart Guide

In this quickstart guide, we describe the building blocks within the Companion MBSE framework and show you ...

Next Article
A Step-by-Step Guide to the Requirements Gathering Process
A Step-by-Step Guide to the Requirements Gathering Process

In the quest for a successful product development process, there are any number of steps that could go wron...