SSE Anforderungen - Ralf Bürger

Systematische
Software-
Entwicklung
Anforderungen

Die folgende Formel berechnet das
Risiko für eine Anforderung als
Kennzahl von 1 (minimal, unterste
Pfeilzeile) bis 27 (maximal, oberste
Pfeilzeile).
R = 1 x P (1 bis 3) + 3 x V (1 bis 3) + 9 x K (1 bis 3)
- (1+3+9) +1
Dabei bestimmt sich also der Grad des
Risikos einer Anforderung aus folgenden
Attributen der Anforderung:
- Priorität
- Variabilität
- Komplexität
Diese werden jeweils grob als niedrig,
mittel oder hoch (Wert 1, 2 oder 3)
bestimmt und entsprechend in die
Formel oben eingesetzt. Das
entspricht den grünen, gelben oder
roten Pfeilen in dem Bild links.
Dann erfolgt in der Formel eine
Gewichtung, nach der die Komplexität
den größten Einfluss nimmt, die
Variabilität den mittleren und die
Priorität tatsächlich den geringsten.
Die zweite Zeile der Formel oben
sorgt lediglich für eine fortlaufende
Ergebniszahl ab 1.
Ein Risiko ist übrigens etwas, aus dem
später ein konkretes Problem entstehen
kann.
s. Kapitel 5.3 auf Seite 101
(„Anforderungsattribute“)

Mantra-Bibliothek auf Reis-Papier in einem tibetischen Kloster (Foto Ralf Bürger 2008)
„Viele möchten in einem Tag verschlingen,
was sie kaum im ganzen Leben verdauen können.“
(Balthasar Gracián)
Inhaltsverzeichnis
1 Einführung .......................................................................................... 5
1.1 Inhalt ................................................................................................ 5
1.2 Vorwort............................................................................................ 6
1.3 Konventionen .................................................................................. 8
2 Startanalyse ...................................................................................... 10
2.1 Inhalt .............................................................................................. 10
2.2 Das S im SADITÜP-Mosaik ............................................................. 11
2.3 Verantwortung .............................................................................. 13
2.4 Name und Hauptziel ...................................................................... 16
2.4.1 Beispiele für Hauptziele ....................................................... 19
SSE – Systematische Software-Entwicklung 1

2.4.2 Embedded Systems............................................................. 20
2.5 Zweck und Tragweite (Purpose & Scope) ..................................... 22
2.5.1 Weitere Beispiele ................................................................ 28
2.5.2 Embedded Systems............................................................. 30
2.6 Prosatext ....................................................................................... 31
2.7 Modelle und Prozesse ................................................................... 33
2.7.1 Geschäftsmodelle und Geschäftsprozesse ......................... 33
2.7.2 Vorgehensmodelle und Entwicklungsprozesse .................. 38
2.8 Was also ist die Startanalyse ....................................................... 40
2.8.1 Embedded Systems............................................................. 45
2.8.2 Softwareprojekte für Softwareprodukte ............................ 45
3 Anforderungsmanagement ............................................................... 47
3.1 Inhalt ............................................................................................. 47
3.2 Definitionen .................................................................................. 48
3.3 Sind Anforderungen wichtig ....................................................... 53
3.4 Das A im SADITÜP-Mosaik ............................................................ 55
4 Anforderungssammlung ................................................................... 59
4.1 Inhalt ............................................................................................. 59
4.2 Arten von Anforderungen ............................................................. 60
4.2.1 Funktionale Anforderungen ............................................... 60
4.2.2 Nicht-funktionale Anforderungen ...................................... 69
4.2.3 Technische Anforderungen................................................. 74
4.3 Kommunikation durch Interviews ................................................ 78
4.4 Anforderungslisten ....................................................................... 84
4.5 Folgeiterationen ........................................................................... 89
5 Anforderungsanalyse........................................................................ 92
5.1 Inhalt ............................................................................................. 92
5.2 Prüfung der Anforderungen.......................................................... 93
5.3 Anforderungsattribute ................................................................ 101
5.4 Akzeptanzkriterien ...................................................................... 110
5.5 Protokolle.................................................................................... 114
5.6 Hilfreiche Prinzipien .................................................................... 118
5.6.1 Hierarchisierung ............................................................... 118
5.6.2 Modularisierung ............................................................... 119
5.6.3 Strukturierung .................................................................. 120
5.6.4 Granulierung ..................................................................... 121
5.6.5 Beherrschung .................................................................... 122
5.6.6 Mustererkennung ............................................................. 123
2 SSE – Systematische Software-Entwicklung

