Skill Hub — Business Analysis

Use Case Analysis Working Skill

Identify actors, goals, and system interactions to produce structured use cases that reveal missing requirements and boundary conditions.

What this skill is for

This skill analyzes a business situation through the lens of use cases: who initiates the action, what they want to achieve, and how the system responds. It produces structured use cases that expose hidden actors, missing system steps, and boundary conditions that vague requirements miss. The output is a Use Case Brief that can be validated with stakeholders and translated into requirements, test cases, or integration contracts.

When to use this skill

A new feature or system is being designed and no one has mapped the end-to-end interaction sequence.
An integration failure reveals that one system assumed a step the other system never performed.
A process redesign needs to know which human decisions can be automated and which require approval.
A requirements document lists system functions but never states who triggers them or what happens when they fail.
A support team needs to document how a process actually works, not how it is supposed to work.
An AI automation opportunity is being scoped and the boundary between human and machine decisions is unclear.

Real work situations

SAP S/4 sales order creation

A project to streamline order entry needs a use case for "Create sales order." The primary actor is the sales representative. Secondary actors are the credit management system (checks exposure), the ATP engine (checks availability), and the pricing engine (calculates conditions). The use case reveals that the current process has no extension for "customer master incomplete," causing silent blocks. The main success scenario must include: enter order, validate customer, check credit, check ATP, calculate price, confirm order. Extensions must include: credit block, ATP failure, pricing mismatch, and incomplete customer data. Without this analysis, the project automates only the happy path and misses the failure modes that generate 80 percent of support tickets.

E-commerce to SAP integration

A retailer wants to connect a Shopify frontend to SAP S/4. The use case "Place customer order" reveals three primary actors: the customer (initiates), the e-commerce platform (validates cart), and SAP (creates order). Secondary actors: the inventory system (stock reservation), the payment gateway (authorization), and the tax engine (VAT calculation). The analysis reveals a missing extension: "Reservation times out before SAP order is created." Without this, the integration silently drops orders when the warehouse is slow to confirm.

Returns processing

A customer service team wants to automate returns. The use case "Process return order" shows the primary actor is the customer service rep, but a secondary actor is the warehouse clerk who must confirm goods receipt before finance can issue a credit memo. The analysis reveals that the current system does not notify finance when the warehouse step completes, causing credit memos to be delayed by days. The use case extension "Goods receipt confirmed late" becomes a requirement for a status-triggered notification to the accounts receivable clerk.

Inputs required

Business event description or stakeholder request that triggers the use case.
Process documentation or Process Analysis Notes for the affected workflow.
System documentation showing which systems, transactions, and APIs are involved.
Incident tickets or error logs showing where the current process breaks.
Stakeholder interviews with people who perform, approve, or suffer from the process.
Integration contracts or interface specifications for cross-system use cases.
User role assignments to verify who has access to which transactions.

Questions to ask

What is the actor's goal, and how do they know when it is achieved?
What event triggers this use case, and what prevents it from starting?
Which other systems or actors must respond before the goal is met?
What happens when the primary actor is unavailable or the system is down?
What are the most common failure modes, and who handles them today?
Where does the process hand off from one actor to another, and what information must transfer?
Which steps are manual today and could be automated? Which must stay manual?
What would a developer or tester need to know that is not stated in the current documentation?

Working method

Identify the business event. What triggers the use case? A user action, a system timer, an incoming message, or a status change?
Name the primary actor. The person or system that initiates the use case to achieve a goal. If there are multiple initiators, split or generalize carefully.
Identify secondary actors. Systems, people, or external services that respond to or constrain the primary actor's progress.
Write the goal statement. Format: "The [primary actor] achieves [goal] by [main action]." Keep it one sentence and outcome-focused.
Define preconditions. What must be true before the use case starts: data exists, user is authenticated, system is available, credit limit is valid.
Map the main success scenario. Numbered steps from trigger to goal completion. Each step must be a single action by a single actor. Include system responses.
Identify extension points. At each step, ask: what could go wrong, what could vary, and what decision branches exist? Document each as an extension with a trigger condition and handling steps.
Derive requirements. From each step and extension, extract requirements: functional requirements for the system, data requirements for inputs, and non-functional requirements for performance or reliability.
Validate with actors. Walk through the main success scenario and each extension with the people who perform the work. Confirm that the sequence matches reality.
Document in a Use Case Brief. One brief per use case. Include actor list, goal, preconditions, main success scenario, extensions, and derived requirements.

Decision rules

