NivaarExam PrepOfficial exam papers ↗

19-Soft-A5 Requirements and Specifications · Undated paper

Question 2 of 8: Requirements Elicitation

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

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 2: Requirements Elicitation (5 points)

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.

Eliciting requirements without any face-to-face contact — by email, written questionnaire, ticket/form submission, or asynchronous messaging — removes several channels an analyst normally relies on, and each removal creates a distinct difficulty. First, it strips out non-verbal cues: hesitation, a confused expression, or a tone that signals a stakeholder is guessing rather than stating a firm need are all invisible in text, so an analyst cannot probe a weak or uncertain answer in the moment the way they could redirect a live conversation. Second, it slows clarification cycles from seconds to days: an ambiguous written answer that would take one follow-up question to resolve in person instead requires another round-trip email, and each round-trip risks the stakeholder losing context or simply not replying. Third, it weakens rapport and trust — stakeholders who have never met the analyst are less likely to disclose politically sensitive information (workarounds they use because the official process is broken, disagreements with a colleague's stated requirement), so the elicited requirements skew toward what is safe to put in writing rather than what is true. Fourth, it removes the option of contextual observation (watching how a task is actually performed), so tacit knowledge that a stakeholder does not think to mention — because it is second nature to them — never surfaces; a written questionnaire only returns what the stakeholder consciously articulates. Fifth, group elicitation techniques such as a facilitated workshop, where disagreements between stakeholders are surfaced and resolved live, are far harder to replicate asynchronously: conflicting written requirements from two stakeholders may simply sit uncontested until much later in the project. Finally, for a stakeholder population that is not comfortable with the communication medium itself — for instance, an elderly end user asked to fill in an online form, directly relevant to the smart-home-for-seniors scenario in Question 1 — the elicitation method can itself introduce a systematic bias, under-representing exactly the users the system is meant to serve.