Wer hat schon mal von "RE" gehört - Requirements Engineering? - Die etwa 30 Teilnehmer des BPM-Club-Treffens am 18.10.16 in Nürnberg wissen nun etwas mehr über "RE", genauer: wie dieses Thema konzernweit bei Stadtwerke München (SWM) eingeführt wird. Lesen Sie hier die Teilnehmerstimmen: https://www.xing.com/communities/posts/nachbericht-konzernweites-requirements-engineering-bei-stadtwerke-muenchen-nuernberg-18-punkt-10-punkt-1012101523

1. Case Study: Einführung Konzernweites Requirements
Engineering bei den Stadtwerken München

2. Warum haben die SWM ein einheitliches
Vorgehen für RE definiert?
19.10.2016 RE@SWM2

3. Kurzvorstellung SWM
Die SWM stehen für eine zuverlässige, sichere Versorgung mit
Strom, Fernwärme, Erdgas und Wasser
Mitarbeiter rund 9.700 – zentrale IT, TK, Prozesstechnik über 550
Die Stadtwerke München sind sehr breit aufgestellt
19.10.2016 RE@SWM3
Kunden mehr als 1,2 Millionen
Mitarbeiter rund 9.700
Umsatz 2015 rund 6,5 Milliarden Euro
Stromnetz rund 12.000 km
Fernwärmenetz rund 800 km
Erdgasnetz rund 6.000 km
Wassernetz rund 3.200 km
Verkehrsnetz rund 636 km
Fahrgäste mehr als 1,5 Millionen pro Tag

4. Kurzvorstellung SWM
 Jeder Punkt entspricht einem
System, Kanten stellen (bekannte,
dokumentierte) Datenflüsse dar.
 Die „Musik“ spielt in dem
komplexen Systemverbund in
der Mitte.
 Änderungen an einem System
haben oft Einflüsse auf andere
Systeme.
 Anforderungen müssen hier
sorgfältig durchdacht werden
 Anforderungen müssen klar und
für alle Beteiligten verständlich
beschrieben werden
Als Ergebnis ist die IT sehr komplex …
19.10.2016 RE@SWM4

5. Herausforderungen an ein konzernübergreifendes RE
Was sind die Konsequenzen der hohen Heterogenität?
 Feste Zuordnung von Entwicklern zu Fachbereichen: Heterogene
Fachbereiche erfordern fachlich und „kulturell*“ viele stark spezialisierte – und
damit nicht flexibel einsetzbare – Entwickler
 Status Quo, skaliert nicht, problematisch bei wachsendem Ressourcendruck
 „Springen“ von Entwicklern zwischen Fachbereichen: „kulturfremder“
Einsatz von IT-Kollegen resultiert in hohen Reibungsverlusten („verstehe
Fachbereich nicht“, „ständiges Neuausbilden der IT“)
Abhilfe?
 Nutzung von RE als „Lingua Franca“, d.h. als gemeinsame konzernweit
akzeptierte Basis, die nahe am Fachbereich ist und zugleich ausreichend präzise
Anforderungsbeschreibungen erlaubt.
 RE als Dolmetscher in alle Richtungen
 Spezialisierung auf „Kulturräume“ statt Fachlichkeit oder Technik (kann man lernen)
Im Kontext von IT Projekten ist ein heterogenes Setup problematisch
19.10.2016 RE@SWM5

6. Was sind die Grundideen von RE@SWM?
19.10.2016 RE@SWM6

7. Vorgehensmodell: Checklisten & Cherry Picking
Große Organisationen erfordern Standards in der Art und Weise, wie
Anforderungen an ein IT-System strukturiert beschrieben werden
 Klares Informationsmodell
 Was ist wo wie beschrieben?  Fachkonzept und Technisches Konzept
 Wer ist für was verantwortlich?  Funktion des „Requirements Engineers“,
Architekten
 Klare Anforderungen an die Inhalte und Form von Fachkonzepten
 Vorgabe zu betrachtender Sichten auf ein System (Was wird beschrieben?)
 Vorgabe verbindlich zu nutzender Notation (Wie wird es beschrieben?)
 Vereinfachte Les- und Prüfbarkeit, Vergleichbarkeit herstellen
