RE Buchkaptiel

• Softwareprojekten scheitern oft an Gründen die mit Anforderungen zusammenhängen —> Beteiligung des Benutzers, (k) eine klare Zielsetzung, eindeutige Festlegung des Scopes und gut formulierte Anforderungen(in den Top 10 Gründen fürs Scheitern)

• Afomanagement spielt damit eine wesentliche Rolle im Projekt erfolgt

• Fehler können durch gutes Afo management reduziert werden und damit auch Kosteneinsparung gegenüber späterer Fehlerbehebung im Betrieb

  
  

• falsch verstandenen Afos führen zu falschen Systemen die nicht passen

• implizite Anforderungen werden nicht erkannt / forumliert und dann nicht umgesetzt

• inerpretierbare Anforderungen werden fehlinterpretiert vom Auftragnehmer und Lösung passt nicht

• Anforderungen ändern sich im laufe der Zeit / Projekts

• Kommunikationsprobleme

  • Afo so formulieren das alle darunter dasselbe verstehen ist schwierig

• Geld sparen

  • gute Analyse kosten Aufwand und Zeit im Projekt

  • Kostenersparnis nach dem Projekt wird nicht als relevant betrachtet

• Zeit sparen

  • Fokus auf raschen lösungen ohne vorherige Abnahmekriterien

  • Aber Zeit wird hinterher mehrfach wieder gebraucht um fehler auszubügeln

• Früher fehlende Methoden und geringe wichtigkeit des Themas

• 2006 gegründet von Fachleuten um Wissen für Beruf des Requirements Engineers zu beschreiben

• Formulierung eines Lehrplans

• Zertifizierung möglich Certified Professional for Requirements Engineering(CPRE)

• 3 stufig Foundation, Advanced, Expert

• Problem verstehen

  • Welches Problem hat Auftraggeber / Kunde

  • Problem definieren, durchleuten und verstehen —> Was braucht er und was erwarten Anwender von IT-Systemen

• Lösungen entwickeln & umsetzen

  • Aufbau Infrastruktur / Entwicklung Architektur

  • Entwicklung, Test und Inbetriebnahme

• Richtiges Team über Zwischenziel zum Ziel führen

  • Projektmanagement mit richtigen Kompetenzen, Zielen und guten Zeitplanen

  • Zwischenziele die man überprüfen kann festlegen

• Tätigkeiten der 3 Säulen heute iterativ durchgeführt

• Anforderungen ermitteln

• Anforderungen spezifizieren

• anforderungen managen (verwalten, pflegen, priorisieren)

• 
  

• Requirements Engineering ist ein iterativer und inkrementeller Prozess mit 3 Zielen

• 1. Aalle relevanten Anforderungen erfassen im erforderlichen Detaillierungsgrad und diese verstehen

• 2. involvierte Personen/ Stakeholder sollen sich in den bekannten Anforderungen einigen sein und das gleiche darunter verstehen und diese als die relevanten bestätigen (zumindest mehrheitlich)

• 3. Die Anforderungen sollen konform zu den Dokumentationsvorschriften der Organisation sein

• Business Analysis ist eine Menge von Aufgaben und Techniken, die genutzt werden, als Liaison zwischen Stakeholdern zu arbeiten, um die Struktur, die Direktiven (Policies) und die Arbeitsweise einer Organisation zu verstehen und (fachliche) Lösungen vorzuschlagen, die es der Organisation ermöglichen, Ihre Ziele zu erreichen

• Beide wohlen ein System verstehen um Schwachstellen zu identifizierne oder Verbesserungspotenziale

• Bei beiden ist man mit dem IST Zustand nicht zufrieden und man will aus verschiedenensten Gründen den Status quo verändern

• Durch Analyse des IST Zustandes hat man Schwachstellen identifiziert und entwickelt Lösungs / verbessrungsvorschläge mithilfe von präzisen Anforderungen an die Umsetzenden

• Gemeinsam mit Stakeholdern muss der Prozess durchlaufen werden, je kurzfristiger die Lösung desto genauer müssen Anforderungen sein

• Aussagen werden nur zu Anforderungen wenn sie identifizierbar und formalisert (halbwegs) sind z.B. als Satz, User Story

• Identifizerbare Anforderungen machen sie überprüfbar

• IEEE 610.12-1990 definiert Anforderungen als

  • Bedingung / Fähigkeit die von einer Person zur Lösung eins Problems / Erreichung eines Ziels benötigt wird

  • Bedingung / Fähigkeit ein System / teilsystem erfüllen muss um einen Vertrag / Norm / Spezifikation /formell vorgegebenes Dokument zu erfüllen

  • dokumentierte Repräsentation einer Beding / Fähigkeit nach den 2 vorherigen

