25-Comp-A6 Software Engineering · December 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams — December 2013 — 98-Comp-A6 Software Engineering. Three-hour, closed-book exam, no calculator permitted. Format: nine questions, candidates answer any five of the nine (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 nine 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, rapid development and prototyping, client-server architectures, software validation; Pressman, Software Engineering: A Practitioner's Approach (9th ed.) — supplementary process, testing and architecture coverage; Gamma, Helm, Johnson & Vlissides, Design Patterns — object-oriented design/reuse vocabulary.
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.
Business environments and the requirements they generate change faster than a large, fully-detailed system can typically be built. If development follows a slow, comprehensive process aiming to nail down every feature before delivering anything, the business conditions the system was designed for may have already changed by the time it ships — a competitor may have captured the market opportunity, the regulatory environment may have shifted, or the organisation's own priorities may have moved on, making much of the painstakingly-specified detailed functionality irrelevant or simply wrong. Delivering a smaller, less complete system quickly instead captures business value earlier (revenue, cost savings, competitive positioning) and, just as importantly, generates real feedback from real usage while there is still time and budget to act on it — letting the detailed functionality evolve in response to validated need rather than being guessed correctly in one attempt up front. In short, an imperfect system delivered in time to matter is usually worth more to the business than a more complete system delivered too late to matter.
This is a strong candidate for a throwaway prototype built primarily as a requirements-elicitation tool, because the description leaves several core aspects of the required behaviour genuinely unclear: what "a certain amount" means as the threshold for attaching conditions, what structural form a "condition" takes (free text vs. a structured link to a specific project/budget code), and exactly how spending is tracked against a condition once money has been disbursed. Rather than commit to a detailed design against guessed answers to these questions, I would build a minimal but interactive prototype quickly — using a high-productivity scripting/RAD environment or even a spreadsheet-backed mock-up — covering only the core entities: a donor record (name, address, interests), a donation record (amount, date, donor link), an optional condition attached to large donations, and a simple running total of "amount spent against this condition."
The prototype would then be used interactively with charity staff: walking through realistic scenarios (a large conditional donation, a small unconditional one, a donor who gives multiple times) and asking them to confirm or correct what the screen shows at each step. This is deliberately a two-way elicitation exercise, not a demonstration — the goal is to use the running prototype to surface the exact unclear points identified above (the threshold value, how a condition is expressed and matched against later spending) before committing to the real system's data model and design.
