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 3.1 — two critical use cases, detailed. "Buy / Sell Club Units" and "Generate Tax Report" are selected as critical: the first is the core financial transaction every member performs and the one on which correct unit accounting depends; the second is described in the brief itself as IseeFin's "main selling point."
| Field | Buy / Sell Club Units |
|---|---|
| Primary actor | Club Member |
| Goal | Purchase or redeem units of the club at the current unit price. |
| Preconditions | Member is authenticated and belongs to the club; a current unit price (net asset value per unit) exists. |
| Main success scenario | (1) Member selects Buy or Sell and enters an amount (dollars or number of units). (2) System computes the equivalent units/dollars at the current unit price. (3) Member confirms. (4) System records the transaction, updates the member's unit balance and the club's total units outstanding, and recomputes the unit price if the transaction changes total club assets by more than a rounding amount. (5) System displays a confirmation and updated holdings. |
| Alternate flow | 3a. Member cancels → no state change. 2a. Requested sell amount exceeds the member's unit balance → system rejects with the maximum sellable amount shown. |
| Postconditions | Member's unit balance and the club's aggregate holdings are updated and consistent; a transaction record exists for audit and for the year-end tax report. |
| Field | Generate Tax Report |
|---|---|
| Primary actor | Treasurer |
| Goal | Produce the club's country-specific flow-through tax filing (T5 in Canada, Form 1065 in the USA) for a given tax year. |
| Preconditions | The club's country/jurisdiction is configured (from "Configure Club Setup"); all trades and unit transactions for the year are recorded; Reconcile Treasury has been completed for the year so the ledger is trustworthy. |
| Main success scenario | (1) Treasurer selects the tax year and confirms the jurisdiction. (2) System aggregates the club's realised gains/losses, income and expenses for the year. (3) System allocates each member's share by their weighted-average unit ownership over the year. (4) System renders the jurisdiction-specific form (T5 slips per member, or the Form 1065 partnership return with member K-1-equivalent schedules). (5) Treasurer reviews and downloads/distributes the report to members. |
| Alternate flow | 2a. An unreconciled discrepancy exists for the year → system blocks report generation and directs the treasurer to Reconcile Treasury first. 4a. A member joined/left mid-year → their allocation is pro-rated by the weighted-average holding period. |
| Postconditions | A jurisdiction-correct tax report exists per member and is available for distribution; the club retains an auditable record of the calculation basis. |
Part 3.2 — a complementary technique. A use-case description alone is verbose and hides the branching logic and inter-role handoffs that matter most for these two critical cases. An activity diagram (UML) or, equivalently for the tax case, a sequence diagram across the Treasurer, IseeFin, and the Tax-Reporting engine, complements the prose by making the decision points and pre-condition checks (e.g. "reconciled?" before report generation) visually explicit and easy to review with a non-technical stakeholder. For "Buy / Sell Club Units," a simple state diagram of a unit-order's lifecycle (Draft → Confirmed → Posted, with a Rejected branch) similarly clarifies the alternate flows in 3.1 more compactly than the tabular scenario alone, and a data/entity-relationship sketch of Member–Club–UnitTransaction ties the use case back to the persistent data it reads and writes.
