Arbeitsprodukte im Requirements Engineeering

Inhalte dieser Lerneinheit

Merkmale von Arbeitsprodukten

Im RE werden verschiedene Arten von Arbeitsprodukten verwendet. Sie zeichnen sich durch
ihren Zweck, ihre Darstellung, ihren Umfang und ihre Lebensdauer aus. Die folgenden
Arbeitsprodukte kommen in der Praxis für die angegebenen Zwecke häufig vor. Dabei ist zu
beachten, dass ein Arbeitsprodukt andere Arbeitsprodukte enthalten kann.

• Arbeitsprodukte für eine einzelne Anforderung umfassen individuelle Anforderungen
  und User Storys.

  Open

  

• Arbeitsprodukte für eine Menge von Anforderungen umfassen Use Cases, grafische
  Modelle jeglicher Art (LE 3.4), Aufgabenbeschreibungen, Beschreibungen externer
  Schnittstellen und Epics.

• Zu den Arbeitsprodukten für eine Anforderungsdokumentation gehören System-,
  Geschäfts-, Stakeholder- und Benutzer-Anforderungsspezifikationen, Produkt- und
  Sprint-Backlogs sowie Story Maps.

  Open

  

• Andere Arbeitsprodukte umfassen Glossare, Textnotizen, grafische Skizzen und
  Prototypen.
  
  

Arbeitsprodukte können in verschiedenen Formen dargestellt werden:

• Auf natürlicher Sprache basierend (LE 3.2)

• Vorlagenbasiert (LE 3.3)

• Modellbasiert (LE 3.4)

• Andere Darstellungen, wie Zeichnungen oder Prototypen (LE 3.7)

Die meisten Arbeitsprodukte werden elektronisch als Dateien, in Datenbanken oder in RE-Tools
gespeichert. Informelle, kurzlebige Arbeitsprodukte können auch auf anderen Medien
gespeichert werden, z.B. auf Papier oder als Post-It-Notizen auf einem Kanban-Board.

Bei der Betrachtung der Lebensdauer von Arbeitsprodukten unterscheiden wir zwischen drei
Kategorien:

• Kurzlebige Arbeitsprodukte: Erstellt, um die Kommunikation zu unterstützen und ein
  gemeinsames Verständnis zu schaffen.

• Sich weiterentwickelnde Arbeitsprodukte: Wachsen im Laufe der Zeit in mehreren
  Iterationen; benötigen einige Metadaten, Änderungskontrolle kann erforderlich sein.

• Langlebige Arbeitsprodukte: Wurden als Baseline erstellt oder freigegeben; benötigen
  einen vollständigen Satz an Metadaten; der Änderungsprozess muss eingehalten werden
  (LE 6).

Ein kurzlebiges Arbeitsprodukt kann (durch Aufbewahrung und Hinzufügen von Metadaten) in
ein sich weiterentwickelndes Arbeitsprodukt umgewandelt werden. Analog dazu kann ein
kurzlebiges oder sich weiterentwickelndes Arbeitsprodukt durch Integration in eine Basislinie
oder durch eine Freigabe zu einem langlebigen (dauerhaften) Arbeitsprodukt werden.

Kategorien von Arbeitsprodukten

Wie in LE 1.3 beschrieben, unterscheiden wir zwischen Systemanforderungen,
Stakeholderanforderungen, Benutzeranforderungen, Domänenanforderungen und
Geschäftsanforderungen. Einige Arbeitsprodukte wie einzelne Anforderungen, Skizzen oder
Prozessmodelle kommen in all diesen Kategorien vor. Andere Arbeitsprodukte sind speziell mit
bestimmten Kategorien verbunden.
Wenn Geschäftsanforderungen und Stakeholderanforderungen in langlebigen Arbeitsprodukten
wie z.B. in Spezifikationen für Geschäfts-, Stakeholderanforderungen oder Visions-Dokumenten
beschrieben werden, gehen sie der Spezifikation der Systemanforderungen voraus. In
vertraglichen Situationen, in denen ein Kunde beispielsweise die Entwicklung eines Systems bei
einem Lieferanten in Auftrag gibt, erstellt der Kunde häufig eine Spezifikation der
Stakeholderanforderungen und gibt sie frei. Der Anbieter erstellt dann auf dieser Grundlage eine
System-Anforderungsspezifikation. In anderen Projekten können sich Geschäfts-, Stakeholder-
und Systemanforderungen auch gemeinsam entwickeln.
Anforderungen existieren in der Regel auf vielen verschiedenen Abstraktionsebenen, von z.B.
abstrakten Anforderungen an einen neuen Geschäftsprozess bis hin zu Anforderungen auf einer
sehr detaillierten Ebene, wie z.B. die Reaktion einer Softwarekomponente auf ein
außergewöhnliches Ereignis.
Häufig sind Anforderungen in drei Abstraktionsebenen organisiert:

• Business

• System

• Komponenten

Die Wahl der richtigen Abstraktionsebene hängt davon ab, was spezifiziert werden soll. Es ist
jedoch wichtig, Anforderungen, die auf verschiedenen Abstraktionsebenen existieren, nicht zu
vermischen. In kleinen (z.B. einer User Story) und mittelgroßen (z.B. einem Use Case)
Arbeitsprodukten sollten die Anforderungen auf mehr oder weniger derselben
Abstraktionsebene liegen. In großen Arbeitsprodukten wie einer System-
Anforderungsspezifikation sollten Anforderungen auf unterschiedlichen Abstraktionsebenen
getrennt gehalten werden, indem die Spezifikation entsprechend strukturiert wird (LE 3.6).

