A guide to requirements engineering

Your project needs requirements. Here’s how to approach them.

Requirements engineering is a team effort — image by DALL-E

Introduction

Every project needs requirements. No exceptions.

Without requirements, a project is just a bunch of people standing around not knowing what to do, and making up what to work on. Which, come to think of it, actually describes several projects I’ve been involved in.

But what are requirements?

“Requirements are the wants and needs of stakeholders clearly defined with acceptance criteria” — Association for Project Management (APM)

Requirements engineering is the framework for working through the whole requirements process, and it’s made up of five distinct phases/stages:

1. Elicitation — sourcing the wants and needs of users and stakeholders.
2. Analysis — ensuring your requirements are comprehensive, viable, prioritised and consistent.
3. Documentation — recording your requirements in a neat, ordered package ready to communicate.
4. Validation — ensuring the requirements are actually what users and stakeholders want/need, and accurately represent the solution you’re building.
5. Management — maintaining and controlling the requirements, especially any changes.

Let’s take a look at these requirements engineering stages in order…

1. Requirements elicitation

Project managers sometimes talk about requirement ‘capture’, as if requirements are users’ dreams floating about in the air waiting to be caught with a net.

Requirements aren’t waiting to be captured — Image by DALL-E

It’s better to refer to this stage as requirements elicitation.

The word ‘elicitation’ emphasises how project requirements often need to be actively drawn out rather than simply documented.

Elicitation methods

There are lots of ways to elicit requirements, including:

• Brainstorming — promoting creative solutions to problems with ideas first generated and then evaluated and selected
• Card sorting — to understand users’ mental models for how information should be labelled and organised within a system
• Document analysis — reviewing existing documentation to acquire explicit knowledge such as customer demographics or business objectives
• Focus groups — where a small number of people (5–10) freely discuss potentially useful features
• Interviews — meeting users and stakeholders one-to-one to learn their goals, frustrations, wants and needs
• Observation — understanding existing tasks and processes by viewing users going about their work
• Prototyping — designing early mock-ups of products to test and validate with users
• Surveys — gathering quantitative data to analyse from questionnaires
• User personas — creating composite profiles to help build empathy and design for specific needs

Remember: Eliciting requirements means interpreting the genuine needs of users and stakeholders from various research methods. It’s not simply about making a list of things people ask for.

Most elicitation methods can be considered part of the ‘Understand’ phase of design thinking, where UX/product designers seek to empathise with users and what they need (see below).

Design thinking — image by Nielsen Norman Group

2. Requirements analysis

Ok, so you’ve sourced a bunch of requirements for your amazing new product. Now what?

Well, following elicitation you need to do some analysis.

Requirements need to be analysed to ensure they’re comprehensive, viable, prioritised and consistent.

This is a critical phase of projects. Why?

About 80% of project errors are introduced during requirements analysis, yet less than 20% of project time is spent on this stage.

Obviously we all want to reduce errors, and avoid building products that people don’t find useful or desirable.

Here are some good practice requirements analysis steps you should cover to minimise errors at this stage…

Categorisation

Categorisation is an approach whereby requirements are labelled as either:

• Functional — what the system will do; the behaviour of the product including actions, processes and interactions.
• Non-functional — how the system will work, with sub-categories including accessibility, interoperability, performance, reliability, scalability and security.

As software systems need to cover functional and non-functional purposes, categorisation can help ensure the requirement set is comprehensive.

Prioritisation

Prioritisation is a method to sort the most essential requirements, with MoSCoW being a commonly used technique. In this system, requirements are categorised as either:

• Must have — it’s essential and the product can’t launch without it
• Should have — it’s not critical, but should be included
• Could have —it’s a ‘nice to have’, and you could live without it
• Won’t have — it might have merit, but won’t be included for now (perhaps due to time or cost constraints)

Typically, project teams will sort requirement priorities using cards and sticky notes, or online tools deisgned to emulate that experience. The outcome will be clear, organised groupings of requirements (see below).

MoSCoW prioritisation — diagram by author

It’s important at this stage to separate a genuine must-have requirement from a feature someone (probably a stakeholder) just really, really wants.

Filtering

Filtering is a process to help ensure requirements avoid common problems such as inconsistency, duplication and lack of detail, clarity or relevance to the project.

Checking through and filtering the requirements helps to ensure that they’re aligned with the following characteristics of high-quality project requirements:

• complete
• consistent
• correct
• feasible
• measurable
• precise
• traceable
• unambiguous

3. Requirements documentation

There’s still a lot to do before building — image by DALL-E

Right, you’ve elicited your requirements and analysed them. You’re feeling pretty good about things.

What do you need to do next?

The next stage of requirements engineering is to document the requirements in written form.

The purpose of this documenting phase is to communicate the requirements with stakeholders and developers.

Good practice requirements documentation will typically include:

• an introduction and some background to the project
• an overview of relevant models (such as functional or data)
• a glossary
• the requirements themselves (obviously!)

It’s important and helpful for everyone that each individual requirement includes enough detail, containing all necessary elements (see below).

