| name | 19-game-software-requirements-specification |
| description | Use when specifying testable game software requirements for player experience, gameplay state, platforms, multiplayer, saves, content, performance, accessibility, telemetry, security, builds, release, or live operations. |
| metadata | {"portable":true,"compatible_with":["claude-code","codex"]} |
Game Software Requirements Specification
Use When
- A game needs a controlled SRS across client, server, content and operations.
Do Not Use When
- The concept is unbounded; use the game product brief first.
- Do not prescribe engine or service APIs without a pinned decision.
Required Inputs
| Artefact | Source or provider | Required? | Behaviour when missing |
|---|
| Approved brief, journeys, target matrix, rules and risks | Product, design, engineering and production | Yes | Stop affected requirements and issue a gap record. |
| Online, economy/ads, learning, wellbeing, data, safety, culture/rights, visual and platform obligations | Specialist owners | Conditional | Exclude or mark the feature blocked. |
Workflow
- Establish boundaries across client, authoritative services, platform services, content/build pipeline and operations.
- Assign
GREQ-* and specify action, precondition, authoritative transition, feedback, failure and oracle.
- Specify saves, time/randomness, input, content, gameplay accessibility, localisation, age treatment, learning evidence limits, wellbeing/stopping, and fact/fiction/consultation/permission controls.
- For online play specify authority, sessions, replication intent, reconnect, version skew and abuse cases.
- Add conditioned device performance, memory, loading, thermal, network and storage measures.
- Specify telemetry purpose, economy integrity, privacy by SDK, build provenance, rollback and ethical commercial behaviour. If ads are in scope, require clear identification, a predictable genuine break after the requested action, neutral decline/close, cap/pace, no-fill/offline/error and kill switch; prohibit interruption of play, learning, narrative, saving, recovery, stopping and exit.
- Specify visual-direction and UI acceptance as observable game outcomes and evidence while deferring craft to the five game skills in
design-system-skills.
- Stop on an ownerless transition, unresolved child/cultural/right boundary or unverifiable threshold; recover with a decision request.
Outputs
| Artefact | Consumer | Acceptance condition |
|---|
| Game SRS and register | Architecture, implementation, QA and operations | Every behaviour has owner, boundary, condition, oracle and trace. |
Evidence Produced
| Evidence | Reviewer | Acceptance condition |
|---|
| Requirement-source-oracle trace | Requirements reviewer | No requirement rests only on assumption or editor behaviour. |
Capability and permission boundaries
Read and search are allowed. Editing baselines requires authority; paid services, policy or certification require approval.
Degraded mode
Return the narrowest qualified subsystem, mark unavailable evidence not assessed, and block dependent claims.
Decision Rules
| Choice or condition | Action | Failure or risk avoided |
|---|
| Mutable field has no authority | Block and assign ownership. | Desynchronisation or exploit. |
| NFR lacks conditions | Replace or mark provisional. | Decorative requirements. |
| Trust/money boundary exists | Add validation, idempotency and recovery. | Fraud or lost state. |
Quality Standards
- Use stimulus, condition, response, measure, tolerance and verification method.
Anti-Patterns
- “Fun” as requirement. Fix: define research evidence.
- “Runs smoothly.” Fix: name hardware, build and metric.
- Client-authoritative economy. Fix: trusted validation.
- Save migration omitted. Fix: add corruption and interruption cases.
- Menu-only accessibility. Fix: cover gameplay verbs.
- Retention or ad revenue as a solitary acceptance measure. Fix: pair with agency, trust, wellbeing, privacy, fairness and stopping evidence.
References
