Session 2 — AI-Driven Requirement Engineering and System Design

AI writes requirements fast. Give it a paragraph of business context and it returns twenty user stories with acceptance criteria in under a minute.

So why do projects still rework their requirements, over and over?

Session 2 answers that, and the answer reframes how you use the tool: the highest-value thing AI does in requirement engineering is not answering — it is asking.

About this write-up

These are my notes from Day 2 of the AI-Driven Software Development Life-Cycle course, taught by Dr. Bùi Thị Mai Anh, School of Information and Communication Technology (SOICT), Hanoi University of Science and Technology, July 2026. The framing and the workshop design are hers; the summary and wording here are mine. The prompts reproduced below are taken from the course workbook — they are the instructor's, not mine, and I have translated them into English.

This follows on from Session 1, which established that shared context — not model capability — is the bottleneck in an AI-assisted lifecycle. A Vietnamese version of this article is also available.

Part 1 — Requirement engineering with AI

Make it ask, not answer

The course states the reframe plainly: AI that asks the right question is more useful than AI that answers immediately.

The reason connects straight back to Session 1. Most missing requirements come from missing context. If you ask for user stories before the context is complete, you get fluent, confident, well-formatted stories built on unstated assumptions — and every one of those assumptions becomes rework later.

There is a hard boundary here that the session keeps returning to:

AI can propose business rules. It cannot confirm them. Business rules and the final decision belong to a person.

The six moves

Requirement work with AI breaks into six activities, each producing an artifact that feeds the next:

1. Elicitation — AI helps mine the existing material for what is actually there
2. Clarification — AI generates the questions that expose what is not there
3. User stories — AI turns clarified requirements into structured stories; a human evaluates
4. Acceptance criteria — so that AI, developer and tester share a definition of done
5. Review — AI re-reads the whole package for gaps, ambiguity and contradiction
6. Prioritisation — AI proposes, a person decides scope

Each artifact is the input to the next. The checkpoints are what stop an unconfirmed assumption in step one from reaching the backlog in step six.

The chain matters more than any individual step. Clarification before specification is the move that removes rework downstream, because an unconfirmed assumption caught at step two is cheap and the same assumption discovered during testing is not.

Part 2 — Architecture and system design with AI

What a requirement package still doesn't tell you

You arrive at design holding a business problem, user stories, acceptance criteria and a prioritised backlog. You need components, APIs, a data design, interactions and technology choices. Nothing in the requirement package determines those. What determines them:

• business goals
• technical constraints
• quality attributes

Architecture thinking is decision-making, not drawing

The session's definition: architecture thinking is a process of systematic decision-making. That framing sets up how AI should be used — not "generate me an architecture", but "help me explore, evaluate, and decide".

So the design flow deliberately asks AI for at least three options rather than one. In the teaching example: monolithic (simple, fast to ship, cheap, fits a small team), modular (clear module boundaries, maintainable, less complex than microservices, fits mid-size), microservices (scales, deploys independently, technology diversity, fits large high-growth systems).

Then the line that governs the whole exercise:

There is no best architecture. Only the one most suited to this problem.

Which is why the next step is explicit trade-off analysis, not a vote.

Where the human line sits in design

The split mirrors Session 1's, one level deeper:

Activity	AI	Human
Component design	Proposes components, responsibilities, boundaries; suggests splits and merges	Decides the actual boundaries and responsibilities
Interaction design	Proposes how components talk	Confirms business fit, picks the communication mechanism, owns non-functional requirements, error handling and transaction boundaries
Security & reliability	Detects risks, proposes mitigations	Accepts or rejects the risk, chooses the treatment
Architecture review	Checks coverage and consistency	Signs off before development starts

Part 3 — Context engineering

This is the genuinely new idea in Session 2, and it is the operational answer to Session 1's context-drift problem.

Once you have a full requirement context plus the current system's context — schema, existing APIs, existing architecture — the naive move is to paste all of it into every prompt. The course names the better move: for each task, retrieve only the relevant subset and assemble a task-specific context.

The full context is the library, not the prompt. Each task gets the subset it needs, which is why the same knowledge base can serve impact analysis, API design and data design without drowning any of them.

