Dokumentieren von Anforderungen

tl/dr; (ca. 11 min Lesezeit): Es stehen die Wünsche der Stakeholder im Raum - und auch die Normen und Gesetze wollen als Anforderung dokumentiert werden. Welche unterschiedlichen Artefakte gibt es, in denen Anforderungen erfasst werden können, und wo eignen sie sich besonders?

Dieser Artikel ist Bestandteil einer mehrteiligen Reihe zu Requirements Engineering:

• Grundlagen Anforderungsanalyse: Wozu dient Anforderungsanalyse und welche Anforderungsarten und Qualitätsmerkmale gibt es?

• Haupttätigkeit Ermittlung: Woher kommen Anforderungen und mit welchen Techniken ermittle ich sie systematisch?

• (dieser Artikel) Haupttätigkeit Dokumentation: Auf welche Arten können Anforderungen dokumentiert werden?

• Haupttätigkeiten Validierung und Verwaltung: Wie kann die Qualität der Anforderungen überprüft werden, wie priorisiere ich sie, und wie verwalte ich sie im Projektverlauf?

Haupttätigkeit 2: Dokumentieren der Anforderungen (requirements documentation)

Je nach Vorgehensmodell und Granularität (Detailgrad) der erfassten Anforderungen können sich die Dokumentationsmittel unterscheiden.

Übersicht von Anforderungen

Um das big picture von Anforderungen zu erhalten bieten sich beispielsweise folgende Artefakte an:

• Wenn Anforderungen von Beginn an relativ fest stehen können oft textuelle Auflistung der Anforderungen vorab erfolgen:

  • In diesen Anforderungsdokumenten können funktionale und nicht-funktionale Anforderungen festgeschrieben werden. Der Grad an Formalität kann von Stichpunktlisten bis hin zu streng formellen Dokumenten reichen.

  • Das Lastenheft wird durch Auftraggeber erstellt: Was soll umgesetzt werden und warum? Es enthält oft noch keine technische Sicht und ist in der Sprache der Problemdomäne formuliert.

  • Im Pflichtenheft erarbeitet der Auftragnehmer wie und womit die Anforderungen des Lastenhefts umgesetzt werden sollen. Es beschreibt Werkzeuge und (grobe) Entwürfe und nutzt die Sprache der Lösungsdomäne. Das Pflichtenheft wird i.d.R. Vertragsbestandteil und sollte mit entsprechender Sorgfalt erstellt werden.

• Anwendungsfälle

  • “A use case is all the ways of using a system to achieve a particular goal for a particular user. Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide.” (Ivar Jacobson) ¹
  • Anwendungsfälle können in UML Use-Case-Diagrammen (Anwendungsfalldiagramm) graphisch und übersichtlich dargestellt werden

  

  • Mit Hilfe dieser einfachen grafischen Darstellungsform können Anwendungsfälle dialogisch mit Stakeholdern erarbeitet werden.
  • In Anwendungsfällen werden funktionale Anforderungen zusammengefasst, die gemeinsam von einem Akteur initiiert werden und dem Anwender einen Nutzen generieren.
  • Die einzelnen Anwendungsfälle können im nächsten Schritt tabellarisch präzisiert werden. Hierbei wird ein Name, eine kurze Beschreibung, ein auslösender Akteur, Randbedingungen sowie Haupt- und Nebenszenarien erfasst.
  • Einzelne Wege durch den Anwendungsfall werden als Szenarien definiert und als Stichpunktliste oder ggf. als UML Aktivitäts-, Zustands- oder Sequenzdiagramm entworfen.

• Product Backlog:

Vor allem im agilen Umfeld werden die Anforderungen häufig als einzelne isolierte Tasks gesammelt. Diese Tasks sollten - unabhängig von der genutzten Technik - so formuliert werden, dass sie den I.N.V.E.S.T.-Kriterien genügen:

Es kann hilfreich sein zur Formulierung der Anforderungen auf Satzschablonen zuzugreifen, um die Formulierungen einfach und präzise zu halten. Die bekannteste Satzschablone stellen die User Stories dar, die festlegen, dass Rolle des Nutzers, Ziel der Anforderung und der Nutzen für die Anwender genannt werden müssen:

Als ROLLE möchte ich ZIEL um zu NUTZEN

• Eine weitere Satzschablonen, mit deren Hilfe Anforderungen beschrieben werden können, ist die folgende:

Welche Informationen sollten zu Anforderungen erfasst werden?

Im Idealfall wird für jede Anforderung bereits im Vorfeld erfasst:

• Name der Anforderung / des Tasks

• Beschreibung (ggf. in Form von Satzschablonen)

• Akzeptanzkriterium: Messbare und mit Stakeholdern abgestimmte Bedingung, wann eine Anforderung als erfüllt gilt (besonders bei nicht funktionalen Anforderungen wichtig!)

• Grundlegende Testfälle (Eingabeparameter, Randbedingungen, erwartetes Ergebnis)

• Risiko bei Nichterfüllung / fehlerhafter Erfüllung

• Geschätzter Aufwand

Festlegung von Akzeptanzkriterien bei Qualitätsanforderungen

Nach der FURPS-Methodik ist die Beschreibung von Akzeptanzkriterien v.a. bei den Qualitäts- (also nicht funktionalen) Anforderungen schwierig. Es sollten nach Möglichkeit Metriken entwickelt und festgeschrieben werden, die die Erfüllung der Anforderung objektivieren. Ein paar Beispiele als Anhaltspunkt:

• U wie Usability: Ein Nutzer mit gegebenem Vorwissen muss eine definierte Aufgabe ohne Hilfe in einer definierten Zeitspanne abarbeiten können. Die Zeit wird gestoppt und das Verhalten des Nutzers beobachtet.

• R wie Reliability: Das System wird mit einem Smoketest bewusst an die Belastungsgrenze gebracht (definierte Anzahl an Zugriffen pro Zeiteinheit). Die akzeptablen Anwortzeiten oder verlorenen Pakete / Neustarts werden festgeschrieben. Informationen zu Abstürzen werden den Logfiles entnommen.

• P wie Performance: Analog zur Reliability werden für die maximal erwarteten Nutzungsdaten Antwortzeiten des Systems erfasst und als Metrik festgeschrieben.

• S wie Supportablity Hier kann z.B. festgeschrieben werden, wie lange ein Durchgang durch die CI/CD-Pipeline (also von der IDE bis zum getesteten Code in der Produktivumgebung) dauern darf. Die Update-Zyklendauer, die verpflichtende Benutzung von Clean-Code Metriken (zyklomatische Komplexität, Testabdeckung) geben darüber hinaus ein Maß der Wartbarkeit, dass vereinbart werden kann.

Wie geht es weiter?

Noch haben wir uns keine Gedanken gemacht, welche Anforderungen wirklich wichtig sind - und woran ich gute Anforderungen erkenne. Darum geht es im nächsten Blogpost zu …

… Validierung und Verwaltung von Anforderungen (requirement validation)

Leitfragen

• In welchen Dokumenten / Artefakten können Anforderungen gesammelt und gemanagt werden?

• Wie ist der generelle Aufbau von Userstories?

• Welche Anforderungen können in einem Use-Case-Diagramm dargestellt werden, welche nicht?

• Was versteht man unter I.N.V.E.S.T.-Kriterien?

• Wie können Anforderungen gegliedert werden?

Weitere Literatur zu Requirement-Engineering

• Das deutschsprachige Handbuch des IREB (Martin Glinz, Hans van Loenhoud, Stefan Staal, Stan Bühne: Handbuch für das CPRE Foundation Level nach dem IREB-Standard) findet sich hier als PDF

• Das Grundlagenbuch (auch zur Zertifizierung) für Anforderungsanalyse ist: Klaus Pohl, Chris Rupp: Basiswissen Requirements Engineering, dPunkt Verlag Heidelberg, ISBN 978-3-86490-814-9

• Weitere Unterlagen des International Requirement Engineering Boards zur Zertifizierung als “Certified Professional for Requirements Engineering Foundation Level”: https://www.ireb.org/de/cpre/foundation/, insbesondere Lehrplan und Glossar

Quellen und offene Ressourcen (OER)

Die Ursprungstexte (als Markdown), Grafiken und zugrunde liegende Diagrammquelltexte finden sich (soweit möglich in weiterbearbeitbarer Form) in folgendem git-Repository:

https://gitlab.com/oer-informatik/uml/umlanwendungsfall.

Sie sind bei Namensnennung (Hannes Stein) zur Nutzung als Open Education Resource (OER) freigegeben gemäß der Creative Commons Namensnennung 4.0 International Lizenz (CC BY 4.0).