| Print | Back | Close |

Managing Stakeholder Requirements

Managing Stakeholder Requirements

In projects, misunderstandings like the one that resulted in the loss of a spacecraft are more common than you might think. Often this happens because requirements aren't clear. It's easy to misinterpret exactly what an important client wants. And it's common for different people on a project team to understand specifications a little differently. This is what makes how you manage collecting project requirements so important. Stakeholders and all the people working on a project need to have the same understanding of what's required. If they don't, it can spell disaster.

For a project to meet agreed requirements, there must be a way to assess whether the requirements are being met. So each requirement has to be measurable. It must answer questions like "how much," "how many," and "how well." It must also be testable so there's an objective way to verify it.

As well as being measurable and testable, a requirement must be traceable – forward and back. You must be able to track it as work proceeds so you know when it has been met. And at the end of a project, you must also be able to look back and identify exactly how a requirement was met, or why it wasn't.

There are two items that make a requirement traceable:

1. unique identifier – Giving each requirement a unique identifier that won't change throughout a project ensures you can track it, even if circumstances change and it's canceled.
2. tracking system – You use a tracking system to document and monitor progress and any changes affecting requirements. The system identifies each requirement, its source, priority, and version, and its current status – such as active, canceled, deferred, or approved. It might also record attributes like the stability of a requirement, details of its complexity, and the criteria that will be used to accept it has been met.

Collect Requirements outputs

The Collect Requirements process has two main outputs. These are the requirements documentation, and a requirements traceability matrix.

The requirements documentation is a direct result of the group creativity techniques you used to collect and prioritize project requirements from stakeholders. It lists each agreed requirement and its attributes. This gives a baseline you can use to monitor and control a project throughout its life cycle.

The level of detail in the requirements documentation will differ for different projects. But the documentation should do four things.

1. organize requirements by stakeholder and priority – Requirements should be grouped by the stakeholders or stakeholder categories they come from, and based on their priority. This helps ensure you can trace requirements easily and guide project work based on which ones are the most important.
2. describe what objectives requirements meet – It's a good idea to document the business need or broad project objective that a requirement satisfies. This ensures that stakeholders and the project team know what overriding objective a requirement is there to meet.
3. classify requirements by type – A requirement or its components can be functional, nonfunctional, or quality-related. In other words, it relates to how a product or service must function, to features that don't affect its underlying operation, or to performance standards it must satisfy. Identifying the broad type of each requirement helps you determine the aspects of project work that is needed to meet it.
4. identify assumptions and constraints – It's important to document any assumptions and constraints on which a requirement is based. For instance, a requirement to assemble a product by a specified date might depend on a customer supplying the product components on time.

The other output of the Collect Requirements process is a requirements traceability matrix. This is a table that assigns each requirement a unique identifier, and lists its status. It also lets you relate each requirement back to broader objectives and forward to the more detailed requirements phases must meet.

The requirements traceability matrix has three main purposes:

1. it ensures each requirement adds value to the project by linking it back to the business need or objective it helps satisfy
2. it tracks requirements, including their status, throughout the project, and
3. it provides a structure for managing changes to the scope of a project so these changes don't result in requirements not being met

So the requirements traceability matrix lets you check how far a product or service has come in meeting each requirement, at any point in a project. It's also what you use to map user requirements to project scope and to product design, development, and testing. The matrix may also include a summary of the details of each requirement from the requirements documentation, so these can be easily referenced.

The outputs of the Collect Requirements process are the requirements documentation and requirements traceability matrix.

The requirements documentation identifies each requirement and its attributes. The requirements traceability matrix is a tool you use to track requirements throughout a project.