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.
Document control
| 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
[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
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
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
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.
5. Objectives
| 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
| 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
| 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
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.
9. Measures of success and desired outcomes
| 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
| 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
| 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
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] |
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.