Question 2 of 4: Part 2: Requirements Elicitation Process

Part 2: Requirements Elicitation Process (25%)

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.

Overview. Requirements elicitation is the activity of discovering, by working with stakeholders and other sources, what a system's stakeholders actually need — as distinct from what they first say they want, which is rarely the same thing (Sommerville §4.5). It is not a single interview or a one-time workshop; it is an iterative process that runs alongside analysis and negotiation for as long as new stakeholders, constraints or domain facts keep surfacing, and it is widely regarded as the single hardest activity in requirements engineering because its raw material — human knowledge, much of it tacit — is neither written down nor, often, consciously known by the person who holds it.

Barriers to elicitation. Several well-documented barriers recur across projects. Tacit knowledge: domain experts routinely know far more than they can articulate, because expertise becomes automatic and unconscious with experience — a treasurer who reconciles accounts every month may not be able to state the reconciliation rule in words even though they apply it correctly every time. Conflicting stakeholder views: different stakeholder classes want incompatible things (a sales team wants a fast, permissive workflow; a compliance officer wants the same workflow gated and audited), and eliciting from only one side produces a requirement set that another stakeholder will later reject. The vocabulary gap: domain experts and analysts do not share a technical language, so a requirement can be "elicited" in words that both parties believe they understood identically and did not. Scope and horizon effects: stakeholders describe the system they can currently imagine, anchored to the process they already have, and rarely volunteer requirements for capabilities that do not yet exist in their mental model (the classic "faster horse" problem). Stakeholder availability and organizational politics: the people with the most valuable knowledge are often the busiest, and elicitation sessions compete for their time against operational duties; power dynamics between stakeholder groups can also suppress a junior stakeholder's real concerns in a joint session. Finally, changing requirements: the business and regulatory environment keeps moving during a long elicitation phase, so a requirement elicited early can be stale before the system ships.

What to elicit. A thorough elicitation covers more than "what should the system do." It should surface: functional needs (the tasks and transactions stakeholders must be able to perform); non-functional/quality needs (performance, security, usability, availability — see Part 3); domain knowledge and business rules that constrain how a function must behave, independent of the software (tax rules, safety regulations, industry conventions); the current process and its pain points, so the new system is judged against a real baseline rather than an idealized one; constraints (budget, schedule, existing systems it must integrate with, organizational standards); and, critically, the underlying goals and rationale behind a stated requirement, because knowing why a stakeholder wants something lets the analyst propose a better solution if the stated requirement turns out to be infeasible or suboptimal.

Stakeholder analysis. Elicitation should begin with, not follow, an explicit identification of who the stakeholders are and what stake each has — direct end users, indirect users, those who are affected by the system without using it (e.g. a regulator), those who commission and pay for it, and those who will maintain it once built. A stakeholder-analysis matrix (often plotting influence against interest) helps decide how much elicitation effort each class warrants: a high-influence, high-interest stakeholder (e.g. the business sponsor) merits deep, repeated engagement, while a low-influence, low-interest one may be adequately served by a single survey question. Missing a stakeholder class entirely is one of the most expensive elicitation failures, because the gap is usually discovered only in acceptance testing or, worse, after deployment.

Suitability of elicitation techniques. No single technique surfaces every kind of requirement from every kind of stakeholder, so a competent elicitation plan matches technique to purpose. Interviews (structured, semi-structured or unstructured) are the workhorse technique for extracting an individual expert's detailed, tacit process knowledge, and are best suited to a small number of key informants rather than a broad population. Focus groups bring several stakeholders together to discuss and react to ideas as a group; they are efficient for surfacing shared problems and ideas and for stress-testing a proposal against multiple viewpoints at once, and a well-run requirements focus group ends with each stakeholder group prioritizing its own top wishes, so the analyst can make sure every stakeholder gets something from the product (see Part 1, item 10). Because of dominant-voice effects, however, they are a poor way to capture one individual's detailed, tacit process knowledge, which still needs an interview or observation. Questionnaires/surveys scale to a large stakeholder population and are well suited to quantifying how widespread a need is, at the cost of depth and of being unable to probe a surprising answer. Observation / contextual inquiry / ethnography watches stakeholders do their actual work and is uniquely effective at surfacing tacit knowledge and workarounds that no one would think to mention in an interview, because the expert is not consciously aware they are doing it. Document analysis of existing forms, manuals, regulations and legacy-system outputs grounds elicitation in artifacts that already encode real business rules. Workshops / JAD sessions combine several stakeholder classes to negotiate and converge on requirements in real time, which is efficient when disagreement (not discovery) is the main obstacle. Selecting among these is itself a requirements-engineering judgement call: tacit, individual expertise favors interviews and observation; broad prevalence questions favor surveys; and consensus-building or trade-off discussion favors workshops or focus groups.

Prototypes. Because many stakeholders cannot reliably state requirements in the abstract but can react concretely to something in front of them, prototyping is elicitation's most powerful technique for closing the gap between "what a stakeholder says" and "what a stakeholder actually needs." A low-fidelity prototype (paper sketch, wireframe, clickable mockup) is cheap to produce and to discard, so it is used early to settle scope and layout before committing to a design; a higher-fidelity, interactive prototype is reserved for validating a workflow that is already believed to be roughly right, because building one is expensive. Prototyping also directly mitigates several of the barriers above: it externalizes tacit knowledge (a stakeholder who cannot describe the reconciliation rule in words will immediately say "no, that's wrong" when a prototype does it incorrectly), and it moves the conversation past the horizon effect by giving stakeholders something new to react to rather than asking them to imagine it. The risk to manage is that a convincing prototype can be mistaken by stakeholders (and by the team) for a finished, verified implementation — the same trap examined in Part 1, item 4.

Putting it together. In practice these elements are not sequential phases but a loop: stakeholder analysis identifies who to talk to and about what; interviews, observation, document analysis and surveys elicit raw material matched to each stakeholder class; prototypes are built from the emerging picture and used both to elicit further detail and to validate what has already been captured; and focus groups or workshops periodically bring the picture back together across stakeholder classes to resolve conflicts before they are baked into a requirements specification. The loop repeats, at decreasing intensity, until new sessions stop surfacing materially new information — the practical signal that elicitation, for a given release scope, is complete enough to move into specification and validation.