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 6.1 — evaluation checklist. Because several competing requirements documents must be scored against each other, the checklist needs to be objective — criteria a reviewer can mark yes/no or on a scale, not impressionistic quality judgements. The hint ties the checklist directly back to the earlier answers: it should verify that each submitted document actually covers what 1.3, 2.4 and 4.3 established as necessary.
| Criterion | Objective check |
|---|---|
| Stakeholder coverage | Does the document address every stakeholder concern identified in 1.3 (member trust/transparency, trading-officer accuracy, treasurer reconciliation/tax, admin configurability, sponsor differentiation)? Score = concerns addressed / concerns identified. |
| Functional completeness | Is every use case from 2.4 (or an equivalent set derived independently) present, with a fully-dressed description (actor, preconditions, main/alternate flow, postconditions) as in 3.1 — not just a one-line title? |
| Non-functional completeness | Is each NFR category from 4.3 (capacity, security, accuracy, usability, language, availability, compliance, performance) addressed with a measurable target, not a vague statement? |
| Traceability | Can every requirement be traced to a stakeholder need or a business goal (no orphan requirements), and can every stated business goal be traced forward to at least one requirement (no gaps)? |
| Consistency | Are there internal contradictions (e.g. two requirements implying incompatible unit-price rounding rules)? Count of detected conflicts (lower is better). |
| Unambiguity | Is each requirement stated in a single, testable way, free of vague terms ("user-friendly," "fast") without a quantified definition? |
| Verifiability | Could an independent tester write a pass/fail acceptance test directly from the requirement as written? |
| Regulatory/domain fit | Does the document correctly reflect the flow-through tax model and multi-currency needs specific to investment clubs, evidence the vendor understood the domain rather than generic financial software? |
| Document quality | Structure, numbering and cross-referencing consistent with a recognised standard (e.g. IEEE/ISO 29148) so the document itself is maintainable. |
Each submitted document is scored per criterion (e.g. 0–5) and the scores compared on a common rubric across the competing vendors, keeping the evaluation defensible and free of reviewer bias toward any one vendor's writing style.
