SlideShare ist ein Scribd-Unternehmen logo
© Software Quality Lab www.software-quality-lab.com
Markus Unterauer
Berater
Rückwärts denken, vorwärts handeln:
Requirements Reverse Engineering bei Systemablösen
Title powered by ChatGPT ;-)
© Software Quality Lab www.software-quality-lab.com - 2 -
Improve your Quality
Was sie erwartet
 Herausforderungen und Learnings
aus einem großen Systemablöseprojekt
 100+ Stakeholder*innen
 5 Teilprojekte
 1.000+ PT für Spezifikation
© Software Quality Lab www.software-quality-lab.com - 3 -
Improve your Quality
Herausforderung 1:
Wie erkennt man, dass eine Software abgelöst
werden soll?
© Software Quality Lab www.software-quality-lab.com - 4 -
Improve your Quality
Ist meine Software End-of-Life?
4
Aufwand
Business
Value An der Kennzahl „Business Value
pro Personentag“ erkennt man,
wann ein System sich seinem End-
of-Life nähert.
© Software Quality Lab www.software-quality-lab.com - 5 -
Improve your Quality
 Immer schwierigere/komplexere Erweiterungen
 Gestiegene technische Schuld
 Veraltete Technologie. Mehr und mehr verwendete
Frameworks werden nicht mehr weiterentwickelt.
Entwickler*innen schwer zu bekommen.
 Mehr Fehler
 Abschätzen von Änderungen immer aufwendiger
 …
Learning: Auf sichere Todeszeichen achten
© Software Quality Lab www.software-quality-lab.com - 6 -
Improve your Quality
Learning: Ziele müssen glasklar sein
 Auch Systemablösen brauchen klare, eindeutige, prüfbare Ziele.
 Mögliche Ziele:
„1:1 Ablöse der Funktionen aus Anwender*innensicht des bestehenden
Systems“
„Keller zusammenräumen“ (nicht mehr Benötigtes rausnehmen,
Workarounds und technische Schuld aufräumen)
6
Helfen die Ziele bei
täglichen
Entscheidungen?
© Software Quality Lab www.software-quality-lab.com - 7 -
Improve your Quality
Herausforderung 2:
Keiner kennt mehr die ursprünglichen fachlichen
Anforderungen
© Software Quality Lab www.software-quality-lab.com - 8 -
Improve your Quality
Anforderungen? … Fehlanzeige
 Anwender*innen im
Fachbereich kennen
Anforderungen im Detail nicht,
sondern bedienen nur das
System.
 Keine Dokumentation der
Anforderungen, maximal
verstreute Fehlerberichte und
Change Requests.
8
© Software Quality Lab www.software-quality-lab.com - 9 -
Improve your Quality
Requirements Engineering und Reverse Engineering
zum Rekonstruieren der Anforderungen
9
Fachliche Anforderungen
Architektur
Design
Code
Requirements
Engineering
Reverse
Engineering
© Software Quality Lab www.software-quality-lab.com - 10 -
Improve your Quality
 Versuchung: Entwickler*innen sollen doch einfach ohne
Aufwand für den Fachbereich das Altsystem nachbauen!
 Aber:
 1:1 Ablöse nur selten möglich und tatsächlich gewünscht
 Entwickler*innen kennen das alte System nicht mehr  Ist-Analyse tw.
aufwendiger als Neuspezifikation
 Anforderungsspezifikation erleichtert bzw. ermöglicht Testen.
 Daher: Auch bei Systemablösen müssen zumindest die
wesentlichen fachlichen Anforderungen ermittelt werden!
Learning: Es braucht auch fachliche
Anforderungen!
© Software Quality Lab www.software-quality-lab.com - 11 -
Improve your Quality
Learning: Anforderungen flexibel
dokumentieren
 Wenn Interaktion anders wird:
 User Stories mit Akzeptanzkriterien
 Vorteil: Robust bei Änderungen, flexibel
 Nachteil: Weniger klare Spezifikation
 Wenn Interaktion im neuen System gleich
bleibt:  Strukturierte Use Cases mit
Ablaufschritten
 Vorteil: Genauere Spezifikation
 Nachteil: aufwendig in Erstellung und Wartung, viele
Änderungen
© Software Quality Lab www.software-quality-lab.com - 12 -
Improve your Quality
Learning: Feldbeobachtung ist extrem hilfreich!
Go & See!
© Software Quality Lab www.software-quality-lab.com - 14 -
Improve your Quality
Herausforderung 3:
Keiner kennt mehr das ganze System in der Tiefe
im Detail
© Software Quality Lab www.software-quality-lab.com - 15 -
Improve your Quality
 Bestehende Systeme sind oft über sehr
lange Zeit gewachsen (30 Jahre und mehr)
 Komplex
 Viele Schnittstellen
 Vielen Anwender*innen und Anwendungsfälle
 Viele Kompromisse und technische Schuld
 System ist oft schlecht dokumentiert
 Architekturdokumentation für Überblick fehlt
 Detaildokumentation für Funktionen maximal im Code selbst
 Entwickler*innen kennen nur Ausschnitte
Gewachsene Gewucherte Systeme
[Quelle: Hopkins, Jenkins, „Eating the IT elephant“, 2008]
Systemablösen sind selten
Neuentwicklungen auf der grünen
Wiese, sondern meist komplexe
Systeme in komplexen Umgebungen.
© Software Quality Lab www.software-quality-lab.com - 16 -
Improve your Quality
 Liefert das WIE, teilweise auch das WAS und WER, nicht
aber das WOZU.
 Liefert auch alle Fehler, Kompromisse, Unsauberkeiten mit
