Start with one completed piece of work

A replacement project often starts with a list of screens, reports and integrations in the current system. That list is useful, but it describes the software more accurately than it describes the work. The difference appears as soon as one completed request is followed through the organisation.

Choose a request that is recent enough for the people involved to remember, and ordinary enough to expose the normal process. An exceptional complaint or unusually large order will pull the conversation towards special handling. A perfect example can be just as misleading because nobody had to resolve an error. A useful starting case has a recognisable beginning, a result that somebody accepted, and enough records to show how it moved.

Collect the material before the walkthrough where possible. This might include the original request, system records, messages used for clarification, approvals, exported files and the final confirmation. Private information should be removed or masked. The aim is to see which artefacts carried the work, not to turn a person's case into workshop theatre.

During the walkthrough, ask the person doing each step to show what they received and what they produced. A general description such as "operations checks it" is too broad. What does the checker open? Which fields do they compare? Where do they look when the values disagree? How do they know the check is complete? Those questions turn a named stage into observable work.

Write down the boundaries of the example as well. Record its request type, channel, responsible team, starting state and accepted end state. If the process differs by region, customer type or contract, note which branch this example followed. Otherwise a particular path will quietly become the assumed universal process.

One case cannot establish every requirement. It does give the team a concrete path to test against the next case, which is more useful at this stage than a tour through every menu in ageing software.