Business Szenarien

Business Szenarien in TOGAF allgemein

Business Szenarios dienen der Identifikation von Anforderungen. Beispielsweise kann damit ermittelt werden, welche Stakeholder involviert werden müssen, welche Capabilities notwendig sind oder welchen Zweck und welche Ziele die Architektur dient.

In ihnen wird ein End-to-End-Szenario umfänglich beschrieben. Es wird in der Phase B weiter detailliert.

Beispiel

Beispiele wäre die Planung einer Route. D.h. der Reisende, z.B. ein LKW-Fahrer möchte Ware von Stuttgart nach Köln transportieren. Er möchte gerne eine Route fahren, die keine Staus enthält und die für seinen LKW mit Sonderhöhe geeignet ist (d.h. keine Brücken unter 3 Meter Höhe).

Daraus ergeben sich Anforderungen an das Planungssystem und an die benötigen Informationen und Daten sowie an die beteiligten Akteure.

Fragen, die man zur Ausarbeitung eines Business Szenarios stellen und beantworten sollte

While there is no single set of appropriate questions to ask in all situations, the following provides some guidance to help business scenario consultants in asking questions.

' Identifying, Documenting, and Ranking the Problem

• Is the problem described as a statement of what needs to be accomplished, like steps in a process, and not how (with technology "push")?
• If the problem is too specific or a "how":

Raise a red flag Ask "Why do you need to do it that way?" questions

• If the problem is too vague or not actionable:

Raise a red flag

• Ask "What is it you need to do, or will be able to do if this problem is solved?" questions
• Ask questions that help to identify where and when the problem exists:
• Where are you experiencing this particular problem? In what business process?
• When do you encounter these issues? During the beginning of the process, the middle, the end?

Ask questions that help to identify the costs of the problem:

• Do you account for the costs associated with this problem? If so, what are they?
• Are there hidden costs? If so, what are they?
• Is the cost of this problem covered in the cost of something else? If so, what and how much?
• Is the problem manifested in terms of poor quality or a perception of an ineffective organization?

' Identifying the Business & Technical Environment, and Documenting in Models Questions to ask about the business environment:

• What key process suffers from the issues? What are the major steps that need to be processed?
• Location/scale of internal business departments?
• Location/scale of external business partners?
• Any specific business rules and regulations related to the situation?

Questions to ask about the current technology environment:

• What technology components are already presupposed to be related to this problem?
• Are there any technology constraints?
• Are there any technology principles that apply?

Identifying and Documenting Objectives

• Is the "what" sufficiently backed up with the rationale for "why"? If not, ask for measurable rationale in the following areas:
• Return on investment
• Scalability
• Performance needs
• Compliance to standards
• Ease-of-use measures

Identifying Human Actors and their Place in the Business Model An actor represents anything that interacts with or within the system. This can be a human, or a machine, or a computer program. Actors initiate activity with the system, for example:

• Computer user with the computer
• Phone user with the telephone
• Payroll clerk with the payroll system
• Internet subscriber with the web browser

An actor represents a role that a user plays; i.e., a user is someone playing a role while using the system (e.g., John (user) is a dispatcher (actor)). Each actor uses the system in different ways (otherwise they should be the same actor). Ask about the humans that will be involved, from different viewpoints, such as:

• Developer
• Maintainer
• Operator
• Administrator
• User

Identifying Computer Actors and their Place in the Technology Model Ask about the computer components likely to be involved, again from different points of view. What must they do? Documenting Roles, Responsibilities, Measures of Success, Required Scripts

• When defining roles, ask questions like:
• What are the main tasks of the actor?
• Will the actor have to read/write/change any information?
• Will the actor have to inform the system about outside changes?
• Does the actor wish to be informed about unexpected changes?

Checking for Fitness-for-Purpose, and refining if necessary

• Is there enough information to identify who/what could fulfil the requirement? If not, probe more deeply.
• Is there a description of when, and how often, the requirement needs to be addressed? If not, ask about timing.

Template zu Busienss Szenarien

Template für BS