Projekte sicher ins Ziel navigieren

Teil 2: Anforderungen als Navigationspunkte auf dem Weg zum Projektziel

Im ersten Teil dieser Serie haben wir uns mit dem angestrebten Ergebnis eines Entwicklungsprojektes befasst. Auch wenn es zunächst paradox klingt, mit dem Ergebnis zu beginnen – aber ohne die Festlegung eines Projektzieles wird man im Verlauf des Projektes viele teure Umwege machen. Falls Sie es noch einmal nachlesen möchten, hier geht es zum ersten Teil.

Auf der Straße lassen sich Umwege am ehesten vermeiden, wenn man jederzeit weiß, welche Strecke man bereits zurückgelegt hat, wo man sich gerade befindet, und welche Strecke noch vor einem liegt. Eingebettet in den Kontext aktueller Karten und Verkehrsinformationen ist man zudem in der Lage, bei unvorhergesehenen Ereignissen eine informierte Entscheidung über die weitere Wegführung zu treffen.

Requirements Engineering als durchgängiger Bestandteil des Entwicklungsprozesses ist nichts anderes: eine kontinuierliche präzise Bestimmung des erreichten Zustandes und des weiteren Weges zum Projektziel. Was das konkret im Projekt bedeutet, betrachten wir in diesem Teil der Serie.

Nicht jede Anforderung ist eine „gute“ Anforderung

Ein oft unterschätzter Faktor, der Probleme verursachen kann, ist die Qualität der Anforderungen. Wichtige Kriterien für die Qualität der Anforderungen sind unter anderem Eindeutigkeit, Notwendigkeit, Nachprüfbarkeit, Realisierbarkeit, Vollständigkeit und Konsistenz. Zur Beschreibung von Anforderungen kann theoretisch jede Notation geeignet sein, wenn damit eine gewünschte Eigenschaft beschrieben werden kann.

In vielen Fällen wird zur Beschreibung der Anforderungen natürliche Sprache, nach Bedarf ergänzt durch Graphiken oder bildhafte Darstellungen genutzt (siehe Abbildung 1). Da es sich dabei um nicht-formale Notationen handelt, ist die Qualität der entstehenden Anforderungen gefährdet durch ungenaue oder missverständliche Formulierungen oder Symbole. Es gibt Spielraum für Interpretationen, die unbeabsichtigte Auslegungen und teure Nacharbeiten zur Folge haben können. Das International Requirements Engineering Board (IREB) beschreibt eine Reihe von Regeln, die dabei helfen, Anforderungen so zu formulieren, dass sie qualitativ hochwertig sind [1]. Danach sind unter anderem zu vermeiden:

• Unspezifische Substantive wie „die Daten“ oder „die Elektronik“. Die Begriffe sollten so präzise wie möglich gewählt werden.
• Unvollständige Bedingungen, die beispielsweise nur den normalen, fehlerfreien Ablauf beschreiben.
• Unklare Mengen- oder Zeitangaben wie „viele“, „fast immer“, „selten“, etc.
• Passive Formulierungen, aus denen nicht klar wird, wer bzw. welches Modul für die Umsetzung der in der Anforderung beschriebenen Eigenschaft zuständig ist, wie „Der Zähler wird auf 0 gesetzt.“

Das IREB beschreibt verschiedene Ansätze, die Anwendung solcher Regeln für natürlichsprachliche Anforderungen zu erleichtern, wie Satzschablonen oder Formular-Templates.

[1] Handbuch für das CPRE Foundation Level nach dem IREB Standard

Einsatz von KI für bessere Anforderungen

Eine weitere Möglichkeit ist die Nutzung entsprechender Ergänzungen im Anforderungsmanagementwerkzeug. Es gibt bereits einen so genannten „Qualitätsassistenten“ für ein etabliertes Tool für Anforderungsmanagement. Dieser Assistent arbeitet KI-basiert und ist trainiert auf die INCOSE Qualitätskriterien für Anforderungen (siehe Kasten) [1]. Er kennt 11 Qualitätsmetriken, die mehr als 80 % der INCOSE-Kriterien abdecken. Auf Knopfdruck überprüft das Modul natürlichsprachliche Anforderungen auf Einhaltung der gewählten Qualitätskriterien und gibt Empfehlungen (siehe Abbildung 4). Aus der Art und Weise, wie der Requirements Engineer diese Empfehlungen dann umsetzt, lernt der Assistent im Lauf der Zeit dazu.

[1] Requirements Working Group, INCOSE: Guide for Writing Requirements

Die Nutzung einer formalen Notation zur Beschreibung von Anforderungen reduziert den Interpretationsspielraum deutlich. Syntax und Semantik sind eindeutig definiert. Oft wird eine Modellierungssprache wie UML oder SysML herangezogen, wenn eine formale Beschreibung einer Anforderung gewünscht ist. Gut geeignet ist die Modellierung für funktionale Anforderungen, wobei zu beachten ist, dass einzelne Modelle für verschiedene Anforderungen im gemeinsamen Kontext konsistent sein müssen. Zudem ergibt sich aus dem Vorteil der formalen Notation gleichzeitig der Nachteil, dass möglicherweise nicht jedes Detail in dieser Notation beschrieben werden kann [1]. Qualitätsanforderungen oder Randbedingungen (constraints) lassen sich in der Regel gar nicht mit einer Modellierungssprache beschreiben.

