19-Soft-A5 Requirements and Specifications · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2014 — 04-Soft-A5, Requirements and Specifications (open book, 3 hours). Notes on the paper: answer five or six of the seven questions with Questions 2 and 4 mandatory (a complete paper totals 100 marks); this solution answers all seven questions as a full study resource. Every question is set against the same running case, IseeFin, a hypothetical cloud-hosted Investment Club financial-management tool.
Reference texts. Sommerville, Software Engineering, 10th ed., Ch. 4 (Requirements Engineering) and Ch. 5 (System Modeling – use cases); Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 8–9 (Requirements Engineering, Requirements Modeling); SWEBOK v4, Requirements Engineering KA; ISO/IEC 25010 (SQuaRE) for the non-functional quality model used in Question 4.
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 5.1 — specifying the UI. Given that several of IseeFin's stakeholders (ordinary club members) are non-technical, the UI is best specified with techniques that communicate concretely rather than abstractly. Wireframes / low-fidelity mockups for the core screens (buy/sell, holdings/valuation, tax-report request) fix layout and information hierarchy before any code is written. Interactive prototypes / mockup tools (clickable prototypes) let a member "use" the flow without a working backend, which is far more revealing for a financial product where trust and clarity matter more than visual polish. A storyboard walking through a representative scenario (a member joining the club, buying units, checking valuation a month later) documents the intended experience end-to-end rather than screen-by-screen. Finally, a lightweight UI style guide (typography, colour, terminology — e.g. always calling it a "unit," never mixing "share"/"unit") keeps the many screens consistent as the product grows, and each use case's main success scenario (Question 3) can be annotated directly with the screen/wireframe that realises each step.
Part 5.2 — validating the UI specification. Usability testing with a small sample of real (or representative) club members — observing them attempt a task like "buy 10 units" on the prototype without guidance, measuring task completion and time-on-task — is the most direct validation, because it tests whether the interface is actually usable by the target, largely non-technical audience rather than whether it merely looks correct. Heuristic evaluation by a usability expert against established principles (visibility of system status, error prevention, consistency) catches issues cheaply before real users are involved. Walkthroughs with stakeholders (the treasurer and trading officer, whose workflows are the most complex) against the use cases from Question 2/3 confirm the UI actually supports every step of the main success and alternate flows, not just the happy path. Finally, once built, A/B testing or analytics on live usage (e.g. drop-off rate on the buy/sell confirmation step) validate the specification against real behaviour and feed back into the next release (Question 7).
