3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation
Key Takeaways
The Business Scenarios technique, described in a TOGAF Series Guide, is used in Phase A to define the problem and Architecture Vision and in Phase B for more detailed business requirements.
TOGAF's seven steps are: identify and rank the problem; identify the business and technical environment; identify SMART objectives; identify human actors; identify computer actors; document roles, responsibilities, and measures of success; check fitness for purpose and refine.
Computer actors are automated systems that take part in the scenario; documenting them exposes interfaces, timing constraints, and security boundaries.
SMART means Specific, Measurable, Actionable, Realistic, and Time-bound, and it applies to scenario objectives and the requirements derived from them.
A business scenario separates the real business problem from any solution a stakeholder has already proposed.
3.3 Business Scenarios Technique for Problem Definition and Requirements Elicitation
A persistent challenge in enterprise architecture is bridging the linguistic and conceptual chasm between executive business leadership and technical engineering teams. Business executives frequently articulate their needs in terms of ambitious strategic desires ("We need to be the Uber of commercial logistics") or prescribe pre-selected commercial software packages ("We must purchase vendor platform X immediately"). If architects accept these statements without deeper analysis, they risk architecting solutions for the wrong problem. The TOGAF Standard provides the Business Scenarios technique as a disciplined, repeatable method to uncover, understand, and articulate authentic business requirements and desired outcomes before technical architectures are designed.
The Role of Business Scenarios in Architecture Requirements Elicitation
A Business Scenario is a formal representation of a significant business problem, operational challenge, or strategic ambition, framed within its real-world operational context. It articulates the operational environment, the participants who interact with it, the desired business results, and the technical requirements necessary to achieve those results.
Within the TOGAF ADM, the Business Scenarios technique is primarily utilized in two critical phases:
- Phase A (Architecture Vision): Used at a high level of abstraction to define the strategic problem space, discover candidate architecture requirements, establish consensus on project scope, and articulate the core narrative of the Architecture Vision deliverable.
- Phase B (Business Architecture): Used at a more granular level of detail to map operational workflows, identify capability gaps, and define precise functional requirements across business services and value streams.
By focusing strictly on business problems and operational outcomes rather than technical components, Business Scenarios prevent premature architectural commitment to vendor solutions, proprietary tools, or unvalidated infrastructure patterns.
The TOGAF Steps for Developing a Business Scenario
The TOGAF Series Guide: Business Scenarios describes seven steps, carried out iteratively in three stages (gather, analyze, and review):
- Identify, document, and rank the problem that is driving the scenario. Ask why the organization must act and which issue matters most.
- Identify the business and technical environment of the scenario and document it in models. This covers the business processes, organizations, locations, regulations, and existing systems involved.
- Identify and document desired objectives: the results of handling the problem successfully. Objectives should be SMART.
- Identify the human actors (participants) and their place in the business model, such as customers, clerks, underwriters, and compliance investigators.
- Identify the computer actors (computing elements) and their place in the technology model, such as core ledgers, partner APIs, scoring engines, and batch schedulers.
- Identify and document roles, responsibilities, and measures of success per actor, and capture the required scripts per actor and the results of handling the situation.
- Check for fitness for purpose and refine the scenario if necessary, confirming it with the stakeholders who contributed to it.
Why Computer Actors Matter
Treating automated systems as actors in their own right exposes interfaces, data exchanges, timing constraints, and security boundaries early. A scenario that documents only people and screens misses the system-to-system interactions that often decide whether a target architecture is feasible.
From Scenario to Architecture Requirements
A completed business scenario gives Phase A a validated problem statement and objectives for the Architecture Vision, and gives Phase B a starting point for more detailed business requirements. Requirements derived from it span the domains:
- Business: new or changed capabilities, roles, processes, and approval rules.
- Data: information that must be created, shared, or retained, and its classification.
- Application: services and interfaces that applications must provide.
- Technology: platform qualities such as availability, latency, and capacity that the solution depends on.
Applying SMART Criteria to Objectives and Requirements
TOGAF asks for business scenario objectives to be SMART: Specific, Measurable, Actionable, Realistic, and Time-bound. The TOGAF Enterprise Metamodel defines an Objective in the same terms. Applying the same test to the requirements derived from a scenario keeps them verifiable later, in compliance reviews:
┌─────────────────┬──────────────────────────────────────────────────────────────┐
│ SMART Criterion │ Enterprise Architecture Interpretation & Quality Standard │
├─────────────────┼──────────────────────────────────────────────────────────────┤
│ Specific │ Unambiguous, clear, and focused on an architectural outcome. │
│ │ Avoids subjective terms ("modern", "flexible", "fast"). │
├─────────────────┼──────────────────────────────────────────────────────────────┤
│ Measurable │ Quantifiable through objective metrics, latencies, or SLAs. │
│ │ Enables unambiguous pass/fail verification during Phase G. │
├─────────────────┼──────────────────────────────────────────────────────────────┤
│ Actionable │ Operationally achievable within the enterprise's technical │
│ │ governance, capability maturity, and organizational capacity.│
├─────────────────┼──────────────────────────────────────────────────────────────┤
│ Realistic │ Grounded in financial budgets, physical infrastructure, and │
│ │ regulatory boundaries established in Phase A scope. │
├─────────────────┼──────────────────────────────────────────────────────────────┤
│ Time-bound │ Bounded by explicit delivery dates, release windows, or │
│ │ designated Transition Architecture roadmaps. │
└─────────────────┴──────────────────────────────────────────────────────────────┘
If a requirement fails the SMART test, it cannot serve as a reliable baseline for architectural design or compliance evaluation in Phase G.
Worked Scenario: Omnichannel Retail Banking Real-Time Fraud Interception
To understand how the Business Scenarios technique functions in practice, consider an enterprise engagement for a commercial retail bank:
1. Problem Background
The bank experiences $15M in annual fraudulent card transactions across web and mobile payment portals. Current fraud detection relies on overnight batch analysis. Customers whose cards are compromised suffer unauthorized fund depletion, while legitimate customers face a 22% cart abandonment rate due to blunt, rule-based card lockouts.
2. Operational Environment
Global retail banking operations across North America and Europe. High transaction volume peaking at 12,000 transactions per second (TPS) during retail holiday seasons. Must comply with PCI-DSS 4.0, GDPR data residency, and PSD2/3 Strong Customer Authentication (SCA).
3. Actors
- Human Actors: Retail Customer, Tier-2 Fraud Investigation Analyst, Compliance Audit Officer.
- Computer Actors: Mobile Client Application, Omnichannel API Gateway, Real-Time Machine Learning Inference Engine, Core Banking Ledger Mainframe, External Credit Bureau Scoring Service.
4. Objectives
- Real-time fraud probability scoring executed within transaction authorization latency budgets without degrading checkout speed.
- Reduction of false-positive declines by at least 40% within 9 months of deployment.
- Automated straight-through authorization for 99.2% of legitimate transactions.
5. Derived SMART Architectural Requirements
| Architectural Domain | Derived SMART Requirement |
|---|---|
| Business Architecture | Establish an automated Tier-1 Straight-Through Fraud Resolution process workflow, routing disputed transactions above $1,000 directly to Tier-2 human analysts within 15 minutes of trigger. |
| Data Architecture | Design an in-memory unified customer behavioral profile data model with read-latency under 5 milliseconds, partitioned by regulatory jurisdiction to satisfy GDPR cross-border restrictions. |
| Application Architecture | Deploy an asynchronous, event-driven fraud evaluation microservice capable of processing 15,000 TPS with a p99 response time under 65 milliseconds. |
| Technology Architecture | Implement a multi-region active-active distributed compute cluster with 99.999% availability, dedicated hardware security modules for encryption key storage, and automated sub-second failover. |
Common Practitioner Pitfalls: Solutions Masquerading as Requirements and Untestable Criteria
Enterprise architects must identify and correct classic requirements traps:
- Prescribing Technologies Instead of Capabilities: A stakeholder states: "The requirement is to install an Apache Kafka streaming cluster." Kafka is a specific technological Solution Building Block (SBB), not a business requirement. The genuine architectural requirement is: "The system must support distributed, real-time event streaming capable of ingesting 15,000 payment event records per second with guaranteed at-least-once delivery and zero data loss."
- Untestable Adjectives: Writing requirements containing words like "user-friendly," "seamless," "highly resilient," or "cost-effective." When an implementation team in Phase G presents their deliverables, an architect cannot objectively verify whether an application is "seamless." The requirement must be rewritten with verifiable metrics (e.g., "Onboarding workflow requires no more than 4 screens and must complete in under 120 seconds").
- Ignoring Computer-to-Computer Interaction: Designing business scenarios that only document customer-to-screen interactions. If the architect ignores background batch synchronizations, external partner rate limits, and network timeout behaviors, the target architecture will fail under production operational conditions.
An enterprise architect reviews an elicited requirement statement: "The new global payment gateway must be highly performant, ultra-reliable, and cloud-native to handle peak holiday traffic." Why does this statement fail the TOGAF criteria for quality architectural requirements?
Because the statement names a single system, and TOGAF requires every architecture requirement to apply across the whole enterprise rather than one platform.
Because TOGAF requires every architecture requirement to be expressed in formal UML or ArchiMate notation before it can be validated.
Because terms like "highly performant" and "ultra-reliable" have no measurable targets or time bounds, so the requirement cannot be validated.
Because business requirements must not be tied to seasonal sales cycles, since peak loads are handled through capacity planning in Phase D.
In the TOGAF Business Scenarios technique, how are "computer actors" distinguished from human actors, and why are they essential to requirements elicitation?
They are the developers who write automation scripts, and they are listed separately so the scenario can exclude them from business requirements.
They are simulated personas used for load testing in Phase G, and they help size infrastructure rather than capture business requirements.
They are peripheral hardware devices such as printers and scanners, and they matter only when the scenario includes physical locations.
They are software systems or external services that take part in the process without direct human action; missing them hides integration requirements.
A business unit vice president insists during Phase A requirements gathering that the enterprise must immediately procure a specific commercial off-the-shelf (COTS) cloud CRM software suite. How should the enterprise architect apply the Business Scenarios technique in this situation?
Use the technique to uncover the business problem, processes, and outcomes behind the request, separating the real requirements from the proposed product.
Record the COTS product in the Architecture Vision as a mandatory constraint, since a vice president's stated preference reflects the sponsor's business priorities.
Decline to discuss the request, because TOGAF does not allow business executives to propose software products during Phase A requirements gathering.
Move straight to Phase E so the product can be evaluated as a Solution Building Block, since the business need is already clear from the request.
Sections you finish are checked off in the contents.