Die (zentrale) IT benötigt – konzernweit! – gute
Anforderungen, um effizient arbeiten zu können.
19.10.2016 RE@SWM7
Standardisierung verbessert Vollständigkeit („Checklisten“) und Qualität
(„Standardmodelle“ statt Prosa) von Anforderungen und Fachkonzepten.

8. Vorgehensmodell: Checklisten & Cherry Picking
Unser Informationsmodell fokussiert auf funktionale
Blöcke (aka Fachkomponenten), nicht Projekte
19.10.2016 RE@SWM8
Businesss
Cluster 2
Fachkom-
ponente 1
Fachkom-
ponente 2
Fachkom-
ponente 3
Fachkom-
ponente 4
Fachlicher
Überblick
Fachkonzept 1 Fachkonzept 2 Fachkonzept 3 Fachkonzept 4
Business Custer beschreiben komplexe
IT-Systeme, die einen betriebswirt-
schaftlichen Sachverhalt abbilden.
Wiederverwendbare Fachkomponenten
sind die Building Blocks eines Business
Clusters
Der Fachliche Überblick beschreibt den
Aufbau des Clusters
 Kernziel „Wegweiser zu
Fachkomponenten“
Jede Fachkomponente wird detailliert in
einem eigenen Fachkonzept mittels
Bausteinen beschrieben.

9. Vorgehensmodell: Checklisten & Cherry Picking
 Was soll in einem Fachkonzept
beschrieben werden?
 Idee: Definition eines Standards, der
definierte Aspekte einer
Fachkomponente beschreibt
 Prozess: BPMN 2
 Datenmodell: UML-Klassendiagramme
 Anwendungsfälle: Use Cases
 Masken: Scribbles
 Berichte: definierte KPIs & Layout
 Nutzerperspektive: Tabelle mit
Rollen & Rechten
 Qualitätsanforderungen: Checkliste
 etc.
 Notation? Die Beste für den Zweck!
Standardisierte „Bausteine“ (Inhalt & Notation)
beschreiben die Aspekte einer Fachkomponente
19.10.2016 RE@SWM9
Bausteinliste dient als „Checkliste“
 Worüber sollte bei der Erhebung
von Anforderungen grundsätzlich
nachgedacht werden?
Die Bausteine unterstützen damit den RE
(An was sollte ich (mindestens!) noch
denken?)
 Zu jedem Baustein gibt es eine
„Anleitung“, die
 Zweck und Nutzungskonzept,
 Input und weitere Verwendung,
 Inhalte und Notation sowie
 ein Beispiel enthält
Die Bausteine standardisieren damit, was
wie definiert wird.

10. Bausteinliste
dient als
„Checkliste“
Auch komplexe Systeme sind aus kleinen Teilen aufgebaut!
19.10.2016 RE@SWM10
Prozesse
BPMN 2.0
Nutzerperspektive
Tabellen, Checkliste
Datenmodell
Klassendiagramm
Anwendungsfall
Use Case
Maskendefinition
Scribbles
Druckstück
Templates
Qualitäts-
anforderungen
Checkliste
Fachlicher Überblick
UML Komponen-
tendiagramm
Fachkonzept
Prozesse
Nutzerperspektive
DatenmodellAnwendungsfall
Maskendefinition Druckstück
Qualitäts-
anforderungen
…
Prozesse
DatenmodellAnwendungsfall
Maskendefinition Druckstück
…
Prozesse
DatenmodellAnwendungsfall
Maskendefinition Druckstück
…
Vorgehensmodell: Checklisten & Cherry Picking

11. Einführung – Per Anweisung? Eher nicht …
Was funktioniert es bei den SWM?
 Begeisterte finden! Nicht nur in der IT!
 Gemeinsam Methode für die SWM entwickeln
 Vorgesetzte überzeugen
 Organisatorische Verantwortung für die Methode definieren:
Die RE Leitungsrunde
 Coachen & Überzeugen, Success Stories erzählen!
 Coachen & Überzeugen , Success Stories erzählen!
 …