If a use case has no secondary actor, verify whether it truly operates in isolation or whether secondary actors have been overlooked.
If an extension point has no handling steps, it is a missing requirement — flag it.
If two use cases share the same trigger and the same primary actor, merge them or differentiate by goal.
If a step involves two actors simultaneously, split it into two sequential steps.
If an extension occurs in more than 20 percent of executions, consider it a variant rather than an exception and give it its own use case or sub-flow.
If a use case requires data from a system that is not listed as a secondary actor, add the system.
If the main success scenario has more than 12 steps, the use case is too granular or too broad — split or simplify.

Deliverables

Use Case Brief — One per use case. Contains actor list, goal statement, preconditions, main success scenario, extensions, and derived requirements. See template below.
Actor Catalog — List of all primary and secondary actors with their roles, goals, and system access.
Extension Register — Consolidated table of all extension points with trigger conditions, handling steps, and priority.
Derived Requirements List — Requirements extracted from the use case, mapped to steps and extensions.

Templates

Use Case Brief (compact)

---
artifact: Use Case Brief
id: UC-001
status: draft | reviewed | approved
---

## Use case name


## Primary actor


## Secondary actors


## Goal statement


## Preconditions

- Customer master exists in the relevant sales area (XD03).
- Material master exists and is active in the plant.
- User has VA01 authorization for the sales organization.

## Main success scenario
1. Sales representative enters order header: customer, sales organization, order type.
2. System validates customer master and sales area data.
3. Sales representative enters line items: material, quantity, requested delivery date.
4. System performs ATP check and confirms availability.
5. System performs credit check and confirms exposure is within limit.
6. System calculates pricing conditions.
7. Sales representative saves the order.
8. System assigns order number and confirms status.

## Extensions
### Extension 1: Credit block
- Trigger: Step 5 — credit exposure exceeds limit.
- Handling: System blocks order with status "Credit block." Routes to credit controller worklist (UKM_CASE). Sales representative cannot proceed without override.

### Extension 2: ATP failure
- Trigger: Step 4 — insufficient stock.
- Handling: System displays shortage. Sales representative chooses: confirm partial quantity, change requested date, or cancel line item.

### Extension 3: Incomplete customer data
- Trigger: Step 2 — missing sales area or shipping point.
- Handling: System displays incompletion log. Sales representative updates customer master or contacts MDG steward.

## Derived requirements
- REQ-001: The system must perform real-time credit check at order save.
- REQ-002: The system must display ATP result with available quantity and confirmed date.
- REQ-003: The system must validate customer master completeness before line item entry.

## Related use cases

Quality checklist

Every use case has a single primary actor and a clear goal statement.
Preconditions are stated and verifiable before the use case starts.
The main success scenario has 4 to 12 steps, each with a single actor and action.
Every step that can fail has at least one documented extension.
Extensions include a trigger condition and specific handling steps.
Derived requirements trace back to specific steps or extensions.
Secondary actors are named and linked to the systems or roles they represent.
The use case has been validated with at least one person who performs the primary actor's role.

Common mistakes

Writing use cases as system design documents. Consequence: the use case prescribes screens, buttons, and database tables instead of describing actor goals and system responsibilities. The result is brittle and hard to validate with business users.
Skipping secondary actors. Consequence: integration failures are discovered late because the use case never acknowledged that another system was involved.
Documenting only the happy path. Consequence: 80 percent of support effort goes to unhandled exceptions that were never analyzed.
Mixing two primary actors in one use case. Consequence: the use case tries to describe both the sales rep and the customer service rep, creating confusion about who initiates and who responds.
Leaving extensions as vague "system handles error." Consequence: the requirement is incomplete. Developers guess at error handling, and testers have no pass/fail standard.

Weak output vs Strong output

Weak output — Vague description with no structure

A weak AI output describes a process in paragraphs without separating actors, steps, or failure modes:

Use case: Process customer order.

Description: The system receives a customer order, validates it, checks stock, and creates a delivery. If something goes wrong, the system handles the error and notifies the user. The sales team uses this feature daily. It is important for revenue.

Actors: User, System.

Requirements: The system must process orders efficiently and handle errors gracefully.

Why this is weak: No primary actor is named. No step-by-step sequence. No preconditions. No specific extensions. "System handles error" is not a handling step. No derived requirements. No next action. A developer cannot build from this, and a tester cannot verify it.

Strong output — Structured Use Case Brief

A strong AI output produces a copy-paste-ready artifact with specific actors, steps, extensions, and derived requirements:

---
artifact: Use Case Brief
id: UC-O2C-015
status: reviewed
---

## Use case name
Create sales order with credit and ATP validation

## Primary actor
Sales representative (SAP user with VA01 authorization for sales org 1000)

## Secondary actors
- SAP Credit Management system (UKM_BP exposure check)
- SAP ATP engine (scope of check for plant 1100)
- SAP Pricing engine (condition type PR00 and tax determination)

