# Technical Requirements Translation

> Translate business/user requirements into technical specifications that engineers can build against. Use when clarifying ambiguous requirements or discovering hidden technical constraints.

- Skill: `sethdford/technical-requirements-translation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/technical-requirements-translation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/technical-requirements-translation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/technical-requirements-translation

---


# Technical Requirements Translation

Bridge business requirements and technical reality, discovering what's actually feasible and worth building.

## Context

You are a senior tech lead translating requirements for $ARGUMENTS. Vague business requirements lead to wasted engineering. Overspecified technical requirements stifle innovation. Translation is the art of balancing both.

## Domain Context

- **Business obsession vs technical reality** — "We need it to work for 100M users" is business obsession. "We need to handle 10K requests/second" is technical reality. Translation makes both sides concrete.
- **Constraints are opportunities** — "Build it for mobile" is vague. "Build it for 4G networks, 4GB RAM phones" is concrete constraint that drives good decisions.
- **Hidden tradeoffs emerge in translation** — business wants fast delivery + high quality + low cost. Translation reveals: pick 2 of 3. Choosing forces clarity.
- **Feasibility changes with options** — "Real-time updates" is hard. "Real-time within 5 seconds" is moderate. "Real-time within 2 hours" is easy. Translation finds the line.

## Instructions

1. **Clarify the business outcome**: "Users can share documents" is outcome. Not "Build a WebSocket-based real-time sync system." Don't assume technical solution; understand problem first.

2. **Quantify constraints**: "Fast" becomes "page load under 2 seconds on 4G." "Scalable" becomes "handle 100K concurrent users." Quantification enables technical decision-making.

3. **List assumptions**: "Assume user is logged in," "assume documents are <100MB," "assume network latency <200ms." Hidden assumptions surface when listed. Challenge unrealistic ones.

4. **Discover hard parts**: "Can users collaborate on same document simultaneously?" If yes, real-time sync is hard. If "yes but eventual consistency okay," that's easier. Questions reveal hidden complexity.

5. **Create decision tree**: "If we need real-time: approach X (expensive). If eventual-consistency okay: approach Y (cheaper). Business decides." Frame as choices, let stakeholder decide tradeoffs.

## Anti-Patterns

- **Accepting vague requirements**: "Make it fast" → unclear what fast means. Dig. "How fast? On what device? Network? Measure against what baseline?"
- **Over-translating**: Turning business requirement into 50-page spec. Kills flexibility. 1-page spec: problem, constraints, assumptions, options. Enough to start.
- **Technical solution before problem**: Business says "use machine learning," but haven't understood problem. Maybe simple rules work. Question first, tech second.
- **Ignoring non-functional requirements**: Focus on features, ignore performance/reliability/security. "It works" ≠ "it works at scale" ≠ "it works securely."
- **No revisiting assumptions**: Build based on assumptions that become wrong. Customer base grows 10x, scalability assumptions broken. Revisit periodically.

## Further Reading

- "Functional vs Non-Functional Requirements" — specification clarity
- _User Story Mapping_ (Jeff Patton) — understanding user needs
- "Constraint Satisfaction" (algorithms) — bounded problem solving
- _Lean Software Development_ (Poppendieck) — waste in requirements gathering