Writing Requirements Artifacts With AI

The Artifact Layer Has Changed

Business analysts produce a range of structured artifacts: Business Requirements Documents (BRDs), Functional Specifications, User Stories with acceptance criteria, Use Cases, Process Flow documentation, Gap Analysis reports. Producing these from elicitation notes previously required significant writing time.

AI can now produce first drafts of any of these artifacts in minutes — given the right input and the right prompt. The constraint is no longer writing speed. It's the quality of the input and the rigor of the review.

Prompting for User Stories

User stories are the most common BA artifact in agile environments. The standard format — "As a [role], I want [feature], so that [benefit]" — is AI-friendly because the structure is consistent.

From raw requirements to user stories:

Here are the extracted requirements from stakeholder
interviews for the accounts payable automation system:
[paste requirements list]

Convert these to user stories in this format:
- Title: [short descriptive title]
- Story: As a [role], I want [action], so that [benefit]
- Acceptance Criteria: [numbered list of verifiable conditions]
- Out of Scope: [what this story explicitly does NOT cover]

Use these roles: AP Clerk, AP Manager, Finance Controller, System Admin.
Each story should be independently testable.
Flag any requirements that are too large to be a single story.

The validation steps for AI-generated user stories:

1. Does the role match the actual user who performs the action?
2. Are the acceptance criteria specific enough to be testable? Vague criteria ("the system should perform well") must be replaced with measurable ones.
3. Are there missing acceptance criteria for obvious edge cases (empty state, error state, timeout)?
4. Is the "out of scope" section accurate to what was discussed?

Refining acceptance criteria:

Here is a user story generated from requirements:
[paste story]

The acceptance criteria are too vague for a developer to implement
against. Rewrite the acceptance criteria to be:
- Specific and measurable
- Covering the happy path, the error path, and at least 2 edge cases
- Written from the user's perspective, not the system's
- Verifiable by a QA tester without knowledge of the implementation

Prompting for Business Requirements Documents

A BRD is a more formal artifact — typically covering executive summary, business objectives, scope, stakeholder analysis, functional requirements, non-functional requirements, constraints, and assumptions.

Draft a Business Requirements Document for the following project:

Project: Accounts Payable Automation System
Organization type: Mid-size manufacturing company, 500 employees
Current state: Manual invoice processing via email and spreadsheets
Desired state: Automated matching, digital approval workflow,
ERP integration

Stakeholders: AP team (8 people), Finance management, IT, Procurement
Timeline: 6-month implementation

Use this structure:
1. Executive Summary (3-4 sentences)
2. Business Objectives (5-7 measurable objectives)
3. Scope — In Scope / Out of Scope
4. Stakeholder Analysis (role, interest, influence, concerns)
5. Functional Requirements (numbered, grouped by domain area)
6. Non-Functional Requirements (performance, security, availability)
7. Constraints and Assumptions
8. Success Metrics

Tone: formal business document. No technical jargon in functional reqs —
these will be reviewed by the finance team, not IT.

The output will be structurally complete. Your review should focus on:

• Business objectives that are measurable (not "improve efficiency" — "reduce invoice processing time from X days to Y days")
• Scope that matches what was actually agreed — AI will infer reasonable scope, not necessarily agreed scope
• Functional requirements that match your elicitation notes
• Non-functional requirements that reflect your organization's actual standards

Process Flow Documentation

Process flows (current state "as-is" and future state "to-be") are typically created in tools like Visio, Lucidchart, or Miro. AI can produce the textual description of the process that then gets translated to a diagram.

Describe the current-state (as-is) process for invoice
processing at a manufacturing company based on this
workflow description: [paste notes]

Format: numbered process steps, each with:
- Actor: who performs this step
- Action: what they do
- System: what tool/system they use
- Decision points: any yes/no branching
- Exceptions: what happens when something goes wrong

Then describe the future-state (to-be) process assuming
an automated AP system that handles matching and routing.
Highlight where the new system replaces or augments human steps.

Gap Analysis Artifacts

Gap analysis compares current state to desired state to identify what needs to change. AI is particularly well-suited to this when you have both a current-state document and a future-state specification.

Compare these two documents:
Current state: [paste current process/system description]
Future state requirements: [paste future requirements]

Identify:
1. Gaps — capabilities required in the future state not present in the current state
2. Changes — capabilities present in both states but requiring modification
3. Preserved — capabilities that transfer unchanged
4. Removals — current-state capabilities not present in the future state

Format: table with columns: Category | Item | Current State | Future State | Impact

Maintaining Traceability

One of the most important BA responsibilities is requirements traceability — ensuring every requirement can be traced from its source (stakeholder, regulation, business objective) through design, development, and testing.

AI can help maintain a traceability matrix:

Here are the requirements from our BRD (numbered FR-1 through FR-24)
and here are the user stories from our backlog (US-1 through US-31):
[paste both]

Create a traceability matrix showing:
- Which user story covers each functional requirement
- Any functional requirements not covered by any user story (gaps)
- Any user stories not traceable to a functional requirement (scope creep)

Key Takeaways

• AI drafts user stories, BRDs, process flows, and gap analyses from your notes — review and validation are the BA's primary contribution
• User story validation focuses on: correct role, measurable acceptance criteria, edge case coverage, accurate scope
• BRD validation focuses on: measurable objectives, agreed scope, requirements matching elicitation notes, appropriate non-functional requirements
• AI-generated acceptance criteria are often too vague — always refine them to be testable by a QA engineer
• Traceability remains the BA's responsibility — AI can help maintain the matrix but cannot determine what the correct linkages are

---

Apply It: Take any set of requirements you have access to (even from a previous project) and use AI to generate user stories from them. Review the output against the four validation criteria: correct role, measurable acceptance criteria, edge case coverage, accurate scope. Note what percentage of the generated stories need revisions and what type of revision they need most.