The second decision gate: is it ready to build? Refine the approved Gate 1 into a design — requirements, architecture (with security in it), and how each acceptance criterion will be met.
Mirrors the canonical FSD-FRM-02 — FitSD v0.2.0; the canonical form is the authority, so review before use. Nothing is sent to any server — this runs entirely in your browser; download a Markdown record to save your progress.
Resuming a saved form? Load a .md you (or a teammate) downloaded earlier to pick up where it left off — read in your browser only, nothing is uploaded.
.md
Reference to the approved Gate 1.
Summarise the approved Gate 1 — outcome sought, value and effort — updated as more is now known.
Functional and technical requirements as user stories, MoSCoW-rated.
As a … I want … so that …
Sketch the architecture and where it fits the wider estate. Show where security sits in it. Note any departures from the team's design principles.
Paste a link to the diagram (or describe it). Image upload isn't supported in this one-shot form.
Where and how security is embedded.
Departures from the team's design principles, if any.
If applicable.
Dev / ongoing.
Does this force changes to change, incident or other processes? Note which capability — FSD-CH / FSD-RR / FSD-SA.
State how each criterion will be met. Each is proven later on the Service Acceptance Record.
Which docs (HLD, runbook, recovery, user) and where they will live.
What is backed up, frequency, retention, location — and how a test restore will be proven.
Hardening, patch path (FSD-RR), vulnerability posture, any exceptions (FSD-SA).
Access model — roles, least privilege, grant/revoke, admin control, JML handling.
Expected availability / SLO, capacity & scaling, DR considerations.
What is monitored, thresholds, where alerts route.
What counts as an incident for this service — triggers and severities — to register with incident management.
Operating & support model, runbook, training; how continuity is assured — cross-training / knowledge capture so it isn't reliant on one person.
Expected run-cost and licences.
Risks, Assumptions, Issues, Dependencies, Decisions.
Keep proportionate: person-days by role/workstream, not a full FTE model.
Person-days, by role / workstream.
Purchase / one-off.
Ongoing run / licensing.
Sign-off authorises progression to delivery. Build and deployment changes are then raised through Change & Release (FSD-CH).