AI Requirements Gathering Prompts: Stop Starting Vague

The project brief says "build a form." That's it. No context, no constraints, no stakeholders named, no definition of done. You paste it into ChatGPT and get back two pages of beautifully formatted AI requirements gathering prompts output that sounds completely authoritative and is about 40% invented. Now you're in a kickoff meeting reading requirements nobody agreed to, and everyone's nodding politely because the document looks so official.

This is the trap. AI is very good at making incomplete information sound finished. It fills gaps with plausible-sounding assumptions and presents them with the same confidence it uses for things that are actually true. Tidy does not mean accurate. That's Rule #5 from Don't Replace Me: It's Not Smart. It's Fast.

The prompts below are built around a different approach. You bring the real inputs. AI helps you structure, question, and pressure-test them. You own the judgment calls.

Why most requirements documents fail before you start

Bad requirements aren't usually the result of laziness. They're the result of starting to write before you've finished listening. Someone has a vague ask, you capture the surface version of it, and then everyone spends three sprints building the wrong thing with increasing confidence.

AI makes this worse, not better, if you use it wrong. Paste a messy Slack thread into any LLM and it will give you a polished requirements brief with clear sections and bullet points. Half the bullets will be extrapolated from context clues. The other half will be the AI guessing what "sounds right" for a project like yours. It won't flag which ones it made up.

The prompts in this guide force you to separate what you actually know from what you're assuming. That gap, named explicitly, is where requirements work actually happens.

The reusable formula before any requirements prompt

Every prompt here follows the same structure. Get this right once and the rest is copy-paste.

Role: Act as a requirements analyst reviewing a project brief.

Input: Here is what I have: [paste verified source material only]

Task: [specific task from the prompts below]

Constraints: Flag every assumption you make. If something is unclear, ask the question rather than fill the gap. Output should distinguish between confirmed facts and open questions.

That last constraint is the one that matters. Without it, AI will happily complete the picture for you.

Safety note before you start: Do not paste customer PII, employee records, credentials, contracts, legal disputes, financial forecasts, unreleased product details, security vulnerabilities, confidential strategy, or sensitive client data into any AI tool that hasn't been approved by your security or legal team. If the source material contains any of that, remove it before prompting. Use placeholder text or anonymized descriptions instead.

10 AI requirements gathering prompts you can use today

Prompt 1: Turn a vague ask into a requirements brief

Use when: Someone handed you a one-liner and called it a project.

Act as a requirements analyst. Here is the initial request I received: [paste the ask].

Turn this into a draft requirements brief with these sections:
- Problem statement (what we know for certain)
- Proposed solution (as described, no additions)
- Known constraints
- Assumptions being made
- Open questions that must be answered before this can proceed

Label every bullet as CONFIRMED or ASSUMED. Do not invent scope.

Prompt 2: Extract requirements from messy notes

Use when: You have a recording transcript, a Slack dump, or six pages of meeting notes.

I have raw notes from a stakeholder conversation. Extract only what was explicitly stated. Do not infer, extrapolate, or complete the picture.

Notes: [paste sanitized notes]

Output:
- Explicitly stated requirements
- Explicitly stated constraints
- Explicitly stated preferences (not requirements)
- Topics that came up but were not resolved
- Things I should go back and clarify

If you're working from meeting notes regularly, the AI meeting notes prompts guide has dedicated templates for that step.

Prompt 3: Identify missing stakeholder inputs

Use when: You have a brief but you're not sure who else should have been consulted.

Here is a draft requirements document: [paste document]

Based on the scope described, identify:
- Which stakeholder groups likely have requirements not represented here
- Which teams will be affected by this work (technical, legal, security, privacy, accessibility, finance, operations, customer-facing)
- What questions each missing group would probably ask
- Which of those gaps could block delivery if not resolved

Do not invent requirements. Only flag what's missing.

Prompt 4: Separate facts from assumptions

Use when: A requirements doc already exists but you're not sure how much of it is real.

Review this requirements document and sort every item into one of three categories:

CONFIRMED: Stated explicitly by a named source
ASSUMED: Inferred or extrapolated without verification
UNKNOWN: Requires research or stakeholder input to resolve

Document: [paste requirements]

For each ASSUMED or UNKNOWN item, write the specific question someone would need to answer to confirm it.

This is the prompt most people skip. It's the most useful one.

Prompt 5: Map users and use cases

Use when: The brief mentions "users" without specifying who they actually are.

Based on this project description, help me map the user landscape:

Description: [paste brief]

For each user type you can identify from the description:
- Who they are (role or context, not invented demographics)
- What they're trying to accomplish
- What constraints or access levels they likely have
- What could go wrong for them specifically

Flag every item as INFERRED if it's not explicitly stated. Note which user types need direct research.

Prompt 6: Find dependencies and constraints

Use when: You need to scope what this project bumps into before you start.

Review this requirements brief and identify:
- Technical dependencies (systems, APIs, platforms this touches)
- Team dependencies (who else has to do something for this to work)
- Timeline dependencies (what has to happen first)
- Compliance or regulatory constraints (data, accessibility, privacy, security)
- Constraints that were implied but not explicitly stated

Brief: [paste brief]

For each dependency, note whether it is CONFIRMED or INFERRED and who owns the resolution.

For deeper work on this, the AI workflow audit prompts are useful for surfacing process-level blockers your brief might be missing.

Prompt 7: Surface risks and edge cases

Use when: The requirements look clean but something feels off.

Here are the requirements for a project: [paste requirements]

