Erfolgreicher Umgang mit Anforderungen

Der Erfolg einer Lösung oder eines Produktes entscheidet sich im Wesentlichen darin, ob die entsprechenden Anforderungen erfüllt sind. Mit der systematischen Erfassung, Verwaltung, Umsetzung und Prüfung von Anforderungen beschäftigt sich Requirements Engineering – eine Methodensammlung, die auch die Technische Redaktion betrifft. Daher ist es hilfreich, wenn Technische Redakteure sie kennen und wissen, wie sie erfolgreich funktioniert.

Die folgenden zwei Beispiele für Requirements Engineering sind Aufgabenstellungen aus der Praxis der Technischen Dokumentation. Die Beispiele ziehen sich durch den ganzen Beitrag.

Beispiel 1 – Normen und Richtlinien

Eine Technische Redaktion steht vor der Herausforderung, Informationsprodukte wie Betriebsanleitungen, Servicehandbücher oder Ersatzteilkataloge so zu erstellen, dass sie den geltenden Anforderungen aus Normen und Richtlinien entsprechen. Je nach Produktart kommen schnell mehrere hundert Einzelanforderungen zusammen. Sie müssen dokumentiert, angewendet und kontinuierlich aktualisiert werden. In stärker geregelten Bereichen wie der Medizintechnik oder der Luftfahrt kann die Zahl auch in den vierstelligen Bereich klettern. Zusätzlich kommen als Grundstock die Anforderungen von Normen hinzu, die vorrangig für die Technische Dokumentation gelten, wie die Norm DIN EN 82079-1 [1].

Beispiel 2 – Systemauswahl

Im Zuge der Professionalisierung setzen Unternehmen immer mehr IT-Systeme in der Technischen Redaktion ein. Dazu zählen Bereiche wie Content Management, Terminologieverwaltung, Übersetzungsmanagement oder auch Publikationsportale. Die Systeme müssen aus einem breiten Angebot entsprechend den eigenen Anforderungen ausgewählt und in möglichst kurzer Zeit angepasst werden. Im Gegenzug gilt es, Systeme abzulösen, die nicht den aktuellen Anforderungen entsprechen.
Immer muss der fachliche Bedarf in handhabbare Anforderungen heruntergebrochen und verwaltet werden. Auch bei der Auswahl eines Systems kommen schnell mehrere hundert Einzelanforderungen zusammen.

Wesentliche Erfolgsfaktoren

Eine Technische Redaktion steht also immer wieder vor dem Anspruch, mit einer hohen Anzahl von Anforderungen effizient und zielgerichtet umgehen zu müssen. Requirements Engineering stellt Bausteine bereit, mit denen sich die Herausforderung bewältigen lässt (Inf. 01).

Inf. 01 (Quelle: Tilo Ried)

Die Bausteine sind in den folgenden Abschnitten für eine Anwendung in der Technischen Redaktion als einzelne Erfolgsfaktoren ausgewählt, transformiert und beschrieben – insgesamt 15 Faktoren.

1. Der richtige Lebenslauf

Der Ablauf eines erfolgreichen Requirements-Engineering-Projekts und damit der Lebenslauf einer Anforderung lassen sich vereinfacht in folgende Phasen gliedern:

• Anforderungen finden
• Anforderungen erfassen
• Anforderungen anwenden

Damit wird schon klar, dass auch für den Umgang mit Anforderungen ein explizites Vorgehensmodell sinnvoll ist und nicht einfach drauflos gearbeitet werden kann (Inf. 02).

Inf. 02 (Quelle: Tilo Ried)

Zu jeder der genannten Phasen sind eigene Vorgehensweisen oder Methoden sinnvoll, um das Ziel eines vollständigen, leistungsfähigen Anforderungsmodells zu erreichen. Ein Projekt benötigt also immer eine Projektplanung, um zu einem erfolgreichen Ende zu gelangen. Weiterhin darf es nicht an Transparenz mangeln, in welchem Bearbeitungsstatus sich die einzelne Anforderung befindet.

2. Kein Anforderungsmodell ohne Ziel

