RE Folien

• Requirements Engineering ist ein kooperativer, iterativer und inkrementeller Ansatz zur Analyse und zum Managmen von Anforderungen

• Verfolgt folgende Ziele

• Relevante Anforderungen erkennen

• Konsens über die Anforderungen herzustellen

• Anforderungen konform zu vorgegeben Standards dokumentieren

• Anforderungen systematisch managen

• Wünsche und Bedürfnisse der Stakeholder verstehen

• System ist eine spezifische Zusammenstellung von einzelnen Komponenten zur Lösung eines Problems

• digitale Lösung ist ein soziotechnisches System das digitale Technologie verwendet um ein reales Problem zu lösen

• Digitale Lösungen umfassen technische Komponenten wie HW / SW und Menschen welche die technischen Teilkomponenten bedienen und nutzen

• Bedingung oder Fähigkeit die von einem Stakeholder zur Lösung eines Problems / Erreichung eines Ziels benötigt wird

• Bedingung / Fähigkeit die ein System / Teilsystem erfüllen oder besitzen muss um vertrag / Norm / Spezifikation oder andere formell vorgegebenen Dokumente zu erfüllen

• Afos sind Grundlage für jede Entwicklung von System, sie existieren immer implizit oder explizit

• Schlechtes RE und daraus resultierende Änderungen kosten viel Geld besonders je später sie entdeckt werden

• Mangelnde Einbeziehung der Nutzer

• Unvollständige Afos

• Unerkannte Afoänderung

• Mangelnde Managementunterstützung

• Technologische Inkompetenz

• Fehlende Ressourcen

• unrealistische Erwartungen

• unklare Ziele

• unrealistische Zeitvorgaben

• neue Technologie

• Ein Problem löst eine Anforderung aus

• Eine Anforderung beschreibt die Eigenschaften und Fähigkeiten der Lösung

• Die Lösung beseitigt das Proble

• Für jede Afo muss Problem bekannt sein das mit ihr erfüllt werden soll, da sonst die Lösung nicht den Erwartungen entspricht

• Geschäftsafo --> Geschäftliche Zielsetzung und Bedürfnisse einer Organisation

• Domänenafos --> übergreifende Eigenschaften aus der Branche / Domäne

• Stakeholderafos —> Eigenschaften / Fähigkeiten aus Sicht der Stakeholder

• Benutzerafo —> Eigenschaften / Fähigkeiten aus Sicht der Nutzer

• Systemafo —> Funktion / Eigenschaften die das System bereitstellen

• Für eine Lösung muss jede Kategorie von Afos betrachtet werden. afos werden auf den Kategorien von oben nach unten immerweiter verfeinert

• Funktiionale Afos beschreiben ein Ergebnis / Verhalten das durch eine Systemfunktion bereitgestellt werden soll

• Qualitätsafos beschreiben qualitative und quantitative Eigenschaften, die das System unterstützen muss

• Randbedingungen (Constraints) begrenzen den Lösungsraum über das was aus den funktionale und Qualitätsafos hinaus notwendig ist

• Funktion und Ablauf

• Funktionen die Ein System zur Verfügung stellen soll

• Kontroll und Datenfluss innerhalb und zwischen Funktionen

• Struktur und Daten

• Informationen die ein System kennen muss um die funktionen auszuführen

• Zustand und Verhalten

• Zustandabhängiges Verhalten eines Systems auf externe Ereignissen

• Zuverlässigkeit (Verfügbarkeit, Robustheit, Fehlertoleranz und Wiederherstellbarkeit)

• Benutzbarkeit(Verständlichkeit, Erlenbarkeit und Bedienbarkeit)

• Effizienz (Berechnungsdauer, Ressourcennutzung)

• Änderbarkeit(Analysierbarkeit, modifizierbarkeit, Prüfbarkeit)

• Übertragbarkeit (Anpassbarkeit, Installierbarket, Austauschbarkeit)

• Kontinuierliche Fokussierung herstellen und halten

• Komplexe Sachverhalte auf das wesentliche vereinfachen

• Entscheidungen zu Fragestellungen herbeiführen

• Methoden einsetzen,um Ergebnisse zu erzielen

• Sachverhalte angemessen veranschaulichen

• Ideen und Wünsche der Stakeholder auf vereinbartes Zielbild lenken

• IREB International Requirements Engineering Board

