Eliciting requirements from people and documents

The previous module asked you to write verifiable goals. This one asks the question underneath: where does the content of those goals come from?

Not from the team. A team that invents requirements builds what it imagined, and finds out in June that the trainer never wanted it. Requirements are elicited — from the people who have the problem, and from the documents they already work with. In German the discipline is Anforderungsanalyse, and its four classical techniques are:

Nobody uses one alone. They compensate for each other’s blind spots, and the order in which you use them decides how much of somebody else’s time you waste.

Document analysis comes first because it is the only technique that costs nobody else anything. Walking into an interview already knowing the fields of the form, the vocabulary and the volumes means you can spend the hour on what only a person can answer — why the third column is always empty, and what happens when somebody cancels twice.

The reverse order is the classical beginner’s mistake: an hour of an expert’s time spent asking things the form on their desk answers, followed by an interview that never gets to the real question.

An interview is a conversation with a goal you wrote down beforehand. Three forms, and you will mostly use the middle one:

Preparation, in order: read the documents; write down what you want to know at the end; turn that into six to ten questions; decide who else must be in the room. An hour is the maximum that stays productive.

Open questions produce content, closed questions produce confirmations.

The left column is suggestive: it offers the answer, and a polite person agrees with it. What you then have is your own idea with somebody else’s name on it.

Two rules for afterwards. Write the protocol the same day — after two days you remember your interpretation, not their sentences. And send it back for confirmation; the corrections that come back are usually the most valuable sentences of the whole exercise.

A questionnaire reaches many people cheaply and produces numbers: how many trainers, how often per week, how many members per group, how important is feature X on a scale of one to five.

What makes one usable:

Its place is after the qualitative work: interviews tell you which questions are worth asking, the questionnaire tells you how widespread each answer is. Used first, it asks the wrong things very efficiently.

Watching the work happen, at the place where it happens. It is the only technique that shows the difference between the process as described and the process as performed — and that difference is where most requirements hide.

What it typically turns up: the second spreadsheet nobody mentions because it is "not part of the system", the sticky note with the abbreviations, the step that is skipped when it is raining and the hall is full, the double entry that exists because two systems do not talk to each other.

Two limits belong to the method. People behave differently when watched — the Hawthorne effect — so the first twenty minutes are usually a performance, and you stay long enough for the normal day to reassert itself. And it is expensive: half a day gives you one workplace, not a survey.

Practicalities: announce it, explain that you are studying the process and not the person, take notes on actions and times rather than on impressions, and ask your questions afterwards rather than during.

The technique that gets skipped and pays best. Everything the organisation already writes down is evidence about what it does — and it can be read before you have met anybody.

How to run one:

What it cannot do: a document shows the rule, never the exception somebody makes every Friday, and it cannot be asked why. That is exactly the division of labour with the interview.

Elicitation is finished when it has produced three things, all of which go into the repository:

The third one is the one teams skip, and it is the cheapest insurance in the project: an assumption that is written down can be corrected in a five-minute conversation, an assumption that lives in somebody’s head is discovered at the acceptance.

Classically these findings are written into a Lastenheft — the client’s statement of what is needed — which the contractor answers with a Pflichtenheft. Both documents, and where their content lives in this course, are the subject of sdd-why-specs.