The workshop is honest about the simplification here: in a real organisation this would be a RAG-based knowledge system that retrieves automatically. Inside the workshop, teams hand the AI the whole context and ask it to select the relevant parts itself before each task — which is a decent approximation and, usefully, makes the selection visible so a human can correct it.

The workshop: what the exercises actually ask you to do

Session 1's case study was a sketch. Session 2's is a running system.

MedBook

MedBook is a working appointment system: patient management, doctor management, booking, cancellation, rescheduling, doctor schedules, notifications. The workbook hands teams the actual implementation detail — six PostgreSQL tables (patients, users, specializations, doctors, slots, appointments), the REST API surface (POST /appointments, GET /my-appointments, POST /appointments/:id/confirm, POST /appointments/:id/cancel, slot management endpoints), and a partial unique index named one_active_appointment_per_slot that enforces one live appointment per slot.

It also hands over the business rules, and they are specific enough to constrain design: only available slots can be booked (a taken slot returns 409); booking sets appointment to booked and the slot to booked, cancelling returns the slot to available; patients may only cancel their own appointments while staff may cancel anyone's; only staff confirm (booked → confirmed); cancelled is terminal; a slot holding an active appointment cannot be reopened; the system has exactly two roles — patient and staff — and doctors are data, not users.

The change request is the same one from Session 1, now sharpened: Dynamic Appointment Rescheduling & Waiting List Management. Free slots go unused while patients wait, because a staff member has to manually scan the waiting list, compare patients, call each one, handle the reply, and update the schedule.

The constraint that shapes everything: you are not redesigning MedBook. Reuse existing modules and APIs, minimise impact on running features, avoid unnecessary database changes, and keep requirements traceable to design decisions.

Activity 1 — AI-driven requirement discovery (35 min)

AI plays AI-Assisted Business Analyst. It may summarise, analyse, detect gaps, ask clarifying questions, propose user stories and acceptance criteria, and flag ambiguity or contradiction. It is not accountable for any of the resulting decisions.

Step 0 — AI-readiness check. Before prompting for anything, score what you have. Eleven kinds of information — business goal, problem, current process, existing MedBook features, existing APIs/services, stakeholders, business rules, the waiting-list selection rule, technical constraints, success criteria, exception cases — each marked clear / partial / unclear. Then name the three most important missing items and why each matters.

This step is the whole of Session 1 turned into a checklist.

Step 1 — Build business context. AI acts as senior BA and produces a Business Problem Canvas: business problem, pain points, business goal, stakeholders, expected value, in scope, out of scope, constraints, success criteria. The prompt constrains it hard — use only what's in the case study, invent no new business rules, and mark anything unsupported as "needs confirmation".

Human checkpoint: does the context reflect the real problem? What did AI miss? Which assumptions need a stakeholder?

Prompt — Business Context

You are a Senior Business Analyst.

Task Goal: understand the business problem behind the
Dynamic Appointment Rescheduling & Waiting List Management feature.

Before proposing any requirements:
- Build the Business Context from the current state of the MedBook system.
- Identify the information directly related to the problem.
- Summarise the problem as a Business Problem Canvas.

Rules:
- Use only information present in the case study.
- Do not invent new Business Rules.
- Anything without sufficient grounding must be marked "Needs confirmation".

Step 2 — Requirement clarification. AI analyses the context for information gaps and proposes questions — explicitly forbidden from proposing solutions or generating stories. For each question it must state what is missing, why it matters, and which stakeholder should answer. The output is a Requirement Clarification Log with a status per row (Answered / Open).

Suggested areas to probe: the patient selection rule, actor permissions, patient response handling, response deadline, ties in priority, multiple available slots at once, schedule conflicts, notifications, exceptions, privacy and security, success criteria.

Prompt — Requirement Clarification

You are a Senior Business Analyst.

Task Goal: clarify the missing requirements of the
Dynamic Appointment Rescheduling & Waiting List Management feature.

Before writing any User Stories:
- Analyse the Business Context.
- Identify the remaining Information Gaps.
- Propose the questions that need clarifying with stakeholders.

