Die perfekte Anforderung …

… zu formulieren könnte das Ziel sein. Ist es jedoch zielführend Anforderungen zu formulieren, die wirklich alle Qualitätskriterien wie z. B. Vollständigkeit, Eindeutigkeit oder Widerspruchsfreiheit  erfüllen? Welcher Aufwand wäre dafür notwendig und welcher Nutzen steht dahinter? Können Anforderungen in einer Entwicklung fehlerfrei formuliert werden? Zu welchem Zeitpunkt ist das möglich? Bei der Anforderungserhebung, während der Entwicklung, zur Abnahme des Produktes, in der operativen Phase oder zur Stilllegung bzw. Entsorgung des Produktes? Wie messen wir, ob eine Spezifikation wirklich alle Anforderungen enthält?

Das Verhältnis zwischen Aufwand und Nutzen bei der Erstellung von Anforderungen ist aus meiner Sicht nicht von der Erstellung anderer Ergebnisse zu unterscheiden. Ob der Aufwand von dem Nutzen nun exponentiell abhängt oder ob die bekannte 80/20 Pareto-Regel gilt, ist nicht entscheidend. Offensichtlich ist, dass sehr schlecht formulierte Anforderungen mit relativ wenig Aufwand sofort verbessert werden können. Weitere Verbesserungen sind jedoch nur mit erhöhtem Aufwand zu realisieren.

Die 100%-Spezifikation kann es auch deshalb nicht geben, da die Abnahme bzw. die Beweiserbringung, dass die Spezifikation perfekt ist, nicht möglich ist. Beispiel: Wann ist eine Anforderung wirklich eindeutig formuliert? Wenn jeder aus dem definierten Leserkreis bei jeder Anforderungen auch immer die gleiche Interpretation bietet? Dies für alle Anforderungen in einer Spezifikation mit allen möglichen Lesern abzuprüfen, wäre sehr aufwendig und u. U. nicht möglich, da nicht alle künftigen Leser bekannt sind.

Wie gehen wir nun damit grundsätzlich um?

Qualitätskriterien wie „Eindeutigkeit“, „Vollständigkeit“ etc. stellen selbstverständlich die Grundlage bei der Erstellung von Anforderungen bzw. Spezifikationen dar. Anforderungsautoren sollten geschult sein, wie Anforderungen den Qualitätskriterien entsprechend formuliert werden. Bei der Erstellung der Anforderungen sollte nur nicht der Anspruch erhoben werden alle Qualitätskriterien sofort einzuhalten. Dies mündet in u. U. sehr zeitaufwendigen Stakeholder-Abstimmungen, die in keinem vernünftigen Verhältnis zum Nutzen stehen.

Der Autor muss bei der Formulierung von Anforderungen seine Aufwände für die Formulierung bzw. Abstimmung gut im Auge behalten, und zunächst die Anforderungen bearbeiten, die für die Entwicklung dringend oder wichtig sind. Mit anderen Worten, die Anforderungen möglichst gut formulieren, die in der Entwicklung zum Problem werden können. Gleichzeitig muss der Anforderungsautor auch abhängig von den Randbedingungen im Projekt wie Lieferzeitpunkte etc. die Formulierungs- und Abstimmungsarbeiten abbrechen, wenn kein signifikanter Nutzen mehr durch eine bessere Anforderung in Aussicht ist.

Man könnte diese Handlungstechnik auch als kleines Risikomanagement für Anforderungen bezeichnen. Wenn ich Anforderungen prüfe oder abstimme, gehe ich nicht von oben nach unten durch die Spezifikation, sondern suche mir die Anforderungen, die ein Risiko für das Projekt darstellen. Das Risiko, dass nicht das geliefert wird, was eigentlich gefordert war, oder dass der Lieferungszeitpunkt oder die Kosten signifikant überschritten werden. Oder auch, dass unnötige Funktionen in dem zu entwickelnden System umgesetzt werden. Wenn Systeme iterativ entwickelt werden, ist es natürlich auch effizienter nur die Anforderungen zu betrachten, die jetzt unmittelbar vor der nächsten Iteration eingeplant sind. Anforderungen mit großem Aufwand zu prüfen oder besser formulieren zu wollen, die erst in späteren Iterationen umgesetzt werden, ist deshalb auch nicht zielführend, weil sie sich noch nach den laufenden Iterationen ändern können und dann der Aufwand für die Prüfung und die Umformulierung teilweise ggf. unnötig war. Dieser Gedanke wird auch sehr stark in agilen Vorgehen wie z. B. auch SCRUM so vertreten.

