Requirements Definition

Agreeing what to build

Ask a builder for “a nice kitchen” and you’ll get their idea of nice. Ask for “a 4-metre worktop, a double sink under the window, and space for a dishwasher” and you’ll get what you actually want. Requirements are that precise list, for a system.

Most failed projects trace back to requirements that were vague, incomplete, or never properly agreed.

Four kinds of requirement

Functional, non-functional, security and control, and compliance requirements.

Type	Describes	Examples
Functional	What the system must do	Calculate premiums; route invoices for approval; produce monthly statements
Non-functional	How well it must do it	Responds in under 2 seconds; 99.9% available; supports 5,000 users
Security and control	How data and processing are protected	Role-based access, segregation of duties, input validation, audit trails, encryption
Regulatory and compliance	Legal obligations	Data retention, privacy, accessibility, sector rules
Interface	How it talks to other systems	File formats, APIs, timing

Users naturally focus on functionality, so security and control requirements are easily forgotten. The auditor checks they’re explicitly captured, because adding them later is expensive.

Vague vs testable

“The system should be secure” can’t be tested, so nobody can ever say it’s been met. Rewritten:

“Users log in with MFA. Sessions time out after 15 minutes of inactivity. Every change to customer bank details is logged with the user ID, time, and the old and new values.”

Now each part can be tested.

Good requirements are clear (one meaning), complete (including controls), consistent (no contradictions), testable, traceable (linked to a business need and to tests) and prioritised (must-have vs nice-to-have).

Gathering and approving

Requirements come from users and business owners, through interviews, workshops, observation, document reviews and prototypes. IT analysts write them up. Then they’re:

checked with users for completeness and accuracy
approved (signed off) by user management
baselined, so later changes go through formal change control

Tracing requirements to tests

A requirement traced through design and code to the tests that verify it.

A requirements traceability matrix links every requirement to its design, code and test cases. It shows:

every requirement was built and tested
nothing was built that nobody asked for (“gold plating”)
what a proposed change would affect

Why requirements go wrong

the right users weren’t involved
vague statements that can’t be tested
missing non-functional and control requirements
uncontrolled changes (scope creep)
sign-off without a real review

How the exam asks about it

If the question asks…	The answer is usually…
The most common cause of project failure	Poorly defined or changing requirements
Who approves requirements?	User / business management
The tool linking requirements to test cases	Requirements traceability matrix
The requirements are missing security controls	Add them now; it’s cheapest at this stage
What makes a requirement verifiable	It’s specific and testable

In short

Requirements describe what the system must do (functional) and how well (non-functional: speed, security, availability, usability).
Security, control, audit trail and regulatory requirements must be included explicitly.
Users and business owners define and approve requirements; IT helps document and analyse them.
Good requirements are clear, complete, consistent, testable and traceable.
A requirements traceability matrix links each requirement to design, code and test cases.
Changes to approved requirements go through change control.

Exam traps

Unclear or incomplete requirements are the most common cause of project failure and overruns.
A requirement that can't be tested can't be verified.
Users approve requirements, not developers.
Leaving security requirements until design or build is too late.

Slides

Click the slide and use the arrow keys. F toggles full screen.

If the question asks…	Answer
Most common cause of project failure	Poorly defined or changing requirements
Who approves requirements	User / business management
Tool linking requirements to tests	Requirements traceability matrix
Requirements missing security controls	Add them now; it's cheapest at this stage
What makes a requirement verifiable	It's specific and testable