• IEEE-Standard 29148 :

  • Eine Anforderung ist eine Aussage, die einen Wunsch samt seinen Einschränkungen und Randbedingungen ausdrückt oder übersetzt

• Anforderungen sind das Bindeglied zwischen zwei Parteien: jemanden, der etwas haben will (Auftraggeber), und jemanden, der es liefern kann (Auftragnehmer).

• klassisch in funktionale und nicht-funktionale Anforderungen

• Funktionale Anforderungen sind Funktionen die das System leisten soll bzw. das gewünschte Verhalten

• Nicht-funktionale Anforderungen alle Anforderungen an das System außer Funktionen , wird unterteilt in Qualitätsanforderungen und Randbedingungen

• Qualitätsanforderungen:definieren qualitative Eigenschaften vom System (im Sinne von schnell, zuverlässig, sicher, wartbar) mit konkreten Qualitätszielen mit bezug zu den funktionalen Anforderungen

• Randbedingungen: technische und organisatorische Vorgaben wie gesamtkosten, Zeitvorgaben, Technologievorgaben usw.

• 4 Hauptaufgaben bei Analytikern —> ermitteln, dokumentieren, rpüfen & konsolidieren und verwalten & managen

• Afo müssen ermittelt / rausgekitzelt werden um zu verstehn was der Kunde wirklich will

• Unterschiedliche Methoden zur Ermittlung u.a. Interviews

• Nach dem die Afos verstanden wurden müssen sie dokumentiert werden (schriftlich)

• graphisch (BPMN / Use Case Diagramme, Datenmodelle etc)

• Sätze / Texte

• Simulieren über Maskenfolgen, Mock-Ups, Prototypen

• Alle 3 arten der Dokumentation haben vor und nachteile

• Oft nachdem alle Afos beschrieben wurden gibt es Widersprüche zwischen den Anforderungen

• Diese Widersprüche müssen aufgelöst werden —> Welche Afos sollen wir wirklich erfüllen, bei Konflikten wer bekommt recht

• Am Ende müssen Afos vor Umsetzung widerspruchsfrei sein

• Afo ändern sich regelmäßig im Projektverlauf (insbesondere je länger das Projekt geht)

• Chance 1-3 Prozent pro Monat

• Verwalten von Anforderungen

  • Versionierung

  • Gültigkeitsbestimmung

  • Prioritäten

  • Umgang mit Change Request

  • Traability zwischen Analyse, Design und Sourcecode / Testdaten

• Analytisches Denken

• Selbstbewustes Auftreten und Kommunizieren

• Methodische Kompetenz

• Domänenkenntnisse helfen sind aber nicht vorraussetzung

• Als RE in Projekten müssen wir mit allen Beteilligten früher oder später interagieren und zusammenarbeiten um alle Aufgaben im RE zu erledigen

Projekte im klassischen Vorgehensmodell

Projekte im agilen Vorgehen

dort werden mehr Rollen zusammengefasst im Product Owner

• Aufwand für Business Analysis & RE in den meisten Vorhaben 25 % der Kosten und Zeit des Gesamtvorhabens

• Faustformel endent bei mehr als 7-10 Personen und 1-2 Jahren

• Aufwand ist nicht nur initial sondern erstreckt sich auch über den Vorhabensverlauf (iterativer Prozess) z.B. wenn man mit MVP arbeitet

• Restlichen Aufwände 25 % Design, 25 % Codierung, 25 % QS & Test

• abhängig davon wie viele Anforderungen der Auftraggeber schon einbring kann sich der Anteil auch reduzieren —> aber häufig viel Aufwand in Präzisierung der Anforderungen des Auftragsnehmmers

• Beteiligte Personen kennen sich —> reduziert missverständnis der afos

• Nicht interpetierbare Anforderungen

• Anforderungen in gleicher (Mutter-)Sprache formulieren —> Kulturelle Nuance können zu unterschiedlichem Verständnis führen

• Kulturverständnis —> unterschiedliche Kulturen haben unterschiedliche Wissenstände und Bedeutungen die sich auch auf Afo Formulierung auswirken

• Domänenhintergrund —> Kennen der Terminologie der Branche, aber vorsichtig bei zu viel Kenntnis nicht Begriffe ausreichend zu definieren für Anforderungen

• Vertrauen untereinander zwischen den Beteiligten und keine “politischen” Spiele

• Wasserfallmodell mit Requirements als erste Phase und dann design, Implementierung, Test —> Nicht erfolgreicfh und heute wenig genutzt

