Requirements Engineering Fundamentals

Use this page to revise the vocabulary and structures a requirements knowledge test typically covers.

Types of requirements

Business requirements describe why a project exists (the organisational goal).
User requirements describe what a user needs to be able to do.
System requirements describe what the system must technically provide to satisfy the user requirements.
Functional requirements describe what the system does (behaviour, features).
Non-functional requirements describe how well the system does it (performance, reliability, availability, scalability, security, usability, maintainability, portability).

Qualities of a good requirement

A well-written requirement is:

Clear — one reading is enough to understand it.
Testable — you can write a test that proves it's satisfied or not.
Unambiguous — it can't reasonably be interpreted two different ways.
Feasible — it can actually be built within the constraints of the project.

Writing requirement statements

The standard structure is: "The system shall <do something>." This phrasing forces a requirement to name a concrete, observable behaviour instead of a vague intention.

Use cases

A use case describes an interaction between an actor (a user or another system) and the system, through a main flow (the expected sequence of steps) and, where relevant, alternative flows (what happens when something deviates from the main flow, e.g. invalid input or a failed step).

Acceptance criteria and traceability

Acceptance criteria state the conditions a piece of work must meet to be considered done, and they should map directly back to a requirement. Traceability means you can follow a line from a requirement, to the use case or user story that implements it, to the test case that verifies it — so nothing gets built, or tested, without a reason.

Starting Points

SWEBOK Guide — "Software Requirements" chapter (IEEE Computer Society).
Atlassian, Requirements and specifications.
Wiegers, K. E., & Hokanson, C. (2023). Software Requirements Essentials. Addison-Wesley.
Technical requirements analysis

Key Points

You can explain the difference between business, user, and system requirements.
You can explain the difference between functional and non-functional requirements, with examples.
You can list the qualities of a good requirement (clear, testable, unambiguous, feasible).
You can write a requirement statement in the standard "The system shall …" form.
You can describe a use case using actors, a main flow, and a basic alternative flow.
You can explain what acceptance criteria are and how they relate to a requirement.
You can explain what traceability means, from requirement to test case.