Manage Requirements To Thrill Your Customers (Part 2) | by Jonathan Gibbon

In my previous article, we looked at what requirements are, why they are important, how to elicit and categorise them, and how to validate them. Here, we will focus on prioritising requirements to deliver a product that meets the true needs of the stakeholders.
 

Prioritising requirements

It’s often the case that a team will create more requirements than they can deliver, so prioritisation is required to select the most essential or valuable requirements to work on. It’s also a very useful process to separate the needs from the wants because meeting the needs of the stakeholders should be prioritised first.
 

The BABOK (Business Analysis Body of Knowledge) guide presents eight elements you can consider to prioritise requirements:

• Benefit: the advantage you gain from implementing a requirement 
• Penalty: It is the consequence of not implementing a requirement. It can refer to the loss in regulatory penalties, poor customer satisfaction or usability of the product.
• Cost: take into consideration the effort and resources needed to implement. A resource can refer to finance, manpower or even technology.
• Risk: It is the probability that the requirement might not deliver the expected value. This can be due to various reasons ranging from difficulty in understanding the requirement to implementing the requirement.
• Dependencies: requirements that cannot be satisfied unless another requirement is completed.
• Time Sensitivity: requirements that need to be delivered before a certain date.
• Stability: establish a lower priority for unstable requirements to avoid rework and wasted effort.
• Regulatory or Policy Compliance: requirements that must be implemented in order to meet regulatory or policy demands imposed on the organisation.

Having established the criteria upon which to base your prioritisation, there are a number of techniques that can be used. These include MoSCoW, the bubble sort technique, the hundred-dollar method and numerical ranking. MoSCoW is one we focus on in the Business Transformation Fellowship, and helps to prioritise requirements as:

• Must have: a mandatory requirement - without these, the product or system doesn’t work. This includes functionality, legality, safety and quality.
• Should have: high priority - should be done where possible and might be expected by the user, but the deliverable still works without it (or a workaround can be found).
• Could have: desirable but non-essential - how much of a pain point would it be for the user if this is left out?
• Won’t have: won’t be implemented but could be considered in future. It’s useful to be aware of these requirements because they can still influence the design if you are planning to add them at a later stage.

Questions like the examples below could be used to categorise and prioritise your requirements with MoSCoW. You could use this list by working down from the top.
 

Must have: 

• Is this required for the product or system to work?
• Is this a legal requirement?
• Is this a critical safety feature?

If you answer ‘yes’ to any of these questions, the requirement is a must-have.

Should have:

• Does the user expect this feature in the final product?
• If you answer ‘yes’, the requirement is a should have.

Could have:

• If this is not included, will the impact on the user be relatively minimal?
• Can this feature or function wait until near the deadline?

If you answer ‘yes’, the requirement is a could have.

Won’t have:

• Can this wait until a future iteration?

If you answer ‘yes’, the requirement is a won’t have.
 

In an agile project, ‘must haves’ are the primary focus of a Minimum Viable Product (MVP), or prototype, that is delivered to the user for testing and feedback. 

As well as helping to clarify what you will work on initially, MoSCoW can be a useful decision-making tool. For example, the different levels within MoSCoW can help you review a project that is going over budget or time. In this situation, ‘could haves’ are sacrificed first, then ‘should haves’ may be discarded if things get worse so that only the ‘must haves’ are delivered. 

By stating the ‘won’t haves’, you are also clearly managing expectations for your customers. 

As a rough rule of thumb, no more than 60% of your team’s effort should be focused on ‘must-haves’. ‘Could-haves’ typically take around 20% of the effort, with ‘should-haves’ being the difference between the two. 

Using a recognised prioritisation framework can help to remove emotion and subjectivity from the process, ensuring you focus more objectively on the real needs of the stakeholders. 

It’s worth noting that if there are changes to a project, it’s good practice to repeat your prioritisation exercise to ensure that your priorities remain up-to-date.
 

Requirements Tracking

Having prioritised your requirements, it’s useful to track them using a traceability matrix, such as in the image below (which can be extended to include things like actions for each requirement). This enables you to:

• Capture all requirements, with a thread and a unique identifier for each one
• Track them against the baseline
• Record actions, tests and changes
• Trace the deliverables from the project’s initiation through to the final implementation.
   

Requirements traceability ensures that all business needs are linked to a requirement and that each requirement is tied to an action. It helps to ensure that no requirements are missed and can be a useful tool for identifying related or dependent requirements if changes need to be made.

If changes are required - for example, customer needs or business objectives change - then a traceability matrix can be used to identify all requirements and actions that need to be reviewed and/or changed in support of this. Understanding the impact of the change on the wider system is critical, so always strive to keep thorough and up-to-date documentation!

Summary

Requirements are critical to a project’s success; if they are not accurate, your project will not be focused on the real needs of the stakeholders and may suffer from scope creep. This can result in a lot of wasted time, effort and cost, as well as unhappy customers, so it’s worth putting in the effort upfront!

Ultimately, the level of rigour in your requirements management process should ensure there’s no dispute about the outputs delivered to the client at the end of the project and should help to keep the project on track and to budget. 

How rigorous is your requirements management process?

Jonathan Gibbon is a Business Transformation Coach at Multiverse.

To practise elements of requirements management in a safe and encouraging space, join the next round of Become the Business Analyst through the Multiverse Community and apply your learning to a real-life case study!