# Business Scenario: [Scenario name]

> Business scenario for one architecture engagement: the business problem,
> the business and technical environment in which it occurs, the
> objectives that solving it must meet, the human and computer actors
> involved, their roles and the scripts they follow, and the measures that
> show success. It is the business scenario technique described in the
> TOGAF Series Guide: Business Scenarios, part of The TOGAF Standard, 10th
> Edition, and is used mainly in Phase A (Architecture Vision) of the
> Architecture Development Method (ADM) to discover and confirm business
> requirements. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- A business scenario is a short, concrete story about one business
  problem, told with enough structure that architects can derive
  requirements from it. Write one document per scenario; an engagement
  usually has two to five.
- Build it with the business, not for it. The sections follow the order
  in which a workshop naturally works: problem (3), environment (4),
  objectives (5), actors (6 and 7), roles and scripts (8), measures (9),
  then a fitness check (10).
- Iterate. A first version states the premise; a second checks it with
  the people who live the problem; a third refines it until the sponsor
  agrees it is accurate. Section 2 tracks those rounds.
- The worked example follows the fictional insurer used in the other
  TOGAF templates of this collection, so goal IDs (BG) and driver IDs
  (DRV) line up with the Architecture Vision
  (`architecture/togaf-architecture-vision`).
- Only the names of the technique and its parts are used. The full
  guidance is in the Open Group publication; see the references.
-->

## Document control

<!-- Guidance: Identify the scenario as an input to a specific engagement and ADM phase. Link the Request for Architecture Work and the Architecture Vision it feeds. -->

| Field | Value |
|---|---|
| Document ID | [BSC-ENG-001] |
| Scenario name | [Policyholder reports a simple claim] |
| Engagement | [Architecture engagement name] |
| ADM phase | [Phase A: Architecture Vision] (also used in [Phase B: Business Architecture]) |
| Request for Architecture Work | [RAW-YYYY-NN] |
| Architecture Vision | [AV-ENG-001] |
| Version | [0.1] |
| Status | [Premise / Verified / Refined and agreed / Superseded] |
| Owner (lead architect) | [@lead-architect] |
| Business owner | [@business-owner] |
| Approvers / reviewers | [Sponsor, business owner, architecture board] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Conditions | Date |
|---|---|---|---|---|
| Sponsor | [@sponsor] | [Agreed / Agreed with changes / Not agreed] | [Conditions] | YYYY-MM-DD |
| Business owner | [@business-owner] | [Decision] | [Conditions] | YYYY-MM-DD |
| Lead architect | [@lead-architect] | [Decision] | [Conditions] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Premise: problem, first objectives and actors from sponsor interview |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Verified with claims handlers and IT operations; problem PRB-02 re-ranked, actor CA-04 added |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Refined and agreed by sponsor; objectives OBJ-01 to OBJ-04 baselined |
| [x.y] | YYYY-MM-DD | [@name] | [Change] |

## Contents

