This article looks to discuss project requirements management. Discussing a requirements management process (such as capture, analysis and prioritisation, testing). Covering the factors used in requirement management and the importance of requirements management and links to scope management and project quality management.

What is Requirements Management?

We’ve been there before: navigating a conversation with the stakeholders, discussing the main purpose of the project and refining the idea of its product, which you and your team are expected to deliver within a specific timeframe. This is what Requirements Management is all about. But what is requirements management and what is its purpose?

First, let’s discuss what a Requirement is

In software development, for example, let’s say the requirement is to increase the level of security for account access. The team is required to  create a more secure way for users to access their personal accounts, based on the stated requirement. Simply put, a requirement is a specific need, demand, or specification that needs to be satisfied.

Requirements Management: How is a requirement is determined

A requirement is identified and analysed based on several contributing sources of information, which include gathering information from the end-users, investors, operations, support, management, sales, and technical teams.

The process involves communication between internal teams and with the external stakeholders, to ensure that the requirement remains within scope and that it remains aligned to the goal of the project.

Here’s more about the different requirement types and the two main fields

There are two main requirement fields: product requirements and process requirements. Product requirements specify the properties or characteristics of a product. Process requirements specify the methodologies and flow of work that must be followed, to satisfy the requirement.

Furthermore, requirements can be broken down into the following classifications: business requirements, solution requirements, architectural requirements, user requirements, functional and non-functional requirements, and stakeholder requirements.

The Requirements Management Process

Requirements Management Process is a continuous cycle and goes on throughout the lifecycle of a product. The requirement may change over the course of the product development, depending on external and internal factors affecting the validity and functionality of the product.

To maintain order and ensure that all efforts remain within the agreed upon scope of the project, the team follows a looping process that starts with working on the requirements, communicating with stakeholders, testing, assessment, revisions and document changes. Let’s take a look at each of these steps in more detail.

Requirements Management: Capture/Investigation

This is the phase where the requirements are identified and analysed. Identifying the requirements is done by gathering the requirements from the end users, the development team, and the business itself. The objectives and the constraints are analysed and discussed by the internal teams working together in the project. At the end of this activity, a documentation stating the specifics of the project must be delivered and used as a guide to ensure that the work stays on track and prevent scope creep. Once everything is in place, the functional or non-functional requirement can then be developed.

Requirements Management: Feasibility

Here is where the amount of resources needed to run the project is determined and evaluated. This is a crucial phase for the project manager, as this will determine the validity and the profitability of the project. The goal of this activity is to get a greenlight from the stakeholders, partners, or investors. Once the project is given an approval, production begins.  

Requirements Management: Design

This is where the requirements document becomes the most important reference tool. During the design phase, the result of each work stage is compared side by side with the requirements stated in the requirements document, to ensure that the results are shaping up the way it’s expected to and that the work remains within scope. There are instances where changes must be made mid-stream, which means departing from the original plan. In such cases, the requirements document becomes a very important reference and tool to ensure that any sort of change doesn’t go too far from the original work parameters and that the entire project remains within scope.

Requirements Management: Construction and Testing

A sandbox or a prototype is created during this stage, and either of these undergo iterative testing to ensure that it actually works as intended and that it actually meets the requirements. A project is usually divided into phases, and each phase is further broken down into different stages.

As the product goes through the different stages, there are certain testing procedures set at crucial points in the build, to ensure that it is ready to move on to the next stage. Upon completion of a stage, there are other several tests performed to ensure that the product is working as expected and that the project is ready to move on to the next phase, until it reaches the delivery phase.


This phase is where the product is handed off to the client and is good to go for use. While this phase may sound like the end of the lifecycle, it actually is the part of the process where post-release and product performance feedback is gathered, documented, and discussed by the team to identify the next requirement/s for next releases and updates.

Revisions/Documentation Changes

This activity occurs throughout all the project stages but more work is done towards the final stages of the last phase of a project. Changes made mid-stream, change requests after release, as well as any additional information including implementation, quality assurance, feedback, and results from testing are all document. These documents are used as basis for future similar projects, for new releases, upgrades, and updates.

59 Seconds Training

Making the Project a Success

Requirements management is a way to ensure that everything stays within budget and within the scope of work. Aside from managing end-to-end traceability, requirements management also provides the developers and other stakeholders the necessary information to make accurate and calculated decisions, when it comes to making changes along the way. Changes mid-stream usually triggers a scope creep and a deviation of work from the original set of deliverables which were derived from the requirement/s established at the beginning of the project. Thus, all the work involving documentation will serve useful in preventing scope creep from happening and the most effective tool to make sure everything stays on the path it’s supposed to take, even with the changes implemented along the way.

While it may sound like the whole management activity centers on the completion of tasks, it actually involves a tremendous amount of communication among the stakeholders, external customers, and most importantly the development team. In order to successfully satisfy a requirement, everyone participating in the project must be in agreement and are all moving to the same direction.

Benefits of Requirements Management

According to studies, there are plenty of organisations that have observed positive changes and huge improvements in their work strategy overtime, especially in software development, following a requirements management process.

As the management process goes through continuous refinement, organisational strategy and work  processes improve along with it, as well. All aspects of the work become more efficient, which improves the quality of the product, the amount of time it takes to deliver it, as well as the overall performance of the product. The costs and risks involved in the project are also reduced, which leads to a more cost-effective, high-quality, completely secure and stable product that benefits the users, the business, and the people working to deliver the product.

Continue Reading —>

Section 11: Development and Estimating

Translate »