Elicitation: the meeting, the scenarios, the work products

Asking is the hard part

Elicitation looks like the easy task on the list. Ask the customer, the users and everyone else what the objectives are, what has to be accomplished, how the system fits the business, and how it will be used day to day. In practice it is very hard, for reasons that have nothing to do with anyone being difficult: goals are unclear, priorities differ, assumptions go unspoken, the same word means different things to different people, and requirements arrive phrased so that nobody could verify them.

A useful discipline is to elicit goals first. A goal is a long-term aim the product must achieve, and goals may be functional or non-functional. Goals are good currency with stakeholders — they can be explained, they can be prioritised, and once written down they become the reference you use to settle a later conflict rather than re-litigating it. The intent of elicitation, overall, is to move ideas from stakeholders into the team smoothly and without delay, knowing that new requirements will keep emerging as the product develops.

The collaborative gathering meeting

The stronger instrument is a joint meeting run to rules. The guidelines are simple and every one of them is load-bearing. The meeting is attended by software engineers and other stakeholders together. There are rules for preparation and participation. The agenda is formal enough to cover the important ground, informal enough to let ideas flow. A facilitator — who may be a customer, a developer or an outsider — controls the meeting. And there is a definition mechanism: a wall of paper, a whiteboard, sticky notes, a shared forum, anything that lets an item be written, moved, merged or deleted.

A one- or two-page product request is written during inception and circulated beforehand. Reading it, each attendee prepares four lists: the objects that surround, are produced by, or are used by the system; the services that act on those objects; the constraints (cost, size, business rules); and the performance criteria (speed, accuracy, security). Nobody is asked to be exhaustive — the lists are asked to reflect each person's perception.

In the meeting, the individual lists are presented and merged into combined lists with duplicates removed and nothing deleted. Discussion then shortens, lengthens or rewords the combined list until there is consensus. Critique and debate are prohibited during the presentation phase; shooting down a customer's idea as too costly is exactly how you stop hearing ideas. Where an entry needs more than a line, a mini-specification is written for it, or a use case is developed. Anything unresolvable is written on an issues list and acted on later, so the meeting keeps moving.

One rule protects the whole exercise: if the system will serve many users, elicit from a representative cross-section of them. If a single user defines everything, acceptance risk is high — several other stakeholders will meet the product for the first time at delivery, and will not accept it.

Usage scenarios, and what elicitation leaves behind

A vision of features is not enough to start technical work; you need to know how the features will be used by different classes of user. So developers and users write usage scenarios — threads of usage, told informally — which are the raw material that later becomes use cases and, after elaboration, the scenario-based, class-based and behavioural elements of the requirements model.

For a large system the elicitation work products are: a statement of need and feasibility; a bounded statement of scope; a list of the customers, users and other stakeholders who took part; a description of the technical environment; a list of requirements organised by function, with the domain constraints attached to each; and a set of usage scenarios covering different operating conditions. Each one is reviewed by everyone who participated. For a small system the same six shrink to a page, but none of them disappears.

Worked example — the first BorrowBox meeting

The product request is a page from the neighbourhood board describing a tool library with unattended pickup. Six people attend: two members, the librarian, the depot admin, a software engineer and a facilitator. The combined object list comes back as member, tool, tool copy, reservation, locker, locker bank, damage report, late fee. The service list is reserve, cancel, collect, extend, return, inspect, charge. Constraints: one depot, an existing locker product the board has already bought, a grant that expires in nine months. Performance: the locker opens quickly, a member finds a tool in a few taps. The word quickly is flagged immediately and left as an issue, because it cannot be validated as written.

The librarian's entry tool condition needs more than a line, so it gets a mini-spec: condition is graded on return, on a four-point scale, by the librarian, and a grade below the third point takes the copy out of circulation. That mini-spec surfaces a service nobody listed — retire a copy — which is exactly what the exercise is for. And the argument about how long a hold should last does not get settled in the room; it goes on the issues list and becomes the first item on the negotiation agenda.