Ein Angebot von

Warum Anforderungsmanagement eine lebenslange Verantwortung darstellt

| Autor / Redakteur: Mark Pitchford * / Sebastian Gerstl

Die Anforderungen bzw. Requirements, die zu Beginn einer Softwareentwicklung aufgestellt werden, stellen quasi die Blaupause eines Projekts dar. Ebenso wie das Projekt selbst müssen aber auch die Anforderungen dauerhaft gepflegt werden.
Die Anforderungen bzw. Requirements, die zu Beginn einer Softwareentwicklung aufgestellt werden, stellen quasi die Blaupause eines Projekts dar. Ebenso wie das Projekt selbst müssen aber auch die Anforderungen dauerhaft gepflegt werden. (Bild: Clipdealer)

Anforderungsmanagement ist nicht mit dem Start eines Projekts abgeschlossen. In der Softwareentwicklung müssen Requirements und Entwicklungskomponenten von Beginn an wie auch dauerhaft verbunden und gepflegt werden.

Bei der Ausarbeitung eines Vertrags formulieren alle Beteiligten ihre Vision davon, was die fertig abgelieferte Applikation leisten soll. Anschließend geht das Projektteam daran, diese Visionen in Anforderungen umzusetzen, auf deren Basis dann die Entwicklung beginnen kann.

Die Anforderungen sollen also als eine Art Blaupause für die Entwicklung dienen, wobei jede übergeordnete Anforderung auf eine Anforderung, ein Design und eine Implementierung abgebildet wird. Allzu häufig kommt es jedoch vor, dass die Anstrengungen des Teams mit der Zeit von dieser Blaupause abweichen, sodass die entstehende Applikation nicht mehr den ursprünglichen Anforderungen entspricht. Im günstigsten Fall ist nur der Auftraggeber enttäuscht, im ungünstigsten Fall aber wird das Team mit Schadenersatzforderungen und teuren Abhilfemaßnahmen konfrontiert.

Zusätzliche Herausforderungen ergeben sich bei neuen Applikationen für vernetzte Autos, interaktive Medizingeräte oder industrielle IoT-Applikationen, bei denen es fraglich ist, wann der Entwicklungsprozess beendet ist. Jede neu aufgedeckte Schwachstelle oder Sicherheitslücke im System verlangt als Gegenmaßnahme nach einer zusätzlichen Anforderung, wodurch die Rückverfolgbarkeit bis in die Produktwartungs-Phase hinein vermehrt in den Blickpunkt rückt.

Hier kommt die lebenslange Verpflichtung ins Spiel. Indem man vom Beginn eines Projekts an Trace-Verbindungen zwischen den Anforderungen und den Entwicklungs-Komponenten anlegt, sorgt man dafür, dass Probleme wie etwa fehlende oder nicht benötigte Funktionalitäten früher erkannt werden können, sodass die Reparaturmaßnahmen einfacher und kostengünstiger sind.

Die Implementierung eines umfassenden, strategischen und automatisierten Prozesses zur Rückverfolgung der Anforderungen kann sich entscheidend auf die Deadlines und Budgets eines Projekts auswirken und vermeiden, dass es zu Unstimmigkeiten zwischen der Vision des Auftraggebers und der letztendlich abgelieferten Applikation kommt. Außerdem ergibt sich dabei ein effektiver Support-Mechanismus für im Einsatz befindliche vernetzte Systeme.

Anforderungen sind eine Kunst

Wenn sich alle Beteiligten auf gleiche Weise für die Anforderungen engagieren, müssen diese verständlich, eindeutig und präzise sein. Anforderungen lassen sich grundsätzlich auf zweierlei Weise definieren, und beide Varianten haben ihre Vor- und Nachteile.

Textliche Spezifikationen

Vorteile Nachteile
Dank der Verwendung natürlicher Sprache ist keine besondere Einarbeitung nötig. Während der Auftraggeber möglicherweise laienhafte Formulierungen verwendet, tendiert der Auftragnehmer zur Verwendung von Fachsprache.
Sprache ist prinzipbedingt ungenau und anfällig für Mehrdeutigkeiten

Eine Möglichkeit zur Vermeidung der oben aufgeführten Nachteile ist es, beim Formulieren der Anforderungen Regeln anzuwenden, ähnlich wie die MISRA-Standards auf C- und C++-Code angewendet werden. Dazu diese Beispiele:

  • Untergliederung in Abschnitte, um Anforderungen von Text außerhalb der eigentlichen Anforderung zu unterscheiden
  • Formulierung von stets nur einer Anforderung je Abschnitt
  • Verwendung des Verbs „muss“
  • Vermeidung des Worts „und“ in einer Anforderung. Stattdessen sollte eine Aufteilung in mehrere Anforderungen erfolgen oder die Formulierung mit allgemeineren Begriffen vorgenommen werden.
  • Vermeidung konditionaler Sprachkonstrukte wie „sofern nicht“ oder „nur wenn“, die Raum für mehrdeutige Interpretationen lassen

Hilfreich ist auch die Verwendung von Schlüsselwörtern, wenn bestimmte Mitglieder des Entwicklungsteams weniger mit der gewählten Anforderungssprache vertraut sind als andere.

Anwendungsfälle

Vorteile Nachteile
Eine reduzierte Abhängigkeit von natürlicher Sprache ist ideal für internationale Teams, die keine gemeinsame Sprache sprechen. Nicht alle Projektbeteiligten werden die Nuancen von Anwendungsfall-Diagrammen
verstehen..
Die grafische Darstellung ersetzt die zeilenweise Auflistung gewünschter Features durch eine anwenderorientierte Betrachtung davon, wie das System mit externen Elementen interagiert und welchen Wert es liefert.

Jeder Anwendungsfall bzw. jede User Story umfasst mehrere Szenarien. Das erste Szenario (Bild 1) ist stets der „Basic Path“ oder auch das „Sunny-Day Scenario“, in dem der Akteur und das System auf normale, fehlerfreie Weise interagieren.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45733902 / Requirements)