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.
Reliability is the probability that a system performs its specified function correctly, without failure, over a stated period of time under its normal, specified operating conditions — commonly measured as mean time between failures (MTBF) or a failure rate. It answers: given the inputs and environment the system was designed for, how likely is it to keep working correctly? Robustness, by contrast, is about behaviour outside that specified envelope — the system's ability to continue operating in a useful, controlled way (or to degrade gracefully rather than fail catastrophically) when it encounters invalid input, an unexpected environment, or a hardware fault it was not explicitly designed around. The two are independent axes: a system can be highly reliable under normal conditions and still brittle the moment conditions deviate even slightly from what was anticipated.
Example. Consider a car's GPS navigation system. If it correctly computes routes and never crashes across a year of ordinary driving, it has high reliability. Now suppose the GPS signal is lost in a tunnel: a robust design continues operating in a degraded but useful mode — showing “signal lost, last known position, continuing by dead reckoning” — while a non-robust design freezes, crashes, or silently displays a wildly wrong location as though nothing had changed. Both versions could have identical reliability figures under normal signal conditions (since the tunnel scenario never appears in that measurement), yet only one of them is robust to the unanticipated loss-of-signal condition. A well-engineered system needs both properties: reliability so it rarely fails under the conditions it was built for, and robustness so that when it does encounter the unexpected, it fails safely and informatively rather than catastrophically.