Core model
Essential use cases describe intent and response.
An essential use case is a simplified account of a meaningful interaction. It alternates between what a user role is trying to accomplish and what the system must provide in response.
What Makes It Essential
Essential use cases avoid premature interface decisions. They do not specify clicks, menu paths, widgets, page names, or implementation services unless those details are genuinely part of the domain obligation.
The result is compact enough to review with stakeholders and abstract enough to survive interface redesign.
Basic Form
The simplest useful form is a two-column sequence.
| User intention | System responsibility |
|---|---|
| Identify a customer whose plan should change. | Provide matching customer records and enough context to choose safely. |
| Indicate the desired plan change. | Show eligible plans, constraints, costs, and effective dates. |
| Confirm the change is correct. | Apply the change and preserve an auditable record. |
Weak And Strong Examples
User clicks Search, types the customer number, presses Enter, selects the row, opens the Plan dropdown, chooses Premium, and clicks Save.
User identifies the customer and chooses the intended plan change. System presents valid options, checks constraints, and records the confirmed change.
The concrete version may be useful later for implementation or test scripting. The essential version is better for early requirements and design because it leaves multiple interface solutions available.
Writing Guidelines
- Name the use case with an action phrase, such as
Register New CustomerorResolve Claim Exception. - Write user-side steps as intentions, not gestures.
- Write system-side steps as responsibilities, not components.
- Keep the main success path short enough to review in one sitting.
- Add variants only when they change meaning, risk, or design obligations.
- Link every essential use case to one or more user roles.
- Capture preconditions and postconditions when they affect design or testing.
Variants And Exceptions
Use variants for legitimate alternate paths, such as a returning customer versus a new customer. Use exceptions for paths where the system cannot complete the user's intention under normal rules.
Variant
The customer is already known, so the role confirms identity instead of creating a new record.
Exception
The requested plan is unavailable for the customer's region, so the system must explain the constraint and support recovery.
Quality Check
An essential use case is ready to drive design when reviewers can answer yes to these questions.
- Can a domain expert recognize the task without seeing a screen mockup?
- Can a designer propose more than one interface solution from the same description?
- Can a tester infer meaningful acceptance checks from the responsibilities?
- Can the team explain which role owns the task and why it matters?
- Can the team identify what success means at the end of the case?