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

Have you ever committed considerable time and resources to deliver a product that you felt was fantastic, only for your client to be disappointed? Or maybe you’ve been the disappointed client, receiving something that didn’t meet your needs. If so, there’s a good chance the reason for this is linked to requirements.

There are numerous stages in the lifecycle of a business transformation, but managing requirements is one of the most crucial. So what’s it all about?

What are ‘requirements’?

Requirements are the wants and needs of the stakeholders and must be clearly defined through acceptance criteria. Fundamentally, they detail the behaviour, features and properties of the product or system you are creating. Requirements must be clear, unambiguous, and expressed as simply as possible so that they are understood by all stakeholders.

Why are requirements important?

Accurate requirements are critical because they ensure that everyone understands - and is in agreement about - what will be produced as an end product (e.g. at the end of a project or a sprint). They should be created as a result of all stakeholders having had the opportunity to input their ideas and needs, and they help to manage budget, resources, quality and risk within a project.

What is “requirements management”?

Requirements management is the process of capturing, organising, validating and prioritising stakeholders’ wants and needs. These ideas can then be turned into an action plan to deliver a future state that meets the needs of the user and your business.

An important thing to note is that requirements management is an ongoing process throughout the lifecycle of a project. This is particularly true in agile projects, where requirements are continually refined as stakeholders gain greater clarity on their needs through the testing cycles. To confidently deliver a successful change, it’s important to consistently return to requirements to ensure that you understand exactly what the stakeholders want and need, and create a change or product that meets this.

How do you manage requirements?

First of all, you need to gather (or ‘elicit’) requirements from stakeholders. You can do this through a variety of investigative techniques, including 1:1 interviews, workshops, surveys, and document analysis. Of course, it’s vital to identify all relevant stakeholders and ensure they have been consulted in this process. It’s also crucial that you understand the real need of the stakeholder, and not just record a solution (or ‘want’) that the stakeholder communicates. 

After collecting the requirements, you can analyse and categorise them. Categorising requirements could be done by level, as follows:

• Level 1: Business requirements
  • The high-level objectives of the business requesting the product (opportunities they want to realise or problems they want to solve). Examples could be increased revenue or improved customer service.
• Level 2: User requirements
  • Outlines the goals and objectives the user will be able to achieve through the new product or system, and defines the high-level functionality the product or system requires in order to meet the needs of the user (the tasks that users must be able to perform).
• Level 3: System requirements
  • The specific characteristics a product must have in order to meet the needs of the stakeholders and the business itself. They can be split as follows:
    • Functional requirements: specific actions the system must perform, i.e. what the product must do. These can often be linked to specific conditions (X happens when Y is done). Functional requirements are mandatory requirements: the system will not work without them.
    • Non-functional requirements: the general properties of the system, or how the product should perform. If these are not met, it does not impact the core functionality of the product. 

The detail for each level of requirements is illustrated quite nicely in this diagram, although for the system requirements, I would substitute ‘user goals’ with ‘non-functional requirements’.

The table below offers a further breakdown of functional vs non-functional requirements. It’s useful to remember that functional requirements are typically defined by the user, whereas non-functional requirements are usually defined by the developers.

Example:

• Business requirement: increase revenue by widening the customer base.
• User requirement: be able to subscribe to a newsletter that delivers regular news and offers via email.
• Functional requirements (not all-encompassing):
  • Have a sign-up form on a webpage for users to input their email addresses and subscribe to the newsletter.
  • Send a welcome email when a customer subscribes.
• Non-functional requirements:
  • The sign-up form should appear in a pop-up within 10 seconds of the user landing on the homepage.
  • The welcome email should be delivered within 30 seconds of subscribing.

Validating Requirements

It’s also important to identify and resolve conflicting requirements, remove any duplication, and validate and prioritise your requirements. This can be done through conversations with stakeholders, such as in 1:1 interviews or workshops, and ensures that your understanding of the requirements is confirmed and agreed upon by all parties. This includes agreeing on the terminology used to ensure everyone has a shared and common understanding of specific terms. 

Requirements validation is achieved when all requirements are agreed upon and signed off by key stakeholders. Some steps for validation include:

• Identifying assumptions in requirements and reviewing these with stakeholders. 
• Defining measurement criteria. Agree on how the benefit of the requirements (i.e. the success of your solution) will be measured once it is delivered.
• Identify whether the requirements are aligned with the project scope. Here, a Product Owner will typically play a key part in ensuring that requirements are always checked against business needs. They will also advise of the acceptance criteria necessary to achieve this. Acceptance criteria are the agreed requirements that must be met in order for the product to be signed off by the user/client.

At this stage, a requirements baseline can be established which forms an agreed set of criteria that, when delivered, should achieve the objectives of the project. This requirements baseline may outline the schedule, cost, and scope of each requirement, and can be used to measure progress. It can be established for a project as a whole, or in agile it may be for an incremental product release.

Of course, change is inevitable in agile projects. Therefore, being able to refer back to the baseline will be an important part of keeping the project on track. The baseline should also be updated when changes are agreed upon. 

Now that we have an understanding of what requirements are, why they are important, and how to begin our requirements management process, in part 2 we’ll take a look at how to prioritise and track requirements to a successful conclusion that will thrill your customers.  

Jonathan Gibbon is a Business Transformation Coach at Multiverse.