IREB - Requirements Engineering Foundation Level

Manche Prozessworte benötigen mehr als ein Substantiv um vollständig spezifiert zu sein.

Bsp. übertragen

1. was
2. von wo
3. nach wo

kann auch bei Adjektiven und Adverben auftreten.

1. Sind ein Bauplan für die syntaktische Struktur einer einzelnen Anforderung.
2. Gut in Verbindung mit Projektglossar

1. Festlegung der rechtlichen Verbindlichkeit
2. Kern der Anfoderung
3. Charakterisieren der Aktivität des Systems
4. Objekte einfügen
5. Formulierung von logischen und zeitlichen Bedingungen

1. Prozess durch Ereignisbezeichnung eindeutlig beschreiben
2. Definition des nominalisierten Begriffes muss klären
   1. Verlauf des Prozesses
   2. potentiell auftretende Ausnahmen
   3. alle Eingabe-& Ausgabeparameter

Aktives Formulieren der Anforderung.

"Das System fragt den Nutzer nach seinem Passwort" anstelle von "Beim Login wird das Passwort übermittelt."

1. rechtlich bindend, dringen, empfohlen...
2. Modalwerben - muss, sollte, wird, kann

1. geforderte Funktionalität des Systems
2. Bsp: drucken; speicher; senden; berechnen

1. Selbstständige Systemaktivität
   1. Das System soll <Prozesswort>
2. Benutzerinteraktion
   1. Das System soll dem Nutzer die Möglichkeit bieten <Prozesswort>
3. Schnittstellenanforderung - System ist passiv
   1. Das System muss fähig sein <Prozesswort>

1. Die notwendige Objekte angeben.
2. Bsp: Drucken: Was wird gedruckt, wo wird gedruckt

1. An den Anfang wird die Zeitliche (solange, sobald) oder logische Bedingungen (wenn..) geschrieben

• Verschiedene Informationen verwalten 
• Logische Beziehungen zwischen Informationen verwalten 
• Jedes Artefakt eindeutig identifizieren 
• Informationen flexibel und sicher zugänglich machen, z.B. durch Zugriffskontrolle 
• Sichten auf die Informationen unterstützen 
• Informationen organisieren z.B. durch Attributierung und Hierarchiebildung
• Berichte über die Informationen erstellen 
• Dokumente aus den Informationen generieren

Die Werkzeugeinführung setzt klare Verantwortlichkeiten und Vorgehensweisen im RE voraus. Dabei sind die folgenden Gesichtspunkte zu beachten: 

• Benötigte Ressourcen planen 
• Risiken durch Pilotprojekte umgehen 
• Evaluierung anhand von definierten Kriterien 
• Über Lizenzkosten hinausgehende Kosten berücksichtigen 
• Benutzer schulen

Die Vielfalt der bei der Bewertung von RE -Werkzeugen zu beachtenden Aspekte lässt sich durch die folgenden sieben Sichten strukturieren: 

• Projektsicht (z.B. Unterstützung der Projektplanung) 
• Benutzersicht (insbesondere Bedienung) 
• Produktsicht (Funktionalität) 
• Prozesssicht (methodische Unterstützung) 
• Anbietersicht (z.B. Service des Anbieters) 
• Technische Sicht (z.B. Interoperabilität, Skalierbarkeit) 
• Betriebswirtschaftliche Sicht (Kosten)

Für jede Sicht sind klare Kriterien zu definieren.

Um die Anforderungen an ein System über den gesamten Lebenszyklus des Systems hinweg verwalten zu können, ist es notwendig, die Informationen zur Anforderung als Attribute möglichst strukturiert zu erfassen. Die Definition der Attributstruktur für Anforderungen erfolgt über ein Attributierungsschema, das entweder tabellarisch oder in Form eines Informationsmodells definiert werden kann.

Typische Attribute sind: 

• Identifikator 
• Name 
• Beschreibung 
• Quelle 
• Stabilität 
• Risiko 
• Priorität

Die "rechtliche Verbindlichkeit" kann ebenfalls anhand eines Attributes als zusätzliche Information zur Anforderung gespeichert werden.

Es werden zwei Ausprägungsformen der Sichtenbildung unterschieden: 

• Selektive Sichten: Darstellung einer Teilmenge der Attributwerte von über definierte Selektionskriterien ausgewählten Anforderungen. 
• Verdichtende Sichten: Darstellung verdichteter Informationen zu den über definierte Selektionskriterien ausgewählten Anforderungen

Anforderungen werden zu verschiedenen Zeitpunkten in verschiedenen Aktivitäten nach unterschiedlichen Kriterien priorisiert. Die Vorbereitung der Priorisierung von Anforderungen basiert auf einer einfachen Systematik: 

• Bestimmung der Ziele und Randbedingungen der Priorisierung 
• Bestimmung der Priorisierungskriterien 
• Bestimmung der relevanten Stakeholder 
• Auswahl der zu priorisierenden Artefakte

Auf Grundlage dieser Festlegungen werden dann eine oder mehrere Techniken zur Priorisierung ausgewählt und die eigentliche Priorisierung durchgeführt.

Zu den Priorisierungstechniken zählen: 

• Ranking und Top-Ten-Technik 
• Ein-Kriterium-Klassifikation 
• Kano-Klassifikation 
• Wiegers'sche Priorisierungsmatrix

Der Nutzen der Verfolgbarkeit von Anforderungen bezieht sich auf: 

• Vereinfachung der Nachweisbarkeit 
• Identifikation von unnötigen Eigenschaften im System 
• Identifikation von unnötigen Anforderungen 
• Unterstützung der Auswirkungsanalyse 
• Unterstützung der Wiederverwendung 
• Unterstützung der Festlegung der Zurechenbarkeit 
• Unterstützung der Wartung und Pflege

