Scenario View: Use‑Case‑Driven Architecture Validation

What is Scenario View?

Scenario view is the “+1” in the 4+1 view model, acting as a bridge between the other four static views. It describes how the system works at runtime and validates the architecture against key scenarios.

Core of Scenario View

Scenario definition

A scenario equals a use case plus its context. It answers Who, What, Why and How, effectively serving as a story‑style user manual for the system.

Functions

Validate architecture design (architecture → scenario analysis → problem discovery → architecture optimisation)

Facilitate communication between product, development and architecture teams

Provide the source of test cases

Representations

Use‑Case Diagram (online shopping example)

┌─────────────────────────────────────────────┐
│          Online Shopping System            │
│ ┌─────────────┐   ┌─────────────┐        │
│ │ User Login  │   │ Browse      │        │
│ └─────────────┘   └─────────────┘        │
│ ┌─────────────┐   ┌─────────────┐        │
│ │ Place Order │   │ Pay Order   │        │
│ └─────────────┘   └─────────────┘        │
│                User                      │
└─────────────────────────────────────────────┘

Use‑case description template (example: User Login)

Use case name: User Login
Actor: User
Precondition: User is registered
Basic flow:
1. User enters username and password
2. System validates credentials
3. System generates login token
4. User logs in successfully
Optional flow:
2a. Wrong credentials → System shows error → Return to step 1
Postcondition: User is logged in

Sequence Diagram (User places order)

User      Frontend   Gateway   Order Service   Product Service   Payment Service   Database
 │          │          │          │                │                │
 │──Click order→│          │          │                │                │
 │          │──Order request→│          │                │                │
 │          │          │──Validate stock──→│                │                │
 │          │          │      │      │──Query──→│                │
 │          │          │      │      │←──Result──│                │
 │          │          │←Stock insufficient│                │
 │          │←Order failed│                │                │
 │←Notify stock insufficient│                │                │
 │          │          │      │      │                │
 │──Retry order→│          │          │                │                │
 │          │──Order request→│          │                │                │
 │          │          │──Validate stock──→│                │
 │          │          │      │      │──Query──→│                │
 │          │          │      │      │←──Stock OK──│                │
 │          │──Create order──→│                │                │
 │          │      │      │──Write──→│                │
 │          │      │      │←──Order ID──│                │
 │          │──Call payment──→│                │                │
 │          │      │      │──Payment request──→│                │
 │          │      │      │←──Payment success──│                │
 │          │←Payment success│                │                │
 │          │──Deduct stock──→│                │                │
 │          │      │      │──Update──→│                │
 │          │←Order completed│                │                │
 │←Order success│                │                │                │

Activity Diagram (User registration)

┌───────┐
│ Start │
└───┬───┘
    ▼
┌─────────────┐
│Enter phone │
└───┬───────┘
    ▼
┌─────────────┐
│Phone valid?│
└───┬───────┘
    ▼
┌─────────────┐
│Send code    │
└───┬───────┘
    ▼
┌─────────────┐
│Enter code  │
└───┬───────┘
    ▼
┌─────────────┐
│Verified    │
└───┬───────┘
    ▼
┌─────────────┐
│Set password│
└───┬───────┘
    ▼
┌─────────────┐
│Registration│
│OK          │
└───┬───────┘
    ▼
┌───────┐
│ End   │
└───────┘

Identifying Key Scenarios

Identification methods

Business perspective : core business flow, most frequently used functions, value chain.

Risk perspective : scenarios prone to failure, high performance or consistency requirements.

Architecture‑decision perspective : scenarios affected by specific architectural choices or new technology stacks.

Prioritisation levels

P0 – Core scenario; failure makes the system unavailable (e.g., user login, order payment).

P1 – Important scenario; impacts core functionality (e.g., product search, order query).

P2 – General scenario; does not affect core functions (e.g., review posting, points redemption).

P3 – Minor scenario; mainly influences user experience (e.g., push notifications, personalized recommendation).

Sample scenario list

Scenario ID | Scenario Name               | Priority | Modules involved
-----------|----------------------------|----------|---------------------------
S001       | User registration & login  | P0       | User service, Auth service
S002       | Product browsing & search   | P0       | Product service, Search service
S003       | Shopping cart management   | P1       | Cart service, Product service
S004       | Order creation              | P0       | Order service, Inventory service
S005       | Order payment               | P0       | Payment service, Order service
S006       | Order cancellation          | P1       | Order service, Inventory service

Using Scenario View

Architecture review process

1. Introduce the overall architecture (the other four views)
2. Present key scenarios
3. Verify that the architecture supports each scenario
4. Identify problems and modify the architecture
5. Repeat until all scenarios are satisfied

Is there an implementation for every key scenario?

Do data flows match the architectural design?

Are exceptional paths handled?

Are performance requirements met?

Scenario‑driven development (BDD example)

Feature: User login functionality

  Scenario: Successful login with correct username and password
    Given the user is on the login page
    When the user enters username "user" and password "pass123"
    Then the system shows login success and redirects to the homepage

  Scenario: Failed login with wrong password
    Given the user is on the login page
    When the user enters username "user" and wrong password "wrong"
    Then the system shows error message "Invalid username or password"

Scenario as test input

Scenario → Test case → Automated test

S001 User login
    ├── TC001 Correct username and password → login success
    ├── TC002 Wrong password → login failure
    ├── TC003 Non‑existent username
    ├── TC004 Account locked
    └── TC005 Login timeout handling

Scenario View Document Template (outline)

# Scenario View Document

## 1. Overview
[Purpose and scope]

## 2. Key Scenario List
| Scenario ID | Scenario Name | Priority | Participants |
|------------|---------------|----------|--------------|
| S001       | …             | P0       | …            |
| S002       | …             | P1       | …            |

## 3. Detailed Scenario Description
### S001: [Scenario Name]
**Scenario description**: …
**Participants**: …
**Preconditions**: …
**Basic flow**:
1. …
2. …
**Exception flow**: …
**Postconditions**: …
**Acceptance criteria**: …

## 4. Scenario Sequence Diagram
[Insert sequence diagram]

## 5. Mapping to Architecture
[Explain how the scenario maps to architectural components]

Summary

Scenario view is dynamic – it describes how the system works.

Scenarios validate architecture – they drive design decisions.

Key scenarios must cover core business processes – P0 and P1 scenarios are essential.

Scenarios must be executable – they can be transformed into test cases.