Technical Requirements Standards

Use this skill when defining or reviewing technical requirements that engineering teams must implement and verify. A TRD or SRS should be specific enough to build and test against, without collapsing into solution code or architecture rationale.

Core Boundaries

• BRD / PRD define business or product intent
• FSD / FRD defines detailed functional behavior
• NFR defines dedicated quality-attribute targets (performance, availability, security, scalability, compliance, DR) — use that skill when NFRs need their own document
• TRD / SRS define the technical requirements, interfaces, constraints, and verification expectations
• ADR / SAD define technical decisions and architecture structure

Required Inputs

• Source business or product requirements
• Technical context, assumptions, and dependencies
• Interface and data expectations
• Target platforms, constraints, and compliance obligations
• Verification expectations and downstream testing needs

Recommended Structure

1. Document Control
2. Purpose and Scope
3. System Overview
4. Assumptions, Dependencies, and Constraints
5. Specific Requirements
6. Interfaces and Data Requirements
7. Verification and Traceability
8. Approval and Change Control

Writing Rules

• Use shall for mandatory requirements.
• Give every requirement a unique identifier.
• Keep statements atomic, clear, active, and objectively verifiable.
• Avoid hidden design choices unless the design constraint itself is a requirement.
• Use measurable criteria instead of vague quality adjectives.

Verification and Traceability

Every requirement should identify or support:

• upward traceability to business or product need
• downward traceability to design, implementation, and tests
• a verification method such as test, analysis, demonstration, or inspection

Verification Method Selection

Requirement Quality Checklist

Each individual requirement should be:

House IDs and traceability

TRD requirements use the house ID grammar from ../references/lifecycle.md: TR-NNN, sequential, zero-padded to 3 (TR-004). Every TR carries a Trace: line to its upstream BR-NNN/PRD-NNN/FR-NNN source (Engineering-imposed requirements with no business parent follow lifecycle.md's rule for those); NFRs folded inline into a TRD keep TR-NNN IDs here or graduate to NFR-NNN in a dedicated NFR document — never both. "What implements TR-004?" must be answerable by grep -rn "TR-004".

Anti-pattern quick reference

Review Workflow

1. Validate scope and technical context.
2. Check each requirement for clarity, uniqueness, and testability.
3. Confirm assumptions, interfaces, and constraints are explicit.
4. Verify traceability and verification approach.
5. Baseline the document only after peer and stakeholder review.

Pre-flight checklist — run before delivering any TRD

• Mandatory requirements use shall
• Every requirement has a unique ID
• Assumptions, dependencies, and constraints are explicit
• Interface and data requirements are not hidden in prose
• Verification method and traceability are addressed
• Approval and change-control expectations are clear