Do not propose solutions.
Do not generate User Stories.
Do not assume unconfirmed Business Rules.

For each question, state:
- What information is missing.
- Why this information matters.
- Which stakeholder should confirm it.

Step 3 — User stories. Grouped by actor, one goal each, independently testable, no unconfirmed business rules, and every story that rests on an assumption is marked as such.

Prompt — User Stories

You are a Senior Business Analyst.

Using the confirmed Business Problem Canvas and Requirement Clarification Log,
write the User Stories for Dynamic Appointment Rescheduling and Waiting List
Management.

Rules:
- Group by actor: Patient, Doctor, Medical Staff, System Administrator.
- Each User Story describes exactly one goal.
- Do not decide Business Rules that have not been confirmed.
- Explicitly mark any User Story that rests on an Assumption or Open Question.
- Prioritise the User Stories needed for a Minimum Viable Product.

Step 4 — Acceptance criteria. Pick the three most important stories and write Given–When–Then criteria covering happy path, at least one alternative flow, at least one exception, plus the specific cases: patient declines, patient doesn't respond in time, slot no longer available. Anything unclear is tagged Open Question rather than guessed.

Prompt — Acceptance Criteria

You are a Senior Business Analyst.

Based on the User Story and the confirmed Business Rules, write Acceptance
Criteria in Given - When - Then format.

Requirements:
- Cover the Happy Path.
- At least one Alternative Flow.
- At least one Exception.
- Include the case where the patient declines.
- Include the case where the patient does not respond within the time limit.
- Include the case where the slot is no longer available.
- Use only confirmed Business Rules.
- Anything unclear must be marked "Open Question" - do not infer.

Step 5 — Requirement review and gap analysis. AI re-reads the entire package as BA and architect, hunting for missing requirements, ambiguity, conflicts, duplicate stories, unconfirmed assumptions, unhandled edge cases, requirements that don't fit the existing system or APIs, missing non-functional requirements, and privacy/security/fairness risks. It may not fix anything — only report the issue, its impact, and what needs confirming.

Prompt — Requirement Review

You are a Senior Business Analyst and Software Architect.

Review the entire Requirement Package and identify the issues that could affect
system design and development.

Check for:
- Missing Requirements.
- Ambiguous Requirements.
- Conflicting Requirements.
- Duplicate or overlapping User Stories.
- Unconfirmed Assumptions and Open Questions.
- Unhandled Edge Cases.
- Requirements that do not fit the existing system or APIs/Services.
- Missing non-functional requirements (Performance, Security, Privacy,
  Reliability, ...).
- Privacy, Security and Fairness risks.
- Items that require a stakeholder decision.

Do not modify Business Rules or Requirements yourself. Only state the issue,
analyse its impact, and propose the questions or items that need confirming.

Step 6 — Prioritisation. MoSCoW, with AI proposing and the team deciding. The discussion questions are the point: where did AI and the humans disagree, and why? Which priority calls depend on business value that AI can't see?

Prompt — MoSCoW Prioritisation

You are a Senior Business Analyst.

Based on the Requirement Package, propose a priority level for each User Story
using MoSCoW.

Consider:
- Business Value.
- How essential it is to the main business flow.
- Dependencies between User Stories.
- The risk of not implementing it.
- Whether existing APIs/Services can be reused.
- Estimated implementation complexity.

Do not make the final decision.
Explain your reasoning briefly for each level, and state clearly which cases
need human review.

The outputs are kept as markdown so both humans and AI can consume them: BusinessProblem.md, BusinessRules.md, UserStories.md, AcceptanceCriteria.md, RequirementReview.md, PrioritizedBacklog.md.

Activity 2 — AI-driven architecture and system design (40–45 min)

Input: the prioritised requirement package. Output: an Architecture Blueprint.

Step 1 — Impact analysis. Build the task-specific context, then determine what can be reused, what must be extended, what is genuinely new, which APIs and data are affected, which flows and integration points are touched, and what the risks are. Output is an Impact Analysis Matrix scoring each user story by change type (Reuse / Extend / New / Replace) and impact level.

Prompt — Impact Analysis

