technical-requirements-translation

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

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