Elements of a project requirement — image by the author

There are multiple ways to document individual requirements, such as mind maps and business process models. But a common method is to use user stories.

User stories

A user story is a project requirement framed from the perspective of a user, explaining what they need and why they need it. The basic format looks like this example focusing on accessibility:

• As a… blind person
• I need… the UK government website to be compatible with my screen reader
• So that… I’m not excluded from accessing public services online

This story format is a user-centred approach that focuses on meeting a need, not prescribing a specification. This accessibility example is more empathetic than simply saying a product needs to comply with the Web Content Accessibility Guidelines (Level AA).

Despite the theoretical benefits, it should be noted that many user stories have been found to be poorly written and defective in practice. This has led to the proposal of a framework that defines 13 criteria for user story quality:

User Story Quality (Lucassen et al, 2016 ) — image by the author

4. Requirements validation

We’re making progress, but there’s still a bit more to do.

Once your requirements are documented, the next step is to validate that they’re well defined.

It’s important to establish that the requirements describe what stakeholders and users actually need, and are an accurate representation of the solution.

Validation is carried out by customers, end users, domain experts, software engineers, project managers and other stakeholders.

You can use different techniques to validate requirements, including:

• Review — checking requirements for errors, conflicts and other issues, typically in a meeting setting.
• Prototype — designing mock-ups of the product or system to test with users and see if the requirement is validated (meets the user’s needs).
• Test case — writing tests for the requirement, with the idea being if this is hard or impossible to do the requirement may not be possible and should be reconsidered.

Throughout this phase the requirements documentation, as well as organisational standards and knowledge, are used to ensure requirements are:

• valid (describe what’s needed)
• consistent (no conflicts)
• complete (everything is included)
• realistic (technically and financially feasible)
• verifiable (can be tested)

Validation adds time and potentially cost to a project, but can improve the quality of the requirements leading to better solutions.

Validation supports supports the model of UX design — Image by author

5. Requirements management

Here we go: the final phase.

What’s requirements ‘management’ all about?

This stage is concerned with keeping track of changes to the requirements, ensuring alterations meet business and stakeholder needs.

There are a few concepts to be aware of in this stage…

Traceability

Traceability is a critical quality characteristic of requirements management.

It should be possible to trace a requirement back to its origins and forward to its resolution.

Requirements traceability — image by author

This matters primarily because if a requirement needs to be changed, you’ll want to know where it came from in the first place.

It should also be possible to trace requirements upwards to their alignment with business strategy, objectives and values:

Requirements alignment — image by author

Essentially, this means requirements should be able to justify how they align to the overall goals of the business.

Linear versus iterative

It’s worth noting at this point that different project management methodologies have different approaches to requirements management.

• In traditional linear project life cycles (such as waterfall), requirements are managed in a very tightly controlled manner.
• However, in iterative project life cycles (such as agile), requirements management is much more flexible and less rigidly controlled.

Both these approaches have their pros and cons, and the correct approach depends on the context of your project.

It’s important to match the requirements management method to the right project management methodology.

You can read more about linear versus iterative project life cycles, and find out which method — and therefore which requirements management approach — might best suit your project.

Configuration management

Configuration management is important in both linear and iterative project approaches. This is all about the maintenance, controlled change and quality control in the scope of requirements.

The iterative approach is preferred by many digital UX professionals, due to its speed, simplicity and alignment with design thinking. In agile, for example, product owners decide on changes to requirements (such as re-prioritising the backlog) as part of a sprint retrospective / planning session.

Manage requirements during construction — image by DALL-E

Summary

So there you have it: five requirements engineering phases, all of which are interdependent on one or more of the other stages:

Requirements engineering (Paul and Cadle, 2020) — image by author

While there might be a lot of detail included in this article, this is actually a pretty basic guide to requirements engineering.

Entire books can, and have, been filled with theory, models and frameworks of how to do this stuff.

But hopefully this is a useful overview, and one you could put straight into practice — especially with smaller, lower risk digital projects.

Sources

Association for Project Management (2020) APM body of knowledge, 7th edn. Buckinghamshire: APM.

Gervasi, V., Gacitua, R., Rouncefield, M., Sawyer, P. Kof, L. Ma, L. Piwek, P. de Roeck, A. Willis, A. Yang, H. and Nuseibeh, B. (2013). ‘Unpacking tacit knowledge for requirements engineering’, Managing requirements knowledge. 1st edn. Springer, Berlin: Heidelberg.

Marsh, S. (2018) User research: a practical guide to designing better products and services. 1st edn. London: Kogan Page, Limited.

Paul, D., and Cadle, J. (2020) Business analysis, 4th edn. Swindon, U.K: BCS Learning & Development Limited.

Project Management Institute (2017) A guide to the project management body of knowledge (PMBOK® Guide), 6th edn.

About the author

Andrew Tipp is a lead content designer and digital UX professional. He works in local government for Suffolk County Council, where he manages a content design team. You can follow him on Medium and connect on LinkedIn.