Elicit requirements with origin and rationale

Conduct elicitation around a concrete question

Planning a technique and conducting elicitation are related but different activities. During the session, check what the technique actually reveals. If the question is which information enables recovery after an instruction fails, a discussion of dashboard colors loses focus.

Explain the objective, intended use of notes and session boundaries. Start with the participant’s work and decisions, allowing an episode to be described before presenting your interpretation. Follow up on conditions, inputs, sequence and expected outcome.

Also ask why an action matters. A requirement without rationale may preserve an accidental limitation of the old tool. If an out-of-scope issue emerges, record and route it rather than forcing every need into the solution you already know.

The session produces information for analysis, specification and validation, not automatic approval of everything said.

Observe work and explore what did not occur

In authorized observation, distinguish the sequence witnessed from the explanation supplied. You may have seen an operator consult three screens and heard that the second prevents repeating an already executed operation. These are different types of information, both useful.

Ask when the sequence changes and request examples of a rejection, a timeout and partial recovery. Do not cause real incidents to complete an exercise; use sanitized examples or an authorized simulation where appropriate. One uneventful execution does not establish that exceptions are absent.

A log does not tell the whole story either: it may show sending and receipt without explaining the human decision between them. Connect observation, permitted artifacts and the person’s account while retaining discrepancies for investigation.

Before proposing removal of a step, understand its purpose and the condition in which it may be needed.

Interviews, groups and distributed participation

An interview can explore an experience and clarify meaning with less group pressure. A workshop can compare interpretations and build shared understanding if differences remain visible. Use an initial round where each participant describes the event before solutions are discussed.

If someone dominates the conversation, make room for specific contributions without assuming quieter people agree. For distributed teams, send a short summary and bounded questions while keeping a channel for asynchronous corrections. A questionnaire can broaden collection, but question wording shapes the answer.

Asking whether desired automation should be fast and secure reveals little. Asking which decisions become blocked, how often and under which conditions produces more useful clues. Record who responded and which perspectives are missing; response volume does not replace coverage of relevant conditions.

A record that retains origin and rationale

Use simple fields that allow information to be revisited: note identifier, origin, relevant date or version, context, observation or account, interpretation, rationale and open question. Unnecessary personal data need not be collected; a role or participant identifier may suffice within the authorized process.

If APS says it needs to confirm the previous outcome before retrying, retain that purpose. A suggestion to wait thirty seconds is a separate statement still needing justification. Link a proposed requirement to the note without changing the note’s status to approved.

When a source corrects meaning, retain the earlier version and correction rationale to identify dependent conclusions. Traceability comes from useful, maintained relationships rather than field count. A reader should be able to distinguish what the person actually confirmed from what the analyst inferred or proposed.

A short record could read: N4, source APS operator, context recovery after timeout, account empty queue, interpretation outcome still unknown, question which evidence confirms execution. This retains a useful observation without inferring that absence from the queue means completion.

The next question can be routed to someone familiar with the queue consumer.

Confirm meaning and handle incomplete information

Return the interpretation in language the source recognizes and include an example that might contradict it. If you understand that every retry requires renewed authorization, ask whether that also applies when submission was rejected before processing.

A response may reveal a previously omitted condition. When the person does not know, retain the question and identify who can clarify it rather than filling the gap with the option most convenient for development. At the end, summarize collected information, confirmed interpretations and points still needing analysis or decision.

Interview confirmation does not establish technical feasibility or solution acceptance. There may be enough information to start bounded analysis while an exception remains open. Make that dependency explicit so subsequent work knows which conclusions may still change.

Workshop: notes, interpretation and next question

In part B of the workshop, you have a state-check observation, an account of recovery and a proposal for automatic retry. Record the witnessed event, stated need and suggested solution separately. Write two questions that could reveal an exception and an English summary for confirming understanding with an international team.

The worked example retains outcome confirmation as a candidate need and leaves open whether a reliable state exists across all systems. It does not turn a thirty-second preference into an approved interval. A second note says that, for certain rejections, the operation never started; that distinction may change required behavior before retrying.

Compare your answer by its rationale: did you preserve origin, context and uncertainty? Does your question allow the hypothesis to be challenged? Can you explain what remains undecided?

The exercise is individual and uses fictional data. Completing the file does not demonstrate that you conducted interviews or have observed facilitation competence.

Common pitfalls

Copying an interface as a requirement; generalizing one observation; embedding the answer in a question; treating silence as confirmation; recording a conclusion without its origin and limits.