Requirements Engineering for AI-Enabled Work: Turn Your Use-Case Canvas into a Delivery Conversation

PathPatron Use-Case Canvas series — 7 of 7

Published Article 7 header

AI-assisted PathPatron illustration, developed under human art direction.

On Monday morning, Maya does not begin with a requirements document. She begins with the supplier-onboarding case the team has already followed for six articles: an incomplete submission, a customer waiting for activation, Procurement reconstructing status, Legal finding a missing clause late and Finance unable to validate bank details.

By Article 6, the team has not selected a shiny technology. It has compared four credible ways to make that work smaller and safer. Requirements are the next question: what has to be true for one of those choices to work in the real organisation?

That includes technology, but it also includes people, process changes, information, authority, training, legal or worker-representation obligations, operational ownership and a way to prove that the change helped. A requirement is not simply a feature request. It is a condition that must be met for the new way of working to be usable, permitted and sustainable.

This final article completes the Requirements area of the same living Use-Case Canvas. Maya is not handing IT the instruction “build an agent.” She is making the conditions of a credible change visible—then taking the technical questions to the people who can answer them.

Maya’s case, carried forward

Use-Case Canvas — Maya’s completed future-state case from Article 6

AI-assisted PathPatron illustration, developed under human art direction.

Before: Article 6’s completed after canvas becomes the starting point for Article 7. Its colour-coded cards still show the current route, the future-state alternatives and the cost-to-solve; the orange-backed Requirements area is where Maya now records what each change needs in order to work.

The Canvas already gives Maya evidence to work from:

  • the people affected: the requester needs timely activation; Procurement needs a complete, defensible record; Legal needs contract evidence; Finance needs valid bank details; the supplier needs a clear request and response;
  • the real route: request, evidence collection, Legal review, Finance check, activation and response—with incomplete submissions and late controls creating loops;
  • the consequences: rework, rechecks, project delay, risk and repeated status chasing; and
  • the four future-state choices: stabilise the intake, automate stable routing, add bounded document assistance, or operate a bounded agentic workflow.

The requirements conversation starts with those facts, not a blank wish list.

A requirement is what makes a future-state step real

Maya puts the four options from Article 6 on the wall. For every proposed step, she asks the same practical questions:

  1. Process and people: What changes in the work? Who performs it, owns it and receives the hand-off?
  2. Information: What must be collected, checked, retained or made visible? Which system is the source of truth?
  3. Capability and tools: Can the existing platform do this? If not, what has to be configured, integrated, bought or built—and who can operate it?
  4. Authority and controls: What may a person, rule or tool do? What must remain with Legal, Finance or another named decision-maker? What must stop and escalate?
  5. Change and adoption: Who needs training, new instructions, time to practise or a consultation before their day-to-day work changes?
  6. Proof and ownership: How will the team test the result, correct it, recover from failure and keep it current?

These are not six separate bureaucratic workstreams. They are the questions hidden inside every proposed future-state step. A technical requirement is often discovered in the third or fourth question. A change-management, operational or legal requirement is just as real.

Monday morning: Maya turns Options A–D into requirements

Option A — Configure a guided intake and visible case ownership

Maya’s smallest move is not AI. The supplier receives an authenticated form or portal link; it preserves an incomplete submission, identifies the named missing evidence, gives the case an owner and lets the requester see what is waiting.

For that to happen, Maya records requirements such as:

  • Process: Procurement must define the intake rule, the incomplete-case loop and who may allow an unusual case to proceed. A supplier must be able to return with the missing item without starting again.
  • Information: the team must agree the mandatory fields—contract evidence, bank details, business owner, supplier identity—and name the current source of truth for each. The form must not collect information that nobody is permitted to use or retain.
  • Capability: the procurement systems owner must confirm whether the existing suite can provide a request type, partial submission, case ID and status view. If it cannot, Maya needs a controlled form/workflow alternative, its identity/access route and a named support owner.
  • Change and adoption: Procurement needs new intake wording, supplier communication, training for people who handle exceptions and a short period in which they can correct the form. If the change materially alters employees’ day-to-day work, Maya asks HR, Legal or the relevant employee/works-council representative what consultation is required in that jurisdiction.
  • Acceptance: on five recent cases, the right gaps are shown, the partial record is preserved and the requester can see the next owner without chasing Maya.