• IIBA International Institute of Business Analysis

• UXQB International Usability and UX Qualification Board

• BABOK

• Ermittlung von Afos

• Dokumentation von Afos

• Validierung von Afos

• Verwaltung der Afos über alle drei Haupttätigkeiten

• Werteorientierung --> Afos sind mittel zum zweck

• Stakeholder —> Ziel Bedürfnisse der Stakeholder befriedigen

• Gemeinsames Verständnis —> erfolgreichen entwicklung nur auf gemeinsamer Basis

• Kontext --> System können nur in ihrem Kontext mit anderen / umwelt vollständig verstanden werden

• Problemlösung —> Beziehung Problem, Afo und Lösung

• Validierung --> nur validierte Afos haben einen Mehrwert

• Evolution --> Afos verändern sich im Projektzeitlauf

• Innovation —> mehr von dem aktuellen ist nicht gennug

• Systematisch und disziplinier —> Grundbasis für erfolgreiches RE

• Arbeitsergebnis ist ein aufgezeichnetes in einem Arbeitsprozess erzeugtes Zwischen / Endergebnis

• Jedes Arbeitsergebnis hat Zweck, umfang und Lebensdauer

• Inhalt sollte einer definierten struktur entsprechen und einen sinnvollen dem Projekt zutragendem Detaillierungsgrad haben

• Beispiele für Arbeitsergebnisse

• Backlog, Sotry Map, Lastenheft, Prozessmodelle, Datnemodelle, Use Case, User story, Glossar, Protokolle

• Natürlichsprachliche Arbeitsergebnisse

• Vorlagenbasierte Arbeitsergebnisse —> vorgefertigter Entwurf für die syntaktische Struktur eines Arbeitsprodukts

• Modellbasierte Arbeitsergbnisse --> Modell ist ein abstraktes Bild einer existierenden / zu schaffenden Realität

TODO Einführung Folie 26 Bild einfügen

und bezug zu Volere

• Ziel bezeichnet einen in der Zukunft liegenden gegneüber dem jetzigen Zeitpunkt im Allgemeinen veränderten, erstrebenswerten und angestrebten Zustand

• Ziel sollten das Kritierienset PAM erfüllen

• Purpose --> was ist der Zweck

• A --> Was ist der betriebliche Mehrwert

• Measure --> wie würde man den Vorteil messen

• Ziele können eine Hierarchie / Baumstrukur haben

• Wurzielziel als Basis dann zerlegung in weitere kleinere Teileziele (auch über mehrere Ebenen möglich)

• Systemkontext ist der Teil der Umgebung eines Systems der für die Definition und das Verständnis der Afo des betrachteten Systems relevant ist

• TODO Einfügen Bild Einführungsfolien S.33

• Es gibt System, den Kontext und die irrelevante Umgebung die am Anfang von einander abzugreznen sind

• Der Umfang des System definiert die Reichweite der gestaltbaren Dinge

• Durch die Systemgrenze grenzt das System von seinem Systemkontext ab

• Die Kontextgrenzen grenzt den Systmekontext von der irrelevanten Umgebung ab

• System und Kontextgrenzen isnd Entscheidungen und können sich im Entwicklungsverlauf verschieben —> Regelmäßige Prüfung des Kontextverständnis wichtig

• Personen wie Stakeholder und Stakeholdergruppen

• System im Betrieb wie SW, HW und technische Systeme

• Prozesse technisch, physikalisch und Geschääftsprozesse

• Ereignisse

• Dokumente wie Gesetze, Standards, Systemdoku

• Stakeholder wie Auftraggeber, Nutzer, Betreiber, Entwickler, DSB

• Dokumente wie Gesetze, Normen, Standards, organisationsspezifische Dokumente

• Systeme in Betrieb wie altsysteme, konkurenzsystem und Schnittstellen des Systemskontext

• Stakeholder eines Systems ist eine Person / Organisation die direkt oder indirekt Einfluss auf die Afos des betrachteten Systems hat

• Zusammenarbeit mit Stakeholder ist für erfolgreiches RE wichtig und beinhaltet Rechte und Pflichten für beide Seiten

• TODO Einfügen Bild einführungsfolien S.36

• Regeln für Umgang mit Stakeholdern

• regelmäßige Statusbesprechungen

• Projektbetroffenen zu beteiligte machen

