Six months ago, writing a stakeholder engagement plan took me the better part of an afternoon. I would stare at the blank document, outline the key players from memory, draft engagement approaches, second-guess whether I had captured the right tone for a resistant executive, revise, and eventually produce something serviceable.
Last week, I did the same work in forty minutes. Not because I got faster at typing. Because I started with a structured prompt, gave it the project context and stakeholder profiles, and received a solid first draft that I spent twenty minutes refining with my own judgment and institutional knowledge.
The AI did not replace my thinking. It replaced the blank page.
That is the practical reality of AI for business analysts in 2026. It is not about automating your job. It is about eliminating the friction between knowing what you need to produce and actually producing it. The thinking, the judgment, the stakeholder relationships - those remain yours. The drafting, the formatting, the "let me get the first version down on paper" - that is where AI compresses hours into minutes.
This article is not a theoretical overview of prompt engineering. It is a library of prompts I use in actual BA work, organized by the stages of the analysis lifecycle. Every prompt is copy-paste ready. Every one includes context on when to use it and how to refine the output.
A note on tools: these prompts work across Claude, ChatGPT, Gemini, and Copilot. The differences between tools are getting smaller with each model update. Use whichever tool your organization has approved.
Not working as a BA yet? Most of this library still applies, and there is a dedicated section for career switchers at the end: interview practice, portfolio case generation, and translating your current experience into BA language.
Take the library with you. Get all 43 prompts as a Notion template you can duplicate, tag, and refine into your own library - plus new prompts as we add them.
We send a confirmation link first. We never share your address.
The Most Powerful Technique in This Entire Article
Before we get into the prompt library, there is one technique that will improve every single prompt you ever write. It is five words long:
"Ask me questions before answering."
Add this line to the end of any prompt and the AI transforms from a one-shot generator into a collaborative analyst. Instead of making assumptions about your context, it asks for the specific details it needs - exactly like a senior BA would before diving into an analysis.
Here is the difference in practice. Without the technique:
Help me create a stakeholder engagement plan for my project.
The AI produces a generic template. Usable but bland.
With the technique:
Help me create a stakeholder engagement plan for my project.
Before you start, ask me questions about the project context,
stakeholders, and constraints so your output is specific to
my situation.
The AI will ask things like: "How many stakeholders are involved? What is the project timeline? Are there known resistors? What level of detail does your organization expect in engagement plans?" Your answers give it the context to produce something genuinely tailored.
You will see this technique embedded into several prompts below. But you can add it to any prompt in this library - or any prompt you write from scratch. It is the single highest-leverage habit you can build.
Four Mistakes That Make BA Prompts Useless
Before the prompt library, four anti-patterns that waste your time:
Giving too little context. "Write user stories for my project" is not a prompt. It is a wish. The AI has no idea what your project is, who the users are, what the constraints are, or what format your team expects. Every assumption the AI makes is a coin flip. Give it the context you would give a new team member on their first day.
Accepting the first output without review. AI generates plausible, professional-looking content. That is exactly what makes it dangerous. A user story with perfect Given/When/Then syntax that describes the wrong business logic is worse than a rough draft with the right logic, because the professional formatting creates false confidence. Always review AI output with the same scrutiny you would apply to a junior analyst's first draft.
Using AI for tasks that require human judgment. AI cannot navigate your office politics, read the room during a tense stakeholder meeting, or decide whether to push back on a VP's pet feature. If the task requires relationship context, political awareness, or professional courage, AI is the wrong tool. Use it for the generative work (drafting, structuring, reviewing) and keep the judgment work for yourself.
Treating AI output as finished work. AI gives you a first draft, not a final deliverable. The value is in the 70% of the work it handles (structure, completeness, formatting) so you can focus on the 30% that requires your expertise (domain accuracy, stakeholder nuance, organizational context). If you copy-paste without refinement, you are shipping someone else's assumptions as your analysis.
Before the Meeting: Research and Preparation (~20 min saved per meeting)
Most BAs underuse AI for meeting prep. We walk into stakeholder sessions with a general sense of the agenda and hope our experience fills the gaps. AI can give you a structured preparation framework in five minutes.
Prompt 1: Stakeholder Research Brief
Use this before meeting a stakeholder for the first time, or before a critical session with someone you need to influence.
I am a business analyst preparing for a meeting with [Name],
who is the [Title] at [Company/Department]. The meeting is
about [topic/project].
Based on this role and context, help me prepare:
1. What are the likely priorities and concerns of someone in
this role regarding this type of project?
2. What questions should I ask to uncover their real needs
(not just stated requirements)?
3. What potential objections or resistance points should I
anticipate?
4. What language or framing will resonate with someone at
this organizational level?
5. What is the one question I should absolutely not leave
the meeting without asking?
Keep responses specific to the role and project context,
not generic advice. If you need more context about the
project, the stakeholder's history, or the organizational
dynamics to give specific answers, ask me before responding.
Pro tip: The more context you provide about the project, the better the output. If you know the stakeholder has budget authority, or that they were burned by a previous failed project, include that. AI cannot read between the lines - you have to put the subtext on the page.
Prompt 2: Meeting Agenda with Discovery Questions
I am preparing a [type: kickoff / requirements workshop /
stakeholder review] meeting for a [brief project description].
Attendees: [list names and roles]
Create a structured agenda (60 minutes) that:
- Opens with context setting (5 min max)
- Prioritizes discovery and elicitation over presentation
- Includes 3-5 open-ended questions designed to uncover
conflicting priorities between attendees
- Ends with clear next steps and action items
- Includes time allocations for each section
The tone should be collaborative, not interrogative. These
stakeholders have varying levels of technical knowledge.
Before generating the agenda, ask me about any known tensions
between attendees or topics I specifically need to avoid or
address.
When to use: Before any workshop or alignment meeting. The discovery questions are the real value - AI is surprisingly good at anticipating where stakeholders might disagree if you give it enough context about their roles.
Prompt 3: Pre-Meeting Risk Assessment
I am about to begin a [type of project] for [brief context].
The key stakeholders are:
[List each stakeholder with: name, role, known position/attitude]
Based on these dynamics, identify:
1. The top 3 risks to requirements alignment
2. Which stakeholder relationships are most likely to create
friction
3. What I should establish in the first two meetings to
prevent these risks from materializing
4. Any "silent stakeholders" I might be missing (people not
in the room who could block the project later)
Requirements Elicitation: Drawing Out What People Actually Need (~2 hours saved per elicitation cycle)
This is where AI becomes a genuine thinking partner. You can simulate stakeholder conversations, process raw interview notes into structured insights, and identify gaps in your elicitation that you might not spot on your own. For the foundational elicitation techniques these prompts build on, see our guide to the five core elicitation techniques every BA needs.
Prompt 4: Stakeholder Simulation
This is one of the most powerful prompts in the library. Use it to practice before a difficult stakeholder conversation, or to stress-test your requirements against a skeptical perspective.
You are [Name], the [Title] at [Company]. You have been in this
role for [X years]. Your primary concerns are [list 2-3 known
concerns].
Your attitude toward this project is [supportive/cautious/
resistant] because [reason].
I am a business analyst who needs to elicit your requirements
for [project]. I will ask you questions, and you should respond
as this stakeholder would - including:
- Being vague where a real stakeholder would be vague
- Having conflicting priorities
- Occasionally pushing back or redirecting the conversation
- Having concerns you do not volunteer unless directly asked
Before we begin, ask me what I already know about this
stakeholder's history with similar projects and any political
dynamics I should be aware of. Then we will start the roleplay.
Pro tip: This prompt creates an interactive roleplay. Ask your questions one at a time, just as you would in a real interview. The AI will stay in character. When you are done, ask it to break character and tell you what questions you missed or what concerns you failed to uncover. That feedback is gold.
Want this with a real grade attached? Chat roleplay is good rehearsal, but the same model that plays your stakeholder also judges your performance, and it tends to be a generous judge. The Case Lab on BAvolta separates the two: you elicit from simulated stakeholders inside a structured case, produce the actual artifact, and get graded against an expert model answer. The first case is free.
Prompt 5: Meeting Notes to Structured Requirements
Use this after a stakeholder session when you have raw notes and need to extract actionable requirements.
Below are my notes from a stakeholder meeting about [project].
The attendees were [list names and roles].
[Paste your raw meeting notes here]
From these notes, extract:
1. Explicit requirements stated by stakeholders (quote the
source where possible)
2. Implied requirements (needs that were suggested but not
directly stated)
3. Conflicting requirements between different stakeholders
4. Ambiguous statements that need follow-up clarification
5. Assumptions made during the discussion that should be
validated
6. Any constraints mentioned (budget, timeline, technical,
regulatory)
Format each requirement as: [REQ-XXX] [Description]
- Source: [Stakeholder name] - Status: [Explicit/Implied/
Needs Clarification]
When to use: Immediately after any elicitation session while the context is fresh. Paste your raw notes - messy is fine. The AI's job is to impose structure on your stream-of-consciousness notes.
Prompt 6: Meeting Summary and Action Items
The prompt you will use most often. Run this within an hour of every meeting.
Here are my raw notes from a [meeting type] about [project]:
[Paste raw notes - bullet points, fragments, whatever you have]
Attendees: [list names and roles]
Produce a structured meeting summary with:
1. Key decisions made (who decided what, with the rationale)
2. Action items (owner, description, deadline if discussed)
3. Open questions that were raised but not resolved
4. Parking lot items (topics deferred for future discussion)
5. Any changes to project scope, timeline, or priorities
Format the summary so I can paste it directly into an email
to attendees. Keep it under 400 words. Lead with decisions
and action items - those are what people actually read.
Prompt 7: Interview Question Generator
I am preparing to interview [Name], [Title], about [project/topic].
What I already know from other sources:
[List key data points, other stakeholder perspectives,
known constraints]
Generate 10 interview questions that:
- Start broad and progressively get more specific
- Include at least 2 questions designed to uncover needs
they might not think to mention
- Include at least 1 question that tests a potential
conflict with another stakeholder's stated requirements
- Avoid yes/no questions
- Are phrased conversationally, not like a survey
Also suggest the best order to ask them and explain why
that sequence works.
Before generating questions, ask me about any sensitive
topics I should avoid and what I most need to learn from
this specific interview.
Prompt 8: Elicitation Plan Builder
Use this at project kickoff, before you book a single meeting. It forces you to plan elicitation deliberately instead of defaulting to "interview everyone."
I am the business analyst on a new initiative: [one-paragraph
description].
Known stakeholders: [list roles].
Discovery timeline: [e.g. 3 weeks].
Draft an elicitation plan. For each stakeholder group, recommend:
1. The best technique (interview, workshop, observation,
document analysis, survey) and why that technique fits
this group specifically
2. What I should aim to learn from them
3. Sequencing: who to engage first and why
Keep it to one page. Flag risks in the plan itself, including
stakeholder groups I appear to be missing and topics where a
single source would be dangerous.
Before drafting, ask me what documentation already exists and
what decisions have already been made, so the plan does not
re-elicit settled questions.
When to use: At the start of discovery, before scheduling. Ten minutes with this prompt regularly saves a week of poorly sequenced meetings.
Requirements Documentation: From Thinking to Writing (~3 hours saved per document)
Writing requirements is where most BAs spend the largest chunk of their time. AI does not replace your judgment about what to document, but it dramatically accelerates the documentation itself.
Prompt 9: User Stories with Acceptance Criteria
Based on the following requirement description, write a user
story with acceptance criteria.
Requirement: [Describe the requirement in plain language]
Context: [Brief project context, system name, user type]
Constraints: [Any known technical, budget, or timeline
constraints that affect how this should be built]
Format:
- User Story: As a [role], I want [capability], so that [benefit]
- Acceptance Criteria (Given/When/Then format):
- At least 3 criteria covering the happy path
- At least 2 negative/edge case criteria (what happens when
input is invalid, system is unavailable, user lacks
permissions, etc.)
- All criteria must be testable with a specific pass/fail
condition
- Include performance thresholds where applicable (e.g.,
"results load within 3 seconds")
Avoid vague terms like "quickly," "user-friendly," or
"efficiently" - replace each with a measurable value.
After writing the user story and acceptance criteria, critique
your own output:
- Which acceptance criteria are still too vague to test?
- What edge cases did you miss?
- Would a developer have enough information to implement this
without asking follow-up questions?
Then rewrite any weak criteria based on your critique.
Pro tip: The self-critique step ("critique your own output") is what separates a mediocre prompt from an excellent one. The AI's first draft is usually 70% there. Asking it to identify its own weaknesses and fix them pushes it to 90%. Your domain expertise handles the final 10%.
Prompt 10: Epic and Story Slicer
The story is too big and nobody in refinement wants to say so. This prompt gives you two slicing options to bring to the team instead of one opinion.
This story is too large:
"[paste epic or oversized story]"
Context: [system, users, any technical constraints]
Slice it into smaller stories using multiple strategies:
by workflow step, by user type, by data variation, and by
happy path first then exceptions.
Show 2 different slicing options. Each option must be an
ordered list where the first story alone delivers something
demonstrable to a stakeholder.
Recommend one option and justify the recommendation in two
sentences. Then flag any slice that is still too large to
build and test independently.
Prompt 11: Requirements Document Scaffold
I need to create a requirements document for [project name].
Before you generate anything, ask me 5-7 questions about the
project context, stakeholders, constraints, and existing
documentation so your output is specific to my situation -
not a generic template.
After I answer your questions, generate a requirements document
scaffold with:
1. Purpose and Scope statement (explicitly stating what is
IN scope and what is OUT of scope, with the reasoning
behind each exclusion)
2. Stakeholder table (name, role, interest level, influence
level, primary concern, engagement approach)
3. 5-7 functional requirements with:
- Unique IDs (FR-001 format)
- MoSCoW priority with a one-sentence rationale that
explains WHY, not just the priority level
- Acceptance criteria in Given/When/Then format
- Source (which stakeholder raised this)
- Dependencies on other requirements
4. 2-3 non-functional requirements with measurable targets
(not "the system should be fast" but "search results
return within 2 seconds for datasets under 10,000 records")
5. Assumptions and constraints section (separate assumptions
from constraints - they are different)
6. Dependencies section with risk assessment per dependency
7. Open questions - things you flagged as ambiguous based on
the context I provided
This is a first draft for me to refine - prioritize
completeness over polish.
When to use: At the start of any project when you need to stand up the initial requirements document. The "ask me questions first" approach is critical here - without it, you get a generic template. With it, you get a scaffold that already reflects your project reality.
Below is a description of a business process:
[Paste the process description, policy document, or
stakeholder explanation]
Extract all business rules from this text. For each rule:
1. State the rule clearly and unambiguously
2. Classify it as: Constraint / Computation / Derivation /
Inference
3. Identify the source (which part of the text)
4. Flag any rules that are ambiguous or potentially
conflicting
5. Suggest validation questions I should ask stakeholders
to confirm each rule
Format as a numbered list with clear categorization.
Prompt 13: Data Dictionary Generator
Use this when you have a database schema, form layout, or spreadsheet structure and need to produce formal data definitions.
Here is a list of fields from [source: database table / form /
spreadsheet / API response]:
[Paste the field names, or describe the data structure]
For each field, generate a data dictionary entry with:
1. Field name (standardized to snake_case)
2. Business definition (plain English, precise enough that
two people reading it would collect the same data)
3. Data type and format (text, integer, decimal, date,
boolean - with length/precision)
4. Allowable values or range (specific list, min/max, or
pattern)
5. Required or optional
6. Validation rule (what the system should check on entry)
7. Example value
Flag any fields where the name is ambiguous (e.g., "status" -
status of what?) and suggest clarification questions.
If you need more context about the business domain to write
accurate definitions, ask me before generating.
Stakeholder Analysis and Mapping (~1 hour saved per analysis)
Prompt 14: Stakeholder Map Generator
I am working on [project description]. The following people
are involved:
[For each stakeholder, provide: name, role, department, and
any known attitudes, concerns, or past experiences with
similar projects]
Create a stakeholder analysis including:
1. Interest/Influence matrix (High/Low for each axis) with
a one-sentence justification for each placement
2. Attitude classification (Champion, Supportive, Neutral,
Cautious, Resistant) with the evidence from my descriptions
that supports each classification
3. A tailored engagement strategy for each stakeholder that
specifies:
- Communication channel (1:1, email, workshop, Slack)
- Frequency (weekly, bi-weekly, milestone-based)
- What content they need (detailed specs, executive
summaries, demo walkthroughs)
- What question to ask them in every interaction
4. Potential alliances - which stakeholders should I align
with each other before the first group meeting, and why?
5. Risk flags - stakeholders who might derail the project,
what the trigger would be, and what preemptive action
I should take
6. "Influence map" - who influences whom? If I can only
convince one stakeholder to champion this project,
who should it be and why?
Do NOT use generic strategies like "keep informed" or
"manage closely." Every recommendation should reference
the specific stakeholder's context.
Before generating, ask me about any organizational dynamics,
recent history, or political sensitivities that would affect
stakeholder engagement.
Prompt 15: RACI Matrix Generator
Here is a project with the following activities and people:
Activities: [list the key project activities, decisions, or
deliverables]
People/Roles: [list the stakeholders and their roles]
Generate a RACI matrix (Responsible, Accountable, Consulted,
Informed) for each activity-person combination.
Rules:
- Each activity must have exactly one Accountable person
- At least one person must be Responsible for each activity
- Flag any activity where more than 3 people are Consulted
(potential bottleneck)
- Flag any person who is Accountable for more than 4
activities (potential overload)
- Flag any person who appears nowhere in the matrix
(may not need to be on the project)
After generating, critique the matrix: are there activities
where the Accountable person lacks the authority to actually
be held accountable? Flag those.
Prompt 16: Conflict Resolution Strategy
I have two stakeholders with conflicting requirements:
Stakeholder A: [Name, Role] wants [their requirement/position]
because [their reasoning]
Stakeholder B: [Name, Role] wants [their requirement/position]
because [their reasoning]
Project constraints: [budget, timeline, technical limits]
Help me:
1. Identify the underlying need behind each position
(not just the stated requirement)
2. Propose 3 potential resolution approaches, ranging from
compromise to phased delivery to scope adjustment
3. For each approach, identify who gains what, who concedes
what, and the project impact
4. Recommend which approach to present first and how to
frame it to each stakeholder
5. Draft talking points I can use in a facilitation session
Process Modeling and Analysis (~1.5 hours saved per model)
Prompt 17: Process Description to Workflow
I need to document a business process. Here is how a team
member described it:
"[Paste the verbal/written process description]"
Convert this into a structured process flow with:
1. Clearly defined start and end points
2. Sequential steps numbered (Step 1, Step 2, etc.)
3. Decision points marked with [DECISION] and both
Yes/No branches
4. Handoffs between roles/systems clearly indicated
5. Any parallel or concurrent activities identified
6. Estimated time for each step (if inferable from context)
7. Pain points or inefficiencies I should investigate further
Also identify any steps that are ambiguous or where the
description assumes knowledge I should clarify with the
stakeholder.
Prompt 18: BPMN-Ready Process Structure
Use this when you model in a BPMN tool and want the logic straight before you start dragging shapes.
Convert this process description into a BPMN-ready structure:
[paste as-is process documentation]
Output:
1. Pools and lanes (actors and systems)
2. Start and end events
3. Tasks in sequence, using verb-noun naming
4. Gateways with the exact condition on each branch
5. Message flows between pools
Note anything in the description that cannot be modeled
cleanly, and explain why. Do not invent branches or
conditions that are not supported by the description;
flag gaps as questions for the process owner instead.
Pro tip: The flagged gaps are the real output. They are your question list for the next process walkthrough.
Prompt 19: As-Is to To-Be Analysis
Here is the current (as-is) process:
[Describe or paste the current process]
Known problems with this process:
[List pain points, bottlenecks, complaints]
Constraints for any proposed changes:
[Budget, timeline, technology, regulatory, organizational]
Propose a to-be process that:
1. Addresses each listed pain point
2. Stays within the stated constraints
3. Identifies which steps are eliminated, automated,
or modified
4. Estimates the impact of each change (time saved,
error reduction, cost impact)
5. Flags implementation risks for each proposed change
6. Suggests a phased rollout approach if all changes
cannot be made simultaneously
Before proposing changes, ask me about any organizational
constraints or past failed improvement attempts that would
affect what is realistic.
Prompt 20: SOP Writer
The process is agreed. Now people have to follow it. This turns a process map into instructions a first-week employee can execute.
Turn this process into a standard operating procedure for
[audience, e.g. new customer service agents]:
[paste process steps]
Format:
1. Purpose (2 sentences) and scope
2. Roles involved
3. Numbered instructions written at the level of a
first-week employee: every click, every system, every
handoff explicit
4. An exceptions section covering what to do when each of
these occurs: [list known exceptions]
5. A one-screen quick-reference version at the end
Before writing, ask me which steps people currently get
wrong most often, so the SOP can emphasize them.
Prompt 21: Root Cause Analysis
We are experiencing the following problem:
[Describe the symptom - what users or stakeholders are
reporting]
Available data/context:
[Paste any relevant data, metrics, timelines, or
observations]
Perform a structured root cause analysis:
1. Apply the "5 Whys" technique to drill down from the
symptom to potential root causes
2. For each potential root cause, assess:
- Likelihood (High/Medium/Low)
- Evidence supporting it from the data provided
- What additional data I would need to confirm it
3. Distinguish between root causes and contributing factors
4. Recommend which root cause to investigate first and why
5. Suggest 2-3 validation steps I can take before proposing
solutions
Gap Analysis and Prioritization (~1 hour saved per analysis)
Prompt 22: Requirements Gap Identification
Here is my current requirements document for [project]:
[Paste your requirements or a summary]
The project objectives are:
[List the stated business objectives]
The primary users are:
[List user groups and their key needs]
Analyze this requirements set for:
1. Coverage gaps - which business objectives are not
addressed by any requirement?
2. User journey gaps - what steps in the user's typical
workflow are not covered?
3. Non-functional gaps - are performance, security,
usability, and accessibility adequately addressed?
4. Edge case gaps - what error scenarios or unusual
conditions are not handled?
5. Dependency gaps - are there requirements that depend
on other systems, teams, or decisions not yet documented?
6. Traceability gaps - are there requirements without a
clear source or business justification?
For each gap found, suggest a specific requirement to
fill it, written in the same format as the existing ones.
Prompt 23: MoSCoW Prioritization with Rationale
Here are the requirements for [project]:
[List requirements with brief descriptions]
Project constraints:
- Budget: [amount]
- Timeline: [deadline]
- Team capacity: [brief description]
- Technical constraints: [any relevant limits]
Assign MoSCoW priority (Must Have / Should Have / Could
Have / Won't Have) to each requirement with:
1. The priority assignment
2. A one-sentence rationale explaining WHY this priority
(not just repeating the definition of the category)
3. Dependencies (does this requirement block others?)
4. Risk of deferral (what happens if we push this to a
later phase?)
Also identify which "Must Have" requirements could be
descoped to a smaller version that still delivers core
value if the budget or timeline gets cut.
Prompt 24: Business Case Financial Summary
Use this when you need to build or validate the financial section of a business case.
I am building a business case for [project description].
Here are the known costs and benefits:
Costs: [list all known costs - implementation, licensing,
training, ongoing maintenance, support]
Benefits: [list expected benefits - cost savings, revenue
increase, efficiency gains, risk reduction]
Timeline: [implementation duration and benefit realization period]
Generate a financial analysis including:
1. ROI calculation over [3/5] years with the formula shown
2. Payback period - the month when cumulative benefits
exceed cumulative costs
3. Total Cost of Ownership - all costs over the analysis
period, not just implementation
4. Sensitivity analysis: what happens to the payback period
if benefits are 30% lower than projected? What if costs
are 30% higher?
5. A one-paragraph executive summary of the financial case
that a CFO could read in 30 seconds
Present the numbers in a clear table format. Flag any
assumptions you made and suggest which ones I should
validate with the finance team.
Communication and Documentation (~30 min saved per communication)
Prompt 25: Stakeholder Update Email
Draft a project status update email for [audience:
steering committee / project sponsor / wider stakeholder
group].
Project: [name]
Current phase: [phase]
Key progress since last update: [bullet points]
Risks or blockers: [list any]
Decisions needed: [list any pending decisions]
Next steps: [upcoming milestones]
Audience context: [What does this audience care about
most? Are they detail-oriented or big-picture? Is there
a specific concern they raised last time that I need to
address?]
The email should:
- Lead with what the audience cares about most, not with
what happened chronologically
- If decisions are needed, present the options with your
recommended choice and a one-sentence rationale - do
not just list the options
- If there are risks, quantify the impact (e.g., "2-week
delay to Phase 2" not "potential timeline impact")
- Close with the single most important next step and who
owns it
- Stay under [150/300] words
After drafting, critique: would a busy executive get the
key message from reading only the first two sentences?
If not, rewrite the opening.
Prompt 26: Quick Stakeholder Message
The prompt you will use five times a day. For Slack messages, follow-up emails, and quick asks.
I need to send a [Slack message / email / Teams message] to
[Name, Role] about [topic].
Context: [1-2 sentences about what happened or what you need]
Tone: [direct / diplomatic / urgent / casual]
Goal: [what action do you want them to take?]
Write the message in under 100 words. Be specific about
what I need and by when. Do not pad with pleasantries
beyond a single greeting. If I need something by a
deadline, make the deadline the first sentence after
the greeting.
Prompt 27: Technical-to-Business Translation
This is core BA work - translating between worlds. AI is excellent at this.
A developer has provided this technical description:
"[Paste the technical explanation, error message,
architecture decision, or technical constraint]"
Translate this into a clear explanation for a non-technical
business stakeholder who needs to understand:
1. What this means for the project in business terms
2. What decision or action is needed from them
3. What the impact is if no action is taken
4. Any options available, with pros/cons in business language
Avoid all technical jargon. Use analogies if they help
clarify the concept. Keep it under 200 words.
Prompt 28: Change Request Impact Analysis
A stakeholder has requested the following change to our
project:
Change request: [describe the change]
Requested by: [name, role]
Current project state: [what's already been built/decided]
Analyze the impact of this change on:
1. Scope - what other requirements are affected?
2. Timeline - estimated delay (if any)
3. Budget - additional cost implications
4. Quality - any risks to existing functionality
5. Stakeholders - who else needs to be consulted or informed?
6. Dependencies - does this change trigger changes in other
systems or teams?
Provide a recommendation: accept, accept with modifications,
defer to next phase, or reject - with clear rationale.
Quality Review: Checking Your Own Work (~45 min saved per review)
This is the most underused category. AI is exceptionally good at reviewing BA artifacts for completeness, clarity, and consistency - the kind of review that a senior BA would do, but that you can get instantly.
Prompt 29: Requirements Quality Review
Review the following requirements for quality issues:
[Paste your requirements]
Check for:
1. Ambiguity - flag any requirement using vague words
(quickly, easily, user-friendly, efficient, etc.)
2. Testability - can each acceptance criterion be verified
with a specific test? If not, suggest a rewrite.
3. Completeness - are there obvious missing requirements
based on the described scope?
4. Consistency - do any requirements contradict each other?
5. Traceability - does each requirement have a clear source?
6. Feasibility - are there requirements that seem
unrealistic given typical technical constraints?
For each issue found, provide:
- The specific requirement ID
- The problem
- A suggested rewrite or fix
Prompt 30: Use Case Review
Review this use case for completeness and quality:
[Paste your use case]
Check for:
1. Is the primary actor clearly defined?
2. Are preconditions realistic and complete?
3. Does the main flow cover the full happy path without
skipping steps?
4. Are there missing alternate flows? (Think about: what
if the search returns no results? What if the user
enters invalid data? What if the system times out?)
5. Are postconditions defined for both success and failure?
6. Do business rules include specific, measurable thresholds?
7. Are step numbers referenced correctly in alternate flows?
Suggest specific additions or rewrites for each issue found.
Prompt 31: Stakeholder Register Audit
Review this stakeholder register for gaps:
[Paste your stakeholder register]
The project is [brief description].
Check for:
1. Missing stakeholders - based on the project description,
who might be affected but is not listed?
2. Generic engagement strategies - flag any strategy that
says "keep informed" or "regular updates" without
specificity
3. Interest/influence mismatches - does the engagement
effort match the stakeholder's influence level?
4. Missing conflict detection - are there stakeholders with
opposing interests that are not flagged?
5. Engagement frequency - is there a clear cadence for
each stakeholder?
For each issue, suggest a specific improvement.
Prompt 32: Assumptions Audit
Run this before presenting any recommendation. Every analysis rests on assumptions; the dangerous ones are the ones you made without noticing.
Here is my analysis and recommendation:
[paste]
List every assumption this analysis depends on, including
assumptions I clearly made without stating them.
For each assumption:
1. What happens to my recommendation if it is false
2. How I could cheaply test it before presenting
3. Danger rating: likelihood of being wrong times impact
on the recommendation
Order the list by danger rating, highest first. Do not
soften the findings. An assumption I cannot defend in the
meeting is a hole in the analysis.
Advanced Prompts: Connecting the Dots (~1 hour saved per analysis)
These prompts go beyond individual artifacts and help you think at a project level.
Prompt 33: Scope Creep Detection
Here is the original project scope statement:
[Paste scope statement]
Here are the requirements that have been documented since
the scope was approved:
[Paste requirements list]
Identify:
1. Which requirements are clearly within the approved scope
2. Which requirements extend beyond the original scope
(potential scope creep)
3. Which requirements are ambiguous - could be argued
either way
4. For scope creep items, suggest whether they should be:
- Absorbed (minor, high value)
- Deferred to Phase 2 (significant, lower priority)
- Rejected with rationale
- Escalated for scope change approval
Prompt 34: Project Risk Register Builder
For early planning, or the moment in a meeting when the PM asks for risks and everyone goes quiet.
Project context:
[paste summary: scope, timeline, stakeholders, systems,
constraints]
Draft a risk register with at least 10 risks. For each:
1. Risk statement (cause, event, impact)
2. Category: delivery / adoption / technical / compliance
3. Likelihood and impact (High/Medium/Low)
4. Early warning sign: what I would observe first if this
risk is materializing
5. One concrete mitigation
Prioritize risks specific to this project context over
generic project risks. Mark which risks a business analyst
can personally influence versus which need escalation.
Prompt 35: Cross-Artifact Consistency Check
I have produced the following artifacts for this project.
Check them against each other for consistency:
Stakeholder Register:
[Paste or summarize]
Requirements Document:
[Paste or summarize]
Use Cases:
[Paste or summarize]
Check for:
1. Stakeholders mentioned in requirements but missing from
the register (or vice versa)
2. Requirements referenced in use cases that don't exist
in the requirements document
3. Use case actors that don't map to documented stakeholders
4. Business rules in use cases that contradict requirements
5. Scope gaps - areas covered in one artifact but missing
from others
This cross-referencing is critical for traceability and
will be flagged during any formal review.
Prompt 36: Sprint Planning Support
Here is our prioritized backlog for the upcoming sprint:
[List user stories with priorities and estimates]
Sprint capacity: [X story points / Y days]
Help me:
1. Identify the optimal set of stories that fits within
capacity while maximizing business value
2. Flag dependencies between stories that affect ordering
3. Identify stories that are too large and should be split
(with suggested split approach)
4. Suggest acceptance criteria additions for any stories
that seem under-specified
5. Identify risks - stories that might take longer than
estimated and why
Prompt 37: Retrospective and Lessons Learned
Use this after a project phase completes or a sprint with notable outcomes.
Here is what happened during [sprint X / Phase Y / the
project]:
What went well: [list]
What went poorly: [list]
Surprises: [anything unexpected]
Stakeholder feedback: [any notable quotes or themes]
Help me structure a retrospective analysis:
1. For each "went poorly" item, apply root cause analysis
to distinguish symptoms from causes
2. For each root cause, propose a specific, actionable
process change (not "communicate better" but "add a
15-minute dependency check to sprint planning")
3. For "went well" items, identify what specifically made
them work so we can replicate it
4. Identify patterns - are any of the problems recurring
from previous retrospectives?
5. Recommend the top 3 changes to implement next sprint,
prioritized by impact-to-effort ratio
Prompt 38: Solution Pre-Mortem
The design feels settled, which is exactly when it is most dangerous. A pre-mortem finds failure modes while they are still cheap to fix.
Proposed solution:
[paste]
Run a pre-mortem. It is 12 months from now and this
solution failed. Write the 5 most plausible failure
narratives, each in 3 to 4 sentences: what went wrong,
what early signal was ignored, and who was affected.
For each narrative, propose one thing I could do this
month to reduce that failure mode.
Rank the narratives by plausibility given the context I
provided, not by drama.
When to use: After solution design, before stakeholder sign-off. Bring the top two narratives to the review meeting as discussion points; it makes you look thorough because you are being thorough.
Breaking Into BA: Prompts for Career Switchers
Everything above assumes you already have stakeholders, sprints, and meetings. If you are still working toward your first BA role, you have a different problem: no project to practice on, no senior BA to review your work, and an interview coming where someone will ask about experience you do not have.
AI closes more of that gap than most people realize. These five prompts cover the work of breaking in: positioning your existing experience, practicing the interview, generating realistic cases to work through, learning concepts in your own language, and getting honest review of your practice artifacts.
Prompt 39: Translate Your Experience into BA Language
Use this before writing your resume or LinkedIn profile. Career switchers consistently undersell experience that is genuinely relevant because they describe it in their old profession's vocabulary.
I am switching careers into business analysis from [current or
previous role, e.g., customer support team lead, QA tester,
operations coordinator]. Here is what I actually did in that role:
[Describe your responsibilities in plain language - projects you
worked on, problems you solved, people you coordinated between]
Help me:
1. Identify which of these experiences map to recognized BA
competencies (elicitation, stakeholder management, process
analysis, requirements documentation, data analysis)
2. Rewrite my top 5 experiences as resume bullets using BA
terminology, each with a concrete outcome
3. Flag any bullet that overstates the experience - I want
credible, not inflated
4. Identify the 2-3 biggest gaps between my experience and a
typical junior BA job description, so I know exactly what
to practice
Before rewriting, ask me follow-up questions about specifics:
numbers, team sizes, outcomes, tools. Vague bullets are worthless.
Pro tip: Point 3 matters more than it looks. Hiring managers read hundreds of AI-polished resumes. A bullet you cannot defend in a follow-up question is worse than a modest one you can talk about for five minutes.
Prompt 40: BA Interview Simulation
Run this at least three times before a real interview, with a different company type each time.
You are a hiring manager interviewing me for a junior business
analyst position at [company type, e.g., a mid-size insurance
company]. I am a career switcher coming from [background] with
no formal BA job experience.
Run a realistic interview:
- Ask one question at a time and wait for my answer
- Mix behavioral questions ("tell me about a time...") with
scenario questions ("a stakeholder gives you a vague
requirement - walk me through what you do")
- Include at least one question that directly probes my lack
of BA job experience
- Push back on weak or generic answers the way a real
interviewer would
After 8-10 questions, break character and give me:
1. An assessment of each answer (strong / adequate / weak)
2. The specific phrases that undermined my credibility
3. Rewritten versions of my two weakest answers
4. The one question I should prepare better before a real
interview
When to use: Alongside our guide to BA interview preparation with no experience, which covers the eight questions career switchers actually face. Use the guide to learn the answers, use this prompt to pressure-test them out loud.
Prompt 41: Practice Case Generator
You learn elicitation by eliciting. This prompt builds a case in a domain you already understand, so your domain knowledge carries you while you practice the BA skills.
I am learning business analysis and need a realistic practice
case. Build one set in [a domain I know well, e.g., retail,
healthcare administration, logistics, hospitality].
The case must include:
1. A company background (2-3 paragraphs) with a real business
problem, not a textbook one
2. 4-5 named stakeholders with roles, conflicting priorities,
and at least one concern each that they will not volunteer
unless asked
3. A vague project brief, written the way a real sponsor
writes one: ambiguous scope, a missing constraint, and one
unstated assumption
4. A list of deliverables for me to produce: stakeholder
register, requirements document with MoSCoW priorities,
and one use case
Do not solve the case for me. After presenting it, stay in
character as any stakeholder I name, and answer my elicitation
questions the way that stakeholder would.
Prompt 42: Learn a Concept Through Your Own Background
The fastest way to make a BA concept stick is to map it onto something you already know cold.
Explain [BA concept, e.g., MoSCoW prioritization, non-functional
requirements, use case alternate flows] using analogies from
[my background, e.g., restaurant management, nursing, military
logistics].
Then:
1. Give me one realistic example of the concept applied in a
software project
2. Give me the same example done badly, and explain exactly
what went wrong
3. Ask me 3 questions to test whether I actually understood
it - and correct my answers honestly, do not just agree
with them
Prompt 43: Mock Senior BA Review
The hardest thing to get as a self-taught BA is honest review. AI defaults to encouragement, which is useless. This prompt forces the review you actually need.
You are a senior business analyst reviewing a junior analyst's
practice work. I have no professional BA experience, so review
this the way you would review a first deliverable from a new
hire: direct, specific, and focused on what would embarrass me
in front of a real stakeholder.
Here is my [artifact type: stakeholder register / requirements
document / use case]:
[Paste your practice artifact]
Give me:
1. An overall grade (A to F) with a one-sentence justification
2. The 3 issues that matter most, in priority order
3. Line-level corrections for the weakest sections
4. One thing I did well, only if it is genuinely true
5. What a hiring manager would conclude about me if this
artifact were in my portfolio
Do not soften the feedback. A harsh accurate review teaches me
more than a kind vague one.
These five prompts will get you practicing today. But practicing in a chat window has a ceiling: there is no case continuity between sessions, no finished artifact at the end, and the model that coached you through the work is the same one grading it. BAvolta's Case Lab was built for exactly this gap. You work realistic cases end to end, your deliverables are graded against expert model answers, and you finish with portfolio artifacts you can put in front of a hiring manager. If you are starting from zero, the complete career switch guide maps the whole path, and Module 1 of the BA Fundamentals course is free.
Building Your Prompt Library
The prompts above are starting points. The most effective BA prompt libraries are personalized over time. Here is how to build yours.
Start with the prompts that match your current project needs. Copy them, use them, and notice where the output is not quite right. Refine the prompt - add more context, adjust the format, include examples of what "good" looks like. Save the refined version.
Here is what refinement looks like in practice. I used Prompt 14 (Stakeholder Map Generator) on a real project and the engagement strategies came back generic: "Schedule bi-weekly check-ins with the project sponsor." Useful as a placeholder, useless as guidance. I refined the prompt by adding this line: "For each stakeholder's engagement strategy, reference the specific concern from their profile and explain how your recommended approach addresses that concern." The next run produced strategies like: "Sarah is concerned about disruption to her team's Q3 targets. Schedule a 20-minute 1:1 before the next steering committee to walk through the implementation timeline and show her team's workload will peak in Q4, not Q3." That is actionable. That is what I saved.
After a month of regular use, you will have a library of ten to fifteen prompts that are tuned to your specific domain, your organization's documentation standards, and your personal working style. That library becomes a productivity multiplier that compounds over time.
When you are ready to turn that personal collection into a shared team asset, our guide to building a business prompt database covers the schema, governance, and 15 cross-department starter prompts that make a team-wide library work.
If you are new to business analysis and building these skills from scratch, start with our complete career switch guide - the prompts in this article will accelerate your learning once you have the fundamentals.
Four principles for effective BA prompting:
Ask questions before answering. This is the single highest-leverage habit. Add "Before you start, ask me questions about my context so your output is specific to my situation" to any prompt. The AI will draw out details you did not think to include. It works because AI is making dozens of assumptions about your project, your stakeholders, and your organization. Forcing it to ask instead of assume produces dramatically better output.
Context is everything. The more you tell the AI about your project, stakeholders, constraints, and objectives, the more specific and useful the output. A prompt that says "write user stories" will get generic results. A prompt that says "write user stories for a CRM search enhancement project with a $75,000 budget, five stakeholders with conflicting priorities, and a two-week deadline" gets work you can actually use.
Make the AI critique its own work. After any generation step, add "Now critique what you just produced - what is vague, what is missing, what would a senior BA flag in review? Then fix those issues." This self-review step catches 80% of the problems you would have caught manually, saving you a full revision cycle.
Iterate, do not restart. When the output is not right, do not rewrite the prompt from scratch. Tell the AI what is wrong: "The engagement strategies are too generic. For Lisa Huang specifically, reference her concern about ROI justification for expenditures above $75K." Iterative refinement produces better results than starting over, because the AI builds on its previous context.
If you want to practice applying these prompts to realistic BA scenarios, the Case Lab on BAvolta lets you work through stakeholder analysis, requirements elicitation, and artifact creation in simulated project environments - with AI-powered feedback on your output. The BA Fundamentals course teaches the analytical skills these prompts enhance. Module 1 is free.
Bookmark this page. Better yet, take it with you: subscribe below and we will send the full library as a duplicate-ready Notion template, updated as new prompts are added.
Frequently Asked Questions
Can AI replace business analysts?
No. AI accelerates the generative parts of BA work - drafting, structuring, reviewing - but cannot replace the judgment, stakeholder relationships, and organizational awareness that make a BA effective. The prompts in this library produce first drafts, not finished deliverables. Your domain expertise, political awareness, and professional judgment are what turn AI output into trusted analysis.
What AI tools do business analysts use?
The most common tools in 2026 are Claude, ChatGPT, Gemini, and Microsoft Copilot. Most organizations have approved at least one. The prompts in this library work across all of them. The choice of tool matters less than the quality of your prompts and the rigor of your review process.
How do I use AI for requirements gathering?
AI does not gather requirements - you do, through stakeholder interviews, workshops, and observation. AI helps you prepare for those sessions (Prompts 1-3), process the outputs afterward (Prompts 5-6), and structure the results into formal documentation (Prompts 9-13). The elicitation itself remains a human skill.
Is using AI for business analysis cheating?
Using a calculator is not cheating at math. Using a spell checker is not cheating at writing. AI is a tool that handles the mechanical parts of analysis work so you can focus on the parts that require human judgment. The analyst who uses AI to produce a first draft in 20 minutes and spends 40 minutes refining it with domain expertise produces better work than the analyst who spends 3 hours writing from scratch, because more of their time goes to thinking rather than typing.