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.

Ein Business Szenario soll dabei ein größeres Problem und die Lösung des Problems umfassend beschreiben. Dabei ist darauf zu achten, dass die Beschreibung aus der Sicht der Anforderungen erfolgt und noch nicht konkret auf Lösungen eingegangen wird.

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

Folgende Liste gibt einen Anhaltspunkt, welche Fragen zur Ausarbeitung eines Business Szenarios verwendet werden können:

Zur Identifikation, Dokumentation des Problems und zum Ranking der Probleme

• Ist das Problem so beschrieben, dass man daraus erkennen kann, was man zur Behebung unternehmen muss (Schritte in einem Vorgehen), nicht wie es behoben werden soll (kein Fokus auf die Technologie).
• Ist das Problem zu spezifisch oder fokusiert es das "Wie"?
• Warum muss es genau so gemacht werden? Kann es alternative Lösungen geben?
• Ist das Problem zu ungenau oder gibt es dazu keinerlei Lösung?
• Was sind die Folgen, wenn das Problem gelöst wurde?
• Wo tritt das Problem genau auf?
• Wann tritt das Problem genau auf?
• Sind die Kosten, die das Problem verursacht, bekannt?
• Gibt es versteckte Kosten? Welche?
• Zeigt sich das Problem durch schlechte Qualität oder ineffektiver Arbeit?

Zur Identifikation der relevanten Umgebung und deren Dokumentation

• Welche Prozesse leiden unter dem Problem?
• Welche Organisationen sind vom Problem betroffen? Wo sind diese verortet? Um welchen Typ von Organisation handelt es sich?

• 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