5.6.7 Fazit ................................................................................... 124
6 Wo endet die Analyse ................................................................... 126
6.1 Inhalt ............................................................................................ 126
6.2 Vom „was“ zum „wie“ ................................................................. 127
6.3 Anwendungsfälle ......................................................................... 133
6.3.1 Embedded Systems ........................................................... 144
6.4 Prototypen ................................................................................... 146
6.5 Testfälle ....................................................................................... 153
6.6 Schätzung und Machbarkeiten .................................................... 159
7 Der weitere Verlauf ........................................................................ 164
7.1 Inhalt ............................................................................................ 164
7.2 Änderungsanforderungen ........................................................... 165
7.3 Abnahme ..................................................................................... 171
7.4 Gehegt und gepflegt .................................................................... 174
8 Anhang ........................................................................................... 179
8.1 Inhalt ............................................................................................ 179
8.2 Bücher.......................................................................................... 180
8.3 Analyseprozess ............................................................................ 181
8.4 Änderungshistorie ....................................................................... 185
8.5 Index, Abkürzungsverzeichnis, Glossar ........................................ 186
Vita ...................................................................................................... 201
SSE – Systematische Software-Entwicklung 3

Startanalyse / Das S im SADITÜP-Mosaik 2.2
„Genau genommen leben sehr wenige Menschen in der
Gegenwart - die meisten bereiten sich gerade vor, demnächst
zu leben.“
(Jonathan Swift)
2.2 Das S im SADITÜP-Mosaik
(Kartenspiel Vorgehensmodell Entwicklungsprozess Teilprozess)
Wenn Sie mein Buch „Das SADITÜP-Mosaik“ kennen, werden Sie den
nächsten Absatz sicherlich auf Anhieb verstehen. Ansonsten sollten Sie ihn
vielleicht zwei Mal lesen – oder das Buch
Eigentlich sagt der Untertitel der Überschrift dieses
Kapitels schon alles: Ich habe ein Kartenspiel mit den
Buchstabenkarten S, A, D, I, T, Ü und P entworfen,
die den Teilprozessen entsprechen, die in nahezu
allen Softwareentwicklungsprozessen vorkommen.
Diese Karten können Sie auslegen, um ein Vorgehensmodell
zu entwerfen – quasi als Mosaik dieser
Buchstaben. Anhand dieses Vorgehensmodells können
Sie dann Ihre Teilprozesse passend ausgestalten
und zu einem gesamten Softwareentwicklungsprozess
zusammensetzen.
Teilprozesse
S tartanalyse
A nalyse
D esign
I mplementierung
T est
Ü bergang
P flege
Ein Beispiel für ein solches Mosaik sehen Sie auf dem Deckblatt dieses
Buches. Dort sind das S und das A hervorgehoben, weil es in diesem
Buch hier genau um diesen Schwerpunkt geht: Die Startanalyse sowie die
Anforderungssammlung und –analyse.
Die ersten Anforderungen werden in der Regel aber bereits ganz am Anfang
des Projekts vorliegen, denn sonst würde es wohl gar nicht erst zum
SSE – Systematische Software-Entwicklung 11

