requirements-clarificationlisted

# Requirements clarification Most rework comes from building the right solution to the wrong problem. The job is to separate the **problem**, the **proposed solution**, and the **success criterion** — stakeholders routinely hand you all three fused into one sentence. ## Step 1: split the ask Take the request literally, then decompose it: > "Add an export to Excel button on the reports page." | Layer | Question | Typical answer | | --- | --- | --- | | Solution stated | What was literally asked for? | Excel export button | | Problem behind it | What can't they do today? | Can't share numbers with finance | | Success criterion | How would we know it worked? | Finance stops asking for manual pulls | The problem layer is where alternatives live. A scheduled email, an API for the finance tool, or a shared dashboard might solve it better — but you cannot see those until you have separated problem from solution. Ask "what would you do with the file once you had it?" and listen for the real workflow. ## Step 2: the questions that change the build Ask only what changes the work. In priority order: 1. **Who is the user, specifically?** Not "users" — which role, how many, how often. A feature for 3 internal admins weekly is a different system than one for 50k customers daily. 2. **What happens today?** The current workaround defines the true baseline and often reveals the real requirement. 3. **What's the trigger and the volume?** Manual click vs event; 10/day vs 10k/da