Design a requirements-gathering process for the project below. I need a usable operating plan, not a generic list of workshops. Separate facts we know, assumptions to test, decisions that need an owner, and requirements that need validation. Project and intended outcome: [PROJECT AND OUTCOME] Scope, constraints, and deadline: [SCOPE CONSTRAINTS AND DEADLINE] Stakeholders and decision rights: [STAKEHOLDERS AND DECISIONS] Existing evidence and systems: [EXISTING EVIDENCE AND SYSTEMS]
Delivery team and available time: [TEAM AND AVAILABILITY]
Ask up to 3 clarifying questions only if a required input is missing. Then produce:
1. A phased plan covering kickoff, current-state discovery, stakeholder interviews, user or customer evidence, requirement definition, prioritization, validation, and sign-off. For each phase, state the purpose, activities, artifact, accountable owner, contributors, duration, and exit criterion.
2. An interview plan with stakeholder segments, the questions each segment can answer, and questions that expose exceptions, handoffs, compliance needs, failure modes, success measures, and dependencies.
3. A requirements template separating business requirements, user needs, functional requirements, nonfunctional requirements, data requirements, integrations, reporting, migration, and out-of-scope items. Include acceptance criteria written as observable outcomes.
4. A decision and risk log with fields for decision owner, due date, evidence needed, impact of delay, and escalation route.
Use MoSCoW or another named prioritization method only if it fits the stated constraints; explain how it will be applied. Do not fabricate user research, legal requirements, technical constraints, or stakeholder agreement. Before answering, check that every requirement has a validation method and that no phase starts before its required inputs or decisions are available.Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROJECT AND OUTCOME] | Describe the project, the problem it addresses, and the outcome it should achieve. | Replace spreadsheet-based employee onboarding with an internal workflow tool that reduces missed setup tasks |
| [SCOPE CONSTRAINTS AND DEADLINE] | State in-scope and out-of-scope areas, hard constraints, and the target date. | US employees only in phase one; launch by March 15; must retain HRIS as system of record |
| [STAKEHOLDERS AND DECISIONS] | List stakeholders, their roles, and who can approve scope, budget, and final requirements. | HR operations owns process; IT owns integrations; Finance approves spend; VP People signs off on requirements |
| [EXISTING EVIDENCE AND SYSTEMS] | List current documentation, data, customer feedback, workflows, and systems involved. | Current onboarding checklist, 18 exit-interview notes, Workday, Okta, Jira Service Management |
| [TEAM AND AVAILABILITY] | State who will run discovery and how much time stakeholders and the delivery team can commit. | One business analyst and one product manager; HR can provide two hours weekly; IT can join a 45-minute weekly review |
How to use
- Paste the prompt with the actual deadline, approvers, current documents, and systems involved.
- Turn the phase plan into calendar holds and assign each artifact to one accountable person.
- Check that acceptance criteria can be observed or tested rather than phrased as preferences.
- Follow up with: “Convert the interview plan into a 30-minute script for HR operations and IT.”
Variations
Workshop agenda
Use this when a cross-functional meeting must surface scope and decisions quickly.
Create a requirements workshop agenda for [PROJECT] with [ATTENDEES] and [MEETING LENGTH]. We need decisions on [DECISIONS NEEDED] and must respect [CONSTRAINTS]. Give a timed agenda, pre-read, facilitation questions, capture template, and closing commitments with owners and dates. Include a way to distinguish requirements, assumptions, risks, and parking-lot items. Do not assume agreement or make decisions for absent owners. Ask up to 3 questions only if key details are missing. Check that each agenda block produces an artifact or decision.
User interviews
Use this when you need reliable input from customers or frontline users.
Build a user-interview guide for [PROJECT OR SERVICE] and [USER SEGMENTS]. Our research goal is [RESEARCH GOAL], and we already know [EXISTING EVIDENCE]. Create a 30-minute guide with introduction, behavior-based questions, task walkthrough prompts, probes for workarounds and edge cases, and a neutral closing. Include a note-taking grid for needs, quotes, evidence strength, and follow-ups. Avoid leading questions and do not ask participants to design the solution. Ask up to 3 questions only if required inputs are missing, then check coverage of the stated research goal.
Requirements review
Use this before a team formally approves a requirements document.
Review these project requirements before sign-off: [REQUIREMENTS DOCUMENT]. Context: [PROJECT CONTEXT], approvers: [APPROVERS], and key constraints: [CONSTRAINTS]. Return a review table with requirement ID, ambiguity or gap, affected stakeholder, question to resolve, proposed acceptance criterion, priority concern, and approval needed. Separate contradictions, missing edge cases, untestable language, dependencies, and scope creep. Do not rewrite unknown facts as decisions. Ask up to 3 questions only if necessary, then provide a short sign-off readiness verdict with blocking items first.
Tips
- An accountable owner is not simply everyone attending a workshop; name the person who can close each decision.
- Ask about exceptions early, including what happens when data is missing, an approval is late, a system is unavailable, or a user lacks access.
- Write acceptance criteria in observable terms, such as a completed action, allowed response time, or reconciled data result.
- Keep a decision log separate from meeting notes so unresolved choices do not quietly turn into assumed requirements.
FAQ
What is the difference between requirements and solutions?
Requirements describe the outcome, rule, capability, or constraint that must be met. A solution is one possible way to meet it and should not be locked in before evidence supports it.
Who should sign off on requirements?
The person accountable for the business outcome should approve scope and business needs, while relevant technical, legal, security, or operations owners validate their areas. Record the exact approval roles at the start.
Can AI write requirements from meeting notes?
Yes, it can structure and identify gaps in supplied notes. Treat its draft as a working artifact and validate every requirement with the responsible stakeholders.