Insbesondere das Beispiel einer System-auswahl, zum Beispiel eines Content-Management-Systems (CMS) oder eines Learning-Management-Systems (LMS), macht deutlich, wie wichtig ein klares Ziel für das Projekt und damit für die geplante Erfassung der Anforderungen ist. Die für eine Systemauswahl erarbeiteten Anforderungen werden sich bei Umfang und Ausprägung stark von Anforderungen unterscheiden, die für die eigentliche Produktentwicklung des CMS erarbeitet und dokumentiert werden müssen.
Das Projektziel „CMS auswählen“ unterscheidet sich offensichtlich stark von einem Projektziel „CMS entwickeln“. Letzteres bedeutet einen Aufwand, den eine Technische Redaktion heute nicht mehr leisten muss. Vor über 20 Jahren konnte es aber durchaus in Form von weitreichenden Systementwicklungen dazukommen.

In jedem Projekt für Requirements Engineering ist es notwendig, zuerst eine Zieldefinition für das Rahmenprojekt und das Anforderungsmodell schriftlich zu erarbeiten und abzustimmen. Dadurch wird Klarheit sowohl hinsichtlich des Standpunktes der Zielgruppe des Anforderungsmodells (= Viewpoint) als auch hinsichtlich der dafür notwendigen Modellstruktur (= View) geschaffen [4]. Folgende Punkte sollten vor der eigentlichen Arbeit notiert werden:

• Ziele des Projekts
• Ziele des Anforderungsmodells (Viewpoint)
• Zielgruppe und Verwendung des Modells (Viewpoint)
• Struktur und Inhalte des Anforderungsmodells (View)

3. Anforderungen vollständig finden

Es kann sich um eine sehr einfache oder ziemlich schwierige Aufgabe handeln, die wesentlichen Anforderungen vollständig zu finden. Auf jeden Fall entscheidet sich der Erfolg eines Projekts daran, wie gut diese Aufgabe gelingt. Nicht erkannte Anforderungen werden nicht erfasst, dokumentiert, nicht angewendet und überprüft. Damit wird es unwahrscheinlich, dass der im Anforderungsmodell spezifizierte Gegenstand in der Realität ausreicht, sei es eine normenkonforme Betriebsanleitung oder ein eingeführtes Content-Management-System.

Für das Erfassen normativer Anforderungen ist die Liste der verbindlich anzuwendenden Normen und Richtlinien ausschlaggebend. Die Liste stammt meist nicht aus der Technischen Redaktion, sondern einem anderen Bereich wie Konstruktion, Entwicklung oder Normenstelle. Erst das Wissen um konstruktive Entscheidungen ermöglicht es, diese Liste zu erstellen. Die Redaktion ist daher auf die Zuarbeit dieser Bereiche angewiesen und fragt im Idealfall die entsprechende Liste an.

Für ein Projekt zur Auswahl einer Software ist diese Vorgehensweise nicht möglich. Hier müssen die fachlichen Anforderungen aus den eigenen und benachbarten Fachbereichen selbst gefunden und erarbeitet werden. Dafür eignen sich Interviews, Fragebögen oder Workshops, um die fachliche Seite abzudecken. In der direkten Zusammenarbeit mit den IT-Abteilungen sind weitere Anforderungen und Einschränkungen aufzunehmen. Nicht zu vergessen sind organisatorische Anforderungen. Sie können aus dem Budgetrahmen oder auch aus den Wünschen eines Projektsponsors oder der Geschäftsführung bestehen.

Auf jeden Fall ist es nötig, vor dem Erfassen der Anforderungen festzulegen und mit den Beteiligten abzustimmen, wie die Recherche ablaufen soll [4]. Bereits zu diesem frühen Zeitpunkt des Projekts wird deutlich, dass ein Anforderungsprojekt von den Beteiligten einiges verlangt. Dazu gehört ein intensiver gemeinsamer Lernprozess über das Problem und mögliche Lösungen.

4. Leistungsfähige Strukturierung