(nicht erkennbar).
 Übergreifende Zusammenhänge sind oft nicht erkennbar.
Gerade bei lose gekoppelten Service-Architekturen.
 Sehr zeitaufwendig! Entwickler*innen sind oft knappe
Ressource und können in der Zeit nichts anderes
programmieren.
 Systemanalysen so schreiben, dass alle es verstehen,
gelingt oft nicht (zu technisch, zu feingranular).
Learning: Reverse Engineerings ist
herausfordernd
Diese Lücken füllt
das Requirements
Engineering!
© Software Quality Lab www.software-quality-lab.com - 17 -
Improve your Quality
Reverse Engineering und Übersetzung von Code
 Wie würden Sie einer*einem Stakeholder*in beschreiben, was diese Funktion
macht?
„ChatGPT erklärt mir, was dieser
Code macht!“
© Software Quality Lab www.software-quality-lab.com - 18 -
Improve your Quality
Herausforderung 4:
Fachbereich und Entwicklung sprechen nicht
dieselbe Sprache
© Software Quality Lab www.software-quality-lab.com - 19 -
Improve your Quality
Beispiel für eine Ist-Analyse aus der Praxis
© Software Quality Lab www.software-quality-lab.com - 20 -
Improve your Quality
Learning: Verständlichkeit ist wichtiger als technische
Detailliertheit
Technisch korrekt: „Zuerst wird eine
ganzzahlige Zählervariable i mit 0 initialisiert.
Danach wird von 0 bis 100 aufsteigend
durchiteriert und immer wenn der Wert von i
modulo 2 Null ergibt, wird i in einer neuen
Zeile ausgegeben.“
Vollständig, korrekt und technisch detailliert.
… aber keiner versteht‘s 
20
for (int i = 0; i <= 100; i++) {
if(i % 2 == 0) println(i);}
Verständlich für die Stakeholder*innen:
„Die Funktion listet alle geraden Zahlen bis
100 auf.“
Hier fehlt, dass es bei 0 losgeht, dass jede
Zahl in eine eigene Zeile kommt, dass die
Zahlen aufsteigend aufgezählt werden, dass
es nur ganze Zahlen sind etc. … aber die
Stakeholder*innen verstehen es!
© Software Quality Lab www.software-quality-lab.com - 21 -
Improve your Quality
Verständlichkeit
verständlich für die
Stakeholder*innen
technisch korrekt,
detailliert,
vollständig
© Software Quality Lab www.software-quality-lab.com - 22 -
Improve your Quality
Tipps fürs verständlich Formulieren
 Verwenden Sie nur Wörter, die Fachbereich und
Entwicklung verstehen.
 Sprechen Sie in ganzen Sätzen, nicht in
Schlagwortlisten.
 Vermeiden Sie Abkürzungen (z.B. UI, DB).
 Vergeben Sie Bildunterschriften (z.B. für Screenshots
aus dem Altsystem).
 Vermeiden Sie IT-Fachbegriffe (z.B. Request,
Response, Session, Server, Deployment, …).
 Beschreiben Sie erstmal den Standardfall, lassen Sie
Sonderfälle, Varianten und Error-Handling weg. Das
kommt später.
 Visualisieren Sie mit einfachen (!) Modellen.
22
© Software Quality Lab www.software-quality-lab.com - 23 -
Improve your Quality
Learning: Glossar
 Oft wird derselbe Begriff unterschiedlich verwendet. Das führt zu Missverständnissen,
vermeidbaren Rückfragen und im schlimmsten Fall zu Mängeln am Produkt.
 Das Glossar unterstützt dabei, eine einheitliche Sprache zu sprechen und Begriffe gleich zu
verwenden.
 Spannend wie das Telefonbuch,
aber extrem nützlich!!!
Ein Glossar ist eine Sammlung von Begriffen und
dazugehörigen Erklärungen. In ein Glossar gehören z.B.
Fachbegriffe und Abkürzungen.
Explain it like
I‘m new!
© Software Quality Lab www.software-quality-lab.com - 25 -
Improve your Quality
Herausforderung 5:
Systemablöse ist Operation am offenen Herzen
© Software Quality Lab www.software-quality-lab.com - 26 -
Improve your Quality
Learning: Tests von Beginn an mitspezifizieren
End-to-End
Geschäftsprozesse
Anwendungsfälle
Funktionen,
UI-Masken
Schnittstellen
End-to-End Tests
(System-Integrations-Tests)
Anwendungsfall-Tests
Funktionstests
© Software Quality Lab www.software-quality-lab.com - 28 -
Improve your Quality
Zusammenarbeit von
Fachbereich und Entwicklung
© Software Quality Lab www.software-quality-lab.com - 29 -
Improve your Quality
Learning: Entwicklung und Stakeholder*innen arbeiten
von Anfang an ständig zusammen!
Systemarchäologi
e
Ist Analyse
Anwendungsfall-
Übersicht
Gemeinsam:
Anwendungsfälle
+ Testfälle
spezifizieren
Lösungskonzept
entwerfen
Anwendungsfälle
reviewen und
priorisieren
Gemeinsam:
UI erarbeiten

Anwendungsfälle
überarbeiten
Implementierung
Laufendes
Feedback
Entwicklung
Fachbereich
© Software Quality Lab www.software-quality-lab.com - 30 -
Improve your Quality
 Wöchentliche Fix-Termine für die
Spezifikation
 Montag Nachmittag
 Freitag Vormittag
 Für die gesamte Projektlaufzeit geplant
 Fachbereich und Lösungsbau arbeiten stetig
