TRD - Technical Requirements Document

The Technical Requirements Document bridges the gap between what (the PRD) and how (the code). It captures the architecture, the technology choices and their rationale, the API and data design, and the decisions worth recording. It is owned by Dani, the Engineering seat of the Three Amigos.

It lives at sdlc-studio/trd.md, and it is gated on the PRD - you cannot design a solution to a problem you have not written down.

Three modes (plus visualise)

create (greenfield)

An interactive conversation builds the TRD, starting from the project type:

/sdlc-studio trd create

1. Project type classification - Web App, API Backend, Mobile Backend, CLI, SDK.
2. Architecture recommendations for that type, which you accept or customise.
3. Technology-stack decisions - each one needs a real justification, not “we know it”; deviations from the recommended default are captured as ADRs.
4. API design, data architecture, infrastructure and security.

Requires a PRD at sdlc-studio/prd.md. Best for greenfield or a major re-architecture.

generate (brownfield)

Reverse-engineer the TRD from an existing codebase:

/sdlc-studio trd generate

It detects the project type and architecture pattern, extracts the stack from configs, maps API contracts from routes, documents data models from schemas, and reads deployment config for the infrastructure picture - all with [INFERRED] confidence markers. It then runs an architecture assessment (see below). Best for brownfield.

review

Compare the TRD against the implementation and sync it:

/sdlc-studio trd review

New components and changes are folded in, significant decisions become new ADRs, and answered questions are resolved. Step four of review explicitly checks the TRD still aligns with the PRD - that the architecture supports every product feature.

The architecture assessment (generate mode)

On a brownfield project, trd generate does not just describe the architecture - it judges it against best practice for the project type, and reports findings with severity markers [CRITICAL] / [REVIEW] / [INFO]. It looks for:

• pattern alignment with the project type,
• architecture smells - Big Ball of Mud, Distributed Monolith, God Objects,
• whether the technology selection is appropriate,
• standards compliance for APIs and error handling.

This turns “document the code” into “document the code and tell me where it hurts.”

Visualise the architecture

/sdlc-studio trd visualise

Parses the TRD’s Technology Stack, Architecture Decisions and Integrations, extracts the system boundaries, containers and components, and regenerates C4-model diagrams as Mermaid into the TRD’s Architecture Diagrams section - so the picture is generated from the document, never hand-drawn and left to rot.

What it captures

Project type classification and architecture implications · architecture decisions with rationale · technology stack with strong justifications · API contracts and data schemas · integration patterns · infrastructure approach · security considerations · ADRs · open technical questions · (brownfield) the architecture assessment.

Tip

The rule that a technology choice needs a real reason - not familiarity - is the TRD earning its keep. A stack chosen by habit is the most expensive kind of decision to unwind later.

Where to next

• TSD - Test Strategy - how the design is proven to work.
• PRD - Product Requirements - the what the TRD answers how to.
• The Three Amigos - Dani owns the TRD; the whole team reviews it.