19-Soft-A5 Requirements and Specifications · May 2015
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2015 — 04-Soft-A5, Requirements and Specifications (open book, one book of the candidate's choice, 3 hours, no calculator). The paper has four parts: Part 1 (30%) is ten statement/reason items on requirements-engineering theory; Part 2 (25%) is a two-page essay on the requirements-elicitation process; Part 3 (25%) covers non-functional requirements, including three NFRs for a life-critical avionics system; Part 4 (20%) asks for the seven characteristics of an excellent individual requirement and the three characteristics of an excellent requirements collection. This solution answers every part and every sub-item in full as a study resource.
Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 4 (Requirements Engineering) & Ch. 5 (System Modeling); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 8–9; SWEBOK v4, Requirements Engineering KA; ISO/IEC/IEEE 29148 (requirements quality characteristics); ISO/IEC 25010 (SQuaRE quality model, used for the avionics NFRs in Part 3); Karlsson & Ryan and Karlsson, Wohlin & Regnell on requirements-prioritization scales (Part 1, items 1–2); Ruhe, Product Release Planning: Methods, Tools and Applications, on precedence/coupling constraints in release planning (Part 1, item 5); Lauesen, Software Requirements: Styles and Techniques, on requirement levels, task descriptions and focus groups (Part 1, items 4, 8 and 10; Part 2).
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 (i) — what non-functional requirements are. A non-functional requirement (NFR) is a constraint on how well, not whether, the system delivers its functions: it restricts the acceptable solution space along a quality dimension — response time, availability, security posture, usability, portability, maintainability — rather than adding a new capability the way a functional requirement does (Sommerville §4.3). Where a functional requirement can typically be satisfied or not satisfied by a single feature, most NFRs are cross-cutting: they apply across many or all of the system's functions simultaneously, which is precisely why they are harder to specify and verify than data requirements (Part 1, item 9). ISO/IEC 25010 (SQuaRE) organizes NFRs into eight quality characteristics — functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability and portability — which gives a systematic checklist for eliciting them rather than relying on whichever quality concern happens to occur to a stakeholder unprompted.
Part (ii) — mapping NFRs to a use-case model. Because an NFR is cross-cutting, it rarely attaches cleanly to a single use case the way an actor or a main-success-scenario step does. The standard technique is to annotate each use case that the NFR materially constrains with a "special requirements" note in the use-case description (e.g. adding "response time < 2 s" to the special-requirements section of a "View Balance" use case), while NFRs that genuinely apply system-wide (e.g. "the system shall be available 99.9% of the time") are recorded once at the model level instead of being copy-pasted onto every use case. A useful discipline when building the model is to walk every use case against the ISO/IEC 25010 checklist and ask which characteristics materially constrain it; a use case that comes back with none flagged is much more likely to indicate a missed NFR than a genuine absence of one, since almost every user-facing use case has at least a performance or usability constraint. This annotation approach keeps NFRs testable and traceable to the specific interaction they govern, instead of floating as an unattached, unverifiable list.
Part (iii) — three non-functional requirements for a life-critical avionics system. A life-critical avionics system (e.g. a flight-control or engine-management computer) is held to a materially higher bar than ordinary business software on at least three quality attributes, each described briefly below.
| Quality attribute | What it requires for this system |
|---|---|
| Safety / fault tolerance | The system shall fail into a known-safe state and continue to provide (or gracefully degrade) critical control functions in the presence of any single hardware or software fault — e.g. via redundant, dissimilar computing channels that vote on outputs, so that no single point of failure can produce an unsafe control command. Unlike ordinary reliability, safety here is explicitly about the consequence of failure, not just its frequency: a rare failure that leads to loss of control is unacceptable even if its probability is extremely low, which is why avionics safety requirements are expressed as maximum tolerable failure-condition probabilities per flight hour, tied to the severity of the consequence (catastrophic, hazardous, major, minor), per the DO-178C/ARP4754A safety framework. |
| Real-time performance (timeliness) | Every control computation that affects flight-critical behaviour shall complete within its specified worst-case deadline on every execution, not merely on average — a hard real-time requirement, since a correct control output delivered late is as dangerous as an incorrect one for a system stabilizing a physical aircraft in real time. This requirement is verified by worst-case execution-time analysis and schedulability analysis on the target hardware, not by average-case benchmarking, and it constrains the software architecture (deterministic scheduling, bounded interrupt latency, no unbounded-latency operations such as dynamic memory allocation in the control loop) far more tightly than a typical business system's performance requirement would. |
| Verifiability / certifiability | The system's software shall be developed and documented to a level of rigor that permits independent, objective verification of every requirement against an approved certification standard (DO-178C for civil avionics), including full requirements-to-code-to-test traceability, structural coverage analysis of the object code, and formal configuration control — because a life-critical avionics system cannot be certified for flight, and therefore cannot be legally operated, unless every requirement is demonstrably verified, not merely believed correct. This attribute constrains the requirements themselves (each must be written testably, echoing Part 4's "verifiable" characteristic) as much as it constrains the implementation process. |
These three are not independent in practice: the safety requirement sets the target failure probability, the real-time requirement is frequently what the safety analysis identifies as the dominant hazard (a control loop that misses its deadline is a failure mode in its own right), and the verifiability requirement exists specifically to give the certification authority objective evidence that the first two have actually been met before the aircraft is allowed to fly.
