Requirements Engineering und Geschäftsprozessmodellierung – zwei Seiten der gleichen Medaille
Heinz Ehrsam1, Ralf Fahney2, Kurt McKeown1
1Credit Suisse, CH-8070 Zürich
{heinz.ehrsam | kurt.mckeown}@credit-suisse.com
2Fahney Anforderungsingenieurwesen GmbH, Scheideggstrasse 73, CH-8038 Zürich.
rf@fahney.com
Abstract: Lassen sich Requirements Engineering und Geschäftsprozess- modellierung im Kontext service-orientierter Architektur überhaupt noch trennen?
Die Autoren sind der Auffassung: Ja! Und es ist sinnvoll, die Disziplinen voneinander zu trennen. Die Autoren begründen dies, beschreiben die bei Credit Suisse geplante Integration und zeigen die Implikationen auf für Projektarbeit. Die dargestellten Konzepte und Erfahrungen basieren auf einem Projekt, welches zum Ziel hat, einen umfangreichen Teil historisch gewachsener IT-Systeme der Credit Suisse binnen der nächsten sechs bis sieben Jahre abzulösen durch Neuentwicklung in service-orientierter Architektur.
1 Das Projekt
Aus geschäftsstrategischen Überlegungen heraus, also getrieben vom Fachbereich, führt Credit Suisse ein Projekt durch, welches einen umfangreichen Teil ihrer historisch gewachsenen Backoffice-Applikationen binnen der nächsten sechs bis sieben Jahre durch zukunftsorientierte Technologien ablösen soll. Daher erarbeitet und pilotiert die Bank derzeit die Grundlagen anhand eines in sich abgeschlossenen Teils der vom neuen System zu unterstützenden Geschäftsprozesse.
Im Fokus stehen sowohl die Lösungstechnologien
• Integration von Geschäftsprozess-, Use Case-, Daten- und Regelmodell auf der konzeptionellen Ebene
• Automatisierte Transformation der modellierten Geschäftsprozesse in eine Business Process Engine
• Einsatz einer Business Rule Engine
• Serviceorientierte Architektur (SOA)
• Codegenerierung gemäß Model-Driven Architcture (MDA)
als auch die Prozesse zur Lösungsentwicklung
• Projektmanagement gemäss SCRUM
• Requirements Engineering (RE) und Geschäftsprozessmodellierung (Business Process Modelling, BPM) als gleichberechtigte Verfahren zur Spezifikation
• Implementierung auf Basis der Geschäftsprozessmodelle
• Testdurchführung auf Basis der Requirements
• Automatisierte Regressionstests
Die Ergebnisse und Erfahrungen aus den pilotierten Prozessen werden wesentlich die zentralen Prozessvorgaben beeinflussen, auch im Hinblick auf die Zertifizierung gemäss CMMI Maturity Level 3, welche Credit Suisse für 2010 plant.
Dieser Beitrag beschreibt die bisherigen Erfahrungen von Credit Suisse aus der Pilotierung im Bereich Requirements Engineering und Geschäftsprozessmodellierung.
2 Die Herausforderung
Zu Beginn des erwähnten Projektes sprachen die Experten für BPM und SOA über Begriffe wie Business Process, Business Rule, Business Service, IT Service oder Business Object. In den von den Experten ausgearbeiteten Metamodellen gab es den Begriff „Anforderung“ nicht.
Gemäß der Planung dieser Experten sollten die Prozessbeschreibungen z.B.
Ausführungen enthalten, was unter einem Business Process oder einer Business Rule zu verstehen sei, welche Arten von IT Services es gibt und wie Modelle des Computation Independent Model (CIM) zu transformieren sind in Modelle des Platform Independent Model (PIM) und Platform Specific Model (PSM)1. Die Prozessbeschreibungen hätten jedoch keine Ausführungen enthalten darüber, wie Anforderungen an das zukünftige System systematisch zu erheben, zu dokumentieren und zu verwalten, der Projektumfang zu definieren, zu verhandeln und zu vereinbaren, das Projekt auf Basis der Anforderungen zu planen oder die Anforderungen in Modelle zu transformieren sind.
Aus den Gesprächen mit dem Fachbereich erarbeiteten die Experten für BPM und SOA Modelle für Geschäftsprozesse oder Geschäftsobjekte, dokumentierten jedoch nicht die den Modellen zugrundeliegenden Anforderungen. Dies sahen die Experten für BPM und SOA als redundante Nacharbeit und mithin überflüssigen Aufwand an. Auf diese Weise war z.B. die Entstehungsgeschichte und Begründung von Modellen im besten Fall unvollständig rekonstruierbar. Dies erschwerte u.a. Verhandlungen mit dem Fachbereich über den geforderten Projektumfang.
1Die Begriffe Computation Independent Model, Platform Independent Model und Platform Specific Model sowie die Abkürzungen CIM, PIM und PSM entstammen [OMG03]. Dort sind auch die Bedeutungen der Begriffe eingehend erläutert.
Es entstand der Eindruck, dass den Experten für BPM und SOA der Einsatz bewährter Verfahren des RE unbekannt, zu aufwändig oder nicht sinnvoll erschien. Die Experten für BPM und SOA sahen nicht die Notwendigkeiten des Projektmanagements (z.B.
Verhandlung von Anforderungen mit dem Fachbereich auf Basis geschätzter Kosten) und des Qualitätsmanagements (z.B. anforderungs-getriebener Test).
Die Herausforderung bestand darin, bei den Experten für BPM und SOA das Verständnis zu wecken für den Sinn und die Notwendigkeit eines systematischen RE.
Weiters war es erforderlich, ein Modell und ein Vorgehen zu finden, welches die Bedürfnisse von BPM/SOA auf der einen und RE auf der anderen Seite abdeckt.
3 Der Lösungsansatz
Dieser Beitrag versteht unter Requirements Engineering sämtliche Tätigkeiten, welche erforderlich sind, um (Produkt- und Projekt-) Anforderungen zu erheben,zu analysieren, zu verstehen und zu dokumentieren. Dies betrifft Anforderungen an alle Arten von Ergebnissen, nicht nur Anforderungen an Geschäftsprozesse oder IT-Systeme.
Business Process Modelling ist diejenige Lösungsdisziplin, welche Anforderungen an Geschäftprozesse umsetzt in Modelle, welche auf konzeptioneller Ebene die Geschäftsprozesse beschreiben, die eine Lösung für diese Anforderungen sind.
Die Integration der beiden Disziplinen RE und BPM besteht in der Zusammenführung der beiden Sichten auf Systementwicklung in ein dreidimensionales Modell und die Positionierung von RE als diejenige Disziplin, welche die Grundlagen dafür liefert, dass BPM die richtigen Geschäftsprozesse konzipiert.
3.1 Drei Dimensionen der Systementwicklung
Credit Suisse verwendet in dem erwähnten Projekt die dreidimensionale Sicht auf die Systementwicklung, welche Forsberg und Mooz in [FM91] einführten unter dem Namen Vee-ModelundVee-Chart. Die drei Dimensionen sind
• Abstraktionsebenen, in Abb. 1 dargestellt in der senkrechten Dimension. Credit Suisse verwendet die Ebenen Business Request, CIM, PIM, PSM und Implementierung2.
• Anforderungen, Rahmenbedingungen und Überprüfung deren Erfüllung, in Abb. 1 dargestellt in der waagrechten Dimension. Credit Suisse verwendet u.a.
die Konzepte Request, Feature und Requirement, dokumentiert in Request- und Anforderungslisten. MS Excel kommt hierbei genauso zum Einsatz wie einschlägige Werkzeuge für das RE.
2Zur Erläuterung der Akronyme CIM, PIM und PSM verweisen wir auf [OMG03]
• Ergebnisse / Produkte / Lösungen, in Abb. 1 senkrecht zum Papier zu denken und angedeutet durch die schräggestellt gezeichnete Matrix. Credit Suisse verwendet die Ergebniskategorien Geschäftsprozess, Daten, Services, Regeln.
Forsberg und Mooz sprechen von Konfigurationseinheiten statt von Ergebnissen, Produkten oder Lösungen.
Das Vee-Model beschreibt auf der linken Seite des „V“ die schrittweise Verfeinerung der Anforderungen an ein Produkt über die verschiedenen Abstraktionsebenen hinweg bis hinunter auf eine Granularität, in welcher die Implementierung möglich wird. Auf der rechten Seite des „V“ beschreibt das Vee-Model die schrittweise Integration des Produkts aus seinen Komponenten über die Abstraktionsebenen hinweg, sowie die Verifikation der Funktionalität anhand der auf der jeweiligen Ebene ermittelten Anforderungen. Die Vereinbarung des Funktionsumfangs mit dem Fachbereich findet zu zwei Zeitpunkten im Projekt statt: Das erste Mal nachdem die Business Requests
Anforderungen, Rahmenbedingungen & Abnahme
Abstraktionsebene
Ergebnis/ Produkt/ Lösung
Business Request
CIM - Computation Independent Model
PIM - Platform Independent Model
PSM – Platform Specific Model
Implementation Integration auf PSM-Ebene
Integration auf PIM-Ebene
Integration auf CIM-Ebene
Integration auf Ebene Bus.Rqst.
Definition,
Dekom positio
n, Verei
nbar ung
"Trace To"
Integration,Verifikation, Abnahme
1. Vereinbarung
2. Vereinbarung
Abbildung 1: Anforderungs-orientierte Sicht auf die Systementwicklung
= Blick auf die Systementwicklung gemäß [FM91] durch die Brille von Experten für RE
verstanden und angemessen dokumentiert sind. Das zweite Mal nachdem die CIM- Modelle ausreichend weit fortgeschritten erstellt wurden.
Auf jeder Abstraktionsebene gibt es sowohl Anforderungen als auch Lösungen für diese Anforderungen. Dies ist angedeutet durch die dritte Dimension, welche man sich senkrecht zum Papier stehend denken muss. Sie ist in Abb. 1 angedeutet durch die schrägstehende Matrix und den Pfeil „Ergebnis / Produkt / Lösung“. Abb. 2 zeigt diese Matrix als Hauptaspekt. Kapitel 3.2 enthält ein Beispiel.
"Lösungen" auf den Ebenen CIM, PIM und PSM meint Modelle und Konzepte, welche auf der Ebene CIM z.B. die Umsetzung von Marktanforderungen in Geschäftsprozesse beschreiben und auf der Ebene PIM die IT-Unterstützung für diese Geschäftsprozesse.
"Lösungen" auf den Ebenen CIM, PIM und PSM sindnichtImplementierungen in einer konkreten Programmiersprache.
Der fundamentale Zusammenhang zwischen den Modellen und Konzepten einer Ebene und den Anforderungen aller darunter liegenden Ebenen ist wie folgt:
Anforderungen, Rahmenbedingungen
&Abnahme
Abstraktionsebene
Ergebnis, Produkt, Lösung
Implementation PSM
PIM
Geschäfts- prozess Daten Services Regeln
Business Request CIM Abstraktions ebene
Ergebnis kategorie
Abbildung 2: Lösungs-orientierte Sicht auf die Systementwicklung
= Blick auf die Systementwicklung gemäß [FM91] durch die Brille von Experten für BPM/SOA:
Die drei Dimensionen des Vee-Model gedreht
um 90 Grad im Uhrzeigersinn um die Achse der Abstraktionsebenen
Die Einhaltung der Modelle und Konzepte der übergeordneten Ebenen ist implizit eine Anforderung an die Lösungen aller darunter liegenden Ebenen.
Die Abbildungen 1 und 2 zeigen und definieren anhand des Vee-Model aus [FM91] die anforderungs- und die lösungsorientierte Sicht auf die Systementwicklung.
3.2 Ein Beispiel Abstraktions-
ebene Anforderung Lösung
Business Request Der Fachbereich benötigt Unterstützung für die Abwick- lung von Geschäften mit physischen Schweizer Namen- aktien
Entscheid des Fachbereichs, die Durchführung von Lieferauf- trägen von Namenaktien als ei- genständigen Geschäftsprozess zu betrachten.
Computation Independent Model (CIM)
Der Geschäftsprozess ‘Liefer- auftrag Namenaktie durch- führen‘ muss umfassen, die notwendigen Kundendokumente zu erzeugen
EPK des Geschäftsprozess
‚Lieferauftrag Namenaktie durchführen‘. Dieses EPK ent- hält die Funktion ‚Kundendo- kumente erzeugen‘.
Platform Independent Model (PIM)
Das System muss diejenigen Kundendokumente erzeugen, deren Dokumenttypen das System zuvor aus den Liefer- instruktionen des Kunden er- mittelt hat
EPK der Funktion ‚Kundendo- kumente erzeugen’. Dieses EPK enthält die Aufrufe der IT Services ‚Liste der Kundendo- kumenttypen berechnen’ und
‚Kundendokumente drucken’
Platform Independent Model (PSM)
• System muss OraBPM als Process Engine verwenden
• Das Projekt muss XPDL verwenden um EPK in die OraBPM-interne Prozess- darstellung zu transfor- mieren
• Das Projekt muss
berücksichtigen, dass ARIS und OraBPM den XPDL Standard unterschiedlich interpretieren
XPDL-Datei für die Funktion Kundendokumente erzeugen‘, exportiert aus ARIS und angepasst an die OraBPM Import-Funktionlität
Implementierung Die von der XPDL-Datei
beschriebende Funktionalität Die nach dem Import der Datei in die OraBPM von OraBPM erzeugte interne Repräsentation
3.3. Nutzen der gewählten Lösung
Mit dem beschriebenen Vorgehen wurde es möglich,
• zu erklären, dass Experten für RE und Experten für BPM/SOA aus unterschiedlichen Blickwinkeln auf das zu entwickelnde System schauen.
• den Experten für BPM und SOA zu erläutern, dass RE ein wesentlicher Bestandteil ihrer Arbeit auch dann ist, wenn sie die Anforderungen nicht ausdrücklich dokumentieren oder Anforderungsanalyse (noch) nicht als Bestandteil ihrer Tätigkeit sehen. [HFW07] zeigt ebenfalls diesen Aspekt auf
• zu erklären, weswegen die Metamodelle für BPM und SOA den Begriff
„Anforderung“ nicht enthalten: Diese Metamodelle beziehen sich lediglich auf die zweidimensionale Sicht der Experten für BPM/SOA, bestehend aus den Dimensionen Abstraktionsebene und Ergebnis/Produkt/Lösung.
4 Erfahrungen aus der Anwendung der Konzepte
4.1 Anforderungs-orientierte Sicht als temporäre Sicht während der Projektarbeit, lösungs-orientierte Sicht als dauerhafte Sicht über den Lebenszyklus hinweg Aus der Erfahrung von Credit Suisse hat es sich als wenig praktikabel erwiesen, Anforderungen in Anforderungslisten in vollem Detaillierungsgrad auszuformulieren und über den gesamten Lebenszyklus eines IT Systems hinweg zu pflegen und aktuell zu halten: Je weiter die Spezifikationsarbeit voran schreitet, umso mehr liegt der Fokus auf der unmittelbaren Arbeit an Modellen. Die ursprünglich in Anforderungslisten aufgeschriebenen Texte müssten aufwändig und sogar redundant nachgepflegt werden.
Die Motivation der Mitarbeiter für derartige Pflege ist eher wenig ausgeprägt. In manchen Situationen eignen sich Modelle schon für den Einstieg in die Analysearbeit besser als textuelle Repräsentationen von Anforderungen.
Daher verwendet Credit Suisse Anforderungslisten lediglich als Mittel zur Strukturierung und Planung der Spezifikationstätigkeit innerhalb eines Projektes.
Anforderungslisten verlieren ihre Bedeutung nach Projektabschluss. Bedeutung über den Projektabschluss hinaus hat die lösungsorientierte Sicht, also die Produktspezifikationen.
Nachteil dieses Vorgehens ist, dass die Begründungen und Quellen für eine bestimmte Modellierung nicht vollständig nachvollziehbar sind. Die Granularität der Historienführung bei den Modellen ist nicht geeignet, jedes Detail der Anforderungsklärung und jeden detaillierten Entscheid auch so detailliert zu
protokollieren. Hier sind die Möglichkeiten eines einschlägigen Requirement-Werkzeugs deutlich höher. Derzeit gewichtet Credit Suisse diesen Nachteil jedoch geringer als den Vorteil der geringeren Redundanz zwischen Modellen und Anforderungslisten.
Abbildung 3 zeigt den geschätzten Grad an Vollständigkeit der Anforderungslisten in dem eingangs erwähnten Projekt. Auf der Ebene CIM z.B. wurden nur 30-60% der Anforderungen an Geschäftsprozesse in den Anforderungslisten dokumentiert. 40-70%
der Anforderungen an die Geschäftsprozesse wurden jedoch nie in die Anforderungslisten eingetragen. Stattdessen setzten die Geschäftsprozessingenieure nach der Anforderungsanalyse diese 40-70% der Anforderungen direkt um in Geschäftsprozessmodelle. Auf den Ebenen PIM und PSM liegt der Anteil der nicht in Anforderungslisten dokumentierten Anforderungen noch deutlich höher. Diese Schätzung ist spezifisch für dieses Projekt zum Zeitpunkt der Erstellung dieses Beitrags.
Die Schätzung kann anders ausfallen sowohl in anderen Projekten und Unternehmen als auch zu späteren Zeitpunkten im gleichen Projekt.
Um die Vollständigkeit der Umsetzung von Anforderungen in Produktspezifikationen prüfen zu können, setzt Credit Suisse Traceability ein.
4.2 Auswirkung der Erfahrungen auf Projektplanung, Kostenschätzung und Test Ursprünglich plante das Test Team, die Anforderungslisten als Basis für die Ableitung von Testfällen zu verwenden. Dies vor allem, weil zwischen Requirements-Werkzeug und dem Werkzeug für das Testmanagement eine Schnittstelle für die automatisierte Übernahme von Anforderungen existiert und funktioniert. Wie erwähnt sind die Anforderungslisten nicht mehr zwingend vollständig und existieren auch nicht in dem
40 – 70 % 60 – 90 %
80 – 95 %
CIM
PIM
PSM
'Business-View'
RE &
Sol.Eng.
Sol.Eng.
30 – 60 %
10 – 40 %
5 – 20 %
2. Vereinbarung 1. Vereinbarung
Undokumentierte Anforderungen Undokumentierte Anforderungen
Anforderungs- datenbank
Explizit= dokumentierte Anforderungen
Abbildung 3: Geschätzter Grad der Vollständigkeit von Anforderungslisten in einem ausgewählten Projekt bei Credit Suisse
Detailgrad, welcher für die Ableitung von Testfällen erforderlich wäre. Ein alternatives Vorgehen ist deswegen erforderlich und wird derzeit ausgearbeitet. Es bietet sich an, die Testfälle aus den Modellen abzuleiten. Eine Schnittstelle zur automatisierten Übernahme von Modellen in das Werkzeug für das Testmanagement ist derzeit jedoch nicht bekannt.
Ähnliches gilt für die Kostenschätzung. Die Projektleitung wünscht für die Verhandlungen mit dem Projektauftraggeber eine Kostenschätzung pro Anforderung.
Derart geschätzte Kosten, über alle Anforderungen der Anforderungsliste summiert, würden jedoch nicht die Gesamtkosten beziffern. Eine Kostenschätzung auf Basis der Produktspezifikationen erscheint unumgänglich, könnte jedoch weniger leicht mit dem Fachbereich verhandelbar sein. Das am Ende geeignete Verfahren ist noch nicht festgelegt.
Die Projektleitung hat für ein Vorgehen gemäss SCRUM entschieden. Dies nicht nur für die Programmierung, sondern auch dort, wo es um die Erstellung von Modellen und anderer Dokumentation geht. Ursprünglich war angedacht, die Inhalte jeder Iteration auf Basis von Anforderungen zu planen. Es zeigt sich, dass die Mitarbeiter eine Iterationsplanung auf Basis von zu implementierenden Produktspezifikationen bevorzugen.
4.3 Wie passen Use Cases zu Geschäftsprozessmodellierung und SOA?
Zu Beginn des Projektes überwog die Ansicht, dass der Begriff „Use Case“ seine Bedeutung verliert, wenn Geschäftsprozesse so weit ausmodelliert werden, dass sie automatisch in eine Business Process Engine transformierbar sind und noch im Modell mit IT Services verknüpft werden können. Gestützt hat diese These Ivar Jacobson anlässlich eines Referates bei Credit Suisse. Er vertrat die Ansicht, dass „Business Process“ und „Business Use Case“ synonym verwendbare Begriffe sind. Denkt man diese Analogie weiter, könnte man das aus [COCK05] bekannte Konzept "System Use Case" auch "System Process" nennen. Ungewöhnlich zwar, aber möglich. Credit Suisse hat entschieden, von "Business Process" (gibt es auf Ebene CIM und PIM) und
"(System) Use Case" (gibt es auf Ebene PIM) zu sprechen.
• Erfahrene Geschäftsprozessmodellierer bei Credit Suisse ziehen eine Analogie zwischen der Spezifikation eines System Use Case mittels EPK und der grafischen Modellierung der in einer Java-Methode programmierten Funktionalität z.B. mittels Sequenzdiagrammen: Einen System Use Case sollte man textuell beschreiben.
• Die Integration von Geschäftsprozessmodellen, anderen Modellen und Process Engines ist nicht nahtlos, die Umsetzung der Visionen von SOA daher noch nicht möglich. Also gibt es derzeit nicht die Notwendigkeit, im EPK auch diejenigen Details einschliesslich der aufgerufenen IT Services zu modellieren, die Credit Suisse derzeit in Use Case Spezifikationen textuell beschreibt.
• In der Methodik der Credit Suisse ist der Begriff „Use Case“ tief verankert. Auf ihn zu verzichten hätte einer umfänglichen Überzeugungsarbeit bedurft, welche angesichts der bereits erwähnten Argumente, insbesondere der nicht nahtlos
miteinander integrierten Modelle und Process Engines, schwierig zu leisten gewesen wäre.
5 Zusammenfassung
Die Erfahrungen von Credit Suisse deuten darauf hin, dass produkt-orientierte Spezifikation von Anforderungen den Erfordernissen der Lösungsentwicklung im Umfeld von BPM und SOA besser gerecht wird als eine detaillierte textuelle Ausformulierung von Anforderungen in Form von Anforderungslisten. Trotzdem helfen Anforderungslisten, den Prozess der Anforderungsspezifikation zu planen und zu strukturieren. Insofern ergibt es weiterhin Sinn, eine anforderungs-orientierte und eine lösungs-orientierte Sicht voneinander zu trennen und das Sammeln von Anforderungen als Aktivität in der Lösungsentwicklung nicht nur zuzulassen, sondern einzufordern.
Noch nicht vollständig abgeschlossen sind bei Credit Suisse die Überlegungen, welche Konsequenzen sich aus dieser Erkenntnis für die Organisation von Tests, die Kostenschätzung, deren Verhandlung mit dem Auftraggeber, und die Projektplanung ergeben. Entsprechende Erfahrungen wird Credit Suisse anlässlich des geplanten Workshops jedoch berichten können.
Literaturverzeichnis
[COCK05] Alistair Cockburn, "Writing Effective Use Cases", Addison-Wesley, 2005
[FM91] Kevin Forsberg, Harold Mooz, “The Relationship of System Engineering to the Project Cycle”, presented at the joint conference sponsored by: National Council On Systems Engineering (NCOSE) and American Society for Engineering Management (ASEM), Chattanooga, TN, 21–23 October 1991, abrufbar
http://www.csm.com/repository/model/rep/o/pdf/Relationship% 20of% 20SE% 20to% 20 Proj% 20Cycle.pdf
[HFW07] Andrea Herrmann, Ralf Fahney, Rüdiger Weißbach, “Wie viel Requirements Engineering steckt im Software Engineering” im gleichnamigen Workshop, Hamburg, Deutschland, März 2007, abrufbar:
http://www.repm.de/docspublic/SE2007workshop/Wieviel_RE_StecktIm_SE_onlinev ersion.pdf
[OMG03] Joaquin Miller, Jishnu Mukerji, "MDA Guide Version 1.0.1", 2003, abrufbar:
http://www.omg.org/docs/omg/03-06-01.pdf
