Requirements Engineering

Martin Weck

This article is also available in English

Begriffe

Das IEEE Standard Glossar des Software Engineering (1990) [1] definiert eine Anforderung (engl. requirement) als [Übersetzung des Autors]:

1. Eine Bedingung oder Fähigkeit, die ein Nutzer benötigt, um ein Problem zu lösen oder ein Ziel zu erreichen.
2. Eine Bedingung oder Fähigkeit, die ein System oder eine Systemkomponente erfüllen oder besitzen muss, um einen Vertrag, Standard, Spezifikation oder ein anderes formales Dokument zu erfüllen.
3. Eine dokumentierte Repräsentation einer Bedingung oder Fähigkeit gemäß 1 oder 2.

Requirements Engineering beschäftigt sich nun mit der Frage, welche Probleme gelöst werden sollen, warum sie gelöst werden sollen und wer für ihre Lösung verantwortlich ist. Formal:

Requirements Engineering ist die Domäne, die alle Aktivitäten umfasst, Anforderungen zu entwickeln und im Folgendem die Anforderungen durch den Entwicklungsprozess bzw. während der Lebenszeit des Systems zu managen [2].

Im Requirements Engineering werden vor allem die folgenden drei Gruppen betrachtet:

• Funktionale Anforderungen spezifizieren die Funktionalität, die Entwickler in ein Produkt bauen müssen, um Nutzer zu befähigen, ihre Aufgaben zu bewältigen
• Nicht-funktionale Anforderungen sind Forderungen nach Einhaltung von Qualitätsattributen (s. Kasten).
• Rahmenbedingungen (engl. constraint) sind organisatorische oder technologische Einschränkungen des Freiheitgrades eine Lösung bereitzustellen.

Prof. Pohl schlägt ins seinem Buch [3] die Vermeidung des Begriffs nicht-funktionale Anforderungen vor zugunsten des Begriffes Qualitätsanforderungen, die dem obigen Begriff der nicht-funktionalen Anforderungen entsprechen. Dazu zeigt er, dass Anforderungen, die nicht auf Qualitätsattribute oder Rahmenbedingungen zurückzuführen sind, sich in funktionale Anforderungen umwandeln lassen. Während funktionale Anforderungen klären, was ein System machen soll, legen Qualitätsattribute fest, wie gut die Umsetzung sein soll bzw. wie gut das System bzgl. verschiedener Charakteristika sein soll. Wenn man die verschiedenen Qualitätsattribute betrachtet, dann ergibt sich daraus, dass manche sich ausschließen. D.h. in der Praxis wird man immer versuchen, abzuwägen und einen Kompromiss zwischen den verschiedenen Qualitätsattributen zu finden [4].

Warum Requirements Engineering?

Nachdem die Begriffe im vorherigen Abschnitt geklärt wurden, fragt sich der Praktiker, welchen Mehrwert es bringt, solche Anforderungen, Rahmenbedingungen für ein zu erstellendes bzw. zu modifizierendes System zu definieren. Die ersten Anforderungen an ein System sammeln Nutzer/Auftraggeber, bevor die ersten Funktionalitäten bereitgestellt werden. Allgemein gilt, je früher Fehler erkannt werden, umso kostengünstiger ist ihre Behebung. D.h. es ist preisgünstiger Anforderungen, die bisher lediglich schriftlich gesammelt wurden, zu ändern, als die Funktionalität, die die Anforderung umsetzt, in einem getesteten, dokumentierten und ausgelieferten System zu ändern. Tatsächlich entstehen die höchsten Kosten in Software-Projekten durch Fehler in den Anforderungen, die erst nach Auslieferung des Systems entdeckt werden [5]: Fehler in den Anforderungen sind die teuersten Software Fehler.

Es gibt unterschiedliche Statistiken [6][7], die zeigen, dass die meisten Fehler eines IT-Systems auf falsche oder fehlende Anforderungen zurückzuführen sind. Diese bleiben über lange Zeiträume in den IT-Systemen erhalten, sodass man sagen kann Fehler in Anforderungen sind zahlreich und persistent.

Die Entwicklung jeder Codezeile kostet Ressourcen. Neben Kosten, die bei Design und Umsetzung entstehen, fallen auch Kosten durch Tests, Dokumentation und spätere Wartung an. Wenn man berücksichtigt, dass die Mehrheit der Projekte über Budget sind und ihren Zeitrahmen sprengen (z.B. sind im Jahr 2015 19% fehlgeschlagen, 52% mit Schwierigkeiten durchgeführt worden, und nur 29% erfolgreich umgesetzt worden [8]), und erst durch die Anforderungsanalyse klar wird, was entwickelt werden soll, kann man folgern, dass eine korrekte Ressourcenplanung erst durch Requirements Engineering ermöglicht wird.