Um das Ziel des Requirements-Engineering-Projekts zu erreichen, benötigen die zu erarbeitenden Inhalte eine geeignete Struktur. Wichtig sind dabei die Gesamtstruktur und Detailaspekte wie Metadaten und Formulierungsmuster.
Für die Gesamtstruktur des Anforderungsmodells stehen leistungsfähige Methoden aus der objektorientierten Analyse und Modellierung bereit. Dazu zählt die Unified Modeling Language, kurz UML. Bei UML spielen Klassen-, Objekt- und Use-Case-Diagramme eine zentrale Rolle. So lassen sich grundlegende Anforderungen an ein IT-System aus Sicht der Anwender auf der Basis definierter Anwendungsfälle dokumentieren. Anforderungen aus Normen und Richtlinien hingegen lassen sich gut in Form strukturierter Tabelleneinträge erfassen und verwalten.

Im Projekt ist es auf jeden Fall hilfreich, vorab eine geeignete Struktur zu diskutieren und zu dokumentieren. Mögliche Änderungen im Projektablauf ziehen meist einen hohen Aufwand nach sich. Oder das Anforderungsmodell funktioniert nur eingeschränkt, wenn dieser Aufwand gescheut wird.

5. Identifikation sicherstellen

Egal in welchem Fachbereich Anforderungen erfasst werden: Die eindeutige Identifikation jeder Anforderung ist ein absolutes Muss. Dafür bietet sich an erster Stelle eine durchlaufende, eindeutige ID für jede einzelne Anforderung an. Sie gilt für das gesamte Projekt. Werden Anforderungen in mehreren Projekten wiederverwendet, ist eine übergreifend Identifikation nötig. Zum Beispiel treten Anforderungen aus den Bereichen Backup, Rechtevergabe und Nutzerverwaltung in Technischen Redaktion in mehreren Auswahlprojekten wiederholt auf. Die Anforderungen müssen sich daher wiederverwendbar identifizieren lassen.

In einem laufenden Projekt konzentrieren sich Diskussion, Änderung und Freigabe von Anforderungen mehr und mehr auf einzelne Problemkandidaten. Die Kandidaten müssen zu jeder Zeit eindeutig identifiziert und durchgängig auffindbar sein. Das Ändern der Nummerierung, während das Projekt läuft, sorgt zuverlässig für Verwirrung und unnötigen Zusatzaufwand. In den folgenden Abschnitten werden immer wieder strukturelle Aspekte auf detaillierter Ebene behandelt.

6. Anforderungen benennen

An vielen ad hoc erstellten Checklisten mit normativen Anforderungen fällt auf, dass die einzelnen Anforderungen keine Benennung haben. Jede Anforderung ist in ihrem Kern in ein oder zwei Sätzen beschrieben, ein Name dafür fehlt aber.

Damit ist ein wesentliches Modellmerkmal nicht vorhanden, das eine vernünftige Arbeit mit den Anforderungen erst möglich macht: die Benennung. Eine gute Benennung fasst die eigentliche Forderung in ein bis drei Wörtern zusammen.

• User anlegen
• User löschen
• User kopieren

Neben der Entscheidung für eine Benennung sind jetzt Festlegungen zur Formulierung und Struktur hilfreich. Es gilt zum Beispiel zu entscheiden, ob Substantivierung oder Verben konsequent verwendet werden:

• Userverwaltung
• User verwalten

Getreu dem Motto, dass „das Verb der Lastesel des Satzes ist“, bieten sich Verben eher an als Substantivierung. Werden Normen und Richtlinien ausgewertet, dann zeigt sich aber, dass sich Inhalte einer Betriebsanleitung auch ohne Verb formulieren lassen:

• Persönliche Schutzausrüstung
• Bauartbedingte Restgefahren

7. Standardisierung ausweiten

Eine Anforderung benötigt neben der Benennung auch eine Beschreibung, die ein Verständnis der Einzelanforderung losgelöst aus dem gesamten Anforderungsmodell ermöglicht. Oft passiert es, dass während der Erfassung von Anforderungen auf Ebene problematischer, noch nicht abgestimmter und nicht freigegebener Anforderungen diskutiert wird. Dabei steht eine isoliert betrachtete Anforderung im Mittelpunkt, die eine möglichst vollständige Beschreibung benötigt.

Es ist daher sinnvoll, die Methode der Standardformulierungen oder der Boilerplates zu nutzen [5]. Dabei werden verschiedene Anforderungen mit ähnlichen Formulierungen dokumentiert. Wie beim instruktiven Text einer Betriebsanleitung kommt es nicht auf Originalität und Abwechslung an (Tab. 01).

