Business Scenario Fields

1. Description (required)

• What it’s for: A brief title or summary that identifies this scenario.

• What to include:

  • Write as a short narrative title: “Actor does something” or “Event triggers outcome”.
  • Enough to distinguish this scenario from others at a glance in the list view.
  • The detail goes in Business Context and the flow fields.

• Examples:

  • "AP Clerk processes a matched invoice for payment"
  • "Finance Manager rejects an invoice due to a discrepancy"
  • "New supplier onboarded and first purchase order raised"

2. Business Context

• What it’s for: The broader business situation in which this scenario occurs — background that helps readers understand the context before the flow begins.

• What to include:

  • The business domain, team, or process this scenario sits within.
  • Any relevant background that is not obvious from the description alone.
  • The business problem or opportunity this scenario addresses.

• Example: "This scenario applies during the month-end close process. The AP Clerk receives a batch of matched invoices from the purchasing team and must validate and submit each one for Finance Manager approval before the payment run."

3. Priority

• What it’s for: The business priority of this scenario.
• Options: High, Medium, Low
• Guidance: Prioritise from the business’s perspective — which scenarios must be fully specified and tested for the solution to be accepted? High-priority scenarios should be fully elaborated, with flows and acceptance criteria, before effort is spent on lower-priority ones.

4. Actors (Actors tab)

• What it’s for: The business roles, systems, and external parties involved in this scenario.
• What to include:
  • Business Roles who participate (e.g. “AP Clerk”, “Finance Manager”)
  • Systems that interact (e.g. “Invoice Processing System”, “ERP”)
  • External parties if relevant (e.g. “Supplier”, “Bank”)

5. Trigger Events (Triggers tab)

• What it’s for: The events that initiate this scenario — the conditions or occurrences that cause it to begin.

• What to include:

  • List each trigger event separately.
  • Write as a business event, not a technical event (e.g. “Invoice received from supplier” not “POST /invoices called”).
  • A scenario may have multiple triggers if any one of them can start it.

• Examples: "Matched invoice notification received", "Finance Manager requests re-submission", "Month-end close window opens"

6. Preconditions (Preconditions tab)

• What it’s for: The state that must be true before this scenario can begin.

• What to include:

  • List each precondition separately.
  • Write as a factual state: “X is Y” or “X exists and is active”.
  • Include both business preconditions (e.g. supplier account exists) and system preconditions (e.g. user is authenticated).

• Examples: "Supplier account exists and is approved", "Purchase order has been raised and authorised", "Invoice has been matched to a purchase order"

7. Post-conditions (Postconditions tab)

• What it’s for: The state of the business after this scenario completes successfully.

• What to include:

  • List each postcondition separately.
  • Describe the end state, not the final action.
  • Include both business outcomes (e.g. payment queued) and system state (e.g. invoice status updated).

• Examples: "Invoice has been approved and queued for payment run", "AP Clerk notified of approval", "Audit trail entry created"

8. Main Flow of Events (Main Flow tab)

• What it’s for: The step-by-step sequence of events in the happy path — what happens when everything goes as expected.

• What to include:

  • Number each step.
  • Write from a business perspective — describe what each actor does and what the system responds with, in plain language.
  • Cover the complete flow from trigger to postcondition.
  • Do not include error handling here — that belongs in Exception Flows.

• Example steps:

  1. AP Clerk opens the invoice queue and selects the next matched invoice for review.
  2. System displays the invoice details alongside the matched purchase order.
  3. AP Clerk validates the details and submits the invoice for approval.
  4. System notifies the Finance Manager of the pending approval.
  5. Finance Manager reviews the invoice and approves it.
  6. System marks the invoice as approved and queues it for the next payment run.

9. Alternative Flows (Alternative Flows tab)

• What it’s for: Valid variations to the main flow — different but equally correct paths through the scenario.

• What to include:

  • Identify the step in the main flow where the variation begins.
  • Describe only the steps that differ; do not repeat the full main flow.
  • Each alternative flow should return to the main flow or reach a valid end state.

• Example: "Alt 1: AP Clerk delegates the review (step 3). Instead of submitting directly, AP Clerk assigns the invoice to a colleague for review. Colleague reviews and submits. Scenario continues from step 4."

10. Exception Flows (Exception Flows tab)

• What it’s for: Error handling and edge cases — what happens when something goes wrong at a point in the main flow.

• What to include:

  • Identify the step in the main flow where the exception can occur.
  • Describe the exception condition and what happens as a result.
  • Note whether the scenario recovers (and where it re-joins the main flow) or ends in an error state.

• Example: "Exc 2: Invoice details do not match the purchase order (step 2). AP Clerk raises a discrepancy. System notifies the purchasing team. Scenario pauses pending resolution. When resolved, the scenario resumes from step 2."

Relationships