2.2 Startanalyse / Das S im SADITÜP-Mosaik
Projekt kommen. Allerdings sollte man ganz am Anfang des Projekts noch
die Anforderungen von dem Bedarf, dem Nutzen und den Zielen trennen.
Zumindest macht das den Einstieg ins Projekt bewusster
und damit sicherer und oft für alle Beteiligten einfacher.
am Anfang Der Bedarf soll gedeckt werden, der Nutzen soll erbracht
Bedarf werden und das Ziel soll erreicht werden. Der Bedarf zeigt
Nutzen auf, was einem fehlt, der Nutzen zeigt auf, was man davon
für Vorteile hätte, und das Ziel zeigt auf, wo man
Ziel
steht, wenn man es geschafft hat.
Wenn Sie jetzt spontan das Gefühl haben, dass dies mehr ist, als Sie bisher
beim Thema „Anforderungsmanagement“ gehört haben, sind Sie nicht
allein! Am Anfang des Projekts steht tatsächlich meistens das S - die
Startanalyse. Dies ist den Leuten oft nicht bewusst – und genau das ist
meistens das Problem: die Manager machen die dicken Fehler am Anfang
und die Entwickler müssen das später ausbaden. Sie merken schon: Ich bin
ein Freund vom „Frontloading“, also dem „nach-vorne-holen“ von Problemen.
Das mache ich auch mit Risiken - aber lassen Sie die Fehler ruhig
hinten, denn die frühen Fehler waren im Nachhinein schon immer die
teuersten Fehler!
Ich möchte hier also zunächst die Startanalyse ins Bewusstsein rücken,
bevor ich in die eigentliche Anforderungssammlung und -analyse einsteige.
In diesem Buch erkläre ich also die Teilprozesse S und A des SADITÜP-
Mosaiks ausführlicher.
In aller Regel hat ein Softwareentwicklungsprozess übrigens genau ein S ,
aber mehrere A , weil ein Projekt in der Regel genau einen Start hat und
mehrere Entwicklungsiterationen, die jeweils mit einer - ggf. kurzen - Anforderungsanalyse
beginnen. Diese mehreren Entwicklungsiterationen
können natürlich auch mehrere Wasserfalldurchläufe sein. Es können aber
auch V-Durchläufe sein, die zwischen System- und Software-Anforderungen
unterscheiden; dann haben Sie auf die A-Karten meines SADITÜP-
Kartenspiels vielleicht noch „Sys“ und „SW“ geschrieben, um sie zu unterscheiden.
12 SSE – Systematische Software-Entwicklung

3.4 Anforderungsmanagement / Das A im SADITÜP-Mosaik
Wurde für Ihr Projekt eine Art von Wasserfallmodell gewählt, bei dem
eigentlich alle Teilprozesse brav nacheinander ablaufen, dann kommt das A
einmal am Anfang nach der Startanalyse. Dann müssen Sie das Thema auch
ausschöpfend behandeln und alle Anforderungen finden, und Sie müssen
sie auch so analysieren, dass damit das gesamte Design erstellt werden
kann und im Übergang die Abnahme sicher erfolgen kann.
Wenn Sie mehrmals einen Wasserfall durchlaufen (oder ein Spiralmodell)
und damit iterativ-inkrementell vorgehen, dann sollten Sie auch am Anfang
eine gründliche Analyse durchführen, damit Sie bei den einzelnen Iterationen
keine grundsätzlichen Überraschungen mehr erleben. Die einzelnen
Iterationen betrachten dann in der Analyse nur noch ihre spezifischen
Arbeitspakete. Die gründliche Analyse am Anfang kann auch iterativ die
Arbeitspakete der Projektiterationen finden und analysieren. Dabei sollten
Sie nur so weit gehen, wie es nötig ist, um sicher genug die Projektiterationen
vorzuplanen. Der Rest sollte in den Analysen zu Beginn der Projektiterationen
erfolgen.
Das kann bei einem Modell, das eher einem evolutionären Treiben von
Prototypen ähnelt, anders sein. Dann fällt die Analyse am Anfang des Projekts
wahrscheinlich sehr kurz aus und die Analysen am Anfang jeder Projektiteration
dafür etwas länger. So ein Modell werden Sie aber auch nur
bauen, wenn Sie am Anfang schon wissen, dass keine grundsätzlichen
Überraschungen drin sind.
Wenn Sie nach einem V-ähnlichen Modell vorgehen, so werden Sie wahrscheinlich
die Software als Teil eines komplexeren Systems ansehen. Deshalb
werden Sie wahrscheinlich zunächst eine Systemanalyse durchführen,
die zu einem Systemdesign führt. Von beidem werden Sie in der Software-
56 SSE – Systematische Software-Entwicklung

