When to use

At the start of any non-trivial analysis request, especially when the ask is vague ("can you look into X?"), when multiple stakeholders have a stake in the outcome, or when the result will drive an important decision. Spending 30 minutes on requirements prevents days of rework.

Process

1. Run the intake interview — use the question guide in assets/interview_guide.md to surface: the business decision being made, who the audience is, what "done" looks like, and what constraints exist.
2. Identify the decision type — apply references/decision_maker_framework.md to classify the decision (strategic / operational / tactical) and calibrate the required rigour and format.
3. Document requirements — fill in assets/requirements_doc_template.md covering: business question, success criteria, scope inclusions/exclusions, data sources, and timeline.
4. Resolve ambiguities — use the elicitation techniques in references/elicitation_techniques.md for any requirement still unclear after the interview (5-whys, scenario walkthrough, MoSCoW prioritisation).
5. Get explicit sign-off — send the requirements doc to the requestor for confirmation before starting work; update based on feedback.
6. Produce the analysis brief — convert approved requirements into assets/analysis_brief_template.md, which becomes the authoritative scope document for the project.

Inputs the skill needs

• Stakeholder's initial request (however vague)
• Name and role of primary requestor and any other stakeholders
• Proposed deadline or urgency level

Output

• Completed requirements doc (requirements_doc_template.md)
• Analysis brief ready to hand to the analyst (analysis_brief_template.md)
• Interview notes (optional, for complex projects)