[1] Handbuch für das CPRE Foundation Level nach dem IREB Standard

Nicht jede Anforderung ist gleich wichtig

Letztendlich ist für die Wirtschaftlichkeit des Projektes entscheidend, dass der angestrebte Ertrag aus dem Projektergebnis erzielt werden kann. Und das ist nur möglich, wenn genau die Anforderungen für die Implementierung festgelegt werden, die diesen Ertrag mit einem vertretbaren Aufwand ermöglichen. Daraus folgt jedoch nicht, dass der Prozess der Auswahl und Verfeinerung der Anforderungen zwingend und vollständig vor Beginn des Designs abgeschlossen sein soll. Auswahl und/oder Ausgestaltung der zu implementierenden Anforderungen können sich im Projektverlauf ändern bzw. verfeinert werden, je nach Projektfortschritt und -ergebnissen.

Requirements Engineering begleitet das Projekt als iterativer und ggfs. inkrementeller Prozess. Daher ist der kontinuierliche Abgleich über den gesamten Lebenszyklus so wichtig, um den Zeitpunkt für Verfeinerungen oder den Bedarf für Nachjustierungen so früh wie möglich zu erkennen und zu (re-)agieren.

Für die Auswahl, Gewichtung und Konfliktlösung stehen eine Reihe von Techniken zur Verfügung [1]. Eine Technik zur Erhebung und Einordnung von Erwartungen der Kunden/Anwender ist das Kano-Modell [2]. Als Grundlage für die Bewertung von Eigenschaften betrachtet das Kano-Modell den Nutzen für die Kunden/Anwender (siehe Abbildung 5). Danach beeinflussen diese 5 Dimensionen deren Zufriedenheit:

1. Basis-Merkmale sind grundlegend und dem Kunden/Anwender nicht bewusst. Sie werden als selbstverständlich vorhanden vorausgesetzt. Abgrenzung von Mitbewerbern ist mit diesen Merkmalen kaum möglich, Fehlen dieser Merkmale führt jedoch zur Unzufriedenheit beim Kunden.
2. Leistungs-Merkmale erhöhen die Kundenzufriedenheit, und sie werden vom Kunden/Anwender nachgefragt. Oft ist die Realisierung von Leistungsmerkmalen und damit eine Abgrenzung vom Mitbewerb mit höheren Kosten verbunden, so dass bei unüberlegter Auswahl die Wirtschaftlichkeit des Projektes bzw. Produktes gefährdet sein kann.
3. Begeisterungs-Merkmale sind Eigenschaften, mit denen der Kunde/Anwender vielleicht gar nicht gerechnet hat, die für ihn aber hohen subjektiven Nutzen darstellen. Es sind Alleinstellungsmerkmale, die mit vertretbarem Aufwand die Zufriedenheit des Kunden enorm steigern.
4. Unerhebliche Merkmale sind solche, deren Fehlen bzw. Vorhandensein keinerlei Auswirkungen auf die Kaufentscheidung und Zufriedenheit des Kunden/Anwenders hat. Unerhebliche Merkmale können aus technischer Sicht notwendig sein, um ein bestimmtes Implementierungsproblem zu lösen.
5. Rückweisungs-Merkmale führen zu Unzufriedenheit, ihr Fehlen erzeugt jedoch keine Zufriedenheit.

[1] IREB Handbuch Requirements Elicitation.  [2] Das Kano-Modell bei Wikipedia

        Abb. 3 – Das Kano-Modell gewichtet Eigenschaften danach, wie deren Vorhandensein oder Fehlen die Zufriedenheit
        des Anwenders/Kunden beeinflusst.

Die Einordnung von Merkmalen nach dem Kano-Modell ist nicht für die Ewigkeit in Stein gemeißelt. Je nach Entwicklung des Marktes und der Technik kann ein Begeisterungs-Merkmal im Lauf der Zeit zu einem Leistungsmerkmal werden. Navigationssysteme für Autos waren anfangs Begeisterungsmerkmale, die bald zu Leistungsmerkmalen wurden. Die Hersteller investierten immer mehr in weitere Funktionen, wie dynamische Routenanpassung oder Verknüpfung mit Umfeldsuche (vergleichbar Google Maps) und dem Telefon. Inzwischen ist ein Navigationssystem eher als Basis-Merkmal einzuordnen: Es wird als vorhanden vorausgesetzt.

Ausblick auf Teil 3

Der Einfluss von Requirements Engineering auf die Kosten der Fehlerbehebung ist immens. Je mehr Zeit vergeht zwischen dem Entstehen eines Fehlers und dessen Entdeckung, desto aufwendiger wird dessen Beseitigung. Damit befassen wir uns in Teil 3 dieser Serie. Falls Sie in der Zwischenzeit weitere Informationen zum Thema Requirements Engineering suchen, ist dies ein guter Ausgangspunkt: https://www.sodiuswillert.com/de/loesungen/anforderungsmanagement