Requirements Engineering erlaubt eine frühzeitige Entdeckung von Fehlentwicklungen im Projekt. Die Validierung von Anforderungen erlaubt eine zusätzliche Absicherungsebene, die neben Validierungen, die durch verschiedene Tests erfolgen, dazu beiträgt, die Qualität der Software zu erhöhen.

Ohne ein hinreichendes Requirements Engineering werden Nutzer nicht eingebunden (d.h. für Nutzer inakzeptable Produkte werden erstellt), es werden ggf. ganze Gruppen von Benutzern übergangen (d.h. unzufriedene Kunden), Anforderungen nicht erfasst (Projektplanung wird unmöglich), schleichende Anforderungen werden implementiert (engl. creeping requirements, Umfang einer Anforderung wächst über die ursprünglichen Vorstellungen hinaus), mehrdeutige Anforderungen entstehen (ggf. werden falsche Lösungen implementiert) oder es wird über das Ziel hinausgeschossen (engl. Gold-plating, Funktionalität wird implementiert, die vom Kunden gar nicht angefordert wurde). In all diesen Fällen gehen Ressource (Zeit, Mannstunden) verloren, die nur durch Zusatzinvestitionen ausgeglichen werden können.

Da die Anforderungen festlegen, was implementiert werden soll, folgt, dass auch die Korrektheit und Vollständigkeit einer Implementierung erst durch Abgleich mit den existierenden Anforderungen festgestellt werden kann. Das Verhältnis der Korrektheit/Vollständigkeit zu den verwendeten Ressourcen definiert die Effizienz, mit der Software entwickelt wird. Eine effiziente Entwicklung von Software ist daher nur durch Requirements Engineering möglich.

Wann soll man Requirements Engineering durchführen?

Die Entwicklung von Software ist hochkomplexe Wissensarbeit [9], welche aufgrund der vielen Unbekannten eine sequentielle Abarbeitung nicht ermöglicht, sondern i.d.R. iterativ erfolgt. Dies führte vom einstigen Wasserfallmodell weg hin zu Agilen Methodiken der Softwareentwicklung, wie z.B. Scrum, bei der die Software in Iterationen (i.e. Sprints) erstellt wird. Da Requirements Engineering festlegt, was zu entwickeln ist und wie gut, folgt, dass auch Requirements Engineering ein iterativer Prozess ist, der mit dem Prozess der Software Entwicklung verwoben ist. Dies ist wenig verwunderlich, wenn man bedenkt, dass Softwareentwicklung i.d.R. von Menschen durchgeführt wird und das Problemlösen mittels des menschlichen Gehirns sich als Kreisprozess darstellen lässt [9]. Requirements Engineering durchwebt also die Softwareentwicklung und findet somit iterativ, zeitgleich zur Entwicklung statt, beginnt i.d.R. aber bereits, bevor mit der Entwicklung begonnen wird.

Fordert ein Projekt, z.B. aufgrund von Zertifizierungsvorgaben, die Bereitstellung von Dokumenten, die abgenommen werden müssen, so kann man den Inhalt dieser Dokumente durch Momentaufnahmen erhalten. Ein Anforderungsdokument würde in diesem Fall den Wissensstand zu einem bestimmten Zeitpunkt widerspiegeln. Diese Momentaufnahme wird nie endgültig oder vollständig sein.

Die Beobachtung, dass Requirements Engineering, wie Software Engineering, ein iterativer Prozess ist, erlaubt uns, die oben eingeführten Begriffe in einem Modell zusammenzuführen, das im folgenden Abschnitt vorgestellt wird.

Die Anforderungsbrezel

Die Erstellung von Software ist komplex. Selbst bei einem gewissenhaftem Requirements Engineering kann nicht ausgeschlossen werden, dass manche Anforderungen nicht erfasst werden oder sie sich im Laufe der Zeit ändern. Bei Sichtung bzw. Erstellung der Anforderungen müssen Widersprüche aufgelöst werden und Kompromisse zwischen konkurrierenden Anforderungen gefunden werden. Auch Rahmenbedingungen, die zu spät erfasst werden oder sich ändern, können gravierende Auswirkungen nach sich ziehen.

Die Umsetzung ist ebenfalls komplex, weil häufig unterschiedliche Lösungsansätze zum Ziel führen und bei der Implementierung eine Auswahl getroffen werden muss. Selbst wenn der Auftraggeber eine genaue Vorstellung der Lösung zu haben glaubt, erreicht diese nur einen limitierten Detaillierungsgrad und ändert sich in der Praxis häufig im Laufe der Zeit. Zum einen erwerben Auftraggeber und Umsetzer der Lösung zusätzliches Wissen im Laufe des Projektes, zum anderen können sich, wie oben erwähnt, Anforderungen oder Rahmenbedingungen ändern, was dann eine Änderung der Lösung erfordern kann. Die Erstellung der Software lässt sich also als dialektisches System auffassen, d.h. ein System bei dem Eingabe, Operatoren und Ausgabe unbekannt sind. Obwohl es viele dokumentierte Empfehlungen und persönliche Erfahrungen gibt, ist für Praktiker jedes Projekt anders und bietet neue Herausforderungen.

