IREB - Requirements Engineering Foundation Level

Bewährt in der Praxis

1. Anforderungen werden aus einem bestimmten Blickwinkeln geprüft und abgestimmt
2. perspektivenbasiertes Lesen

1. nutzt die Stärken einer Dokumentationsform um die Schwächen einer anderen auszugleichen
2. Bsp: natürlich sprachige Mehrdeutigkeit <-> Präzision eines Modells

1. Prozess zur Erstellung von Entwicklungsartefakten beispielhaft durchgeführt. 
   1. sorgt für intensives Auseinandersetzen und zeigt ggf. Fehler
   2. Resourcenaufwändig
2. Entwicklungsartefakte sind z.B.
   1. Entwurfsartefakte
   2. Testartefakte
   3. Benutzerhandbuch

sollte Stattfinden wenn:

1. Hoher Innovationsanteil in dem System
2. Hoher Wissenszugewinn beim REngineering
3. Längerfristige Projekte
4. sehr frühe Prüfung von Anforderungen
5. unbekannte Domaine
6. Wiederverwendung von Anforderungen

1. Review
   1. Stellungnahme
   2. Inspektion
   3. Walkthrough
2. Perspektivenbasiertes Lesen
3. Prüfung durch Prototypen
4. Einsatz von Checklisten

1. Eine dritte Person mit Expertiese prüft die Anforderungen hinsichtlich festgelegter Qualitätskriterien
2. Mängel werden im Dokument makiert und in komprimierter Form erkläutert

Entwicklungsartefakte systematisch nach Fehlern zu durchsuchen.

1. leichtgewichtige Ausprägung eines Reviews
2. nicht so strikt wie eine Inspektion
3. gemeinsammer Prozess zum
   1. Identifizieren von Mängeln in Anforderungen
   2. Herstellen eines gemeinsamen Verständnisses
4. Ablauf:
   1. Anforderungen werden vorher verteilt
   2. im Walkthrought werden die Anforderungen vorgestellt und besprochen
   3. Vorher Identifizierte Mängel werden in der Sitzung diskutiert und durch Protokollant festgehalten

Man ließt die Anforderungen aus einer bestimmten Perspektive!

Bsp:

1. Kunde (gewünschte Funktionalität &Qualität)
2. Softwarearchitekt (Infos für Architektur enthalten)
3. Tester (Infos für Testfälle)

Ansatz:

1. Anforderungen für den Prüfer erlebbar zu machen.
2. effektivste Methode für die Aufdeckung von Fehlern in Anforderungen.
3. Stakeholder können Vorstellungen mit Zielsystem abgleichen. (Abweichungen oder Lücken in A. werden gefunden)

1. Checkliste ist eine Menge von Fragen und Aussagen
2. enthält Fragestellung, die der Prüfer beantworten sollen
3. vorangestellt oder ergänzend zu allen anderen Prüftechniken
4. Sinnvoll, bei vielen Aspekten

1. Konfliktidentifikation
2. Konfliktanalyse
3. Konfliktauflösung
4. Dokumentation der Konfliktlösung

• Interessenskonflikt - Stakeholder haben faktisch unterschiedliche Bedürfnisse oder persönliche Interessen (zur Beachtung: Dieser Konflikttyp beinhaltete objektive und subjektive Konflikte. Objektive Interessenskonflikte entstehen aus faktisch unterschiedlichen Bedürfnissen, Subjektive Interessenskonflikte entstehen durch unterschiedliche persönliche Interessen). 
• Sachkonflikt - Stakeholder interpretieren Information unterschiedlich oder kennen die Information nicht. 
• Wertekonflikt - Stakeholder haben unterschiedliche Werte und Präferenzen. 
• Beziehungskonflikt - Stakeholder haben in ihren persönlichen Beziehungen untereinander Probleme. 
• Strukturkonflikt - Der Konflikt entstehet durch unterschiedene Hierarchie- und Entscheidungsbefugnis- Ebenen in einem Unternehmen.

1. Einigung - Aushandeln einer Lösung (Austausch von Infos und Überzeugen von einer Lösungsalternative)
2. Kompromiss - Kompromiss zwischen mehreren Lösungsalternativen, o. ggf. einer neuen)
3. Abstimmen - Stakeholder Stimmen über die Wahl der Lösungsaltertive ab
4. Variantenbildung - Variantenwahl o. Parameter des Systems decken alle konfliktierenden Anforderungen ab)
5. Ober-Strich-Unter- höchste Hierarchiestufe, oder die über den höchsten entscheidet
6. Consider-all-Facts (CAF) - Alle Einflussfaktoren & Infos des Konflikts werden untersucht und Relevanz bestimmt (für PMI)
7. Plus-Minus-Interesting (PMI) - Untersuchung aller Folgen (in Plus, Minus, Interesting) um besser die Auswirkungen abschätzen zu können
8. Entscheidungsmatrix - Spalten sind Lösungsalternativen; Zeilen enthalten alle Entscheidungskriterien, jede Zelle wird nach Relevanz bewertet (0-10); am Ende alle Zellen einer Spalte aufsummieren)

Auflösungs sollte in jedem Fall nachvollziehbar dokumentiert werden

Sonst Gefahr fürs Projekt