Anforderungsmanagement / Das A im SADITÜP-Mosaik 3.4
analyse die Anforderungen ableiten, die Sie dann in einem Softwaredesign
genauer spezifizieren. Dieses Modell kann bei komplexen Softwaresystemen,
an denen mehrere Parteien beteiligt sind, sehr sinnvoll sein, aber es
kann auch eine Hardware-nahe Software unterstützen (engl. „embedded
System“).
Bei einem Forschungs- oder Vorserienprojekt, wo Sie noch gar nicht wissen,
was überhaupt geht, versuchen Sie vielleicht immer verschiedene
Ansätze parallel, entscheiden sich dann für einen und starten neu durch
zur nächsten Iteration. Dann werden Sie nur analysieren können, was Sie
schon sehen können und der Rest wird Sie während des Designs oder der
Implementierung überraschen. Hier sollten Sie alles, was im Nachhinein
aufkommt, rückwirkend dokumentieren, damit Sie wieder eine solide Basis
für die nächste Iteration bekommen. Da Sie mit Ihren Ergebnissen nicht
wirklich in Produktion oder gar in Serie gehen werden, haben Sie entsprechend
wenige Tests und keine Pflege als Teilprozesse im Modell.
Ein weiteres Vorgehensmodell haben Sie schon auf dem Umschlag dieses
Buchs gesehen. Dieses ist sehr ehrgeizig, weil stark parallelisiert wird. Entsprechend
viel und gründlich wird getestet. Auch bei diesem Modell wird
zu Beginn einer jeden Iteration analysiert, und Sie sehen, dass durch das
versetzte Parallelisieren die Analytiker durchgehend im Einsatz sind.
Damit kommen wir nun zu den modernen agilen Ansätzen (eigentlich fand
ich das alles schon recht agil). Am bekanntesten ist derzeit wohl „Scrum“,
dessen Dachorganisation, die „Scrum Alliance“, leicht im Internet zu finden
ist. Scrum ist allerdings weder ein Vorgehensmodell noch ein Prozess, son-
SSE – Systematische Software-Entwicklung 57

3.4 Anforderungsmanagement / Das A im SADITÜP-Mosaik
dern ein „Rahmenwerk“ (engl. „Framework“), das für die Projektabwicklung
effiziente Methoden bereit hält und viele zentrale Aspekte auf
3 Rollen, 3 Artefakte und 3 Veranstaltungen reduziert.
Aber auch bei Scrum sollte man vorher darüber nachdenken, was man
eigentlich wie erreichen will, also eine Startanalyse durchführen. Wann
und wie will man auch sonst entscheiden, das Projekt überhaupt mithilfe
von Scrum abzuwickeln
Anforderungen werden bei Scrum auch gesammelt und analysiert, und
zwar einerseits am Projektanfang und projektbegleitend (im sog. „Product
Backlog“, quasi dem Produktkatalog) und andererseits am Anfang jeder
Iteration (Iterationen heißen bei Scrum „Sprints“ und die Anforderungslisten
der Iterationen demzufolge „Sprint Backlogs“, quasi Sprint-Katalog).
Damit unterscheiden sich Scrum-Projekte hinsichtlich der Teilprozessanordnung
im Vorgehensmodell nicht von meinem zweiten und dritten linearen
SADITÜP-Mosaik oben, also dem iterativen Wasserfall. Das mag manchen
Scrum-Jüngern nicht gefallen, weil die hier sicherlich was besonders
tolles für Scrum erwartet haben, ist aber nun mal so.
Deshalb brauche ich hier für Scrum erst gar nicht extra noch Diagramme zu
malen. Die Methoden, die bei Scrum in den Teilprozessen der Iterationen
- pardon: „Sprints“ - benutzt werden, sind übrigens effizienter als bisher
üblich, und verlangen deshalb extreme Diszipliniertheit von den
Teammitgliedern – nicht gerade jedermanns Sache!
58 SSE – Systematische Software-Entwicklung

