19-Soft-A5 Requirements and Specifications · Undated paper
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2019 — 04-Soft-A5, Requirements and Specifications (open book, no calculator, 3 hours, 75 points total across 8 questions).
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; RTCA DO-178C for the avionics certification context in Question 4(iii).
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.
Agile methods organize work as small, independently deliverable increments of visible, functional value — a user story following the “as a <user>, I want <capability>, so that <benefit>” template, sized to fit in one sprint and demoable at the sprint review. Non-functional requirements resist this shape for several reasons. They are typically cross-cutting — “the system shall be secure” or “the system shall respond within 200 ms” is not a property of one story but of the whole system as it accumulates, so it cannot be isolated into a single sprint's backlog item the way a discrete feature can. Many NFRs are also only measurable late: a scalability or performance requirement often cannot be meaningfully tested until a substantial part of the system exists under realistic load, which conflicts with agile's preference for early, incremental verification. There is also a prioritization bias: a product owner building a backlog from stakeholder value tends to rank a visible, demoable feature above an “invisible” quality attribute that no one directly asked for, so NFRs are systematically under-prioritized unless someone deliberately protects budget for them — the well-known result being technical debt that accumulates silently, sprint after sprint, until it becomes a crisis. Finally, NFRs do not naturally fit the INVEST criteria (independent, negotiable, valuable, estimable, small, testable) that a good user story satisfies, since they are rarely independent of other work and rarely deliver value on their own; teams typically address this by treating NFRs as standing constraints or a “definition of done” checklist applied to every story, or by scheduling dedicated architecture/technical spikes, rather than by writing them as ordinary stories.