Hinsichtlich der Verfolgbarkeitsbeziehungen von Anforderungen werden drei Klassen von Verfolgbarkeitsbeziehungen unterschieden: 

Pre-Requirements-Specification-Traceability ( = bezeichnet die Nachvollziehbarkeit zwischen Anforderungen und ihrer Quelle. Beispiel: Welcher Stakeholder interessiert sich für welche Anforderung?)

Post-Requirements-Specification-Traceability  ( = bezieht sich auf Anforderungen und ihre Beziehungen zu anderen Artefakten wie Entwurf, Code, Testfälle etc. Beispiel: Wie wurde eine Anforderung implementiert?)

Traceability zwischen Anforderungen ( = bezieht sich auf die Beziehung von Anforderungen wie Business-, Stakeholder- oder Solution-Requirements untereinander sowie zu ihrer Dokumentation bspw. im Lastenheft.) 

Die Verfolgbarkeitsinformationen von Anforderungen können unterschiedlich repräsentiert werden. Typische Repräsentationsformen sind: 

• Textuelle Referenzen und Hyperlinks 
• Verfolgbarkeitsmatrizen 
• Verfolgbarkeitsgraphen

Eine Anforderungskonfiguration fasst eine definierte Menge logisch zusammengehöriger Anforderungen zusammen, wobei jede Anforderung maximal in einer Version in der Anforderungskonfiguration enthalten ist.

Die Bildung von Anforderungskonfigurationen wird dabei entlang zweier Dimensionen definiert: 

• Produktdimension: die einzelnen Anforderungen der Anforderungsbasis 
• Versionsdimension: die verschiedenen Versionsstände einer Anforderung

Die Versionsnummer einer Anforderung besitzt dabei mindestens zwei Bestandteile: 

• Version 
• Inkrement

Anforderungskonfigurationen besitzen einige typische Eigenschaften: 

• sachlogischer Zusammenhang der Anforderungen einer Konfiguration 
• Konsistenz der Anforderungen innerhalb der Anforderungskonfiguration 
• Eindeutiger Identifikator der Anforderungskonfiguration 
• Unveränderbarkeit der Anforderungen innerhalb der Anforderungskonfiguration 
• Grundlage für das Rücksetzen auf frühere Versionen der Anforderungsbasis

Anforderungsbasislinie = ausgezeichnete Anforderungskonfigurationen, die stabile Versionen von Anforderungen umfassen & oftmals auch Auslieferungsstufen des Systems (Systemreleases) definieren

• Verwaltung von Anforderungsänderungen nötig, da sich Anforderungen über den gesamten Lebenszyklus verändern
• Änderungen werden in einem systematischen Änderungsmanagementprozess verwaltet und bearbeitet
• Darin ist das Change-Control-Board für die Bearbeitung eingehender Änderungsanträge verantwortlich

Änderungen werden in einem systematischen Änderungsmanagementprozess verwaltet und bearbeitet. Darin ist das Change-Control-Board für die Bearbeitung eingehender Änderungsanträge verantwortlich. Aufgaben des Change-Control-Boards für Änderungsantrage:

• Klassifikation
• Aufwandsbestimmung
• Beurteilung hinsichtlich Aufwand / Nutzen
• Definition neuer Anforderungen auf Basis eingehender Änderungsanträge
• Entscheidung über Annahme oder Ablehnung
• Priorisierung
• Zuordnung zu Änderungsprojekten 

Typische Vertreter im Change-Control-Board:

• Änderungsmanager
• Auftraggeber
• Architekt
• Nutzervertreter
• Qualitätsbeauftragter
• Anforderungsingenieur

Mindestens folgende Informationen sind im Änderungsantrag:

• Identifikator
• Titel
• Beschreibung der Änderung
• Begründung der Notwendigkeit
• Datum der Beantragung
• Antragsteller
• Priorität der Änderung aus Sicht des Antragstellers

3 Arten von Änderungsanträgen:

• Korrektiv
• Adaptiv
• Ausnahmeänderung

Das Vorgehen des Änderungsmanagement ist: 

• Auswirkungsanalyse und Beurteilung des Änderung 
• Priorisierung der Anforderungsänderung 
• Zuordnung der Änderung zu einem Änderungsprojekt 
• Kommunikation der Annahme/Ablehnung des Änderungsantrags

Die Qualität von Anforderungsdokumenten kann anhand von Information aus Anforderungsvalidierung und - verwaltung, wie z.B. Fehler, Attribute, Verfolgbarkeitsbeziehungen oder Änderungen, analysiert werden. Darauf aufbauend können Verbesserungen identifiziert werden.

Typische Messdaten sind

• Änderungsraten von Anforderungen 
• Fehler in Anforderungen

1. Die Sicherstellung des Erreichens von Qualitätskriterien  (Korrektheit, Abgestimmtheit etc.)
2. sowohl einzelne Anforderungen, als auch ganze Anforderungsdokumente

Unaufgelöste Konflikte in den Anforderungen eines Systems führen z.B. dazu, dass Anforderungen einer Gruppe von Stakeholdern nicht umgesetzt werden können bzw. dass das System im späteren Betrieb nicht oder nur unzureichend akzeptiert und genutzt wird.

Das Ziel der Abstimmung von Anforderungen ist es, unter den relevanten Stakeholdern ein gemeinsames und übereinstimmendes Verständnis hinsichtlich der Anforderungen an das zu entwickelnde System zu erarbeiten.

Es werden drei Qualitätsaspekte für Anforderungen unterschieden:

• Inhalt
• Dokumentation
• Abgestimmtheit