Option A is often called “just configuration.” The requirements show why it still needs process ownership, information decisions, access, training and support.

Option B — Add rules and a controlled validation integration

Option B keeps the guided intake but routes a complete case to Legal, triggers approved bank-data validation after Legal approval and creates a visible Finance exception when validation fails.

The additional requirements are different:

  • Rules and data: Legal, Finance and Procurement must agree which fields are stable enough to automate, which event counts as Legal approval and what a validation pass, failure or retry means.
  • Integration: a system owner must identify the approved validation service, the system identities, data sent and received, failure behaviour, monitoring and recovery route. “Connect it to Finance” is not a requirement; it hides all of those questions.
  • Control: Finance retains the decision on suspicious or failed bank data. A failed check must create a named task, not silently retry or create a vendor.
  • Operating capability: someone in-house, or a retained accountable service, must be able to diagnose a broken route, change a rule safely and tell users what has happened.
  • Acceptance: a normal case routes once; a failed validation becomes visible to Finance; a broken connection neither creates a vendor nor loses the case.

Here Maya may need an architect or integration specialist. Their job is to translate the business requirement into interfaces, security, reliability and effort—not to decide whether Finance’s control can be removed.

Option C — Add bounded document assistance

Option C adds assistance at one defined point: after a supplier uploads permitted files and before Procurement decides whether the evidence is complete. The assistant may identify likely gaps and draft a follow-up. Procurement still verifies the result.

Maya’s requirements now include:

  • Permitted information: which document types may be read; where they are held; what data must never enter the service; retention, privacy, security and contractual conditions; and who approves those boundaries.
  • Service capability: whether the organisation uses an existing approved service, an external vendor or an internal platform; who owns procurement, configuration, prompts/instructions, version changes and vendor due diligence.
  • Human review: Procurement must see the source evidence, correct a wrong draft and decide whether to request the missing item. The assistant must never send an external message by itself.
  • Quality and escalation: the team needs representative test files, a way to measure false gaps and missed gaps, a low-confidence signal, and a reviewer queue for unsupported, conflicting or uncertain documents.
  • Change and adoption: reviewers need time to learn when to trust, correct and override the output. Their feedback must improve the process rather than becoming invisible extra work.

The requirement is not “use a model.” It is “give Procurement a bounded, reviewable aid that works only on permitted files and makes uncertainty visible.” The technical team can then assess models, vendors, interfaces and cost against that boundary.

Option D — Operate a bounded agentic workflow

Option D is not simply Option C with more automation. It may send a pre-approved portal request for a standard missing item, update the case and route a complete standard pack—but it must stop at a non-standard document, a missing source, an unavailable integration, a policy mismatch or an authority boundary.

Before Maya can recommend it, the requirements become more demanding:

  • Authority: each permitted action must be explicit, authorised and reversible. Legal retains contract judgement; Finance retains exceptions; nobody delegates an external commitment or vendor creation by accident.
  • Tooling and suppliers: the organisation must identify the orchestration tool, the APIs/queues it can use, whether it is externally supplied or built in-house, and who owns vendor management, credentials, action permissions and change control.
  • Operations and recovery: a named team must monitor runs, inspect action logs, handle incidents, revoke access, repair a connector and safely change the workflow. If no such capability exists, that is a requirement gap—not an implementation detail to ignore.
  • Assurance: the team needs test cases for normal, incomplete, conflicting and failed cases; an audit trail; stop conditions; a human recovery task; and a proportionate security, legal and risk review.
  • People and consultation: the people whose work changes need a clear role, training and a route to report failures. Significant changes to responsibilities, performance monitoring or work allocation may require HR, legal or employee-representation consultation before launch.

