Requirements Engineering (CPRE foundation content)
This section covers the domain this exam names: Requirements Engineering at CPRE foundation level. Items test whether you can separate requirement types, select an elicitation technique that fits the situation, judge documentation against quality criteria, and explain how requirements are controlled once a baseline exists.
Core concepts
- A requirement is a need perceived by a stakeholder plus its documented representation; the need and the document are not the same artefact.
- Stakeholder requirements state what a stakeholder needs in their working context; system requirements state what the system must provide at its boundary. Expect classification items.
- Functional requirements, non-functional (quality) requirements and constraints are three distinct kinds. Quality requirements need a measurable scale, not an adjective.
- The four core activities - elicitation, documentation, validation and negotiation, management - run iteratively across the lifecycle.
- Quality criteria: unambiguous, complete, consistent, correct, verifiable, traceable, modifiable.
- Attributes such as ID, source, rationale, priority, status, version and owner make impact analysis and release planning possible.
Choosing a technique
Interviews and questionnaires suit dispersed stakeholders; workshops suit consensus building and conflict resolution; observation and apprenticeship expose tacit work people cannot articulate; document analysis recovers legacy constraints; prototyping clarifies unclear behaviour. Creativity techniques generate candidates - they do not confirm them.
Worked example
Take "The system shall be user-friendly." Unambiguous? No - no agreed meaning. Verifiable? No test can pass or fail it. Complete? No actor, task or context. Correct? Unknown, since no source is named. The fix is not to invent a number: interview the stakeholders, decompose friendliness into concrete characteristics (task completion time, error rate, learnability), then write measurable statements with acceptance criteria, for example: "A first-time user shall complete checkout without assistance within 3 minutes in usability test scenario T-04." Record source and rationale so the threshold can be defended when it is challenged.
Traps that cost marks
- Swapping validation ("did we build the right product?") with verification ("did we build the product right?"). In RE, validation asks whether documented requirements reflect real needs.
- Writing a design decision as a requirement; a prescribed technology is legitimate only as a genuine constraint.
- Assuming any sentence containing "shall" is a good requirement - form is not quality.
- Omitting rationale and source, which turns every change request into guesswork.
- Treating elicitation as a phase that ends; most defects come from missing stakeholders, not careless wording.
- Using MoSCoW and Kano interchangeably: Kano classifies satisfaction impact (must-be, performance, attractive, indifferent, reverse); MoSCoW is a scoping decision.