Business requirements: Dispatch board

One paragraph the approving sponsor can repeat: the problem, the recommended option, and the headline benefit with its owner and date.

Dispatchers lose the first minutes of every job hunting across three screens for the right technician. This case recommends building the live dispatch board (total investment $380k to $520k) rather than licensing an off-the-shelf dispatch product, because Meridian's union rules and customer response-time contracts require assignment logic no vendor product expresses. The headline benefit, removing the dispatch-delay share of technician idle time, owned by J. Whitfield (operations sponsor), lands by March 31, 2027, two quarters after the October 1, 2026 Toronto pilot cutover, in service of the project's idle-time target (project PRD^[1]).

What happens today, as a measured fact, and what it costs. The template forbids adjectives here: "slow" is not a problem statement, "four minutes per job" is. When the problem lives in a process, the template shows the process: the loops and handoffs that cost the money, made visible.

The current process: where the four minutes go

BPMN 2.0: today's dispatch process, rendered by bpmn-js through Specira's diagram service. The loop on "ask around again" is the delay. Fallback: a job arrives → Dana checks the scheduling screen for who is free → the paper cheat-sheet for who is qualified → phones technicians for who is close → loops until confident → calls the chosen technician, four-plus minutes elapsed.

In the June 2026 sample, the average job waited over four minutes before anyone had even been asked to take it (assignment-delay sample^[5]). Four minutes per job, across three hundred jobs a day, is the single largest controllable slice of the 18% technician idle rate the project has committed to reducing.

Which project objective this serves (as a link, never a restatement) and why delay is costly.

This requirement serves the project objective "Technician idle rate at or below 10% by March 31, 2027"^[1] by removing its assignment-delay component. Why now: Meridian's two largest customer contracts re-tender in January 2027; the October 1, 2026 pilot cutover gives a full quarter of measured improvement before those tenders open.

The honest comparison. Every option is scored on the same criteria, and every verdict carries its evaluation trace: what the option is, why it was considered, who evaluated it, how, and what they found. A verdict without its reasoning is a conclusion, not a decision. The full comparison lives in the attached workbook; this section summarizes it.

* $700k/yr assignment-delay share × 3 years. A different quantity from the project-level $2.1M ANNUAL total idle cost the PRD cites: the delay share is the slice this requirement removes. Both derive from the attached cost model^[4].

How each option was evaluated

Full scoring, quotes, and reference-call notes: Options evaluation workbook^[3], attached to this package.

How the business (not engineering) will know this worked. Each criterion carries its agreed measurement methodology: how it is measured, how often and where it is reported, and who tracks it. Deciding this at approval is what prevents the downstream argument about whether "achieved" was achieved.

The business signs off when, and only when:

The benefit register. The template's rule is blunt: a benefit without a named owner, a measure, and a date is an aspiration, and aspirations don't enter the register.

Each measured benefit rolls up to the project's idle-rate objective (PRD success metrics^[1]). The chain from this requirement's output to the business outcome is explicit, so in a year we can tell whether the benefit actually landed and who is answering for it.

The full form: total investment stated, cost breakdown by category, timeline with its critical path, the payback calculation shown, and the sensitivities that matter, each with the number that triggers action. This investment is neither small nor easily reversible, so "accepted uncertainty" alone would not clear the template. The detailed model is attached; this section summarizes it.

Total investment: $380k to $520k (delivery, internal time, and first-year run, from the attached cost model^[4]). The upper end applies only if the union clarification forces propose-only rework.

Timeline and critical path. Build August to September 2026 · distance-proxy shadow trial September 1 to 14 (gates pilot commitment) · assignment-speed baseline September 1 to 26 · Toronto pilot cutover October 1 · remaining four hubs November 3 to December 12, gated by the PRD guardrails. Benefits start at pilot cutover, not at project end: the pilot hub's delay reduction is real recovered time from week one, a full quarter before the January 2027 contract re-tenders.

Sensitivity, with the numbers that trigger action. The result moves most on two assumptions. Adoption: the planned pace is 80% of Toronto dispatchers running full shifts on the board by pilot week four; at half that pace, payback slips roughly two quarters and the case still holds. Delay share: if revalidation (two additional hubs, before commitment, §12) shows the assignment-delay share more than 25% below the June sample, this case returns to R. Okafor before build starts.

The simple form, and when it is permitted. For a small, easily reversible spend, this section may shrink to: "Effort class: small. Under two weeks, one developer, no ongoing cost. Assumes the export API covers the fields (checked June 12). Qualifies for the simple form: reversible in a day, no contract or headcount impact." The qualification sentence is mandatory: the simple form is a justified choice, not a shortcut.

What the business needs the ability to do: one need per statement, in business language. How the system will behave lives in the functional spec each statement links to.

The rules this requirement must respect, each one a link to its knowledge-base entry, where the rule's full text and history live. Rule logic is never copied into this document, so the rule can evolve in one place.

The accountability register: one row per person, so it stays readable no matter how many parties are involved. Names here match the benefits register exactly; the full project responsibility grid lives at project level, not here.

Register entries trace to the project's stakeholder records^[8], linked, not redescribed.

What could stop the benefits landing. Every risk carries how likely (Likely = better-than-even odds; Possible = 10 to 50%), how bad (impact stated as its effect on the case), and what we do about it; a risk missing any of the three is incomplete and the template says so.

The remaining governance sections, rendered in the same discipline: every constraint cites its authority, every load-bearing assumption carries a validation plan, every open question has an owner and a date.

Everything this case points at. Package items travel in the same export bundle; workspace items link into Specira where the full record and its history live.

In this export package

In the Specira workspace

Omission note style: a BRD for a requirement with no applicable policies renders §9 as: "§9 Business Rules omitted: no policy constrains this requirement. Rationale recorded in adaptation event #2."