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 7.1 — prioritisation strategy. With time-to-market explicitly the key driver, prioritisation should combine a lightweight, stakeholder-friendly scheme with an objective weighting. MoSCoW (Must / Should / Could / Won't-this-time) is a good first pass because non-technical club stakeholders can participate directly in the conversation. Within the "Must" bucket, features are then ranked by a value-versus-effort assessment: business value is scored against the stakeholder concerns from 1.3 and the differentiation goals from the brief (multi-currency, tax reporting, ease of use versus the antiquated incumbent), and effort is estimated by the delivery team; the ratio favours features that unlock the most member/business value per unit of implementation cost. Dependencies matter too — "View Holdings & Valuation" cannot ship before "Buy / Sell Club Units" exists to generate a holding, so a simple dependency ordering is layered on top of the value/effort ranking. Because time-to-market is paramount, the strategy explicitly favours a thin, end-to-end walking skeleton (one club, one currency, one member workflow working completely) over a wide but shallow first release, so that real feedback starts flowing as early as possible.
Part 7.2 — first three releases.
| Release | Scope |
|---|---|
| Release 1 — MVP core ledger | Single club, single currency: Configure Club Setup (basic), Join/Leave Club, Buy/Sell Club Units, View Holdings & Valuation. Proves the core unit-accounting model end-to-end for one real club before anything else is built on top of it. |
| Release 2 — trading & treasury | Record Securities Trade (so the unit price reflects real portfolio performance, not just cash in/out) and Reconcile Treasury. Adds the trading-officer and treasurer roles and closes the gap between "money in" and "portfolio value" that Release 1 leaves open. |
| Release 3 — the selling point + scale-out | Generate Tax Report (Canada T5 first, as the initial target market per the 390-Canadian-club figure) and Convert Multi-Currency, plus multi-club onboarding hardening (Configure Club Setup fully generalised, Sync Bank/Brokerage Feed as a beta). Ships the feature the brief calls the "main selling point" as soon as the core platform (Releases 1–2) is proven stable, and opens the product to more than one club/currency. |
This ordering follows the strategy in 7.1 directly: Release 1 is the smallest possible walking skeleton with no external dependency; Release 2 adds the two roles whose concerns (1.3) are otherwise unaddressed; Release 3 adds the two highest-value differentiators (tax reporting, multi-currency) once the ledger they depend on is trustworthy.
