IREB - Requirements Engineering Foundation Level

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.

1. Zustandsdiagramme / Automaten,
2. bestehend aus Zuständen und Zustandsübergängen.
3. Ein Übergang wird abhängig von einem Ereignis ausgeführt.

1. Eine Kombination von Modellen und Sprache nutzt die Stärken beider Arten und mildert die Schwächen.

Bsp:

1. Anforderungsmodelle können genutzt werden um natürlichsprachige Anforderungen zu präzisieren.
2. Prosa kann genutzt werden um Modelle mit Informationen anzureichern.

Elemente:

1. Prozesse (Verarbeitet Eingabedaten und gibt Ausgabedaten)
2. Datenspeicher  (persistent)
3. Quellen & Senken / Terminatoren (Aspekte der Umgebung)
4. Datenfluss
5. ggf. Kontrollfluss

1. Zustand (Zeitraum in dem das System ein Verhalten aufweißt & auf ein Ereignis wartet)
2. Startzustand
3. Finaler Zustand
4. Super-Zustand & Subzustand (Hierarchisierung)
5. Eintrittspunkt & Austrittspunkt
6. Nebenläufige Zustände
7. Zustandsübergänge (ausgelöst durch definierte Ereignisse)

Ermitteln

Dokumentieren

Prüfen/Abstimmen

Verwalten von Anforderungen

Qualitätsanforderungen müssen explizit dokumentiert werden. Dabei sind insbesondere die folgenden Aspekte zu beachten:

• Performanz 
• Sicherheit 
• Zuverlässigkeit 
• Benutzbarkeit 
• Änderbarkeit 
• Übertragbarkeit

Analytisches Denken

Empathie

Konfliktlösungsfähigkeit

Moderationsfähigkeit

Selbstbewusstsein

Überzeugungsfähigkeit

Funktionale Anforderungen

Qualitätsanforderungen

Randbedingungen

(Nicht-funkt. Anforderungen = Qualitätsanforderungen | Randbedingungen )

Sprache ist das wichtigste Mittel zur Kommunikation von Anforderungen.

Der Ursprung und damit auch die Rechtfertigung der Anforderungen eines Systems liegen im Systemkontext des geplanten Systems.

Zu den möglichen Aspekten im Systemkontext gehören u.a.: 

• Personen (Stakeholder oder Stakeholdergruppen) 
• Systeme im Betrieb (technische Systeme, Software und Hardware) 
• Prozesse (technisch oder physikalisch, Geschäftsprozesse) 
• Ereignisse (technisch oder physikalisch) 
• Dokumente (z.B. Gesetze, Standards, Systemdokumentationen)

Aufgabe der Systemabgrenzung ist es festzulegen, welche Aspekte durch das geplante System abgedeckt werden, und welche Aspekte Teil der Umgebung dieses Systems sind.

Bei der Kontextabgrenzung wird der Teil der Umgebung identifiziert, der eine Beziehung zu dem zu entwickelnden System hat.

Auch die Kontextgrenze kann sich über die Zeit verändern, z.B. wenn festgestellt wird, dass eine vormals als relevant eingestufte gesetzliche Vorschrift wider Erwarten keinerlei Auswirkung auf das geplante System hat, reduziert sich der Systemkontext an dieser Stelle.

• Use-Case-Diagramme (In Use-CaseDiagrammen werden die Akteure (d.h. beispielsweise Personen oder andere Systeme) in der Umgebung des Systems und deren Nutzungsbeziehungen mit dem zu entwickelnden System modelliert.)
• Datenflussdiagramme (Bei der Kontextmodellierung auf der Basis von Datenflussdiagrammen werden die Quellen und Senken in der Umgebung des Systems modelliert, die einen Ursprung bzw. einen Endpunkt von Datenflüssen zwischen dem betrachteten System und der Umgebung darstellen.)

Grundlagen für die Anforderungsermittlung bilden einerseits der Systemkontext und andererseits die Anforderungsquellen.

Mögliche Anforderungsquellen sind z.B.:

• Stakeholder
• Dokumente 
• Altsysteme.

Bleiben Anforderungsquellen unberücksichtigt, kann dies signifikant negative Auswirkungen auf den gesamten Projektverlauf haben.

