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.