Requirements Engineering
What this domain tests
The exam probes whether you can tell a requirement from a design decision, and whether you can spot a statement that no test could ever pass or fail. Expect elicitation technique selection, requirement classification, specification quality attributes, traceability, and change control.
Core rules and concepts
- Requirement types: functional (behavior the system performs), non-functional (performance, security, reliability, usability, maintainability), and constraints (regulatory, platform, contractual, imposed design).
- A well-formed requirement is necessary, unambiguous, complete, feasible, verifiable, and traceable. ISO/IEC/IEEE 29148 (which superseded IEEE 830) is the reference for SRS structure and requirement quality.
- Elicitation techniques: interviews, facilitated workshops, observation/job shadowing, document analysis, questionnaires, and prototypes. Pick by stakeholder availability and how novel the problem domain is; observation beats interviews when users cannot articulate their own workflow.
- A bidirectional traceability matrix links stakeholder needs to requirements, requirements to design elements, and requirements to test cases. Orphan requirements and untested requirements are both findings.
- Requirements management means baselining the agreed set and routing every subsequent change through impact analysis and approval. Uncontrolled change is scope creep.
Worked example
Weak statement: The order service shall respond quickly under load.
Why it fails: quickly has no metric and under load names no condition, so no test can pass or fail. It is a wish, not a requirement.
Rewrite: Under a sustained load of 500 concurrent users on the reference hardware, 95% of GET /orders calls shall return in under 300 ms and 99% in under 800 ms.
Reasoning: the rewrite names the measurement (response time), the operating condition (concurrency, hardware baseline), the statistic (95th and 99th percentile), and the threshold. Each of those elements converts directly into a load-test acceptance check.
Traps that cost marks
- Smuggling design into requirements (
shall use a Redis cache) instead of stating the need; this forecloses options and biases estimation. - Treating non-functional requirements as optional decoration, when they are what drive the architecture.
- Omitting negative and error-path requirements, so half the behavior is unspecified.
- Validating only with the requester and not with the people who operate or maintain the system.