Was hat nicht funktioniert?
 Richtlinien, Arbeitsanweisungen, GF-Beschlüsse:
Wir sind im Dschungel der Kompetenzen untergegangen
19.10.2016 RE@SWM11
Vorgehensmodell: Checklisten & Cherry Picking

12. Welche Anforderungen bestehen
an die Werkzeugunterstützung?
19.10.2016 RE@SWM12

13. Tooling – Woher kommen die Anforderungen?
Baustein-Konzept definiert, was wir wie dokumentieren wollen
 (Textuelle) Anforderungen
 UML2-Diagramme
 BPMN2-Diagramme
 Erfassen von Spezifikationstexten zu allen Elementen
Nachhaltige Spezifikation – Repository-Ansatz …
Bislang verfolgten die SWM einen Dokumenten-basierten Ansatz; dies führt leider oft zu
„veralteten Dokumenten“. Eine nachhaltige Dokumentation erfordert einen klar definierte
„Quelle der Wahrheit“ – also ein Spezifikations-Repository, wobei …
… und zugleich Dokumentenexport
… unsere Stakeholder stark an Dokumenten-basierte Reviews gewöhnt sind. Ein
unmittelbarer flächendeckender Wechsel zu einem rein Repository-basierten Ansatz ist daher
schwierig.
Die Methode RE@SWM definiert die Anforderungen an das Tooling –
MID hat sich in einem Ausschreibungsverfahren durchgesetzt
19.10.2016 RE@SWM13

14. Tooling – Woher kommen die Anforderungen?
Elektronische Publikation von Spezifikationen
 Einfacher Zugang zu Systemspezifikationen
ohne Expertenwissen für komplexe
Modellierungstools erforderlich
 Abhängigkeiten zwischen Elementen müssen
nachverfolgbar sein
Review-Support ist dort erforderlich
 Aktualisierte oder neue Spezifikationselemente
müssen über das Tooling einem Review
unterzogen werden können
 Insbesondere im Kontext von
Weiterentwicklungen ist eine Versionierung und
Vergleichsfunktionen verschiedener Versionen
erforderlich
Mittelfristig wollen wir auf Dokumente verzichten
19.10.2016 RE@SWM14

15. MID Innovator und smartfacts stellen wesentliche
Werkzeuge zur Unterstützung von RE@SWM dar!
19.10.2016 RE@SWM15

16. Tooling – Innovator & smartfacts
 Im Rahmen eines Ausschreibungsprozesses konnte sich MID mit dem Tandem
aus Innovator als Modellierungstool (Experten, Modellerstellung) und
smartfacts zur Publikation der Spezifikationen (Konsumenten, Reviewgeber)
durchsetzen
 Im ersten Quartal 16 wurde Innovator durch MID Berater entsprechend der
Methode RE@SWM konfiguriert (incl. Dokumentenexport)
 Wir konnten unsere Methode ohne Anpassung am Tool selbst zu 95%
umsetzen. Das hat unsere Erwartungen übertroffen!
 Wir generieren unsere Fachkonzepte entsprechen unserer Methode
RE@SWM und der zuvor definierten Templates direkt aus Innovator.
 MID wird bei den SWM seit 04/16 produktiv genutzt, aktuell haben wir gerade
Version 13 eingeführt. Unsere Erfahrungen seitdem sind sehr positiv!
 Flächendeckender Einsatz? Nein, aber es wird beständig mehr!
MID Innovator und smartfacts haben die SWM überzeugt;
die Tools werden seit einem halben Jahr produktiv genutzt
19.10.2016 RE@SWM16

17. Tooling – Woher kommen die Anforderungen?
Zweck: Erstellung von Modellen
Anwender: Experten (Requirements Engineers)
 Kleiner, definierter Personenkreis
 In-House Schulungen nach Train-the-Trainer Schulung von MID
Kernfeatures
 UML- und BPMN-Modellierung ebenso …
 … wie textuelle Spezifikationen und Anforderungen
 Dokumentenexport
Innovator ist das empfohlene Modellierungstool der SWM
19.10.2016 RE@SWM17

