Anforderungen: wenn wünschen allein nicht hilft

Produktverantwortliche sammeln über ihre Schnittstelle zum Verkauf die Marktanforderungen (z. B. anwendbare Normen) und positionieren ihr Produkt im Markt. Sie machen eine Produkt-Releaseplanung, indem sie Anforderungen gruppieren und priorisieren (siehe auch das SMART Attribut «Relevant»). Sie verwenden dazu z. B. das MosCoW-Schema (Must-have, should-have, Could-have, and Won't-have) oder noch ausgeklügeltere Tools wie die Requirements Prioritization Matrix.

Für die Definition eines Produkt-Releases brauchen Produktmanager Informationen aus der Entwicklungsabteilung, z. B. zur Machbarkeit von Anforderungen oder zum Entwicklungsaufwand. In der Diskussion zwischen Produktmanagement und Entwicklungsabteilung sollten im Hinblick auf die Lastenheft-Erstellung auch die Anforderungsprioritäten geklärt werden.

Spätestens im Pflichtenheft sollte es keine "nice-to-have" Anforderungen mehr geben. Jede Anforderung braucht Zeit für die Umsetzung und Verifikation (siehe auch das SMART Attribut «Time-Bound»), erhöht die Komplexität und kostet. Klare Anforderungsprioritäten mindern auch das Risiko einer zu späten Markteinführung.

Das Pflichtenheft wird von der Entwicklungsabteilung oder dem Entwicklungsdienstleister verfasst und ist in der Regel detaillierter als das Lastenheft. Die Verfasser dieses Dokuments stellen sicher, dass alle Anforderungen SMART sind, siehe unten. Da das Pflichtenheft bindend für die Produktumsetzung ist, muss es vom Produktmanagement gegengelesen und freigegeben werden.

Jeder hat schon davon gehört, dass Anforderungen SMART (Specific, Measurable, Achievable, Relevant, and Time-Bound) sein sollten. Was bedeuten diese Attribute?

Specific (Spezifisch)

Wie oft sieht man in Lastenheften Anforderungen der Art: "Der Eingangsspannungsbereich muss grösser sein als bei Produkt xy". Selbst wenn der Eingangsspannungsbereich dieses Produkts noch definiert wäre, bliebe diese Anforderung unspezifisch, weil keine explizite Angabe (Wert und Einheit, Schnittstellendefinition) des Bereichs erfolgt. Wörter im Komparativ wie grösser, schneller, besser haben in Anforderungen in der Regel nichts zu suchen.

Zur Spezifität trägt auch eine Aufteilung der Spezifikation in funktionale und nicht-funktionale Anforderungen bei.

Measureable (Messbar)

Vieles bzgl. Messbarkeit ist bereits im obigen Abschnitt aufgeführt. Ist eine Anforderung nicht messbar, ist sie auch nicht überprüfbar und damit kann nicht sichergestellt werden, dass die Anforderung auch umgesetzt wurde.

Achievable (Erreichbar)

Anforderungen müssen realistisch, d.h. umsetzbar sein. Dieses Attribut ist in der Regel zusammen mit dem letzten Attribut (Time-Bound) zu sehen. Anforderungen, deren Umsetzung über den Stand der Technik hinausgehen, erfordern einen (sehr) grossen Entwicklungsaufwand.

Relevant

Anforderungen müssen wichtig sein, d.h. sie müssen sich auszahlen (business value). Oft sieht man hier eine Priorität der Anforderungen, z. B. "must" oder "nice-to-have" oder es werden noch feinere Aufteilungen vorgenommen. In einem Pflichtenheft sollte es hingegen keine "nice-to-have" Anforderungen mehr geben, weil jede Anforderung Zeit für die Umsetzung und Verifikation braucht (siehe auch das Attribut Time-Bound), die Komplexität erhöht und etwas kostet.

Solcept verfügt in seinen Anforderungstemplates über drei Prioritäten: safety, must, nice-to-have. Alle nice-to-have werden vor der ersten Baseline des Pflichtenhefts zusammen mit dem Kunden eliminiert, so dass bei der Umsetzung nur noch safety und must vorkommen. Hinter dem safety Attribut steht ein Effizienzgedanke: Nicht alle Anforderungen eines Produkts sind sicherheitsrelevant. Sicherheitsrelevante Anforderungen erfordern aber in der Regel einen erhöhten Dokumentationsaufwand (z. B. Spezifikations- und Architekturbeschreibungen bis auf die unterste Ebene). Dieser Aufwand soll nur für die sicherheitsrelevanten Anforderungen geleistet werden. Unser Anforderungsmanagement Tool unterstützt uns dabei, die verlangte Dokumentationstiefe aller Safety-Anforderungen sicherzustellen (Traceability-Analyse mit entsprechender Filterung).

Time-Bound (Zeitbegrenzt)

Wie bereits oben erwähnt, ist dieses Attribut im Zusammenhang mit der Wichtigkeit und Erreichbarkeit von Anforderungen zu sehen. Der geplante Zeitpunkt des Markteintritts ist hier im Fokus.

Es macht Sinn, funktionale und nicht-funktionale Anforderungen zu unterscheiden:

• Funktionale Anforderungen beschreiben das verhalten, d.h. was ein Produkt tut (z. B. Sensorwert lesen, verarbeiten, anzeigen)
• Nicht-funktionale Anforderungen spezifizieren, wie diese Funktion ausgeführt wird (z. B. mit welcher Aktualisierungsrate)

Funktionale Anforderungen

Funktionale Anforderungen erfordern eine andere Beschreibungsform als nicht-funktionale Anforderungen. Man verwendet hier mit Vorteil eine semi-formale Notation in Tabellenform, die folgende Informationen zusammenfasst: 

• Ziel
• Vorbedingung
• Auslöser ("Trigger")
• Abfolge von Tätigkeiten
  • v.a. hier semi-formal, z. B. mit IF-THEN-ELSE oder DO-WHILE, etc.
• Endzustand

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen sind oft ebenfalls in Tabellenform und verlangen folgende Information: 

• Parameter (zur Referenzierung in funktionalen Anforderungen, z. B. T_Sample)
• Beschreibung
• Wert
• Einheit
• Bedingungen (z. B. nur innerhalb eines gewissen Temperaturbereichs)

Wichtig ist, dass in funktionalen Anforderungen keine expliziten nicht-funktionalen Anforderungen enthalten sind, sondern dass diese nur über einen Parameter referenziert werden (Vermeidung von Mehrfachdefinition einer Anforderung). Ein modernes Anforderungswerkzeug erlaubt die Verknüpfung der beiden Anforderungen für Analysen der Rückverfolgbarkeit oder der Auswirkung von Änderungen.

Einfach anfangen, dann optimieren, optimieren, optimieren

„Der erste Entwurf von allem ist Scheisse.“ – Ernest Hemingway

Lassen Sie sich nicht von einer Schreibblockade aufhalten und tarnen Sie den Nicht-Anfang nicht mit Perfektionismus. Um Anforderungen effizient zu besprechen und auszuarbeiten, müssen Sie aufschreiben, was Sie wissen. Niemand schreibt perfekte Anforderungen in nur einem Entwurf. Klare und eindeutige Anforderungen werden eher in vielen kleinen Schritten erreicht:

• Schärfen Sie Ihre Gedanken, während Sie sie aufschreiben oder ein Diagramm zeichnen
• Besprechen Sie Ideen/Konzepte mit Ihren Kollegen
• Passen Sie die Anforderungen iterativ an die Architekturbeschreibung an
• Passen Sie das Format an die Anforderungsregeln Ihrer Organisation an
• Verschieben Sie Informationen auf die richtige Ebene im V-Modell (sehen Sie dazu auch hier)
• Führen Sie eine Überprüfung nach dem Vier-Augen-Prinzip und anhand einer Checkliste durch
• Überarbeiten Sie Inhalte auf der Grundlage des Feedbacks von der oberen, unteren und rechten Seite des V-Modells
• Löschen Sie eine Anforderung einfach, wenn sie veraltet ist (zumindest hat sie Ihnen geholfen, dieses Verständnis zu erlangen)
• Beginnen Sie so früh wie möglich mit der Überprüfung der einzelnen Anforderungen (d. h. warten Sie nicht, bis das vollständige Spezifikationsdokument fertig ist)

Aber seien Sie sich bewusst: Die Optimierung sollte auf ein globales Optimum abzielen und nicht zwischen lokalen Optima oszillieren (z. B. die Anforderung jedes Mal nach persönlichem Formatgeschmack umschreiben, wenn sie mit einer weiteren Person besprochen wird).

Veränderungen managen: Verbesserungen ermöglichen, Risiken begrenzen

„Change Management ist Anforderungsmanagement für Erwachsene“ – fast Tom DeMarco

Je weiter das Projekt voranschreitet, desto höher sind die inhärenten Risiken und Kosten von Änderungen. Andererseits sind Änderungen unerlässlich, um eine gute Qualität zu erreichen. Wie oben erläutert, wird Exzellenz in vielen kleinen Schritten erreicht.

Hier sind einige Tipps für einen schlanken Änderungsmanagement-Prozess:

• Verwenden Sie ein Tool, das den Status jeder einzelnen Anforderung verwaltet
• Optimieren Sie Ihren Prozess für Änderungen und gehen Sie nicht von einer einzigen Erstellungs- und Überprüfungsschleife aus (selbst Projekte mit geringer Komplexität weisen viele Abhängigkeiten auf, bei denen eine Feedbackschleife und Änderungen in alle Richtungen des V-Modells erforderlich sind)
• Bieten Sie eine gute Tool-Unterstützung, um Änderungen und ihre Auswirkungen zu überprüfen (das Diff-Tool ist die erste Funktion, die bei der Bewertung eines Anforderungsmanagement-Tools betrachtet werden sollte)
• Stellen Sie mit Gates sicher, dass der Inhalt der Anforderungen auf einem angemessenen Niveau für den Projektlebenszyklus ist (z. B. sollten zu Beginn der Entwicklung zumindest die Unbekannten identifiziert und dann im Rahmen des Änderungsmanagements während der Entwicklung/Verifizierung geschlossen werden)
• Nutzen Sie Traceability, bauen Sie diese Links schon während dem Schreiben ein, dann sehen Sie immer, was von waqs abhängt

Verschieben Sie das Schreiben zu den Informationen

„Verschiebe nicht die Informationen zur Befugnis, sondern die Befugnis zu den Informationen.“ – L. David Marquet

Anforderungsmanagement ist weder schwarze Magie noch eine Rollendefinition. Alle relevanten Informationen auf einige wenige Anforderungsmanager zu übertragen, ist ineffizient und birgt das Risiko, dass kritische Themen während der Übertragung verloren gehen.

Richten Sie stattdessen einen einfachen Prozess und ein Tool ein, das jeden Stakeholder als Mitwirkenden willkommen heisst (Autor, Prüfer, Tester, Freigebender oder Auditor). Stellen Sie sicher, dass die Person mit den meisten Informationen (Entwickler, Tester, Produktmanager, Servicebeauftragter usw.) direkt in den Prozess einbezogen wird und die Kontrolle und Befugnis erhält, die relevanten Anforderungen direkt zu schreiben und zu überprüfen.

Selbst bei einem System mit geringer Komplexität erfordert die Festlegung von Anforderungen und die Sicherstellung ihrer Rückverfolgbarkeit fundiertes Know-how in vielen Bereichen. Daher kann dies nicht von einem einzelnen Spezialisten bewältigt werden, sondern es ist Teamarbeit erforderlich.

Das V-Modell gibt Struktur, keine Zeitachse

„Das V-Modell ist die schlechteste aller Organisationsformen – abgesehen von allen anderen“ – fast Winston S. Churchill

Das V-Modell hilft, Informationen zu strukturieren und Beziehungen (über die Rückverfolgbarkeit) in zwei Dimensionen darzustellen:

• Vertikal: Der Entwurf wird hierarchisch verfeinert, Schichten helfen, die Komplexität zu reduzieren, sodass die Erfüllung der Anforderungen bereits durch Entwurf und Überprüfung sichergestellt werden kann
• Horizontal: Auf jeder Schicht wird sichergestellt, dass alles getestet wird

Dies hilft insbesondere dabei,

• zu zeigen, wo Informationen abgelegt und gefunden werden können
• die Auswirkungen von Änderungen effizient zu verwalten (siehe auch oben)

Ein häufiges Missverständnis ist, dass das V-Modell eine Zeitachse darstellt. Ein Projekt wird nicht einfach durch ein- oder zweimaliges Durchlaufen des Modells abgeschlossen. Die Arbeit erfordert inhärente Feedback-Schleifen in alle Richtungen und wird auch von unten nach oben erfolgen. Dies ist in Ordnung, wenn die Informationen am Ende von oben nach unten und von links nach rechts konsistent sind.

Man denke z. B. an Hardware-Unvollkommenheiten, die in der Software korrigiert werden. Dabei handelt es sich um Details aus dem Low-Level Hardware-Design, die normalerweise erst spät im Projekt definiert werden. Dennoch gehören sie auf Systemebene in die Hardware-Software Schnittstellenspezifikation, um sicherzustellen, dass der Software-Ingenieur die Informationen findet.

Ein weiteres Beispiel ist die Top-Level-Spezifikation. Am Ende der ersten Phase des Systemdesigns kann normalerweise nicht jedes Detail vollständig spezifiziert werden. Stattdessen kann eine Annahme getroffen werden, um die Entwicklung zu ermöglichen, oder zumindest sollten die Unbekannten (TBD's) identifiziert werden. Anschließend können sie nachverfolgt und gelöst werden, wenn während der Entwicklung genügend Informationen gewonnen werden.

Strukturieren und formalisieren Sie die Kommunikation, aber kommunizieren Sie weiter

„Gute Kommunikation ist die Brücke zwischen Verwirrung und Klarheit“ – Nat Turner

Ein sauberes Anforderungsmanagement klingt nach viel Aufwand, aber Unklarheiten/Mehrdeutigkeiten können zu Ineffizienz und viel mehr Aufwand führen, wie z. B.:

• Hoher Aufwand bei der Umsetzung des Falschen aufgrund von Missverständnissen
• Grosse Änderungen spät im Projekt aufgrund vergessener Anforderungen/Probleme
• Wiederkehrende Diskussionen darüber, was umgesetzt werden muss

Eine Anforderung ist etwas, worüber alle beteiligten Personen dasselbe Verständnis haben müssen, damit die individuell entwickelten Teile zusammen funktionieren und das Endprodukt die gewünschte Funktionalität bietet. Letztendlich ist das Anforderungsmanagement nur eine strukturierte und formalisierte Methode, um alle Beteiligten zu kommunizieren und zu verbinden. 

Beachten Sie insbesondere Folgendes:

• Wenn eine Anforderung mehrdeutig ist und zu Diskussionen führt, aktualisieren Sie sie mit der Schlussfolgerung, welche aus der Diskussion resultiert, da sonst dieselbe Diskussion erneut aufkommt (z. B. während Reviews, Implementierung, Tests usw.).
• Zu Beginn des Projektlebenszyklus ist es wichtig, die wichtigsten Anforderungen/Entscheidungen zu erfassen und aufeinander abzustimmen (ohne sich in Details zu verlieren, die später geklärt werden können), da grundlegende Änderungen an der Architektur/dem Design dann noch ohne grosse Auswirkungen/Aufwand vorgenommen werden können.
• Da die natürliche Sprache mehrdeutig ist, helfen klar definierte Semantiken und formalisierte Ansätze, die Mehrdeutigkeit zu reduzieren. Bedenken Sie jedoch, dass die Verständlichkeit immer vor dem Format und den Werkzeugen kommt.