19-Soft-A5 Requirements and Specifications · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2019 — 04-Soft-A5, Requirements and Specifications (open book, no calculator, 3 hours, 75 points total across 8 questions).
Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 4 (Requirements Engineering) and Ch. 5 (System Modeling – use cases); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 8–9 (Requirements Engineering, Requirements Modeling); SWEBOK v4, Requirements Engineering KA; ISO/IEC 25010 (SQuaRE) for the non-functional quality model used in Question 4; RTCA DO-178C for the avionics certification context in Question 4(iii).
Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.
Part 1 — product specification, and completeness (3 points). Yes, this reads as a product specification rather than a requirements specification proper: every clause fixes a specific implementation decision (a 3-inch screen, a 1-bit signal, the COM port, a fully red GUI) instead of stating the externally observable behaviour the emergency-stop function must provide, independent of how it is built. A requirements specification would instead say something like “the device shall visibly and unambiguously signal a stop state to the operator” and “the device shall convey a stop event to the controlled system within a defined maximum latency,” leaving the screen size and signalling protocol to design. It is not complete: nothing specifies what the controlled system (or the COTS itself) must do if the interrupt signal is not received — a broken USB connection, a COM port fault, or touch-screen hardware failure has no defined fallback, which is precisely the failure mode a safety-critical stop function must not be silent about. There is also no requirement covering how the stopped state is reset/re-armed once the emergency has been cleared, no environmental requirement (an emergency-stop device is typically specified for a dust/liquid ingress rating and an operating-temperature range appropriate to its installation), and no requirement on how conformance to (d)'s 0.1-second bound is to be verified. A specification that is silent on failure behaviour, reset behaviour, and verification method cannot be called complete for a life-safety device.
Part 2 — quality attributes unfulfilled by the specification as a whole (4 points). The most serious gap is safety itself: nothing requires the design to fail safe — if power, the touch-screen hardware, or the USB/COM link fails, the specification does not say the controlled system must default to a stopped state, so a hardware fault could silently disable the emergency stop rather than triggering it. Closely related is reliability: the design as specified is a single point of failure (one screen, one cable, one signal line) with no redundancy requirement, which is unusual for a component whose entire purpose is safety assurance. Verifiability/testability is unfulfilled across the set — there is no acceptance-test procedure implied for any requirement, so a supplier could claim conformance without an agreed method to check it. Finally, security is absent: nothing prevents a spurious or malicious signal on the COM port from being misinterpreted as the “everything is okay” (0) state when a real stop condition exists, or vice versa.
Part 3 — quality attributes unfulfilled by each individual requirement (8 points).
| Requirement | Quality attribute(s) not fulfilled | Why |
|---|---|---|
| (a) GUI completely red, centred “STOP” in white | Verifiability; Accessibility/usability | “Completely red” is not quantified (no colour reference, e.g. a specific hex/Pantone value, and no minimum text size/contrast ratio), so two implementations could both claim conformance while looking different — not independently verifiable. It also relies on colour alone: roughly 8% of men have red–green colour vision deficiency, so a safety-critical indicator that depends solely on hue, with no additional shape/texture/flashing cue, is a usability and accessibility gap. |
| (b) 1-bit interrupt signal on COM port if pressed | Design-independence (abstraction level); Robustness | This specifies how (a 1-bit signal over a COM port) rather than what (a stop event must be conveyed to the controlled system) — premature design commitment that constrains portability. It is also silent on fault handling: what happens if the port disconnects, or if noise flips the bit, is undefined, so robustness under abnormal conditions is unaddressed. |
| (c) 3-inch touch screen monitor | Traceability; Verifiability | No rationale ties the 3-inch figure to an actual user need (legibility at a stated viewing distance, minimum touch-target size for a gloved or trembling hand). Without a derived need to trace back to, the number cannot be checked as correct or incorrect — it is simply asserted. |
| (d) Interrupt sent within 0.1 s of being pressed | Verifiability (partial); Traceability | This is the only requirement with a genuinely measurable value, but it still lacks the operating conditions the bound must hold under (worst-case processor load, temperature range) and an acceptance test method, so it is measurable in principle but not yet verifiable in practice. It also is not traced to a hazard/risk analysis of the controlled machine that would justify why 0.1 s, rather than some other bound, is the correct safety margin. |
