Discover the Workflow People Actually Perform
Requirements are not waiting in a meeting to be collected. They are scattered across actions, workarounds, records, and disagreements. Model the current workflow as ordered actions with evidence. Separate direct observation from reported or inferred behavior. Locate friction, handoffs, authority, and hidden state. Keep uncertain claims visible instead of turning them into requirements. Do not begin by asking what features people want. Begin by reconstructing what happens now. For each step, record: The workflow is larger than the screen. It includes waiting, copy-paste, side channels, approval, error recovery, and the steps people have stopped noticing. Use a simple evidence ladder: Direct behavior: observation, trace, recording, or system event. Artifact: ticket, runbook, log, form, or completed output. Reported behavior: a person describes what they do. Inference: the team concludes what probably happens. All four can be useful. Only the first two prove current behavior directly. Label the rest so confidence does not silently inflate. Friction: repeated effort, delay, re-entry, or recovery. Hidden state: facts carried in memory, chat, or personal notes. Authority: the person or system allowed to make a consequential change. Exceptions: the case where the normal workflow stops being normal. AI features often fail at handoffs and exceptions because the happy path was the only path shaped. Two users can perform different workflows for good reasons. Preserve the variants…
Discover the Workflow People Actually Perform: Requirements are not waiting in a meeting to be collected. They are scattered across actions, workarounds,…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.