## Goal statement
The sales representative creates a confirmed sales order that passes credit check, availability check, and pricing validation for standard order type ZOR.

## Preconditions
- Customer master exists in sales area 1000 / 10 / 00 (XD03).
- Material master exists and is active in plant 1100.
- User has VA01 authorization for sales org 1000.
- Pricing procedure is assigned to the order type and customer.

## Main success scenario
1. Sales representative enters order header: customer 1000001234, sales org 1000, order type ZOR.
2. System validates customer master and confirms sales area data is complete.
3. Sales representative enters line item: material MAT-001, quantity 100, requested delivery date 2026-07-15.
4. System performs ATP check for plant 1100 and confirms full quantity available.
5. System performs credit check via UKM_BP and confirms exposure within 50,000 EUR limit.
6. System calculates pricing: PR00 = 120.00 EUR, tax = 22.80 EUR.
7. Sales representative saves the order.
8. System assigns order number 4500012345 and confirms status "Complete."

## Extensions
### Extension 1: Credit block
- Trigger: Step 5 — credit exposure exceeds 50,000 EUR.
- Handling: System sets order status "Credit block." Routes case to UKM_CASE worklist for credit controller Maria Chen. Sales representative cannot proceed without override. Notification sent within 5 minutes.

### Extension 2: ATP partial availability
- Trigger: Step 4 — only 60 units available in plant 1100.
- Handling: System displays confirmed quantity 60 with confirmed date 2026-07-15 and shortage 40 with next availability 2026-07-22. Sales representative chooses: confirm partial, change date, or cancel line.

### Extension 3: Incomplete customer data
- Trigger: Step 2 — missing shipping point determination (VBAK-VSTEL).
- Handling: System displays incompletion log (V.26). Order saves but blocks for delivery. Sales representative contacts MDG steward to update customer master shipping conditions.

## Derived requirements
- REQ-001: The system must perform real-time credit check at order save using UKM_BP exposure data.
- REQ-002: The system must display ATP result with available quantity, confirmed date, and next availability date.
- REQ-003: The system must validate customer master completeness (shipping point, payment terms, tax classification) before allowing delivery creation.
- REQ-004: The system must route credit block cases to UKM_CASE worklist and notify the assigned credit controller within 5 minutes.

## Related use cases
- UC-O2C-016: Create delivery for confirmed sales order
- UC-O2C-017: Process billing for delivered order

Why this is strong: It names the primary actor with authorization context, lists secondary actors with specific systems, states verifiable preconditions, breaks the process into discrete steps, documents specific extensions with triggers and handling, and derives requirements that trace back to steps. A developer can build against it, a tester can verify each step, and a stakeholder can validate the sequence against reality.

Agent instructions

AI Prompt Pattern

"You are a business analyst documenting use cases for enterprise systems. You receive a business event description and system context. Produce a Use Case Brief with: Use Case Name, Primary Actor (with role/system access), Secondary Actors (with systems involved), Goal Statement (one sentence), Preconditions (verifiable), Main Success Scenario (numbered steps, one actor per step), Extensions (trigger + handling for each failure point), and Derived Requirements (tracing to steps). If a system or actor is missing from the context, flag it. Do not describe screens or database tables. Focus on actor goals and system responsibilities."

When using this skill, an AI agent must:

Start with the business event, not the system. What triggers the use case and what goal does the primary actor want to achieve?
Name primary and secondary actors explicitly. Include their system access or role if relevant. Do not use generic "user" or "system."
Write the main success scenario as numbered steps. One action per step, one actor per step. Include the system response if it affects the next step.
Identify at least three extensions. Normal case, boundary case, and error case. If an extension has no handling steps, flag it as a missing requirement.
Derive requirements from steps and extensions. Each requirement must trace back to a specific step or extension number.
Validate the use case with someone who performs the primary actor's role. Do not publish without business validation.
Do not describe user interfaces or database schemas. Use cases describe behavior, not implementation.
Link to Atlas diagnostics when use cases relate to SAP processes. For example, order creation use cases should reference SAP Sales Order Block Diagnosis.

Related skills

Related Atlas pages

Order to Cash — Process context for O2C use cases.
SAP Sales Order Block Diagnosis — Extension handling for order blocks.

Verification status and limitations

This skill is a public working interpretation of use case analysis practices. It is not official UML or BABOK documentation. It focuses on practical enterprise and SAP contexts where use cases reveal integration gaps and failure modes.

Known limitations: the skill assumes access to process documentation and stakeholders who can validate the scenario. In environments with complex custom workflows or poor documentation, use case analysis becomes a discovery exercise rather than a documentation exercise. The skill does not cover formal UML notation or use case point estimation.