Requirements Definition for Field Rollout

Ch.1 Conveying accurately to the vendor

How to write the RFP and requirements document. Express functional requirements as "use case × CRUD," and don't miss any non-functional requirements (performance, availability, security, operations). Avoid vague Japanese phrasing and decompose to a "granularity judgeable Yes/No."

Ch.2 Requirements definition for field rollout

Write only from the vendor's view and "this isn't what we expected" happens in the field. Three bird's-eye tools prevent this.

• ─CRUD diagram — matrix of who can C/R/U/D on each screen
• ─Status transition diagram — surface all the states and transition conditions on the business workflow
• ─Operable period — whether operations are allowed after close / after month-end / across fiscal years

The "functional requirements = TO-BE" trap

Hear "functional requirements" and you tend to write screens and fields, but functional requirements are the TO-BE business workflow itself. Screens and fields are merely the means of implementing TO-BE. Flee from TO-BE and start making "screen mockups" and "unusable" happens in the field. The starting point of requirements definition is always the TO-BE business workflow.

Non-functional requirements when embedding AI

AI features can't get by on "it works." Make the following four points explicit as requirements. Run with them vague and operations stop after go-live with "the accuracy is low" or "we can't explain it."

• ─Acceptable accuracy range (precision, recall, the operational impact of false detections)
• ─The business flow on misjudgment (always draw the return path to human judgment)
• ─Accountability (can you show the operational owner why that judgment was made?)
• ─Retraining cycle (frequency of model updates / verification flow / rollback conditions)

ROI phasing

Build all the requirements at once and the ROI is poor. From a Pareto lens, put the "effective top 20%" in Phase 1 and the rest in Phase 2. Proceed in the order: verify Phase 1's effect → reconsider Phase 2's priorities — and field agreement is easier to secure too.

The 3 big omissions that recur in the field

From the gap catalog that real projects "always read through at the final requirements review," here are the three that recur most. Fail to write these and it always blows up after go-live.

• ─Master maintenance features — "the supplier master can't be added," "who updates the product master?" become problems after go-live. For each master, write into the requirements who can C/U/D and on which screen
• ─Data migration requirements — release gets postponed right before go-live over "what do we do with the old data?" Put into requirements the migration-target list / when, how, and who / the verification period (at least one week)
• ─Printing and form output — after go-live, requests like "we want to print A4 for audits" or "in the invoice format" arise. Don't assume only screen operations; imagine all the way to paper-based work

The trap of writing only the "happy path," and the 3 exception flows

When writing functional requirements, imagining only the "cases that go well" is the most common failure. For each functional requirement, always consider three exception flows and write the use case's Alternative Flow.

• ─Input errors (invalid values / missing required fields / format violations)
• ─System errors (external API down / DB failure / timeout)
• ─Operational exceptions (insufficient permissions / concurrent-execution conflicts / state-transition violations)

Quantify performance, peak, and logs

Write non-functional requirements qualitatively — "snappy," "comfortable" — and "too slow to use" happens after go-live. Always quantify the following.

• ─Performance: define "within X seconds" for each major feature / peak-time concurrent access / batch completion time
• ─Peak load: state the operations that concentrate at month-start, month-end, and peak season, and design for peak (3× load), not average
• ─Logs / audit trail: what operations to log / retention period (7 years, etc., per industry regulation) / tamper prevention
• ─Backup: frequency (daily / weekly) / RTO (recovery time objective) / RPO (recovery point objective)