4.2 Anforderungssammlung / Arten von Anforderungen
Manche Leute halten so was für eine Anforderung:
Terminliche Fertigstellungen der Förderanlagen
Und Was heißt das Als Anforderung an eine Software weiß das auch nur
der, der es geschrieben hat. Und selbst der weiß es wahrscheinlich morgen
auch schon nicht mehr.
Eine Übersicht über die terminlichen Fertigstellungen der Förderanlagen
soll abrufbar sein.
Besser! Jetzt wäre es noch spannend, zu wissen, wer das eigentlich will und
wozu das gut sein soll:
Für mich als Regionalleiter soll jederzeit eine Übersicht über die
terminlichen Fertigstellungen aller Förderanlagen meiner Region abrufbar
sein, um bei Verzögerungen der Bauprojekte sofort Gegenmaßnahmen
einleiten zu können.
Testen wir doch diese Anforderung mal gemäß den obigen Erläuterungen
und der zugehörigen orangefarbenen Checkbox – ja, so früh kann schon
Software getestet werden!
„Wer“ – der/die Regionalleiter (Rolle)
„Was“ – eine Übersicht über die terminlichen Fertigstellungen der Förderanlagen
der Region abrufen – ob da Kohle oder Öl gefördert wird, ist offensichtlich
egal
„Wie“ – ist nicht drin und das ist genau richtig so
„Wann“ – jederzeit, also nicht nur am Jahresende
„Warum“ – um bei Verzögerungen der Bauprojekte sofort Gegenmaßnahmen
einleiten zu können; welche Gegenmaßnahmen das sind, ist egal, wenn sieaußerhalb
des Systems sind – das sollte nochmal geklärt werden
„EAI“ – könnte eine Wiederverwendung der Förderanlagen aus einer Bauplanung
sein - das muss wohl noch mal genauer betrachtet werden
„Wichtigkeit“ (s. Kapitel Definitionen) – es „soll“ möglich sein
„Akzeptanz“ - „jederzeit“ ist ganz schön konkret und fragt nach den nichtfunktionalen
Anforderungen der Verfügbarkeit und Robustheit, „eine Übersicht“
ist eindeutig genug, „über die Fertigstellungen … der Region“ ist hier
präzise genug, „aller Förderanlagen“ sind wohl wirklich alle
Also ich meine, diese Anforderung ist so schon recht brauchbar!
66 SSE – Systematische Software-Entwicklung

Anforderungssammlung / Arten von Anforderungen 4.2
Schauen wir uns mal eine andere Anforderung an:
Als Handelsvertreter muss ich die Fragen und Antworten meiner finanztechnischen
Beratung nachhaltig festhalten können, um den europäischen
Dokumentationspflichten nachzukommen.
Testen wir wieder:
„Wer“ – der/die Handelsvertreter (Rolle)
„Was“ – die Fragen und Antworten meiner finanztechnischen Beratung nachhaltig
festhalten
„Wie“ – ist implementierungstechnisch nicht drin und das ist genau richtig so;
fachlich inhaltlich haben wir aber einen Verweis auf die europäischen Dokumentationspflichten;
da steht bestimmt drin, was man alles beachten
muss
„Wann“ – direkt während der Beratung, oder Lieber noch mal nachfragen!
„Warum“ – um den europäischen Dokumentationspflichten nachzukommen
„EAI“ – ist hier nicht erwähnt, also wohl eher kein Aspekt
„Wichtigkeit“ (s. Kapitel Definitionen) – er „muss“, weil es wohl ein europäisches
Gesetz ist
„Akzeptanz“ – „die Fragen und Antworten meiner finanztechnischen Beratung“
werden im Nachgang hoffentlich noch genauer als Teilanforderungen
genannt oder später noch genauer spezifiziert, „nachhaltig“ ist hier endlos,
„festhalten“ wird hoffentlich durch technische Anforderungen zur Speicherung
unterstützt
Testen Sie doch selbst mal die folgenden Anforderungen, und testen Sie
dann mal Ihre eigenen bzw. die Ihnen vorliegenden Anforderungen.
Für mich als Leiter der Finanzabteilung soll die Entwicklung der
Budgetanmeldungen verfolgbar sein, um in dieser Phase jederzeit qualifizierte
Aussagen zum Management geben zu können.
Als Controller möchte ich, dass zu den wichtigsten 80% unserer
Bauprojekte eine unterjährige Jahresendprognose durch die Projektleiter
erfolgt, damit ich an zentraler Stelle stets eine zuverlässige Aussage
erhalte.
SSE – Systematische Software-Entwicklung 67