• Name 
• Funktion (Rolle) 
• weitere Personen- und Kontaktdaten 
• zeitliche und räumliche Verfügbarkeit während der Projektlaufzeit 
• Relevanz des Stakeholders 
• sein Wissensgebiet und -umfang 
• seine Ziele und Interessen bezogen auf das Projekt

Durch ein mündlichen oder schriftlichen Vereinbarung mit dem Stakeholder werden die Aufgaben, Verantwortungsbereiche, Weisungsbefugnisse usw. festzulegen. Aus der Stakeholdervereinbarung resultieren für jeden Stakeholder Rechte und Pflichten. Ein effektiver Umgang mit Stakeholdern beugt Mangel an Motivation und Konflikten vor.

Basisfaktoren: Sind so grundlegend und selbstverständlich, dass sie den Kunden erst bei Nichterfüllung bewusst werden (implizite Erwartungen). Werden die Grundforderungen nicht erfüllt, entsteht Unzufriedenheit; werden sie erfüllt, entsteht aber keine Zufriedenheit. Die Nutzensteigerung im Vergleich zur Differenzierung gegenüber Wettbewerbern ist sehr gering. Am Beispiel Auto: Sicherheit, Rostschutz // unterbewusstes Wissen //  Für deren Ermittlung eignen sich besonders  Beobachtungstechniken und dokumentenzentrierte Techniken.

Leistungsfaktoren: Sind dem Kunden bewusst, sie beseitigen Unzufriedenheit oder schaffen Zufriedenheit abhängig vom Ausmaß der Erfüllung. Am Beispiel Auto: Fahreigenschaften, Beschleunigung, Lebensdauer, Verbrauch // bewusstes Wissen // Leistungsfaktoren lassen sich gut durch Befragungstechniken ermitteln.

Begeisterungsfaktoren: Sind Nutzen stiftende Merkmale, mit denen der Kunde nicht unbedingt rechnet. Sie zeichnen das Produkt gegenüber der Konkurrenz aus und rufen Begeisterung hervor. Eine kleine Leistungssteigerung kann zu einem überproportionalen Nutzen führen. Die Differenzierungen gegenüber der Konkurrenz können gering sein, der Nutzen aber enorm. Am Beispiel Auto: Sonderausstattung, besonderes Design // unbewusstes Wissen // Für die Ermittlung von Begeisterungsfaktoren sind Kreativitätstechniken geeignet.
 

Über die Zeit gesehen verändern sich die Eigenschaften, da ein Gewöhnungseffekt entsteht. Ein Begeisterungs-Merkmal kann zu einem Leistungs- und später zu einem Basis-Merkmal werden.

Wichtige Einflussfaktoren auf die Wahl der Ermittlungstechnik sind:

• Risikofaktoren
• menschliche Einflüsse
• organisatorische Einflüsse
• fachlich-inhaltliche Einflüsse
• der angestrebte Detaillierungsgrad der Anforderungen.

Befragungstechniken (z. B. Interview, Fragebogen) 

Kreativitätstechniken (z.B. Brainstorming, Brainstorming paradox, Perspektivwechsel, Analogietechnik) 

Dokumentenzentrierte Techniken (z.B. Systemarchäologie, Perspektivenbasiertes Lesen, Wiederverwendung von Anforderungen) 

Beobachtungstechniken (z.B. Feldbeobachtung, Apprenticing) 

Unterstützende Techniken (z.B. Mind Mapping, Workshops, CRC-Karten, Audio- und Videoaufzeichnungen, Use-Case-Modellierung, Prototypen)

Die Dokumentation nimmt bei der Kommunikation eine zielgerichtete, unterstützende Funktion ein. Folgende Faktoren machen diese Unterstützung notwendig:

• Anforderungen sind langlebig
• rechtlich relevant
• sollten allen zugänglich sein
• Anforderungsdokumente sind komplex.

Anforderungsdokumente umfassen (unter anderem) funktionale Anforderungen, welche üblicherweise folgende drei verschiedenen Perspektiven eines Systems repräsentieren:

• Strukturperspektive
• Verhaltensperspektive
• Funktionsperspektive