am Projekt. Mal führt der eine, mal der
andere.
 Moderiert durch erfahrenen Requirements
Engineer (kann auch externer Berater sein ;-
)
Gemeinsame Workshops
© Software Quality Lab www.software-quality-lab.com - 31 -
Improve your Quality
Wenn neue Kolleg*innen ins Team dazustoßen,
dann gab es immer ein Onboarding:
 Bereits erarbeitete Spezifikationen einlesen
 Go & See! Führung durch den Fachbereich
 Einladungen für Regeltermine schicken (wird
gerne vergessen)
Learning: Neue Team-Mitglieder intensiv
onboarden!
© Software Quality Lab www.software-quality-lab.com - 32 -
Improve your Quality
Markus Unterauer
Software Quality Lab
Senior Consultant
 Requirements Engineering
Beratung und Coaching
 Agility
 Potenzialanalyse von
Entwicklungsorganisationen
https://www.linkedin.com/in/markus-unterau
Die Slides zum Vortrag poste ich
auf LinkedIn. Wer sie haben möchte,
einfach connecten…
© Software Quality Lab www.software-quality-lab.com - 33 -
Improve your Quality
Learnings
1. Bei bestehender Software ständig auf sichere Todeszeichen achten
2. Ziele für die Systemablöse müssen glasklar sein
3. Auch bei Systemablösen braucht es fachliche Anforderungen
4. Feldbeobachtung ist extrem hilfreich!
5. Anforderungen flexibel dokumentieren (Use Cases, User Stories)
6. Reverse Engineerings ist herausfordernd
7. Verständlich ist wichtiger als technisch korrekt
8. Glossar schafft gemeinsame Sprache
9. Tests von Beginn an mitspezifizieren
10.Entwicklung und Stakeholder*innen arbeiten von Anfang an ständig
zusammen!
11.Neue Team-Mitglieder intensiv onboarden!
© Software Quality Lab www.software-quality-lab.com
Consulting | Academy | Operational Services
IMPROVE YOUR QUALITY
Software Quality Lab

Weitere ähnliche Inhalte

Ähnlich wie Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Systemablösen.pptx

Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?
Ernest Wallmueller
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Fabian Niesen
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
Christoph Menke
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Digicomp Academy AG
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungChristian Baranowski
 
Next Level Unit Testing
Next Level Unit TestingNext Level Unit Testing
Next Level Unit Testing
Daniel Lehner
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
Marc Müller
 
Zinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.deZinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.de
Kenner Soft Service GmbH
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
camunda services GmbH
 
Webanwendungen testen
Webanwendungen testenWebanwendungen testen
Webanwendungen testenBoris Köster
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
Claudia Haußmann 🦋
 
Specification by example
Specification by exampleSpecification by example
Specification by example
Markus Unterauer
 
Test-Alternativen
Test-AlternativenTest-Alternativen
Test-Alternativen
Sebastian Dietrich
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshopmrdoubleb
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
FotiosKaramitsos
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
Dennis Wilson
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Michael Fischlein
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
jlink
 

Ähnlich wie Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Systemablösen.pptx (20)

Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?Softwarequalität – Schlagwort oder Realität ?
Softwarequalität – Schlagwort oder Realität ?
 
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop AnalyticsWindows as a Service - Herausforderungen ohne Windows Desktop Analytics
Windows as a Service - Herausforderungen ohne Windows Desktop Analytics
 
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen SystemlandschafteneCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
eCATT & OpenSource - Automatisierter Test in heterogenen Systemlandschaften
 
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)Referat: Scrum Rocks – Testing Sucks?! (reloaded)
Referat: Scrum Rocks – Testing Sucks?! (reloaded)
 
Einführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software EntwicklungEinführung Vorgehensmodelle und Agile Software Entwicklung
Einführung Vorgehensmodelle und Agile Software Entwicklung
 
Next Level Unit Testing
Next Level Unit TestingNext Level Unit Testing
Next Level Unit Testing
 
2011 05 11 11-45 top_sopft-startfolien-xx-01
2011 05 11 11-45 top_sopft-startfolien-xx-012011 05 11 11-45 top_sopft-startfolien-xx-01
2011 05 11 11-45 top_sopft-startfolien-xx-01
 
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software EntwicklungDevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
DevDay 2016 Keynote - Die Evolution agiler Software Entwicklung
 
Zinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.deZinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.de
 
Roadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht'sRoadshow 2018 - Camunda in der Praxis: So geht's
Roadshow 2018 - Camunda in der Praxis: So geht's
 
Webanwendungen testen
Webanwendungen testenWebanwendungen testen
Webanwendungen testen
 
Agiles Testen - Überblick
Agiles Testen - ÜberblickAgiles Testen - Überblick
Agiles Testen - Überblick
 
Specification by example
Specification by exampleSpecification by example
Specification by example
 
Test-Alternativen
Test-AlternativenTest-Alternativen
Test-Alternativen
 
Scrum Workshop
Scrum WorkshopScrum Workshop
Scrum Workshop
 
Agile Business Software mit der Enterprise Cloud
Agile Business Software mit der Enterprise CloudAgile Business Software mit der Enterprise Cloud
Agile Business Software mit der Enterprise Cloud
 
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
2023-08_RPA-ChapterEvent_Überprüfung-der-Codequalität
 
JavaScript und trotzdem Softwerker
JavaScript und trotzdem SoftwerkerJavaScript und trotzdem Softwerker
JavaScript und trotzdem Softwerker
 
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0Ich will agil testen! was muss ich können   iqnite 2014 - verison 2.0
Ich will agil testen! was muss ich können iqnite 2014 - verison 2.0
 
