Requirements Engineering Fundamentals
Use this page to revise the vocabulary a requirements knowledge test typically covers, including constraints that show up on devices.
Types of requirements
- Business requirements describe why a project exists (the organisational goal).
- User requirements describe what a user or operator needs to be able to do.
- System requirements describe what the device must technically provide.
- Functional requirements describe behaviour (what it does).
- Non-functional requirements describe how well (latency, reliability, power, safety, security, maintainability).
Qualities of a good requirement
A well-written requirement is clear, testable, unambiguous, and feasible on the chosen hardware.
Writing requirement statements
The standard structure is: "The system shall <do something>." For devices, add a condition or bound where needed (within 50 ms, at 3.3 V, with the e-stop open).
Use cases, acceptance, traceability
A use case or operational scenario has an actor, a main flow, and alternative flows. Acceptance criteria are the checks that prove a requirement. Traceability means you can follow a line from requirement → design/part → test (including a lab measurement).
Starting Points
- SWEBOK Guide — "Software Requirements" chapter (IEEE Computer Society).
- 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 functional vs. non-functional requirements, with an embedded example of each.
- You can list the qualities of a good requirement.
- You can write a requirement in "The system shall …" form with a testable bound.
- You can describe a use case using actors, a main flow, and an alternative flow.
- You can explain acceptance criteria and traceability from requirement to a hardware or firmware check.