Detaillierungsgrad von Arbeitsprodukten

Der Detaillierungsgrad, in dem die Anforderungen spezifiziert werden sollten, hängt
insbesondere von folgenden Faktoren ab:

• Problem und der Entwicklungskontext

• Grad des gemeinsamen Verständnisses des Problems

• Freiheitsgrad, der den Designern und Programmierern überlassen wird

• Verfügbarkeit von schnellem Stakeholder-Feedback während der Konzeption und
  Implementierung

• Kosten vs. Nutzen einer detaillierten Spezifikation

• Auferlegte Standards und regulatorische Einschränkungen

Je detaillierter die Anforderungen spezifiziert sind, desto geringer ist das Risiko, dass am Ende
etwas Unerwartetes oder nicht Spezifiziertes herauskommt. Die Kosten für die Spezifikation
steigen jedoch mit zunehmender Detaillierung.

Aspekte von Arbeitsprodukten

Bei der Spezifikation von Anforderungen in Arbeitsprodukten müssen verschiedene Aspekte
berücksichtigt werden.

(1) Die Anforderungen werden nach ihrer Art (LE 1.1) eingeteilt in:

a. Funktionale Anforderungen
b. Qualitätsanforderungen
c. Randbedingungen

(2) Die funktionalen Anforderungen konzentrieren sich auf verschiedene Aspekte eines
Systems:

a. Struktur und Daten
b. Funktion und Ablauf
c. Zustand und Verhalten

(3) Schließlich können Anforderungen nur im Kontext (Prinzip 4 in LE 2) verstanden
werden:

a. Systemkontext
b. Systemgrenze und externe Schnittstellen

Zwischen den genannten Aspekten gibt es viele Wechselbeziehungen und Abhängigkeiten.
Beispielsweise kann eine von einem Benutzer (Kontext) ausgehende Anforderung einen
Zustandsübergang (Zustand und Verhalten) auslösen, der eine Aktion auslöst, gefolgt von einer
weiteren Aktion (Funktion und Ablauf), die Daten (Struktur und Daten) benötigt, um dem
Benutzer (Kontext) innerhalb eines bestimmten Zeitintervalls (Qualität) ein Ergebnis zu liefern.
Einige Arbeitsprodukte konzentrieren sich auf einen bestimmten Aspekt und abstrahieren von
den anderen Aspekten. Dies gilt insbesondere für Anforderungsmodelle (LE 3.4). Andere
Arbeitsprodukte, wie z.B. eine System-Anforderungsspezifikation, decken all diese Aspekte ab.
Wenn verschiedene Aspekte in getrennten Arbeitsprodukten oder in getrennten Kapiteln
desselben Arbeitsprodukts dokumentiert sind, müssen diese Arbeitsprodukte oder Kapitel
miteinander konsistent gehalten werden.

Allgemeine Richtlinien für die Dokumentation

Unabhängig von den verwendeten Techniken gelten bei der Erstellung von Arbeitsprodukten die
folgenden Richtlinien:

• Wählen Sie einen Typ von Arbeitsprodukten aus, der den beabsichtigten Zweck erfüllt.

• Vermeiden Sie Redundanz, indem Sie auf Inhalte verweisen, anstatt denselben Inhalt noch
  einmal zu wiederholen.

• Stellen Sie sicher, dass es keine Inkonsistenzen zwischen den Arbeitsprodukten gibt,
  insbesondere wenn sie verschiedene Aspekte abdecken.

• Verwenden Sie Begriffe konsistent, so wie im Glossar definiert.

• Strukturieren Sie Arbeitsprodukte angemessen.

Planen der Arbeitsprodukte

Jeder Projektrahmen und jede Domäne ist anders, sodass für jedes Vorhaben die zu
entwickelnden Arbeitsprodukte ausgewählt werden müssen. Folgende Punkte müssen folglich
vereinbart werden:

• In welchen Arbeitsprodukten sollen die Anforderungen erfasst werden und zu welchem
  Zweck?

• Welche Abstraktionsebenen sind zu berücksichtigen?

• Bis zu welchem Detaillierungsgrad müssen Anforderungen auf jeder Abstraktionsebene
  dokumentiert werden?

• Wie sollen die Anforderungen in diesen Arbeitsprodukten dargestellt werden?

Die zu verwendenden Arbeitsprodukte sollten zu einem frühen Zeitpunkt im Projekt festgelegt
werden. Dies hat mehrere Vorteile:

• Es hilft bei der Planung von Aufwand und Ressourcen.

• Es stellt sicher, dass geeignete Notationen verwendet werden.

• Es stellt sicher, dass alle Ergebnisse in den richtigen Arbeitsprodukten erfasst werden.

• Es stellt sicher, dass keine größere Umstrukturierung von Informationen und keine
  „Schlussredaktion“ erforderlich ist.

• Es hilft, Redundanz zu vermeiden, was zu weniger Arbeit und besserer Wartbarkeit
  führt.