25-Comp-A6 Software Engineering · December 2015
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2015 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. 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, software testing, requirements engineering, dependability and critical systems, configuration management, project/risk management; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process and testing coverage; Leveson, Safeware: System Safety and Computers — hazard analysis and fault tree analysis for safety-critical software (applied to the Question 7 medical-device case).
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 user" or "then" 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 ticket-system paragraph analysed in part (b) illustrates all four of these problems at once.
The statement is short, but a careful reading against itself finds a substantial list of defects:
| # | Defect | Explanation |
|---|---|---|
| 1 | Sequence contradiction (ambiguity) | The first sentence says the user "input[s] a credit card and a personal identification number" as if together, and that the ticket is issued and the account charged as one step. The second passage gives a different, more detailed order: select destination → input credit card → validity checked → input PIN → "when the credit card has been validated, the ticket is issued." These two accounts do not agree, and taken literally the second passage says the ticket is issued once the card is validated — not once the PIN is also validated. |
| 2 | Missing PIN-validation gate (omission) | Nowhere does the text state what happens if the PIN is wrong. If the ticket is genuinely issued "when the credit card has been validated" (as literally written), a valid card with a wrong PIN would still produce a ticket — almost certainly not the intended behaviour, but the text does not say so. |
| 3 | Missing charge-timing statement (omission) | The first sentence mentions charging the credit card account; the detailed second passage never mentions charging at all. It is not specified whether the charge happens before, after, or atomically with ticket issuance, nor what happens if the charge itself fails after the ticket has already printed. |
| 4 | No invalid-card handling (omission) | The text says the card's validity "is checked" but never states what happens on failure — reject and return to destination selection, allow a retry, or abort the transaction and return the card? |
| 5 | No invalid-PIN handling / retry limit (omission) | No retry count is specified for a wrong PIN, and there is no mention of what happens after repeated failures (card retained, transaction cancelled, etc.) — a security-relevant omission for a system handling payment cards. |
| 6 | No fare/pricing rule (omission) | The requirement never states how "its cost" is determined — by distance, by zone, by a fixed table — despite this being central to the system's purpose. |
| 7 | No user-cancel path (omission) | There is no way described for the user to abort the transaction (e.g. after seeing the destination menu, or after inserting the card) and get the card back without completing a purchase. |
| 8 | No failure/exception handling for ticket issuance (omission) | What happens if the ticket printer jams or is out of stock after the card has already been charged is not addressed at all. |
| 9 | Ambiguous term "start button" (ambiguity) | Not defined as hardware, a touch-screen control, or otherwise, and it is unclear whether the destination menu can be reached without first pressing it. |