Testgetriebene Softwareentwicklung
Testgetriebene SoftwareentwicklungTestgetriebene Softwareentwicklung
Testgetriebene Softwareentwicklung
 

Mehr von Markus Unterauer

Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in ÖsterreichNotfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Markus Unterauer
 
Man kann nicht nicht planen
Man kann nicht nicht planenMan kann nicht nicht planen
Man kann nicht nicht planen
Markus Unterauer
 
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMNWas machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
Markus Unterauer
 
Risikobasiertes testen
Risikobasiertes testenRisikobasiertes testen
Risikobasiertes testen
Markus Unterauer
 
Lessons learned from measuring software development processes
Lessons learned from measuring software development processesLessons learned from measuring software development processes
Lessons learned from measuring software development processes
Markus Unterauer
 
You cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements qualityYou cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements quality
Markus Unterauer
 
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ..."Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
Markus Unterauer
 
Tipps für Requirements Management Tools
Tipps für Requirements Management ToolsTipps für Requirements Management Tools
Tipps für Requirements Management Tools
Markus Unterauer
 
Erfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements EngineeringErfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements Engineering
Markus Unterauer
 
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Markus Unterauer
 
Traceability von Software Anforderungen
Traceability von Software AnforderungenTraceability von Software Anforderungen
Traceability von Software Anforderungen
Markus Unterauer
 

Mehr von Markus Unterauer (11)

Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in ÖsterreichNotfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
Notfallvorsorge in der Stadt - Staatliche Notfallvorsorge in Österreich
 
Man kann nicht nicht planen
Man kann nicht nicht planenMan kann nicht nicht planen
Man kann nicht nicht planen
 
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMNWas machen unsere Anwender so? Prozessmodellierung mit BPMN
Was machen unsere Anwender so? Prozessmodellierung mit BPMN
 
Risikobasiertes testen
Risikobasiertes testenRisikobasiertes testen
Risikobasiertes testen
 
Lessons learned from measuring software development processes
Lessons learned from measuring software development processesLessons learned from measuring software development processes
Lessons learned from measuring software development processes
 
You cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements qualityYou cant control what you cant measure - Measuring requirements quality
You cant control what you cant measure - Measuring requirements quality
 
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ..."Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
"Das Reiten eines hässlichen Pferdes ist verboten" - Gesetze aus Sicht eines ...
 
Tipps für Requirements Management Tools
Tipps für Requirements Management ToolsTipps für Requirements Management Tools
Tipps für Requirements Management Tools
 
Erfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements EngineeringErfolgsfaktoren im Requirements Engineering
Erfolgsfaktoren im Requirements Engineering
 
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
Software Quality Lab - Beratung und Training für mehr Qualität und Effizienz ...
 
Traceability von Software Anforderungen
Traceability von Software AnforderungenTraceability von Software Anforderungen
Traceability von Software Anforderungen
 

