Requirements Engineering
What this domain tests
CWIIP treats requirements as the contract that makes an IoT project testable and maintainable. Questions probe elicitation technique choice, requirement quality, traceability, prioritisation and change control - with heavy emphasis on non-functional requirements, where most IoT projects fail.
Elicitation and specification
- Techniques: stakeholder interviews, facilitated workshops, observation of the physical process, document analysis, prototyping and site surveys. Choose by access and risk - observation reveals workarounds that interviews hide.
- Functional requirements describe behaviour; non-functional requirements describe qualities: latency, throughput, availability, battery life, security, maintainability, regulatory compliance.
- Write user stories with acceptance criteria (Given/When/Then) and use cases with main and alternate flows.
- ISO/IEC/IEEE 29148 quality characteristics: necessary, unambiguous, complete, singular, feasible, verifiable, correct, conforming, traceable. Avoid design decisions smuggled into requirements ("shall use MQTT") unless the protocol is a genuine constraint.
Traceability, priority and change
- A traceability matrix links each requirement to design elements, code and test cases in both directions, so you can prove coverage and assess change impact.
- Prioritise with MoSCoW; make NFRs SMART (specific, measurable, achievable, relevant, time-bound).
- Baseline the requirements; route changes through change control with impact analysis on cost, schedule, architecture and tests.
- Verification confirms the system was built right (tests pass); validation confirms the right system was built (stakeholder need met). They are different questions.
Worked example
Requirement: "The gateway shall respond quickly to actuation commands." That is unverifiable. Rewrite: "The gateway shall publish an actuation acknowledgement on topic site/{id}/ack within 500 ms of receipt of the command, at the 95th percentile, with 200 devices active." Now it names a channel, a metric, a threshold, a statistical basis and a load condition - so a tester can pass or fail it, and a designer knows what to build.
Traps
- Unmeasurable NFRs ("fast", "secure", "user-friendly") that cannot be tested.
- Missing acceptance criteria, leaving scope disputes unresolved.
- Unrecorded assumptions such as assumed Wi-Fi coverage or assumed mains power.
- Gold-plating: features no stakeholder requested, expanding scope.
- Treating validation (right system) as verification (system right).