• positive Stakeholder halten und negativ eingestellte überzeugen

• lege Aufgaben, Verantwortungsbereich und Weisungsbefugnisse festlegen

• Name

• Funktion (Rolle)

• Weitere Personen und Kontaktdaten

• zeitliche und räumliche Verfügbarkeit während der Projektlaufzeit

• Relevanz des Stakeholders

• Wissensgebiet und umfang

• Ziele und Interessen bezogen auf das Projekt

• Schneller zugriff auf diese Doku hilfreich, dient als network des RE

• Klassisch als abgeschlossenen Phase Bild Folie 40

• Am Anfang hoher Aufwand für RE wo auf dem vollem Projektumgang und Detailtiefe Ziele Stakeholder, Prozesse, Randbedingungne, Use Cases und Systemafos erfasst, dokumentiert und validert werden

• Agil mit T Methode über mehrere Iterationen

• Am Anfang etwas höherer Aufwand um über gesamten Scope Ziele, Stakeholder, Prozesse, Randbeindungen und Use Cases in einer geringen Detailtiefe zu definieren

• Dann über Iterationen jeweils vertiefen für einen bestimmten Aspekt auf tiefere Detailtiefe

• Suchen,erfassen und konsolidieren von afo aus den Quellen

• Wünsche / Bedürfnisse erkennen analysieren und darstellen

• Stakeholdern auch neue Möglichkeiten aufzeigen

• ggf. IST Analyse und Marktanalyse

• Risiko bei schlechter Afoermittlung

  • Erfolg und Akzeptanz gefährdet

  • Afos übersehen und spät erst erkannt —> teuer

• Was ist das Ermittlungsziel

• Was ist die gewünschte Ergebnisqualität

• Was sind die Anforderungsquellen

• Welche Ermittlungstechniken sollen genutzt werden —> z.B. Interview, Workshops, Prototyping, Scenarios, Beobachtung

• Ermittlungsplan aus mit so beschriebenen Ermittlungsaktivitäten erstellen und auch Reihenfolge dir Aktivitäten bestimmen

• Ziele und Randbedingunen festlegen

• Systemkontext verstehen

• Systemgestallten und beschreiben

• Detaillierungsgrad geht bei diesen Schritte nvon Geschäft über Nutzer zu Systemebene

  
  

• Gespärch z.B. 1:1 mit Stakeholdern

• Strukturiertes Interview mit vorher festgelegten Fragen

• Unstrukturiertes Interview nur mit Thema und Fragen ergeben sich durch Gesprächsverlauf

• Gemeinsaem Erarbeitung von afos mit einer Gruppe von Stakeholder

• Haben Ziel und Ergebniserwartung z.B. Vision, Liste von Zielen, Afos am Ende des Termins

• Vorteile

  • höhere akzeptanz erarbeitetet Afos

  • vereinen ermittlung und Abstimmung

  • unmittelbares Feedback

• Prinzipien Workshopgestaltung

  • richtige Teilnehmer aktiv einbinden

  • Auf Ergebnise fokussieren

  • Psychologische Sicherheit schaffen

  • Atmosphäre zum Austausch & Zusammenarbeit schaffen

• Aufbau von Workshops

  • Einstieg —> zielsetzung, Spielregeln und kurze inhaltiche Vorstellungen

  • Themen sammeln und auswählen —> ermittelt, priorisieren der Themen

  • Themen bearbeiten —> aufteilung in kleingruppen und mehrere iteration und dann Präsentation

  • To Dos festhalten —> Aus ausarbeitungen To Dos sammeln und prioriseren

  • Abschluss —> Beurteilung der Arbeit und Reflexion

• Wahrnehmung der Realität wird bei jedem durcfh persönliche Wahrnehmung und persönliches Wissen beeinflusst

• Ebenso ist die Art wie wir gesehenes beschreiben unterschiedlich

• In guter Kommunikation müssen wir Komminkationsfallen umgehen damit wir ein gemeinsames Verständnis haben

• Afodoku ist eine systematisch dargestellte Sammlung von Afos die vorgegebenen Kriterien erfüllt

• Ziel Afo zweckmäßig konservieren und für die weiter Entwicklung verfügbar machen

• Formalität hilft für die nachnutzbarkeit

