Systematisches Requirements-Engineering (Teil 1)
Software-Projekten zum Erfolg verhelfen
Softwareintensive medizinische Systeme stehen unter einem immensen Marktdruck. Während sie technologisch und hinsichtlich Sicherheit kompromisslos innovativ sein müssen, fordern die Krankenhäuser und auch Gesundheitsreformen eine immer kürzere Zykluszeit bei gleichzeitig angespannten Budgets. Requirements-Engineering hat daher eine Schlüsselrolle als Erfolgsfaktor für Projekte und Produkte im Gesundheitswesen. Im ersten Teil dieses Beitrags geht es zunächst darum, systematisches Requirements-Engineering allgemein näher zu beleuchten, der zweite Teil in der nächsten Ausgabe gibt es dann wertvolle Praxistipps.
Der Kriminalautor Gilbert Keith Chesterton schrieb: »It isn‘t that they can‘t see the solution. It is that they can‘t see the problem.« Und er meint damit, dass wir häufig zu schnell auf eine vermeintliche Lösung aufspringen, bevor wir das Problem richtig verstanden haben. Hand aufs Herz, wer kennt die Szene nicht: Man sitzt in einem Review mit Kunde oder Auftraggeber und würde sich ob der Schwerfälligkeit in der Bestimmung der Anforderungen am liebsten hinsetzen und einfach die Software so umsetzen, wie man es ja bereits die ganze Zeit verstanden hat.
Ist doch nur Zeitverschwendung, sagen sich da viele. Das ist auch der Grund, warum in Krisenzeiten die Probleme durch unzureichendes Requirements-Engineering anwachsen. Man meint, Geld sparen zu können, wenn weniger Aufwand in diese Vorbereitung gesteckt wird. Wir alle wissen: Zu viele Projekte scheitern, und Produkte erreichen die Marktziele nicht. Was wir nicht wissen oder nicht wahrhaben wollen: Unzureichendes Requirements-Engineering ist ein Hauptgrund.
Die neueste Studie der Standish Group von 2010 zeigt, dass ein gutes Drittel aller Projekte erfolgreich abgeschlossen wird.
Ein Fünftel wird abgebrochen, und der Rest kommt zwar zu einem Abschluss, aber nur unter Aufgabe von ursprünglichen Zielen (Bild 1). Die meisten abgebrochenen Projekte hatten nur ungenügend geklärte Anforderungen und konnten Änderungen der Anforderungen nicht beherrschen.
Auf was sollte man beim Requirements-Engineering achten? Aus unterschiedlichen Praxiserfahrungen lassen sich die wichtigsten Risiken ableiten. Die Risiken zu kennen, heißt, dass man sich darauf vorbereiten kann, um sie beim nächsten Mal zu vermeiden.
Hier einige Beispiele aus Kundenprojekten, bei denen Vector Consulting zur Unterstützung und Moderation gerufen wurde:
- implizite Anforderungen (z.B. Kunde erwähnt Funktionen nicht, da sie für ihn selbstverständlich sind, nur Lieferant weiß dies nicht);
- fehlende Anforderungen (z.B. schwammige Anforderungen, die zwar nötig sind, aber nicht geklärt werden, da sie teuer werden könnten; unklare Ausrichtung des Projekts: Was wird nicht geliefert?);
- Anforderungen, die erst spät klar werden (z.B. Festpreisangebot; Anforderung im Grobkonzept klar, später im Feinkonzept werden weitere Details deutlich, die zu zusätzlichem Aufwand führen);
- Anforderungs-Baseline von vornherein fehlerhaft oder unzureichend (d.h., Kunde hat sich nicht die Zeit genommen, die nötigen Anforderungen zu präzisieren);
- niedrige Qualität der Ausschreibungen (z.B. oberflächlich und missverständlich beschriebene Anforderungen);
- Unsicherheiten und Unklarheiten (z.B. Schätzungen und Pläne basieren auf nicht verstandenen Risiken und oberflächlich dokumentierten Anforderungen);
- unzureichendes Change-Management (z.B. Kundenanforderungen werden vom Projektmanager adhoc ins Produkt aufgenommen);
- fehlende Dokumentation von Basis und Änderungen (z.B. Testfälle setzen auf einer anderen Basis auf als die Entwicklung);
- Varianz und Komplexität (z.B. Mehrfachentwicklungen, die in der Codebasis später inkonsistent werden und einzeln nachverfolgt werden müssen);
- Rotation von Mitarbeitern in ein neues Feld (z.B. Projektmanager übernimmt neues Kundenprojekt und hat nicht das implizite Wissen über den Kunden und dessen Hintergrund).
Anforderungen sauber beschreiben
Eine Anforderung beschreibt, was der Kunde oder Benutzer vom Produkt erwartet (Bedingungen, Attribute, Ziele, Nutzen, etc.). Formal lassen sich Anforderungen wie folgt definieren:
- Eigenschaft oder Bedingung, üblicherweise vom Kunden festgelegt, um ein Problem zu lösen oder ein Ziel zu erreichen.
- Eigenschaft oder Bedingung, die ein System oder eine Systemkomponente erfüllen muss, um einen Vertrag, einen Standard, eine Spezifikation oder andere formal festgelegte Dokumente zu erfüllen.
- Eine dokumentierte Repräsentation einer Eigenschaft oder Bedingung wie in den vorigen Punkten beschrieben.
Wir trennen klar zwischen Anforderungen und Lösungen. Eine Anforderung beschreibt ein Bedürfnis oder einen Nutzen, der erreicht werden soll. Sie beschreibt nicht, wie dieser Nutzen zu realisieren ist. Diese Implementierungssicht wird durch die Lösung beschrieben.
Bild 2 veranschaulicht diesen Unterschied durch die Trennung zwischen Problemraum (Marktanforderungen, Lastenheft, etc.) und Lösungsraum (Lösungsspezifikation, Pflichtenheft, Design, Fachkonzept, etc.). Der Problemraum ist zunächst immer nur unscharf umrissen und wird im Verlauf der Lösungskonzeption eingeschränkt. Es gibt nicht die »Anforderung« schlechthin.
Zu einer Anforderung gehört immer die Perspektive, aus der sie beschrieben wird. Eine Anforderung ist eine Bedingung oder eine Fähigkeit, die ein Benutzer benötigt, um ein Problem zu lösen oder um ein Ziel zu erreichen. Das heißt, sie hängt von der Perspektive ab. Ein Benutzer kann der Kunde sein, der für die Lösung bezahlt, aber es kann auch ein Entwickler sein, der daraus eine Architektur ableitet.
Entsprechend unterschiedlich sind die Schwerpunkte und Inhalte, die diese Anforderung beschreiben soll. Was für den einen die Anforderung, ist für den anderen die Lösung. Man trennt daher in der Praxis unterschiedliche Arten von »Anforderungen«, beispielsweise Marktanforderungen oder Komponentenanforderungen, und vermeidet, von einer »Anforderung« ohne Präzisierung zu sprechen. Drei verschiedene Sichten auf Anforderungen werden im Laufe der Lösungskonzeption unterschieden:
- Marktanforderungen: Sie werden auch als Kunden-, Benutzer- und Geschäftsanforderungen oder Bedürfnisse bezeichnet. Sie sind die Ziele, die Benutzer und die Außenwelt mit dem zu entwickelnden Produkt erreichen wollen. Sie beschreiben, warum ein Projekt überhaupt durchgeführt wird.
- Produktanforderungen: Dies sind Eigenschaften des Produkts und Systemanforderungen, die aus der Sicht des Produkts beschrieben werden. Sie zeigen, was verschiedene Benutzer mit dem Produkt machen können, in der Sprache des Produkts - also auch nichtfunktionale Anforderungen mit den nötigen Details. Sie definieren den Lösungsraum und die Prioritäten.
- Komponentenanforderungen: Dies sind die konkreten Softwareanforderungen, die aus Entwicklersicht beschreiben, wie zu entwickeln ist. Sie umfassen Komponenten, Architektur, Technologien, Struktur und Dynamik sowie Algorithmen. Sie sind hinreichend klar, um eine Komponente durch einen externen Lieferanten entwickeln zu lassen, der den gesamten Systemkontext nicht kennt.
Anforderungen entwickeln
Bild 2 zeigt diese drei Sichten, die sich durch Verfeinerung auseinander ergeben. Offensichtlich ist diese Dreiteilung rekursiv: Die Komponentenanforderung an einen Lieferanten ist dort wiederum eine Marktanforderung. Diese drei Sichten und ihre Trennung sind also nicht im Voraus definiert, sondern hängen von der Lösungsstruktur ab. Beispielsweise könnte ein Benutzer oder Kunde die Anforderung wie folgt stellen:
M-Req-11-18: Das System verwaltet die Kundendaten im Format Name, Vorname, Adresse.
Der Requirements-Ingenieur spezifiziert dazu eine Lösung mit der folgenden Komponentenanforderung:
K-Req-11-24: Die Datenbank zur Verwaltung der Kundendaten wird mit Oracle 10 realisiert.
Offensichtlich sind dies zwei Anforderungen an die Datenhaltung, die aus verschiedener Perspektive beschrieben sind, nämlich Nutzung und Realisierung. Nun könnte aber auch der Kunde bereits eine technische Anforderung zur Realisierung haben, da er eine »mySQL«-Umgebung einsetzt und Kompatibilität sowie günstigere Lizenzkosten will. Er spezifiziert daher:
M-Req-11-19: Die Datenbank zur Verwaltung der Kundendaten wird mit mySQL realisiert.
Nun wird aus der bisherigen Komponentenanforderung (K-Req-11-24) eine Marktanforderung (M-Req-11-19). Gleichermaßen gibt es Situationen, wo das Lastenheft und die Geschäftsanforderungen so vage sind, dass das Pflichtenheft auch als Problembeschreibung fungiert. Anstatt über solche Feinheiten zu debattieren, ist es wichtig, dass die Anforderungen immer mit ihrer jeweiligen Quelle spezifiziert werden. Dann ist zu jedem Zeitpunkt klar, wie es zur Anforderung kam, und welche Freiheitsgrade für eine Änderung bestehen, sofern diese die Realisierung erleichtert. M-Req-11-19 lässt sich sehr viel schwerer beeinflussen als die konzeptionell gleiche K-Req11-24, da die M-Req-11-19 direkt vom Kunden stammt und daher unsere Lösung bereits definiert.
Ziele und Aufgaben des Requirements-Engineering
Requirements-Engineering ist das disziplinierte und systematische Vorgehen, um alle Anforderungen (also Prozessanforderungen, funktionale und nichtfunktionale Produktanforderungen) zu ermitteln, zu spezifizieren, zu validieren, zu analysieren, zu vereinbaren und einem Projekt zuzuweisen sowie im Projekt zu verwalten, und Änderungen konsistent umzusetzen.
Gutes Requirements-Engineering macht den Unterschied aus zwischen einem erfolgreichen Produkt und einer Feature-Sammlung. Requirements-Engineering beschreibt die Disziplin innerhalb der Softwaretechnik und der Systemtechnik, die sich mit den gewünschten Eigenschaften und Einschränkungen von Softwaresystemen befasst. Damit ist gutes Requirements-Engineering eine unabdingbare Voraussetzung für gutes Projektmanagement:
- Das Ziel von Requirements-Engineering ist es, qualitativ gute - nicht perfekte - Anforderungen zu generieren, die es erlauben, das Projekt mit einem akzeptablen Risiko zu beginnen.
- Der Zweck des Requirements-Engineering ist es, ein Einverständnis zwischen dem Kunden und dem Softwareprojekt (also dem Lieferanten) über jene Anforderungen zu erreichen, die durch das Softwareprojekt abgedeckt werden.
Requirements-Engineering ist damit eine sehr bunte und spannende Disziplin. Sie reicht weit über die Softwaretechnik hinaus. Sie bedient sich der Erfahrungen aus der Systemtechnik, der Psychologie, der Betriebswirtschaftslehre, dem Marketing, dem Produktmanagement, dem Projektmanagement und natürlich der Informatik. Durch Requirements-Engineering werden Ziele konkretisiert, Wünsche geweckt und Realitäten geschaffen.
Da es keine absoluten Wahrheiten gibt, kommt dem Requirements-Engineering die einmalige Aufgabe zu, Wahrnehmungen und Ziele zu entwickeln. Es stellt zudem sicher, dass der Projektmanager das Projekt zu jedem Zeitpunkt unter Kontrolle hat - ohne dass die Eigendynamik aus Kundenbeziehungen, Herausforderungen in der Realisierung und den zahlreichen politischen Risiken ihn zu einem Spielball externer Interessen machen.
Es ist in diesem Zusammenhang bewusst kein Prozess (also eine Abfolge von Schritten über die Zeit) dargestellt, denn der hängt von den Randbedingungen an das Projekt ab (Bild 4). Beispielsweise fordert ein agiles Requirements-Engineering mehr Flexibilität und Kundenbeteiligung als ein relativ starres Vorgehen in Konsortien verschiedener Unternehmen.
Bild 3 impliziert aber eine gewisse Ordnung, die unabhängig vom Vorgehensmodell gilt. Offensichtlich kommt die Analyse der Anforderungen nach deren Ermittlung. Unterschieden wird dabei eher, wie viele Anforderungen sinnvollerweise ermittelt sein müssen, um ein Projekt zu schätzen oder zu starten. Dies erklärt im oberen Teil von Bild 3 die Sequenz von Schritten.
Spezifikation/Verifikation sowie Verfolgung/Änderungsmanagement sind zeitlich nicht limitiert. Das Änderungsmanagement muss es bis zum Projektende geben, und der Bedarf dafür wird im Laufe des Projekts eher größer. Standardisierte Prozesse schaffen Wiederholbarkeit, Transparenz und Effizienz. Aber, so wenig es einen einzigen überall gültigen Entwicklungsprozess aus dem Buch gibt, so wenig passt ein einziger Prozess für das Requirements-Engineering.
Markterfordernisse, Produkte und Projekte sind zu unterschiedlich, um alle Prozesse über einen Kamm zu scheren. Allerdings kann und sollte es für bestimmte Projekttypen im Unternehmen definierte Prozesse für das Requirements-Engineering geben. Wenn ein Unternehmen beispielsweise eine Produktlinie hat, die sowohl eine Plattform als auch Varianten davon für Kunden produziert, dann ist es sicherlich sinnvoll, die Variantenproduktion durch einen definierten Prozess zu steuern. Ein solcher Prozess könnte beispielsweise Zugriff auf alle existierenden Funktionen der ganzen Produktlinie bieten, sodass Entscheidungen zu Durchführbarkeit und Aufwand vereinfacht und reproduzierbar werden.
Nutzen von Requirements-Engineering
Prozesse sind durch die Dokumente oder Arbeitsergebnisse am Eingang und Ausgang von Prozessschritten definiert (Tabelle 1).
| Arbeitsergebnisse | Ermittlung | Analyse | Prüfung | Abstimmung | Verwaltung |
|---|---|---|---|---|---|
| Vision | x |
||||
| Use-Case/Szenario | x | ||||
| Bewertung | x | x | x | x | |
| Lastenheft, SLA | x | x | x | x | x |
| Projektplan | x | x | x | x | |
| Teststrategie | x | x | x | ||
| Lösungsmodell | x | x | x | ||
| Pflichtenheft | x | x | x | x | |
| Release-Planung | x | x | x | ||
| Produktkatalog | x | x | |||
| Vertrag | x | x | x | ||
| Abhame | x |
x |
Tabelle 1: Arbeitsergebnisse und Dokumente im Requirements-Engineering
Jeder Prozess bearbeitet bestimmte Dokumente, verändert sie und führt damit schrittweise zum endgültigen Produkt. Definierte Meilensteine und Freigabekriterien in der Verifikation und Validierung sichern eine ausreichende Qualität dieser Dokumente. Die Meilensteine im Produktlebenszyklus prüfen, ob diese Dokumente freigegeben sind.
Im Requirements-Engineering werden verschiedene Dokumente erzeugt beziehungsweise bearbeitet, auf die nachher weitere Entwicklungsschritte aufbauen. Tabelle 1 bildet die wesentlichen Arbeitsergebnisse auf die Aktivitäten des Requirements-Engineering ab. Mit diesen Herausforderungen und diesen zahlreichen externen Einflüssen ist Requirements-Engineering aber auch sehr schwierig in der erfolgreichen Umsetzung.
Betrachten wir ein einfaches Beispiel, die Änderungen von Anforderungen. Eine gemeinsame Eigenschaft jeglicher Software und damit auch von Softwareanforderungen ist, dass sich die Anforderungen im Lebenszyklus ständig ändern. Anforderungen sind in aller Regel unsicher. Sie ändern sich mit einer monatlichen Rate, die ein bis fünf Prozent des gesamten Projektaufwands betragen kann. Das heißt, dass sich von Anforderungen, die mit insgesamt einhundert Personenwochen Projektaufwand ursprünglich abgeschätzt wurden, pro Monat Anforderungen im Umfang von bis zu fünf Wochen ändern.
Diese fünf Wochen relative Änderung sind nicht immer mit fünf Personenwochen Aufwand zu erledigen. Wenn man sich vorstellt, dass die Änderung erst kommt, nachdem die Anforderung bereits integriert ist, dann kann eine Änderung ein Vielfaches des ursprünglich dafür nötigen Aufwands betragen. Diese Hebelwirkung unterstreicht den Geschäftsnutzen eines systematischen Requirements-Engineering.
Was über diesen fünf Prozent Änderungsrate pro Monat liegt, gefährdet den Projektverlauf massiv und lässt sich eigentlich nur mit evolutionären Vorgehensweisen abfangen. Gutes Requirements Engineering stellt sicher, dass der Projektmanager zu jedem Zeitpunkt aus Kundensicht weiß, welche Anforderungen bereits implementiert, getestet oder freigegeben sind. Er muss dies wissen, um bei Gefahr von Terminüberschreitungen rechtzeitig niedrig priorisierte Anforderungen verschieben zu können.
Über den Autor:
Dr. Christof Ebert ist Geschäftsführer und Partner der Vector Consulting Services.
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Projektmanagement
Entwicklungen erfolgreich gestalten
Embedded Office
IEC-62304-Zertifizierungskit für Echtzeitkernel…