It may be entirely responsible for Maya to conclude: we can operate A now, add parts of B where stable, test C later, and defer D until we have the operating capability and authority model. Requirements engineering is where that conclusion becomes defensible.

Activity: turn each option into requirement cards

Article 7 activity — Requirements Evidence Trace working area

AI-assisted PathPatron illustration, developed under human art direction.

Use the same Article 4-style working board. Each yellow note is one potential requirement, not a feature request: record the requirement, its evidence, an assumption, the owner and the acceptance test. The notes can come from any of Options A–D, but they must remain visibly attached to their option.

Maya takes one future-state step at a time. “Guided intake checks evidence” may produce several notes: Procurement owns the mandatory-field rule; the systems owner confirms whether partial submissions are possible; the supplier-facing team approves new wording; people handling exceptions receive training; and the team tests five incomplete cases.

“The assistant drafts a follow-up” produces different notes: permitted document types; a named AI-service or vendor owner; a human approval route; an evaluation sample; a low-confidence queue; and privacy, legal or employee-representation checks where the new workflow affects people’s work or data.

The card format keeps five things together:

  1. Requirement: what must be true or possible?
  2. Evidence/source: what previous canvas evidence, policy, real case or owner supports it?
  3. Assumption/open question: what is still unknown and who will validate it?
  4. Named owner: who can decide, provide or operate it?
  5. Acceptance test: what will show that the requirement is met?

Do not fill the panel with generic nouns such as “training,” “AI” or “integration.” Write the condition. For example: “Procurement exception handlers complete a short practice session and can route an unusual case without bypassing Legal.” Or: “The approved bank-validation integration creates a Finance task on failure and does not retry indefinitely.”

How Maya runs the requirements work

Maya does not need to do all of this alone, and she should not convene a large workshop simply to discover what is already visible in the Canvas. Her job is to prepare the evidence, bring the right people to the right decisions and make unknowns explicit. The mode depends on the complexity of the option.

First, Maya prepares—AI can help, but does not decide

Before asking people for time, Maya gathers the current case, the completed Canvas, the intake checklist, recent incomplete submissions, relevant policy or approval material, system screenshots and the future-state steps from Article 6. She can use AI to:

  • turn the work map and Article 6 options into a first set of requirement-card prompts;
  • cluster de-identified ticket, inbox or case notes into recurring missing-information and exception patterns;
  • compare a draft form, rule or follow-up with an approved checklist or template;
  • draft short, role-specific validation questions for Procurement, Finance, Legal, IT, HR or a vendor; and
  • flag assumptions, missing owners and counterexamples—for example, “What happens if bank validation is unavailable?”

AI prepares a structured draft; it does not establish an access right, policy, employee-consultation outcome, control boundary, cost, owner or factual requirement. Maya keeps a source beside every claim and marks every unconfirmed card as an assumption.

Mode 1 — Maya prepares a straightforward case herself

For Option A, or a small stable part of Option B, Maya can prepare most cards asynchronously. She reviews a handful of real cases, drafts the cards and sends only the relevant ones to named owners: Procurement validates the mandatory fields and exception loop; the systems owner confirms the platform capability and access; Finance or Legal confirms the control boundary; the affected users challenge whether the new route helps them.

This is not solitary decision-making. It is focused validation. Maya records who confirmed each card, which questions remain open and the date for a decision. A short 30–45 minute check-in may be enough to resolve the remaining conflicts.

Mode 2 — Run a focused online session

Use a 60–90 minute online session when the people need to see the same case together: a hand-off is disputed, an exception path is unclear, a system rule affects several teams or the change has a material people, legal or control implication.

In Mural or Miro, Maya locks the completed Use-Case Canvas in the background. She places the Article 7 cards beside it, colour-codes them by Option A–D and uses a different marker for evidence, assumptions and decisions. The group does not start by debating tools. It walks the real supplier case from incomplete submission to activation, asking at each proposed future-state step: what must be true; who can confirm it; what happens when it fails; and how will the people doing the work learn the new route?

The output is not a polished workshop board. It is a small set of validated cards, unresolved dependencies, owners and a review date.

