Dialog Maps and Event-Response Tables
In short A dialog map shows how a user moves between the screens or dialog elements of a system, without designing any of them. An event-response table lists what the system must do when something happens in its environment, given the state it is in. Both are cheap ways to find requirements nobody mentioned.
Based on: K. Wiegers, J. Beatty, Software Requirements, 3rd ed., ch. 12.
On this page
Key ideas#
Dialog map#
A dialog map is a state-transition diagram applied to a user interface. Each box is a dialog element: a menu, a window, a work area, a command prompt. Each arrow is an allowed transition, labelled with the condition that triggers it.
It deliberately shows no layout or visual design, only the structure of the interaction. That is why you can draw it during requirements analysis, before anyone designs screens.
Wiegers and Beatty name four kinds of trigger:
- a user action, such as a click, gesture or keyboard shortcut;
- a data value, such as invalid input leading to an error message;
- a system condition, such as a printer out of paper;
- a combination of these.
They advise leaving out global transitions, such as help available from every screen or the browser’s back button. Drawing them clutters the map; a single text requirement saying the function exists is enough.
A dialog map differs from a flowchart. A flowchart shows process steps and decision points. A dialog map hides the decisions inside the boxes (usually the user’s choice) and writes the conditions on the arrows.
Related notations include the navigation map (Constantine and Lockwood), which is richer, and the user interface flow (Beatty and Chen), which presents the same idea in swimlanes.
Why bother? Users looking at a dialog map spot missing paths. In the book’s example, reviewing the map revealed that cancelling a whole order needed a confirmation step to prevent accidental data loss. The map is less a design record than another way to find missing requirements. It is especially useful for a complex use case: sketch it on a whiteboard during an elicitation workshop and walk through it with participants.
Event-response table#
An event is a change or action in the system’s environment that the system must respond to. An event-response table (also called an event table or event list) lists each event with the required response. It is an alternative to use cases where use cases fall short, typically in real-time systems, where behaviour depends less on a user’s intent than on external signals and timing.
Wiegers and Beatty distinguish three classes of event:
- Business event: a user action that starts a use case.
- Signal: data or an interrupt from outside, such as a switch, a sensor, a touch, or a request from another system.
- Temporal event: a time is reached or a period expires, such as a nightly export or a sensor reading every ten seconds.
The crucial point is that the response depends on both the event and the current state of the system. The book’s example is a car’s windscreen wipers: the same control action produces different results depending on whether the wipers are already running. So the table usually has columns for the event, the system state, the response and, optionally, the state afterwards, how often the event occurs, and the data needed to handle it.
To find events, Wiegers and Beatty suggest two routes: for each state of the object you are analysing, ask which events lead into it; and scan the context diagram for external entities that can trigger something.
How to apply it#
Dialog map:
- Take one use case or user task.
- Draw a box for each dialog element the user needs; name it by purpose (“Choose slot”), not by screen design.
- Draw arrows for every allowed transition and write the trigger on each.
- Walk through normal, alternative and error paths with users. For each box, ask: how do I get here, how do I leave, what if I want to cancel or go back?
- Turn every new path into a requirement or a question.
Event-response table:
- List external entities from the context diagram and the events each can cause.
- Add temporal events: deadlines, schedules, timeouts.
- List the states of the system or main object.
- For each event and state combination that matters, write the required response.
- Check for gaps: events with no response in some state, and states no event can reach.
Example#
Dialog map for online booking at The Workshop (a fictional bike-repair chain):
- Home → Choose workshop (user selects “Book a repair”)
- Choose workshop → Choose slot (workshop selected)
- Choose slot → Enter bike details (slot selected)
- Choose slot → Slot taken (slot booked by someone else meanwhile: a data condition)
- Enter bike details → Confirm booking (details valid)
- Confirm booking → Home (user cancels)
Walking through it, a workshop manager asks what happens when a customer cancels at Confirm booking after entering long fault notes. The team adds a requirement: ask for confirmation before discarding entered details.
Event-response table for repair notifications:
| Event | Class | System state | Response |
|---|---|---|---|
| Mechanic marks repair done | Business | Repair in progress | Set status to “Ready”; notify customer |
| Mechanic marks repair done | Business | Waiting for part | Reject; ask mechanic to record part arrival first |
| Supplier confirms part dispatch | Signal | Waiting for part | Update expected date; notify customer of delay or new date |
| 18:00 daily | Temporal | Ready, not collected for 3 days | Send reminder to customer |
The second row exists only because the analyst asked what the same event means in a different state.
Sources and further reading#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 12 (dialog maps; event-response tables).