Technical Specification: [Component or system name]

Author: [Your name / team] Status: [Draft / In review / Approved] Date: [Date] Version: [e.g., 1.0] Related documents: [Links to the PRD, system architecture, and any feature specs]

---

1. Overview and goals

[In a short paragraph, state what this component is, the problem it solves, and where it sits in the wider system. Then list the goals that shape the design and the things it is deliberately not trying to do.]

• Purpose: [What this component is responsible for, in one sentence.]
• Goals (in priority order): [The qualities this design is optimised for, e.g., reliability, then latency.]
• Non-goals: [What this component deliberately does NOT do, to fix the boundary.]

2. Functional requirements

[The behaviours the component must exhibit. Number each one so it can be referenced in review and traced to a test. State each as an observable behaviour, not an implementation detail.]

ID	Requirement
FR-1	[The system shall ... when ...]
FR-2	[The system shall ... when ...]
FR-3	[The system shall reject / handle ... by ...]

3. Non-functional requirements

[The quality targets that apply across the behaviour. Give each a measurable threshold and the condition under which it holds, so it can be passed or failed.]

ID	Category	Target
NFR-1	Performance	[e.g., 95% of requests complete within X ms under Y load]
NFR-2	Reliability	[e.g., availability target / SLO, recovery objective]
NFR-3	Scalability	[e.g., supports N concurrent items / scales horizontally on X]
NFR-4	Security	[e.g., all calls authenticated; sensitive data encrypted in transit and at rest]

4. Proposed design and approach

[Describe how the component is structured internally and how it satisfies the requirements above. Name each part and the single responsibility it owns, then describe the key interactions in words. Reference the requirement IDs that each part addresses.]

Part	Responsibility
[Part A]	[What it is accountable for]
[Part B]	[What it is accountable for]
[Part C]	[What it is accountable for]

Key flow — [name]:

1. [What enters the component and where it arrives.]
2. [What each part does, in order, and what is read or written.]
3. [What the end state is and what is returned or emitted.]

5. Interfaces and APIs

[Define the contracts this component exposes to callers and depends on from others. For each operation, give its inputs, its outputs, and how it behaves on error.]

Operation	Direction	Inputs	Output	Errors
[operationName]	[Exposed / Consumed]	[Key inputs]	[What it returns]	[Error responses and meaning]
[operationName]	[Exposed / Consumed]	[Key inputs]	[What it returns]	[Error responses and meaning]

6. Data

[Describe the entities this component owns or touches, their key fields, and how they are stored and validated. Note ownership where another component is the source of truth.]

Entity	Key fields	Notes
[Entity A]	[field, field, field]	[Type / constraint / where it is stored]
[Entity B]	[field, field, field]	[Validation rule; owned here or referenced]

7. Dependencies and constraints

• External dependencies: [Services, APIs, or libraries this design relies on, and what it expects of each.]
• Platform constraints: [Limits the design must respect — runtime, memory, rate limits, compliance.]
• Assumptions: [Things taken as given; if one proves false, the design must be revisited.]

8. Acceptance criteria

[The concrete, checkable conditions that must all be true for the work to be accepted. Write each so a tester or stakeholder can verify it by observing the system. Given / When / Then keeps them precise.]

• [Given ..., when ..., then ...]
• [Given ..., when ..., then ...]
• [Given an error condition ..., when ..., then the system ... rather than ...]
• [Non-functional check: under [load], the system meets [NFR-1 / NFR-2].]

9. Open questions

• [Any decision still outstanding, and who needs to resolve it.]
• [Any assumption that needs confirming before build.]