TL;DR: Generative AI training for business analysts should teach people to turn approved evidence into testable requirements, not simply produce more documentation. Use seven connected exercises: extract source-backed needs; prepare elicitation questions; draft bounded user stories; write acceptance criteria; investigate non-functional needs; build traceability; and assess a proposed change. Grade source accuracy, explicit uncertainty and testability. Keep stakeholder approval separate from AI-generated drafts.
A requirement can be well written and still be wrong. An AI assistant may fill in an approval deadline, invent an exception or assume a system integration that stakeholders never requested. Fluent wording makes those additions easy to miss.
A useful corporate workshop gives analysts a bounded source packet, asks them to produce a specific artifact and then makes them defend each material statement. The learning outcome is better analysis and review judgment, with AI assisting the work.
This article describes a proposed workshop design for business analysis teams. It focuses on requirements and acceptance criteria. For actions, risks and status reporting, use the separate AI training workshop for project managers.
Method and disclosure: The exercises, prompts, timing and scoring model are illustrative training materials, not a published LuMay course syllabus or measured customer result. Professional references were checked on 10 November 2026. This article does not promise a certification, accreditation, delivery schedule or productivity improvement.
Define the outcome before choosing the AI tool
Participants should leave with a requirements pack they can explain and defend: evidence references, open questions, user stories, acceptance criteria, a traceability matrix and a change-impact note. A long document is not the target.
IIBA's business analysis glossary relates acceptance criteria to the conditions needed for stakeholder acceptance. The training implication is practical: a criterion should help a reviewer decide whether an agreed requirement has been met.
Use an organization-approved AI environment and permitted synthetic or sanitized material. Confirm handling of prompts, uploaded files and generated outputs before the workshop. Do not use real customer records or confidential project material merely because the exercise is internal.
Build one fictional source packet
Hypothetical scenario: a company wants a portal for employees requesting access to internal applications. The proposed workshop packet contains these source notes:
| Source ID | Approved training fact | Boundary |
|---|---|---|
| S1 | An employee can request access to an application from an approved catalog. | The catalog's content is supplied; the AI cannot add applications. |
| S2 | The employee's line manager approves or rejects the request before provisioning. | No delegate or self-approval policy has been supplied. |
| S3 | A request for sensitive access also requires a security review. | The packet identifies which catalog items are sensitive. |
| S4 | The employee can view the request status. | Notification channels and response-time targets are undecided. |
| S5 | When a provisioning timeout occurs, the outcome may be unknown. | Retry and reconciliation behavior needs stakeholder agreement. |
Add a short interview transcript, a sample request form and a process sketch consistent with those notes. Seed ambiguities deliberately. For example, a stakeholder may say 'urgent requests should move quickly' without defining urgency or an approval exception.
Keep a facilitator answer key identifying what the packet supports, what remains unknown and which additions would be fabricated. Learners should not be penalized for preserving uncertainty when the source is incomplete.
1. Extract needs with source evidence
Task: identify the needs, constraints and unresolved questions in the packet. Ask the AI to cite source IDs and distinguish evidence from inference. Review the output against the actual sources.
Use only the supplied source packet. Create a table with: need ID, proposed need, source ID and excerpt, confidence reason, and unresolved question. Label every inference as a hypothesis. Do not add deadlines, integrations or policy exceptions.Expected artifact: an evidence register. For S4, 'employees can view request status' is supported. 'Employees receive an SMS within five minutes' is not.
Review test: ask participants to locate the evidence for a randomly selected row. A citation to a real document does not make an unsupported claim correct.
2. Prepare elicitation questions that expose assumptions
Task: turn the unknowns into questions for the right stakeholders. Name the decision owner and explain which requirement depends on the answer.
From the evidence register, propose questions that resolve missing decisions. For each, name the stakeholder role, ambiguity, consequence and artifact affected. Do not answer the questions yourself.For manager absence, ask who may approve, under what authorization and with what record. For sensitive access, ask how security review interacts with a manager rejection. For urgency, establish whether it changes priority or authority; those are separate decisions.
Expected artifact: an elicitation plan. Avoid leading questions that imply approval bypasses already exist.
Review test: the facilitator answers one question and leaves another unresolved. Learners should update only the requirements the answer supports.
3. Draft user stories with explicit boundaries
Task: draft a small set of stories from confirmed needs. Separate employee requests, managerial decisions, security review and status visibility rather than compressing the whole workflow into one story.
Draft user stories from confirmed needs only. Include actor, goal, business value, source IDs, scope boundaries and unresolved decisions. Keep assumptions visible. Do not treat proposed designs as approved requirements.Illustrative story: 'As an employee, I want to submit an access request for an approved catalog application so that the required reviewers can assess it.' This does not promise automatic access or a completion deadline.
Expected artifact: a small backlog with source links and an open-question log. Do not require a story format when another representation expresses the need more clearly.
Review test: remove a source and ask which stories need reconsideration. Participants should explain the relationship rather than ask AI to regenerate everything.
4. Write acceptance criteria that can fail
Task: describe observable outcomes for supported behavior. Include positive, negative and boundary cases. 'The process is seamless' offers no unambiguous test.
For the selected story, draft observable acceptance criteria. Map each to a source. Mark criteria needing stakeholder decisions as proposed. Explain the test evidence needed.| Case | Illustrative criterion | Review status |
|---|---|---|
| Catalog selection | A submitted request retains the chosen catalog item and requester identity. | Derived draft; validate with stakeholders |
| Pending manager decision | The request does not enter provisioning without manager approval. | Supported by S2; review wording |
| Sensitive access | Provisioning requires both manager approval and the required security review. | Supported by S2 and S3 |
| Manager unavailable | Automatically approve after 24 hours. | Unsupported; reject or return for elicitation |
Given/When/Then helps express examples, but the format cannot establish correctness. Check expected states, access boundaries and evidence.
Review test: present an implementation that meets the words while missing the business need. Ask learners to identify the loophole and improve the criterion.
5. Investigate non-functional needs without inventing targets
Task: explore availability, accessibility, performance, access control and audit needs. Identify what requires a measurable target and who can authorize it.
Identify candidate non-functional requirements. For each, explain the risk, ask for a measurable target, name the decision owner and state whether source evidence exists. Do not invent numeric limits.AI can propose questions and failure cases. It should not establish a retention period or response-time commitment without an approved basis. Label proposed targets visibly.
For S5, ask how an uncertain provisioning outcome is detected and reconciled before a retry. Do not equate a timeout with a failed action.
Expected artifact: a table separating confirmed controls from proposed targets.
Review test: compare a slow but correct system with a fast system that grants unauthorized access. Learners should identify separate acceptance dimensions.
6. Build traceability and verify the connections
Task: connect business need, source, requirement, acceptance criterion, test and decision owner. Ask AI to flag missing links, then verify each relationship.
IIBA's Business Analysis Standard discusses requirement lineage and relationships to needs, solution components and other requirements. Use that principle to expose unsupported or untested work.
| Source | Requirement | Test evidence | Open decision |
|---|---|---|---|
| S2 | Manager approval precedes provisioning | Inspect pending and rejected requests | Delegated approval |
| S3 | Sensitive access needs security review | Inspect state for a sensitive application | Security rejection handling |
| S4 | Employee can view request status | Compare visible and stored status | Notification channels |
Expected artifact: a traceability matrix with meaningful links. A populated spreadsheet is not proof that its relationships are correct.
Review test: seed a criterion without a source and a requirement without a test. Learners should detect both and identify the decision needed.
7. Assess a change and revise only affected artifacts
Task: introduce a hypothetical approved change: a documented delegate may decide a request while the line manager is unavailable. The facilitator supplies the conditions. AI must not invent delegation rules.
Using the approved change and traceability matrix, identify affected requirements, criteria, tests and process steps. Preserve unaffected approved content. Provide a change log with evidence for each revision.Expected artifact: an impact note and revised subset of the backlog. Consider identity, authority, the recorded decision-maker and any security-review dependencies.
Review test: compare before and after versions. Reject unrelated additions such as new SMS notifications or automatic approvals. A plausible improvement is still a scope change if nobody authorized it.
Use a practical workshop schedule
Illustrative 180-minute plan: adjust to the team's familiarity and artifact complexity. This is a planning example, not a LuMay delivery commitment.
| Activity | Minutes |
|---|---|
| Briefing and permitted-tool check | 15 |
| Exercise 1: evidence | 15 |
| Exercise 2: elicitation | 15 |
| Exercise 3: user stories | 20 |
| Exercise 4: acceptance criteria | 25 |
| Break | 10 |
| Exercise 5: non-functional needs | 20 |
| Exercise 6: traceability | 20 |
| Exercise 7: change impact | 20 |
| Assessment and debrief | 20 |
| Total | 180 |
Pair participants for the first task, then assess individually on an equivalent but unfamiliar packet. Repeating the same example can measure memory of the answer key instead of transferable judgment.
Score judgment, not output volume
Use this proposed rubric for the final artifact. Score each dimension 0–2: 0 means materially missing or wrong, 1 means partial, and 2 means consistently demonstrated. The maximum is 10.
| Dimension | Evidence of a strong result |
|---|---|
| Source accuracy | Claims are supported by the cited evidence |
| Uncertainty handling | Unknowns stay explicit and have decision owners |
| Testability | Criteria describe observable outcomes and failure cases |
| Traceability | Needs, requirements, criteria and tests have meaningful relationships |
| Change discipline | Revisions follow approved changes without unrelated additions |
Set any pass threshold before assessment. Treat invented approvals, prohibited data exposure and unsupported business commitments as critical review issues even when the overall score is high. Record assistance given so comparisons remain fair.
For outcomes beyond the lab, use our corporate AI training scorecard. Attendance and document length do not establish workplace improvement.
What the training package should include
- Synthetic source packet with stable IDs and deliberate ambiguities.
- Facilitator answer key distinguishing facts, hypotheses and unresolved decisions.
- Seven learner worksheets and reusable prompt instructions.
- Requirements and traceability templates with review status.
- Equivalent assessment packet and a scoring rubric.
- Permitted-tool and data-handling brief.
- A follow-up task using approved work material when appropriate.
An IIBA-hosted article on AI-assisted business analysis discusses draft acceptance criteria and change-impact analysis while retaining professional judgment. This workshop design translates such activities into assessed practice; it is not IIBA-endorsed training.
Questions to settle before booking a workshop
Do participants need coding? These exercises do not require coding. They require enough business-analysis familiarity to distinguish needs, assumptions and approved decisions.
Which AI tool should the team use? Use an approved environment that supports the permitted packet and a reviewable source workflow. Check data handling rather than choosing solely by brand.
Can AI approve requirements? It can assist drafting and inspection. Designated stakeholders retain approval authority under the organization's process.
Does the workshop qualify for professional-development credits? No credit or certification claim is made here. Verify a provider's specific recognition and eligibility separately.
Request training around the artifacts your analysts produce
Bring an example of current requirements work, the quality problems you need to reduce and the tools the team may use. Ask providers to demonstrate how their lab teaches source discipline, testable criteria and controlled change.
For a LuMay workshop, confirm audience, data boundaries, target artifacts and assessment expectations before agreeing a syllabus. Start with LuMay's AI training page. The proposed exercises here should be scoped and confirmed for the engagement.
