Question 4 of 8: Non-functional Requirements

Question 4: Non-functional Requirements (20 points)

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 are non-functional requirements (5 points). A non-functional requirement (NFR) constrains how well a system must deliver its functions rather than describing a new function or capability itself: it restricts the acceptable solution space along dimensions such as response time, availability, security posture, usability, or portability, instead of adding a “the system shall do X” behaviour (Sommerville §4.3). ISO/IEC 25010 (SQuaRE) organizes these into eight characteristics — functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, and portability — and unlike a functional requirement, which is typically satisfied by a single feature, a non-functional requirement is usually a cross-cutting property that must hold across many or all of a system's functions simultaneously.

Part (ii) — mapping NFRs to a use-case model (5 points). Because an NFR is cross-cutting, it rarely attaches to exactly one use case the way a functional requirement does. The standard technique is to annotate the use cases it constrains: a fully-dressed use-case description gets a “special requirements” section listing the NFRs that apply to that specific case (for example, a response-time bound attached to a time-critical use case), shown on a use-case diagram as a constraint note connected by a dashed line to the relevant use case, as in the figure below. NFRs that apply system-wide (e.g. “the system shall be available 99.9% of the time”) are instead recorded once, at the level of the whole system boundary, rather than repeated on every individual use case. A useful discipline when building the model is to check every use case against the ISO/IEC 25010 characteristic list; a use case with no NFR flagged against it is a signal that a real constraint may have been missed, not evidence that none exists.

Part (iii) — three NFRs for a life-critical avionics system (10 points).

Reliability / fault tolerance. The system must continue delivering its function correctly over a very long operating horizon with an extremely low probability of a catastrophic failure — commonly expressed against a target failure rate (e.g. on the order of 10^-9 per flight-hour for a catastrophic failure condition, the DO-178C Design Assurance Level A benchmark) — achieved through redundancy (dual or triple modular redundant computers, voting logic) and graceful degradation rather than a single point of failure, because an avionics failure can directly cause loss of life.

Real-time performance / timing predictability. A flight-control loop must meet its deadlines deterministically: the requirement is not merely “fast on average” but a proven worst-case execution time bound on every safety-relevant task, since a late response in a hard real-time control loop is functionally equivalent to no response at all and can itself be the proximate cause of an accident.

Safety / certifiability. The software must be developed and verified to a documented process that produces an auditable, bidirectional traceability chain from requirement to design to code to test (the DO-178C life cycle for the applicable Design Assurance Level), including a defined, independently verifiable fail-safe or fail-operational behaviour for every identified failure mode, because for a life-critical system the process by which correctness is demonstrated is itself part of what is being required, not only the resulting behaviour.