• Motivation zur Dokumentation

  • Afos langlebig und rechtliche Relefanz

  • Afos müssen für alle Beteiligten verfügbar sien

  • kritische Reflexion des eigenen Verständnis und Gedanken

• Auszug Inhalt einer Doku

  • Zweck des Systems

  • Rahmenbedingungen und Annahmen

  • Kontextbeschreibungen

  • Systembeschreibeung (funktionale und Qualitäts afos)

  • Glossar

  • Anhang

• vorteile

  • Leicht anwendbar da keine Schulung / werkzeuge benötigt werden

  • keine einarbeitungszeit in dokumentaiton

  • universell und felxibel für alle Bereiche geeignet

  • beliegie Abstraktion und Detaillierung möglich

• nachteile

  • Mehrdeutig durch fehlende Details, nicht ausreichende spezifizierung

  • mehrdeutigkeit durch sprachliche Freiräume

  • Vermischung von Perspektiven da trennugn von sichtweisen hier eher schwierig ist

• Templates definieren die Inhalte und Attribute die zu einer Afo beschrieben werden sollten

• Inhalte sind Infos die für die Umsetzung des Systems berücksichtigt werden müssen

  • Beschreibungen, Szenarien vom Use Case

  • Motivation begründung für Afo

• Attribute sind Ifos die im Rahmen des Entwicklungsprozesses enstehen und den unterstützen

  • Idenfitikationsattribute wie ID / titel

  • Nachvollziehbarkeitsattribute wie Quelle

  • Managementattribute wir Risiko, Status

• Vorteile

  • Einheitliche Struktur —> Infos immer am selben Platz

  • Referenz für strukturelle Vollständigkeit

  • Unterstütz Qualität und Verwaltung von Afos

  • Unterstütz überführung in RE Werkzeuge

• Nachteile

  • Templates müssen projektspezifisch angepasst werden

  • trotzdem kompetentes Personal wichtig

  • keine Garantie für inhaltliche Vollständigkeit

• Szenarien als Alternativen zu langen Afolisten

• Beschreiben konkrete Anwendungssituationen in denen ein Nutzer mit dem System interagiert

• strukturierte Szenarie bestehen aus Akteur, Auslöser und den einzelnen Schritten eines Hauptszenarios sowie alternativszenarien

• Beschreibung einer Interaktion zwischen min. einem Akteur und dem System, durch die ein Ziel des Haupotakteurs erreicht wird

• Use Cases beschreiben Verhalten aber nicht interne Struktur eines Systems

• bildet funktionale Afos ab

• Gründe üfr Use Cases

  • Szenarien färdern Verständnis

  • Ziele leichter prüfbar

  • strukturierung in UC verbessert Afo aufnahme

  • Zusammenhänge ziwschen funktionale Afos werden abgebildet

  • Komplexität wird übersichtlicher und strukturierter erfasst

• Validierung um Fehler von Afos möglcihst früh zu identifizieren

• Qualitätskritieren von Arbeitsprodukten und Afos nochmal sichern

• Konflikte erkennen und Konflikt resolution anstoßen

• Wichtig die richtigen Stkaheolder zu Beteiligen

• Trennen ovn Fehlersuche und Fehlerkorrektur

• Prüfung der Afos aus unterschiedlichen sichten und auch wiederholte Prüfungen

• Abgestimmt —> Wenn afo für alle Stakeholder korrekt ist und von ihnen akzeptiert wird

• Eindeutig —> nur eine Art und Weise verstanden werden kann

• Notwendig —> Afo im Systemkontext gültig

• Konsistent —> widerspruchsfrei zu anderen afos

• Prüfbar —> Afo muss so beschrieben werden das sie getestet werden kann

• Relaisierbar —> Afo in den Randbedinungungen umsetzbar

• Verfolgbar —> Urpsrung, umsetzung und Beziehungen zu anderen Afo ist bekann

• Vollständig —> Afo beschreibt gefordeerte Funktionalität vollständig

• Verständlich—> Afo und verwendete Begriff für alle Stakeholder verständlich

• Review Techniken

  • informelle Reviews

  • Walkthroug

  • Inspektionen

• Explorationstechniken

  • Prototyping

  • A/ B Tests

• Probe Entwicklung

• Mittel zur Spezifikation von Afos

  • Modell kann eindeutigikeit der Prozessanfos verbessern

  • Modelle können Vollständigkeit der Afos unterstützen