You are a Software Architect analysing the impact of a requirement change on
the MedBook system.

First, from the Requirement Context and Current System Context, select and
assemble the relevant information into a Task-specific Context for Impact
Analysis:
- Related prioritised User Stories.
- Related Acceptance Criteria.
- Business Rules that affect design.
- Related existing Modules and Services.
- Related existing APIs.
- Related database entities or data.
- Technical, Security and Privacy Constraints.
- Open Questions or Assumptions to keep in mind.

Then, using that Task-specific Context, perform the Impact Analysis and identify:
- Components that can be reused.
- Components that must be extended or changed.
- New components that must be added.
- APIs to add or adjust.
- Data to add or change.
- Business flows and integration points affected.
- Dependencies between components.
- Risks introduced by the change.

Do not propose redesigning the whole system.
Prefer reusing existing modules, services, APIs and data structures where
appropriate.
Do not create new Business Rules or Requirements. Mark anything unclear as
"Needs confirmation".

Step 2 — Architecture exploration. At least three evolution options — not a redesign. Each must maximise reuse, describe the integration approach with the current architecture, and state its strategy for concurrency, consistency and failure recovery, plus pros, limits, trade-offs, risks, and the conditions under which it would be the right pick.

Prompt — Architecture Exploration

You are the Software Architect responsible for extending MedBook to support
Dynamic Appointment Rescheduling and Waiting List Management.

MedBook already has a running architecture and live features. Your goal is not
to redesign the system, but to propose evolution options with minimal change.

Using the Task-specific Context, Impact Analysis and Current System Context,
propose at least 3 different architecture options.

For each option:
- Maximise reuse of existing components, services, APIs and database.
- Add or change only what is genuinely necessary.
- Describe the high-level architecture and the components affected.
- Explain how it integrates with the current architecture.
- Describe the strategy for Concurrency, Consistency and Failure Recovery.
- Analyse advantages, limitations, trade-offs and risks.
- State the conditions under which this option is the right choice.

Prioritise:
- Reusability of existing components.
- Minimal impact on running features.
- Avoiding database and public API changes unless truly necessary.
- Backward compatibility.
- Future extensibility and maintainability.

Do not pick the final option on the human's behalf.

Step 3 — Evaluation and decision. Score every option 1–5 across ten criteria: fit with current architecture, implementation complexity, maintainability, scalability, reliability, security and privacy, operating cost, rollback capability, fit with the team's current skills, and time to deliver.

Then the move I liked most in the whole workbook — a second, adversarial prompt:

Act as an independent software architecture reviewer. Critique the evaluation above: name the assumptions that don't hold, the risks that were missed, the cases where a different option would fit better, and the questions the architect should settle before deciding.

Making the model argue against its own recommendation is a cheap, direct counter to the fact that AI will happily rationalise whatever it proposed first.

Prompt — Architecture Evaluation

You are the Software Architect of the MedBook system.

Based on the Impact Analysis and the 3 proposed architecture options, evaluate
each option against:
- Fit with the current architecture
- Implementation complexity
- Maintainability
- Scalability
- Reliability
- Security & Privacy
- Operating cost
- Rollback capability
- Fit with the team's current capability
- Time to deliver

For each criterion:
- Score from 1 (low) to 5 (high).
- Explain the score briefly.
- Note any risks or assumptions to be aware of.

Finally:
- Rank the options by suitability.
- Analyse the trade-offs of each option.
- Identify the decisions the Software Architect should make rather than the AI.
- State what information is still missing to reach a final decision.

Prompt — Adversarial review

Act as an independent Software Architecture Reviewer.

Critique the evaluation above by:
- Naming the assumptions that do not hold.
- Finding the risks that were missed.
- Describing the cases where a different option would fit better.
- Proposing the questions the Software Architect should consider before making
  the final decision.

Step 4 — Component and responsibility design. For each component: role (Reuse / Extend / New), responsibilities, which business rules it owns, what it talks to, inputs and outputs. Then a check for components carrying too much, and a rule worth stealing — each business rule belongs to exactly one component. An adversarial reviewer pass follows, grading against SRP, cohesion, coupling, reusability, extensibility and maintainability.

