Classic PM: Requirements

Abstract

Identifying and managing Requirements is the key to a successful project. High-quality execution of these two processes will increase the chances of successfully completing the Project within Constraints, thereby increasing customer satisfaction, reducing rework, improving the quality of Deliverables and Project Execution, and achieving improved control over Change Requests.

Influence

Failure to fully define Requirements has a detrimental effect, particularly on the project’s Cost. Below is a graph showing how much Cost changes when requirements are incompletely described:

Requirements Lifetime

Loosely saying, requirements management can be divided into several operations, which, by the way, can be performed in parallel or sequentially, synchronously or asynchronously:

1. Defining. This activity involves identifying (discovering) all possible Requirements from various sources. When compiling a requirements list, it’s important to remember to describe the Deliverables and Business Requirements, not their direct implementation. As a guide, it’s recommended to use the SMART methodology, which defines the requirements for compiling each Requirement in five points:

• Specific. Avoid ambiguous requirement descriptions (such as “ensure delivery of a large quantity of goods…” and instead “ensure delivery of 3 kg of products with article number…”). The Requirement description should provide a complete understanding of what, why, when, in what quantity, etc., is required;
• Measurable. Requirement should be described in a way that can be measured – “the information system must support the simultaneous operation of at least 1000 users with an operation waiting time of no more than 10 seconds.”;
• Agreed-to. Jargon and technical language should be avoided; Requirements should be written in accessible language. This is justified by the fact that Requirements can be read by people who are not experts in a particular field;
• Realistic. Any Requirement must be feasible, otherwise it must be waived in advance. If a Requirement is mandatory but cannot be implemented, the implementing party must waive that part of the Project, or the entire project;
• Testable. A Requirement must be testable or verifiable (and for this to be true, it must be Measurable). It’s certainly a good idea to describe the testing procedure, but if that doesn’t make sense, it’s important to at least understand it.

When identifying requirements, it is advisable for the Project Manager to constantly refer to the SMART language, i.e., having identified a new requirement from Stakeholders, it is necessary to analyze it using the SMART technique.

2. Recording. After defining and analyzing the requirement, it must be registered in the Requirements Register. This can be either a paper document or an electronic document (for example, an Excel or Word document), but the most convenient tool is a dedicated requirements management application. Whatever tool is chosen, it should:

• Grant access to Requirements to all key Stakeholders;
• Provide only the information that is required;
• Provide a sufficient level of data security;
• Allow Requirements or any other project elements to be linked;
• Be easy to use (both for viewing and adding);
• Support sorting;
• Support versioning (very important requirement).

3. Selecting. During the Project, Requirements may be expanded and expanded, and the Project Team should sort them by priority. For example, when Defects are discovered, their elimination can be added to the Requirements, while compliance with a newly Requirement can be given high priority.

4. Controlling. The Project Team must track the fulfillment of Requirements. The most effective tool for this is the Requirements Traceability Matrix, which is described in more detail when discussing the Collect Requirements process. Using this, or any other similar tool, the Project Team should track not only the fulfillment of each individual requirement, but also monitor Cost, Schedule, and Risks, and provide Stakeholders reports on each Requirement.
   Control Requirements process involves both monitoring existing Requirements and controlling the Scope of the Project and identifying new Requirements that arise. This is directly analogous to the initial identification of Requirements – the later a Requirement is identified and described as fully as possible, the easier it will be to implement and control it.

Requirements Documenting

This document is not de facto mandatory, but it is recommended. It should not include any technical specifications or wording; it should describe what Deliverables are, but from the customer’s perspective. The document’s content could be, for example, as follows:

1. General Section. This section should contain a brief description of the Project;
2. Project Purpose. Description of the Project’s purpose and why it is being implemented;
3. Stakeholders. List of key Stakeholders;
4. Terminology;
5. General Description. Includes a high-level overview of the Project;
6. Project Scope. Description of what is and is not part of the Project;
7. Risk Analysis. High-level Risk Analysis;
8. Dependencies. Brief description of the Project’s potential interactions (these could be organizations, organizational departments, government agencies, information systems, support services—anything);
9. Requirements. Description of Requirements written in SMART language. May include or reference the Requirements Traceability Matrix;
10. Notes.

Summary

To successfully manage Requirements, they must be certified with key Stakeholders and adhere to the following rules:

1. Must be written using SMART language;
2. Stored in a location accessible to key Stakeholders for tracking;
3. Sortable (prioritized).

The requirements management process itself:

1. Is the result of collaboration between business representatives and the technical Project Team;
2. Implements only Requirements approved by key Stakeholders;
3. Uses an agile approach to Change Management;
4. Uses a requirements management tool approved before the start of the Project;
5. Allows for requirements to be tracked throughout the entire Project Lifecycle;