Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management

Über den Unterschied zwischen Business Analysis und Requirements Engineering & Management REConf Schweiz 2010 IIBA BABOK 2.0 Wortzählung 1729 "Requirement" = 42% von ( Requirement + Business + Solution ) 1469 "Business" = 35% 553 "Business Analysis 243 "Business analyst 126 "Business need 82 "Business Case 59 "Business Process 53 "Business Rule 49 "Business Requirement 7 "Business knowledge 6 "Business principles 291 "Business... 943 "Solution = 23% Seite 2 1

Warum geht es im BABOK dann um Business Analysis und nicht um Requirements Engineering & Management? Weil der BABOK von Requirements Engineering auf der Business Ebene handelt! Seite 3 Ihr Nutzen von dieser Präsentation Sie verstehen warum Menschen über Requirements Engineering sprechen und dabei perfekt aneinander vorbei reden Sie wissen um derartige Missverständnisse und wie sie entstehen Sie können für sich selber unterscheiden Entwerfen Sie eine Lösung und denken über diese Lösung nach? Oder entwickeln Sie Anforderungen? (sei es für die Ebene über oder die Ebene unter der Ihren) Ihnen bleibt bewusst, dass (IT) architekten Stakeholder sind, die Ihre Spezifikationen lesen und verstehen müssen Sie können besser unterscheiden, ob Sie Mitarbeiter benötigen mit Erfahrung im RE&M oder mit Erfahrung in BPMN, EPC, UML, etc. Sie können sich besser mit anderen an der entwicklung Beteiligten verständigen Sie verbessern die Qualität Ihrer Ergebnisse Sie sparen Geld und halten Termine Seite 4 2

Projektbeispiel 1 Automotive OEM / Produkt-Entwicklungsprozess Erheben & Analysieren von Anforderungen an IT- zur Unterstützung eines Teils des Produkt-Entwicklungsprozesses Implementierung geschätzt ein- bis zweistellig Mio EUR Ergebnis: 1200 Anforderungen auf Ebene Platform Independent Model (PIM) und Platform Specific Model (PSM) Ca. 120 Use Case benannt auf Ebene PIM Seite 5 Projektbeispiel 2 Bank / Neuentwicklung Kundenberichtswesen Projektbeginn Entscheidung für konkrete Standardsoftware Entscheidung für neueste Version von GUI-Technologie A Entscheidung für multidimensionale Datenbank Anforderungsanalyse Experten für GUI-Technologie A verfügbar Zusammenspiel zw. GUI-Technologie A & multidim. DB unausgereift Entscheidung für GUI-Technologie B mit erheblichen Nebenwirkungen Geplante Produktivsetzung Seite 6 3

Projektbeispiel 3 Bank / Grundlagen für BPM und SOA The Gap Seite 7 Projektbeispiel 4 Endkunde, Generalunternehmer, Unterauftragnehmer Lastenheft = Grobkonzept vom Endkunden Festpreis Spec & Implementierung Generalunternehmer: Deutlich zweistellig Mio EUR Unterauftragnehmer: Ein- bis zweistellig Mio EUR Change Request Management Pflichtenheft Ca. 150 Use Case-Spezifikationen mit Haupt-, Alternativ- und Ausnahmeszenarien, Screen, Screenflow, sog. Einzelanforderungen Davon ca. 20 vom Unterauftragnehmer UC-Spec unabhängig vom Worksplit zwischen GU und Unterauiftragnehmer Ca. 20 Querschnittskonzepte Ca. 30 Regelwerke Ca. 100 - und Batchschnittstellen Seite 8 4

Methodische Diskussion damals Seite 9 und heute Seite 10 5

V-Modell der entwicklung (Forsberg/Mooz) angeglichen an die OMG Terminologie Geschäftskontext Computation Independent Model (CIM) Platform "Design Independent To" Model (PIM) Integration im Geschäftskontext Platform "Build Specific To" Model (PSM) Implementierung Seite 11 Zachman Framework in OMG Terminologie Ergebnistyp Ebene der Abstraktion Geschäftskontext Daten Prozess Netzwerk Mensch Zeit Ziel Computation Independent Model (CIM) Platform Independent Model (PIM) Platform Specific Model (PSM) Implementierung Betrieb Seite 12 6

2D-Sicht auf V-Modell und Zachman Framework Integration im Geschäftskontext Seite 13 Beispiele Business Glossar Business "Trace Process To" Modell Use Case Akteur Deployment Diagramm Seite 14 7

Zusammenspiel zwischen Requirements Engineering Requirements Engineering auf strategischer Ebene Seite 15 Zusammenspiel zwischen Requirements Engineering Solution Engineering = Lösung entwerfen und dann spezifizieren = Anforderungen (!!!) aufschreiben für nächste Ebene = Requirements Engineering Seite 16 8

Zusammenspiel zwischen Requirements Engineering Lösungsspezifikation wird Anforderung für die nächste Ebene Seite 17 Zusammenspiel zwischen Requirements Engineering Solution Engineering = Lösung entwerfen und dann spezifizieren = Anforderungen (!!!) aufschreiben für nächste Ebene = Requirements Engineering Seite 18 9

Zusammenspiel zwischen Requirements Engineering Lösungsspezifikation wird Anforderung für die nächste Ebene Seite 23 Zusammenspiel zwischen Requirements Engineering Implementierung Seite 24 12

Business Analysis = Requirements Engineering und Solution Engineering auf der Business Ebene Integration im Geschäftskontext Seite 25 Kernaspekte des Unterschieds zwischen Software Engineering und RE&M Software Engineering Durchgeführt auf Ebene PSM und Implementierung, evtl. PIM Ebene Umfasst Solution Engineering im Sinn von IT-Lösungen definieren und validieren. Requirements Engineering & Management Durchgeführt auf jeder Ebene der entwicklung Umfasst per Definition keine Form von Solution Engineering. Die Bedürfnisses anderer Menschen ausdrücken durch IT-Modelle = Wissen, welches Metamodell man verwendet, um IT-e zu spezifizieren Die Bedürfnisse anderer Menschen ausdrücken durch Modelle im Allgemeinen = Wissen, wann man ein Modell und wann man besser Prosa verwendet Mut haben zu fragen Verstehe ich das richtig? Menschen und deren Bedürfnisse verstehen Bedürfnisse anderer Menschen in Prosa ausdrücken Stakeholder einbeziehen Zustimmung von den Stakeholdern erhalten etc. Seite 26 13

Kernaspekte des Unterschieds zwischen Business Analysis und RE&M Business Analysis Beschränkt auf CIM Ebene, evtl. PIM Ebene Umfasst Solution Engineering im Sinn von Lösungen definieren und validieren, welche Bedürfnisse und Ziele des Business erfüllen. Die Bedürfnisses anderer Menschen ausdrücken durch Businessmodelle = Wissen, welches Metamodell man verwendet, um Bedürfnisse des Business auszudrücken Requirements Engineering & Management Durchgeführt auf jeder Ebene der entwicklung Umfasst per Definition keine Form von Solution Engineering. Die Bedürfnisse anderer Menschen ausdrücken durch Modelle im Allgemeinen = Wissen, wann man ein Modell und wann man besser Prosa verwendet Mut haben zu fragen Verstehe ich das richtig? Menschen und deren Bedürfnisse verstehen Bedürfnisse anderer Menschen in Prosa ausdrücken Stakeholder einbeziehen Zustimmung von den Stakeholdern erhalten etc. Seite 27 14