Tab. 01 (Quelle: Tilo Ried)

8. Vereinzelung sicherstellen

In der Regel wird in einem Requirements-Engineering-Projekt der Erfüllungsgrad gegen eine Anforderung geprüft. Dafür ist es notwendig, mit einer dokumentierten Anforderung immer nur eine Forderung zu verbinden. Hinweise auf einen Verstoß gegen diese Regel geben Formulierungen, die „und“ sowie „oder“ enthalten oder die durch einige Kommas gegliedert sind:

• Das System ermöglicht die Versionierung und die Verwaltung von Varianten
• Die Betriebsanleitung enthält alle notwendigen Angaben zum sicheren Gebrauch, zur persönlichen Schutzausrüstung und zum gefahrlosen Entsorgen nach Gebrauch.

Es ist nötig, die Anhäufung von Informationen zu trennen und in eigenen Anforderungen festzuhalten. Dies gilt auch für teilweise umfangreiche Anforderungen an Layout und Leserlichkeit, wie sie zum Beispiel in der Norm DIN EN 82079-1 vorhanden sind. Die Frage, ob die Anforderungen einer Norm erfüllt werden oder nicht, lässt sich nur schwer auf der Basis zusammengefasster Requirements beantworten. Es ist eine konsequente Entscheidung für die Berücksichtigung aller Anforderungen nötig. Denn eine nur teilweise erfüllte Norm ist immer eine nicht erfüllte Norm.

9. Überprüfbarkeit ist Voraussetzung

Bei einer Vielzahl von Ausschreibungen für IT-Systeme finden sich Anforderungen wie diese:

• Das System ist einfach zu bedienen.
• Die Suche führt zu schnellen Ergebnislisten.
• Das Anlegen eines Users ist bequem möglich.

Auch wenn es sich um vereinzelte, so genannte atomisierte Anforderungen handelt, haben sie kaum Wert. Allen drei Anforderungen fehlt die Möglichkeit, sie konkret zu überprüfen.

Adjektive wie einfach, schnell oder auch bequem zeigen wichtige Anliegen aus Anwendersicht. Die Anforderungen sind aber nicht überprüfbar und müssen verbessert werden:

• Die Publikation ist mit höchstens drei Interaktionen möglich.
• Die Suche zeigt die Ergebnisliste in höchstens drei Sekunden an.
• Das Anlegen eines Users ist über einen automatisierten LDAP-Import möglich.

10. Hierarchie und Detaillierungsgrad

Eine weitere Herausforderung stellt die Frage, wie Anforderungen richtig detailliert werden. Zurück zum Beispiel des Content-Management-Systems: Alle Systeme, die in Betracht kommen, sind in der Lage, Inhalte durch Modularisierung wiederzuverwenden – eine Anforderung. Aber nicht alle Systeme unterstützen vollständig die Verwaltung des wiederverwendeten Inhalts:

• Das System fixiert die Version eines wiederverwendeten Moduls (= Freeze).
• Das System ermöglicht das automatische Aktualisieren eines wiederverwendeten Moduls auf die jeweils aktuellste Version (= Floating).
• Das System ermöglicht das manuelle Management der gewünschten Modulversionen während der Publikation.
• Das System ermöglicht das regelhafte, automatisierte Management der Modulversion während der Publikation.
• Das System …

Je nach Prozess und Produkt enthalten Anforderungen wie „Das System ermöglicht die Wiederverwendung von Inhalten auf Modulebene“ deutlich mehr, im Einzelfall sinnvolle und gewünschte Anforderungen.

Werden die Anforderungen nicht identifiziert und dokumentiert, ist nicht sichergestellt, dass das ausgewählte und eingeführte System diesen entspricht. Die Wirksamkeit einer Software entscheidet sich nach der Erfahrung also in vielen Fällen im Detail. Dies führt im Normalfall zu umfangreichen Listen mit Requirements, die für die im Bereich der Technischen Dokumentation eingeführten CMS zwischen 150 und 500 Einträge aufweisen können.