1. [Scenario summary](#1-scenario-summary)
2. [How this scenario was built](#2-how-this-scenario-was-built)
3. [Problem](#3-problem)
4. [Business and technical environment](#4-business-and-technical-environment)
5. [Objectives](#5-objectives)
6. [Human actors](#6-human-actors)
7. [Computer actors](#7-computer-actors)
8. [Roles, responsibilities and scripts](#8-roles-responsibilities-and-scripts)
9. [Measures of success and desired outcomes](#9-measures-of-success-and-desired-outcomes)
10. [Fitness-for-purpose check and refinement](#10-fitness-for-purpose-check-and-refinement)
11. [Traceability to ADM deliverables](#11-traceability-to-adm-deliverables)
12. [Glossary and references](#12-glossary-and-references)

## 1. Scenario summary

<!-- Guidance: Tell the whole scenario in one paragraph that a sponsor can read in a minute: who has the problem, what happens today, what should happen instead and why it matters. If you cannot write this paragraph, the scenario is not yet understood. -->

[Summary paragraph. *Example:* A policyholder whose car windscreen is
cracked reports the damage online. Today the report is re-keyed by a
claims handler into the policy system, the claims system and a supplier
portal; the customer waits 11 days on average for a decision and calls
the contact centre twice. The insurer wants simple claims like this one
decided within 48 hours, with the customer able to see the status
online, without adding staff. The scenario supports business goal BG-01
(faster claims decisions) and BG-03 (lower cost to serve) in the
Architecture Vision.]

| Item | Value |
|---|---|
| Business goal(s) supported | [BG-01, BG-03] |
| Business drivers | [DRV-01, DRV-04] |
| Scope of the scenario | [Simple claims below the auto-decision threshold, motor glass and minor home damage] |
| Out of scope | [Injury claims, fraud investigation, large losses] |

## 2. How this scenario was built

<!-- Guidance: Record the steps and rounds you went through, with whom, so readers can judge how far to trust the scenario. The technique describes a cycle of planning, gathering, analysing, documenting and reviewing, repeated over several rounds that move from an initial premise to a verified and refined scenario. -->

### 2.1 Steps

| Step | What we did | Who took part | Date | Output |
|---|---|---|---|---|
| Planning | *Example:* Chose the scenario from the RAW problem list; agreed interviewees and workshop agenda | Lead architect, business owner | YYYY-MM-DD | Plan and participant list |
| Gathering | *Example:* Two-hour workshop with claims handlers; interviews with contact centre lead and IT operations; review of complaint data | 9 participants | YYYY-MM-DD | Workshop notes, process walk-through |
| Analysing | *Example:* Grouped problems, traced each to systems and roles, drafted SMART objectives | Architects | YYYY-MM-DD | Draft sections 3 to 8 |
| Documenting | *Example:* Wrote this document and the models in section 4 and 8 | Lead architect | YYYY-MM-DD | Version 0.1 |
| Reviewing | *Example:* Walk-through with sponsor and business owner; changes logged | Sponsor, business owner, architects | YYYY-MM-DD | Version 0.2 and 1.0 |

### 2.2 Rounds

| Round | Purpose | Status | Version |
|---|---|---|---|
| Premise formulation | Capture the problem and goals as the sponsor sees them | *Example:* Done | 0.1 |
| Initial verification | Check the premise with the people who live the problem | *Example:* Done | 0.2 |
| Refinement | Correct, deepen and agree the scenario | *Example:* Done | 1.0 |

## 3. Problem

<!-- Guidance: Describe the problem in business terms and rank its parts. Ask: what goes wrong, how often, for whom, and what it costs. Separate symptoms from causes. Pitfall: stating a solution ("we need a new claims system") as the problem. -->

### 3.1 Problem statement

[Problem statement. *Example:* Simple claims take as long as complex
ones because every claim follows the same manual route. Information is
captured three times in three systems, the decision rules live in
handlers' heads, and the customer has no view of progress.]

### 3.2 Ranked problems

| Rank | ID | Problem | Who is affected | Frequency or size | Evidence |
|---|---|---|---|---|---|
| 1 | PRB-01 | *Example:* Average 11 days from report to decision for simple claims | Policyholders, handlers | About 4,800 simple claims per month | Claims system report, last 12 months |
| 2 | PRB-02 | *Example:* Each claim re-keyed into three systems; 38 minutes of handler time per simple claim | Claims handlers | Every simple claim | Time-and-motion study, 60 claims |
| 3 | PRB-03 | *Example:* Customers call to ask about status | Contact centre, policyholders | 2 calls per claim on average | Telephony data |
| 4 | PRB-04 | *Example:* Decision rules are inconsistent between handlers | Policyholders, compliance | 1 in 12 sampled decisions differed from the guide | Quality review sample |
| [N] | [PRB-NN] | [Problem] | [Who] | [Size] | [Evidence] |

### 3.3 Causes

| Problem | Underlying cause | Type |
|---|---|---|
| PRB-01, PRB-02 | *Example:* No shared claim record; three systems with separate data entry | Information and technology |
| PRB-01, PRB-04 | *Example:* Decision rules undocumented and not automated | Process and knowledge |
| PRB-03 | *Example:* No status events exposed to customer channels | Technology |
| [PRB IDs] | [Cause] | [Process / People / Information / Technology] |

## 4. Business and technical environment

<!-- Guidance: Describe where the problem lives: the business process, the organisation units, the systems and the constraints. Use simple models; the technique expects the environment to be documented in models, not only prose. Keep it at the level of detail the problem needs. -->

### 4.1 Business environment

| Element | Description | Constraint or influence |
|---|---|---|
| *Example:* Claims operations | 140 handlers in two centres, working in pools by product | Union agreement on changes to job content |
| *Example:* Contact centre | Handles status calls for all products | Separate budget and management line |
| *Example:* Glass repair suppliers | Panel of approved suppliers | Contracts renew in [YYYY-MM] |
| *Example:* Regulation | Fair treatment of customers, claims handling rules, data protection | Decisions must be explainable to the customer |
| [Element] | [Description] | [Influence] |

### 4.2 Technical environment

| Element | Description | Constraint or influence |
|---|---|---|
| *Example:* Policy administration system | Holds cover and excess per policy | Batch interfaces only, overnight |
| *Example:* Claims management system | Records claims and payments | Vendor support ends [YYYY] |
| *Example:* Supplier portal | Third-party web portal for repair booking | No API; manual entry |
| *Example:* Customer web portal | Login, policy documents | Owned by digital team; can call internal APIs |
| [Element] | [Description] | [Influence] |

### 4.3 Current process model

The model shows today's route for a simple claim, with the three points of
manual data entry marked.

```mermaid
flowchart LR
  A["Customer reports damage (web form or phone)"] --> B["Handler re-keys report into claims system (entry 1)"]
  B --> C["Handler checks cover in policy system (entry 2)"]
  C --> D{"Handler decides using personal judgement"}
  D -->|"Accept"| E["Handler books repair in supplier portal (entry 3)"]
  D -->|"Refer"| F["Senior handler review"]
  F --> E
  E --> G["Letter sent to customer"]
```

## 5. Objectives

<!-- Guidance: Turn the problem into objectives that are specific, measurable, actionable, realistic and time-bound (SMART). Each objective names its baseline, target and date, and traces to a business goal. The TOGAF guidance groups goals into categories such as improving business process performance, decreasing costs, improving user productivity and reducing risk; use a category column to show the mix. -->

| ID | Objective | Goal category | Baseline | Target | By | Traces to |
|---|---|---|---|---|---|---|
| OBJ-01 | *Example:* Decide simple claims within 48 hours of report | Improve business process performance | 9% of simple claims (about 432 a month) | 70% (about 3,360 a month) | YYYY-MM | BG-01, PRB-01 |
| OBJ-02 | *Example:* Cut handler time per simple claim | Decrease costs | 38 minutes (3,040 handler hours a month) | 15 minutes (1,200 handler hours a month) | YYYY-MM | BG-03, PRB-02 |
| OBJ-03 | *Example:* Remove the need for status calls | Improve user productivity | 2 calls per claim | 0.5 calls per claim | YYYY-MM | BG-01, PRB-03 |
| OBJ-04 | *Example:* Apply decision rules consistently | Reduce risk | 1 in 12 sampled decisions differ from the guide | 1 in 100 or fewer | YYYY-MM | PRB-04 |
| [OBJ-NN] | [Objective] | [Category] | [Baseline] | [Target] | YYYY-MM | [BG / PRB IDs] |

Worked numbers (*Example*): 4,800 simple claims a month at 38 minutes is
3,040 handler hours; at 15 minutes it is 1,200 hours, a reduction of
1,840 hours a month (about 61%). At the 48-hour target, 70% of 4,800 is
3,360 claims a month against 432 (9%) today.

### 5.1 SMART check

| Objective | Specific | Measurable | Actionable | Realistic | Time-bound | Note |
|---|---|---|---|---|---|---|
| OBJ-01 | Yes | Yes | Yes | *Example:* Partly | Yes | Depends on cover data being available in real time (CA-01) |
| OBJ-02 | Yes | Yes | Yes | Yes | Yes | |
| OBJ-03 | Yes | Yes | Yes | Yes | Yes | |
| OBJ-04 | Yes | Yes | Yes | Yes | Yes | Needs a sampling method agreed with compliance |
| [OBJ-NN] | [Yes / No / Partly] | [Yes / No / Partly] | [Yes / No / Partly] | [Yes / No / Partly] | [Yes / No / Partly] | [Note] |

## 6. Human actors

<!-- Guidance: List the people and organisations who take part in the scenario and where they sit in the business model (organisation unit, process step). Use roles, not names. Pitfall: forgetting actors who are affected but never touch a system, such as a regulator or supplier. -->

| ID | Human actor | Organisation unit | Place in the business model | Interest in the outcome |
|---|---|---|---|---|
| HA-01 | *Example:* Policyholder | Customer | Starts the scenario; receives decision | Speed, clarity, fairness |
| HA-02 | *Example:* Claims handler | Claims operations | Decides claims outside the automatic rules | Less re-keying, clear rules |
| HA-03 | *Example:* Senior handler | Claims operations | Reviews referred claims | Only real exceptions referred |
| HA-04 | *Example:* Contact centre agent | Customer service | Answers status calls | Fewer status calls |
| HA-05 | *Example:* Glass repair supplier | External partner | Books and performs repair | Complete job details, fast booking |
| HA-06 | *Example:* Claims quality reviewer | Compliance | Samples decisions | Consistent, explainable decisions |
| [HA-NN] | [Actor] | [Unit] | [Place] | [Interest] |

## 7. Computer actors

<!-- Guidance: List the systems, services and devices that take part, and where they sit in the technology model. Include systems that should take part in the future, marked as target. A computer actor that appears in no script in section 8 is probably not needed. -->

| ID | Computer actor | Owner | Place in the technology model | Current or target |
|---|---|---|---|---|
| CA-01 | *Example:* Policy administration system | Policy IT | System of record for cover | Current (batch); target exposes a cover API |
| CA-02 | *Example:* Claims management system | Claims IT | System of record for claims | Current; replacement under study |
| CA-03 | *Example:* Customer web portal | Digital team | Customer channel | Current; target shows claim status |
| CA-04 | *Example:* Decision rules service | Claims IT | Shared business rules | Target |
| CA-05 | *Example:* Supplier booking interface | Partner integration team | Integration with supplier panel | Target (replaces manual portal entry) |
| [CA-NN] | [System] | [Owner] | [Place] | [Current / Target] |

## 8. Roles, responsibilities and scripts

<!-- Guidance: For each actor, say what it is responsible for in the scenario, then write the script: the ordered steps of the desired future scenario, showing which actor does what. Scripts are where requirements come from; every step should be testable. Keep a current-state script only if it helps to show the change. -->

### 8.1 Responsibilities

| Actor | Responsibility in the target scenario | Measure of success |
|---|---|---|
| HA-01 Policyholder | Reports the damage with photos and answers guided questions | Report completed in under 10 minutes |
| HA-02 Claims handler | Decides claims the rules refer, using one claim record | Referred claims decided within 24 hours |
| CA-03 Customer web portal | Collects the report and shows status | Status shown at every step |
| CA-04 Decision rules service | Applies documented rules to accept, refer or decline | Same result for the same facts every time |
| CA-05 Supplier booking interface | Books the repair with the chosen supplier | Booking confirmed within 2 hours |
| [Actor] | [Responsibility] | [Measure] |

### 8.2 Target script

| Step | Actor | Action | Result |
|---|---|---|---|
| S-01 | HA-01 via CA-03 | Reports damage with photos | Claim record created once |
| S-02 | CA-03 to CA-01 | Requests cover and excess for the policy | Cover confirmed in seconds |
| S-03 | CA-03 to CA-04 | Submits claim facts for a decision | Accept, refer or decline with reason |
| S-04 | CA-04 to CA-05 | On accept, books repair with a panel supplier | Booking reference |
| S-05 | CA-03 to HA-01 | Shows decision, reason and booking | Customer informed without a call |
| S-06 | HA-02 | On refer, decides using the same claim record | Decision within 24 hours |

### 8.3 Target scenario model

The sequence below shows the accept path of the target script, steps S-01
to S-05.

```mermaid
sequenceDiagram
  actor PH as Policyholder (HA-01)
  participant WEB as Customer web portal (CA-03)
  participant POL as Policy administration (CA-01)
  participant DR as Decision rules service (CA-04)
  participant SUP as Supplier booking interface (CA-05)
  PH->>WEB: S-01 Report damage with photos
  WEB->>POL: S-02 Request cover and excess
  POL-->>WEB: Cover confirmed
  WEB->>DR: S-03 Submit claim facts
  DR->>SUP: S-04 Book repair on accept
  SUP-->>DR: Booking reference
  DR-->>WEB: Decision, reason and booking
  WEB-->>PH: S-05 Show decision and booking
```

## 9. Measures of success and desired outcomes

<!-- Guidance: State how the business will know the scenario has been solved, in terms the sponsor already tracks. Link each measure to an objective and say where the number comes from. These measures usually become KPIs in the Architecture Vision. -->

| ID | Desired outcome | Measure | Data source | Objective | Review frequency |
|---|---|---|---|---|---|
| MS-01 | *Example:* Customers get fast decisions | Share of simple claims decided within 48 hours | Claims system timestamps | OBJ-01 | Monthly |
| MS-02 | *Example:* Handlers spend time on judgement, not typing | Handler minutes per simple claim | Workflow time logs | OBJ-02 | Quarterly |
| MS-03 | *Example:* Customers can see progress | Status calls per claim | Telephony data | OBJ-03 | Monthly |
| MS-04 | *Example:* Decisions are consistent | Share of sampled decisions that differ from the rules | Compliance sampling | OBJ-04 | Quarterly |
| [MS-NN] | [Outcome] | [Measure] | [Source] | [OBJ ID] | [Frequency] |

## 10. Fitness-for-purpose check and refinement

<!-- Guidance: Before calling the scenario agreed, check that it is good enough to drive architecture work. Answer each question honestly; a "no" sends you back to the relevant section for another round. Record what changed in each round. -->

| Check | Question | Result | Action |
|---|---|---|---|
| FP-01 | Does the sponsor agree the problem and its ranking are right? | [Yes / No] | *Example:* Yes, after PRB-02 moved to rank 2 |
| FP-02 | Is every objective SMART and traced to a business goal? | [Yes / No] | *Example:* Yes |
| FP-03 | Does every actor appear in at least one script step? | [Yes / No] | *Example:* No: HA-03 to HA-06 have no direct step (HA-05 acts through CA-05); kept as affected actors |
| FP-04 | Can each script step be turned into a testable requirement? | [Yes / No] | *Example:* Yes |
| FP-05 | Are the measures available today, or is a new data source needed? | [Yes / No] | *Example:* Workflow time logs needed for MS-02 |
| FP-06 | Have the people who live the problem reviewed the scenario? | [Yes / No] | *Example:* Yes, handlers and contact centre in round 2 |
| [FP-NN] | [Question] | [Result] | [Action] |

### 10.1 Refinement log

| Round | Date | What changed | Why |
|---|---|---|---|
| Initial verification | YYYY-MM-DD | *Example:* Added CA-04 decision rules service as a separate actor | Handlers showed the rules are the bottleneck, not the systems |
| Refinement | YYYY-MM-DD | *Example:* OBJ-03 target lowered from 0 to 0.5 calls per claim | Some customers will always call; sponsor agreed |
| [Round] | YYYY-MM-DD | [Change] | [Reason] |

## 11. Traceability to ADM deliverables

<!-- Guidance: Show where each part of the scenario goes next, so the scenario is not lost after Phase A. Typical destinations: goals and KPIs in the Architecture Vision, requirements in the Architecture Requirements Specification, gaps in the Architecture Definition Document. -->

| Scenario element | Feeds | Deliverable | Reference |
|---|---|---|---|
| OBJ-01 to OBJ-04 | Goals, objectives and KPIs | Architecture Vision (`architecture/togaf-architecture-vision`) | Sections 3 and 7 |
| Script steps S-01 to S-06 | Business and system requirements | Architecture Requirements Specification (`architecture/architecture-requirements-specification`) | [Requirement IDs] |
| Section 4 environment and 4.3 model | Baseline business and technology architecture | Architecture Definition Document (`architecture/architecture-definition-document`) | [Section] |
| Computer actors marked target | Building blocks and work packages | Architecture Roadmap and Transition Architectures (`architecture/architecture-roadmap-transition`) | [Work package IDs] |
| Measures MS-01 to MS-04 | Benefits tracking | Architecture Contract (`architecture/architecture-contract`) | [Clause] |
| [Element] | [What it feeds] | [Deliverable] | [Reference] |

## 12. Glossary and references

<!-- Guidance: Define terms that the business and IT may read differently. Keep definitions in your own words. -->

### 12.1 Glossary

- **Business scenario**: a structured description of a business problem,
  its environment, objectives, actors and expected results, used to
  derive architecture requirements.
- **Human actor**: a person or organisation that takes part in the
  scenario.
- **Computer actor**: a system, service or device that takes part in the
  scenario.
- **Script**: the ordered steps that actors perform in the scenario.
- **SMART**: specific, measurable, actionable, realistic and time-bound,
  a common test for objectives.
- **Simple claim** (*Example*): a claim below the auto-decision threshold
  with no injury and no fraud indicators.

### 12.2 References

| ID | Reference | Version or date |
|---|---|---|
| REF-01 | The TOGAF Standard, 10th Edition (The Open Group, catalogue C220), https://publications.opengroup.org/c220 | 10th Edition incorporating Technical Corrigendum 1 (U254, 15 May 2025) |
| REF-02 | TOGAF Series Guide Set: Business Architecture (The Open Group, document T190), which includes the TOGAF Series Guide: Business Scenarios, https://publications.opengroup.org/t190 | Catalogue lists publication 25 April 2022; a 2025 update is sold in print (June 2025) |
| REF-03 | Request for Architecture Work (`architecture/request-for-architecture-work`) | [x.y] |
| REF-04 | Architecture Vision (`architecture/togaf-architecture-vision`) | [x.y] |
| REF-05 | Business Capability Map (`architecture/business-capability-map`) and Value Stream Map (`architecture/value-stream-map`) | [x.y] |

Official text: The Open Group, purchase or licensed access at
https://publications.opengroup.org/t190 (Business Architecture guide set,
including Business Scenarios) and https://publications.opengroup.org/c220
(the TOGAF Standard). Some documents are free to download after
registration; check the licence terms on the Open Group site.

## Standard and licence note

Structure aligned with the business scenario technique described in the
TOGAF Series Guide: Business Scenarios, part of The TOGAF Standard, 10th
Edition, published by The Open Group: the problem, business and technical
environment, objectives, human and computer actors, roles and scripts,
measures of success and fitness-for-purpose check, built in rounds of
planning, gathering, analysing, documenting and reviewing. Only the names
of the technique, its parts and the ADM phases are used; this template is
original text and reproduces no definitions, tables, figures or other
text from the publication. TOGAF is a registered trademark of The Open
Group. Check the current edition at opengroup.org and obtain the guide
for its full method. Template licence: MIT.