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 4.1 — non-functional requirement. A non-functional requirement (NFR) is a constraint on how a system delivers its functions rather than a description of a new function itself — it restricts the solution space (e.g. response time, availability, security posture, supported languages) instead of adding a capability (Sommerville §4.3; ISO/IEC 25010 groups these into eight quality characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability). Unlike a functional requirement, an NFR usually cannot be satisfied by a single feature; it is a property that must hold across many or all use cases.
Part 4.2 — mapping NFRs to the use-case model. Because an NFR is cross-cutting, it rarely attaches to only one use case the way a functional requirement does. The standard mapping technique is to annotate each relevant use case with the NFRs that constrain it — e.g. adding a "Special Requirements" section to the fully-dressed use-case template from Question 3 — or, for NFRs that apply system-wide (e.g. "the system shall be available 99.5% of the time"), to record them once at the model level rather than repeating them on every use case. A useful discipline is to ask, for every use case, which of the eight ISO/IEC 25010 characteristics materially constrain it; a use case with none flagged is a strong sign a real constraint was missed, not that none exists.
Part 4.3 — NFRs for IseeFin.
| Category | Non-functional requirement |
|---|---|
| Capacity / scalability | The system shall support at least 6,000 concurrent clubs (covering the stated ~4,700 US + 390 Canadian population with headroom) and up to a few dozen members per club without degraded response time. |
| Security | Club financial data shall be accessible only to that club's own members and administrators (multi-tenant isolation); all data in transit and at rest shall be encrypted; authentication shall support at minimum strong passwords with the option of multi-factor authentication given the financial nature of the data. |
| Accuracy | Unit-price and valuation calculations shall be correct to the cent (or smallest currency unit) and shall be reproducible/auditable from the underlying transaction log — a hard requirement given the tax and reconciliation use cases. |
| Usability | A non-technical club member shall be able to check their holdings and submit a buy/sell without training, given the brief's emphasis on being easier to use than the "DOS like" incumbent. |
| Language / localisation | The user interface and generated documents shall support at minimum English and French (Canadian bilingual requirement) with the architecture allowing further languages to be added for the stated Asian-market ambition. |
| Availability | The hosted service shall target at least 99.5% uptime during business hours, since members expect to check valuations at any time ("published on web"). |
| Compliance | Tax-report generation shall stay current with each supported jurisdiction's flow-through reporting rules (T5, Form 1065) as they change year to year. |
| Performance | Common member-facing pages (holdings, valuation) shall render within 2 seconds under normal load. |
Part 4.4 — relating these NFRs to the two Question-3 use cases. Buy / Sell Club Units is directly constrained by accuracy (a rounding error here misstates every member's valuation, not just the transacting member's), by performance (a member expects the confirmation and updated balance promptly), and by security (only the authenticated member may transact against their own holding). Generate Tax Report is directly constrained by accuracy and compliance (an incorrect T5/Form 1065 exposes the treasurer and members to real regulatory and financial consequences), by security (tax documents contain sensitive personal financial data and must not leak between clubs), and by language/localisation (the report itself must be produced in the jurisdiction's required form and, for a Canadian club, potentially bilingual). Both use cases therefore share the same top-two NFR priorities — accuracy and security — which is unsurprising since both are financial-record-of-truth operations; where they diverge is that the buy/sell case is performance-sensitive in the moment (a member is waiting on-screen) while the tax-report case is compliance-sensitive over the long term (correctness must survive a regulatory audit years later).
