A payroll platform's use-case diagram has grown to 31 tiny use cases that read like a function list — how do you diagnose and fix it?

## The symptom, and why it is a real defect A use-case diagram exists to settle one argument: what is inside this system and what is outside it. It does that with very few marks, which is precisely why it works in a room. Thirty-one entries is past the point where a reader can hold the picture, and when the entries are named "Enter employee identifier", "Validate employee identifier", "Load tax band", "Compute gross", the diagram has stopped making a scope claim and started listing implementation steps. This failure has a name: **functional decomposition**. It is not merely untidy. Three concrete things break. - **The boundary argument disappears.** Nobody asks "is this ours?" of "Compute gross", so the one question the diagram is good at goes unasked. - **Review meetings become spec-reading.** An eleven-person team walks the 31 boxes instead of arguing about the four decisions that matter. - **The model tracks the code, not the users.** Every refactor invalidates the picture, so it rots, and a rotten diagram is worse than none because people still cite it. ## The test for the right level One question decides it for every entry: **would the primary actor walk away satisfied if only this completed?** A use case is a **goal of value to an actor**, not a step towards one. Supporting heuristics that interviewers like to hear: - **One sitting, one actor, one occasion.** A use case is normally something one primary actor completes in one go — minutes, not a quarter. - **State it as a success outcome.** If you cannot finish the sentence "afterwards, the actor has …", it is a step. - **Name it from the user's side**, active verb plus object, in the actor's vocabulary: "Correct a paid payslip", not "Update payslip record". - **Watch for the create-read-update-delete explosion.** Four entries per entity is a database schema wearing a diagram's clothes. - **Watch for screen names.** "Open the payroll summary screen" is a navigation step, and navigation is not a goal. | Level | Example | Belongs on the diagram? | |---|---|---| | Summary | Administer the payroll year | Rarely — too coarse to scope work | | Goal | Run monthly payroll | Yes — this is the level a use case sits at | | Step | Compute gross for one employee | No — it belongs in the written flow | | Data operation | Write a row to the payments table | No — it is implementation | ## How this happens Almost never at once. The common path is a stakeholder — on this platform, a founder who changes priorities weekly — who asks for something new, and the fastest way to acknowledge it is to add a box. The diagram is visible, so it becomes the place requests are parked. After a few months the picture is an unordered backlog of requests drawn as ovals, and its original job is gone. A second path is a team that treats the diagram as documentation to be *completed* rather than an argument to be *settled*, and completeness pressure always pushes towards decomposition. ## The repair 1. **Sort the 31 entries against the satisfaction test.** In practice a handful pass. Seven goal-level use cases is a normal answer for a platform this size. 2. **Attach each failing entry to the goal it serves**, as a numbered step in that use case's written flow. Nothing is lost — the detail moves to where it can change without redrawing. 3. **Rename the survivors from the actor's side.** If a name only makes sense to someone who has read the code, it is not a use case name yet. 4. **Re-derive the actors** from the survivors, and check each one is genuinely outside the boundary. 5. **Redraw the boundary and re-run the scope argument**, which is the whole reason to do the work. Expect at least one entry to move out of the box. 6. **Agree a rule for new requests** — they go where work is tracked, and only reach the diagram when they change the scope claim. ## What to say about relationships while you are there A decomposed diagram usually carries a thicket of relationship arrows added to reconnect the fragments. Most of them evaporate with the fragments. Resist the urge to keep them: relationship arrows between use cases are worth drawing only when they change what a reader concludes about scope, and a diagram that needs arrows to be readable is telling you the entries are at the wrong level. ## What interviewers are checking They want to see that you know what the artefact is *for*, and that you will shrink a document rather than grow it. Candidates who answer with layout advice — grouping, colours, a second page — have missed that the level of the entries, not the presentation, is the defect. The strong answer names functional decomposition, gives a one-sentence test anyone can apply, and finishes by pointing back at the boundary.