Prompt — Component Design

You are the Software Architect of the MedBook system.

Based on the Architecture Decision, design the components that realise Dynamic
Appointment Rescheduling and Waiting List Management.

For each component, identify:
- Role (Reuse / Extend / New)
- Main responsibilities
- The Business Rules it is responsible for
- Components or Services it interacts with
- Input
- Output

Also:
- Check whether any component is carrying too many responsibilities.
- Propose splitting or merging components if needed.
- Ensure each Business Rule belongs to exactly one component.
- Briefly explain the reasoning behind the design decisions.

If you need to clarify an existing component or interface, refer to the Current
System Context.

Prompt — Adversarial review

Act as a Software Architecture Reviewer.

Evaluate the component design against:
- Single Responsibility Principle (SRP)
- Cohesion
- Coupling
- Reusability
- Extensibility
- Maintainability

If you find a problem:
- Name the component that is not right.
- Explain the cause.
- Propose an improvement.

Step 5 — API and interaction design. Built around one concrete flow: a slot becomes available, the system picks a suitable patient, sends an offer, and handles the reply. Four tasks — assemble the business flow context (goal, trigger, actors, stories, criteria, rules, pre/postconditions, alternative and exception flows, open questions); design the interaction flow step by step; define API and event contracts marked Existing / Modified / New with reuse preferred; then analyse runtime behaviour — timeout, retry policy, error handling, concurrency control, idempotency, rollback and compensation.

Prompt — API & Interaction Design

You are the Solution Architect of the MedBook system.

Based on the Requirement Context and Component Design, design the API and
interaction flow for: when a slot becomes available, the system selects a
suitable patient, sends an offer, and handles the patient's reply.

Task 1 - Build Business Flow Context
From the Requirement Context, retrieve the information related to this flow.
Identify: Business Goal, Trigger, Actors, related User Stories, Acceptance
Criteria, Business Rules, Preconditions, Postconditions, Alternative Flows,
Exception Conditions, Open Questions.
If information is missing, write "Needs confirmation" - do not assume.

Task 2 - Design Interaction Flow
For each step, identify: the Actor or Component acting, the action, the API or
Event used, Input, Output, and the state created or changed.
Clearly separate Main Flow, Alternative Flow and Exception Flow.

Task 3 - Design API and Event Contracts
For each API or Event: Existing / Modified / New, Provider, Consumer, Purpose,
Request or Event Payload, Response or Output, Error Response.
Prefer reusing existing APIs before proposing new ones.

Task 4 - Analyse Runtime Behaviours
For each important interaction, analyse: Timeout, Retry Policy, Error Handling,
Concurrency Control, Idempotency, Rollback or Compensation.
If you find a risk or bottleneck, propose an improvement.

Step 6 — Data and state design. Reuse or extend before adding. The interesting sub-task is deciding what an offer even is: should AppointmentOffer be its own entity, an extension of an existing one, or just a state on an existing entity? Then design the state machine — current state, triggering event, condition, action, next state, invalid transitions, terminal states — covering accepted, rejected, expired, cancelled, timeout, offer superseded, slot already confirmed by someone else, and duplicate event delivery.

Prompt — Data & State Design

You are the Data Architect of the MedBook system.

Based on the Requirement Context, Current Data Model, Component Design and
Interaction Flow, design the data and state extension needed for Dynamic
Appointment Rescheduling and Waiting List Management.

Task 1 - Build Data Design Context
Retrieve: Business Rules that affect data, Acceptance Criteria related to state
and storage, existing entities and attributes that can be reused, existing
relationships, data constraints, audit/privacy/retention requirements, and
anything missing that needs confirming.
Do not assume when information has not been provided.

Task 2 - Identify Data Model Changes
Identify entities reused, entities to extend, new entities, new attributes, new
or changed relationships, constraints and uniqueness rules, and the data needed
for concurrency, idempotency and audit.
For each change describe: Change Type (Reuse / Extend / New), purpose, key
attributes, state or lifecycle, relationships, the owning component, and data
constraints.
Do not create a new entity if an existing one can reasonably be extended or
reused.

