A Requirements Workshop That Ends With a Document

A workshop agenda built backwards from the document cells it must fill, an invite list read off decision rights, and three bins for whatever leaves the room.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece uses the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources, namely a published returns policy [POLICY], help centre articles [HELP], ten public complaint threads I selected myself [THREADS n=10], consumer law [LAW] and a walk through the published customer journey [WALKTHROUGH]. No client, no engagement and no workshop: nobody inside the company was asked anything. So the workshop below is a design, marked [MINE], for the first session the case would need once someone had access. What the case does have is two dated review sessions, and their record is the best evidence I have for what a session should leave behind.

A requirements workshop is a working session whose output is fixed before it starts: a named set of cells in a named document, each of which leaves the room holding a decision with an owner, an open question with an owner, a date and a fallback, or a written reason it is out of scope.

The interview piece built questions for one person at a time, from the case's open questions. A workshop serves a different need: the cells that only fill when two people with different decision rights hear each other say it.

In short

• Write the agenda backwards from the document. Each block names the cell it fills, the rule for "filled", and what the cell holds if the block runs out of time.
• Read the invite list off the decision-right column of the stakeholder map, not the org chart. In the returns case that puts the warehouse goods-in lead in the room and keeps legal out of it, with a written question instead.
• Everything leaves in one of three bins: decided, open with a fallback, or out of scope with a reason. A fourth bin, "discussed", is where workshops lose their output.
• The minutes have the shape of a review log: who said it, what changed in which section, and what did not change and why. The case's two review sessions produced five entries in that shape, and four of them changed the document.

Why does a workshop need its output named in advance?

Because otherwise it ends with a photo of a whiteboard. The Wikipedia article on joint application design, the workshop method developed at the New York Telephone Company's Systems Development Center in the mid-1970s, says it in one line: "In general, the deliverables from a workshop are documentation and a design." It also gives the scribe a job description worth copying: "Records and publish the proceedings of the meeting and does not contribute information to the meeting."

An agenda of topics ends when the time does. The requirements elicitation article, following Christel and Kang (1992), names problems of scope first, where "the boundary of the system is ill-defined". A topic-shaped agenda brings that problem into the room. A cell has a boundary: filled or not.

What the case had instead of a workshop

Two review sessions, recorded in section 6 of the case. On 2 April 2026 a developer on the delivery side read the document, starting from the process model. On 6 April a business analyst who reviews requirements documents for a living read it, asked to be unkind. Neither works for the retailer, so these are peers testing a document, not stakeholders confirming their own process.

Their record is what I would want from a workshop:

Five objections, four accepted, one held with a reason. Every row lands on a section. Nothing in the log says "discussed". That is the standard for the workshop below, and it is scorecard check 19: "Every entry names who raised the objection, what changed as a result, and the date."

One entry matters for the end of any session. RL-02 closes with: "One vague sentence was concealing two decisions." A sentence agreed out loud hides decisions the same way, which is why the plan below ends with a read-back.

Start from the page: the agenda as a list of cells

The case leaves several cells that no source outside the company can fill, and some of them need two decision rights in the same conversation. Those are workshop material. A cell one person can settle goes to an interview or an email and stays off the agenda.

The agenda for the first session, built that way [MINE]:

Three notes on the table.

Block 1 is the gap nobody has logged. The case's as-is says of the evidence step: "No written test exists. Two agents can reach two answers on the same photographs." The gap analysis piece found that this test is neither changed by the to-be nor listed among the things deliberately kept. A cell that neither list owns needs both rights at once: the agent who applies the test daily (the map gives that row "Whether the evidence is 'enough' today") and the manager who owns the published promise.

Block 2 exists because of one row. The stakeholder map calls the goods-in lead "the row nobody invites", and the one-page summary asks: "Put the goods-in lead in the room before anything ships." REQ-017 was written for that role without anyone in the role reading it. Block 2 is where that changes.

Blocks 3 and 4 have one approver each, so why are they here? Block 3 because adopting BR-12 commits people to staff what REQ-015 asks for. Block 4 because the rota question is the Head of Customer Care's call, but someone has to be on the rota. The case does not say who staffs it, and OQ-04 still asks for its owner. My assumption [MINE] is that the frontline agents would, which is why they hold a seat in both blocks. If either block looks like an email when you plan your own session, send the email.

Who is in the room, read off decision rights

Scorecard check 04 gives the reason: "Titles tell you who attends the meeting; decision rights tell you who can stop the work". The case's map uses A (approves), V (vetoes), D (decides in practice), C (consulted) and I (informed). The invite list follows from it:

Three people, on purpose [MINE]: every seat holds a right that one of the cells needs. Before adding anyone "to be safe", ask which cell they would fill. If none, they read the output.

What leaves the room?

Every cell ends in one of three bins, and the case already has a written form for each.

Decided. A sentence, the person who said yes, and the section it goes back into. The governance piece draws the line that matters here: for an observed rule the owner confirms, for a proposed rule the owner adopts. Block 3 is an adoption, so the minutes say "adopted", not "agreed".

Open. An open question with an owner, a date and a fallback, because, in the case's words, "An open question without a fallback is a wish." A block that ends with that row still produced something.

Out of scope, with a reason. Section 1.5 keeps two tables apart: what is excluded, and what is "not decided yet, which is not the same as out of scope". Its warning fits a workshop even better than a document: "Items in the first table are gone. The item in the second one is coming back, and it will come back at the worst possible moment unless it has a date on it."

There is no fourth bin. "We discussed it" is the state scorecard check 21 is written against: "An objection parked in the 'we discussed it' state comes back later, usually from somebody more senior and in front of more people."

The read-back is the cheapest control in the session [MINE]. Ten minutes before the end, read each filled cell aloud in its final wording. A duration with no start event, a list ending in "etc.", "the team" where a name should be: each is RL-02 again, caught before the room empties rather than at the next review.

The workshop sheet, filled in

One page, written before the session and completed in it. Every value comes from the case. The session never happened, so the cells say what the case needs, not what anybody said.

The workshop sheet, blank

Where is this method weak?

It is untested on this case: the agenda above is a plan built from a document, and the first real session would change it. It assumes a draft exists. In early discovery the first session fills a brief rather than cells. And it says nothing about running the room, which is facilitation and has its own literature.

What it does cover is a workshop whose end can be checked by someone who was not there: open the document, find the cells, read the dates. If your minutes pass the review log checks (19 to 21) in the scorecard, the session produced a document.

All field notes · The portfolio guide · More in The Case File