25-Comp-A6 Software Engineering · December 2019
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2019 — 17-Comp-A6 Software Engineering. Three-hour, closed-book, no-calculator exam. Format: eight questions, candidates answer any five of the eight (all questions equal weight — each of the five counted questions is worth 20%; only the first five questions as they appear in the answer book are marked). All eight questions are solved below for completeness.
Reference texts: Sommerville, Software Engineering (10th ed., Pearson) — software process models, object-oriented and function-oriented design, requirements engineering, software testing, software reuse, formal methods, dependable/critical systems, real-time software engineering, distributed software systems; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process, testing and architecture coverage.
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.
Natural language is ambiguous: the same sentence can be read in more than one way (a term like "the system" or "these" can bind to different things depending on the reader), and a requirement's imprecision is often invisible to its own author. It is over-flexible: the same requirement can be expressed in many different ways, so there is no canonical form against which two statements can be mechanically compared, making it hard to spot when two requirements conflict or duplicate each other. It lacks modularity: unlike a structured specification notation, prose does not enforce grouping of related requirements, so requirements about the same feature can end up scattered across a long document, and requirements about different features can end up entangled in the same paragraph. Finally, because it is not a formal notation, natural language cannot be automatically checked for completeness or consistency — there is no way to run an analysis tool over prose to detect a missing case or a contradiction the way one can over a formal or semi-formal specification; the HSS paragraph analysed in part (b) illustrates several of these problems at once.
The statement is short, but a careful, literal reading finds a substantial list of defects:
| # | Defect | Explanation |
|---|---|---|
| 1 | No arm/disarm concept at all (omission) | A home security system's most basic behaviour — the owner arming the system on leaving and disarming it on entry — is never mentioned. Without an armed/disarmed state, the entry sensor cannot distinguish "owner is coming home" from "intruder has entered," so the system as literally described would trigger on every entry, always. |
| 2 | Ambiguous meaning of "threshold" across sensor types (ambiguity) | "Set thresholds for the sensors" makes clear sense for a temperature sensor (a numeric trip point) but is unclear for an entry sensor (which is naturally binary, open/closed) and for a smoke sensor (which may be binary or an analog obscuration level depending on hardware) — the text does not say whether "threshold" applies uniformly or means something different per sensor class. |
| 3 | Entry-delay vs. exit-delay not distinguished (ambiguity) | "Set delays for various alarms" does not say whether a delay is an entry delay (time after the door opens before the alarm sounds, so the owner can disarm) or an exit delay (time after arming before entry sensors go live, so the owner can leave) — a real HSS needs both, for different reasons, and the text conflates them into one undifferentiated "delay." |
| 4 | No alarm-acknowledgement or silence path (omission) | Once "the system generates alarms," there is no described way to stop an alarm that has already been triggered (e.g. the owner returning and disarming mid-alarm, or a false alarm being cancelled) — without this, every triggered alarm runs indefinitely. |
| 5 | Alarm-to-response mapping unspecified (omission) | The system "generates alarms, turning on selected lights, and calling owner-specified phone numbers," but never states which response applies to which sensor — are all three responses fired for every sensor type identically, or does (say) a flood sensor light the kitchen while a smoke sensor calls the fire department's number? "Selected" lights and "owner-specified" numbers imply some sensor-specific configuration exists, but the mapping itself is never given. |
| 6 | No behaviour on call failure (omission) | Nothing states what happens if a called number is busy, unanswered, or unreachable — is the next number in the list tried, is there a retry count, and is failure to reach anyone itself logged or escalated? |
| 7 | No keypad authentication for programming (ambiguity/omission) | "The system is owner-programmable through a keypad" never mentions a PIN or other authentication gating access to programming mode — for a security system specifically, allowing anyone with physical access to the keypad to reprogram thresholds, phone numbers or delays is a serious, unstated security gap. |
| 8 | No concurrent-alarm priority (omission) | If two sensors trigger at the same time (e.g. a break-in during a fire), the text gives no rule for how the system prioritizes or combines the resulting alarms, lights and calls. |
| 9 | No power-failure/backup behaviour (omission) | A microprocessor-based system controlling life-safety functions (smoke, flood) has no stated behaviour on loss of mains power — whether it has battery backup, and if so for how long, is left completely unaddressed. |
