IREB - Requirements Engineering Foundation Level

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.