Identify:
- Edge cases that are not addressed
- User behaviors the requirements assume won't happen but probably will
- Technical failure modes not covered
- Accessibility or inclusion gaps
- Privacy or data handling risks
- Scenarios where the stated requirements conflict with each other

For each risk, note its likely severity (high/medium/low) and whether it needs legal, security, privacy, or engineering review.

Before you get here, AI risk assessment prompts can help you run a broader blast radius check on the overall project.

Prompt 8: Prepare stakeholder interview questions

Use when: You have a draft brief and you're about to talk to real humans who will fill the gaps.

I'm preparing to interview stakeholders for this project: [paste brief]

Generate interview questions designed to:
- Validate or challenge the assumptions in the brief
- Surface constraints I haven't captured
- Clarify decision rights (who approves what)
- Understand success criteria in their words, not ours
- Identify what they're worried about that isn't in the document

Group questions by stakeholder type: business owner, end users, technical team, legal/compliance if relevant.

Prompt 9: Rewrite requirements for different audiences

Use when: You need the same requirements to work for a technical team and a business sponsor.

Here are the project requirements: [paste requirements]

Rewrite them twice:

Version 1, For the technical team: Include implementation context, system references, data handling specifics, edge case handling, and acceptance criteria language.

Version 2, For the business sponsor: Focus on outcomes, business impact, user experience, and decision points without technical jargon.

Do not add new requirements in either version. Only change the framing and language.

If the technical version needs to go further into acceptance criteria, the AI acceptance criteria prompts have dedicated templates for making requirements testable.

Prompt 10: Run a pre-kickoff readiness check

Use when: You think you're ready to kick off but you want to be sure.

Here is our current requirements document for an upcoming project: [paste document]

Run a pre-kickoff readiness check. Evaluate whether we have:
- A clearly stated problem (not just a solution)
- Named stakeholders with confirmed buy-in
- Defined success criteria
- Known constraints and dependencies
- Open questions logged with owners and deadlines
- Risk items flagged for specialist review (legal, security, privacy, accessibility)
- Decision rights documented
- Scope boundaries (what's out of scope)

Rate each area as READY, NEEDS WORK, or BLOCKED. For anything that's not READY, say what's missing.

This one pairs well with AI project kickoff prompts for the meeting itself.

What AI should never replace in requirements work

AI requirements gathering prompts are useful for structure, questions, checklists, and language. They are not useful for the things that actually determine whether requirements are real.

Those things are:

Stakeholder conversations. AI can generate interview questions. It cannot sit across from a product owner and read the room when they say "yes, sure" while clearly meaning "I have no idea."

User research. A language model can map plausible user types. It has never met your users and doesn't know what their actual context is.

Political judgment. Which requirements will get cut in budget discussions. Which ones are negotiable but nobody will say so. Which stakeholder's opinion overrides the brief on paper. That's what Dee calls the taste moat in Don't Replace Me: the human value that doesn't show up in a document.

Legal, security, privacy, and compliance review. If your requirements touch personal data, financial systems, health information, regulated industries, contracts, or security-sensitive infrastructure, a prompt is not a review. Get the actual experts involved. An AI-generated requirements brief does not constitute sign-off from anyone.

Delivery ownership. Requirements signed by nobody change easily. Requirements with a named owner who has committed to them change through a process. AI can't create accountability. You have to.

A note on confidence levels

One practical habit: when you finalize a requirements brief, add a confidence field to each requirement. Not complicated. Just: HIGH (confirmed by named source), MEDIUM (inferred but plausible), LOW (assumed, needs verification).

This forces you to have a conversation about the LOW items before the kickoff, not in a sprint retro six weeks later. It also makes it easier to log decisions when things change, which they will. The AI decision log prompts can help you track those downstream.

The goal of requirements gathering is not a polished document. It's shared understanding. AI can help you write that document faster. It can't create the understanding for you.

Frequently asked questions

Can AI write requirements documents for me?

AI can draft a requirements structure from your inputs, but it will fill gaps with plausible-sounding assumptions that may not reflect what stakeholders actually need. Use it to organize and question your material, not to complete it. Every ASSUMED item in an AI-generated brief needs a human to verify it before you build anything.

What's the biggest mistake people make with AI requirements gathering prompts?

Pasting a vague brief and accepting the output as real requirements. AI will produce something that looks complete even when the source material is missing half the information. The prompts in this guide are designed to surface gaps, not hide them.

What information should I never paste into an AI tool for requirements work?

Customer PII, employee records, credentials, contracts, legal disputes, financial forecasts, unreleased product details, security vulnerabilities, medical or safety information, and anything your security or legal team hasn't approved for use in external AI tools. Anonymize or remove sensitive details before prompting.

How do I handle requirements that need legal or compliance review?

Flag them explicitly in the document and do not treat an AI-generated requirements brief as approval. Escalate to legal, security, privacy, accessibility, or finance as appropriate. The prompt for surfacing risks and edge cases (Prompt 7 above) will help you identify which items need that review.

Do I need to tell stakeholders I used AI to draft the requirements?

That depends on your organization's AI disclosure policies, and you should check them. What you definitely need to do is verify the requirements with stakeholders regardless of how you drafted them. A document drafted by AI that stakeholders haven't reviewed and confirmed is not a requirements document. It's a guess with good formatting.

How does requirements gathering connect to project kickoff?

Requirements work happens before kickoff, and a lot of kickoff chaos comes from starting with requirements that haven't been properly validated. If your brief has unresolved open questions, unknown owners, or unverified assumptions, those problems don't disappear when the kickoff meeting starts. The AI project management prompts cover the broader project structure these fit into.