Rückwärts denken vorwärts handeln - Requirements Reverse Engineering bei Systemablösen.pptx

  • 1. © Software Quality Lab www.software-quality-lab.com Markus Unterauer Berater Rückwärts denken, vorwärts handeln: Requirements Reverse Engineering bei Systemablösen Title powered by ChatGPT ;-)
  • 2. © Software Quality Lab www.software-quality-lab.com - 2 - Improve your Quality Was sie erwartet  Herausforderungen und Learnings aus einem großen Systemablöseprojekt  100+ Stakeholder*innen  5 Teilprojekte  1.000+ PT für Spezifikation
  • 3. © Software Quality Lab www.software-quality-lab.com - 3 - Improve your Quality Herausforderung 1: Wie erkennt man, dass eine Software abgelöst werden soll?
  • 4. © Software Quality Lab www.software-quality-lab.com - 4 - Improve your Quality Ist meine Software End-of-Life? 4 Aufwand Business Value An der Kennzahl „Business Value pro Personentag“ erkennt man, wann ein System sich seinem End- of-Life nähert.
  • 5. © Software Quality Lab www.software-quality-lab.com - 5 - Improve your Quality  Immer schwierigere/komplexere Erweiterungen  Gestiegene technische Schuld  Veraltete Technologie. Mehr und mehr verwendete Frameworks werden nicht mehr weiterentwickelt. Entwickler*innen schwer zu bekommen.  Mehr Fehler  Abschätzen von Änderungen immer aufwendiger  … Learning: Auf sichere Todeszeichen achten
  • 6. © Software Quality Lab www.software-quality-lab.com - 6 - Improve your Quality Learning: Ziele müssen glasklar sein  Auch Systemablösen brauchen klare, eindeutige, prüfbare Ziele.  Mögliche Ziele: „1:1 Ablöse der Funktionen aus Anwender*innensicht des bestehenden Systems“ „Keller zusammenräumen“ (nicht mehr Benötigtes rausnehmen, Workarounds und technische Schuld aufräumen) 6 Helfen die Ziele bei täglichen Entscheidungen?
  • 7. © Software Quality Lab www.software-quality-lab.com - 7 - Improve your Quality Herausforderung 2: Keiner kennt mehr die ursprünglichen fachlichen Anforderungen
  • 8. © Software Quality Lab www.software-quality-lab.com - 8 - Improve your Quality Anforderungen? … Fehlanzeige  Anwender*innen im Fachbereich kennen Anforderungen im Detail nicht, sondern bedienen nur das System.  Keine Dokumentation der Anforderungen, maximal verstreute Fehlerberichte und Change Requests. 8
  • 9. © Software Quality Lab www.software-quality-lab.com - 9 - Improve your Quality Requirements Engineering und Reverse Engineering zum Rekonstruieren der Anforderungen 9 Fachliche Anforderungen Architektur Design Code Requirements Engineering Reverse Engineering
  • 10. © Software Quality Lab www.software-quality-lab.com - 10 - Improve your Quality  Versuchung: Entwickler*innen sollen doch einfach ohne Aufwand für den Fachbereich das Altsystem nachbauen!  Aber:  1:1 Ablöse nur selten möglich und tatsächlich gewünscht  Entwickler*innen kennen das alte System nicht mehr  Ist-Analyse tw. aufwendiger als Neuspezifikation  Anforderungsspezifikation erleichtert bzw. ermöglicht Testen.  Daher: Auch bei Systemablösen müssen zumindest die wesentlichen fachlichen Anforderungen ermittelt werden! Learning: Es braucht auch fachliche Anforderungen!
  • 11. © Software Quality Lab www.software-quality-lab.com - 11 - Improve your Quality Learning: Anforderungen flexibel dokumentieren  Wenn Interaktion anders wird:  User Stories mit Akzeptanzkriterien  Vorteil: Robust bei Änderungen, flexibel  Nachteil: Weniger klare Spezifikation  Wenn Interaktion im neuen System gleich bleibt:  Strukturierte Use Cases mit Ablaufschritten  Vorteil: Genauere Spezifikation  Nachteil: aufwendig in Erstellung und Wartung, viele Änderungen
  • 12. © Software Quality Lab www.software-quality-lab.com - 12 - Improve your Quality Learning: Feldbeobachtung ist extrem hilfreich! Go & See!
  • 13. © Software Quality Lab www.software-quality-lab.com - 14 - Improve your Quality Herausforderung 3: Keiner kennt mehr das ganze System in der Tiefe im Detail
  • 14. © Software Quality Lab www.software-quality-lab.com - 15 - Improve your Quality  Bestehende Systeme sind oft über sehr lange Zeit gewachsen (30 Jahre und mehr)  Komplex  Viele Schnittstellen  Vielen Anwender*innen und Anwendungsfälle  Viele Kompromisse und technische Schuld  System ist oft schlecht dokumentiert  Architekturdokumentation für Überblick fehlt  Detaildokumentation für Funktionen maximal im Code selbst  Entwickler*innen kennen nur Ausschnitte Gewachsene Gewucherte Systeme [Quelle: Hopkins, Jenkins, „Eating the IT elephant“, 2008] Systemablösen sind selten Neuentwicklungen auf der grünen Wiese, sondern meist komplexe Systeme in komplexen Umgebungen.
  • 15. © Software Quality Lab www.software-quality-lab.com - 16 - Improve your Quality  Liefert das WIE, teilweise auch das WAS und WER, nicht aber das WOZU.  Liefert auch alle Fehler, Kompromisse, Unsauberkeiten mit (nicht erkennbar).  Übergreifende Zusammenhänge sind oft nicht erkennbar. Gerade bei lose gekoppelten Service-Architekturen.  Sehr zeitaufwendig! Entwickler*innen sind oft knappe Ressource und können in der Zeit nichts anderes programmieren.  Systemanalysen so schreiben, dass alle es verstehen, gelingt oft nicht (zu technisch, zu feingranular). Learning: Reverse Engineerings ist herausfordernd Diese Lücken füllt das Requirements Engineering!
  • 16. © Software Quality Lab www.software-quality-lab.com - 17 - Improve your Quality Reverse Engineering und Übersetzung von Code  Wie würden Sie einer*einem Stakeholder*in beschreiben, was diese Funktion macht? „ChatGPT erklärt mir, was dieser Code macht!“
  • 17. © Software Quality Lab www.software-quality-lab.com - 18 - Improve your Quality Herausforderung 4: Fachbereich und Entwicklung sprechen nicht dieselbe Sprache
  • 18. © Software Quality Lab www.software-quality-lab.com - 19 - Improve your Quality Beispiel für eine Ist-Analyse aus der Praxis
  • 19. © Software Quality Lab www.software-quality-lab.com - 20 - Improve your Quality Learning: Verständlichkeit ist wichtiger als technische Detailliertheit Technisch korrekt: „Zuerst wird eine ganzzahlige Zählervariable i mit 0 initialisiert. Danach wird von 0 bis 100 aufsteigend durchiteriert und immer wenn der Wert von i modulo 2 Null ergibt, wird i in einer neuen Zeile ausgegeben.“ Vollständig, korrekt und technisch detailliert. … aber keiner versteht‘s  20 for (int i = 0; i <= 100; i++) { if(i % 2 == 0) println(i);} Verständlich für die Stakeholder*innen: „Die Funktion listet alle geraden Zahlen bis 100 auf.“ Hier fehlt, dass es bei 0 losgeht, dass jede Zahl in eine eigene Zeile kommt, dass die Zahlen aufsteigend aufgezählt werden, dass es nur ganze Zahlen sind etc. … aber die Stakeholder*innen verstehen es!
  • 20. © Software Quality Lab www.software-quality-lab.com - 21 - Improve your Quality Verständlichkeit verständlich für die Stakeholder*innen technisch korrekt, detailliert, vollständig
  • 21. © Software Quality Lab www.software-quality-lab.com - 22 - Improve your Quality Tipps fürs verständlich Formulieren  Verwenden Sie nur Wörter, die Fachbereich und Entwicklung verstehen.  Sprechen Sie in ganzen Sätzen, nicht in Schlagwortlisten.  Vermeiden Sie Abkürzungen (z.B. UI, DB).  Vergeben Sie Bildunterschriften (z.B. für Screenshots aus dem Altsystem).  Vermeiden Sie IT-Fachbegriffe (z.B. Request, Response, Session, Server, Deployment, …).  Beschreiben Sie erstmal den Standardfall, lassen Sie Sonderfälle, Varianten und Error-Handling weg. Das kommt später.  Visualisieren Sie mit einfachen (!) Modellen. 22
  • 22. © Software Quality Lab www.software-quality-lab.com - 23 - Improve your Quality Learning: Glossar  Oft wird derselbe Begriff unterschiedlich verwendet. Das führt zu Missverständnissen, vermeidbaren Rückfragen und im schlimmsten Fall zu Mängeln am Produkt.  Das Glossar unterstützt dabei, eine einheitliche Sprache zu sprechen und Begriffe gleich zu verwenden.  Spannend wie das Telefonbuch, aber extrem nützlich!!! Ein Glossar ist eine Sammlung von Begriffen und dazugehörigen Erklärungen. In ein Glossar gehören z.B. Fachbegriffe und Abkürzungen. Explain it like I‘m new!
  • 23. © Software Quality Lab www.software-quality-lab.com - 25 - Improve your Quality Herausforderung 5: Systemablöse ist Operation am offenen Herzen
  • 24. © Software Quality Lab www.software-quality-lab.com - 26 - Improve your Quality Learning: Tests von Beginn an mitspezifizieren End-to-End Geschäftsprozesse Anwendungsfälle Funktionen, UI-Masken Schnittstellen End-to-End Tests (System-Integrations-Tests) Anwendungsfall-Tests Funktionstests
  • 25. © Software Quality Lab www.software-quality-lab.com - 28 - Improve your Quality Zusammenarbeit von Fachbereich und Entwicklung
  • 26. © Software Quality Lab www.software-quality-lab.com - 29 - Improve your Quality Learning: Entwicklung und Stakeholder*innen arbeiten von Anfang an ständig zusammen! Systemarchäologi e Ist Analyse Anwendungsfall- Übersicht Gemeinsam: Anwendungsfälle + Testfälle spezifizieren Lösungskonzept entwerfen Anwendungsfälle reviewen und priorisieren Gemeinsam: UI erarbeiten  Anwendungsfälle überarbeiten Implementierung Laufendes Feedback Entwicklung Fachbereich
  • 27. © Software Quality Lab www.software-quality-lab.com - 30 - Improve your Quality  Wöchentliche Fix-Termine für die Spezifikation  Montag Nachmittag  Freitag Vormittag  Für die gesamte Projektlaufzeit geplant  Fachbereich und Lösungsbau arbeiten stetig am Projekt. Mal führt der eine, mal der andere.  Moderiert durch erfahrenen Requirements Engineer (kann auch externer Berater sein ;- ) Gemeinsame Workshops
  • 28. © Software Quality Lab www.software-quality-lab.com - 31 - Improve your Quality Wenn neue Kolleg*innen ins Team dazustoßen, dann gab es immer ein Onboarding:  Bereits erarbeitete Spezifikationen einlesen  Go & See! Führung durch den Fachbereich  Einladungen für Regeltermine schicken (wird gerne vergessen) Learning: Neue Team-Mitglieder intensiv onboarden!
  • 29. © Software Quality Lab www.software-quality-lab.com - 32 - Improve your Quality Markus Unterauer Software Quality Lab Senior Consultant  Requirements Engineering Beratung und Coaching  Agility  Potenzialanalyse von Entwicklungsorganisationen https://www.linkedin.com/in/markus-unterau Die Slides zum Vortrag poste ich auf LinkedIn. Wer sie haben möchte, einfach connecten…
  • 30. © Software Quality Lab www.software-quality-lab.com - 33 - Improve your Quality Learnings 1. Bei bestehender Software ständig auf sichere Todeszeichen achten 2. Ziele für die Systemablöse müssen glasklar sein 3. Auch bei Systemablösen braucht es fachliche Anforderungen 4. Feldbeobachtung ist extrem hilfreich! 5. Anforderungen flexibel dokumentieren (Use Cases, User Stories) 6. Reverse Engineerings ist herausfordernd 7. Verständlich ist wichtiger als technisch korrekt 8. Glossar schafft gemeinsame Sprache 9. Tests von Beginn an mitspezifizieren 10.Entwicklung und Stakeholder*innen arbeiten von Anfang an ständig zusammen! 11.Neue Team-Mitglieder intensiv onboarden!
  • 31. © Software Quality Lab www.software-quality-lab.com Consulting | Academy | Operational Services IMPROVE YOUR QUALITY Software Quality Lab

