IREB - Requirements Engineering Foundation Level

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

1. Vorteile
   1. natürliche Sprache -> kein Stakeholder muss eine neue Notation lernen
   2. am häufigsten benutzt
   3. kann alle Arten und Persepktiven beschreiben
2. Nachteile
   1. nicht eindeutig -> Missinterpretationen möglich
   2. leichte Vermischung von mehreren Perspektiven

1. Use-Case-Diagramm (F)
2. Aktivitätsdiagramm (F)
3. Klassen-Diagramm (S)
4. Zustandsdiagramm (V)

1. kombiniert die Vorteile beider Dokumentationsformen
2. Nachteile werden weitestgehend verringert
3. Entscheidungen, Erläuterungen & relevante Informationen direkt am Diagramm 

Bsp: Modell mit Prosa-Kommentaren

Bsp. Glossar mit Diagramm

Modelierungssprachen, die immer auf eine Perspektive abzielen.

1. Vorteil:
   1. hoher Grad an Eindeutigkeit
   2. kompakte Darstellung
   3. der geübte Leser versteht den Inhalt schnell
   4. decken nur eine Perspektive ab
   5. daher ist bei der Nutzung von verschiedenen KM klar, dass alle Perspektiven beachtet wurden
2. Nachteil
   1. man muss eine Notation lernen
   2. Modellierungskenntnisse notwendig

1. schnell Einarbeitung neuer Mitarbeiter
2. schnelle Erfassung bestimmter Inhalte
3. ermöglicht selektives Lesen & Überprüfungen von Anforderungsdokumente
4. ermöglicht eine automatische Prüfung
5. ermöglicht Wiederverwendung von Inhalten

Die Standardgliederungen nach IEEE 29148:2011! umfasst 5 Teile

1. Kapitel: einführenden Informationen
2. Kapitel: Auflistung referenzierten Dokumente
3. Kapitel: spezifischen Anforderungen
4. Kapitel: geplanten Verifikationsmaßnahmen
5. Anhänge

1. Einleitung
2. Allgemeine Übersicht
3. Anforderungen (funktional und qualitativ)
4. Anhang (weiterführende Infos)
5. Index/Inhalsverzeichnis

Anforderungsdokumente dienen im Laufe der Projektlaufzeit als Grundlage für verschiedene Aufgaben, wie z.B.

• Planung 
• Architekturentwurf 
• Implementierung 
• Test 
• Änderungsmanagement 
• Systemnutzung und Systemwartung 
• Vertragsmanagement

1. Eindeutigkeit & Konsistenz 
2. klare Strukturen
3. Modifizierbarkeit und Erweiterbarkeit
4. Vollständigkeit 
5. Verfolgbarkeit

Auch die einzelnen Anforderungen müssen bestimmten Qualitätskriterien genügen, insbesondere: 

• Abgestimmt 
• Eindeutig 
• Notwendig 
• Konsistent 
• Prüfbar 
• Realisierbar 
• Verfolgbar 
• Vollständig 
• Verständlich

Neben den Qualitätskriterien für Anforderungen gibt es zwei weitere elementare Stilregeln für natürlichsprachige Anforderungen, welche die Lesbarkeit fördern: 

• kurze Sätze und Absätze 
• nur eine Anforderung pro Satz formulieren.

Ein Glossar ist eine Sammlung von Begriffsdefinitionen mit dem folgenden Inhalt:

1. Kontextspezifische Fachbegriffe
2. Alltägliche Begriffe, die im Kontext eine spezifische Bedeutung haben
3. Abkürzungen und Akronyme
4. Synonyme
5. Homonyme

Für ein Glossar sind nachfolgende Umgangsregeln zu beachten: 

• Das Glossar muss zentral verwaltet werden 
• Es müssen Verantwortlichkeiten zur Glossarpflege definiert werden 
• Das Glossar muss projektbegleitend gepflegt werden 
• Das Glossar muss allgemein zugänglich sein
• Das Glossar muss verbindlich verwendet werden 
• Die Herkunft der Begriffe sollte im Glossar enthalten sein. 
• Das Glossar muss mit den Stakeholdern abgestimmt sein 
• Die Einträge des Glossars müssen eine einheitliche Struktur aufweisen

Es ist vorteilhaft, möglichst frühzeitig mit der Erarbeitung des Glossar zu beginnen, um den späteren Angleichungsaufwand zu reduzieren.

Die Struckturperspektive stellt die Struktur des Systems und die Kommunikation zwischen verschiedenen (Teil)-Systemen dar. Sie wird in Komponentendiagramm, Klassendiagramm, ER-Diagramm dargestellt und umfasst:

1. Input & Output
2. Nutzungs- und Abhängigkeitsbeziehungen

Die Funktionsperspektive zeigt die Funktionalität aus Sicht des Benutzers. Sie wird mit  Use Cases (+Beschreibungen) und Aktivitätsdiagramme dargestellt. Die wichtigesten Aspekte sind:
 

• welche Daten des Kontextes werden manipuliert
• welche Daten fließen in den Kontext
• ggf. Systematik zur Verarbeitung von Eingabedaten

Die Verhaltensperspektive zeigt die Reaktionen auf Ereignisse und Zustandswechsel. Am häufigsten werden Zustandsdiagramm, Entscheidungsbäume, Und/Oder-Bäume verwendet. Die folgenden Aspekte werden in dieser Perspektive abgedeckt:

1. Einbettung in den Systemkontext
2. z.B.Reaktion bei Ereignissen im Kontext
3. z.B.Effekte des Systems in einem anderen System / der Umgebung

1. Funktionen das System für den Nutzer
2. Verbindung mit externen Interaktionspartnern

1. statische Strukturen von Daten
2. Darstellung statisch-strukturelle Abhängikeiten von System und Kontext
3. strukturierte Darstellung komplexe Begriffssyteme

1. kann Geschäftsprozesse abbilden
2. kann ablauforientierte Abhängigkeiten des Systems dokumentieren
3. Ablauflogik eines Use Cases
4. detailierte Spezifikation eines Verarbeitungsmechanismus

1. Zustände des Systems
2. Bedingungen zum Zustandswechsel
3. Effekte des Systems in der Umgebung