At the heart of every successful project lies a clear understanding of what needs to be achieved.

Defining the requirements at the start of a project is absolutely crucial. When requirements are well understood and properly managed, projects are far more likely to succeed. A well-executed requirement management process sets the foundation for clarity, alignment and delivery, making sure everyone knows what needs to be achieved and how to get there.

Requirements management involves gathering, analysing and justifying the wants and needs of the users to ensure that the project deliverables meet their needs and expectations. The users are going to use the output of the project – whether a new mobile app or a business transformation – and generate the benefits. When requirements are unclear or incomplete, the consequences can be very damaging and result in:

Rework and Delays – Misunderstood or missing requirements lead to costly changes and wasted effort.

Frustration and Disappointment​ – Users feel unheard or misrepresented; teams lose morale due to unclear direction and shifting goals.​

Project Failure​ – Budget overruns and missed deadlines erode confidence.​ If the gap between expectations and delivery becomes too wide, sponsors may pull the plug.​

Poor Customer Experiences​ – A service or product that misses the mark results in low adoption and negative feedback. Let’s walk through the requirements management process in a bit more detail.

Damaged Reputation – The delivery team or organisation may be seen as unreliable and future opportunities may be jeopardised due to lack of trust.

Gather

Requirements start at a high level during the concept phase and evolve through planning and deployment as the solution becomes clearer. Think of requirements gathering as detective work, the requirements are already there but need to be uncovered by asking lots questions, listening closely, and playing back. What users want isn’t always what they need or can afford, so it’s key to distinguish between ‘must-haves’ and ‘would-like-to-haves’.

Requirements can be split into functional requirements and non-functional requirements.

• Functional: What the solution must do e.g. an alarm must be able to be switched off remotely.
• Non-functional: How it must perform e.g. alarm triggers must activate within 5 seconds of detecting a fault.

User stories are written to help clarify requirements:

• Who needs it
• What they need
• Why they need it

For example: “As a user, I need to reset my password, so that I can regain access.”
Each user story should focus on a single requirement and be written in plain, non-technical language so anyone can follow along.

Solutioning should be avoided at this stage. Users may suggest solutions, but they may not have the right solution in mind or may not be aware of other possible solutions. If solutions are shared by users, they should be noted down and kept for later because they might tell something about the users’ requirements. If users aren’t sure what they want, it may be possible to show examples to help them gain clarity and identify what they need or not need.

Analyse

Once gathered, the requirements need to be analysed for gaps, overlaps and conflicts. Clear analysis leads to stronger solutions and happier users.

• Gaps happen when parts of a process, like outputs, are missed. These must be identified and filled to ensure completeness.
• Overlaps occur when different user groups share similar needs and these may be streamlined with modular solutions that serve multiple groups.
• Conflicts are trickiest area to deal with. If one group’s needs clashes with another’s, resolution is essential before the solution is developed. Trying to please everyone often ends up pleasing no-one.

Justify

Each requirement needs to be reviewed and ranked in order of its importance and priority to guide smart trade-offs when time or budget is limited. A variety of useful techniques can be used to rank requirements such as the MoSCoW method, which stands for: ‘must-have, should-have, could-have and won’t- have’. The MoSCoW method helps built a picture of the essential elements and the requirements that can be traded first if needed:

Must-have:

The solution won’t work if these essential requirements are not satisfied. For example, viewing account balances in a banking app.

Should-have:

These requirements are important but not critical. Workarounds can be found. Using the banking app example again, a ‘should have’ might be personalised notifications for account activities.

Could-have:

These are nice-to-have but not essential features that enhance user experience or functionality e.g. a spending analysis dashboard for the banking app.

Won’t-have:

Satisfying these requirements is not necessary and will not be included in the current project scope. They may be revisited in future phases or projects. A ‘won’t have’ for the banking app could be integration with a third-party investment platform.

Must-haves and won’t-haves are usually clear. The challenge lies in separating should-haves from could-haves, as users’ views often differ on these.

Baseline

Once requirements are prioritised, it is time to baseline and sign off the agreed set as version 1.

This marks the formal scope of the project, there is no solution in place yet, but the intended functionality is now locked in. Baselining prevents scope creep. Any changes must go through a formal change control process. If approved, the updated output is re-baselined, and the previous version archived for audit and review. Agreeing the requirements with users sets clear expectations, reduces handover conflicts, and ensures all changes are tracked. With the baseline in place, solution exploration and development can begin.

In Agile projects, adaptability is key. If time or budget becomes tight, the ‘could-have’ and ‘should-have’ requirements may need to be sacrificed to ensure the ‘must-have’ requirements are met.

In summary, requirements management is an art and craft as well as a process. It needs ongoing attention throughout the project to ensure alignment, clarity, and delivery.

By Marielle Brouwer

By Marielle Brouwer is Sr. Business Consultant at Skewb. To speak with her about this topic in more detail, you can connect with her on LinkedIn.