Auf eine vergleichbare Problematik stößt man bei der Auswertung der Norm DIN EN 82079-1. In Kapitel 6.2 „Leserlichkeit“ werden in Tabelle 2 „Empfohlene minimale Schriftgrößen und Höhen der grafischen Symbole“ die Anforderungen an Layout und Schriftgestaltung detailliert aufgeführt. Bei der Identifikation und Anwendung der Anforderungen ist zu entscheiden, ob eine generelle Anforderung definiert wird oder ob alle aufgeführten Aspekte in Einzelanforderungen umgearbeitet werden sollen.

Wieder lässt sich die Antwort nur aus dem Ziel des Projekts und damit aus dem Ziel der Modellierung ableiten. Besonders problematisch sind Forderungen, die im Normungsdokument nur beispielhaft und damit nicht vollständig genannt sind.

11. Horizontal und vertikal

Zwischen Anforderungen lassen sich Beziehungen in horizontaler und vertikaler Richtung erkennen und dokumentieren. Insbesondere bei Softwareanforderungen stößt man regelmäßig auf sich gegenseitig ausschließende Anforderungen. Wenn ein Web-Content-Management-System ohne eine Datenbank laufen soll, schließen sich Forderungen nach Microsoft SQL Server oder Oracle als Datenbank horizontal logisch aus.
Gleiches kann auch bei der Erarbeitung normativer Anforderungen auftreten. So ist es möglich, dass sich Forderungen aus unterschiedlichen Normen hinsichtlich Warn- oder Sicherheitshinweisen widersprechen und sich damit gegenseitig ausschließen. So fordert zum Beispiel die Spielzeugrichtlinie 2009/48/EG in Artikel 11, dass Warnhinweise mit dem Signalwort „Achtung“ beginnen müssen. Die Anforderung ist nicht mit denen der DIN EN 82079-1 in Übereinstimmung zu bringen. Sie schließen sich damit horizontal aus. Eine Entscheidung für die eine oder andere Anforderung ist wieder nur aus dem Ziel- und Projektkontext möglich.

12. Klassifikation von Anforderungen

In der Fachliteratur existiert eine Vielzahl verwendbarer Aspekte, einzelne Anforderungen zu klassifizieren. Hier eine kleine Auswahl:

• Funktionale/nicht funktionale Anforderungen
• Priorität der Realisierung der Anforderung
• Risiko, wenn die Anforderung realisiert/nicht realisiert wird
• Urheber der Anforderung (Stakeholder)
• Erwartete Kosten zur Realisierung der Anforderung
• Beitrag der einzelnen Anforderung zur Zielerreichung
• Verhältnis der Kosten in Bezug auf Beitrag zur Zielerreichung

In jedem Requirements-Engineering-Projekt müssen die Beteiligten der Klassifikation und damit den Details des Anforderungsmodells besondere Aufmerksamkeit widmen.

Anforderungen aus Normen und Richtlinien benötigen eine geeignete Struktur und eine passende Klassifikation, damit sich die hohe Anzahl an Anforderungen handhaben lässt. Das Zusammenfassen aller Anforderungen zum Thema „Persönliche Schutzausrüstung“ in einer Rubrik ist sicherlich hilfreich. Die erste und wichtigste Klassifikation wird aber in diesem Bereich durch die Liste der anzuwendenden Normen und Richtlinien vorgegeben und folgt damit einfach der Produktart.

Bei einem IT-Projekt wie der Auswahl eines CMS bietet sich eine Klassifikation nach Funktionsgruppen und nach dem Hauptprozess der Systemnutzung an: Erstellung, Wiederverwendung, Lektorat, Übersetzung und Publikation.

13. Realisierbar oder nicht realisierbar

Anforderungen sollen ausschließlich wegen eines fachlichen Bedarfs erhoben werden. Die spätere Realisierbarkeit einer Anforderung kann von vielen Aspekten abhängen und sollte in einem ersten Schritt noch kein Kriterium für oder gegen die Anforderung sein. Allerdings ist es wenig sinnvoll, offensichtlich nicht realisierbare Anforderungen zu dokumentieren, abzustimmen und zu verwalten. Die dafür notwendige Zeit kann man sich sparen.