• Prüfungszweck

  • Modelle können Sachverhatle strukturieren und sehr präzise darstellen

  • Aufdecken von Widersprüchen /unvollständigkeit

• bessere Kommunikation

  • minimieren Verständnisschwierigkeiten

  • erleichttern Kommunikation zwischen FBs

• Modell ist ein abstrahiertes Abbild einer existereneden Realität oder Vorbild für eine zu schaffende Realität

• 3 zentrale Eigenschaften

  • Abbildungsseigenschaft der Realität

  • Verkürzende Eigenschaft der Realität

  • Pragmatische Eigenschaft —> modell für spezifische Verwendung

• Semantik eines Modellierungssprache definiert Bedeutung des Modells und dient als Grundlage für Interpretaiton

• Syntaix definiert die Elemten und ihre erlaubten Verbindungen

• Struktur und Daten

  • ER Modelle

  • UML Klassendiagramme

• Funktion und Ablauf

  • UC Diagramme

  • Datenflussdiagramme

  • UML Aktiivtätsdiagramme

• Zustand und Verhalten

  • Automatenmodelle

  • UML Statecharts

• Requirements Managmeent umfasste alle Tätigkeiten zur Festlegung der Vorgehensweise beim RE

• Verwalten bestehender Afos in verschiuedenen Arbeitsprodukten und ergebnissen

• Es gibt einmaltige und laufende Tätigkeiten im Requirements Managmenet

• Einmalige

  • Rollen und Verantwortungen definieren

  • Anforderungsprozess etablieren

  • Prüfvberfahren und Cheklisten erstellen

  • Werkzeuge bestimmen

  • Methoden und Ergebnisse festlegen

• laufende Tätigkeiten

  • Versionierung von Afos und Releases

  • Attributierung

  • Sichtenbildung

  • Priorisierung

  • Change Mangement

  • Verfolgbarkeit

• Afos haben einen Lebenszyklus

• Afos haben auch untereinander Abhängigkeiten weshalb innerhalb einer Version in der Implementierung definiert werden soll welche Version einer Afo implementiert werden mit welchen weiteren Afos (Afo konfiguration)

• Attribute verwalten Informationen über Afos

• ID

• Name

• Quelle

• Stabilität

• Kritikalität

• Priorität

• Art

• Rechtliche Verbindlichkeit

• Weiter projektspezifische Attribute

• Vorgaben aus dem Unternehmen

• Vorschriften des Anwendungsgebiets

• Randbedingungen des Entwicklungsprozesses

• Verfolgbarkeit von Afos ist wichtig

• Vereinfacht die Nahcweisbarkeit

• Identifikation von unnötigen afos wenn sie keine Quelle und verbindungen haben

• unterstützt Auswikrungsanalyse von afos

• Unterstützt bei der Wartung und Pflege ovn Afos

• Hilft Verbindungen zwischen Afos zu erkennen und ihre Ursprünge zu kennen

• Können textuell, Hyperlinks, Matrizen oder graphen sein zur nachverfolgung

• Attribute werden genutzt um Afos nach bestimmten Kriterien zu selektieren

• Sichten helfen bie der Beherrschung großer Mengen von afos

• Selektive Sichten z.B. nach Kritkalität

• Projektive Sichten von allen Afos eines Projektes

• Verdichtete Sichten Prozentsatz der Afos mit niedrig / mittel / hoch Kritkalität

• Priorität einer Afo dokumentiert die Bedeutung der Afo anhand eins / mehren ausgewähölten Priorisierungskritieren

• Vorgehen

  • Bestiimung der zu berücksichtigen STakeholder

  • Festleung der zu bewertenden Afos

  • Auswahl der Priorisierungskriterien

  • Auswahl der Priorisierungstechniken

• Übersicht Techniken zur Priroiseirung

  • Ranking

  • Top Ten

  • Ein Krterien Klassifikation

  • Kano Klassifikation

  • wiegershce Priorisierungsmatrix

  • Kosten Wert Analyse

• Mehre ebene von Tools mit unterschiedlichem Umfang und Kosten

• Auswahl nach eigenem Zielen im Requirements Management und komplexität des Projektes sowie benötigte Expertise

• Ebenene Office Tools, Wiki udn Ticketing Systeme, Klassische RE Tools und moderen RE Tools

•