Mit mehr als zwei Jahren Verspätung konnte Anfang 2014 der neue ICE 3 von der Deutschen Bahn erstmals in Aktion präsentiert werden. Insbesondere die Funktionalität der Software zur Zugsteuerung entsprach lange Zeit nicht den Anforderungen des Eisenbahn-Bundesamtes und führte zu dieser Verzögerung.
Zunehmender Funktionsumfang und sich verkürzende Innovationszyklen in der Produktentwicklung führen in der Industrie seit vielen Jahren zur Frage, wie sich die daraus ergebende Komplexität und Dynamik ausreichend und effizient beherrschen lassen. Das Requirements Engineering als Methode der Wahl gehört im Bereich der Softwareentwicklung seit vielen Jahren zum Stand der Dinge. Nach dem Überwinden der Lernkurve steht dem Anwender ein praxiserprobtes und leistungsfähiges Vorgehensmodell zur Verfügung, das ein mögliches Chaos verringert.
Auch die Deutsche Bahn verweist übrigens in Veröffentlichungen auf diese Methode: „Anforderungsmanagement bei der Deutschen Bahn AG: Der Schlüssel zur nachhaltigen Beschaffung von Schienenfahrzeugen“ (41. Schienenfahrzeugtagung).Der Idee, einzelne Methodenbausteine aus dem Vorgehensmodell des Requirements Engineering fachübergreifend einzusetzen, wird meist noch wenig Aufmerksamkeit gewidmet. Der Nutzen dieser Methoden und Vorgehensweisen für die Technische Kommunikation wird jedoch schnell klar, wenn man zum Beispiel anzuwendende Normen und Richtlinien systematisch auszuwerten beginnt oder als zweites Beispiel durch Anforderungen ein geeignetes Content-Management-System auswählen muss. In den zwei beispielhaften Fällen ist in knapper Zeit eine Anzahl schnell wachsender Checklisten zu erstellen, zu ergänzen und zu aktualisieren.
Beispiel Normen und Richtlinien
Die Technische Kommunikation unterliegt heute einer Vielzahl normativer Anforderungen, insbesondere die Bereiche Normen und Richtlinien zeichnen sich dabei durch Dynamik und inhaltliche Unübersichtlichkeit aus. Zu den Forderungen einzuhaltender EU-Richtlinien kommt eine Vielzahl an Fach-, Sicherheits- und Produktnormen. Sie gilt es auszuwerten und einzuhalten. Daraus resultierende Checklisten erreichen normalerweise einen Umfang von mehreren Hundert Einzelanforderungen, deren Erfüllungsgrad durch Dokumente wie Betriebsanleitung und Ersatzteildokumentation sichergestellt werden muss. Aus einer detaillierten Analyse der DIN EN 82079-1 resultieren beispielsweise mehr als 400 Einzelanforderungen.
Abb. 1 Zahlreiche Anforderungen aus Normen und Richtlinien ergeben umfangreiche Listen.
Quelle Tilo Ried
Unklare Formulierungen, nicht atomar strukturierte Anforderungen sowie Redundanz und unklarer Status erschweren nicht nur die Anwendung der Checkliste, sondern machen eine spätere Aktualisierung und Pflege des Anforderungsapparates unmöglich. Spätestens jetzt wird deutlich, warum sich der professionelle und effiziente Umgang mit Anforderungen zu einem eigenen methodischen Feld, dem Requirements Engineering ausgewachsen hat. Grund genug, einzelne Bausteine des Requirements Engineering auch für diesen Bereich anzuwenden.
Beispiel Systemauswahl
Um ein geeignetes Redaktionssystem erfolgreich auswählen und einführen zu können, ist die Dokumentation der fachlichen Anforderungen unabdingbar. Erst wenn die Anforderungen in geeigneter Struktur vorliegen, ist es möglich, einen Anbieter zu bewerten, eine vertragliche Grundlage für dessen zu erbringende Leistungen zu definieren und das ausgewählte und angepasste System zu testen und abzunehmen.
In typischen Ablösungs- oder Einführungsprojekten sind neben Festlegungen zum Soll-Prozess und festgelegten Anwendungsfällen (Use Cases) Einzelanforderungen im dreistelligen Bereich zu erfassen, zu dokumentieren, zu priorisieren und gegen die gelieferten Leistungen des ausgewählten Systemanbieters zu prüfen. In Kombination mit weiteren Spezifikationsmethoden wie Anwendungsfällen ergeben sich in der Praxis Anforderungslisten mit rund 200 Anforderungen. Letztlich steht und fällt der Erfolg eines IT-Projektes meist auf Detailebene. Eine erfolgreiche Kommunikation der eigenen Vorstellungen und eine vertragssichere Abnahme der erbrachten Leistungen erfordern daher die richtige Struktur der Einzelanforderungen.
Weitere Einsatzfelder
Die Erkenntnisse aus den bereits schon genannten, für viele Redaktionen typischen Einsatzfeldern „Normen und Richtlinien“ und „Systemauswahl“ lassen sich auf weitere Bereiche der Technischen Kommunikation erweitern. So enthält beispielsweise ein leistungsfähiger Redaktionsleitfaden eine große Anzahl an Anforderungen an die Anwenderdokumentation oder ein geeignetes Publikationslayout ist durch eine detaillierte Liste an Einzelanforderungen vollständig spezifizierbar.
Die folgenden Grundlagen des Requirements Engineering werden mit Bezug auf die Auswertung von Normen und Richtlinien und IT-Projekte wie Systemauswahl erläutert, sind aber wie schon gesagt auf andere Bereiche übertragbar.
Atomare Anforderungen
Erster und wichtigster Schritt für ein leistungsfähiges Requirements Engineering ist die Zerlegung von Anforderungskomplexen in atomare Einzelanforderungen, also möglichst kleinteilig. Anforderungen aus Normen und Richtlinien ebenso wie Anforderungen an ein geeignetes Redaktionssystem lassen sich erst dann überprüfen, wenn jeweils nur eine fachliche Forderung enthalten ist.
Die Maschinenrichtlinie 2006/42/EG fordert beispielsweise in 1.7.4.2 k) als Inhalt der Betriebsanleitung „Hinweise zur Inbetriebnahme und zum Betrieb der Maschine sowie erforderlichenfalls Hinweise zur Ausbildung bzw. Einarbeitung des Bedienungspersonals“. Um eine anwendbare Checkliste aufzubauen, ist dieses Anforderungskonglomerat auf vier oder auch sechs einzelne Anforderungen aufzuteilen: Inbetriebnahme und Betrieb in Kombination mit Ausbildung und Einarbeitung.
Gleiches gilt für eine Anforderung an ein Redaktionssystem, in der „Modularisierung, Versionierung und XML“ gefordert werden. Erst eine Auftrennung in drei einzelne Anforderungen erlaubt die Bewertung möglicher Unterstützung durch ein konkretes System. Insbesondere Satzkonstruktionen mit „und“ oder Aufzählungen mit Komma sind Hinweise auf fehlende atomare Zerlegung von Anforderungskomplexen.
Voraussetzung für Klarheit
Wesentlicher Aspekt erfolgreicher Dokumentation von Requirements ist die Standardisierung und Vereinheitlichung der Formulierung. Fordert man zusätzlich, dass jede Anforderung für sich vollständig verstehbar sein muss, kommt man schnell zu einem so genannten Boilerplate-Konzept. Darin stellen Lückentexte die Standardisierung und Vereinzelung der Anforderungen sicher. Für die Inhalte aus dem genannten Beispiel 1.7.4.2 k) der Maschinenrichtlinie lassen sich folgende Lückentexte anwenden:
- „Die Betriebsanleitung berücksichtigt <…>“
- „Die Betriebsanleitung enthält <…> zu <…>“
- „Die Betriebsanleitung enthält <…> zu <...>, wenn <...>“
Ausgefüllt ergeben sich Anforderungen wie
- „Die Betriebsanleitung enthält <Hinweise zur Inbetriebnahme der Maschine>.“
- „Die Betriebsanleitung enthält <erforderlichenfalls Hinweise zur Ausbildung des Bedienpersonals für den Betrieb>.“
Analog lassen sich Standardformulierungsmuster für die Spezifikation von Anforderungen an IT-Systeme vorgeben:
- Das Redaktionssystem <verwaltet Abbildungen als wiederverwendbare Module>.
- Das Redaktionssystem <ermöglicht die Vorübersetzung auf Modulebene>.
Die Redundanz, die sich durch diese Art der Standardisierung von Anforderungsformulierungen ergibt, ermöglicht im Gegenzug das Verständnis jeder Anforderung für sich. Sie erhöht aber auch den Umfang der Anforderungsdokumente und den Aufwand bei der Erstellung. Die Erfahrung aus konkreten Projekten lässt den Autor des Beitrags normalerweise redundante Formulierungsmuster verwenden.
Identifikation und Benennung
Folgt man der Methode atomar zerlegter Anforderungen, dann stellt sich auf Grund der sich ergebenden hohen Anzahl an Einzelanforderungen schnell die Frage nach Identifikation und Benennung. Löst eine fortlaufende Nummer (ID) für jede Anforderung noch das Problem der eindeutigen Identifikation, bringt jede aussagekräftige Benennung einen Mehraufwand, aber auch einen deutlichen Mehrwert.
Für die Suche in einer umfänglichen Anforderungsliste bietet eine saubere Benennung unschätzbare Vorteile. Die kurzen Benennungen für die beispielhaften Anforderungen aus 1.7.4.2 k) der Maschinenrichtlinie zeigen die Vorgehensweise:
- Inbetriebnahme der Maschine
Die Betriebsanleitung enthält Hinweise zur Inbetriebnahme der Maschine. - Ausbildung des Bedienpersonals für Inbetriebnahme
Die Betriebsanleitung enthält erforderlichenfalls Hinweise zur Ausbildung des Bedienpersonals für die Inbetriebnahme.
Abb. 2 Vergleichbare Anforderungen aus unterschiedlichen Quellen unter einer Benennung.
Quelle Tilo Ried
Das folgende Beispiel aus einer Anforderungsliste zur Systemauswahl zeigt die gleiche Vorgehensweise. Zusätzlich wird deutlich, welchen Wert eine Strukturierung der Anforderungslisten durch Kapitel und Unterkapitel besitzt:
5.4 Suchfunktionen
5.4.1 Die Volltextsuche in Objekten ist möglich
5.4.2 Die Volltextsuche in Metadaten ist möglich
5.4.3 Die Volltextsuche in Dokumenten ist möglich
Je nach Projekt- oder Anwendungsfokus ist es sinnvoll, einzelne Anforderungen durch Metadaten weiter zu qualifizieren:
- Autor, Eigentümer
- Erfassungs-/Änderungsdatum
- Status (Vereinbarung/Bearbeitungsstand/Überarbeitungsstand)
- Priorität, Gewichtung, Erfüllungsgrad (voll, teilweise, nicht)
- Anwendbarkeit (muss, kann, nicht anwendbar)
Die Metadaten zeigen, welche Möglichkeiten bestehen und bewusst ausgewählt und genutzt werden können.
Deutlich weiter gehen Metadaten, wenn die Beziehungen der Anforderungen untereinander modelliert werden:
- In Abhängigkeit (mit Anforderung XY)
- Im Widerspruch (zu Anforderung XY)
Anforderungen aus Normen und Richtlinien werden in ihrer praktischen Anwendung normalerweise durch die Eigenschaften der Quellnorm oder -richtlinie qualifiziert. Wenn klar ist, welche Norm anzuwenden ist, sind die entsprechenden Anforderungen automatisch mit ausgewählt und für die Anwendung qualifiziert. In der Praxis lohnt es sich daher oft nicht, Metadatensysteme wie die Folgenden aufzubauen und zu pflegen:
- Formale Anforderung (geforderte Nachweise etc.)
- Anforderungen an Layout (Schriftgröße, Farben etc.)
- Bezug zu geforderten Gegenständen (Persönliche Schutzausrüstung, Sicherheitseinrichtung etc.)
- Lebensphase (Montage, Transport, Betrieb etc.)
Überprüfbarkeit sicherstellen
Strukturiert und standardisiert erfasste Anforderungen erhalten ihren Wert aus der Möglichkeit, ihre Einhaltung eindeutig zu bewerten. Dafür ist neben einer atomaren Struktur die Vermeidung „weicher“ Forderungen notwendig. Beispielsweise fordert DIN EN ISO 12100:2010 in 6.4.5.2 f ein „Inhaltsverzeichnis“: „Falls die Betriebsanleitung umfangreich ist, sollte ein Inhaltsverzeichnis verwendet werden.“
Die weiche Spezifikation mit „umfangreich“ ist allerdings nicht für eine eindeutige Bewertung im Anwendungsfall ausreichend. Hier sind weitere Anforderungen aus anderen Normen notwendig. Alternativ kann auch eine ergänzende Festlegung durch den Anwender erfolgen, zum Beispiel durch „bei mehr als 30 Seiten“.
Praxisbeispiele für eine fehlende Überprüfbarkeit von Einzelanforderungen aus Spezifikationen an IT-Systeme sind durch Formulierungen wie die folgenden geprägt:
- Das Redaktionssystem stellt eine einfache Suche zur Verfügung.
- Der Redakteur kann ein Modul schnell an beliebiger Stelle einfügen.
- Das Redaktionssystem unterstützt den Anwender durch eine elegante Indexierungsfunktionalität.
Durch solche Formulierungen ist spätestens bei der Abnahme des Systems eine unfruchtbare Diskussion mit dem Systemanbieter vorprogrammiert. Insbesondere im IT-Bereich ist im Pflichtenheft Vertrags- und Leistungssicherheit mit Formulierungen wie einfach, schnell oder auch elegant nicht zu erreichen.
Vor der Vertragsunterzeichnung sollten daher sprachliche und strukturelle Anforderungen an ein gutes Pflichtenheft des Systemlieferanten festgelegt werden. Werbliche Formulierungen unüberprüfbarer Zusicherungen gilt es zurückzuweisen. Auch ein Pflichtenheft unterliegt in der Regel einer Abnahme.
Abb. 3 Vergleichbare Anforderungen aus unterschiedlichen Quellen unter einer Benennung.
Quelle Tilo Ried
Systemunterstützung sinnvoll
Tabellen aus Microsoft Excel stellen oftmals die erste Systemgrundlage für die systematische Erfassung und Verwaltung von Anforderungen aus Normen und Richtlinien oder für die Dokumentation von IT-Requirements dar. Die Anzahl der verwendeten Spalten zeigt in der Praxis, wie umfangreich ein leistungsfähiges Datenmodell für Verwaltung und Nutzung ist. Folgende minimale Beschreibungsaspekte für normative Anforderungen stammen aus der Praxis:
- Name der Anforderung
- Kurzbeschreibung der Anforderung
- Quelle der Anforderung (Nummer der Norm/Richtlinie, Ausgabedatum, Name der Norm/Richtlinie, Sprache, Kapitel/Unterkapitel, Seite)
- Originaltext der Anforderung (Vorsicht, hier lauern Gefahren aus Urheberrecht)
- Anwendungshinweise und Ergänzungen
In Kombination mit den Filterfunktionen von Excel und mit einer geeigneten hierarchischen Struktur (Gruppierung der Daten) ergeben sich Checklisten, die sich anwenden und pflegen lassen.
Von der Tabelle zur Datenbank
Die Grenzen von Excel werden bei der Umsetzung relationaler Datenmodelle schnell deutlich. Gleiche Zelleninhalte können mehrfach vorkommen und nicht so einfach an zentraler Stelle geändert werden. Ein Requirement kann beispielsweise auf Anforderungen aus mehreren Normen zurückgehen, diese „1 : n-Relation“ ist in einer flachen Excel-Tabelle nur durch redundante Inhalte zu erfassen.
Vielen Anwendern mit IT-Kenntnissen erscheint daher die Idee naheliegend, eine Datenbank mit Office-System selbstzuentwickeln, zum Beispiel auf Grundlage von Access oder Base. Das dafür notwendige relationale Tabellenmodell ist aber nicht mehr so leicht zu beherrschen. Insbesondere wenn zusätzlich Checklisten für den einzelnen Anwendungsfall in der Datenbank erfasst und gepflegt werden sollen, nähert sich der Redakteur mit schnellen Schritten einem ausgewachsenen Content-Management-System. Diese Komplexität ist auch mit Office-Datenbanken nur aufwendig zu verwalten. Ohne Erfahrung eine Datenbank selbst zu stricken, empfiehlt sich ohnehin nicht.
Spezielle Systeme
Eine Recherche im Internet liefert Fundstellen für zahlreiche fachlich spezialisierte Systeme für das Requirements Engineering. Ein recht umfassendes System heißt zum Beispiel DOORS. Es sind aber auch Anwendungen verfügbar, die einfacher scheinen, in einer Cloud laufen und keine hohen Investitionen erfordern. Voraussetzung für alle Systeme ist jedoch, dass ein solides Management der eigenen Anforderungen bei der Auswahl des passenden Systems besteht.
Methoden und Vorgehensweisen des Requirements Engineering bieten fachübergreifend für die Technische Dokumentation leistungsfähige Unterstützung in zahlreichen Anwendungsfällen. Schon die Anwendung einfachster methodischer Überlegungen wie Formulierungsmuster, atomare Zerlegung und aussagekräftige Benennung führen zu verständlichen, verwaltbaren und anwendbaren Requirements. Damit werden die Methode und der entsprechend aufgebaute Schatz an Anforderungen im Projekt und in der täglichen Arbeit schnell zum Erfolg beitragen.
Links und Literatur zum Beitrag
Schienenfahrzeugtagung, 41. Tagung (2011): H. Möller, (Deutsche Bahn AG) Anforderungsmanagement bei der Deutschen Bahn AG – der Schlüssel zur nachhaltigen Beschaffung von Schienenfahrzeugen. www.schienenfahrzeugtagung.at/41_%20tagung.htm.
Hull, Elizabeth; Jackson, Ken; Dick, Jeremy (2011): Requirements Engineering. Springer.
van Lamsweerde, Axel (2011): Requirements Engineering. From System Goals to UML Models to Software Specification. WILEY.
List of Requirements Management Tools: http://makingofsoftware.com/resources/list-of-rm-tools.