Mode 3 — Run the seven articles as one on-site working session

For a consequential workflow with competing options, several control owners or a change that materially alters daily work, run the full Canvas as one connected workshop: approximately half a day for a tight, well-prepared case, or a full day for a complex one. Invite the people who perform the work, the accountable business owner, the relevant system/data owner, Finance or Legal where their controls apply, and HR or employee-representation input where the change affects roles, workload, monitoring or working conditions.

Print the Canvas large enough to stand around. Start with the real Monday-morning case, not a future tool. Move through people, pain, current work, cost, future-state options and requirements in sequence. Keep the evidence visible. When a tool is proposed, ask which breakpoint it changes; when a requirement appears, write its evidence, owner, assumption and test on one card. Finish with the smallest credible route to validate—not a promise to implement every option.

Whether Maya works alone, online or on-site, the discipline is the same: prepare with AI, validate with the people who own the work and controls, and record the conditions needed to operate the change after launch.

Maya chooses a route—and the requirements become a delivery brief

Maya may now select Option A plus a carefully bounded part of B. She does not discard the C and D cards; they become visible prerequisites for a later decision. The selected cards go into the Requirements area of the Canvas.

Use-Case Canvas — Maya’s requirements area completed

AI-assisted PathPatron illustration, developed under human art direction.

After: the completed Requirements area shows exemplary content rather than a blank template: guided intake, complete-pack routing, bank validation, bounded document assistance, and training/support. Each card preserves the link between a requirement, its evidence, an open question, an owner and a test.

Only now does Maya schedule the technical conversation. Her delivery brief contains:

  • the chosen process change and the people affected;
  • the information that is needed, permitted and authoritative;
  • the controls and decisions that remain human;
  • the existing capability to configure, plus the integrations, vendors or in-house skills to assess;
  • the change, communication, training and consultation that enable adoption;
  • the operational owner, recovery route and review cadence; and
  • the acceptance tests, open assumptions and decision date.

The technical architect translates relevant cards into technical requirements: data fields, identity, interfaces, security controls, logging, service levels, evaluation and monitoring. HR, Legal, privacy, security, procurement and employee representation may translate other cards into their own conditions. No one group owns every requirement, but every material requirement needs an owner. The AI-Enabled Teams Path carries that delivery conversation into bounded agentic work, where the same named owners and maps become operating controls.

Where Maya finds the evidence

The earlier Canvas entries provide the starting evidence. When they are incomplete, Maya does not invent certainty. She looks at normal, messy and failed cases; process maps; inboxes, tickets and service data; policies, contract terms, approval matrices and retention rules; system fields, logs and supplier documentation; and the people who own the process, data, risk and lived consequences.

Ask named questions of named owners: Who can confirm the mandatory evidence? Who owns the source system? Who is allowed to send, approve or change? Who supports the team when the route fails? Does this change require a worker/employee-representation, HR, privacy or legal check? Who will test whether the people doing the work can actually use it?

When evidence is missing and the deadline is real, leave it visibly unknown, state an assumption with a validator and date, or keep a safe, reversible human boundary around sending, approval, payment, record creation and other irreversible action. AI can organise documents, compare de-identified cases, draft questions and flag assumptions; it cannot invent an access right, a policy, an employee consultation outcome or an accountable owner.

Pro tip: make the seven articles an established practice

The important move is not to run a beautiful workshop once. Make the cards a lightweight operating record for material AI-enabled workflows: store them with the process map and test evidence; name the business, process, data and control owners; review them after a policy, supplier, model, workflow or regulatory change; and treat overrides, failures and user feedback as evidence that a requirement needs revision.

The right format may change—Maya alone with focused validation, an online working session or an on-site team workshop—but the record stays connected to the same real workflow. That continuity stops a later delivery team from rediscovering why a boundary, control or adoption requirement exists.

The Canvas is complete not when every note is full, but when the organisation can explain what will change, why it is allowed, who owns it, how people will adopt it and what will happen when reality does not follow the happy path.

Continue the PathPatron Use-Case Canvas