1. Wiederholte Behandlung von Konflikten (Kosten und ggf. Andere Lösung)
2. Überprüfung von Konfliktauflösungen (Ggf. war Lösung falsch und muss aufgearbeitet & erneut gemacht werden)

Nach der Konfliktauflösung sollte der Konflikt geeignet dokumentiert werden. Hierzu sollte insbesondere die Konfliktursache, die beteiligten Stakeholder, die Meinungen der einzelnen Stakeholder, die Art der Konfliktauflösung, mögliche Alternativen, die Entscheidungen und die Gründe für die Entscheidungen festgehalten werden.

1. Ziele (Intentionen von Stakeholdern)
2. Use Cases & Szenarien
3. Systemanforderungen (detailierte Funktionalitäten und Qualitäten)

Ergänzt werden die Modelle oft durch Prosa.

Ein Modell ist ein abstraktes Abbild einer existierenden oder einer noch zu schaffenden Realität.

1. Abbildung der Realität (Aspekte) (deskriptiv oder präskriptiv)
2. Verkürzung der Realität
   1. Selektion(bestimmte Aspekte) 
   2. Verdichtung (Zusammenfassen von Aspekten)
3. Pragmatische Eigenschaften
   1. Möglichst nur die Informationen im Modell darstellen, die für den Zweck notwendig sind

1. Syntax -  Modellelemente & gültige Kombinationen
2. Semantik - Bedeutung der einzelnen Elemente

1. informale M
2. semiformale M
3. formale M

Formalisierungsgrad abhängig über die Definition der Syntax und Semantik ( ggf. mathematisches Kalkül)

1. Modelle die Anforderungen eines Systems dokumentieren (Häufig UML)
2. Man unterscheidet konzeptuelle Modelle für
   1. Systementwicklung -> beschreibt Lösungsaspekte
   2. Dokumentation von Anforderungen -> Beschreibt Aspekte des Problems

1. Schnellere Erfassung & bessere Memoriesierung von bildhaften Darstellungen
2. definieter Fokus, Perspektive & Abstraktion einer Modellart
3. Elemente der Modellierungssprache geben Abstraktion vor

Zielmodelle stellen ein gewünschtes charakteristisches Merkmal eines Systems da. (Ziel eines Stakeholders)

Vorteil : Geringer Aufwand beim Erstellen und hoher Nutzen.

Bsp.: Und-Oder-Bäume zur Zieldekomposition

Baumartige Dekompensation eines Ziels

Leicht verständliche Modelle, die die

1. Nutzungssicht von Funktionalitäten 
2. deren Beziehungen untereinander
3. die Interaktion mit anderen Systemen

darstellen.

1. Use-Case
2. Akteur (Person, System)
3. Systemgrenze
4. extend-beziehung
5. include-beziehung
6. Kommunikation zwischen Aktuer und Use-Case

Use-Case-A <<extends>> Use-Case-B heißt

Beim Eintreten einer bestimmten Bedingung wird die Interaktionsfolge in Use-Case-B an seinem Extension-point um Use-Case-A erweitert.

Use-Case-A <<include>> Use-Case-B, bedeutet, dass in jedem Fall Use-Case-B in Use-Case-A enthalten ist (genauer. die Interaktionsfolge des Use-Cases)

Tabelle mit zusätzliche, strukturierten, textuellen Informationen zum Use-Case-Diagramm.

Attribute in der Tabelle

1. eindeutige Identifikationsattribute
2. Managementattribute (Quelle, Prio)
3. Beschreibung des Use-Cases
4. spezifische Use Case Attribute (Beispiele)
   1. Vor-& Nachbedingung
   2. Hauptszenario
   3. Alternativ-& Ausnahmeszenario
   4. auslösende Ereignisse

1. Strukturperspektive (Klassendiagramm & ER-Diagramm)
   1. In&Output
   2. statisch-Strukturelle Aspekte von Nutzungs-& Abhängigkeitsbeziehungen
2. Fuktionsperspektive (Use-Case; Aktivitätsdiagramm; Datenflussdiagramm)
   1. welche Informationen werden im Kontext manipuliert
   2. welche Daten fließen in den Kontext
3. Verhaltensperspektive (Statechart; Sequenzdiagramme)
   1. zustandsorientiere Dokumentation des Systems im Kontext
   2. Bsp. Reaktion des Systems auf Ereignisse

1. Entitytyp
2. Relationshiptyp
3. Attribut (Sowohl an EntityTyp als auch an RelationshipTyp)
4. Kardinalität (default 0...*)

ERD dokumentiert die Struktur des Gegenstandsbereichs. (Schemaebene und keine Instanzebene!)

1. Klasse mit Compartments (Name, Attribute, Funktionen)
2. Assoziationen
3. Aggregation
4. Komposition (Ein Teil kann nicht ohne das Ganze existieren)
5. Generalisierung
6. Multiplizität

1. Ein Datenflussdiagramm stellt die
   1. Quellen & Senken 
   2. Fluss von Daten durch das System dar.
2. Es werden keine Bedingungen dargestellt.

1. stellen den Kontrollfluss (Kanten) zwischen Aktivitäten & Aktionen (Knoten) des Systems dar
2. Ereignisgesteuerte Prozessketten (EPK) sind ein weiterer Ansatz der Ablaufmodellierung.

Eine Aktivität wird erst ausgeführt, wenn alle vorhergehenden Aktivitäten fertig sind.