Requirements Engineering Technische Exzellenz

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

2 Minuten Lesezeit

05. Februar 2019

4:27

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	Um eine Übersicht der wichtigsten Funktionsblöcken eines Systems zu erhalten Für Systeme, die mit einem Benutzer interagieren Als Teil einer Produkt Vision, siehe auch Wie kann ich meinen Produkt Scope visualisieren?
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.

Teamentwicklung So aktivieren wir Teams.

Autor

David Berger

Ich befähige wissensintensive R&D-Organisationen, leistungsfähiger zu werden in einem Umfeld, das gleichzeitig schneller, komplexer und regulierter wird. Mein Fokus liegt auf der Zusammenarbeit: innerhalb von Teams, zwischen Disziplinen und auf Ebene der Gesamtorganisation. Und muss die Organisation sich anpassen, gestalte und begleite ich diesen Prozess. Das Ziel ist immer dasselbe: eine Organisation, die verlässlich liefert, ohne sich dabei zu verbiegen oder die Menschen zu ruinieren.