Ask what each workflow must do

Learning objective

Elicit functional requirements, data dependencies, and failure-handling expectations through workflow walkthroughs and real examples.

Core idea

You already know how an interview and explicit examples clarify an implementation request. At Professional level, the additional responsibility is deciding whose expectations become business requirements, which source supports each outcome, and what operations must do when the normal path fails. A stakeholder-approved workflow requirement carries authority that a plausible generated specification does not.

NIST AI RMF MAP 1.6 calls for eliciting requirements from relevant AI actors, and MAP 3.5 addresses documented human oversight. Use a workflow requirements register to connect those responsibilities: trigger, preconditions, required behavior, data dependencies, failure outcome, and accepting owner. The register is a proposed team artifact, not a Claude API field.

How it works

Walk through a completed business case

Ask the operator to reconstruct a real case from its initial request to its accepted outcome. Ask what they knew at each step, what they looked up, why they chose that action, and who could reverse it. Avoid starting with “what should the assistant say?” That question can hide a business action behind a conversational interface.

Anthropic’s ticket-routing guidance asks how existing automation fails and how people handle ambiguous cases. Use those questions to expose workflow branches. A correct intent label may still require a separate eligibility check before a case reaches the right team. A summary is not the completed disposition if a person must accept responsibility for the case.

Anthropic’s customer-support guide recommends breaking the interaction into every distinct task Claude must perform so you can prompt and evaluate each task separately. Use that breakdown to check that the requirements cover the whole interaction, including lookups, decisions, actions, and handoffs.

Write each function as an observable business behavior. “Understand account disputes” leaves success undefined. “Associate a verified customer’s dispute with the relevant transaction and send it to the dispute team for review” identifies required work, its dependencies, and the boundary before a decision. Keep the implementation pattern open while those requirements are settled.

Attach required data to each branch

For every step, ask which record is authoritative, which fields are needed, how the record is matched to the request, and what makes it usable. Separate customer assertions from verified account data. If a workflow depends on transaction status, a customer email mentioning that status does not establish it.

The dependency entry should identify the source owner and the condition under which absence, conflict, or staleness changes the outcome. Discovery does not need to select a retrieval architecture to establish that only the approved policy version may support a customer-facing eligibility answer. Access feasibility and measurable freshness constraints are assessed in 6.1.3.

Keep real examples under the data owner’s handling rules. Ask the business owner to annotate expected outcomes before using model-generated labels. A sample that contains several intents requires an explicit decision about whether the workflow handles them together or creates separate work items. Do not let a single-label prototype silently impose a single-intent requirement.

Elicit the unsuccessful paths explicitly

Present a small set of contrasting cases to the responsible owners. Include a normal case, a missing prerequisite, conflicting information, and a dependency failure. Ask what the requester receives, whether any action is permitted, what work remains, and who must take it next.

A requirements register for a dispute workflow might contain these project-defined cases:

These are scenario requirements, not universal banking rules. In particular, “try again” does not settle an uncertain submission: the owner must specify how staff determine whether work already exists. Capture the required business outcome here; the design later chooses mechanisms to enforce it.

Make the handoff an accepted function

“Escalate to a human” is incomplete until discovery identifies the receiving queue or team, the information transferred, and the point at which that team accepts the work. Ask what happens if nobody is available or the queue rejects the case. The receiving team’s operational capacity is a constraint for 6.1.3, but the required transfer behavior belongs here.

Return annotated cases to the people who supplied them. Resolve contradictory outcomes with the authorized owner rather than majority vote among meeting attendees. Preserve unresolved branches as open decisions. A generated requirement becomes approved only after the relevant owner accepts its meaning.

Key distinctions and trade-offs

An example versus a rule: A real case demonstrates an expected outcome under stated conditions. Ask the owner what rule generalizes it and which adjacent cases remain undecided. One approved case does not authorize every superficially similar action.

A failure outcome versus a recovery implementation: “Keep the dispute pending until receipt is reconciled” defines required behavior. Choosing the transaction or reconciliation mechanism belongs to design. Discovery must establish the obligation without pretending the mechanism is already available.

Detailed exception walkthroughs take time from common-case analysis, but consequential rare cases can determine whether automation is acceptable at all. Choose examples that change the permitted action or the owner, rather than many routine cases with identical outcomes.

Architecture / decision scenario

A financial-services firm wants a dispute assistant operating within six weeks. The product lead proposes using thirty successful historical cases to specify the whole workflow and letting Claude fill in missing rules. During walkthroughs, operators report that twelve percent of requests lack a transaction identifier and a separate two percent have an uncertain case-submission outcome.

Choose additional real examples from those branches and ask dispute operations, the policy owner, and the case-system owner to annotate them. The firm requires clarification for unmatched transactions, policy review for conflicting rules, and reconciliation before any uncertain submission is repeated. Each requirement identifies its source data and accepting owner.

The case-system owner must demonstrate how staff recognize an existing submission before automated submission enters scope. The product lead accepts an initial review-request workflow if that dependency remains unresolved. The successful-case-only alternative meets the deadline more easily, but leaves fourteen percent of the observed workload without an approved outcome. The architect’s job is to expose that scope decision, not supply a business rule on the owners’ behalf.

Common exam traps

• Treating fluent conversation as a complete business outcome.
• Asking only about successful cases and inventing the remaining branches.
• Listing data sources without stating what decisions depend on them.
• Accepting “human escalation” without a receiving owner or handoff outcome.
• Treating generated requirements or labels as stakeholder approval.

What to remember

Walk through real business cases and record the function, required data, and accepted outcome for each consequential branch. Have authorized owners resolve conflicting examples and specify failure handoffs before implementation choices hide those decisions.

Knowledge check

References

• NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• Anthropic, Ticket routing
• Anthropic, Customer support agent