4.2 Anforderungssammlung / Arten von Anforderungen
Als oberster Architekt fordere ich, dass das HOAI-Phasenschema des
Leistungsbildes „Bautechnik“ in den Phasen 3 bis 8 gemäß der Verordnung
für Architekten unterstützt werden muss.
Als Qualitätsverantwortlicher unserer Lieferkette benötige ich eine
vollständige qualifizierte Übersicht über die durchgeführten Eingangsprüfungen
an den zugelieferten Bauteilen unserer Unterlieferanten.
Für mich als Hydrologe sollen die Bemessungshochwasserspiegellagen der
Zuflüsse unserer Talsperren über die Kilometrierungen bereitgestellt
werden, damit ich sie als Grundlage für die jährliche Berechnung der
Überströmungsgefahr der Mauern verwenden kann.
Sie haben spätestens jetzt an den Beispielen gemerkt, dass funktionale
Anforderungen tatsächlich meistens auf die Funktionen des neuen softwaretechnischen
Systems abzielen, also auf die „Fähigkeiten“. Aber
manchmal ist es auch eher die „Beschaffenheit“ im Sinne eines Vermögens,
mit dem sich dann was anstellen lässt. Die letzte der obigen Anforderungen
beschreibt beispielsweise viel eher, wie das System beschaffen sein
muss, damit es die „Grundlage“ für eine Funktionalität bietet; Ist Ihnen
aufgefallen, dass hier gar nicht gefordert wird, dass die eigentliche Funktionalität
der „Berechnung“ Teil des Systems sein soll Die Grundlage kann
später technisch auch das Datenschema einer Datenbank sein, aus dem
sich eine externe Berechnung bedient, die es schon lange gibt.
So oder so spiegeln die funktionalen Anforderungen die Fachlichkeit des
Kunden wieder, und zwar eben aus Kundensicht, nicht aus softwaretechnischer
Implementierungssicht.
Sie werden aber auch gesehen haben, dass diverse Attribute dieser Anforderungen
durchaus noch mit Teilanforderungen untersucht werden müssen.
Stellen Sie also als Analytiker die passenden Fragen: „Was meinen Sie
mit ‚jederzeit‘“, „Was ist für Sie eine ‚vollständige qualifizierte‘ Übersicht“,
„Woran erkenne ich die ‚wichtigsten 80%‘ der Bauprojekte“, „Was
ist bei Ihnen eine ‚unterjährige Jahresendprognose‘“, etc.
Wenn Sie die Teilanforderungen formulieren und dabei einen formalen
Bezug zu einer Hauptanforderung herstellen, ist es meines Erachtens nicht
68 SSE – Systematische Software-Entwicklung