• Heute iterativer inkrementelles Vorgehen mit immer wieder kleinere Requirementsanalyse, Design, Implementierung, Test und dann wieder von vorne

• Länge einer Iteration unterschiedlich

• scrum 2-4 Wochen Zyklus mit Backlog und Sprints

• Industireschnitt IT projekte 2-4 Monate für Teillösungen —> oft 2 Hauptlieferunt im Jahr und zwei kleinere Releases für Fehlerbehebung

• T-Modell

  • Am Anfang einmal in die volle Breite aber wenig Tiefgang um dringendste Afo zu erfassen

  • Dann über weitere iterationen abbildung des tiefgangs für neue wichtige Themen / anforderungen

• Einigung über Projektziele was wir erreichen wollen —> Ziele sind abstrakte Afos und müssen überprüfbar sein

• stakeholder ermitteln die am Projekt mitworken sollen & können

• Umfang des Projekts begrenzen von Nachbarsystemen und Schnittstellen

• Faktoren stehen in Wechselwirkung zueinander

• 
  

• Ziele sind auch Anforderungen auf hoher Ebene und in abstrakter Form

• Alle weiteren detail Afo müssen sich aus diesen ableitten lassen

• Deshalb müssen auch Ziele wie gute Afos formuliert werden

• Ziele notwendig um Arbeit im Projekt in die gleiche Richtung zu bekommen

• Vorgehen für Zielformulierung

  • Ausganssituation beobachten (Was ist das Poblem, wen betrifft es, Auswirkungen, Ideen?) und beschreiben

  • Aus Ausganssituation Ziele ableiten —> Was wollen wir erreichen, wollen das alle?, weleche (quantifizierbaren) Vorteile bringt es? ist es sinnvoll und machbar?

  • Bei größeren Projekten Ziele noch unterteilen in Gesamt und für den nächsten Release

• Ziele als Afos sollten sich nicht im Projektverlauf ändern

• SMART —> Sepzifisch, Messbar, Angemessen, Realistisch und terminiert

• PAM —> Purpose, Advantage, Measure pro Ziel

• Ein Projekt sollte 3-5 solcher SMART / PAM Ziele haben

• Ziele sind abstrakt und damit schwerer überprüfbar aber Überprüfubarkeit und Messbarkeit sollte bei formulierung betrachtet werden

• Produktkoffer Methode —> In einer Kiste wird der Name, ein Logo und 2-3 Highlightpuntke des Produkts gesammelt und bei Besprechungen als Referenz genutzt

• Fakte Zeitungsartikelt schreiben über das Projekt wie als wäre es gerade fertig geworden und das Projekt loben

• Stakeholder sind die Beteiligten und vom Projekt betroffenen ebenso wie Entscheidungsträger und alle die auf das Projekt Einfluss haben

• Projekte haben häufig viele Stakeholkder und verpasste Stakeholder sind verpasste Afos

• Wenn wir Stakeholder übersehen kann uns das im späteren Projektverlauf auf die Füße fallen

• Erstmal alle Stakeholder erfassen und dann schauen welche Afos von wem relevant sind und umgesetzt werden

• Projektnähe der Stakeholder unterschiedlich

• meisten Afos kommen aus dem betroffenen Geschäftsfeld

• Je weiter weg vom Projekt desto indirekter auch der Einfluss

• Brainstorming am Anfang des Projekts mit Kernteam um stakeholder zuidentifizieren

• Wer hat interesse mit Name und Rollen

• Was wissen sie und können sie beitragen?

• welchen einfluss haben sie (relevanz fürs projekt)

• was sind ihre interessen?

• Liste mit Stakeholder mit diesen Punkten machen und an Stakeholder mit Bitte um ergänzung verschicken

• Es gibt auch versteckte Stakeholder mit Macht die wir erkennen und betrachten müssen

• Liste im Projektverlauf periodisch überprüfen

• Nicht jeder Stakeholder muss gleich stark beachtet und einbezogen werden —> artgerechte Betrachtung

• Nutzende sind die wichtigsten Stakeholder eines Softwareprodukts —> alle Gruppen mitdenken sie Auflistung unten

• Wir müssen wissen wer sie sind, welches Wissen und Fähigkeiten / Einschränkungen Sie haben, weil das die Afos mitprägt

  • domänenwissen, technologiekenntniss, sprachliche , alter

• Personas als Hilfsmittel

  • Personas repräsentieren typische Anwender —> für da man die fragen beantwortet was diese gerne haben wollen und diese werden im Prozesse immer wieder miteinbezogen

• Hauptquelle Nutzende / Stakeholder

