| Lesson 6 | Use Case Description (Part 2) |
| Objective | Add assumptions, pre-conditions, and post-conditions to a use case narrative. |
Use Case Pre-conditions and Post-conditions
A good use case is a single, testable unit of behavior that advances an actor’s goal. To make that behavior reliable and auditable, we anchor it with three guardrails:
- Assumptions - external conditions that are satisfied before this use case starts (handled elsewhere).
- Pre-conditions - checks performed by this use case before the main flow can proceed.
- Post-conditions - facts that must be true when the use case ends (state changes, records written, etc.).
Assumptions
Assumptions scope the entry point. If prior work must already be true (e.g., the user is authenticated), declare it here. Assumptions prevent mixing responsibilities across narratives and clarify ordering between use cases.
Pre-conditions are Tests
Pre-conditions are validations performed by the current use case: required inputs exist, permissions are granted, accounts are in a valid state, limits are not exceeded. Failed pre-conditions short-circuit to an alternate/exception flow.
Post-conditions
Post-conditions describe observable outcomes: new/updated records, emitted events, confirmations, and audit entries. They make the use case verifiable and support downstream processes (reconciliation, reversal, reporting).
Extended Use Case Template (concise)
Use Case: <Verb Noun> // e.g., Deposit Funds
Actor(s): <Primary/Secondary roles>
Assumptions:
- <External conditions satisfied before entry>
Pre-conditions:
- <Validations performed by this use case>
Trigger:
- <Event or choice that starts the use case>
Main Flow:
1) <Actor/System step>
2) ...
Alternate/Exception Flows:
A1) <Name>: <when/then>
E1) <Name>: <when/then>
Post-conditions:
- <Facts that must be true upon exit>
- <State changes / audit trail>
Worked Example - “Deposit Funds”
How the Example Evolves (Images 1 → 4)
- Start (Image 1): Basic template with the main flow only.
- Add Assumptions (Image 2): User is already authenticated; identity is known.
- Add Pre-conditions (Image 3): User is authorized to use the feature; inputs are valid.
- Add Post-conditions (Image 4): The transaction is recorded in the daily activity log (auditability).
This sequence reinforces the triad Authentication → Authorization → Accountability. Keep exception flows in your full narrative; they’re omitted in the image strictly for space.
Analyst Tips
- Write each use case for one goal; avoid UI/layout details-focus on observable behavior.
- Make pre-conditions executable checks; make post-conditions objectively verifiable.
- Use assumptions to declare prerequisites handled by other use cases (login, account linkage, etc.).
- Trace each post-condition to downstream needs (reporting, rollback, notifications).
Practice
Draft an extended narrative for a related scenario (e.g., “Withdraw Funds”) using the template above. Ensure at least one alternate flow (insufficient funds) and one exception (service outage) with clear pre-/post-conditions.