Um dieser Komplexität Herr zu werden, hilft eine vereinfachte Abbildung der Wirklichkeit (d.h. ein Modell), mit der die wesentlichen Punkte ausgearbeitet werden. Anschließend kann das Modell je nach Bedarf ausgebaut werden, um einen für die Praxis hinreichenden Detaillierungsgrad zu erreichen. Das in Abb. 1 dargestellte Modell erarbeiten wir im Folgenden Schritt für Schritt (Nummern der Elemente werden im Text in Klammern angegeben).

Nutzer

Im einfachsten Fall möchte ein Nutzer eine gewisse Funktionalität haben, um bestimmte Ziele (1) mittels Software zu erreichen, die jemand anderes, der die Fachkompetenz hat, Software zu entwickeln (im Folgenden als Techniker bezeichnet) ihm bereitstellen soll. Auf Basis dieser Nutzerwünsche lassen sich funktionale Anforderungen (2) definieren. Obwohl der Nutzer einen starken Fokus auf die Fachlichkeit hat, verfügt er ggf. auch über Umsetzungswissen (3), aufgrund seiner möglicherweise vorhandenen Erfahrungen mit IT-Systemen. Dieses Umsetzungswissen wird allerdings höchstwahrscheinlich deutlich geringer ausgeprägt sein, als das des Technikers.

In der Praxis wird der Nutzer Einschränkungen ausgesetzt sein, die bei Realisierung seiner Wünsche einzuhalten sind. Solche Rahmenbedingungen (4) können Gesetze sein, Unternehmensvorgaben, beschränkte Ressourcen usw.. All diese Elemente ergeben Aufgaben, die, genau beschrieben, wir als Stories bezeichnen. Diese können Stories (5) entsprechen, wie sie Scrum definiert [9], können aber auch andere Systemausgaben repräsentieren.

Der Techniker setzt diese Stories um, sodass eine prüfbare Ausgabe entsteht. In einem eher abstrakten Ansatz mögen das lediglich detaillierte Beschreibungen sein, in einem konkreten Ansatz eine lauffähige Software. Diese kann der Nutzer mit starkem Fokus auf Funktionalität z.B. mittels Use Cases testen (6). Der Nutzer ermittelt, welche Funktionalität vorhanden ist, fehlt oder unvollständig ist, und überprüft die Verwendbarkeit (7). Parallel wird der Nutzer auch auf die Einhaltung seiner Gesamtziele (1) achten. Er definiert dann ggf. neue funktionale Anforderungen (2) bzw. priorisiert diese neu, welche zusammen mit seinem Umsetzungswissen (3) und Rahmenbedingungen (4) zu neuen Stories (5) führen. Diese Iterationen im Kreis setzen sich kontinuierlich fort bis die Nutzerziele hinreichend erreicht wurden bzw. die Rahmenbedingungen den Entwicklungsprozess so stark eingeschränkt haben, das keine Bewegung mehr möglich ist.

Techniker

Parallel dazu arbeitet der Techniker, immer die Nutzerziele (1) vor Augen. Der Schwerpunkt des Technikers wird auf dem Umsetzungswissen (7) liegen, das er vor allem zur Definition und Umsetzung von Stories beiträgt, dabei immer unter Berücksichtigung der Rahmenbedingungen (9). Er wird dabei versuchen, Qualitätsattribute (8) einzuhalten, die dem Nutzer erlauben, Funktionalität zufriedenstellend zu nutzen. Nur wenn das nicht gelingt, wird auch der Nutzer auf mangelnde Qualität aufmerksam (z.B. zu lange Antwortzeiten eines Systems). Mit Hilfe dieser Elemente (7–9) sowie der Eingabe des Nutzer (2–4), welche durch des Nutzers Fachwissen geprägt sein sollte, detailliert der Techniker die Stories (5), sodass er sie schließlich umsetzen kann. Das Ergebnis reicht von einer detaillierten Beschreibung, wie Stories umgesetzt werden können, bis hin zu einer realisierten Software, die der Techniker technisch testen kann (Unit- bis Integrationstests (10)).

Dabei überprüft er Features (12) sowie das allgemeine Verhalten des Systems (11). Während das Verhalten Aussagen über die Qualitätsattribute des Systems erlaubt, geben Features Aufschluss über die Korrektheit und Vollständigkeit der Realisierung (13). Diese werden zur erneuten Definition/Verfeinerungen/Priorisierung der Anforderungen (8) führen. Diese, vereint mit dem Umsetzungswissen (7), unter Berücksichtigung der Rahmenbedingungen (9) und den Eingaben des Nutzer (2–4), führen zur Ausarbeitung und Umsetzung von Stories (5) in der nächsten Iteration.

