Requirements Analysis with AI
Turn conversations into requirements nobody has to guess.
Use AI to elicit, structure and validate requirements, from stakeholder conversations to acceptance criteria, data rules and change impact that developers, testers and AI agents can rely on.
AI TEACHING PERSPECTIVES · Meet the team
When AI agents implement what they are given, the quality of the requirements becomes the quality of the software. Analysts who can turn messy conversations into precise, testable requirements are now on the critical path of every delivery.
This course shows you how to use AI to prepare, synthesise and critique requirements — and where you must not let it decide for you. You will practise elicitation, behaviour specification, data and rule modelling, validation and change impact on one realistic case.
One step closer.
With every module.
6 modules · 0 published lessons
Open a module to explore its lessons.
01LEARNING MODULE · ≈3 hoursThe analyst in an AI-assisted team0 lessons · Week 1
Understand why requirements quality now sets the pace of delivery, and where analysis fits in a spec-driven workflow.
Objectives
- Explain how AI-assisted implementation changes the value of requirements work.
- Recognise the main kinds of ambiguity in a request.
- Place analysis artefacts across the delivery lifecycle.
Topics
- Requirements as the input to coding agents
- Four kinds of ambiguity: scope, behaviour, data and responsibility
- What AI does well and badly in analysis
- The analyst’s artefacts, from brief to traceability matrix
Concepts
Ambiguity
A statement that two reasonable readers could implement differently.
Requirement
A statement of something the system must do or satisfy, written so that it can be verified.
Traceability
The ability to follow a requirement from its source to the design, code and tests that satisfy it.
Exercise
Classify the ambiguities in five sample requests.
Deliverable
An ambiguity log with the question that resolves each item and who should answer it.
Lesson material is being prepared for this module.
02LEARNING MODULE · ≈4 hoursElicitation with AI0 lessons · Week 1
Prepare interviews, process transcripts and surface conflicts with AI support, while keeping every requirement linked to a real source.
Objectives
- Prepare interview guides and question banks with AI.
- Turn transcripts into candidate requirements with source references.
- Detect conflicting statements between stakeholders.
Topics
- Interview preparation and question banks
- Summarising transcripts with citations
- Stakeholder maps and decision rights
- Spotting and recording conflicts
- Confidentiality when working with recordings and transcripts
Concepts
Candidate requirement
A requirement drafted from elicitation material that still needs confirmation from its owner.
Source reference
The transcript line, document or decision that a requirement came from.
Stakeholder conflict
Two statements from different stakeholders that cannot both be true in the same system.
Exercise
Process three interview transcripts — finance, programme manager and learner — for the registration case.
Deliverable
A list of candidate requirements with source and owner, and a list of conflicts to resolve.
Lesson material is being prepared for this module.
03LEARNING MODULE · ≈4 hoursBehaviour and acceptance criteria0 lessons · Week 2
Write atomic, testable requirements and derive edge and failure cases systematically.
Objectives
- Write atomic requirements using EARS and given–when–then.
- Derive happy-path, edge and failure cases systematically.
- Use AI as a reviewer for vague words and untestable criteria.
Topics
- EARS requirement templates
- Given–when–then scenarios
- Happy path, edge cases and failure states
- Splitting compound requirements
- AI-assisted review for soft words such as “fast”, “robust” or “gracefully”
Concepts
EARS
Easy Approach to Requirements Syntax: a small set of sentence patterns that make requirements consistent and unambiguous.
Atomic requirement
A requirement that states one behaviour, so it passes or fails on its own.
Failure state
A specified behaviour for when something goes wrong, such as a declined payment or a timeout.
Exercise
Specify the registration-and-payment behaviour of the shared case.
Deliverable
A behaviour specification with numbered requirements and acceptance criteria.
Lesson material is being prepared for this module.
04LEARNING MODULE · ≈4 hoursData, rules and process models0 lessons · Week 2
Make the data, business rules and states behind the behaviour explicit, so nobody has to infer them from code.
Objectives
- Write a data dictionary with validation rules.
- Express business rules as decision tables.
- Model state transitions and simple processes.
Topics
- Data dictionaries and validation rules
- Business rules and decision tables
- State transition tables
- Generating process diagrams from text, for example with Mermaid
- Checking models against the requirements
Concepts
Data contract
The agreed shape, constraints and meaning of the data exchanged or stored.
Decision table
A table listing combinations of conditions and the action each combination leads to.
State transition
A move from one state to another in response to an event, such as pending to paid.
Exercise
Model the registration states and the payment rules.
Deliverable
A data dictionary, a decision table and a state transition table.
Lesson material is being prepared for this module.
05LEARNING MODULE · ≈4 hoursValidation and traceability0 lessons · Week 3
Check that the requirements are complete, consistent and testable, and connect each one to its evidence.
Objectives
- Run a structured requirements review.
- Use AI to find gaps, duplicates and contradictions.
- Build a requirement-to-test matrix with QA.
Topics
- Review techniques and checklists
- AI-assisted consistency checks
- The traceability matrix
- Sign-off and its limits
- Working with QA from day one
Concepts
Traceability matrix
A table mapping each important requirement to the test or check that proves it.
Review finding
A recorded issue in a requirement, with its type, severity and owner.
Sign-off
A stakeholder’s agreement to a requirement set. It records a decision; it does not prove the requirements are right.
Exercise
Review a deliberately flawed specification.
Deliverable
A review report and a traceability matrix.
Lesson material is being prepared for this module.
06LEARNING MODULE · ≈4 hoursChange and impact analysis0 lessons · Week 3
Handle change without losing intent: assess impact, version requirements and communicate clearly.
Objectives
- Assess the impact of a change on requirements, data and tests.
- Version and retire requirements.
- Communicate a change to people and to agents.
Topics
- Writing a change request
- Impact analysis with AI, and its blind spots
- Versioning and retiring requirements
- Communicating change to teams and agents
Concepts
Change request
A documented proposal to change agreed requirements, with reason, owner and impact.
Impact analysis
Identifying everything a change affects: requirements, data, processes, tests and users.
Requirement baseline
The agreed, versioned set of requirements that change requests are measured against.
Exercise
Analyse a new refund policy for the registration case.
Deliverable
A change request with impact analysis and an updated requirement set.
Lesson material is being prepared for this module.
The course,
in context.
Explore the approach, expectations and practical details. These are public course notes, separate from your learning modules.
PUBLIC COURSE GUIDEWho this is for
- Business analysts, systems analysts and requirements engineers.
- Product owners who write detailed requirements.
- Developers and testers who regularly clarify requirements.
Before you begin
- Experience writing requirements, user stories or functional specifications.
- No programming required; reading simple tables and diagrams is enough.
- Access to a general-purpose AI assistant of your choice.
What you will learn
- Prepare elicitation and synthesise transcripts with traceable sources.
- Write atomic, testable requirements using EARS and given–when–then.
- Model data, business rules and states explicitly.
- Validate requirements and build a traceability matrix with QA.
- Analyse and communicate the impact of change.
Applied assignments
Elicitation pack
Ambiguity log, candidate requirements with sources, and a stakeholder conflict list.
Behaviour and data specification
Numbered requirements, acceptance criteria, data dictionary, decision table and state table.
Validation and change pack
Review report, traceability matrix and a change request with impact analysis.
Your capstone project
Specify the registration and refund process
Capstone brief
Start from three conflicting stakeholder interviews about course registration and a new refund policy. Elicit and reconcile the requirements, specify behaviour and data, validate the result with a traceability matrix, and prepare a change request that a development team and its AI agents could implement without guessing.
Assessment
A 60-minute scenario exam: repair ambiguous requirements, resolve a stakeholder conflict, complete a decision table and assess the impact of a change.
What you will produce
- Elicitation and interview template
- Requirement specification template (EARS and given–when–then)
- Data dictionary and decision-table templates
- Traceability matrix and change-request templates
The method, explained
Requirements are now the input to the machine
When a coding agent implements a feature, it implements what it was given. If a rule is missing, it invents one. If two stakeholders disagree, it picks a side without telling anyone. Good analysis is the cheapest place to remove those guesses.
Where AI helps an analyst
- Preparing interview guides and checklists.
- Summarising long transcripts, with references back to the original lines.
- Proposing edge cases and failure states you may have missed.
- Reviewing requirements for vague words, duplicates and contradictions.
Where it must not decide
- Which stakeholder’s rule wins.
- What the business is willing to risk.
- Whether a requirement is still valid after a change.
Those decisions belong to named people. The analyst’s job is to make them visible and recorded.
How the case runs
Throughout the course you work on one realistic case: the course-registration and payment flow of a small learning platform, plus an AI-powered assistant that helps visitors choose a course. Developers meet the same case in Spec-Driven Development, so teams that learn together practise on the same material. You move from interviews to a behaviour specification, model the data and rules behind it, validate it with QA, and handle a real change: a new refund policy.
Course glossary
Ambiguity
A statement two reasonable readers could implement differently.
EARS
Easy Approach to Requirements Syntax: sentence patterns for clear requirements.
Atomic requirement
A requirement that states exactly one behaviour.
Decision table
Combinations of conditions and the action each leads to.
Data contract
The agreed shape, constraints and meaning of data.
Traceability matrix
A map from requirements to the evidence that proves them.
Requirement baseline
The agreed, versioned requirement set that changes are measured against.
Compare the approaches
Ways of expressing requirements
| Format | Best for | Watch out for |
|---|---|---|
| User stories | Conversation and prioritisation | Hide edge cases, data rules and failure behaviour |
| Use cases | End-to-end flows with alternatives | Grow long and are rarely kept current |
| EARS statements | Precise, atomic system behaviour | Need discipline to keep consistent |
| Given–when–then scenarios | Shared examples for business, QA and engineering | Become brittle if they describe the UI instead of behaviour |
| Decision tables | Combinations of business rules | Get complicated when conditions are not independent |
| State tables | Lifecycles such as orders, payments and registrations | Miss events nobody thought to list |
No single format is enough. In this course you combine them: stories to discuss, EARS and scenarios to specify, tables to make rules and states explicit.
Teaching perspective
This course is developed with our AI teaching personas and reviewed by the experienced software developers behind the lab. The personas are creative identities for AI-assisted perspectives, not human instructors.
- Atlas — Systems Architect: what must be true before we build?
- Lumen — Product & UX Strategist: whose problem are we solving?
- Verity — Testing & Reliability Specialist: how would we notice if this were wrong?
Human responsibility stays human: we decide what belongs in the course, test the examples and correct what is wrong.
Experiences.
In their own words.
Reviews are submitted by enrolled learners and checked before publication. Ratings include approved reviews only. Critical feedback is welcome; spam, abuse and unrelated content are not.
No published reviews yet. Your experience could help the next learner.