Task 3 - Design State Transition
First decide what should own the lifecycle of an appointment offer. Should
AppointmentOffer be an independent entity, an extension of an existing entity,
or just a state on an existing entity?
Then design the State Transition: Current State, Triggering Event, Transition
Condition, Action or data updated, Next State, Invalid Transition, Terminal
State.
Cover: Accepted, Rejected, Expired, Cancelled, Timeout, offer superseded, slot
already confirmed by another patient, and duplicated event delivery.

Task 4 - Review Data Integrity and Lifecycle
Check for duplication with existing data, missing entities/attributes/
relationships, unreachable or inescapable states, uncontrolled invalid
transitions, concurrent-update or data-loss risk, idempotency and optimistic
locking support, sufficient timestamps and audit information, unnecessary
sensitive data, and a suitable retention or deletion policy.
If you find a problem, propose an improvement and state clearly what a human
must confirm.

Step 7 — Security and reliability review. Across security and privacy, concurrency and data consistency, failure handling and recovery, and business risk. To stop the model answering in generalities, three scenarios are mandatory:

1. Two patients accept the same slot almost simultaneously
2. The notification fails to send but the offer timer keeps running
3. A patient accepts an offer after it has expired

Each risk gets an impact rating, a proposed mitigation, and a flag for whether a human must decide.

Prompt — Security & Reliability Review

Based on the Requirement Context and Design Context, review the design from
four angles:
- Security & Privacy
- Concurrency & Data Consistency
- Failure Handling & Recovery
- Business Risks

For each risk, identify:
- A description of the risk.
- The component or flow affected.
- Impact level (High / Medium / Low).
- Mitigation.
- Whether a human decision is required.

Do not change Business Rules. If information is missing, state it as an Open
Question.

Three scenarios you must address:
- Two patients accept the same slot almost simultaneously.
- The notification fails to send but the offer timer keeps running.
- A patient accepts an offer after it has already expired.

Step 8 — Requirement traceability review. Every requirement must map to at least one component, every acceptance criterion must be traceable to the design, no business rule may be dropped, and no component may exist without a requirement behind it. That last check — unused components — is the one people skip, and it's how speculative design gets caught.

The closing question in the deliverable is the sharpest one in the workbook: if you handed this document set to an AI developer, would it have enough context to build the feature? Summarise what it has, and highlight what's still missing.

Prompt — Traceability Review

You are a Software Architecture Reviewer.

Based on the Requirement Context and Design Context, evaluate how well the
design meets the original requirements.

For each Requirement or User Story, identify:
- The component responsible.
- Whether the requirement has been met.
- Whether the Acceptance Criteria are supported.
- Whether any Business Rules have been dropped.
- Whether any component serves no requirement at all.

Finally, list:
- Missing Requirements
- Missing Acceptance Criteria
- Missing Business Rules
- Unused Components
- Open Questions
- Improvement Suggestions

Part 4 — Spec as an interface

Which leads to how the session ends. Chain those artifacts together — requirements through to architecture — and you get what the course calls an AI-Ready Specification: the foundation from which AI can generate code, tests and development documentation.

Spec is no longer documentation. Spec becomes the working interface between human and AI.

That is the whole arc of Session 1 and 2 in one sentence. Session 1 diagnosed context loss between phases. Session 2's answer is not "prompt better" — it's to make the context a first-class, versioned, reviewable artifact chain that every phase and every assistant reads from.

What I took away

Clarification is the highest-leverage prompt you will write. Asking AI to generate questions before generating stories costs one extra step and removes the class of rework that comes from confident output built on unstated assumptions.

Ask for three options, then make it attack its own answer. Requesting alternatives stops you anchoring on the first design; the adversarial-reviewer prompt stops the model defending it.

Context engineering is selection, not accumulation. Having a big knowledge base is not the same as feeding it wholesale into every prompt. Choosing the relevant slice per task is the skill.

"Needs confirmation" is a feature. Nearly every prompt in the workbook instructs the model to mark unsupported content rather than fill the gap. That single instruction converts silent fabrication into a visible checklist item.