Anforderungssammlung / Arten von Anforderungen 4.2
mehr nötig, zu beschreiben, wer das fordert; oft können Sie auch die Begründung
weglassen. Tun Sie nur das, was hilft, und handeln Sie situativ!
Die Übersicht der durchgeführten Eingangsprüfungen soll wöchentlich
erstellbar sein und zu allen Bauteilen der zugehörigen Woche die
Prüfkriterien unserer Klasse A zeigen.
Die wichtigsten 80% der Bauprojekte sollen jeweils am Jahresanfang auf
Basis einer Kostenkalkulation mit dem System festgelegt werden können.
Die unterjährigen Jahresendprognosen sollen an jedem 3. eines Monats
die zugehörige Prognose des Ausgabenstands zum Jahresende aufzeigen.
4.2.2 Nicht-funktionale Anforderungen
Als Auftraggeber werden Sie nicht nur fachliche funktionale Anforderungen
an das neue softwaretechnische System haben. Wenn Sie eine neue Software
entwickeln lassen, die Sie genauso in Ihrer Forschungsabteilung in
Deutschland einsetzen wollen wie in Ihrer Produktionsstätte in Rumänien,
dann werden Sie vielleicht wollen, dass Ihre neue Software zumindest die
Texte auf dem Bildschirm in zwei Sprachen darstellen kann. Gehört die
„Mehrsprachigkeit“ zu Ihrer Fachlichkeit, für die Sie die neue Software
entwickeln lassen Oder sehen Sie in der Mehrsprachigkeit eine ganz bestimmte
Funktion Ihrer neuen Software Das passt nicht so ganz. Das liegt
auch daran, dass die Mehrsprachigkeit eine Art Querschnittthema ist, also
eine Eigenschaft, die wahrscheinlich die meisten Funktionen Ihrer neuen
Software irgendwie beeinflussen wird und über die Begrifflichkeiten auch
Ihre Fachlichkeit an vielen Stellen betreffen wird.
Ähnlich wird es Ihnen gehen, wenn Sie eine kaufmännische Software entwickeln
lassen und mehrere „Währungen“ unterstützt haben müssen.
Oder verschiedene „Metriken“ wie Zentimeter, Zoll oder Seemeilen (und
verschiedene Tausender- und Dezimaltrenner).
Aber auch bei der „Bedienbarkeit“ kann es Querschnittthemen geben,
wenn Sie auf Menschen mit Behinderungen Rücksicht nehmen möchten.
SSE – Systematische Software-Entwicklung 69

5.3 Anforderungsanalyse / Anforderungsattribute
Wind, drehen sich mit jedem, mit dem man spricht und können einfach
nicht abschließend formuliert werden („hoch“, „lose“, „3“). Andere Anforderungen
konnten noch nicht endgültig entschieden werden, weil sie noch
von verschiedenen Leuten diskutiert werden, aber eine Einigung ist absehbar
(„mittel“, „wackelig“, „2“). Wieder andere gab es von Anfang an so, wie
sie sind, und da waren sich auch alle einig und da ändert sich offensichtlich
auch nichts mehr dran („niedrig“, „fest“, „1“).
Bewertung
Priorität
Variabilität
Komplexität
Risiko
Die „Komplexität“ (z.B. „hoch“, „mittel“, „niedrig“ oder
„komplex“, „erklärbar“, „easy“ oder „3“, „2“, „1“) sagt
auch eine Menge über den Detaillierungsgrad der zugehörigen
Geschäftsprozesse und damit über den Implementierungsaufwand
aus. Sie zeigt oft auch den
Anteil von Algorithmen. Auf jeden Fall ist sie als Input
für Aufwandsschätzungen wichtig, weil komplexe Anforderungen
zur realistischen Schätzung ggf. erst noch in Teilanforderungen
zerlegt werden müssen. Vielleicht finden Sie eine Situation vor, die
keiner wirklich richtig verständlich erklären kann, bei denen immer wieder
vermeintlich in Details abgestiegen wird und wo immer wieder neue Leute
zur Klärung gebraucht werden („hoch“, „komplex“, „3“). Andere sind
durchaus Standard, aber haben dennoch ihre Tücken und müssen vorsichtshalber
nochmal genauer abgeklärt werden („mittel“, „erklärbar“,
„2“). Und dann gibt es noch die, über die gar nicht weiter gesprochen wird,
weil sie eigentlich eh jedem klar sind („niedrig“, „easy“, „1“).
Ein „Risiko“ ist etwas, was später zum Problem werden kann. Was heute
schon ein Problem ist, muss heute erledigt werden und birgt höchstens ein
Risiko, solange es nicht erledigt ist. Wie groß aber das Problem hinter dem
Risiko später werden kann, ist aus den drei oben erklärten Attributen direkt
ableitbar: Eine hoch variable und komplexe Anforderung mit hoher
Priorität stellt ein viel höheres Risiko für das Projekt dar als eine stabile
einfache Anforderung niedriger Priorität. Logisch, oder Aber wie steht es
mit einer hoch komplexen Anforderung, die andererseits absolut fest ist
und als „soll“ eingestuft ist
Meiner Erfahrung nach kann eine Gewichtung der Attribute P, V und K
vorgenommen werden: Die Komplexität ist dabei am kritischsten, weil sie
eine Schätzung um Faktoren verreißen kann, und bereits eine einzelne
komplexe unterschätzte Anforderung das ganze Projekt gefährden kann.
Die Variabilität kommt als nächste, denn wenn Anforderungen nicht fixiert
werden können, dann kann auch das Projekt nicht abgeschlossen werden.
Die Priorität kommt tatsächlich als letztes und ist am wenigsten bedroh-
102 SSE – Systematische Software-Entwicklung

