Requirements Specification

A requirement specification is the contract between the person who wants a feature and the people who will build, test, and operate it. Every spec at Media Tech follows the same ten-section format. The format exists because the gaps between sections — what we forgot to say — are where bugs and disputes are born.

Specs are typically drafted with AI assistance from a screenshot, a Loom video, or a Figma frame. The author pastes the source material, lets the AI generate a first draft of all ten sections, then verifies and edits. The AI accelerates the writing; the human owns the truth.

The ten sections

1. Overview. Two paragraphs: what is this, why are we building it, who asked for it. If the reader doesn't understand the feature after reading this section, the rest of the spec is unread.

2. Scope & Roles. What this spec covers and — critically — what it doesn't. The roles section names the Responsible, Accountable, Consulted, and Informed parties using the company RACI (hr/raci-model).

3. Dependencies. Other specs, libraries, third-party services, design assets, or organizational decisions this depends on. Each dependency is linked. A spec with unresolved dependencies cannot pass the spec-phase gate.

4. Business Logic. The rules. Inputs, outputs, edge cases, error paths. Written as numbered rules so they can be referenced in test cases and code. "If the user has not verified their email address, the AI Diary feature must not be presented." That kind of clarity.

5. UI. Annotated screens or Figma frames. Every interactive element gets a label that ties back to a business-logic rule. Empty states, loading states, and error states are mandatory — not optional.

6. Language & Localisation. Every user-facing string in the feature. For SPYN this means English, Danish, and any other markets the feature ships in. Strings live in the i18n catalogue; the spec references the catalogue keys, not literal strings.

7. Performance. Concrete latency, throughput, and resource targets. "API endpoint responds in p95 ≤ 200ms under 50 RPS sustained load." Vague targets like "feels fast" are rejected at spec review.

8. Security. Threat model for the feature, authentication and authorisation rules, data classification of anything stored or transmitted (compliance/data-classification), and explicit GDPR / EU AI Act flags where relevant.

9. Accessibility. WCAG 2.2 AA at minimum. Mobile features additionally meet the iOS Human Interface Guidelines and Android Material accessibility checklist. Screen-reader, keyboard, contrast, and touch-target requirements are checklist items, not aspirations.

10. Open Questions. What we don't know yet. Each open question has an owner and a target resolution date. A spec can pass the gate with open questions only if none of them block the current build phase.

Lifecycle

Specs are versioned. The first sign-off is v1.0.0. Material changes (any rule in section 4 or interface in section 5) bump the minor version and require re-sign-off. Patch versions are reserved for editorial fixes.

Owned by

Project Management Office, with Engineering Leadership as co-owner. Audited by the Master skill on a 90-day cadence.