No Documentation, Twelve Hundred Rules
Coastline Logistics is replacing a 17-year-old customs declaration system. The original developers have left, there is no current specification, and roughly 1,200 validation and duty-calculation rules live in three places: hard-coded in the legacy application, in 40 linked spreadsheets maintained by the duty team, and in the heads of four operations staff. Those four describe the process differently, and one insists the system just knows when asked how a particular exemption is applied. Discovery is capped at six weeks before build starts, with two BAs and limited access to operations staff because the team is handling peak season. An external auditor has said duty must be calculated correctly and that errors will be treated as a compliance breach. The sponsor wants a complete rules catalogue before development begins.
1. Which techniques would you use in the six weeks, and in what order? Justify the sequence.
Read the worked answer
Sequence by risk and by scarcity of access. Weeks one and two: document analysis of the legacy code, the 40 spreadsheets and historical error logs. This is the cheapest source and gives a candidate rule list plus a trace from each rule back to its origin. In parallel, short structured interviews with the four operations staff, focused on exceptions and on why the spreadsheets exist, since spreadsheets usually encode a workaround someone needed.
Weeks two to four: observation or job shadowing of live declarations, half a day per person if that is all peak season allows. Tacit rules such as the exemption will not be recalled in a meeting but will be performed in front of a case. Capture real declarations as test cases while you watch. Weeks three to five: decision tables for duty calculation and exemption logic, because tables force contradictory or missing conditions into the open and are directly testable. Review them with operations and the auditor. Weeks four to six: example mapping on key declaration scenarios and a story map to slice delivery, plus a small prototype of the highest-risk calculation validated against 50 historical declarations.
The reason for this order is to spend scarce operations time on contested and tacit knowledge, not on what can be recovered from artefacts, and to use checkable outputs rather than prose. A large requirements workshop in week one would likely manufacture false consensus among four people who disagree.
2. The sponsor wants a complete rules catalogue before development starts. How do you respond?
Read the worked answer
Say clearly that complete is neither achievable in six weeks nor the right target, and that claiming otherwise creates the compliance risk everyone is trying to avoid. The auditor's requirement is correct duty calculation plus evidence of control; a catalogue is one means to that, not the requirement itself.
Propose a versioned catalogue prioritised by risk, with duty-bearing rules and exemptions first, each carrying its source, owner, review status and linked test case. Maintain alongside it a known-unknowns register listing rules that are unresolved, who owns them and by when. Agree with the auditor what evidence of correctness looks like - reconciliation against legacy outputs for a sample period plus a parallel run is stronger evidence than a document, and it is available earlier.
Start build on the highest-risk, best-understood rules and let the catalogue grow with the system, with operations reviewing each rule and signing it off. Set a measurable exit criterion rather than a document milestone, for example every duty-bearing rule has a reviewed decision table and passes a defined set of historical declarations before go-live.
3. The four operations staff disagree about how an exemption is applied. How would you resolve it?
Read the worked answer
Treat the disagreement as data. It usually marks one of three things: genuine variation by site, commodity or customer type; an error someone has been quietly correcting; or a practice that has drifted from policy. None of these is resolved by averaging views or deferring to the most senior person.
Use concrete artefacts. Take four real past declarations and have each person work the same case, recording where they differ. Build a decision table that forces the branch conditions into the open. Shadow each person doing the task, and compare what they do with what the legacy code and spreadsheets actually do. Then classify each difference with the group: model it as a rule branch, correct it, or retire it - and if a practice is being retired, tell the auditor rather than leaving the old behaviour in production.
Record the resolution, its owner and the evidence behind it in the catalogue. This is faster and far more defensible than seeking agreement in the abstract, and it gives the auditor a trace from decision to evidence, which is what the compliance finding will actually be judged on.