Anforderungsanalyse / Anforderungsattribute 5.3
lich, weil sie letztendlich „nur“ eine Reihenfolge bestimmt. Das ist anders,
als die meisten Menschen erwarten, und deshalb sind verschieden gewichtete
Attribute oft nur schwierig objektiv beurteilbar. Daher habe ich aus
den oben dargestellten Attributen eine Formel ermittelt, mit der das Risiko
berechnet werden kann:
R = 1 x P (1 bis 3) + 3 x V (1 bis 3) + 9 x K (1 bis 3) - (1+3+9) +1
Dabei bewerten Sie Priorität, Variabilität
und Komplexität so mit 1 bis 3, wie Sie es
oben schon kennengelernt haben. Die
Priorität wird dann einfach gewichtet, die
Variabilität dreifach und die Komplexität
neunfach. Schließlich muss ich noch –
gemäß dieser Gewichtung - 13 abziehen
(= 1+3+9). Dann zählt das Risiko allerdings
ab Null, weshalb ich noch eins addiere,
damit es ab 1 für das geringste
Risiko läuft und bis 27 für das höchste
Risiko durchläuft.
Statt der Bewertung 1, 2 und 3 können
Sie auch mit Pfeilen tief, mittel und hoch
für eine entsprechende Bewertung arbeiten.
Diese Pfeile können Sie zusätzlich
noch gemäß einer Ampel grün, gelb und
rot einfärben.
Grün, grün und grün ergibt dann grün
und ist unproblematisch; Rot, rot und rot
ergibt dann rot und ist geradezu explosiv.
Zunächst können Sie jetzt erkennen, wo
noch Klärungsbedarf besteht und andererseits
festlegen, was zuerst angegangen
werden sollte - nämlich immer das
höchste Risiko!
Zerlegen Sie also Anforderungen hoher
Komplexität in Teilanforderungen, um die
Komplexität besser bewerten zu können.
SSE – Systematische Software-Entwicklung 103

… Ich beschäftige mich als Berater intensiv mit Fragestellungen aus dem
Bereich IT-Architektur und -Management. Kompliment für die von Ihnen
geleistete Arbeit und den Ergebnissen auf Ihrer Web-Site. Selten findet man
dieses Thema so "aufgeräumt" und lesenswert. ...
Manager / Prokurist
affinis consulting GmbH
… Ihre Zusammenstellung der Themen in Sachen Softwareentwicklung
finde ich hervorragend und werde sie künftig in Besprechungen und Meetings
nutzen. …
Knorr Bremse AG
… Viele Dank für diese tolle Artike!!!. Ich finde sie eine der besten, die ich in
diesem Bereich gelesen habe. Ich finde die Sprüche auch extrem cool! …
Quang Tran Minh
Vietnam
... I was so impressed with your skilled & disciplined project management
approach that I felt, and still feel, that if I get into any conversations with
large firms concerning a substantial migration project then I would have to
consider getting you involved with us. ...
OpenOffice.org
New York
Ziele werden erreicht, wenn Anforderungen erfüllt
werden. Anforderungen stellen also die wesentliche
Vereinbarung zwischen Auftraggeber und Auftragnehmer
dar. Die Sammlung und Analyse von messbar
formulierten Anforderungen bilden die Grundlage zur
Vermeidung der frühen teuren Fehler. So werden die
Verfolgung der Anforderungen und die Abnahme auf
Basis der Anforderungen abgesichert. Bewerten Sie
dafür Anforderungen mindestens in ihrer Priorität,
Variabilität und Komplexität, um daraus nach einer
einfachen Formel deren Risiko zu berechnen.
Ralf Bürger (http://www.RalfBuerger.de)