Michael E. Fagan, der die Methode „Inspection“ zur Prüfung von Dokumenten bzw. Arbeitsergebnissen in der Entwicklung ausgearbeitet hat, hat ähnliches gemacht, indem er bei der Fehlersuche zwischen Minor, Majors und Super Majors-Fehlern differenziert (Details siehe auch  http://www.ida.liu.se/~TDDC90/labs/doolan91.pdf). Innerhalb der Überprüfung der Dokumente und deren Inhalte werden die Prüfer angewiesen, zunächst die Fehler in Anforderungen zu finden, die für das Projekt kritisch sein können. Somit werden keine Kommafehler oder Diskussionen, ob nun das Wort „muss“ besser als „soll“ ist geführt, sondern es werden von den Spezialisten die Anforderungen lokalisiert, die falls sie fehlerhaft sind, in der Entwicklung mit hoher Wahrscheinlichkeit zu hohen Aufwänden führen oder auch das Projekt deswegen abgebrochen werden muss. Auch die Diskussion über die Atomarität von Anforderungen (nicht weiter zerlegbar in einzelne Anforderung) verursacht bei der Erstellung von Anforderungen teilweise hohen Diskussionsbedarf, der aus meiner Sicht nicht immer nutzbringend ist.

Falls wenig Zeit zur Verfügung steht, könnte man auch einfach mal die 20 risikoreichsten Anforderungen identifizieren und diese auf Herz und Nieren prüfen. Damit würde das Projektrisiko mit vertretbaren Aufwand stark reduziert werden.

Falls schon Erkenntnisse in einem Unternehmen vorhanden sind, welche Fehlerarten der Anforderungen oft zu größeren Problemen geführt haben, könnte man auch diese Qualitätskriterien vorrangig sicherstellen. Ein kombiniertes Beispielszenario könnte darin bestehen die zehn risikoreichsten Anforderungen auf das Qualitätskriterium „Eindeutigkeit“ detailliert zu prüfen.

Fazit ist nun: Unser Qualitätsmodell mit all unseren Qualitätskriterien benötigen wir weiter. Unsere Anforderungsautoren zu schulen, wie man Anforderungen grundsätzlich gut formuliert macht Sinn. Dies sollte man jedoch alles iterativ nach dem Prinzip des größtmöglichen Nutzens generieren. Qualitätskriterien können auch iterativ in einem Unternehmen eingeführt werden. Basierend darauf werden die Schulungen durchgeführt. In den Projekten benötigen wir jedoch ein Bewusstsein sich zunächst auf die risikoreichen Anforderungen zu konzentrieren, um auf die Einhaltung der wichtigsten Qualitätskriterien zu achten. Um diese Ideen umsetzen zu können, ist es notwendig auch zu wissen, wo die Stärken und die Schwächen in der Anforderungsqualität in dem Unternehmen sind. Dies stellt die Grundlage dar, ziel- und bedarfsgerecht konkrete Qualitätsverbesserungs-maßnahmen in ein Entwicklungsunternehmen einsteuern zu können.

Frank Stöckel

Kontaktieren Sie Frank Stöckel

Herr Frank Stöckel ist als Principal Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung von Requirements Engineering in Entwicklungsunternehmen mit Hilfe von Assessments, Seminaren, Workshops und Coaching. Fokus hierbei stellen wichtige initiale Pilotprojekte dar, die dann in unternehmensweite Prozessverbesserungsmaßnahmen führen, um RE langfristig in Entwicklungsunternehmen zu etablieren. Herr Stöckel führt Werkzeugauswahlverfahren für RM Tools durch, erarbeitet Konzepte zur Realisierung und Einführung von DV-Lösungen unter Einbindung von Werkzeugen des gesamten Entwicklungsprozesses. Darüber hinaus hat er in den letzten Jahren insbesondere in der Automobilindustrie Produktivstellungen (Roll-Outs) sowie Prozessentwicklungen von Anforderungsmanagement inkl. angrenzenden Prozessdisziplinen wie Projekt- und Testmanagement, Änderungsmanagement, Systemmodellierung, Lieferantendatenaustausch etc. erfolgreich geleitet. Kenntnisse in Modellierungstechniken runden sein Profil ab. Als erfahrener Trainer gibt er sein vielfältiges Wissen weiter, z.B. auch als akkreditierter Trainer für den Kurs „Certified Professional Requirements Engineering - Foundation Level".