| name | technical-requirements-translation |
| description | Translate business/user requirements into technical specifications that engineers can build against. Use when clarifying ambiguous requirements or discovering hidden technical constraints. |
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
-
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.
-
Quantify constraints: "Fast" becomes "page load under 2 seconds on 4G." "Scalable" becomes "handle 100K concurrent users." Quantification enables technical decision-making.
-
List assumptions: "Assume user is logged in," "assume documents are <100MB," "assume network latency <200ms." Hidden assumptions surface when listed. Challenge unrealistic ones.
-
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.
-
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
