dot.tipp - Wie kann ich meine Anforderungen sinnvoll dokumentieren?

David Berger
05. Februar 2019

Der Kurs "IREB Certified Professional for Requirements Engineering Foundation Level" (kurz IREB CPRE FL) liefert eine Fülle von Techniken zum Dokumentieren von Anforderungen. Eine häufig gestellte Frage unserer Kunden ist, welche Technik sich für welchen Kontext eignet.

Und zwar im klassische Requirements Engineering wie auch im agilen Backlog Refinement in z. B. Scrum. In diesem Blogbeitrag wollen wir hierauf antworten. Damit die richtige Spezifikationsform für den richtigen Kontext gewählt werden kann. 

Requirements Engineering ist Kommunikation

Einige der Gründe nach IREB, warum man Anforderungen dokumentieren soll, ist die Zugänglichkeit und Kommunizierbarkeit von Anforderungen. Eine lediglich in meinem Kopf existierende Anforderung ist für andere nicht zugänglich. Also muss sie kommuniziert werden. Zugänglichkeit und Kommunikation werden zu einem hohen Grad durch Dokumentation erfüllt.

Drei Perspektiven auf Anforderungen

IREB selbst benennt unterschiedliche Dokumentationsformen. Seien es informale wie Prosa, semiformale wie Satzschablone und Use Case Specification oder formale wie UML. Der einzige Hinweis von IREB, welche Technik sich wann eignet, sind die sogenannten Perspektiven auf Anforderungen, vor allem im Kontext der Modellierung von Anforderungen.

  • Strukturperspektive: Beschreibt die Struktur von Daten und deren Beziehungen sowie Attribute.
  • Funktionsperspektive: Beschreibt Abläufe, die Daten manipulieren, deren Bedingungen und Verzweigungen.
  • Verhaltensperspektive: Beschreibt die Zustände von Daten aufgrund deren Manipulationen und mögliche Übergänge.

Wir bei der dot consulting AG bieten unseren Kunden jeweils eine weitaus pragmatischere Tabelle, die darstellt, welche Dokumentationsform sich für welchen Kontext anbietet. Das gewählte Vorgehensmodell (klassisch oder agil) beeinflusst unseres Erachtens die Wahl der Dokumentationsform nicht. Diese Tabelle gilt also auch für agile oder klassische Entwicklungsvorhaben. 

Übersicht der Notationsformen

Notationsform Kontext
UML Sequenzdiagramm
  • Sobald unterschiedliche Komponenten betroffen sind
  • Wenn ein Informationsfluss über mehrere Schichten/Rollen visualisiert werden muss
  • Für Service-Architekturen
UML Aktivitätsdiagramm
  • Für interne Backend-Logiken
  • Für Batch-Spezifikationen
  • Für Workflow-Spezifikationen
  • Für Ausdetaillierung von Geschäftsregeln
  • Sobald ein Ablauf mit Verzweigungen, Parallelisierungen und Optionen aufgewertet ist
UML Klassendiagramm
  • Als Glossar auf einer mittleren Abstraktionsstufen, um das Verständnis über die Fachbegriffe zu schärfen
  • Als Spezifikation eines Domain-Modells, das Input für die Entwicklung ist
  • Für Anwendungen mit Fokus auf CRUD-Operationen
UML Zustandsdiagramm
  • Für "Life-Cycle"-Anforderungen einzelner Klassen (z. B. die Zustände eines Dossiers, eines Kunden, eines Vertrages etc.)
  • Für eingebettete Systeme, die einen Zustandswechsel dem Benutzer signalisieren müssen (z. B. System in Betrieb, System im Fehlermodus etc.)
  • Für innere Systembetrachtungen
UML Use Case Diagramm
Satzschablone
  • Für grobe Anforderungen einer hohen Abstraktionsstufe
  • Für nicht-funktionale Anforderungen (z. B. für Qualitätsanforderungen die Schablone namens Planguage)
GUI Mockups
  • Für GUI-lastige Anforderungen
  • Sobald die Logik mehrheitlich im GUI abgebildet ist und nicht durch "unsichtbare" oder "verborgene" Services/Batches
IREB Kontextanalyse
  • Um eine Übersicht der Aspekte zu erhalten, die potenziell Anforderungen ans entwickelnde System stellen
  • Als gemeinsame Übung für eine Art "Kickoff" eines Entwicklungsvorhabens
  • Als Teil einer Produkt Vision, siehe auchWie kann ich meinen Produkt Scope visualisieren?


Mehr erfahren?

In unserem Kurs IREB Certified Professional for Requirements Engineering (CPRE) Foundation Level (FL) üben wir gemeinsam, welches Modell sich am besten für welchen Zweck eignet. Wir liefern einerseits einen Erfahrungsaustausch, andererseits die notwendige Theorie, damit die Teilnehmenden die Zertifikatsprüfung von IREB realistisch bestehen können. Für mehr Effective Delivery in der Schweiz.

Requirements Engineering lernen

Keine Kommentare bis jetzt

Lass uns wissen, was du darüber denkst.

Newsletter Anmeldung