18. Repository, Dokumente, kontinuierliche Pflege von Modellen
 Schritt 1: Nutzung von Innovator zur
Modellierung
 Innovator wird ausgerollt, die
Kollegen nutzen Innovator zur
Modellierung, Fachkonzepte werden
(teils) konventionell
(aka Word) erstellt.
 Schritt 2: Konsequente Nutzung des
Repositories
 Etablierung der Nutzung des
Repositories erfordert ein
langfristiges Engagement
 Qualitätskontrolle erforderlich
 Mittelfristig: Verzicht auf Dokumenten-
zentrierten Ansatz?
Quo Vadis RE-Informationsmodell? Fachkonzept vs. Repository
19.10.2016 RE@SWM18

19. Tooling – Woher kommen die Anforderungen?
Zweck: Recherche, Lesen und Kommentieren (Review) von Modellen
Anwender: Konsumenten von Spezifikationen (Entwickler und Fachexperten)
 Vielzahl von Nutzern
 Gelegenheitsnutzer; Tool muss selbsterklärend sein
Kernfeatures
 Publikation
 Versionierung
 Impact Analyse
 Kommentierung und Reviews
 Traceability über Modelle hinweg
smartfacts dient zur Publikation, Recherche und Review
von Modellen (Spezifikationen)
19.10.2016 RE@SWM19

20. Repository, Dokumente, kontinuierliche Pflege von Modellen
Stärken von smartfacts – Voll nutzbar bei gefülltem Repository
19.10.2016 RE@SWM
Wasleistet
smartfacs?
• Recherche – „Google
für Modelle“
• Versionierung mit
graphischen Versions-
vergleichen
• Verknüpfungen und
Impact Analyse
• Kommentierung und
Review-Support
Wiewollenwirdiese
Featureseinsetzen?
• Auffinden bestehender
Services
• Nachvollziehen von
Änderungen an der
Fachlichkeit
• Beziehungen zwischen
Fachlichkeit und Technik
darstellen - Traceability
• Erfassen von
Änderungswünschen
direkt am Modell
20

21. Repository, Dokumente, kontinuierliche Pflege von Modellen
Herausforderung & Potential:
 Anforderungen aus Fachkonzepten sind häufig
im technischen Konzept nicht direkt
nachvollziehbar (fehlende Traceability)
 Über smartfacts können diese
Beziehungen definiert werden
 Direkte (..) technische Weiterverarbeitung
der BPMN-Modelle in WF-Engine
… in Arbeit
 Migration bestehender Modelle nach
Innovator / smartfacts … in Arbeit
 Beziehungen zu UAM-Modellen in pIT
 Beziehungen zu ITSM Service Landschaft
Ausblick: Ausweitung von RE@SWM auf Schwester-
disziplinen (Innovator und / oder smartfacts)
19.10.2016 RE@SWM21

22. Zusammenfassung
19.10.2016 RE@SWM22

23. Summary
 Die SWM sind heterogen aufgestellt. Die Einführung einer konzernweit gültigen
Methode ist schwierig. Einiger Weg: Überzeugen, überzeugen, überzeugen …
 Einführung RE verändert Arbeitsweisen – und muss „verkauft“ werden
 Dem Management, durch Darstellung der Effizienz (Kosten & Aufwände)
 Den Anwendern, durch klare Vorgaben, Support, und Darstellung des
individuellen Nutzens
 Durch organisatorische Verankerung des Themas – Es muss Personen
geben, die das Thema im Konzern vertreten, coachen und nachhalten
 Unsere Methode ist pragmatisch, flexibel und leicht erlernbar
 Beschreibung von Systemen durch Bausteine
 Nutzung der “passenden“ Standardnotation (UML Basisdiagramme, BPMN)
 Mit dem MID Innovator und smartfacts haben wir ein Tooling gefunden, dass
unsere Methode und die gelebte Praxis bei den SWM sehr gut unterstützt.
 Wir stehen erst am Anfang die Potentiale auszuschöpfen!
Wo stehen wir, was haben wir gelernt?
19.10.2016 RE@SWM23

24. Vielen Dank für Ihre Aufmerksamkeit.
Haben Sie Fragen?