Bei normativen oder gesetzlichen Anforderungen darf die Realisierbarkeit keine Rolle spielen. In der Praxis stößt man aber immer wieder auf Aussagen wie „diese Anforderung ist nicht erfüllbar“, sei es eine Übersetzung in eine geforderte EU-Sprache oder die Vollständigkeit einer Betriebsanleitung. Dies führt natürlich zu schlechter Qualität und einem finanziellen Risiko.

Die Realisierbarkeit von Anforderungen an IT-Systeme hängen meist davon ab, welche Mittel bereitstehen. Die Entscheidung wird durch die zur Verfügung stehende Zeit oder das Budget unterstützt und fällt damit erst spät im Projektablauf. Daher ist es bei Softwareauswahl oder Grobspezifikation noch nicht sinnvoll, allzu sehr über die Realisierbarkeit nachzudenken.

14. Pragmatische Qualität

Die Qualität eines Requirements-Engineering-Modells hängt von einer Reihe von Aspekten ab:

• Abstraktionsgrad passend zu Aufgabenstellung und Zielgruppe des Modells – View entspricht Viewpoint
• Vollständigkeit hinsichtlich Aufgabenstellung
• Verständlichkeit der dokumentierten Inhalte hinsichtlich Zielgruppe

Die Eigenschaften tragen direkt zur so genannten pragmatischen Qualität des Anforderungsmodells bei [2]. Damit ist gemeint, dass über die erreichte Qualität die Zielgruppe in der konkreten Verwendung des Modells entscheidet. Anders gesagt: Der Grad des Verständnisses der Zielgruppe gegenüber dem Modell stellt eine Aussage über die erreichte pragmatische Qualität des Modells dar. Unverstandene Terminologie, sei es im Bereich Softwareauswahl oder bei Normen und Richtlinien, wird keine sichere Anwendung des Anforderungsmodells erlauben. Ebenso erschweren zu hohe Abstraktion oder zu komplexe Modelle die Verständigung mit der Zielgruppe.

15. Professionelle Verwaltung auswählen

Aus den meist hohen Mengen an zu verwaltenden Anforderungen resultiert die Frage nach einer geeigneten systemtechnischen Unterstützung. Reicht dafür Microsoft Excel? Eine strukturierte Verwaltung ist durchaus möglich. Eine für die Auswertung von Normen und Richtlinien typische Spaltenstruktur zeigt Abbildung 1.

Abb. 01 Spaltenstruktur in Excel für Anforderungen aus Normen und Richtlinien. (Quelle: Tilo Ried)

Deutliche Einschränkungen treten bei der Verwaltung von Beziehungen auf. Zwar ist es möglich, für einzelne normative Anforderungen mehrere Quellen zu dokumentieren. Die Verwaltung mit Excel wird aber beim Aufbau so genannter Beziehungs­tabellen unübersichtlich, die Information lässt sich immer schlechter pflegen. Ähnlich schwierig ist die automatische Vergabe und Beibehaltung eindeutiger IDs zu den einzelnen Anforderungen. Hier hilft nur eine Datenbank weiter. Der notwendige Funktionsumfang entspricht annähernd dem eines Content-Management-Systems. Das Klassendiagramm in Abbildung 2 zeigt ausschnittweise eine passende Datenstruktur eines Anforderungsmodells zur Auswahl von Software. Das Modell wurde in der Software ReqSuite von Osseno (6) implementiert und angewendet.

Abb02 Einfaches Anforderungsmodell für die Systemauswahl als UML-Klassenmodell. (Quelle: Tilo Ried)

Das Fachwissen vertiefen

Effektives und effizientes Arbeiten mit Anforderungen erfordert handwerkliches und konzeptionelles Können. Die dargestellten Erfolgsfaktoren tragen in hohem Maß zum Projekterfolg bei. Darüber hinaus darf aber nicht übersehen werden, dass es sich bei Requirements Engineering um einen professionalisierten Bereich mit einer Vielzahl an erprobten Vorgehensweisen und Methoden auf Grundlage umfangreicher Theorie handelt. Ein tieferes Verständnis erfordert mehr Aufwand bei der Einarbeitung, lohnt sich aber insbesondere für die Aufgaben und Projekte der Technischen Redaktion.