Kosten und Kontext

Nutzer und Techniker arbeiten iterativ, parallel, ggf. versetzt im Kreis, teilen sich aber die Stories, welche das Software-System repräsentieren, das im Mittelpunkt des Modells steht. Als Ausgabe entstehen neben den Stories auch Kosten (14) aus Sicht des Nutzers, aber auch aus Sicht des Technikers, in Form von konsumierten Ressourcen (Mannstunden, Hardware etc. (15)), deren Grenzen, wer für was aufkommt, in Verträgen hart umkämpft sind. Die sich hieraus ergebende Anforderungsbrezel bewegt sich innerhalb eines Systemkontextes, in dem die Grenzen des Systems verlaufen (hier Grenzen der Brezel). Den Systemkontext sowie die Nutzerziele müssen Nutzer wie Techniker bei jeder Iterationen immer wieder berücksichtigen, ggf. zugunsten einer pragmatischen Lösung auf Details verzichten, um Budget und Zeitrahmen des Projektes einzuhalten.

Zusammenspiel der Iterationskreise

In größeren Softwareprojekten sind mehrere Menschen beteiligt, die sich der Nutzer- oder Technikerrolle zuteilen lassen. Ggf. füllen sie nur einen Teil der Rolle aus und andere Personen übernehmen die anderen Teile. Alternativ könnte man davon ausgehen, dass jeder einen eigenen Iterationskreis hat, der sich die Stories mit allen teilt. Am Ende lassen sich diese Kreise aber alle auf den Iterationskreis des Nutzers bzw. Technikers reduzieren. Das hier vorgestellte einfache Modell übergeht damit nicht die Forderung, dass in Softwareprojekten alle Stakeholder mit einzubeziehen sind. Im Gegenteil. Laut Modell müssen Techniker und Nutzer sich über Stories austauschen können. Beispielsweise ist es unzulässig, eine detaillierte Spezifikation zu erstellen und diese von reinen Entwicklern offshore entwickeln zu lassen, ohne dass diese sich mit den Nutzern austauschen können. In der Praxis erreicht die Spezifikation nie die notwendige Genauigkeit, da Softwareentwicklung Wissensarbeit ist [8], sodass Anforderungen nicht bis zur Umsetzung durchdringen. Umgekehrt ist es unzulässig, Nutzer durch Business Analysten komplett zu ersetzen, weil z.B. eine White-Label-Lösung entwickelt wird, bei der Nutzer noch nicht existieren. Vielmehr sollten einzelne Stories zügig so weit entwickelt werden, dass sie einer Testgruppe von Nutzern bereitgestellt werden können.

Im Modell wird der Nutzer in den Vordergrund gerückt, da der Kunde, der zahlt, zwar aus wirtschaftlicher Sicht bestimmt, aber Nutzer festlegen, ob das System nutzlos ist oder nicht. Dies ist besonders bei Softwareprojekten der Fall, die im Rahmen des Platform Business Models [10] entwickelt werden, bei dem der Nutzer im Fokus steht [11].

Die wesentliche Herausforderung im Modell besteht beim Zusammenführen der Eingaben des Nutzers sowie des Technikers zu Stories. Dabei steuern beide Wissen bei, was in beide Richtungen hinreichend übertragen werden muss, damit eine erfolgreiche Kommunikation möglich ist. Es ist unerlässlich, dass der Nutzer sein Fachwissen an den Techniker überträgt, sodass dieser die Anforderungen richtig interpretieren kann und die Stories richtig erstellt werden. Umgekehrt muss der Nutzer so viel technisches Wissen erwerben, dass er mit den Stories umgehen kann. Dieses Übertragen von Wissen auf Basis der Kommunikation zwischen fachlicher und technischer Domäne mittels Anforderungen ist essentiell, um die Stories erfolgreich zu realisieren und damit effektiv und effizient Software zu entwickeln.

Fazit

Erfassung und Management von Anforderungen sind die Basis für eine effiziente Softwareentwicklung und helfen, kostspielige Fehlentwicklungen in Projekten frühzeitig zu vermeiden. Dieses Requirements Engineering und Management durchwebt den iterativen Prozess der Softwareentwicklung. Dieser iterative Kreisprozess dreht sich einerseits um die Gruppe der Nutzer und andererseits um die Ersteller der Software, die beide zum Ergebnis, zur Software, beitragen. Alle Stakeholder sind einzubeziehen und nicht ersetzbar durch Repräsentanten. Nicht der bezahlende Kunde, sondern der Nutzer, der das System nutzt, ist entscheidend.

Referenzen