• 80 % der Afos eines neuen Systems stecken im Vorgängersystem —> alte Dokumentation sollte auch für Afos herangezogen werden

• Visionsdokumente mit Firmenzielen zur Ableitung von Afos

• Modellierung von Geschäftsprozessen um von geschäftlichen Vorgaben ableitungen für IT zu machen

• Standards, Gesetze, Normen enthalten (implizite) Anforderungen

• Konkurrenzprodukte um sich von anderen abgrenzen zu können

• Literatur

• Scope eines Systems ist Bereich der bei der Entwicklung bewusst gestaltet und beeinflusst werden kann

• Um den Scope befindet sich der Kontext des analysierten Systems

• Kontext kann System beeinflussen, ohne das er Teil des Scopes ist z.B. über Ein und Ausgaben zu unserem System

• Scope und Kontext zu kennen ist wichtig um Abgrenzungen klar zu definieren und zu wissen was im Rahmen des Projektes betrachtet wird und was nicht

  
  

• Productscope ist der innerste Bereich unseres Produkts

  • Hier gibt es Potenzial zur automatisiereung von Teilen des Geschäfts

• Scope of Business ‘/ System Scope

  • Betrachtet Arbeitsumfeld und Geschäftsprozesse um Entscheidungen zu treffen was wir automatisieren

  • Aus dem Geschäftsfeld können wir Ideen für Productscope entwickeln

• Zuständigkeiten bei Businessscope und Produktscope häufig unterschiedlich (Business Anaysts und IT) —> kann Prozess hindern

• Verständnis zwischen Geschäftslichen und Technischen Afos wichtig —> zusammenarbeit statt gegeneinander oder losgelöst

• Erfolgsfaktor gemeinsame Sprache über gemeinsame Notation, Werkzeuge und Methoden

• Arbeiten Sie miteinander , nicht gegeneinander —> Gemeinsames Verständnis des Scopes führt zu gezielten Entscheidungen über Schnittstellen, was das System tun soll und Chancen & Risiken

• Am Anfang Umfeld breiter analysieren für Verständnis der Zusammenhänge und wo sich das Produkt da einfügen (soll)

• Minimierung Anzahl Notationen und Tools —> Vermeidung von Notationsbrüchen um widersprüchliche Dokumente zu vermeiden

• Business Anaysis und RE gehören zusammen und unterscheiden sich eher hinsichtlich Scope und Detailgrad der Afos

• Auch bei Abgrenzungsversuchen gibt es Grauzonen insbesondere während des Entscheidungsprozesses was zum Produkt gehört

• Auflösen von Grauzonen über nachfragen am Anfang des Projektes um spätere Konflikte zu vermeiden

• Zeichnen der “Umrisse” des Projektes um zu zeigen was nicht dazugehört ohne direkt spezifischer zu modellieren was hinein gehört ( Zusammensetzung Gesamtsystem, Funktionen, Prozessem, Projektstakeholder)

• Bei IT-System Scope über Schnittstellen von Daten in und aus dem System —> Systemschnittstellen sind Grenze des Projektes

• Kontextdiagramm als Mittel zur Scopebegrenzung

  • Bild mit in der mitt Blackbox mit ganzem Projektscope

  • Rundherum Nachbarsystem (Menschen, IT-Systeme,Software) benennen

  • Berührung mit Nachbarsystemen (Ein / Ausgaben) benennen mit Richtung

  • Kontextdiagramm kann man auch als Tabelle darstellen

  • Use Case Diagramme können auch erweitert werden um als Kontextdiagramm zu funktionieren oder UML Klassendiagramme

• Systematisierung für aufbewahrung von Systemanalyse ergebnissen

• Projekttreiber

  • Ziele des Projekts / Vision

  • Stakeholder

• Randbedingungen für das Projekt

  • Geforderte Randbedingungen

  • Namenskonventionen und Terminologie

  • Relevante Fakten und Annahmen

• Funktionale Anforderungen

  • Einbettung in das Arbeitsgebiet

  • Datenmodell

  • Umfang des Products

  • Functional Requirements

• Nichtfunktionale Anforderungen

  • Anforderungen an Benutzerschnittstelle

  • Ergonomieafos

  • Perrformanzafos

  • Operatieve und Umwelt afos

  • Afos an Wartbarkeit und Support

  • Sicherheitsafos

  • Kulturelle Afos

  • Rechtliche Afos

• Projektaspekte

  • offen Punkte

  • Kauf und Wiederverwendung

  • neue Probleme

  • Projektplanung

  • Anforderung an Migration und Inbetriebnahme

  • Risiken

  • Kosten anwenderdoku und Schulung

  • Warteraum

  • Lösungsidee