Hinweis der Redaktion

  1. Seite 1
  2. Während des Entwicklungsprojektes und die erste Zeit im Betrieb kann mit wenig Aufwand viel neue Funktionalität und damit Wert für die Anwender*innen geschaffen werden. Hier macht Software-Entwicklung Spaß. Je länger das System in Betrieb ist, desto mehr Aufwand ist nötig, um selbst kleine neue Funktionen umzusetzen. Ursachen dafür: Angehäufte technische Schuld Komplexität des Systems wächst Immer mehr muss getestet werden Immer mehr Side-Effect-Fehler Weitere Gründe für das Ende eines Software-Produktlebens: Technologische Gründe (z.B. Technologie wird von der*vom Hersteller*in nicht mehr weiterentwickelt) Kosten für ein Re-Engineering zu groß Zu große Änderungen an Anforderungen und Kontext Wartungs- und Weiterentwicklungskosten werden zu hoch …
  3. Reverse Engineering versucht, die (fachlichen) Anforderungen aus dem Quellcode zu extrahieren. Hierfür gibt es viele Methoden und Tools. Aus Requirements Engineering Sicht lassen sich so aber nur Teile der Anforderungsspezifikation ermitteln: Ziele: Nein Stakeholder*innen: Nur die Anwender*innen, andere Stakeholder*innengruppen nicht. Kontext: Nur Fremdsysteme, zu denen es Schnittstellen gibt. Alles andere im Kontext nicht. Funktionale Anforderungen: Ja, aber nur das WIE und nicht das WAS und das WOZU Qualitätsanforderungen: Manche können aus den Funktionen abgeleitet werden Rahmenbedingungen: Nein Im Wesentlichen findet man nur heraus, welche Funktionen das System anbietet, aber nicht die Anwendungsfälle. Es fehlt also die Info, wer die Funktionen wann wofür in welcher Reihenfolge einsetzt und welchen Nutzen sie damit verfolgt.
  4. Eine komplette Ist-Analyse aller Funktionen ist extrem aufwendig, da geht oft eine Neukonzeption basierend auf Fachanforderungen schneller. Neue IT-Infrastruktur bietet neue Möglichkeiten, anderes geht dafür nicht mehr Änderungswünsche vom Fachbereich Bestehendes System enthält oft viele Kompromisse, ja sogar Fehler
  5. Wenn Interaktion im neuen System wirklich gleich bleibt (gleiche Masken, gleicher Aufbau des UI, gleiche Abläufe)  Strukturierte Use Cases mit Ablaufschritten Zeigen zwar den Ablauf gut und es ist klar, wer wann was macht, aber wenn sich zB durch neue UI dann Schritte zusammengefasst werden, die Reihenfolge der Schritte anders wird etc., dann müssen auch die Use Cases angepasst werden Wenn Interaktion auch anders wird (weniger/mehr Masken, anderer UI Aufbau, Prozessoptimierung)  User Stories mit Akzeptanzkriterien Sind zwar weniger strukturiert und zeigen den Ablauf nicht, aber sind robuster gegen Änderurngen
  6. Anforderungen und Lösung sind in der Praxis oft miteinander verzahnt und können nicht völlig unabhängig betrachtet und verfeinert werden. Der Software-Lösungsraum wirkt auf die Wirklichkeit der Stakeholder*innen ein. Oft muss man Lösungsentscheidungen treffen, um mit den Anforderungen weiterzukommen. Mit jeder Entscheidung im Lösungsraum müssen andere Anforderungen erarbeitet werden. Je länger man im Requirements Engineering dahingeht, ohne die Entwickler*innen in Bezug auf Machbarkeit zu fragen, desto höher ist das Risiko, dass man etwas fordert, das dann schlussendlich nicht realisierbar ist! Daher vor jeder weiteren Verfeinerung oder jedem größeren Schritt auf der Anforderungsseite immer prüfen, ob das eh technisch so umsetzbar ist. Das ist ein aktiver Beitrag zum Risikomanagement.
  7. erkläre bitte in form einer user story mit akzeptanzkriterien, was folgender cobol code macht:
  8. Im Kapitel „Anforderungen gut dokumentieren“ finden Sie noch einige weitere Tipps.
  9. Zum Beschreiben von Begriffen im Glossar können Sie die Methode „Explain it like I‘m new“ anwenden: Beschreiben Sie dazu einen Glossarbegriff so, dass eine neu ins Team hinzukommende*r Kolleg*in ihn verstehen würde.
  10. Parallelbetrieb Altes und Neues System. Daten wurden in beide Systeme eingespielt. Automatisches Vergleichstool vergleicht erzeugte Daten. Bei Abweichungen  Vergleichs-Task und Behandlung durch Vergleichsteam Entweder als Fehler einstufen und korrigieren Oder Abweichung akzeptieren
  11. Seite 34
  12. Software wird im Initialprojekt geschaffen (entwickelt) und geboren (Release). Die meisten Vorgehensmodelle betrachten nur diese erste Phase. In der Ausbildung wird darauf das meiste Augenmerk gelegt. Die längste Zeit ist allerdings die Erhaltung (Maintenance). Hier entstehen auch die meisten Aufwände für Änderungen und Fehlerkorrekturen. Viele Software-Entwickler*innen verbringen die meiste Zeit ihrer Karriere mit Software-Wartung. Was sehr wenig beachtet wird ist die letzte Phase, die Zerstörung (End-of-Life). Auch Software, wie alles andere, erreicht diese Phase irgendwann einmal. Hierfür gibt es nur sehr wenige Vorgehensweisen, auch in der Ausbildung wird das wenig betrachtet.
  13. Als Entwickler*in erkennt man beispielsweise: Abschätzen von Änderungen immer aufwendiger Immer mehr Abhängigkeiten und Wechselwirkungen Mehr und mehr verwendete Frameworks werden nicht mehr weiterentwickelt Gestiegene technische Schuld Immer schwierigere/komplexere Erweiterungen Veraltete Technologie Mehr Fehler …
  14. Software lebt oft sehr lange, oft über 30 Jahre. Während des Lebenszyklus werden viele Änderungen vorgenommen. Diese werden oft nicht dokumentiert. Mitarbeiter*innen, die an der Entwicklung beteiligt sind und die Anforderungen kennen, verlassen das Unternehmen. Anwender*innen bedienen oft nur das abzulösende Altsystem, wissen aber nicht, was genau im Hintergrund passiert. Bei einer Systemablöse muss nun mühsam rekonstruiert werden, was die ursprünglichen Anforderungen waren und was das System kann.
  15. System ersatzlos streichen Wenn Systemablöse teurer ist als Prozesse und Organisation zu ändern. Altes System durch ein neues System ersetzen Wenn System für Geschäftsprozesse unabdingbar ist. Ablöse durch Standardprodukt oder Individualentwicklung Funktionen des alten Systems in ein anderes bestehendes System (z.B. SAP) integrieren Ist oft eine strategische Entscheidung Oder wenn Integration günstiger ist, als neue Lösung einzuführen Geht oft mit teilweisem Verlust von Funktionen einher
  16. Bei Systemablösen ist es nicht Reverse Engineering STATT Requirements Engineering, sondern man braucht beides. Requirements Engineering und Reverse Engineering starten dabei gleichzeitig. Anwender*innen beschreiben, was sie aus fachlicher Sicht mit dem System tun  Anwendungsfälle Entwickler*innen analysieren Quellcode, Masken, Datenbanken und ggf. vorhandenen Dokumenten und ermitteln, wie das System im Inneren arbeitet  Feature-Baum, detaillierte Daten- und Funktionsbeschreibungen Am Ende werden alle Informationen zusammengelegt, es entsteht dadurch eine Beschreibung des bestehenden Altsystems. Aus dieser wird dann erarbeitet, was das neue System können muss.
  17. Bei Systemablösen ist es nicht Reverse Engineering STATT Requirements Engineering, sondern man braucht beides. Requirements und Reverse Engineering starten dabei gleichzeitig. Anwender*innen beschreiben, was sie aus fachlicher Sicht mit dem System tun  Anwendungsfälle Entwickler*innen analysieren Quellcode, Masken, Datenbanken und ggf. vorhandenen Dokumenten und ermitteln, wie das System im Inneren arbeitet  Feature-Baum, detaillierte Daten- und Funktionsbeschreibungen Im Idealfall sind die Entwickler*innen, die die Ist-Analyse der betroffenen Teile gemacht haben, mit dabei. So kann gleich diskutiert werden: Was ist im bestehenden System an Funktionen drin, das nicht in den Anwendungsfällen der Anwender*innen erwähnt wurde? Was ist in den Anwendungsfällen drin, was in der Ist-Analyse noch nicht im System angesehen wurde? Vieles wissen die Anwender*innen auch nicht, was im Detail im Inneren des Systems passiert. Sie können z.B. teilweise nur sagen, welche Daten sie wo eingeben und wissen, dass das System die eingegebenen Daten dann irgendwie prüft. Nach welchen Prüfregeln das System prüft wissen sie aber nicht, oder kennen nur die Regeln, bei denen sie schonmal Fehlermeldungen erhalten haben. Am Ende werden alle Informationen zusammengelegt, es entsteht dadurch eine Beschreibung des bestehenden Altsystems. Aus dieser wird dann erarbeitet, was das neue System können muss. Ergänzen fehlender Schritte und (Detail-)Informationen in den Anwendungsfällen mit Ergebnissen der Ist-Analyse (z.B. Business Rules, automatisierte Schritte, Hintergrundprüfungen, Schnittstellen, …) Ergänzen fehlender Informationen der Ist-Analyse (z.B. wer führt welche Funktion aus, in Rahmen welchen Anwendungsfalls, …) Ergebnisse der Ist-Analyse in Sprache übersetzen, die der Fachbereich versteht Prüfen, ob es Funktionen, Schnittstellen, Masken gibt, die in keinem Anwendungsfall erwähnt sind  Lücke in den Requirements Entscheiden, was vom alten System 1:1 übernommen, was verbessert und was gestrichen werden soll.
  18. Parallel zum Reverse Engineering durch die Entwickler*innen wird mit den Anwender*innen erarbeitet, was sie mit dem neuen System machen wollen. Ziel ist es, die zukünftigen Soll-Anwendungsfälle herauszufinden. In Interviews werden die Anwender*innen befragt: Was macht ihr mit dem bestehenden System? Was wollt ihr mit dem neuen System machen können? Welche Prozesse sind betroffen? Wann nutzt ihr welche Funktionen? Zu welchem Zweck? In welcher Reihenfolge? Was passiert davor (ggf. in anderen Systemen)? Was danach? Was ist problematisch? Was soll geändert werden? Was fehlt? Ergebnis sind beispielsweise: Prozessbeschreibungen und Prozessmodelle für den Überblick Anwendungsfallbeschreibungen, wenn man viel Zeit hat und die Stakeholder*innen genau beschreiben können, was sie tun. User Stories mit Akzeptanzkriterien, wenn die Zeit knapp ist und die Stakeholder*innen nicht genau beschreiben können/wollen, was sie tun. Für die einzelnen Anwendungsfälle und Funktionen sollte auf die Wichtigkeit (Priorität) hinterfragt werden: Wie wichtig ist die Funktion? Wie häufig wird sie verwendet? Gibt es Alternativen und Workarounds? Welcher Schaden entsteht, wenn das nicht mehr geht?
  19. Oft müssen bestehende Systeme abgelöst werden. Dabei soll das neue System im Wesentlichen so funktionieren, wie das bestehende + einige Verbesserungspunkte. Stakeholder*innen im Fachbereich wissen nicht, was das alte System im Inneren tut  Entwickler*innen müssen das herausgraben. Die Ergebnisse werden von der Struktur her ähnlich aufgebaut wie eine Anforderungsspezifikation. Zu den Funktionen und Schnittstellen werden je nach Bedarf tiefgehende Analysen durchgeführt und genau herausgearbeitet, was wann wie von wem berechnet und getan wird.