Requirements Engineering und Management by SOPHIST GmbH

Einleitung

Liebe Leserin, lieber Leser Es ist vollbracht. Nach langen Abenden und Wochenenden voll ergiebiger Diskussionen und hektischer Betriebsamkeit können wir nun mit Stolz sagen: Willkommen zur neuen Auflage unseres Standardwerkes zum Thema Requirements-Engineering und Requirements-Management.

Unser Ziel war es, Ihnen mit diesem Buch eine pragmatische Anleitung für die fundierte, erfolgreiche Arbeit mit Anforderungen zu geben. Bevor wir jedoch in die Materie einsteigen, wollen wir Ihnen auf den nächsten Seiten die Lektüre schmackhaft machen.

Die Stationen in diesem Buch Wie in den vorigen Auflagen auch haben wir unser Buch in verschiedene Abschnitte eingeteilt, die die Inhalte des Requirements-Engineerings logisch zusammenfassen.

Teil I: Requirements–Engineering zum Erfolg bringen Wieso wird Requirements-Engineering überhaupt betrieben? Ist das sinnvoll? Lohnt sich das? Die Antwort auf diese und ähnliche Fragen finden Sie im ersten Abschnitt. Da die reine Theorie ein sehr trockenes Gebäck ist, haben wir das Buch mit einem durchgängigen Beispiel durchsetzt – dies werden wir hier vorstellen. Danach folgt eine kurze Übersicht der Prozesslandschaft, in deren Rahmen sich Requirements-Engineering zumeist abspielt.

Teil II: Anforderungen ermitteln Anforderungen fallen (leider) nicht vom Himmel. Sie müssen in harter Arbeit aus einer Vielzahl von Quellen zusammengetragen werden. In diesem Abschnitt stellen wir Ihnen diese Quellen vor, zeigen Probleme auf, die bei der Ermittlung auftreten, und legen dar, wie Anforderungen auf Herz und Nieren geprüft werden können.

Teil III: Anforderungen formulieren Sind alle Anforderungen erst einmal bekannt, müssen sie schriftlich niedergelegt werden. Wir stellen unser bewährtes Template für natürlichsprachliche Anforderungen vor, erläutern die brauchbarsten Dokumentationstechniken und behandeln jene Anforderungen, die allzu gerne übersehen werden: die nicht-funktionalen.

Einleitung Teil IV: Anforderungen validieren Qualitätssicherung – für manche Leid, für manche Freud. Auch Anforderungen sind keine Ausnahme und müssen einer Prüfung unterzogen werden, daher zeigen wir Ihnen in diesem Abschnitt die wichtigsten Prüftechniken für Anforderungen. Und wenn die Qualität erst einmal gesichert ist, wie überzeugen Sie Ihr Management davon? Richtig: durch Metriken. Wir stellen Ihnen eine Auswahl von praxistauglichen Metriken vor und erörtern ihre Anwendung.

Teil V: Anforderungen verwalten Sind die Anforderungen ermittelt, dokumentiert und validiert, dann kann man das Anforderungsdokument getrost in eine Schublade packen und zum nächsten TOP übergehen, richtig? Natürlich falsch, Anforderungen sind nicht in Stein gehauen, sondern ändern sich mit der Zeit ganz erheblich und müssen verwaltet werden – eine ganz und gar nicht triviale Aufgabe. Hier finden Sie eine Anleitung, wie Anforderungsmanagement sinnvoll gestaltet wird, welche Zustände Anforderungen während ihrer Lebensdauer durchlaufen, wie Anforderungen freigegeben werden und wie sie, nach Gebrauch, am besten wiederverwendet werden.

Teil VI: Verträge, Konflikte und Einführungsprojekte managen Um erfolgreiches Requirements-Engineering zu betreiben, reicht es nicht, gute Anforderungen zu sammeln und zu verwalten: Es gilt auch, Verträge und Konflikte zu meistern. Wie das gemacht wird, beschreibt Abschnitt 6. Fast am Ende des Buches angelangt, stellt sich noch die Frage, wie Sie Ihr gesammeltes Wissen über Requirements-Engineering „unters Volk“ bringen. Deshalb haben wir das letzte Kapitel den Einführungsstrategien gewidmet.

Die SOPHISTen: Alt und Neu Die Sophisten, eine Gruppe von Philosophen, lebten in der Zeit um 450 vor Christus in Athen. Sie galten als die Ersten, die auf die von den Vorsokratikern propagierte Naturphilosophie eine menschenbezogene Antwort gaben. Protagoras (481– 411) postulierte: „Der Mensch ist das Maß aller Dinge“. Der Mensch erzeugt ein neues Weltverständnis und ermöglicht so einen neuen Umgang mit seiner Umgebung. Sie gaben auch die entscheidenden Impulse für die Entwicklung vom Mythos zum Logos, das heißt zur Idee eines durch theoretische Vernunft begründeten Weltverständnisses. Als SOPHISTen der Neuzeit bezeichnen sich die Mitarbeiter der SOPHIST GmbH, der Gesellschaft für innovatives Software-Engineering. Die Ideen und die Werte der alten SOPHISTen haben wir aufgegriffen und sehen es als Teil unserer Mission, unsere Kunden dazu zu bringen, das Althergebrachte in Frage zu stellen. Seit Jahren begleiten die SOPHISTen namhafte Kunden in unterschiedlichsten Projekten mit Coaching, Training und Auditierung. Dadurch entstand ein umfassender Wissenspool in den Bereichen Requirements-Engineering und -Management und Architektur.

Einleitung Neue Inhalte in neuem Gewand Dass wir uns mit unseren Werten nach den SOPHISTen des Altertums richten, bedeutet nicht, dass wir alte fachliche Inhalte vermitteln. Seit der letzten Auflage sind wieder zwei ereignisreiche Jahre vergangen, in denen wir viel gelernt haben. Diese neue Auflage bietet uns die Möglichkeit, unseren Kunden und Freunden das neue und alte Wissen zu vermitteln und Ihnen so die Chancen und Inhalte eines guten Requirements-Engineering und -Managements darzulegen. Wie Sie bestimmt bereits erkannt haben, haben wir in diese Auflage nicht nur inhaltliche Änderungen einfließen lassen. Wir haben auch die graphische Gestaltung überarbeitet. Wir hoffen, damit den teils trockenen Inhalt in eine kurzweilige Form gebracht zu haben. Und wir hoffen, dass Ihnen dieses Layout genauso gut gefällt wie uns.

Neudeutsch: gepimpt

Das Team Auf den nächsten beiden Seiten werden Sie die Personen kennenlernen, die an der Erstellung dieses Buches beteiligt waren. Bei so vielen Personen haben wir auf eine detaillierte Vorstellung der einzelnen Autoren verzichtet. Sie finden diese jedoch auf unserer Homepage. Was halten Sie von dem, was wir hier geschrieben haben? Das gesamte Team freut sich auf Ihre Eindrücke und Verbesserungsvorschläge, Ihre Kritik, aber auch Ihr Lob. Treten Sie mit uns in Kontakt.

www.sophist.de

buch@sophist.de „Die Grenzen meiner Sprache sind die Grenzen meiner Welt“ L. Wittgenstein (1889 -1951)

Das Team

Christian Pikalek

Hajo Hoffmann Ellen Wolf

Dr. Stefan Queins Anja Ranft

Die Autoren

Rainer Joppich Matthias Strößner

Dirk Schüpferling

Andreas Günther Thorsten Cziharz

Das Team

Elke Bischof Karin Polach

Dr. Oliver Creighton

Fachliches Sven Biedermann Review

Karol Frühauf Dr. Peter Hruschka

Emmerich Fuchs

Dr. Matthias Recknagel Suzanne Robertson Dr. Helmut Sandmayr

Margarete Metzger

Volker Schmidt

Verlag

Erik Simmons

Irene Weilhart

Dr. Stefan Walburg Dr. Walter Wintersteiger

Externes Team

Michaela Witzel

Design

Heike Baumgä

Experten

Dr. Stefan Queins

Alex Marta Steiner Bednarczyk Andreas Günther

Projekt– Projekt– Management Organisation

Zentrales Review Chris Rupp Internes Team

Christian Schmidt Johannes Happe Marta Bednarczyk

Ghostwriter

Patrick Arnold

Claudia Benjamin Kellermann- Franta Lindskog

Mario Klinger

Layout Stefanie Spitzer

Roland Hübner

Illustration

Chris Rupp

Fotos Thorsten Cziharz

Sven Biedermann

Inhaltsverzeichnis

Inhaltsverzeichnis Einleitung......................................................................................................................1 Die Stationen in diesem Buch.................................................................................... 1 Die SOPHISTen: Alt und Neu................................................................................... 2 Neue Inhalte in neuem Gewand................................................................................. 3 Das Team................................................................................................................... 3

Teil I — Requirements–Engineering zum Erfolg bringen............7 1

In medias RE..........................................................................................................9 1.1 Motivation für eine erfolgreiche Systemanalyse.................................................. 10 1.2 Der Requirements-Engineer – Mittler zwischen den Welten............................. 11 1.3 Das Requirementsgehirn................................................................................... 11 1.4 Die Disziplin Requirements-Engineering.......................................................... 12 1.4.1 Zweck einer Anforderung....................................................................... 16 1.5 Die Einteilung von Anforderungen................................................................... 17 1.5.1 Einteilung von Anforderungen nach ihrer Art........................................ 17 1.5.2 Einteilung von Anforderungen nach ihrer rechtlichen Verbindlichkeit 18 1.6 Requirements-Management – der Dompteur im Dokumentenzirkus?.............. 20 1.7 Typische Probleme in der Anforderungsanalyse................................................. 21 1.8 Qualitätskriterien im Requirements-Engineering............................................... 23 1.8.1 Qualitätskriterien für jede einzelne Anforderung.................................... 23 1.8.2 Qualitätskriterien für die Anforderungsspezifikation.............................. 26 1.9 Ausreichend motiviert für ein exzellentes Requirements-Engineering?............... 29

Das Bibliothekssystem – Das durchgehende Beispiel im Überblick.....................31

Von der Idee zur Spezifikation.............................................................................33 3.1 Das Need-to-Know-Prinzip............................................................................... 34 3.1.1 Vom richtigen Augenblick...................................................................... 34 3.1.2 Das akkumulierte Wissen....................................................................... 35 3.1.3 Eine Anforderung ist wie ein Chamäleon............................................... 35 3.2 Vorgehensmodelle und Standards...................................................................... 36 3.3 Die richtigen Anforderungen zum richtigen Zeitpunkt..................................... 40 3.3.1 Der Zusammenhang zwischen Anforderungen....................................... 41 3.3.2 Die Einordnung der Systemanalyse........................................................ 46 3.3.3 Die Durchführung der Systemanalyse.................................................... 48 3.3.4 Das Vorgehen in der Projektpraxis......................................................... 50 3.4 Die optimale Systemanalyse............................................................................... 54 3.5 Am Anfang war das Vorgehen ........................................................................... 55

V VI

Inhaltsverzeichnis Teil II — Anforderungen ermitteln..........................................57 4

Ziele, Informanten und Fesseln............................................................................59 4.1 Die wichtigsten Schritte vor dem Start in die Systemanalyse.............................. 60 4.1.1 Anforderungsquellen: Ausgangspunkt und Mittelpunkt......................... 62 4.1.2 Die derzeitige Realität unter die Lupe nehmen....................................... 63 4.1.3 Probleme erkunden und Optimierungspotenziale beschreiben............... 63 4.1.4 Ziele definieren und bewerten................................................................ 63 4.2 Der Stakeholder – das unbekannte Wesen......................................................... 64 4.2.1 Die Notation von Stakeholdern.............................................................. 67 4.2.2 Stakeholder-Relationship-Management – Die Pflege von Stakeholdern 69 4.3 Ziele beschreiben .............................................................................................. 70 4.4 Umfang, Kontext und Grenzen des Systems festlegen ....................................... 72 4.4.1 Der Systemkontext ................................................................................ 72 4.4.2 System- und Kontextgrenzen bestimmen .............................................. 74 4.5 Alles bereit für den Start in eine erfolgreiche Systemanalyse?............................. 77

Anforderungsermittlung – Hellsehen für Fortgeschrittene ..................................79 5.1 Ran an die Kundenwünsche ............................................................................. 80 5.1.1 Aller Anfang ist schwer........................................................................... 80 5.1.2 Die Qual der Wahl ................................................................................ 81 5.2 Die entscheidenden Produktfaktoren ................................................................ 81 5.2.1 Basisfaktoren ausgraben ........................................................................ 82 5.2.2 Leistungsfaktoren abholen ..................................................................... 83 5.2.3 Begeisterungsfaktoren erarbeiten ........................................................... 84 5.3 Ermittlungstechniken ....................................................................................... 85 5.3.1 Kreativitätstechniken ............................................................................. 86 5.3.2 Beobachtungstechniken ........................................................................ 93 5.3.3 Befragungstechniken ............................................................................. 95 5.3.4 Artefaktbasierte Techniken .................................................................... 99 5.3.5 Unterstützende Techniken ................................................................... 102 5.4 Anwendung in der Praxis ................................................................................ 110 5.5 Techniken erfolgreicher Hellseher ................................................................... 112 5.6 Anleitung zum Hellsehen ............................................................................... 114

Das SOPHIST-REgelwerk – Psychotherapie für Anforderungen .......................115 6.1 Vom Phänomen der Transformation – Sprachliche Effekte ............................. 116 6.2 Die Wurzeln – Das Neurolinguistische Programmieren .................................. 116 6.2.1 Transformationsprozesse ...................................................................... 117 6.2.2 Kategorien der Darstellungstransformation ......................................... 120 6.3 Vom Umgang mit sprachlichen Effekten ........................................................ 123 6.4 Das Vorgehen beim SOPHIST-REgelwerk – Anforderungen auf die Couch gelegt .............................................................. 125 6.5 Prüfen der Satzbestandteile ............................................................................. 128 6.5.1 Prüfen der Prozesse ............................................................................. 128 6.5.2 Prüfen von Eigenschaften .................................................................... 136 6.5.3 Prüfen von Mengen und Häufigkeiten ................................................ 140 6.5.4 Prüfen von Begriffen, die Möglichkeiten beschreiben .......................... 144 6.6 Prüfen des Satzes............................................................................................. 146

Inhaltsverzeichnis 6.7 Prüfen des Gesamtbildes ................................................................................. 148 6.8 Anwendung des SOPHIST-REgelwerks .......................................................... 153 6.9 Ene, mene, muh – und defektbereinigt bist du!............................................... 156

Teil III — Anforderungen formulieren ..................................157 7

Schablonen – Baupläne für Anforderungen und mehr ......................................159 7.1 Linguistische und philosophische Grundlagen ................................................ 160 7.2 Der schablonenbasierte Ansatz ....................................................................... 161 7.3 Schritt für Schritt zur Anforderung ................................................................ 162 7.4 Semantische Präzisierung der Anforderungsschablone .................................... 168 7.4.1 Rechtliche Verbindlichkeiten ............................................................... 168 7.4.2 Verben – Prozesswörter ....................................................................... 169 7.4.3 Substantive – Akteure, Rollen, Objekte und Eigenschaften ................. 171 7.4.4 Bedingungen – Logische Operatoren .................................................. 173 7.4.5 Abkürzungen ...................................................................................... 176 7.5 Konstruieren in englischer Sprache ................................................................. 177 7.5.1 Der Syntaxbauplan im Englischen ....................................................... 177 7.5.2 Semantische Normierung im Englischen ............................................. 177 7.6 Erfahrungen aus der Praxis ............................................................................. 179 7.7 Auf die Sätze, fertig, los! ................................................................................. 181

Dokumentation von Anforderungen – gut dokumentiert ist halb gebaut..........183 8.1 Dokumentation? Ja bitte! ................................................................................ 184 8.1.1 Navigationshinweise für dieses Kapitel ................................................ 184 8.1.2 Weitere Dokumentationstechniken ..................................................... 186 8.1.3 Fallbeispiel „Bibliothek“ ...................................................................... 188 8.2 Geschäftsprozessbeschreibung ......................................................................... 189 8.2.1 Business-Use-Cases ............................................................................. 190 8.2.2 Ablaufdiagramme ................................................................................ 193 8.2.3 Geschäftsregeln ................................................................................... 196 8.2.4 Übergang: Geschäftsprozess – System ................................................. 201 8.3 Ziele und der Systemkontext .......................................................................... 202 8.3.1 Formulierung von Zielen .................................................................... 202 8.3.2 Kontextvisualisierung .......................................................................... 203 8.4 Begriffe und Definitionen ............................................................................... 206 8.4.1 Das Glossar ........................................................................................... 206 8.4.2 Das Klassendiagramm als Begriffsmodell ............................................... 207 8.5 Grobe Anwenderforderungen ......................................................................... 209 8.5.1 Prosaanforderungen ............................................................................ 209 8.5.2 Das System-Szenario ........................................................................... 210 8.5.3 Das System-Use-Case-Diagramm ........................................................ 211 8.5.4 Die Use-Case-Beschreibung ................................................................ 214 8.5.5 Das Aktivitätsdiagramm ...................................................................... 217 8.5.6 Sequenzdiagramm ............................................................................... 220 8.5.7 Zustandsautomat................................................................................. 222 8.5.8 Systemregeln ....................................................................................... 224 8.5.9 Testfälle als Spezifikation...................................................................... 227

VII VIII

Inhaltsverzeichnis 8.6 Anwenderforderungen verfeinern ................................................................... 232 8.6.1 Detaillierung von Diagrammen ........................................................... 232 8.6.2 Tipps zum Thema Verfeinerung .......................................................... 234 8.7 Diagramm – Sprache – Diagramm ................................................................. 235 8.7.1 Randbedingungen, Nutzen und Ziele ................................................. 235 8.7.2 Diagramme transformieren ................................................................. 236 8.8 Die Wahl der richtigen Dokumentationstechniken ......................................... 239 8.8.1 Einflussfaktoren auf die Wahl der Dokumentationstechniken............. 240 8.8.2 Auswahlempfehlungen ........................................................................ 240 8.8.3 Diagramm oder doch lieber natürliche Sprache? .................................. 242 8.9 Wer schreibt der bleibt ................................................................................... 245 9

Nicht-funktionale Anforderungen – Funktionen sind nicht alles ......................247 9.1 Denken Sie an die Beilagen ............................................................................ 248 9.1.1 Was sind nicht-funktionale Anforderungen? ........................................ 248 9.1.2 Chancen durch nicht-funktionale Anforderungen ............................... 250 9.2 Technologische Anforderungen ...................................................................... 255 9.2.1 Was wird beschrieben? ........................................................................ 256 9.2.2 Wie werden technologische Anforderungen ermittelt? ......................... 258 9.2.3 Wie werden technologische Anforderungen dokumentiert? ................. 259 9.3 Qualitätsanforderungen .................................................................................. 260 9.3.1 Was wird in Qualitätsanforderungen beschrieben? .............................. 261 9.3.2 Wie werden Qualitätsanforderungen ermittelt? ................................... 265 9.3.3 Wie werden Qualitätsanforderungen dokumentiert? ........................... 265 9.4 Anforderungen an die Benutzungsoberfläche .................................................. 267 9.4.1 Was wird mittels Anforderungen an die Benutzungsoberfläche beschrieben?......................................................................................... 268 9.4.2 Wie werden Anforderungen an die Benutzungsoberfläche ermittelt? ............................................................................................. 270 9.4.3 Wie werden Anforderungen an die Benutzungsoberfläche dokumentiert? ..................................................................................... 271 9.5 Anforderungen an sonstige Lieferbestandteile ................................................. 275 9.5.1 Was wird mittels Anforderungen an sonstige Lieferbestandteile beschrieben?......................................................................................... 275 9.5.2 Wie werden Anforderungen an sonstige Lieferbestandteile ermittelt? ............................................................................................. 277 9.5.3 Wie werden Anforderungen an sonstige Lieferbestandteile dokumentiert? ..................................................................................... 277 9.6 Anforderungen an durchzuführende Tätigkeiten ............................................ 277 9.6.1 Was wird mittels Anforderungen an durchzuführende Tätigkeiten beschrieben?...................................................................... 278 9.6.2 Wie werden Anforderungen an durchzuführende Tätigkeiten ermittelt? .......................................................................... 279 9.6.3 Wie werden Anforderungen an durchzuführende Tätigkeiten dokumentiert? .................................................................. 279 9.7 Rechtlich-vertragliche Anforderungen ............................................................ 280 9.7.1 Was wird mittels rechtlich-vertraglicher Anforderungen beschrieben?......................................................................................... 280 9.7.2 Wie werden rechtlich-vertragliche Anforderungen ermittelt? ............... 283

Inhaltsverzeichnis 9.7.3 Wie werden rechtlich-vertragliche Anforderungen dokumentiert? ....... 283 9.8 Fertig für die Nicht-Funkionen? ..................................................................... 284

Teil IV — Anforderungen validieren .....................................285 10 Prüftechniken für Anforderungen – Ungeahntes Verbesserungspotenzial .........287 10.1 Qualität ist das, was der Kunde braucht ....................................................... 288 10.1.1 Ziele in der Qualitätssicherung von Anforderungen ........................ 288 10.1.2 Von Mängeln und Fehlern in Anforderungen ................................. 289 10.1.3 Konstruktive und analytische Qualitätssicherung von Anforderungen ........................................................................ 290 10.2 Vorgehen beim Prüfen von Anforderungen .................................................. 291 10.2.1 Qualitätsziele festlegen .................................................................... 292 10.2.2 Prüfzeitpunkte bestimmen............................................................... 292 10.2.3 Prüfung durchführen ...................................................................... 293 10.2.4 Qualität verbessern ......................................................................... 293 10.3 Die Prüftechniken im Detail ........................................................................ 293 10.3.1 Reviews........................................................................................... 293 10.3.2 Prototyp/Simulationsmodell .......................................................... 298 10.3.3 Testfälle........................................................................................... 298 10.3.4 Analysemodell ................................................................................ 304 10.3.5 Hilfsmittel bei der Prüfung ............................................................. 306 10.4 Vom Durchblick im Dschungel der Prüftechniken ....................................... 308 10.4.1 Einschätzung der Prüftechniken ..................................................... 308 10.4.2 Über die Auswahl geeigneter Prüftechniken..................................... 309 10.4.3 Über die Auswahl geeigneter Prüfer ................................................ 309 10.5 Das ultimative Rezept für gute Anforderungen ............................................. 312 11 Qualitätsmetriken – Drum messe, wer sich ewig bindet ....................................313 11.1 Qualitätsmetriken – Die Hüter der Anforderungsqualität ............................ 314 11.1.1 Qualitätsmetriken für Anforderungen ............................................. 314 11.1.2 Ziele von Qualitätsmetriken – der Blick ins Unbekannte ................ 315 11.1.3 Die Qualitätsmetriken im Überblick .............................................. 316 11.1.4 Aussagekraft von Qualitätsmetriken – ein schmaler Grat? ............... 317 11.2 Inhaltsbasierte Qualitätsmetriken ................................................................. 318 11.2.1 Die Qualitätsmetrik „Eindeutigkeit“ ............................................... 318 11.2.2 Die Qualitätsmetrik „Klassifizierbarkeit“ ........................................ 321 11.2.3 Die Qualitätsmetrik „Vollständigkeit“ ............................................ 323 11.3 Verwaltungsorientierte Qualitätsmetriken .................................................... 327 11.3.1 Die Qualitätsmetrik „Identifizierbarkeit“ ........................................ 327 11.3.2 Die Qualitätsmetrik „Sortierbarkeit“ .............................................. 329 11.3.3 Die Qualitätsmetrik „Redundanzfreiheit“ ....................................... 331 11.4 Vorgehen beim Messen von Anforderungen Qualitätsmetriken im praktischen Einsatz .................................................... 332 11.4.1 Ziele der Messung festlegen ............................................................ 333 11.4.2 Qualitätsmetriken auswählen .......................................................... 333 11.4.3 Messbedingungen definieren .......................................................... 334 11.4.4 Messende Person(en) auswählen ..................................................... 335

IX X

Inhaltsverzeichnis 11.4.5 Messvorlage erstellen ...................................................................... 336 11.4.6 Messung durchführen ..................................................................... 336 11.4.7 Messergebnisse auswerten ............................................................... 337 11.5 Bereit zur Qualitätsmessung – oder noch risikofreudig?................................. 340

Teil V — Anforderungen verwalten ......................................341 12 Requirements-Management – Die Reise beginnt ...............................................343 12.1 Wider die Unordnung – Requirements-Management ................................... 344 12.1.1 Gründe für professionelles Requirements-Management .................. 345 12.1.2 Anforderungen ändern sich ............................................................ 345 12.1.3 Anforderungen werden weiterverwendet ......................................... 346 12.1.4 Die Schlussfolgerung: Professionelles Requirements-Management muss sein............................................. 346 12.1.5 Wann ist wie viel RM sinnvoll? ....................................................... 348 12.2 Die Aufgaben professionellen Requirements-Managements .......................... 349 12.2.1 Informationsaustausch - Wer gibt wann wem was? ......................... 349 12.2.2 Ablaufsteuerung – Wer darf wann was? ........................................... 350 12.2.3 Verwaltung von Abhängigkeiten – Was hängt wie mit was zusammen? ................................................. 351 12.2.4 Auswertung und Projektsteuerung – Wie läuft‘s? ............................ 351 12.3 Was soll genau verwaltet werden? – Informationsarten ................................. 352 12.4 Gliederungsstrukturen – Das Skelett des Requirements-Management .......... 355 12.4.1 Lücken finden – Sind schon alle da? ............................................... 355 12.4.2 Lücken lassen – Erwarte das Unerwartete ....................................... 356 12.4.3 Standard-Gliederungen – Das Rad nicht neu erfinden .................... 356 12.5 Objekt-IDs – Denn Namen sind Schall und Rauch ..................................... 359 12.5.1 Wann ist eine Objekt-ID wirklich eindeutig? .................................. 360 12.5.2 Wie soll eine Objekt-ID aussehen? ................................................. 361 12.6 Schritt für Schritt ins RM-Paradies ............................................................... 362 13 Versionen und Zustände – Das Leben einer Anforderung .................................363 13.1 Die Anforderung lebt! .................................................................................. 364 13.2 Die Zustände einer Anforderung .................................................................. 365 13.3 Die Zustandsübergänge einer Anforderung .................................................. 369 13.4 Der Zustandsautomat einer Anforderung ..................................................... 370 13.5 Stakeholder des Requirements-Management................................................. 373 13.6 Rollen identifizieren ..................................................................................... 374 13.7 Rechte vergeben ........................................................................................... 375 13.7.1 Tätigkeiten definieren ..................................................................... 375 13.7.2 Zuständigkeiten festlegen ............................................................... 377 13.7.3 Für Sicherheit sorgen ...................................................................... 379 13.8 Den Lebensweg dokumentieren ................................................................... 379 13.8.1 Historie einer Anforderung ............................................................. 379 13.8.2 Versionen einer Anforderung .......................................................... 380 13.9 „Offen“ oder „Abgehakt“? ............................................................................ 384

Inhaltsverzeichnis 14 Strukturen und Mengen – Das Chaos verhindern .............................................385 14.1 Das Chaos verhindern .................................................................................. 386 14.1.1 Attribute – Alles, was man über seine Anforderungen wissen muss .................................................................................... 387 14.1.2 Die Übersicht behalten – Filtern, Sortieren, Sichten bilden ............ 390 14.2 Auswertungen .............................................................................................. 394 14.2.1 Wer möchte was sehen? .................................................................. 395 14.2.2 Die Fortschrittsauswertung ............................................................. 395 14.3 Traceability .................................................................................................. 397 14.3.1 Eltern/Kind-Verbindung ................................................................ 398 14.3.2 Verbindung zwischen Anforderungen auf gleicher Ebene ................ 399 14.3.3 Verbindung zwischen Anforderungen und weiteren Informationsarten.............................................................. 400 14.3.4 Traces technisch realisieren ............................................................. 401 14.4 Anforderungen strukturieren ........................................................................ 404 14.4.1 Strukturierung nicht-funktionaler Anforderungen .......................... 406 14.4.2 Strukturierung funktionaler Anforderungen ................................... 407 14.5 Anforderungen importieren und exportieren................................................. 416 14.6 Toolevaluierung – Wie finde ich das Richtige? .............................................. 417 14.7 Ordnung muss sein!........................ ............................................................. 420 15 Change- & Release-Management – Die stabile Instabilität ................................421 15.1 Quellen und Typen von Änderungen – Es kommt was auf Sie zu ................. 423 15.1.1 Incident-Management – Einer für alle und alles auf einmal ............ 424 15.1.2 Fachbereich und Produkt-Management .......................................... 424 15.1.3 Tester .............................................................................................. 425 15.1.4 Entwickler ...................................................................................... 425 15.1.5 Definitionen der Tickettypen .......................................................... 425 15.1.6 Sammeltopf für die Tickets ............................................................. 427 15.2 Problem-Management – Analyse der Probleme ............................................ 427 15.3 Change-Management ................................................................................... 428 15.3.1 Priorisierung der Tickets ................................................................. 428 15.3.2 Grob beschreiben ........................................................................... 429 15.3.3 Lösungsvarianten skizzieren ............................................................ 429 15.3.4 Aufwände schätzen ......................................................................... 430 15.3.5 Variante auswählen – oder Ticket schließen .................................... 430 15.4 Tickets einplanen ......................................................................................... 431 15.5 Release-Management .................................................................................... 432 15.5.1 Änderungen durchführen – Die Stunde der Traceability ................. 432 15.5.2 Konfigurationen und Basislinien ..................................................... 434 15.5.3 Release umsetzen ............................................................................ 435 15.5.4 Testen ............................................................................................. 435 15.6 Der Zielspurt – Release ausrollen ................................................................. 436 15.7 Ausnahmesituation – Das Emergency Release .............................................. 436 15.8 Die C- & RM-Salami scheibchenweise ......................................................... 439 16 Wiederverwendung – aus alt mach neu .............................................................441 16.1 Das Rad nicht immer neu erfinden .............................................................. 442 16.2 Die potentiellen Kandidaten ........................................................................ 443

XI XII

Inhaltsverzeichnis 16.3 Regelgeleitete Wiederverwendung ................................................................ 444 16.3.1 Spezifikationslevel ........................................................................... 445 16.3.2 Eingeschränkte Produktpalette ....................................................... 445 16.3.3 Einbindung in den Ablauf............................................................... 446 16.3.4 Technologie .................................................................................... 446 16.3.5 Konstanter Inhalt ........................................................................... 446 16.3.6 Zwischenfazit ................................................................................. 446 16.4 Vorgehensarten ............................................................................................ 447 16.4.1 Der Ansatz nach IVENA XT .......................................................... 447 16.4.2 Der Produktlinien-Ansatz ............................................................... 451 16.4.3 Der Main-Stream-Ansatz ................................................................ 456 16.4.4 Copy & Paste-Ansatz ...................................................................... 457 16.4.5 Wann eignet sich welcher Ansatz? ................................................... 458 16.5 Vorbereitungen für die Wiederverwendung .................................................. 459 16.6 Aus alt mach neu .......................................................................................... 460

Teil VI — Verträge, Konflikte und Einführungsprojekte managen ..............................461 17 Vertragspoker und Requirements-Engineering ..................................................463 17.1 Systementwicklung und Wirtschaftlichkeit .................................................. 464 17.2 Kooperationsprinzipien – Arten der Zusammenarbeit .................................. 465 17.2.1 Interessen des Auftraggebers ........................................................... 465 17.2.2 Interessen des Auftragnehmers ........................................................ 466 17.3 Vertragsmodelle ............................................................................................ 466 17.3.1 Aufwands- oder Festpreisbasis? ....................................................... 468 17.3.2 Dienst- versus Werkvertrag ............................................................. 470 17.3.3 Umgang mit fachlichen Änderungen .............................................. 473 17.4 Vertragsrelevante Dokumente ....................................................................... 475 17.4.1 Detaillierungsniveau ....................................................................... 477 17.4.2 Beschreibungsstile (Notation) ......................................................... 478 17.4.3 Spielart: Lastenheft – Pflichtenheft ................................................. 478 17.4.4 Spielart: OCD – SRS – SSS – SSDD ............................................. 479 17.5 Die Karten auf den Tisch – oder pokern Sie noch? ....................................... 482 18 Konsolidierungstechniken – Das Eis brechen ....................................................483 18.1 Unter der RE-Oberfläche ............................................................................. 484 18.2 Konfliktindikatoren – die Spitze des Eisbergs ............................................... 484 18.3 Ursachen und Wirkungen ............................................................................ 485 18.4 Vom Umgang mit Konflikten – Auf dem Eis ................................................ 487 18.4.1 Erkennen eines Konfliktes .............................................................. 489 18.4.2 Eindämmen eines Konfliktes .......................................................... 490 18.4.3 Lösen eines Konfliktes .................................................................... 490 18.4.4 Annäherungsmethoden ................................................................... 492 18.4.5 Abstimmungs- und Weisungsmethoden ......................................... 493 18.4.6 Analytische Methoden .................................................................... 494 18.5 Vom richtigen Konsolidierungszeitpunkt ..................................................... 498

Inhaltsverzeichnis 18.6 Das Vorgehen ............................................................................................... 499 18.7 Die Konsolidierungsmatrix .......................................................................... 500 18.8 Volle Fahrt voraus! ........................................................................................ 501 19 Einführungsstrategien – Reiseanleitung ins Land des perfekten Requirements-Engineerings .........................................................503 19.1 Gründe für eine gute Strategie ...................................................................... 504 19.1.1 Einführung bedeutet Veränderung .................................................. 504 19.1.2 Nichts ist beständiger als der Wandel .............................................. 506 19.1.3 Veränderung bedeutet Lernen ......................................................... 507 19.2 Eine Einführung ist ein Projekt! ................................................................... 510 19.2.1 Vorbereiten und Ausarbeiten .......................................................... 511 19.2.2 Umsetzen und anpassen .................................................................. 517 19.3 Arbeitspakete einer Einführung .................................................................... 518 19.3.1 Marketingkonzept .......................................................................... 518 19.3.2 Konzept zur Wissensvermittlung .................................................... 522 19.3.3 Pilotierungskonzept ........................................................................ 526 19.3.4 Leitfaden ........................................................................................ 531 19.3.5 Migrationskonzept .......................................................................... 533 19.4 Sind Sie gerüstet für die optimale Einführung? ............................................. 535 Anhang A – Literaturverzeichnis.............................................................................................537 B – Index...................................................................................................................545 C – Fotoverzeichnis....................................................................................................555

XIII

Chris Rupp, Ellen Wolf

Das SOPHIST–REgelwerk — Psychotherapie für Anforderungen

■■ Wenn Anforderungen von Menschen formuliert werden, finden bewusst und unbewusst Transformationen statt, die zu unvollständigen, verzerrten oder sogar falschen Informationen führen. ■■ Mittels SOPHIST-REgelwerk, das auf dem Therapieansatz „Neurolinguistisches Programmieren (NLP)“ basiert, können Sie Lücken und Verfälschungen in Ihren Anforderungen systematisch aufdecken und gezielt beheben. ■■ Therapieren Sie Ihre Anforderungen Schritt für Schritt — diese Regeln helfen Ihnen dabei, wirklich das zu verstehen, was Ihr Gegenüber will.

115

6 Das SOPHIST–REgelwerk

6.1

Vom Phänomen der Transformation — Sprachliche Effekte

Anforderungen werden von vielen verschiedenen Stakeholdern formuliert – Menschen unterschiedlichen Wissens, sozialer Prägung und Erfahrung. Diese Vielfalt spiegelt sich in den Anforderungen wider und birgt die Gefahr von Informationsverlusten, Unvollständigkeiten oder Zweideutigkeiten. Vor diesem Hintergrund stellen sich bei der Ermittlung von Anforderungen folgende zentrale Fragen: ■■ Was meint der Stakeholder wirklich? ■■ Wie erfährt man das, was der Urheber der Anforderung meinte, als er sie formulierte?

Das Metamodell der Sprache.

Die Antwort ist leider nicht so trivial, wie man es sich wünschen würde. Um dieses Problem zu lösen, haben wir Methoden aus den Disziplinen Linguistik, Informatik, Psychologie und Psychotherapie im sogenannten „SOPHIST-REgelwerk“ vereinigt. Bevor wir aber in die Tiefen des SOPHIST-REgelwerks einsteigen, stellen wir Ihnen zunächst sein theoretisches Fundament vor, das Neurolinguistische Programmieren (NLP). Wir zeigen Ihnen, wie Wissen von der Wahrnehmung der Realität bis hin zum sprachlichen Ausdruck Schritt für Schritt transformiert wird und zu den bekannten Unzulänglichkeiten in der natürlichen Sprache führt.

Als NLP-Kenner oder Theorie-Muffel können Sie direkt zu Abschnitt 6.3 springen.

Sie kennen diese Grundlagen oder Sie finden sie zu theoretisch? Kein Problem. Steigen Sie direkt bei der praxistauglichen Beschreibung der Regeln des SOPHIST-REgelwerks (vgl. Abschnitt 6.3) ein, die wir und auch unsere Kunden in vielen Projekten bereits erfolgreich eingesetzt haben. Wir haben dabei großen Wert darauf gelegt, die Anwendung der Regeln anhand vieler Beispiele zu erläutern. Ferner finden Sie viele Tipps und Tricks aus unserer Projekterfahrung, die Ihnen den Einsatz des SOPHIST-REgelwerks in Ihrem Projektalltag erleichtern werden.

6.2

Das ist das Modell des Modells „Sprache“, d. h. es beschreibt das Modell der Sprache.

Die Wurzeln — Das Neurolinguistische Programmieren

Das SOPHIST-REgelwerk basiert im Wesentlichen auf dem Metamodell der Sprache des Therapieansatzes Neurolinguistisches Programmieren (NLP) [Bandler75], [Bandler94]. Die Regeln des NLP helfen Therapeuten, die bei jedem Menschen vorhandene Intuition, ob ein Satz „richtig“ (linguistisch: wohlgeformt) ist oder nicht, bewusst zu machen. Bei der Systementwicklung kann der Requirements-Engineer mit ähnlichen Regeln Effekte in natürlichsprachlichen Anforderungen systematisch aufspüren und beheben. Wegweisend bei der Entwicklung natürlichsprachlicher Ansätze war der Linguist Noam Chomsky [Chomsky65], der wichtige linguistische Grundkonzepte erforschte und diese in der generativen Transformationsgrammatik beschrieb (siehe Artikel „Transformations-Linguistik“ unter www.sophist.de).

116

6 Das SOPHIST–REgelwerk Aufbauend auf einigen Thesen Chomskys wurde in der Psychotherapie ein Modell menschlicher Kommunikation und Ausdrucksweise erstellt und verfeinert. Maßgeblich daran beteiligt waren der Psychologe und Linguistikprofessor John Grinder und der Informatiker und Gestalttherapeut Richard Bandler. Mitte der 70er Jahre des 20. Jahrhunderts war es ihr Ziel, eine für jedermann erlernbare Therapieform zu entwickeln, die darauf beruht, dass der Therapeut die persönliche Wirklichkeit (Wahrnehmung) des Patienten versteht. Dazu muss der Therapeut herausfinden, was genau der Klient mit seinen Aussagen meint.

6.2.1

Transformationsprozesse

Jeder Requirements-Engineer sieht sich mit Anforderungen konfrontiert, die ein reales oder noch zu entwickelndes System beschreiben sollen. Wenn Menschen ein System beschreiben, also natürlichsprachliche Anforderungen formulieren, wird ein Transformationsprozess, wie in Abbildung 6.1 veranschaulicht, vollzogen.

Die eingeschränkte persönliche Wahrnehmung führt zur Wahrnehmungstransformation. Persönliche Wahrnehmung

Realität

Der sprachliche Ausdruck des persönlichen Wissens führt zur Darstellungstransformation.

Software-System, Produkt, Anwendung, Unternehmensprozess o. ä.

Persönliches Wissen

Wahrnehmung

Wissensdarstellung

Defekte?

Defekte? Sprachlicher Ausdruck des Wissens

Abbildung 6.1: Transformationen als mögliche Informationsvernichter

Ausgangspunkt (in der Abbildung 6.1 links) ist die zu beschreibende Realität, das eigentlich von den Stakeholdern gewünschte System. Rechts befindet sich hingegen die Beschreibung des Systems, also die formulierten Anforderungen, die der Systemanalytiker im Anforderungsdokument vorliegen hat. Zwischen den beiden Enden kann eine (mehr oder weniger tiefe) Lücke klaffen, die aufgrund von komplexen, meist unbewussten Transformationsprozessen entsteht.

RE-Bauernregel: Wenn der Stakeholder sein Wissen transformiert, die Anforderung er mit Verlust notiert.

Um die Lücke zwischen Realität und sprachlichem Ausdruck schließen zu können, müssen Sie als Requirements-Engineer zunächst die möglichen Transformationsarten kennen. Nur wenn Sie wirklich verstehen, warum die Realität „verfälscht“ oder nicht mehr abbildungstreu in den Anforderungen formuliert ist, können Sie die Realität auch gezielt ergründen.

117

6 Das SOPHIST–REgelwerk Jeder Mensch kann nur einen kleinen Bruchteil der gesamten Realität aufnehmen.

Transformationsprozesse resultieren aus unserer menschlichen Natur. Der Mensch wird durch seine soziale Prägung, sein Vorwissen und seine Erfahrungen in seiner Wahrnehmung beeinflusst. Psychologen sprechen hierbei von der so genannten „persönlichen Wirklichkeit“. Die persönliche Wirklichkeit wirkt sich auf die persönliche Wahrnehmung der Realität aus, so dass sich jeder Mensch seine eigenen Vorstellungen von der Realität macht. So wird zum Beispiel Bibliothekar A und Bibliothekar B dasselbe Leihobjekt, ein Buch, gezeigt. Bibliothekar A erfasst sofort die ansprechende Gestaltung mit Grafiken, die harmonisch mit dem Textkörper zusammenspielen und das Gesamtbild auflockern. Bibliothekar B hingegen nimmt dasselbe Buch vollkommen anders wahr. Er bemerkt die klare Gliederung des Werkes mit Einleitung, Hauptteil und Schluss, welche dem Leser das Verständnis erleichtern soll. Die ansprechenden Grafiken bemerkte er überhaupt nicht. Beide Bibliothekare haben somit unterschiedliche Bilder (in der Sprache der Psychologen: Modelle) von dem gleichen Buch – von der gleichen Realität. Woran liegt es aber, dass Bibliothekar A sich ausschließlich auf Grafiken und Layout konzentriert, während Bibliothekar B vor allem die thematische Gliederung wahrnimmt? Dieses Phänomen bezeichnen Psychologen als Wahrnehmungstransformation. Jeder Mensch wendet bei der Wahrnehmung der Realität unbewusst solche Transformationen (Umgestaltungsprozesse) an, die abhängig von seiner persönlichen Wirklichkeit sind.

Daraus ergibt sich für die Systemanalyse eine wichtige Erkenntnis: Die Gesamtinformation über die Realität ist immer „auf mehrere Köpfe“ verteilt, da jeder Mensch nur einen Bruchteil der Realität wahrnimmt. Dies hat zur Folge, dass es zur vollständigen Abbildung der Realität nicht ausreicht, nur einen Bibliothekar zu befragen.

Jeder Mensch setzt ein gewisses Grundwissen bei anderen voraus.

Interessanterweise treten die Transformationen aber noch an einer weiteren Stelle im Abbildungsprozess von der Realität zur Anforderung auf. Und zwar dann, wenn das persönliche Wissen in Sprache ausgedrückt wird (in Abbildung 6.1 als Wissensdarstellung bezeichnet). Wird Bibliothekar B nach dem Aufbau befragt, könnte die Antwort „äußerst sinnvoll“ lauten, obwohl er eigentlich den genauen Aufbau (nämlich Einleitung-Hauptteil-Schluss) meint. Er wandelt (transformiert) somit sein vorhandenes Wissen um, während er es in Sprache ausdrückt. Analog transformiert der Schreiber von Anforderungen oder ein Interviewpartner im Gespräch sein Wissen beim konkreten Formulieren der Anforderungen.

Fokussierung

Es gibt also zweierlei Transformationsprozesse: Wahrnehmungstransformationen treten auf, weil jeder Mensch die Realität anders wahrnimmt und sich ein individuelles Bild davon macht.

Vereinfachung

Darstellungstransformationen treten auf, weil eine Wandlung erfolgt, sobald ein Mensch sein Wissen (dieses Bild) in Sprache ausdrückt. Transformationen sind grundsätzlich nichts Problematisches und, wie wir noch sehen werden, sogar lebenswichtig. Für die Anforderungsanalyse stellen sie jedoch ein entscheidendes Problem dar, da mit den Transformationen möglicherweise essenzielle Informationen ver-

118

6 Das SOPHIST–REgelwerk lorengehen. Es macht schon einen Unterschied, ob der Bibliothekar von einem Buch, das sich in Einleitung-Hauptteil-Schluss gliedert, spricht, oder ob er den Aufbau mit „äußerst sinnvoll“ beschreibt. Bei der Entwicklung eines Systems können sich solche Nuancen in enormen Kostenunterschieden ausdrücken. Um dem entgegenzuwirken, müssen die Transformationen rückgängig gemacht und die Anforderungen mit den verlorengegangenen Informationen angereichert werden.

Transformationsprozesse führen zu Informationsverlusten und Informationsverfälschungen, die aufgedeckt werden müssen. Nun stellt sich die Frage: Ist es überhaupt möglich, diese Transformationen rückgängig zu machen? Und wenn ja, wie geht der Requirements-Engineer dabei vor? Zunächst lässt sich sagen, dass nur bestimmte Transformationen rückgängig gemacht werden können. Die Wahrnehmungstransformation (Realität  Persönliche Wahrnehmung) ist nicht mehr aufzulösen, da das individuelle Bild eines Menschen sich nicht problemlos beeinflussen lässt. Dies ändert sich unter Umständen, wenn sich die Erfahrungen und das soziale Umfeld des Menschen ändern. Unabhängig davon erfasst jeder Mensch aber immer nur einen Teil der Realität.

RE-Bauernregel: Lässt man Transformationen schleifen, muss man später tief in den Beutel greifen.

Auch wenn Sie es manchmal wollen ... therapieren Sie bitte nicht Ihre Stakeholder.

Um Wahrnehmungstransformationen zu kompensieren, muss der Requirements-Engineer stets mehrere Stakeholder zum gleichen Sachverhalt befragen. Die aus einer Befragung von mehreren Personen resultierenden unterschiedlichen Erfahrungen und Meinungen wirken nicht nur der Wahrnehmungstransformation entgegen, sondern stellen zudem auch eine Bereicherung für jedes Projekt dar. Wenn hier Synergien entstehen, kann ein insgesamt besseres System konstruiert werden. Darstellungstransformationen (Persönliches Wissen  Ausdruck in Sprache) lassen sich dagegen glücklicherweise sehr gut auflösen. Voraussetzung dafür ist allerdings, dass der Requirements-Engineer die möglichen Transformationsarten und deren Konsequenzen genau kennt.

Um Darstellungstransformationen aufzulösen, kann der Requirements-Engineer das SOPHIST-REgelwerk einsetzen. Darstellungstransformationen werden auch auf dem Gebiet der Linguistik untersucht. Linguisten nehmen an, dass der Mensch im Geist (unbewusst oder unterbewusst) von seiner Wahrnehmung eine vollständige sprachliche Repräsentation, eine so genannte Tiefenstruktur, bildet. Beginnt er dann zu reden oder zu schreiben, so trifft er eine Reihe von Auswahlentscheidungen hinsichtlich der Gestalt der zu artikulierenden Informationen und bildet somit die zugehörige Oberflächenstruktur. Er wählt aus einer Menge von Transformationen eine bestimmte oder meist mehrere aus, durch deren Anwendung auf die Tiefenstruktur die Oberflächenstruktur entsteht.

Das ist die „transformierte“ Form des Originals, also das, was der Mensch aussagt, wenn er das Gedachte in Sprache ausdrückt.

D. h. sprachliche Effekte gezielt erkennen und hinterfragen.

Das ist das Original, also das, was dem Menschen gedanklich vorschwebt, bevor er es in Sprache ausdrückt.

119

6 Das SOPHIST–REgelwerk Ein Satz (eine Oberflächenstruktur) ist also eine andere Form des „Originals“ (der Tiefenstruktur) im Kopf des Menschen. Der Oberflächenstruktur fehlen unter Umständen aber Teile oder es werden Teile falsch dargestellt. Aus dieser Annahme leitet sich auch das (linguistische) Ziel der Analyse von Anforderungen ab:

Um ein vollständiges und nicht verändertes Bild der persönlichen Wahrnehmung eines Stakeholders zu erlangen, muss der Requirements-Engineer aus der Oberflächenstruktur die zugehörige Tiefenstruktur ermitteln. Die Tatsache, dass Menschen sich bei der Bildung von Oberflächenstrukturen an Regeln halten, führte Chomsky zu der Annahme, dass das Verhalten der Menschen bei der Bildung sprachlicher Äußerungen offenbar regelgeleitet ist. Einen möglichen (und plausiblen) Satz von Regeln legte Chomsky in der bereits erwähnten Generativen Transformationsgrammatik erstmalig dar. Ähnlich dem Ansatz von Chomsky können wir auch in der Systemanalyse Regeln definieren, durch die ein systematisches Aufspüren der Transformationen bei Prosa-Anforderungen und Aussagen des Kunden möglich ist. Der Requirements-Engineer will einen Teil der persönlichen Wirklichkeit des Verfassers verstehen, kennt aber nur die sprachlichen Oberflächenstrukturen des Verfassers. Kann er aus ihnen die verwendeten Transformationen folgern, so ist es ihm durch gezieltes Hinterfragen möglich, an die Tiefenstruktur dessen zu gelangen, was der Verfasser auszudrücken suchte.

Reminder: Neurolinguistisches Programmieren

6.2.2

Kategorien der Darstellungstransformation

Aufbauend auf den Erkenntnissen der Linguistik unterscheiden Bandler und Grinder im NLP drei prinzipielle „Arten der Umgestaltung“: Tilgung, Generalisierung und Verzerrung. Diese Einteilung mag vielleicht nicht disjunkt erscheinen, hat sich in der Praxis aber als durchaus nützlich erwiesen.

Sprachlichen Effekte In Abbildung 6.2 sind diese drei Kategorien als Symbole grafisch dargestellt. Diese Symbole lassen sich nicht immer strikt nur einer verwenden wir in den nachfolgenden Abschnitten, um den Regeln des SOPHIST-REgelwerks Kategorie zuordnen. die Art der Umgestaltung entsprechend zuzuordnen. TILGUNG ist ein Indikator für unvollständige Informationen.

VERZERRUNG ist ein Indikator für realitätsverfälschende Aussagen.

GENERALISIERUNG ist ein Indikator für fehlerhafte Verallgemeinerungen. Abbildung 6.2: Klassifizierung sprachlicher Effekte

120

6 Das SOPHIST–REgelwerk Nachfolgend beschreiben wir die Transformationskategorien nach Bandler und Grinder. Die Definitionen sind rein sprachwissenschaftlicher Natur, können aber durchaus auch auf die sprachlichen Effekte im Zusammenhang mit Anforderungen angewendet werden.

Tilgung Der Prozess der Tilgung reduziert die Flut an Informationen, mit denen wir konfrontiert werden, auf Ausmaße, mit denen wir umgehen können. Wenn wir wiederum Informationen weitergeben, dann tilgen wir dabei unbewusst jene Teile, die wir als „selbstverständlich“ ansehen oder unbewusst beim Informationsempfänger als bekannt voraussetzen. Mit Hilfe der Tilgung ist es uns zum Beispiel möglich, das allgemeine Stimmengewirr in einem Raum mit vielen Menschen so zu filtern, dass uns nur noch die Stimme unseres Gesprächspartners bewusst erreicht (selektive Wahrnehmung). Tilgung (engl. Deletion) ist ein Prozess, durch den wir unsere Aufmerksamkeit selektiv bestimmten Dimensionen unserer (im Moment möglichen) Erfahrungen zuwenden und andere ausschließen. Tilgung reduziert die Welt auf Ausmaße, mit denen wir umgehen können. [Bandler94] Diese Reduktion kann in einem gewissen Kontext sinnvoll sein, in Anforderungen an ein Softwaresystem können durch Tilgungen jedoch wichtige Informationen verloren gehen. So mag ein Bibliothekar mitteilen: „Zum Ende eines Monats werden die Konten mit den anfallenden Gebühren belastet“. Ein anderer Bibliothekar, vertraut mit den Arbeitsprozessen der Bibliothek, wird aus diesem Satz die getilgten Inhalte wahrscheinlich rekonstruieren können: „Es fallen Mahngebühren für Kunden an, die Leihfristen überschreiten.“ Der unbedarfte Zuhörer, dem diese getilgten Informationen nicht bekannt sind, könnte die Aussage des Bibliothekars aber vollkommen anders interpretieren.

RE-Bauernregel: Wenn Informationen nicht vollständig kommen ans Licht, fehlendes Wissen herauskitzeln ist des RElers Pflicht.

Generalisierung Die Generalisierung ist ein Prozess, durch den eine einmalige Erfahrung (Teile eines persönlichen Modells) auf andere, ähnliche Sachverhalte oder verwandte Zusammenhänge übertragen und somit als allgemeingültig angenommen wird. Die menschliche Fähigkeit, Erfahrungen zu generalisieren, ist ein Prozess, der überlebenswichtig sein kann. Ein Beispiel für eine solche Generalisierung ist die heiße Herdplatte, bei deren schmerzvoller Berührung ein Kind richtig generalisiert, dass alle heißen Herdplatten gefährlich sind, nicht nur die eine, an der es sich verbrannt hat. Eine nicht ganz so richtige Generalisierung wäre die grundsätzliche Angst, alle Herdplatten anzufassen (also auch kalte), oder die Annahme, dass man sich nur an dieser einen speziellen Herdplatte die Finger verbrennen kann. Was bleibt, ist das Wissen, dass die Berührung irgendeiner heißen Herdplatte zu unerwünschten Verbrennungen führt, und hoffentlich auch die Vorsicht gegenüber allen Herdplatten (da sie ja heiß sein können).

121

6 Das SOPHIST–REgelwerk RE-Bauernregel: Generalisierung (engl. Generalization) ist der Prozess, durch den Elemente oder Wenn GeneralTeile eines persönlichen Modells von der ursprünglichen Erfahrung abgelöst isierungen dem Stakewerden, um dann die gesamte Kategorie, von der diese Erfahrung ein Beispiel holder nicht richtig darstellt, zu verkörpern. [Bandler94] gelingen, der REler die Information auf den Generalisierung ist auch im Kontext der Systemanalyse nützlich und sinnvoll. Wichtig ist Punkt muss bringen.

allerdings die passende Gruppierung der Sachverhalte, auf die sich das zu beschreibende Systemverhalten bzw. die Systemeigenschaft generalisierend beziehen soll. Durch eine zu starke Generalisierung entstehen globale Anforderungen an das System, die wahrscheinlich nur für einen Teilbereich des Systems richtig und sinnvoll sind. Sonder- und Fehlerfälle gehen hierbei häufig verloren. So könnte der Bibliothekar berichten, dass die Kennungen aller Bücher, die zur Kunstabteilung gehören, mit dem Kürzel KST beginnen. In der Kunstabteilung gibt es aber auch Exfolianten, die aufgrund ihrer Übergröße nicht in die vorgesehenen Regale passen und daher an anderer Stelle untergebracht sind. Diese sind mit dem Kürzel EXF ausgezeichnet. Der Bibliothekar hat diesen Sonderfall versehentlich vergessen.

Verzerrung Die Verzerrung ist der Vorgang, durch den die Realität umgestaltet oder sogar verfälscht wird. Von einer Verzerrung spricht man, wenn ein Aspekt der Realität so verändert wird, dass er beim Betrachter zu einem Zerrbild führen kann. Verzerrung findet statt, wenn eine Situation mit Ausdrücken beschrieben wird, die nicht entsprechend dieser Situation sind. Somit wird die Situation ausgeschmückt oder getrübt und die eigene Wahrnehmung oder die des Empfängers (wenn auch meist unbewusst) beeinflusst. Das Phänomen der Verzerrung sorgt dafür, dass der Mensch neue Informationen leichter in seine Vorstellungen integrieren kann. So manches Detail wird nötigenfalls ein wenig verändert, um in das bereits erstellte Bild einer Situation zu passen. Somit verändern wir häufig eine Information oder unsere Wahrnehmung so, wie es für uns richtig erscheint.

RE-Bauernregel: Wenn der Stakeholder eine Umgestaltung hat vorgenommen, der REler der Realität auf die Spur muss kommen.

122

Jede Verzerrung kann eine Menge an Informationen vernichten und ist damit implizit auch ein Tilgungsdefekt. Verzerrung (engl. Distortion) ist der Prozess, der es uns ermöglicht, in unserer Erfahrung sensorischer Einzelheiten eine Umgestaltung vorzunehmen. [Bandler94] Verzerrungen stellen für jeden Requirements-Engineer eine harte Nuss dar, da er häufig nicht entscheiden kann, ob formulierte Sachverhalte korrekt sind, ob sie verzerrt wurden oder ob er sie durch seine eigene Wahrnehmung selbst verzerrt. Ein Bibliothekar berichtet beispielsweise, dass bei jeder Reservierung eine Sperrung erfolgen soll. Der Bibliothekar verzerrt hier einen Sachverhalt, da er den Prozess der „Sperrung“ als selbstredend und somit vereinfacht beschreibt. Unter Umständen kann dieser Prozess aber aus einer Reihe komplexer Prozessschritte bestehen.

6 Das SOPHIST–REgelwerk

6.3

Vom Umgang mit sprachlichen Effekten

Jede der erwähnten Transformationskategorien Tilgung, Generalisierung und Verzerrung zeigt sich in bestimmten so genannten sprachlichen Effekten. Jeder Effekt kann zu qualitativ minderwertigen Anforderungen führen, jedoch nicht in allen Fällen auch zu einem Defekt. Inwiefern ein sprachlicher Effekt ein Problem darstellt und deshalb behoben werden sollte, hängt von vielen Randbedingungen ab. Ein wichtiger Faktor ist sicherlich das Detaillierungsniveau, auf dem Sie gerade Anforderungen schreiben. Sprachliche Effekte auf der Ebene von Zielen oder von eher generischen Anforderungen (z. B. Spezifikationslevel 0 und 1, siehe Kapitel 3 „Von der Idee zur Spezifikation“) sind normal und auf dem angestrebten Detaillierungsniveau auch nicht immer zu vermeiden. Da es allerdings Leser geben wird, die Ihre Spezifikation nur auf diesen Ebenen betrachten werden, ist es wichtig, dass die für diese Leserschaft wichtigen Informationen nicht durch Effekte vernichtet werden. Gewisse grundlegende Regeln sollten Sie bereits auf Spezifikationslevel 0 und 1 einhalten: ■■ Schreiben Sie Ihre Anforderungen stets in vollständigen Sätzen. ■■ Formulieren Sie immer im Aktiv (siehe Regel 1 in Abschnitt 6.4.1). ■■ Verwenden Sie Begriffe konsistent und vermeiden Sie Synonyme oder Homonyme. ■■ Falls es bereits ein Glossar (siehe Kapitel 8 „Dokumentation von Anforderungen“ und Kapitel 7 „Schablonen“) gibt, verwenden Sie die darin definierten Begriffe. ■■ Formulieren Sie Prozesse durch Vollverben.

Wie z. B. berechnen, drucken, exportieren, überweisen, ....

Schreiben Sie sehr detaillierte Anforderungen (ab Spezifikationslevel 2), die auch noch Teil eines Vertrages für eine externe Beauftragung werden, so sind sprachliche Effekte bei weitem schädlicher und sollten sehr kritisch geprüft und nach Möglichkeit beseitigt werden. Auch wenn Ihre Anforderungen syntaktisch meist wohlgeformt sind, können sie sprachliche Effekte enthalten. Ihre Aufgabe ist es nun, diese Effekte zu erkennen und zu beheben, sofern die fehlenden oder verzerrten Informationen wesentlich sind.

Grammatikalisch richtig Wir empfehlen daher, die Regeln des SOPHIST-REgelwerks im Wesentlichen ab Spezifikationslevel 2 anzuwenden. Ab diesem Level formulieren Sie detailliertere Anforderungen, durch die Anforderungen auf Level 0 und Level 1 verfeinert werden.

123

6 Das SOPHIST–REgelwerk Unabhängig davon, auf welchem Spezifikationslevel Sie Anforderungen formulieren, sollen Sie sich immer an folgende grundlegende Regel halten: Für jeden Spezifikationslevel gibt es zu der obigen Grundregel „Formulieren Sie Prozesse durch Vollverben“ eine Verfeinerung, die immer zu beachten ist: ■■ Verwenden Sie immer nur Vollverben, die für den jeweiligen Spezifikationslevel auch „gute“ Vollverben darstellen. Denn nicht jedes Vollverb ist ein für den Spezifikationslevel angemessenes Vollverb. Auf Spezifikationslevel 1 werden beispielsweise für das Bibliothekssystem die Use-Cases definiert, von denen sich einer auf die Kundenverwaltung bezieht. Als Vollverb formuliert notieren wir den Use-Case als „Kunde verwalten“. Für Spezifikationslevel 1 ist das Vollverb „verwalten“ durchaus angemessen. Ab Spezifikationslevel 2 verwenden wir aber niemals das Vollverb „verwalten“, da es für diesen Level viel zu nichtssagend, zu „schwammig“ ist. Vielmehr verfeinern wir das Vollverb „verwalten“ durch detailliertere und für Level 2 geeignete Vollverben, wie beispielsweise „eingeben“, „speichern“, „anzeigen“, usw.

Setzen Sie hier auch die Anforderungsschablone aus Kapitel 7 „Schablonen“ ein. Wenn Sie das Auftreten sprachlicher Effekte von Anfang an vermeiden wollen, dann set-

zen Sie das SOPHIST-REgelwerk direkt konstruktiv während der Ermittlung und bei der Formulierung Ihrer Anforderungen ein. Wollen Sie Effekte in bereits dokumentierten Anforderungen aufspüren? Dann empfehlen wir den analytischen Einsatz des SOPHIST-REgelwerks.

Kombinieren Sie das REgelwerk mit den analytischen Prüftechniken aus Kapitel 10 „Prüftechniken für Anforderungen.“ Und wenn Sie basierend auf einer Qualitätsaussage über Ihre Anforderungen eine Grundlage für die Entscheidungsfindung schaffen wollen, messen Sie die formale Qualität Ihrer Anforderungen mit Hilfe von Qualitätsmetriken (vgl. Kapitel 11 „Qualitätsmetriken“), die im Wesentlichen auf den Regeln des SOPHIST-REgelwerks aufbauen. Grundsätzlich sollte es aber nicht Ihr Ziel sein, alle Anforderungen so weit zu perfektionieren, bis sie von allen Effekten befreit sind. Konzentrieren Sie sich auf die Informationen, die Sie für den weiteren Prozess benötigen. Hinterfragen Sie vor allem an den Stellen, an denen fehlende oder falsche Informationen das höchste Risiko für Ihren Projekterfolg darstellen.

Z. B. ab Spezifikationslevel 2

Gehen Sie risikogetrieben vor. Gehen Sie auf Nummer sicher: Setzen Sie die Regeln des SOPHIST-REgelwerks umso intensiver ein, ■■ je detaillierter Sie Anforderungen beschreiben, ■■ je kritischer Ihr System und damit Ihr Projekt ist.

Eine Rangliste hierzu finden Sie in Abschnitt 6.8. 124

Nach unserer Erfahrung treten sprachliche Effekte in unterschiedlicher Häufigkeit auf. Daher ist es wichtig und ratsam, dass Sie sich zunächst auf die Gruppe der gefährlichen Wiederholungstäter konzentrieren.

6 Das SOPHIST–REgelwerk

6.4

Das Vorgehen beim SOPHIST–REgelwerk — Anforderungen auf die Couch gelegt Basierend auf den Thesen des Linguisten Noam Chomsky und dem Metamodell der Sprache lässt sich auch ein Regelwerk für die Systemanalyse aufstellen: das SOPHIST-REgelwerk. Es basiert auf Regeln, nach denen der Mensch unbewusst vorgeht, wenn er sich natürlichsprachlich, d. h. in Wort und Schrift, äußert.

RE-Bauernregel: Hast du einen wilden Anforderungshaufen, lass ihn gleich das REgelwerk durchlaufen.

Mithilfe des SOPHIST-REgelwerks können auf definierte, systematische Art und Weise mehrdeutige, unvollständige und widersprüchliche Aussagen in Anforderungsdokumenten gefunden werden (analytische Qualitätssicherung). Auch präventiv, also im Zuge der konstruktiven Qualitätssicherung, lässt sich die Kenntnis der Transformationsprozesse beim Ermitteln und Dokumentieren von Anforderungen einsetzen (vgl. Kapitel 10 „Prüftechniken für Anforderungen“).

Das SOPHIST-REgelwerk ist eine Technik, die es Ihnen ermöglicht, Tilgungen, Generalisierungen und Verzerrungen in Anforderungen zu erkennen und somit fehlende und verzerrte Informationen in Anforderungsquellen aufzudecken. Durch jede einzelne Regel des SOPHIST-REgelwerks können unterschiedliche sprachliche Effekte in einer Anforderung gezielt gefunden werden. Obwohl sich die Regeln in diesem Kapitel ausschließlich auf Anforderungen beziehen, lassen sie sich natürlich auf sämtliche natürlichsprachliche Ausdrucksformen (mündlich oder schriftlich) anwenden. Das Vorgehen beim Einsatz einer einzelnen Regel aus dem SOPHIST-REgelwerk ist denkbar einfach:

Z. B. auch auf semiformale Notationen, wie beispielsweise Diagramme, Tabellen oder Bilder, in denen natürliche Sprache vorkommt.

Signalwort finden ■■ Schritt 1: Identifizieren von sprachlichen Effekten in Anforderungen anhand von Signalwörtern. ■■ Schritt 2: Analysieren verlorener oder verfälschter Informationen durch gezielte Fragestellungen. ■■ Schritt 3: Bereinigen sprachlicher Mängel oder inhaltlicher Fehler durch Umformung der Anforderung mittels der gegebenen Antworten, so dass Effekte eliminiert werden.

Fragen zum Signalwort stellen

Anworten einarbeiten Vom Grundsatz her ist das SOPHIST-REgelwerk eine Ansammlung von Regeln. In der Praxis fällt es uns jedoch häufig schwer, mit einem solch umfangreichen Pool an Regeln umzugehen, wenn darauf keine Ordnung definiert ist.

125

6 Das SOPHIST–REgelwerk Vermutlich kennen Sie das auch: Sie erfahren von einem Kollegen, dass es da eine ganz tolle Ansammlung von Regeln und Empfehlungen gibt, durch die Sie die Qualität Ihrer täglichen Arbeit steigern können. Voller Euphorie stürzen Sie sich auf das Regelwerk und erkennen, dass alle Regeln einfach und verständlich sind. Mit Ihrem neu erlangten Wissen machen Sie sich voller Elan an Ihre nächste Aufgabe. Und dann sitzen Sie ganz verzweifelt da und wissen nicht, wie Sie diese eigentlich simplen Regeln am besten einsetzen sollen. Sie stellen sich sicherlich die folgenden Fragen: Wie soll ich denn konkret vorgehen? Mit welcher Regel fange ich an und brauche ich wirklich alle Regeln? In welcher Reihenfolge soll ich welche Regeln mit welcher Priorität anwenden?

1. Prüfe die Satzbestandteile

2. Prüfe den Satz

3. Prüfe das Gesamtbild

Abbildung 6.3: Das Vorgehen beim Einsatz des SOPHIST-REgelwerks

Den Fallstricken der natürlichen Sprache kann man wahrscheinlich nie endgültig entgehen. Es gibt nicht den einen, wahren Leitfaden, der immer gültig ist. Dennoch lässt sich ein Muster aufzeigen, das sich bei der Anwendung der Regeln in unseren Projekten bereits mehrfach bewährt hat. In Abbildung 6.3 ist dieses Vorgehen dargestellt.

126

6 Das SOPHIST–REgelwerk Nach unserer Projekterfahrung sollten Sie beim Prüfen einer Anforderung immer vom Kleinen (den Satzbestandteilen) zum Großen (dem Gesamtbild) vorgehen. Grundsätzlich durchlaufen Sie das folgende Vorgehen Anforderungssatz für Anforderungssatz: ■■ 1. Prüfen Sie zunächst die einzelnen Wörter (Bestandteile) eines Anforderungssatzes, um ihn schrittweise durch wesentliche, aber getilgte Informationen zu vervollständigen. Bestimmte Wörter in Ihrem Anforderungssatz stellen dabei Ihre Signalwörter dar, auf die Sie achten müssen. Jedes einzelne Signalwort weist auf einen spezifischen semantischen Effekt hin. An diesem Signalwort erkennen Sie dann auch die Regel, die Sie anwenden müssen. ■■ 2. Prüfen Sie danach den Anforderungssatz als Ganzes, um ihn von unnötigem Ballast zu befreien und ihn somit aufs Essenzielle zu reduzieren. Für das System nicht relevante Informationen oder Floskeln blähen Ihren Satz nur unnötig auf und lassen ihn unübersichtlich werden. Solche Satzbestandteile können Sie dann ohne Informationsverlust entweder aus der Anforderung als Kommentar herauslösen oder komplett eliminieren. ■■ 3. Prüfen Sie zum Schluss, wie sich der Anforderungssatz in das zu beschreibende Gesamtbild einfügt. Durch diese Kontrolle können Sie schrittweise das Gesamtbild („Big Picture“) vervollständigen. Nutzen Sie hierzu die Informationen, die Ihnen in dem Anforderungssatz bereits vorliegen. Fehlt Ihnen beispielsweise die Spezifikation einer bestimmten Systemfunktionalität oder -eigenschaft, damit der untersuchte Anforderungssatz sinnvoll in das Gesamtbild passt? Auch hier helfen Ihnen wieder bestimmte Signalwörter dabei, selbst die vom Gesamtbild fast vollständig getilgten Funktionalitäten oder Prozesse aufzufinden. Das beschriebene Vorgehen hört sich relativ einfach an. Die Analyse von Anforderungen ist aber leider alles andere als trivial. Insbesondere beim konstruktiven Einsatz des Vorgehens sollten Sie beachten, dass Sie bereits beim Analysieren der Satzbestandteile häufig nicht nur den untersuchten Anforderungssatz mit fehlenden Informationen anreichern, sondern auch auf zusätzliche Anforderungen stoßen oder den Anforderungssatz verfeinern müssen. Gerade in diesem Fall ist dann ein diszipliniertes Vorgehen nach dem Schema „Anforderungssatz nach Anforderungssatz“ äußerst wichtig. Ansonsten könnten Sie schnell Schiffbruch erleiden und in den (teilweise mächtig ausschlagenden) Wellen neuer Anforderungen oder gar neuer Prozesse untergehen. Wir empfehlen hier, sich die neuen bzw. verfeinerten Anforderungen zu notieren, diese aber noch nicht direkt detailliert zu analysieren. Sie sollten zunächst die Analyse der ursprünglich untersuchten Anforderung fortsetzen. Prüfen Sie dann anschließend die neu hinzugekommenen Anforderungen im Detail.

Wenn das Signalwort „speichern“ fällt, müssen Sie die typischen „W-Fragen“ zu „speichern“ stellen. Wenn etwas „von grüner Farbe“ sein soll, dann ist es ausreichend, „grün“ zu schreiben. Wenn nach einem „erfolgreichen Plausibilitätscheck“ Daten gespeichert werden sollen, muss auch der Negativfall spezifiziert sein.

Behalten Sie bei Interviews oder beim Schreiben von Anforderungen den roten Faden.

Nachfolgend werden alle Regeln des SOPHIST-REgelwerks im Detail vorgestellt und anhand vieler Beispiele erläutert. Generell gilt, dass die Reihenfolge, in der die Regeln beschrieben werden, das Vorgehen bei deren Anwendung widerspiegelt. Für NLP-Kenner ist jede Regel, die sich sinnvoll einer der Transformationskategorien gemäß Bandler und Grinder zuordnen lässt, mit dem entsprechenden Symbol aus Abbildung 6.2 gekennzeichnet.

127

6 Das SOPHIST–REgelwerk RE-Bauernregel: Will der REler die Anforderung korrekt spezifizieren, muss er sich auf ihre Einzelteile konzentrieren.

6.5

Prüfen der Satzbestandteile

Zunächst konzentrieren wir uns auf die einzelnen Bestandteile (Wörter) des Anforderungssatzes, um diesen schrittweise mit fehlenden Informationen zu vollständigen.

6.5.1

Prüfen der Prozesse

Verb, aber auch Nominalisierung oder Funktionsverbgefüge

Wenn ein Prozess in einer Anforderung durch ein Prozesswort beschrieben wird, müssen für diesen Prozess weitere Informationen beschrieben werden.

Funktionalität, Vorgang oder Tätigkeit Um den Interpretationsspielraum zu reduzieren, muss beispielsweise für den Prozess „drucken“ beschrieben werden, wer wann was worauf drucken möchte. Auch das Verb „übertragen“ benötigt zu seiner vollständigen Erklärung zumindest die vier Ergänzungen, wer etwas überträgt, was übertragen wird, von wo und wohin. Ihr Sprachgefühl gibt Ihnen darüber Auskunft, um welche Informationen ein Prozesswort ergänzt werden muss, um vollständig spezifiziert zu sein. Beim Prüfen der Prozesswörter liegt Ihr Hauptaugenmerk auf der in einer Anforderung beschriebenen Funktionalität. Das zu identifizierende Signalwort ist demnach das Prozesswort, also ein Verb (oder eine abgeleitete Form des Verbs), durch das ein Prozess beschrieben wird.

RE-Bauernregel: Wenn der REler im Passiv schreibt, der Akteur auf der Strecke bleibt.

Schritt 1: Prüfe auf Aktivformulierung Ein sprachlicher Effekt, nämlich die Tilgung des Akteurs, lässt sich dadurch vermeiden, dass Anforderungen im Aktiv formuliert werden. Liegt eine Anforderung dagegen im Passiv vor, so muss die Anforderung ins Aktiv umformuliert werden. Regel 1: Formulieren Sie jede Anforderung im Aktiv. Prüfen Sie, ob die Anforderung im Aktiv formuliert ist. Wenn nicht, wurde der Akteur, also die ausführende Person oder Einheit, getilgt. Erfragen Sie den Akteur und ergänzen Sie diesen in der Anforderung, indem Sie die Anforderung im Aktiv formulieren.

Wer soll den Prozess ausführen bzw. über die Eigenschaft verfügen?

selbständige Systemaktivität Schnittstellenanforderung

Gerade bei der Formulierung von Anforderungen ist die Angabe des Akteurs entscheidend, da wichtig ist, ob die Aktivität vom System, vom Nachbarsystem oder vom Benutzer durchgeführt wird (vgl. Kapitel 7 „Schablonen“). Auf diese Weise erhält die Anforderung einen höheren Informationsgehalt und das Prozesswort wird näher spezifiziert, da angegeben wird, wer den Prozess durchführt bzw. über eine bestimmte Eigenschaft verfügen muss.

Benutzerinteraktion

128

6 Das SOPHIST–REgelwerk Bei der im Passiv formulierten Anforderung „Das Benutzerkennwort muss an einem Terminal des Bibliothekssystems eingegeben werden.“ ist beispielsweise nicht klar, wer das Kennwort eingeben kann. Im Aktiv muss hingegen ein Akteur oder Verantwortlicher angegeben werden: „Der Bibliothekskunde muss das Benutzerkennwort an einem Terminal des Bibliothekssystems eingeben.“ Diese Aussage ist schon ein Stück klarer, doch noch lange keine Anforderung an ein System. Hier wird lediglich etwas von einem Benutzer gefordert (und Sie wollen bei der Abnahme wohl kaum Ihren Benutzer testen). Leiten Sie nun die Anforderung an das System ab, also die Funktionalität, die das System zur Verfügung stellen muss, damit der Benutzer die Eingabe machen kann. Dies könnte beispielsweise das Bereitstellen einer Eingabemöglichkeit für das Benutzerkennwort sein: „Das Bibliothekssystem muss es dem Bibliothekskunden ermöglichen, ein Benutzerkennwort an einem Terminal des Bibliothekssystems einzugeben.“

Schritt 2: Identifiziere die geforderte Funktionalität Nachdem nun die Anforderung im Aktiv formuliert ist, lassen sich sprachliche Effekte, durch die eine konkret geforderte Funktionalität verschleiert wird, leichter identifizieren, wenn die in der Anforderung beschriebene Funktionalität durch ein Vollverb formuliert ist.

Verben, die alleine das Prädikat eines Satzes bilden, z. B. „speichern“, „anzeigen“ oder „eingeben“ Hilfsverben sind dagegen Verben wie „haben“, „sein“, „werden.“ Regel 2: Drücken Sie Prozesse durch „gute“ Vollverben aus. Schwammig formulierte Prozesswörter (Verben, Tätigkeitswörter) verschleiern die konkret geforderte Funktionalität. Hinterfragen Sie die konkret geforderte Funktionalität und drücken Sie diese durch ein „gutes“ Vollverb aus.

Nicht alle Vollverben sind auf jedem Spezifikationslevel „gute“ Vollverben, wie z.B. „verwalten“ oder „prüfen.“

Welche Hinterfragen Sie beispielsweise die schwammige Forkonkrete Funktionalität wird mulierung „umfassende Informationen angeben“ in der gefordert? Wie lautet das Anforderung „Das Bibliothekssystem muss dem BiblioVOLLVERB? thekar bei der Suche nach einem Leihobjekt umfassende Informationen über das gefundene Leihobjekt angeben.“, so wird sich wahrscheinlich die konkret vom System geforderte Funktionalität „anzeigen“ ergeben. Durch die Umformulierung in das Vollverb „anzeigen“ wird dann schnell deutlich, dass weitere Angaben zur vollständigen Beschreibung des Vollverbs erkundet werden müssen. Zumindest die Frage, was genau angezeigt werden soll, müssen Sie bei der Umformulierung der Anforderung beantworten. Damit beschäftigt sich Regel 6.

Definieren Sie das Vollverb anschließend in Ihrer Prozesswortliste (vgl. Kapitel 7 „Schablonen“).

129

6 Das SOPHIST–REgelwerk

Bitte verwenden Sie ab Spezifikationslevel 2 keine Vollverben, wie z. B. „prüfen“, „verwalten“ oder „abbrechen“.

Damit beschäftigt sich Regel 17

RE-Bauernregel: Will der Stakeholder die Anforderung verderben, macht er Substantive aus den Verben.

Eine verbesserte (aber noch lange nicht perfekte) Anforderung könnte, nachdem die Antworten auf die Fragen eingearbeitet wurden, folgendermaßen lauten: „Nachdem das Bibliothekssystem die Suche nach einem Leihobjekt durchgeführt hat, muss das Bibliothekssystem dem Bibliothekar alle verfügbaren Stammdaten des Leihobjekts anzeigen.“ Auch die Prozessbeschreibung „Plausibilität prüfen“ in der Anforderung „Nachdem der Bibliothekar das Speichern eines neuen Kunden initiiert hat, muss das Bibliothekssystem die Plausibilität der eingegebenen Kundendaten prüfen.“ ist streng genommen eine schwammige Prozessformulierung. Der Prozess „Prüfen“ erfordert vielmehr die Beschreibung des nachweisbaren Ergebnisses, wie beispielsweise „Daten speichern“ oder „Fehlernachricht anzeigen“. Hier muss die Anforderung also umformuliert werden: „Nachdem der Bibliothekar den Speichervorgang eines neuen Kunden initiiert hat und falls das Alter des neu eingegebenen Kunden größer als oder gleich 18 Jahre ist, muss das Bibliothekssystem die Daten des neu eingegebenen Kunden speichern.“ Die Umformulierung der Anforderung hat dazu geführt, dass Sie eine präzise Fallunterscheidung machen müssen. Sie müssen genau beschreiben, welches Verhalten Ihr System bei Eintritt einer bestimmten Bedingung oder Bedingungskombination aufweisen muss. Jetzt müssen Sie natürlich noch die weiteren Fälle der obigen Anforderung hinterfragen und spezifizieren. Das Offenlegen der konkret zu spezifizierenden Funktionalität ist aber nicht immer so einfach. Manche Anforderungen sind so effektbehaftet, dass der eigentlich zu spezifizierende Prozess vollkommen verschleiert wird. In diesem Fall ist es die Aufgabe des RequirementsEngineers, den konkreten Prozess zu identifizieren und zu präzisieren. Typischerweise treten Prozessformulierungen auch in Form von sogenannten „Nominalisierungen“ oder „Funktionsverbgefügen“ auf.

Nominalisierungen

Ein (oft länger währender) Prozess wird zu einem (einmaligen) Ereignis verzerrt.

Nominalisierungen sind Substantive (Nomen, Hauptwörter), durch die komplexe Prozesse in einem Begriff (einem „substantivierten Verb“) zusammengefasst werden, die im Detail aufwändig zu beschreiben wären. Durch diese Umwandlung gehen wichtige Informationen verloren, die für die Beschreibung des Prozesses wesentlich sind. Bei der sprachlichen Analyse werden alle Nominalisierungen identifiziert und analysiert.

Achten Sie auf Signalwörter wie „die Reservierung“, „die Registrierung“ (und auch „Requirements-Engineering“). Regel 3: Lösen Sie Nominalisierungen auf. Nominalisierungen können einen kompletten Prozess verschleiern. Analysieren Sie jede Nominalisierung und prüfen Sie, ob der Prozess an anderer Stelle im Anforderungsdokument ausreichend spezifiziert ist. Ist dies nicht der Fall, müssen Sie für die Nominalisierung: ■■ ■■

130

Eine oder mehrere neue Anforderungen mit jeweils einem „guten“ Vollverb spezifizieren, ODER Einen neuen Glossareintrag erstellen.

6 Das SOPHIST–REgelwerk Analysiert man beispielsweise die Anforderung „Das Ist das System muss eine Archivierung ermöglichen.“, wird Substantiv eine Nominalisierung? sich herausstellen, dass das Substantiv „Archivierung“ Welcher konkrete Prozess steckt eine Nominalisierung ist. Nun müssen Sie die genaue dahinter? Intention des Stakeholders hinterfragen. Der hinter der Anforderung steckende Prozess wird, als Vollverb ausgedrückt, wahrscheinlich „archivieren“ lauten. Eine verbesserte Anforderung, in der die Frage nach dem „Was muss archiviert werden?“ beantwortet wird, könnte dann die folgende sein: „Das Bibliothekssystem muss die Daten der aus dem Bestand aussortierten Leihobjekte archivieren.“ In der Beispielanforderung des Bibliothekssystems „Bei der Rückgabe eines reservierten Leihobjekts muss das Bibliothekssystem an den Bibliothekskunden, der das Leihobjekt reserviert hat, eine Benachrichtigung versenden.“ stellen die Begriffe „Rückgabe“ und „Benachrichtigung“ jeweils Nominalisierungen dar, die genauer analysiert werden müssen.

Was geschieht alles bei der „Rückgabe“? Wann und durch wen oder was wird die „Rückgabe“ eingeleitet bzw. beendet? Welche Fehler-/Ausnahmefälle können bei der „Rückgabe“ auftreten?

Werden alle Fragen aus dem Anforderungsdokument heraus beantwortet, so kann die obige Anforderung weitestgehend unverändert bestehen bleiben. Nur dann, wenn hinter den Nominalisierungen „Rückgabe“ und „Benachrichtigung“ Prozesse stecken, die nicht vollständig spezifiziert oder definiert sind, müssen die fehlenden Informationen dem Anforderungsdokument hinzugefügt werden. Wird durch die Nominalisierung ein (unter Umständen komplexer) Prozess verzerrt, muss dieser in der Regel mit allen zugehörigen Schritten für Normal- und Ausnahmeverhalten durch entsprechende Anforderungen beschrieben werden. In der obigen Anforderung könnte die „Rückgabe“ eines Leihobjektes beispielsweise aus folgendem Verlauf bestehen: „Leihobjekt auswählen“, „Status des Leihobjektes ändern“, „Anzahl der ausgeliehenen Leihobjekte für Bibliothekskunde aktualisieren“… Dieser Verlauf erfordert also eine Reihe von Anforderungen. Im nächsten Schritt muss geprüft werden, ob diese Anforderungen bereits im Anforderungsdokument spezifiziert sind. Ist dies nicht der Fall, müssen diese Anforderungen ergänzt werden. Nach Regel 2 müssen Sie also zunächst für jede in der Nominalisierung verschleierte Funktionalität das entsprechende Vollverb identifizieren, wie „auswählen“, „ändern“, „aktualisieren“, und diese Funktionalitäten anschließend detailliert analysieren (vgl. Regel 6). Wäre für das Bibliothekssystem die „Rückgabe eines Leihobjektes“ bisher noch nicht spezifiziert, würde dies gleichzeitig auch die Einführung eines neuen Use-Cases „Leihobjekt zurückgeben“ bedeuten. Grundsätzlich ist es nicht unser Ziel, Nominalisierungen in Anforderungen ganz zu vermeiden oder zu verbieten.

Die Auflösung von Nominalisierungen resultiert meist in mehreren zusätzlichen Anforderungen.

Das Hinterfragen von Nominalisierungen deckt häufig auch einen komplett getilgten Use-Case auf.

Gehen Sie auf Nummer sicher: Versuchen Sie immer, Nominalisierungen aufzulösen und die hinter den Nominalisierungen verborgenen Prozesse durch Vollverben auszudrücken. Setzen Sie Nominalisierungen wirklich nur dann ein, wenn ■■ Ihre Entscheidung dafür fachlich motiviert ist, ■■ der Begriff an zentraler Stelle definiert ist und ■■ die Definition der Nominalisierung keinen Rraum für Interpretation lässt.

131

6 Das SOPHIST–REgelwerk Nominalisierungen werden u. a. auch dazu verwendet, um nicht den eigentlichen Prozess, sondern ein in den Prozess involviertes Ding oder Objekt zu beschreiben. Wenn Sie für den nominalisierten Begriff eine eindeutige Begriffsdefinition hinterlegt haben, spricht nichts dagegen, ihn auch in Ihren Anforderungen zu verwenden. Für das Bibliothekssystem wäre die Nominalisierung „Benachrichtigung“ ein solcher Kandidat, da die „Benachrichtigung“ im Kontext der obigen Beispielanforderungen ein Ding oder Objekt darstellt, das versendet werden soll.

Z. B. die „Benachrichtigung“

Achten Sie auf Signalwörter wie „zur Verfügung stellen“, „zu Ende bringen“ oder „zum Ausdruck bringen“

Wenn Sie Nominalisierungen zur Benennung eines Prozesses in Ihren Anforderungen verwenden, empfehlen wir Ihnen, diese durch das Postfix „-vorgang“ oder „-prozess“ zu ergänzen. Das kennzeichnet die Nominalisierung eindeutig als einen Prozess. So können Sie auch vermeiden, dass Sie den gleichen nominalisierten Begriff für verschiedene, voneinander abzugrenzende Sachverhalte verwenden, wie beispielsweise das mit einem Prozess zusammenhängende Objekt und den Prozess selbst.

Funktionsverbgefüge

Z. B. der „Benachrichtigungsvorgang“

Nicht selten werden zur Beschreibung von Systemfunktionalitäten auch sogenannte Funktionsverbgefüge verwendet. Funktionsverbgefüge sind Kombinationen aus inhaltsarmen Verben (machen, können, haben, sein, ...) und sinngebenden Substantiven. Regel 4: Lösen Sie Funktionsverbgefüge auf. Funktionsverbgefüge können einen kompletten Prozess verschleiern. Analysieren Sie das Funktionsverbgefüge und formulieren Sie für jede geforderte Funktionalität eine neue Anforderung, die das Systemverhalten durch ein „gutes“ Vollverb beschreibt.

Durch die enge Verbindung zwischen Verb und SubsWird der tantiv in Funktionsverbgefügen tritt der eigentliche Prozess durch ein FunktionsverbProzess vollkommen in den Hintergrund. Er wird gefüge ausgedrückt? Welcher konkrete erst dann offengelegt, wenn das FunktionsverbgeProzess steckt dahinter? füge hinterfragt und die für den Prozess wesentlichen Funktionalitäten durch Vollverben beschrieben werden.

In der Beispielanforderung „Nachdem ein Leihobjekt entliehen wurde, muss der Status des Leihobjektes eine Veränderung erfahren.“ verbirgt das Funktionsverbgefüge „eine Veränderung erfahren“ das unvollständig spezifizierte Vollverb „verändern“. Eine verbesserte Anforderung lautet z. B. „Nachdem ein Bibliothekskunde ein Leihobjekt entliehen hat, muss das Bibliothekssystem den Status des Leihobjektes in den Status „entliehen“ ändern.“

Was genau bedeutet „eine Veränderung In unserem REgelwerk haben wir die Auflösung von Funktionsverbgefügen als eine separate erfahren“? Regel aufgeführt, weil sie, ähnlich den Nominalisierungen, nach unserer Erfahrung häufig

mehrere Funktionalitäten gleichzeitig oder sogar einen kompletten Use-Case verschleiern. So kann in der Anforderung „Es sollten statistische Auswertungen zur Verfügung gestellt werden.“ das Funktionsverbgefüge „zur Verfügung stellen“ die Prozesse „Erstellen“, „Anzeigen“, „Drucken“, „Importieren“ etc. enthalten sein.

Was genau heißt „zur Verfügung stellen“?

132

6 Das SOPHIST–REgelwerk Funktionsverbgefüge finden häufig dann Anwendung, wenn das Hauptproblem eines Anforderungsstellers darin besteht, dass er selbst noch nicht genau weiß, was er in Zukunft wirklich braucht und will. Unser Bibliothekar weiß, dass er statistische Auswertungen benötigt, ist aber noch unsicher bezüglich der konkreten Ausgestaltung dieser Funktionalität. Dann ist es Ihre Aufgabe als Requirements-Engineer, den Anfordernden bei der Präzisierung und damit der Auseinandersetzung mit dieser Funktionalität zu unterstützen, indem er beispielsweise die fünf W-Fragen beantwortet (siehe Regel 6). Beispielsweise kann die Frage „In welcher Form müssen statistische Auswertungen zur Verfügung gestellt werden?“ zu der Aussage führen, dass statistische Auswertungen sowohl in elektronischer Form als auch als Papierausdruck vorliegen müssen. Ferner muss auch die Frage geklärt werden, aus welcher Quelle die statistischen Auswertungen stammen. Eine erste verbesserte Anforderung könnte folgendermaßen lauten: „Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten, statistische Auswertung erstellen, anzeigen und ausgeben zu können.“

Schritt 3: Zerlege in vereinzelte Anforderungssätze

... oder Stakeholder beschreiben einfach nur Prozesse, die sie nicht wirklich kennen.

Richtig! Das ist eine Nominalisierung, die nach Regel 3 noch tiefer analysiert werden muss.

Bis jetzt haben wir die in einer Anforderung geforderte Funktionalität identifiziert und in mindestens ein Vollverb transformiert. Unter Umständen hat das Aufdecken der geforderten Funktionalität dazu geführt, dass die ursprüngliche Anforderung nun mehrere Vollverben beinhaltet. Unterschiedliche durch Vollverben formulierte Funktionalitäten verlangen in der Regel aber auch unterschiedliche Zusatzinformationen, so dass (zumindest zu deren Analyse) mehrere Anforderungssätze daraus generiert werden sollten.

Reminder: Eine Anforderung kann aus einem oder mehreren Anforderungssätzen bestehen. Regel 5: Schreiben Sie für jedes Prozesswort genau einen Anforderungssatz. Jedes Prozesswort (Vollverb) wird in der Regel durch unterschiedliche Informationen (Satzbestandteile, wie Subjekt, Objekt und Ergänzungen) vollständig beschrieben. Identifizieren Sie die Prozesswörter (Vollverben) in der Anforderung und formulieren Sie für jedes identifizierte Prozesswort einen eigenen Anforderungssatz mit genau einem Vollverb.

Zerlegen wir beispielsweise die Anforderung aus dem Bibliothekssystem „Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten, die Daten eines neuen Kunden einzugeben und zu speichern.“, so resultieren hieraus folgende vereinzelte Anforderungssätze:

Wie viele Prozesswörter (Verben) sind in der Anforderung enthalten?

„Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten, die Daten eines neuen Kunden einzugeben.“ Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten, die eingegebenen Daten eines neuen Kunden zu speichern.“

133

6 Das SOPHIST–REgelwerk Vorteile sind: Anforderungen können besser priorisiert, bewertet und nachvollzogen werden. Nachteile sind: Zusammengehörige Informationen werden über mehrere Anforderungen verstreut und sind aufwändiger in der Verwaltung.

Die Vereinzelung hat nun dazu geführt, dass für jede geforderte Systemfunktionalität genau ein Satz gebildet wurde. Jeder Satz kann nun separat durch gezieltes Hinterfragen des enthaltenen Vollverbs systematisch analysiert werden (Regel 6). Weitere Informationen zum Vorgehen bei der Vereinzelung von Anforderungen finden Sie auf unserer Homepage, www.sophist.de.

Schritt 4: Prüfe Unvollständigkeiten in Prozesswörtern Um in einer Anforderung einen Prozess eindeutig zu beschreiben, ist es notwendig, dass alle zur vollständigen Erklärung des Prozesswortes (Vollverbs) erforderlichen Informationen in der Anforderung enthalten sind. Bleiben zum Prozess noch Fragen offen, so müssen die zugehörigen Informationen aufgedeckt und der Anforderung hinzugefügt werden. Regel 6: Analysieren Sie fehlende Informationen zum Prozesswort. Hinterfragen Sie das Prozesswort (Vollverb) der Anforderung mit den typischen W–Fragen. Wenn diese nicht alle durch die Informationen in der Anforderung beantwortet werden können, so wurde Information getilgt. Ist die fehlende Information wissenswert, ergänzen Sie die Anforderung um die getilgte Information.

Um sprachliche Effekte in Anforderungen zu beheben, stellt der Requirements-Engineer gezielte Fragen rund um das Prozesswort. Die Antworten auf diese Fragen liefern Informationen, die zur Beseitigung eines Defekts notwendig sind. Nach unserer Erfahrung sollten zumindest folgende Fragen diskutiert und in der Anforderung beantwortet werden:

Objekt: An wem oder was wird die Funktionalität ausgeführt?

Methode: Wie wird die Funktionalität ausgeführt (nicht technologisch, sondern fachlich)?

Häufigkeit: Wie oft wird die Funktionalität ausgeführt?

Zeit/Logisch: Wann bzw. unter welchen Randbedingungen wird die Funktionalität ausgeführt?

Anhand der Fragen zum Prozesswort lässt sich feststellen, ob dieses ausreichend spezifiziert ist oder eine Anforderung um weitere Informationen ergänzt werden muss.

134

6 Das SOPHISTâ&#x20AC;&#x201C;REgelwerk FĂźr die Anforderung â&#x20AC;&#x17E;Nicht zugelassene Kunden werden vom System angezeigt.â&#x20AC;&#x153; ist beispielsweise das Vollverb â&#x20AC;&#x17E;anzeigenâ&#x20AC;&#x153; zu hinterfragen. Einige Fragen lassen sich aus der Anforderung heraus mehr oder weniger beantworten. Zum Beispiel lautet die Antwort auf die Frage â&#x20AC;&#x17E;Was wird angezeigt?â&#x20AC;&#x153; vermutlich: â&#x20AC;&#x17E;eine Meldung Ăźber nicht zugelassene Kundenâ&#x20AC;&#x153;. Hingegen bleiben die Fragen â&#x20AC;&#x17E;Wem wird angezeigt?â&#x20AC;&#x153;, â&#x20AC;&#x17E;Wie wird angezeigt?â&#x20AC;&#x153;, â&#x20AC;&#x17E;Wann wird angezeigt?â&#x20AC;&#x153; und â&#x20AC;&#x17E;Wie oft wird angezeigt?â&#x20AC;&#x153; in der Anforderung unbeantwortet. Hier handelt es sich um sprachliche Effekte, die genauer analysiert werden mĂźssen. Sind die getilgten Informationen wesentlich, so muss die Anforderung um diese Informationen ergĂ¤nzt werden.

Was? Wem? Wie? Wann? Wie oft?

Nachdem die Antworten auf die Fragen eingearbeitet wurden, kĂśnnte die verbesserte Anforderung folgendermaĂ&#x;en lauten: â&#x20AC;&#x17E;Nachdem das Bibliothekssystem die Kundenkarte geprĂźft hat und falls der Kunde nicht zur Ausleihe des Leihobjektes zugelassen ist, muss das Bibliothekssystem dem Bibliothekar die Fehlermeldung â&#x20AC;&#x17E;Kunde nicht zugelassenâ&#x20AC;&#x153; anzeigen.â&#x20AC;&#x153; Ein weiteres Beispiel fĂźr eine effektbelastete Anforderung wĂ¤re: â&#x20AC;&#x17E;Der Benutzer muss suchen kĂśnnen.â&#x20AC;&#x153;. Auch bei dieser Anforderung bleiben zu dem Vollverb â&#x20AC;&#x17E;suchenâ&#x20AC;&#x153; eine Menge an Fragen offen, die durch die Anforderung beantwortet werden mĂźssen. Nach was bzw. nach welchem Objekt wird gesucht? Wie oft kann gesucht werden? Nach welchen Kriterien wird gesucht? Wann bzw. unter welchen Randbedingungen wird gesucht? Die Behebung der unvollstĂ¤ndig spezifizierten ProzesswĂśrter kann zu aufwĂ¤ndigen Umformulierungen der Anforderung fĂźhren. HĂ¤ufig resultieren aus den Antworten zu den Fragen aber auch zusĂ¤tzliche Anforderungen, oder man erkennt, dass die Originalanforderung durch mehrere detailliertere Anforderungen verfeinert und somit ersetzt werden muss.

Nach was? Wie oft? Nach welchen Kriterien? Wann?

Die vier Schritte zum PrĂźfen des Prozesses Fassen wir kurz zusammen. Entlang der in Abbildung 6.4 aufgezeigten Schritte haben Sie Ihre Anforderung(en) im Aktiv formuliert. Alle zu spezifizierenden FunktionalitĂ¤ten sind durch Vollverben beschrieben, wobei alle offenen Fragen zum Prozesswort beantwortet und in die Anforderungen eingearbeitet sind.

LĂśsen Sie nominalisierte Prozesse auf! DrĂźcken Sie schwammige ProzesswĂśrter durch Vollverben aus!

LĂśsen Sie FunktionsverbgefĂźge auf!

Schreiben Sie fĂźr jedes Vollverb genau eine(n) Anforderung(ssatz)!

Formulieren Sie jede Anforderung im Aktiv!

Analysieren Sie fehlende Informationen zu ProzesswĂśrtern!

Abbildung 6.4: Die vier Schritte zum PrĂźfen der Prozesse.

Dennoch befinden wir uns erst auf dem halben Weg zur perfekten Anforderung.

135

6 Das SOPHIST–REgelwerk 6.5.2

Prüfen von Eigenschaften Ähnlich den Prozessbeschreibungen muss auch die Beschreibung von Eigenschaften eindeutig und vollständig sein. Systemeigenschaften beziehen sich auf die Beschreibung nicht-funktionaler Aspekte des zu spezifizierenden Systems. In Anforderungen werden Eigenschaften in der Regel durch Adjektive und Adverbien ausgedrückt.

Eigenschaftswörter, wie z. B. groß, wichtig, verständlich, schnell

Umstandswörter, wie z. B. hier, gestern, anders

Für die Beschreibung von Systemeigenschaften reicht ein Adjektiv bzw. Adverb allerdings nicht aus. Eigenschaften müssen durch weitere Informationen ergänzt werden. Für das Adjektiv „sicher“ muss beispielsweise beschrieben werden, was vor wem oder was sicher sein muss, wer sichert und wie gesichert wird. Auch hier hilft Ihnen Ihr natürliches Sprachgefühl dabei, fehlende oder verzerrte Informationen aufzuspüren. Bei der Prüfung der Adjektive liegt Ihr Hauptaugenmerk auf der in einer Anforderung beschriebenen Systemeigenschaft. Das zu identifizierende Signalwort ist ein Adjektiv oder Adverb, also ein Wort, durch das eine Eigenschaft oder ein Umstand beschrieben wird.

Achten Sie auf Signalwörter wie „schnell“, „performant“, „groß“, „gering“

Schritt 1: Analysiere geforderte Eigenschaften Um die Eigenschaftsbeschreibung in einer Anforderung zu vervollständigen, müssen die für die Eigenschaft wesentlichen Informationen aufgedeckt und der Anforderung hinzugefügt werden (ähnlich Regel 6). Regel 7: Analysieren Sie fehlende Informationen zum Eigenschaftswort. Hinterfragen Sie das Eigenschaftswort (Adjektiv, Adverb) der Anforderung mit den typischen W–Fragen. Wenn diese nicht alle durch die Informationen in der Anforderung beantwortet werden können, so wurde Information getilgt. Ist die fehlende Information wissenswert, ergänzen Sie die Anforderung um die getilgte Information.

Für wen oder was wird die Eigenschaft gefordert? Wann bzw. unter welchen Rahmenbedingungen? ...

Für wen soll das Bibliothekssystem intuitiv bedienbar sein? Was genau muss intuitiv bedienbar sein?

Für die Anforderung „Das Bibliothekssystem muss intuitiv bedienbar sein“ muss beispielsweise die Eigenschaft „intuitiv bedienbar“ hinterfragt werden. Die sprachlichen Effekte müssen genauer analysiert und wesentliche Informationen der Anforderung beigefügt werden. Eine verbesserte (aber lange noch nicht effektfreie) Anforderung wäre beispielsweise: „Die Benutzeroberfläche des Bibliothekssystems muss für den Bibliothekar intuitiv bedienbar sein.“

Richtig! „Intuitiv bedienbar“ hat vollen Interpretationsspielraum und muss quantifiziert werden (vgl. Regel 8). 136

6 Das SOPHIST–REgelwerk Häufig finden wir nicht-funktionale Aspekte in funktionalen Anforderungen. Diese werden durch Adjektive beschrieben, die entweder als Attribut zu einem Nomen auftreten oder als Ergänzung zum Prozesswort (Adverb).

Z. B. etwas „schnell“ übertragen

Z. B. die „schnelle“ Übertragung

Um nicht-funktionale Aspekte in Anforderungen offenzulegen, extrahieren Sie diese zunächst aus der funktionalen Anforderung, um sie auch separat analysieren zu können. Die Anforderung „Ein schnelles Ausdrucken des Benutzerausweises ist erforderlich.“ wurde durch Anwendung der Regeln 1 bis 6 beispielsweise folgendermaßen umformuliert: „Nachdem das Bibliothekssystem die Registrierungsdaten eines neuen Bibliothekskunden gespeichert hat, muss das Bibliothekssystem den Benutzerausweis des neu registrierten Bibliothekskunden schnell ausdrucken.“ Die Forderung „schnelles Ausdrucken“ weist darauf hin, dass der Ausdruckprozess ein bestimmtes Zeitverhalten aufweisen muss. Daraus könnte zunächst die nicht-funktionale Anforderung “Das Bibliothekssystem muss das Ausdrucken des Benutzerausweises schnell durchführen.“ generiert werden. Klarerweise bleibt an dieser Stelle die Frage nach dem konkreten Zeitverhalten noch unbeantwortet: „Was genau bedeutet schnell?“. Zur Analyse solcher sprachlicher Effekte haben wir eine eigene Regel formuliert.

Achten Sie auf Signalwörter wie „besser“, „schneller“, „leichter“.

Achten Sie auf Signalwörter wie „am schnellsten“, „größte“, „geringste“.

Diese Regel besagt, dass Adjektive oder Adverbien in Anforderungen häufig Vergleiche (Komparative) oder Steigerungen (Superlative) ausdrücken. Für einen Vergleich oder eine Steigerung muss als Zusatzinformation aber immer der Bezugspunkt konkret spezifiziert sein. Für den Vergleich „schneller“ muss beispielsweise angeben werden, um wie viel etwas schneller als was sein muss oder wie schnell genau etwas sein muss.

RE-Bauernregel: "Schneller, besser, schöner, breiter...", frag stets " ... als was?", das wirkt gescheiter.

Regel 8: Formulieren Sie Vergleiche und Steigerungen mess– bzw. testbar. Vergleiche und Steigerungen benötigen zur vollständigen Beschreibung immer einen Bezugspunkt. Hinterfragen Sie den Bezugspunkt des Vergleichs bzw. der Steigerung und ergänzen Sie die Anforderung um die getilgte Information.

Eine Abweichung von der Forderung muss natürlich auch messbar und damit überprüfbar (testbar) sein. Dies bedeutet, dass die Messmethode bekannt sein sollte, damit schon beim Erstellen der Anforderungen klar ist, ob die Anforderung anschließend wirklich getestet werden kann.

In Bezug bzw. Vergleich zu wem bzw. was? Wie kann die Erfüllung bzw. Abweichung gemessen werden ?

In vielen Fällen ist es sinnvoll, sich bereits mit der Messgenauigkeit auseinanderzusetzen.

137

6 Das SOPHIST–REgelwerk Für die Anforderung „Das Bibliothekssystem muss die Benutzerdaten sicher verwalten.“ müssen Sie beispielsweise den Bezugspunkt für die Eigenschaft „sicher“ hinterfragen und das gewonnene Wissen in die Überarbeitung der Anforderung einfließen lassen.

■■ Sicher in Bezug zu was bzw. vor wem? ■■ Was macht Benutzerdaten sicher? ■■ Nach welchen Kriterien kann sicher bei der Abnahme getestet werden? Basierend auf den Antworten zu den Fragen könnte eine überarbeitete Anforderung dann folgendermaßen aussehen: „Das Bibliothekssystem muss so gestaltet sein, dass die in Standard X definierten Datenschutzrichtlinien eingehalten werden.“ Die Behebung der unvollständigen Vergleiche und Steigerungen gestaltet sich unterschiedlich schwierig. Im obigen Beispiel kann durch leichtes Modifizieren der Anforderung der Bezugspunkt hinzugefügt werden. Dagegen lässt sich im nächsten Beispiel die verwendete Phrase „intuitiv bedienbar“ nur schwer oder gar nicht messen: „Die Benutzeroberfläche des Bibliothekssystems muss für den Bibliothekar intuitiv bedienbar sein.“ Für diese Anforderung können aufwändige Umformulierungen erforderlich sein, die mit der Einführung neuer, messbarer Kriterien einhergehen. Zuerst muss allerdings einmal der Wunsch hinterfragt werden, der sich hinter der Formulierung „intuitiv bedienbar“ eines Stakeholders verbirgt.

■■ Intuitiv bedienbar in Bezug zu was? ■■ Was macht die Benutzeroberfläche intuitiv bedienbar? ■■ Welches Messkriterium kann bei der Abnahme angewendet werden? Hier kann es hilfreich sein, Eigenschaften in paradoxer Weise zu hinterfragen, z. B.: Wie muss das System gestaltet sein, damit es NICHT„intuitiv bedienbar“ ist?

Sicherlich hatte der Schreiber dieser Anforderung einige sehr konkrete Sachverhalte im Sinn. Beispielsweise kann hinter einer derartigen Formulierung der Wunsch nach einem Hilfesystem stecken, welches bei jeder Benutzerinteraktion konsultiert werden kann und in mehreren Detaillierungsebenen Auskunft über mögliche Eingabewerte, Folgen und Ausnahmebedingungen der Aktion gibt. Dahinter kann sich aber auch die Forderung nach einer Menüsteuerung, einem interaktiven Lernprogramm, nach Spracherkennung, nach Mehrsprachigkeit oder nach der Konformität mit gängigen Oberflächenstandards verbergen. Vielleicht liegt hinter der Anforderung aber auch lediglich folgender Wunsch: „Das Bibliothekssystems muss so gestaltet sein, dass der Bibliothekar jeden Ausleihvorgang innerhalb von „5 Klicks“ ausführen kann.“ Es lohnt sich auf jeden Fall, dies zu erkunden, und derartig defektbelastete Anforderungen durch detailliertere zu ersetzen.

Schritt 2: Prüfe Separierbarkeit nicht–funktionaler Anforderungen Nicht unbedeutend, aber häufig kaum beachtet ist die Trennung zwischen funktionalen und nicht-funktionalen Anforderungen. In der Projektrealität erleben wir häufig unterschiedliche Varianten. In manchen Projekten werden beide Anforderungsarten ganz strikt getrennt, was die Frage aufwirft, ob bei der Abnahme dann auch wirklich alle Anforderungen eigenständig getestet werden können. In anderen Projekten dagegen finden wir Spezifikationen vor, in denen in derselben Anforderung sowohl funktionale als auch nicht-funktionale Aspekte beschrieben werden. Wie so häufig im Leben muss man auch hier den goldenen Mittelweg finden.

138

6 Das SOPHISTâ&#x20AC;&#x201C;REgelwerk Regel 9: Formulieren Sie eigene Anforderungen fĂźr nichtâ&#x20AC;&#x201C;funktionale Aspekte. Trennen Sie nichtâ&#x20AC;&#x201C;funktionale Aspekte aus funktionalen Anforderungen, wenn mindestens eine der folgenden Bedingungen erfĂźllt ist: â&#x2013; â&#x2013; â&#x2013; â&#x2013;

Der nichtâ&#x20AC;&#x201C;funktionale Aspekt ist eigenstĂ¤ndig testbar, ODER Der nichtâ&#x20AC;&#x201C;funktionale Aspekt wird Ăźbergreifend als ein nichtâ&#x20AC;&#x201C;funktionales Constraint fĂźr mehrere FunktionalitĂ¤ten gefordert.

Die Entscheidung, ob funktionale und nicht-funktionale Ist die Aspekte getrennt werden sollten, gestaltet sich unterEigenschaft eingenstĂ¤ndig schiedlich schwierig. Beispielsweise wĂźrde man die Antestbar? Wird sie global forderung â&#x20AC;&#x17E;Das Bibliothekssystem muss die eingegebenen gefordert? neuen Benutzerdaten innerhalb von maximal 1 Sekunde speichern.â&#x20AC;&#x153; genau dann unverĂ¤ndert bestehen lassen, wenn die geforderte Zeitvorgabe nur fĂźr die spezifizierte FunktionalitĂ¤t, nĂ¤mlich das â&#x20AC;&#x17E;Speichern neuer Kundendatenâ&#x20AC;&#x153;, gelten soll. Das Separieren der Zeitvorgabe in eine eigene Anforderung wĂźrde keinen Sinn ergeben, da Sie die Zeitvorgabe bei der Abnahme niemals testen kĂśnnten, ohne dabei auch die FunktionalitĂ¤t auszufĂźhren. Andererseits kĂśnnte es sein, dass sich wĂ¤hrend der Analyse des nicht-funktionalen Aspekts â&#x20AC;&#x17E;innerhalb von maximal 1 Sekunde speichernâ&#x20AC;&#x153; herausstellen wĂźrde, dass diese Zeitvorgabe ein globales Constraint darstellt. Beispielsweise mĂźssen auch Stammdaten neuer Leihobjekte oder Ă&#x201E;nderungen von Benutzerdaten dieser Forderung entsprechen. Formulieren Sie in diesem Fall eine separate Anforderung: â&#x20AC;&#x17E;Das Bibliothekssystem muss jeden Speichervorgang innerhalb von maximal 1 Sekunde durchfĂźhren.â&#x20AC;&#x153;

Die zwei Schritte zum PrĂźfen von Eigenschaften Fassen wir weiter zusammen. Sie haben durch Einsatz der in Abbildung 6.5 aufgezeigten Schritte fehlende Informationen zu Eigenschaftsbeschreibungen aufgedeckt. Dabei haben Sie nicht-funktionale Aspekte (Eigenschaften) analysiert und qualifizierte Aussagen in messbare Anforderungen transformiert.

Formulieren Sie Vergleiche und Steigerungen mess- und testbar! Analysieren Sie fehlende Informationen zu Eigenschaften!

Formulieren Sie eigene Anforderungen fĂźr eigenstĂ¤ndig testbare und/oder global geltende nicht-funktionale Aspekte!

Abbildung 6.5: Die zwei Schritte zum PrĂźfen von Eigenschaften

139

6 Das SOPHIST–REgelwerk 6.5.3

Prüfen von Mengen und Häufigkeiten

Zur Vermeidung von Redundanzen formuliert man nicht für jede kleinste Einheit die eigentlich gleiche Anforderung mehrfach, sondern beschreibt ein Verhalten oder eine Eigenschaft nur einmal und weist dieser Beschreibung eine Gruppe von Sachverhalten zu, für die das Spezifizierte gültig sein soll. Wichtig ist allerdings, dass die Sachverhalte richtig zusammengefasst sind (siehe Transformationseffekt „Generalisierung“ in Abschnitt 6.2.2).

Z. B. „Kundenname speichern“, „Kundenadresse speichern“, … lässt sich durch „Registrierungsdaten eines Kunden speichern“ zusammenfassen.

Der Linguist sagt hierzu „Universalquantoren“ oder einfach nur „Quantoren“.

Signalworte, die auf eine Generalisierung von Wissen hinweisen, sind Zahl- und Mengenwörter sowie Substantive, durch die Akteure oder Objekte zusammengefasst werden. Die Prüfung von Mengen- und Häufigkeitsangaben zielt nicht darauf, Generalisierungen zu vermeiden. Eher geht es darum zu hinterfragen, ob ein Stakeholder eine Gruppe von Sachverhalten richtig zusammengefasst hat.

Schritt 1: Prüfe Zahl– und Mengenwörter RE-Bauernregel: Sei allzeit bereit für Quantoren wie "alle, keiner, jeder, nie ...", doch Obacht: Prüf sie erst, dann verwende sie.

Durch Anforderungen werden Funktionalitäten oder Eigenschaften spezifiziert, die für eine bestimmte Menge an Objekten gültig sein sollen. Hierzu verwendet man in der natürlichen Sprache Zahl- oder Mengenwörter. In einer Anforderung wird dann eine Aussage getroffen über das Verhalten oder die Eigenschaft dieser Menge von Objekten.

Achten Sie auf Signalwörter wie „alle“, „jeder/jeden“, „immer“, „kein“, … Die Anforderung „Das Bibliothekssystem muss es jedem Bibliothekskunden ermöglichen, jedes Leihobjekt auszuleihen.“ würde faktisch zu der Annahme führen, dass auch die jüngeren Bibliothekskunden solche Leihobjekte ausleihen dürfen, die laut Jugendschutzgesetz nicht an diese ausgegeben werden dürfen. Weiterhin können sich im Portfolio der Bibliothek auch Leihobjekte befinden, die nur zur Ansicht, nicht aber zur Ausleihe gedacht sind. Dass solche Leihobjekte dann tatsächlich an alle Bibliothekskunden ausgeliehen werden können, ist sicherlich nicht im Sinne der Bibliotheksverwaltung. An dieser Stelle hat der Bibliothekar falsch generalisiert. Die Gefahr bei der Verwendung von Zahl- oder Mengenwörtern besteht also darin, dass das spezifizierte Verhalten bzw. die Eigenschaft nicht für alle Objekte der bezeichneten Menge zutrifft. Häufig sind Elemente in der Menge enthalten, die einen Sonder- oder Ausnahmefall darstellen und für die das spezifizierte Verhalten falsch ist. Hier ist es Ihre Aufgabe als Requirements-Engineer, solche Ausnahmen durch gezieltes Hinterfragen der verwendeten Mengen- und Häufigkeitsangaben aufzudecken.

Hinterfragen Sie Zahl- oder Mengenwörter sehr gezielt, denn wenn Sie bei jeder Anforderung „Wirklich alle“, „wirklich jeder“ … hinterfragen, laufen Sie Gefahr, dass Ihre Stakeholder schnell die Geduld verlieren.

140

6 Das SOPHIST–REgelwerk Regel 10: Hinterfragen Sie verwendete Zahl– und Mengenwörter. Jedes geforderte Verhalten bzw. jede geforderte Eigenschaft muss für wirklich alle Objekte der angegebenen Menge und nur für die Objekte der angegebenen Menge gelten. Prüfen Sie die verwendeten Zahl– oder Mengenwörter der Anforderung. Wenn falsch zusammengefasst wurde, müssen Sie: ■■ ■■

Die Menge der Objekte einschränken, wenn nur ein Teil der Menge betroffen ist, ODER Die Menge der Objekte erweitern, wenn zusätzliche Objekte betroffen sind.

Häufig gibt es auch Ausnahmen, die Sie zusätzlich spezifizieren müssen.

In der Anforderung „Das Bibliothekssystem muss es jedem Benutzer ermöglichen, alle Benutzerdaten zu ändern.“ sollten die Mengenangaben „jedem Benutzer“ und „alle Benutzerdaten“ hinterfragt werden.

Muss wirklich jeder Benutzer die Benutzerdaten ändern können?

Gilt das Verhalten/die Eigenschaft für wirklich alle Objekte der Menge? Oder gibt es auch Ausnahmen?

Muss jeder Benutzer wirklich alle jemals im System abgespeicherten Benutzerdaten ändern können?

Falls sich bei der Beantwortung der Fragen herausstellen sollte, dass es Ausnahmefälle gibt, so müssen diese spezifiziert und die Ausgangsanforderung geändert werden: „Das Bibliothekssystem muss es jedem Bibliothekskunden ermöglichen, die über ihn gespeicherten Registrierungsdaten zu ändern.“ Auch Sätze, die keine explizite Mengen- oder Häufigkeitsaussage für das spezifizierte Verhalten oder die Eigenschaft angeben, sollten überprüft werden. Fehlende Angaben hierzu enthalten die implizite Annahme, dass das angegebene Verhalten für alle überhaupt relevanten Objekte immer gelten soll. Diese Annahme kann durchaus korrekt sein. Als Requirements-Engineer laufen Sie aber Gefahr, dass Ausnahmen übersehen werden. Regel 11: Klären Sie fehlende Zahl– und Mengenwörter. Für jedes geforderte Verhalten bzw. jede geforderte Eigenschaft muss die Menge der Objekte, für die das spezifizierte Verhalten bzw. die spezifizierte Eigenschaft gelten soll, explizit beschrieben sein. Prüfen Sie, ob der Anforderung Zahl– oder Mengenworte hinzugefügt werden können. Ist dies der Fall, müssen Sie prüfen, für welche Objekte genau die Anforderung gültig sein soll. Ergänzen Sie in der Anforderung das zugehörige Zahl– oder Mengenwort, falls erforderlich.

141

6 Das SOPHIST–REgelwerk Die Beispielanforderung „Das Bibliothekssystem muss es dem Benutzer ermöglichen, die gespeicherten Daten auf Band zu sichern.“ enthält beispielsweise keine expliziten Mengen- und Häufigkeitsangaben. Die Interpretation der Anforderung wäre daher, dass „jeder Benutzer jederzeit alle gespeicherten Daten auf jedes Band sichern kann“. Um aber sicherzustellen, dass die Angaben in dieser Anforderung inhaltlich korrekt sind, müssen die Mengen- und Häufigkeiten konkret hinterfragt und ggf. hinzugefügt werden.

Für welche Objekte genau soll das geforderte Verhalten bzw. die Eigenschaft gelten?

Darf jeder Benutzer die Sicherung einleiten? Über alle jemals gespeicherten Daten? Kann die Sicherung immer geschehen? Also auch mehrfach parallel? Der Realisierungsrahmen der oben definierten Anforderung liegt zwischen einer trivialen Sicherungssoftware für 1.000 €, die den Bibliothekar seine Daten auf Band kopieren lässt, und einer vollautomatischen Robotik-Sicherungsstation für mehrere Millionen Euro. Einen derartigen Sachverhalt sollte man dann vermutlich doch klarstellen, bevor das System beauftragt wird, sofern man bei seinem Auftragnehmer oder seiner Entwicklungsabteilung keine hellseherischen Fähigkeiten voraussetzt.

Verwenden Sie beispielsweise nur: „alle“, „jeder/jeden“, „immer“, „kein“ … Um die Eindeutigkeit zu gewährleisten und das Schreiben von Anforderungen zu erleichtern, oder „all “, „every“, empfiehlt es sich, die Menge der verwendeten Mengen- und Zahlwörter auf eine Anzahl eindeutig definierter Quantoren zu reduzieren. „each“, „none“ … Für die obige Beispielanforderung könnte die Analyse zu folgender Verbesserung führen: „Das System muss jedem Bibliothekar jederzeit die Möglichkeit bieten, alle im Bibliothekssystem aufgezeichneten Benutzer- und Leihobjektdaten als Sicherung auf Band zu speichern.“

Linguisten sprechen hier von „Substantiven ohne oder mit zu wenig Bezugsindex“. Achten Sie auf Signalwörter wie „der Anwender“, „die Meldung“, „die Daten“, „die Funktion“...

Schritt 2: Prüfe Unvollständigkeiten in Substantiven In einer Anforderung werden durch Substantive (Hauptwörter) sowohl Akteur(e) als auch Objekte repräsentiert, für die ein Verhalten bzw. die Eigenschaft gefordert wird. Häufig finden wir in Anforderungen aber Substantive, die Akteure oder Objekte so schwammig beschreiben, dass zu ihrer eindeutigen Spezifikation weitere Informationen erforderlich sind. Durch das Substantiv „Werte“ könnten beispielsweise alle Datenwerte zusammengefasst werden, die in irgendeiner Weise im System vorhanden sind und eingegeben werden können. In der Regel beschränkt sich eine Anforderung aber nur auf einen Teil dieser „Werte“. Zur vollständigen Erklärung muss also genau angegeben werden, auf welche „Werte“ genau sich die Anforderung bezieht. Regel 12: Hinterfragen Sie schwammige Substantive. Beschreibt ein Substantiv eine nicht genau einzugrenzende Menge von Objekten, so wurde aus dem Originalsatz eine Information getilgt. Hinterfragen Sie schwammig formulierte Substantive und stellen Sie fest, für welche Objekte oder Akteure genau diese Anforderung gelten soll. Ergänzen Sie dann die Anforderung um die getilgte Information.

142

6 Das SOPHISTâ&#x20AC;&#x201C;REgelwerk Der Bibliothekar berichtet beispielsweise: â&#x20AC;&#x17E;Die Daten mĂźssen dem Anwender grafisch dargestellt werden.â&#x20AC;&#x153; In dieser Anforderung mĂźssen zumindest die Substantive â&#x20AC;&#x17E;Datenâ&#x20AC;&#x153; und â&#x20AC;&#x17E;Anwenderâ&#x20AC;&#x153; detaillierter analysiert werden.

Wer/Was ... genau? Welcher Teil der genannten Menge?

Welche Daten genau?

Welchen Anwendern genau?

Die Analyse der Substantive kĂśnnte beispielsweise ergeben, dass sich â&#x20AC;&#x17E;Datenâ&#x20AC;&#x153; auf â&#x20AC;&#x17E;statistisch berechnete Daten der Leihobjekteâ&#x20AC;&#x153; beziehen und der Akteur â&#x20AC;&#x17E;Anwenderâ&#x20AC;&#x153; auf den â&#x20AC;&#x17E;Bibliothekarâ&#x20AC;&#x153; eingeschrĂ¤nkt wird. Eine verbesserte Anforderung zu dem obigen Beispiel wĂ¤re dann: â&#x20AC;&#x17E;Nachdem der Bibliothekar die Berechnung der Leihobjektstatistik initiiert hat, muss das Bibliothekssystem dem Bibliothekar alle statistisch berechneten Daten der Leihobjekte grafisch anzeigen.â&#x20AC;&#x153; Diese Umformulierung setzt natĂźrlich voraus, dass es weitere Anforderungen gibt, die den Prozess â&#x20AC;&#x17E;Berechnung der Leihobjektstatistikâ&#x20AC;&#x153; detailliert beschreiben und dass auch wirklich alle statistisch berechneten Daten der Leihobjekte grafisch dargestellt werden kĂśnnen.

Was genau bedeutet â&#x20AC;&#x17E;grafischâ&#x20AC;&#x153;? Welche Daten der Leihobjekte genau? Des Weiteren muss natĂźrlich auch das Adjektiv â&#x20AC;&#x17E;grafischâ&#x20AC;&#x153; prĂ¤ziser beschrieben werden. HĂ¤ufig resultiert aus diesen Fragen eine Verfeinerung der Anforderung, beispielsweise dann, wenn aus den Antworten hervorgeht, dass fĂźr die unterschiedlichen statistischen Leihobjektdaten auch unterschiedliche grafische Darstellungen gefordert werden.

Die zwei Schritte zum PrĂźfen von Mengen und HĂ¤ufigkeiten Nun haben Sie es bald geschafft. Nachdem Sie die in Abbildung 6.6 aufgezeigten Schritte absolviert haben, haben Sie sprachliche Effekte in Bezug auf Mengen- und HĂ¤ufigkeitsangaben identifiziert und behoben. Hierzu haben Sie Zahl- und MengenwĂśrter sowie schwammige Substantive dahingehend geprĂźft, ob Objekte oder Akteure durch diese richtig zusammengefasst wurden.

Hinterfragen Sie fehlende Zahl- und MengenwĂśrter!

KlĂ¤ren Sie die Korrektheit von verwendeten Zahl- und MengenwĂśrtern!

Analysieren Sie fehlende Informationen zu Substantiven!

Abbildung 6.6: Die zwei Schritte zum PrĂźfen von Mengen und HĂ¤ufigkeiten

Nun sind Sie nur noch wenige Schritte von der nahezu â&#x20AC;&#x17E;perfektenâ&#x20AC;&#x153; Anforderung entfernt.

143

6 Das SOPHIST–REgelwerk 6.5.4

Prüfen von Begriffen, die Möglichkeiten beschreiben

Oft ist es nicht nur notwendig, eine Funktion des Systems durch eine Anforderung einfach zu fordern, sondern auch, den Weg zu beschreiben, wie das System die Forderung erfüllen soll und welche Mittel dazu verwendet werden sollen. Dies gilt insbesondere für fachlich komplexe Abläufe, die so genannte Geschäftslogik.

Im Englischen: Business Logic Uups, wie soll ein Implementierer, der nicht nebenbei noch Flugsicherungsexperte ist, wissen, wie diese zu berechnen ist?

Schritt 1: Prüfe Mögliches und Unmögliches Wir erleben häufiger, dass Anforderungen nur die Ergebnisse komplexer Berechnungen spezifizieren, zum Beispiel: „... Bei jedem Radar-Update muss die Flugplanroute neu berechnet werden.“ Oftmals reicht es einfach nicht aus, nur zu fordern, dass gewisse Ergebnisse ermittelt werden, sondern die Anforderungsspezifikation muss auch die Details enthalten, welche fachliche Geschäftslogik hinter der Ermittlung bestimmter Ergebnisse steht. Signalwörter, die auf eine getilgte Fachlogik hinweisen, sind Begriffe, die ausdrücken, dass etwas möglich oder unmöglich sein soll.

Der Linguist sagt hierzu „Modaloperatoren der Möglichkeit“ Hinterfragen Sie die fachliche Logik, nicht die technische Lösung!

Achten Sie auf Signalwörter wie „kann“, „darf“, „es ist (nicht) möglich“, „er/sie/es ist außerstande“.

Achten Sie immer darauf, dass die Beschreibung der fachlichen Logik (die unweigerlich zu der Fragestellung „Wie“ führt) nicht gleichzusetzen ist mit der Beschreibung von Implementierungsdetails. Insbesondere bei der Formulierung fachlicher Anforderungen (Spezifikationslevel 2 und 3) sollten Implementierungsdetails (wie beispielsweise der Einsatz einer bestimmten Datenbank, ...) nicht beschrieben werden, außer wenn diese auch ausdrücklich gefordert werden (zum Beispiel aus Wartungsgründen). Regel 13: Klären Sie Mögliches und Unmögliches.

Durch Hinterfragen von Möglichem und Unmöglichem finden Sie vergessene Vorbedingungen.

Aussagen, die nur beschreiben, dass ein Verhalten möglich oder unmöglich sein soll, tilgen die mit der Forderung verbundene fachliche Logik. Hinterfragen Sie, was das geforderte Verhalten oder die Eigenschaft möglich oder unmöglich macht und ergänzen Sie die Anforderung um die identifizierte fachliche Logik.

Wenn in einer Anforderung Begriffe verwendet werden, die ausdrücken, dass etwas möglich oder unmöglich sein soll, können Anforderungen fast immer in das sprachliche Konstrukt „Etwas verhindert bzw. macht es möglich, dass etwas anders möglich oder unmöglich ist.“ umformen. In der Anforderung eines Stakeholders wird häufig aber nur der letztere Satzteil expliziert. Der vordere Satzteil (der Begründungssatz) bleibt dann unbeantwortet. Dann wurde die Voraussetzung, die das geforderte Verhalten überhaupt erst möglichen oder unmöglich macht, getilgt. Prüfen Sie deshalb immer, ob alle relevanten Voraussetzungen bzw. Vorbedingungen notiert sind.

Was macht das Verhalten möglich/unmöglich? Welche fachliche Logik steckt dahinter? Welche Vorbedingung muss gelten?

144

6 Das SOPHISTâ&#x20AC;&#x201C;REgelwerk Hierzu eine Beispielanforderung aus dem Bibliothekssystem: â&#x20AC;&#x17E;An einen Bibliothekskunden, fĂźr den noch mindestens zwei offene Mahnungen vorliegen, darf kein weiteres Buch ausgeliehen werden.â&#x20AC;&#x153; Zur Umsetzung dieser Anforderung muss das System auf eine Information zugreifen kĂśnnen, die Ăźber die offenen Mahnungen eines Bibliothekskunden Auskunft gibt. Aber woher kommt diese Information?

Wodurch wird dies unmĂśglich? Woher erhĂ¤lt das System das Die Antworten auf diese Fragen kĂśnnen, falls noch nicht notiert, zusĂ¤tzliche Anforderungen erforderliche Wissen? erfordern. Durch diese wird Ăźberhaupt erst die Voraussetzung fĂźr die obige Anforderung expliziert, nĂ¤mlich die Verwaltung einer Mahnhistorie fĂźr jeden Bibliothekskunden: â&#x20AC;&#x17E;Sobald der RĂźckgabetermin fĂźr ein Leihobjekt erreicht ist, muss das Bibliothekssystem fĂźr den Bibliothekskunden, der das Leihobjekt ausgeliehen hat, die Anzahl der offenen Mahnungen in der Mahnhistorie des Bibliothekskunden um 1 erhĂśhenâ&#x20AC;&#x153;. Basierend auf dieser Funktionsbeschreibung wird nun klarer, wie das System beim Entleihvorgang die Anzahl noch offener Mahnungen ermitteln kann: â&#x20AC;&#x17E;Nachdem der Bibliothekar das Ausleihen eines Leihobjektes fĂźr einen Bibliothekskunden initiiert hat und falls fĂźr den Bibliothekskunden noch mindestens zwei offene Mahnungen in seiner Mahnhistorie existieren, muss das System dem Bibliothekar die Fehlermeldung â&#x20AC;&#x17E;noch offene Mahnungenâ&#x20AC;&#x153; anzeigen.â&#x20AC;&#x153; Auch die Bibliothekssystem-Anforderung â&#x20AC;&#x17E;Es darf nicht mĂśglich sein, dass ein neuer Bibliothekskunde registriert wird, der jĂźnger als 18 Jahre ist und keine EinverstĂ¤ndniserklĂ¤rung der Eltern vorlegen kann.â&#x20AC;&#x153; sollte durch die Zusatzinformation ergĂ¤nzt werden, wie das System diese Forderung erfĂźllen soll. Sicherlich hat der Stakeholder eine sehr konkrete Vorstellung davon, wie die Neuregistrierung eines Kunden geregelt werden soll. Eine verbesserte Anforderung wĂ¤re daher: â&#x20AC;&#x17E;Nachdem der Bibliothekar das Speichern neuer Kundendaten initiiert hat und falls der neu eingegebene Kunde ein Alter von unter 18 Jahren hat und falls keine EinverstĂ¤ndniserklĂ¤rung vorliegt, muss das Bibliothekssystem dem Bibliothekar die Fehlermeldung â&#x20AC;&#x17E;Kunde unter 18â&#x20AC;&#x153; anzeigen.â&#x20AC;&#x153;

Durch wen oder was wird das verhindert? Welche fachliche Logik steckt dahinter?

Diese Aussage ist schon ein StĂźck klarer, doch nach wie vor mit Effekten behaftet. Die Zusatzinformation, wie das Bibliothekssystem wissen kann, ob eine EinverstĂ¤ndniserklĂ¤rung vorliegt oder nicht, fĂźhrt uns natĂźrlich zur wiederholten Anwendung dieser Regel und wahrscheinlich zu folgender Anforderung: â&#x20AC;&#x17E;Falls der neu eingegebene Kunde ein Alter von unter 18 Jahren hat, muss das Bibliothekssystem dem Bibliothekar die MĂśglichkeit bieten, das Vorhandensein einer EinverstĂ¤ndniserklĂ¤rung zu bestĂ¤tigen.â&#x20AC;&#x153;

Der Schritt zum PrĂźfen von MĂśglichkeiten und UnmĂśglichkeiten Nachdem Sie nun den in Abbildung 6.7 aufgezeigten Schritt durchgefĂźhrt haben, haben Sie der Anforderung noch die fehlende fachliche Logik hinzugefĂźgt (falls dies erforderlich war) und sie von wesentlichen sprachlichen Defekten bereinigt.

Analysieren Sie die hinter der Anforderung steckende fachliche Logik!

Analysieren Sie notwendige Vorbedingungen!

Abbildung 6.7: Ein Schritt zum PrĂźfen von MĂśglichkeiten und UnmĂśglichkeiten

145

6 Das SOPHIST–REgelwerk

6.6

Prüfen des Satzes Nach der Prüfung anhand einzelner Satzbestandteile wenden wir uns jetzt ganzen Anforderungssätzen zu.

Schritt 1: Extrahiere unwesentliche Nebensätze Die einzigen Nebensätze, die für eine Anforderung notwendig sind, sind logische oder zeitliche Bedingungssätze (siehe dazu auch Kapitel 7 „Schablonen“).

Achten Sie auf Signalwörter wie „weil“, „damit“, „um“, „deshalb“, „so dass“…

Nebensätze, die eine Begründung, Absicht oder Folge enthalten, sollten aus der eigentlichen Anforderung eliminiert und als Kommentar notiert werden. Sie sind für die eigentliche Systembeschreibung überflüssig und führen nur zu Verwirrungen und im schlimmsten Fall zu Missverständnissen. Regel 14: Extrahieren Sie unbedeutende Informationen. Nebensätze, die eine für die Systembeschreibung unwesentliche Information beschreiben, wirken sich negativ auf die Lesbarkeit aus und lassen die konkret geforderte Systemanforderung in den Hintergrund treten. Prüfen Sie den Informationsgehalt eines Nebensatzes. Ist die Information für die Systembeschreibung unwesentlich, dann: ■■

Lösen Sie den Nebensatz aus der Anforderung heraus UND

■■

Notieren sie ihn als „Kommentar“ zur Anforderung.

Welche Relevanz hat die Information im Nebensatz?

Die folgende Beispielanforderung aus unserem Bibliothekssystem zeigt eine Anforderung, wie wir sie nur allzu häufig in Spezifikationen vorfinden: „Um dem Bibliothekar das Erstellen einer Leihobjekt-Statistik zu erleichtern, muss das Bibliothekssystem die Verwendung eines virtuellen Assistenten anbieten.“

Das ist die fachliche Begründung für die Anforderung — aber eine unwesentliche Information für die Systembeschreibung. Obwohl der Nebensatz „Um ... zu erleichtern“ einen Sachverhalt beschreibt, der beispielsweise zur Entscheidungsfindung für die Umsetzung der Anforderung wesentlich sein kann, stellt er keine geforderte Funktionalität des Systems dar. Dieser Nebensatz sollte daher als Kommentar aus der Anforderung herausgezogen werden. Die obige Anforderung lautet dann umformuliert: „Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten, eine Leihobjekt-Statistik mit Hilfe eines virtuellen Assistenten zu erstellen.“ Der verbleibende Nebensatz, durch den lediglich die Begründung für die Anforderung beschrieben wird, wird als Kommentar zur entsprechenden Anforderung formuliert: „Kommentar: Dadurch wird dem Bibliothekar das Erstellen der Leihobjekt-Statistik erleichtert.“

146

6 Das SOPHISTâ&#x20AC;&#x201C;REgelwerk Falls sich allerdings etwas fĂźr den Systemkontext Wesentliches hinter diesem Nebensatz verbergen sollte, muss dieser Sachverhalt als eine separate Anforderung notiert werden.

Schritt 2: Beseitige redundante Informationen Oft ist uns gar nicht bewusst, dass wir SĂ¤tze bilden, in denen redundante Informationen stecken. FĂźr die verbale Kommunikation zwischen Menschen ist dies oft erheiternd oder sinnvoll, Anforderungen jedoch werden dadurch unnĂśtig kompliziert. Regel 15: Vermeiden Sie redundante Informationen. Entfernen oder kĂźrzen Sie alle Teile des Satzes, die Sie ohne Bedeutungsverlust straffen kĂśnnen: â&#x2013; â&#x2013; â&#x2013; â&#x2013;

Redundante Informationen Floskelhafte WĂśrter und Wendungen

klein in der GrĂśĂ&#x;e => klein gelb in der Farbe => gelb eine wahre Tatsache => eine Tatsache

Wird etwas doppelt oder mit Floskeln ausgedrĂźckt?

Viele Anforderungen kĂśnnen Sie ohne Informationsverlust straffen. Die Anforderung aus dem Bibliothekssystem: â&#x20AC;&#x17E;FĂźr den Fall, dass das Bibliothekssystem zusammen mit dem Bestellserver interoperiert, muss die FunktionsfĂ¤higkeit des Bibliothekssystems fĂźr die Benutzer mit der gleichen FunktionalitĂ¤t erhalten bleiben.â&#x20AC;&#x153; lĂ¤sst sich beispielsweise durch folgende Formulierung straffen: â&#x20AC;&#x17E;Solange das Bibliothekssystem mit dem Bestellserver interoperiert, muss das Bibliothekssystem die uneingeschrĂ¤nkte FunktionsfĂ¤higkeit fĂźr den Benutzer sicherstellen.â&#x20AC;&#x153;

Die beiden Schritte zum PrĂźfen des Satzes Herzlichen GlĂźckwunsch. Nachdem Sie die in Abbildung 6.8 aufgezeigten Schritte durchgefĂźhrt haben, haben Sie nicht nur sĂ¤mtliche semantischen Effekte in Ihrer Anforderung erkannt und behoben, sondern die Anforderung auch von unnĂśtigem Ballast befreit.

KlĂ¤ren Sie die Relevanz von NebensĂ¤tzen!

PrĂźfen Sie auf redundante Informationen und Floskeln!

Abbildung 6.8: Die zwei Schritte zum PrĂźfen des Satzes

147

6 Das SOPHIST–REgelwerk

6.7

Prüfen des Gesamtbildes So, nun begeben wir uns noch eine Stufe höher und betrachten nicht nur den einzelnen Satz, sondern dessen Integration in die Gesamtspezifikation.

Schritt 1: Prüfe Ausnahmen vom Normalverhalten Um die Funktionalität eines Systems vollständig zu beschreiben, müssen Anforderungen sowohl das gewünschte Normalverhalten als auch das Verhalten im Ausnahmefall – sofern dieser auftreten kann – beschreiben. Beim Schreiben einer Anforderung sollten Sie sich grundsätzlich fragen, ob das System das geforderte Verhalten immer sicherstellen kann oder ob es Randbedingungen gibt, unter denen dies nicht möglich ist.

Der Linguist sagt hierzu „Modaloperatoren der Notwendigkeit“.

Wenden Sie diese Suchmethode verstärkt auf die frei formulierten Anforderungen an.

Leider sind Systeme in der Realität von äußeren Einflüssen abhängig, so werden zum Beispiel Daten und Ereignisse für die Weiterverarbeitung erwartet, die eventuell ausbleiben können. Beschreiben Sie das Verhalten des Systems in derartigen Ausnahmefällen, die es nicht selbst beheben kann. Solche Anforderungen erkennen Sie häufig an Begriffen, die ausdrücken, dass etwas notwendig sein muss.

Achten Sie auf Signalwörter wie „müssen“, „sollen“, „sollte“, „es ist notwendig“, ... Für Anforderungen, die mit Hilfe unserer Anforderungsschablonen formuliert wurden (vgl. Kapitel 7 „Schablonen“), die also bewusst solche Modaloperatoren als Schlüsselwörter zur Festlegung der rechtlichen Verbindlichkeit enthalten, wird die Suche nach Modaloperatoren natürlich erfolgreich ausfallen. Regel 16: Klären Sie Ausnahmen vom Normalverhalten. Jedes Normalverhalten benötigt häufig auch die Beschreibung dessen, was passieren soll, wenn das System das Verhalten nicht sicherstellen kann. Klären Sie, ob es Situationen gibt, in denen das System das Normalverhalten nicht gewährleisten kann. Ist dies der Fall, dann: ■■

Beschreiben Sie entweder das Ausnahmeverhalten durch eine zusätzliche Anforderung, ODER

■■

Erweitern Sie die bestehende Anforderung um das Ausnahmeverhalten.

Die Anforderung „Das Bibliothekssystem muss BestellunKann das gen für neue Leihobjekte an das Versandsystem versenSystem das geforderte Verhalten den.“ fordert ein Verhalten, welches den Normalfall immer sicherstellen? Was passiert, betrachtet, dass Daten an ein Nachbarsystem geliefert wenn nicht? Welche Ausnahmen sind werden müssen. Einige Fragen bezüglich möglicher möglich? Ausnahmefälle bleiben jedoch offen. Was passiert, wenn die Verbindung zum Versandsystem nicht hergestellt werden kann und

148

6 Das SOPHIST–REgelwerk somit keine Daten versendet werden können? Was passiert, wenn während der Datenübertragung Fehler aufgetreten sind? Welches Verhalten wird also vom System erwartet, wenn die geforderte Funktionalität systemisch nicht geleistet werden kann? Soll es einfach kommentarlos abstürzen? Wahrscheinlich erwarten Sie eher, dass es ein definiertes Verhalten aufweist. Zum Beispiel sollen mögliche Probleme während der Datenübertragung dem Benutzer über die Benutzungsschnittstelle angezeigt werden, so dass dieser auch eine Neuübertragung veranlassen kann. Nach Beantwortung der Fragen kann für die Anforderung das Verhalten im Ausnahmefall spezifiziert werden: „Falls das Bibliothekssystem aus technischen Gründen keine Verbindung zum Versandsystem herstellen kann, muss das System dem Bibliothekar die Fehlermeldung „Verbindung kann nicht hergestellt werden“ anzeigen.“ Die Beschreibung von Anforderungen in Ausnahmesituationen wird häufig vernachlässigt. Eine vollständige Definition des Systemverhaltens in Ausnahmefällen kann den identischen Aufwand bedeuten wie die Definition des Systemverhaltens für die Normalfälle. Das wird gerne unterschätzt. Kalkulieren Sie diesen Aufwand daher frühzeitig mit ein. Wir erleben es in unserer Projektpraxis nur allzu häufig, dass die Definition des Verhaltens in Ausnahmesituationen aus Zeitgründen unterlassen oder nur angerissen wird. Im schlimmsten Falle resultiert dann ein System, welches bei minimalen Störungen der Umgebung ein unkalkulierbares Verhalten aufweist.

Spezifizieren Sie mögliche Ausnahmefälle sofort bei der Ermittlung der Benutzeranforderungen (ab Spezifikationslevel 2).

Schritt 2: Prüfe unvollständig spezifizierte Bedingungen Ähnlich der Spezifikation von Ausnahmefällen (siehe vorhergehende Regel), die das Systemverhalten in Situationen beschreiben, in denen das System das geforderte Verhalten nicht sicherstellen kann, müssen auch alle (häufig komplexen) Bedingungsstrukturen des „Normalverhaltens“ spezifiziert werden. Anforderungen, die Bedingungen enthalten, geben das Verhalten bei Gültigkeit bzw. Eintritt der Bedingung an. Wichtig ist, dass dann auch beschrieben ist, was passieren soll, wenn die Bedingung nicht eintritt. Nach unserer Erfahrung wird aber letztere Information bei der Systemspezifikation häufig vernachlässigt.

Achten Sie auf Signalwörter wie „wenn ... dann“, „falls ... dann“, „im Falle von“ und „abhängig von“.

Regel 17: Analysieren Sie unvollständige Bedingungsstrukturen. Jedes bedingte Verhalten benötigt zumindest auch die Beschreibung dessen, was passieren soll, wenn die Bedingung nicht eintritt. Klären Sie das Systemverhalten für den Fall (oder die Fälle), dass die Bedingung nicht erfüllt ist: ■■

Spezifizieren Sie für jede noch nicht beschriebene Bedingung eine zusätzliche Anforderung, ODER

■■

Erweitern Sie die bestehende Anforderung um die fehlenden Fälle.

149

6 Das SOPHIST–REgelwerk

Wie soll sich das System verhalten, wenn die Bedingung nicht eintritt? Gibt es noch weitere Fälle?

Welches Systemverhalten wird für den Fall gefordert, dass das Leihobjekt reserviert ist?

Bei der Anforderung aus dem Bibliothekssystem: „Falls ein Leihobjekt nicht reserviert ist, muss das Bibliothekssystem dem Bibliothekar die Fortsetzung des Ausleihprozesses ermöglichen.“ bleibt mindestens die Frage nach dem Systemverhalten im Falle eines reservierten Leihobjekts unbeantwortet.

Für unser Bibliothekssystem würde die Klärung der Frage nach dem Systemverhalten im Falle eines „reservierten Leihobjektes“ nur dann zu einer Erweiterung führen, wenn das entsprechende Systemverhalten bisher noch nicht beschrieben wurde. In diesem Fall muss das Systemverhalten für den Nichteintritt der Bedingung, beispielsweise durch eine zusätzliche Anforderung, beschrieben werden: „Falls das Leihobjekt reserviert ist, muss das Bibliothekssystem dem Bibliothekar eine Fehlermeldung anzeigen.“

Schreiben Sie separate Anforderungen, wenn es viele zu unterscheidende Fälle gibt. Ansonsten erweitern Sie einfach die bestehende Anforderung. Alternativ können Sie natürlich auch die bestehende Anforderung ergänzen: ■■ „Nachdem das Bibliothekssystem die Entleihbarkeit des Leihobjektes geprüft hat und falls das Leihobjekt nicht reserviert ist, muss das Bibliothekssystem dem Bibliothekar die Möglichkeit bieten, den Ausleihprozesses fortzusetzen.“ ■■ „Falls das Leihobjekt reserviert ist, muss das Bibliothekssystem dem Bibliothekar die Fehlermeldung „Leihobjekt reserviert“ anzeigen.“ Wichtig ist vor allem, dass Sie alle Fälle unterscheiden und das geforderte Systemverhalten auch für alle Fälle beschreiben. Leider lassen sich die Fallunterscheidungen nicht immer einfach nur in zwei Kategorien (erfüllt/nicht erfüllt bzw. reserviert/nicht reserviert) einteilen. Häufig kommt es vor, dass eine genauere Fallunterscheidung getroffen werden muss. Als Beispiel prüfen wir eine Anforderung aus unserem Bibliothekssystem: „Nachdem das Bibliothekssystem den Bibliothekskunden identifiziert hat und falls für den Bibliothekskunden höchstens eine offene Mahnung existiert oder falls für den Bibliothekskunden zum Zeitpunkt der Ausleihe weniger als 24 noch ausgeliehene Leihobjekte registriert sind, muss das Bibliothekssystem dem Bibliothekar die Möglichkeit bieten, das zu entleihende Leihobjekt anzugeben.“

Welches Systemverhalten wird für den Fall gefordert, dass für den Bibliothekskunden mindestens zwei Mahnungen existieren?

Welches Systemverhalten wird für den Fall gefordert, dass der Bibliothekskunde mindestens 25 Leihobjekte ausgeliehen und noch keines zurückgegeben hat?

Für diese Anforderung müssen gleich mehrere Fragen geklärt und im Anforderungsdokument beschrieben werden. Die Analyse dieser Fallunterscheidung kann zu sehr komplexen Anforderungen führen. Wie komplex Anforderungen sein können, zeigt sich, wenn beim letzten Beispiel noch die Bedingungen hinzukommen „Das Bibliothekssystem muss den Bibliotheksausweis eines Bibliothekskunden zerstören, falls für diesen mehr als fünf offene Mahnungen existieren.“ und „Das Bibliothekssystem muss dem Bibliothekar eine

150

6 Das SOPHIST–REgelwerk Warnmeldung anzeigen, falls für den Bibliothekskunden eine „beschädigte Rücklieferung“ registriert ist.“

Oder verwenden Sie Aufzählungszeichen für die einzelnen Fälle (wie im obigen Diese können dabei helfen, komplexe Bedingungsstrukturen übersichtlich darzustellen. Im Beispiel). Bedingte Anforderungen können extrem komplex werden, so dass sie mittels der natürlichen Sprache nur sehr unübersichtlich beschrieben werden können. Hier sollten Sie auf geeignetere Darstellungsmittel, wie beispielsweise eine Entscheidungstabelle (siehe Kapitel 10 „Prüftechniken für Anforderungen“), zurückgreifen. Rahmen der Vollständigkeitsprüfung sind sie in der Regel das Mittel der Wahl, um nicht beschriebene Varianten von Aktionen oder Bedingungen ausfindig zu machen.

Schritt 3: Prüfe implizite Annahmen Viele Sachverhalte des zu beschreibenden Systems sind gerade dem fachlich erfahrenen Stakeholder so selbstverständlich, dass er sie bei der Ermittlung von Anforderungen erst gar nicht mehr kommuniziert. Auch in anderen Anforderungsquellen, wie z. B. Dokumenten, sind diese Sachverhalte häufig nicht zu finden. Sie werden als bekannt vorausgesetzt oder man scheut sich davor, solche vermeintlich banalen Sachverhalte niederzuschreiben. Wir bezeichnen das als Muskelgedächtnis.

D. h. dem Stakeholder ist nicht mehr aktiv bewusst, über welches umfassende Wissen er verfügt. Spätestens bei der Umsetzung der Anforderungen in ein Produkt müssen diese implizit enthaltenen Annahmen aber explizit formuliert werden (Qualitätskriterium der Vollständigkeit, vgl. Kapitel 1 „In medias RE“), da ansonsten die angemessene Funktionsfähigkeit des Systems gefährdet ist.

Implizite Annahmen (Präsupposition) sind getilgte Aussagen, die wahr sein müsssen, damit andere Aussagen (Anforderungen) überhaupt einen Sinn ergeben. Hier hilft nur noch: ■■ Sichtenbildung bei der UseCase-Methodik ■■ Geeignete ErmittlungsWenn aber auch nur die kleinste Information in den Anforderungen zu finden ist, die auf techniken eine implizite Annahme hinweist, so können Sie diese durch das SOPHIST-REgelwerk aufdecken. Um Sie dabei zu unterstützen, haben wir unsere Erfahrung zum Auffinden impliziter ■■ Logischer MenAnnahmen in eine weitere, relativ einfache Regel gegossen: schenverstand Im Prinzip decken Sie durch alle beschriebenen Regeln gewisse implizite Annahmen auf, beispielsweise durch die Analyse von Nominalisierungen oder Mengen- und Häufigkeitsangaben. Werden allerdings ganze Sachverhalte oder Teile eines Systems verschwiegen, sind implizite Annahmen nur sehr schwer zu entdecken. In unserer Projektpraxis stoßen wir daher häufig auch an gewisse Grenzen.

151

6 Das SOPHIST–REgelwerk

Regel 18: Analysieren Sie implizite Annahmen.

Achten Sie auf Signalwörter wie „Falls“, „Nachdem“, „Sobald“, „Wenn“ ...

Anforderungen beinhalten häufig eine (meist nur nebenbei erwähnte) Aussage, die wahr sein muss, so dass die eigentliche Anforderung überhaupt erst erfüllt werden kann. Solche Aussagen bilden dann Ihre Signalwörter, die auf implizite Annahmen hinweisen, wie z.B. ■■ ■■

Zeitliche/logische Ablaufbeschreibungen Substantive, die durch ein Bezugswort genauer beschrieben werden.

Prüfen Sie implizite Annahmen durch Anwendung der folgenden Schritte:

Achten Sie auf Signalwörter, wie „eingegebene Benutzerdaten“, „angezeigte View“, „berechneter Kapitalwert“ ...

■■ ■■ ■■

Identifizieren Sie in Ihrer Anforderung das Signalwort, das auf eine implizite Annahme hinweist. Prüfen Sie, welche Funktionalität sich hinter dem Signalwort verbirgt. Prüfen Sie, ob diese Funktionalität durch andere, bereits vorhandene Anforderungen beschrieben ist.

Formulieren Sie für jede noch nicht beschriebene Funktionalität eine oder mehrere zusätzliche Anforderungen.

Als Beispiel zur Anwendung dieser Regel schauen wir uns Steckt in die folgende Anforderung des Bibliothekssystems an: der Anforderung eine implizite das Bibliothekssystem die eingegebenen Annahme? Ist diese Aussage bereits „Nachdem Registrierungsdaten eines neuen Bibliothekskunden geirgendwo in der Spezifikation speichert hat, soll das Bibliothekssystem einen Benutzebeschrieben? rausweis ausdrucken.“

Gibt es eine Anforderung, die beschreibt, dass Registrierungsdaten gespeichert werden müssen? Gibt es eine Anforderung, die beschreibt, dass Registrierungsdaten eingegeben werden können?

152

Damit die eigentliche Funktionalität der Anforderung „Benutzerausweis ausdrucken“ einen Sinn ergibt, muss angenommen werden, dass vorher „Registrierungsdaten eines neuen Bibliothekskunden gespeichert“ wurden. Genau diese Funktionalität muss über eine andere Anforderung beschrieben sein. Ist dies nicht der Fall, haben Sie eine implizite Annahme gefunden, die im Anforderungsdokument durch eine neue Funktionsbeschreibung spezifiziert werden muss: „Das Bibliothekssystem muss Registrierungsdaten eines neuen Bibliothekskunden speichern“. Diese zusätzliche Anforderung muss anschließend natürlich noch hinsichtlich semantischer Effekte, idealerweise beginnend bei Regel 1, detailliert analysiert werden. Auch Substantive, die durch ein Bezugswort detailliert werden, sind Indikatoren für implizite Annahmen. Betrachten wir die obige Beispielanforderung, so stellen wir schnell fest, dass das Bezugswort „eingegebene“ vor dem Substantiv „Registrierungsdaten“ darauf hinweist, dass es eine Funktionalität zum Eingeben von Registrierungsdaten geben muss. Falls diese Funktionalität noch nicht über mindestens eine Anforderung beschrieben ist, wurde eine Information getilgt: „Das Bibliothekssystem muss dem Bibliothekar die Möglichkeit bieten, Registrierungsdaten für einen neuen Bibliothekskunden einzugeben.“

6 Das SOPHISTâ&#x20AC;&#x201C;REgelwerk RE-Bauernregel: Ein einzelner Satz kann zeigen, dass Eine qualitativ hochwertige Anforderung hat Ihnen nun dabei geholfen, selbst komplett getilgte Informationen, wie Ausnahmeverhalten, vergessene zeitliche oder logische Bedin- Fragen im Gesamtbild gungen oder gar implizite Annahmen zu erkennen und gezielt aufzuspĂźren. unbeantwortet bleiben. Der drei Schritte zum PrĂźfen des Gesamtbildes auf einen Blick

KlĂ¤ren Sie Ausnahmen vom Normalverhalten!

Analysieren Sie alle mĂśglichen Fallunterscheidungen!

Analysieren Sie Aussagen, die wahr sein mĂźssen, damit die Anforderung einen Sinn ergibt!

Abbildung 6.9: Die drei Schritte zum PrĂźfen des Gesamtbildes

Wenn Sie diese systematische Vorgehensweise Anforderung fĂźr Anforderung weiter fortsetzen, werden Sie Schritt fĂźr Schritt zu einer vollstĂ¤ndigen und qualitativ hochwertigen Gesamtspezifikation gelangen.

6.8

Anwendung des SOPHISTâ&#x20AC;&#x201C;REgelwerks

Das SOPHIST-REgelwerk stellt Ihnen einen Werkzeugkasten zur VerfĂźgung, um Anforderungen systematisch zu analysieren. Wir haben es bereits in vielen Industrieprojekten erfolgreich eingesetzt, die unterschiedlichste fachliche DomĂ¤nen thematisierten.

Semantische Effekte einstufen

Fragen stellen

SignalwĂśrter finden

Semantische Defekte beseitigen

HĂ¤ufig werden zusĂ¤tzlich Schablonen fĂźr die Formulierung von Anforderungen angewendet, die eine klare Vorgabe dafĂźr geben, wie ein Anforderungssatz genau zu formulieren ist (siehe Kapitel 7 â&#x20AC;&#x17E;Schablonenâ&#x20AC;&#x153;). Dadurch kann man einige Schritte des SOPHIST-REgelwerks (z.Â B. Regel 1, Aktivformulierung) einsparen.

153

6 Das SOPHIST–REgelwerk Sie können sich zu unterschiedlichen Zeitpunkten auf die Suche nach Effekten machen (vgl. Kapitel 7 „Schablonen“, Kapitel 10 „Prüftechniken für Anforderungen“ und Kapitel 11 „Qualitätsmetriken“):

Das erfordert natürlich etwas Übung — ist aber sehr effektiv.

Da Papier ja geduldig ist, lässt sich auf der Basis schriftlicher Anforderungen die Technik gut üben. RE-Bauernregel: Ist die Zeit dir weggerannt, nimm nur ein paar Regeln in die Hand.

■■ Konstruktiv direkt im Interview: Dabei prüft der Requirements-Engineer jede Aussage, die er im Interview von einem Stakeholder erhält, sofort auf mögliche sprachliche Effekte. Er hinterfragt direkt im Gespräch die fehlenden Sachverhalte, die ihm als wichtig erscheinen. So wird das nötige Wissen im Interview sehr effizient erhoben, da Wissenslücken umgehend aufgedeckt werden. Ist der Requirements-Engineer geübt, nimmt der Befragte gar nicht wahr, dass seine Aussagen systematisch nach psychotherapeutischen Gesichtspunkten untersucht und gezielt hinterfragt werden. Der Befragte merkt nur, dass das Gespräch sehr schnell auf den Punkt kommt. Auch während der Dokumentation, also dem Schreiben von Anforderungen, helfen ihm die Regeln konstruktiv weiter. So formuliert er beispielsweise die Funktionalität direkt durch ein Vollverb oder jede Anforderung direkt im Aktiv. Der konstruktive Einsatz der Regeln zum Auffinden semantischer Effekte erfordert natürlich schon ausreichend Praxiserfahrung mit den Fragetechniken des SOPHIST-REgelwerks. ■■ Analytisch als Prüfkriterien auf der Basis erstellter Anforderungen: Liegen bereits Anforderungen in schriftlicher Form vor, so werden diese mittels der sprachlichen Regeln überprüft. Auslassungen, Unklarheiten usw. werden dann hinterfragt. Hier dient das REgelwerk als eine Technik zur analytischen Qualitätssicherung. Natürlich sind auch Requirements-Engineers nicht vor den unerwünschten Defekten der Fokussierung und Vereinfachung gefeit, so dass man sich dementsprechend vorbereiten muss. Für eine erste Anwendung der Methode empfiehlt es sich zunächst, bereits dokumentierte Anforderungen zu analysieren. Nach einiger Zeit Übung sind die psychotherapeutischen Ansätze mit dem SOPHIST-REgelwerk so in das Denken integriert, dass Aussagen eines Stakeholders direkt im Gespräch untersucht und hinterfragt werden können. Wenden Sie zu Beginn auch nur einige wesentliche Regeln an, durch die Sie Ihre Aufmerksamkeit auf die Gruppe der gefährlichen Wiederholungstäter konzentrieren können.

Regel 1

Nach unserer Erfahrung sollten Sie die folgenden Regeln des SOPHIST-REgelwerks mit sehr hoher Priorität beachten:

Regel 2,3 oder 4

■■ ■■ ■■ ■■ ■■

Regel 6 Regel 10 und 12 Regel 17

154

Formulieren Sie jede Anforderung im Aktiv. Lösen Sie Prozesse auf und drücken Sie diese durch Vollverben aus. Analysieren Sie fehlende Informationen zum Prozesswort. Klären Sie Mengen- und Häufigkeitsangaben. Klären Sie fehlende Bedingungen.

6 Das SOPHIST–REgelwerk

Am besten können Sie genannten Regeln des SOPHIST-REgelwerks verinnerlichen, wenn Sie diese mit den zugehörigen Fragen auf ein Blatt Papier notieren. Hängen Sie dieses in Augenhöhe an Ihren Arbeitsplatz und werfen Sie jeden Tag bewusst einen Blick darauf. Versuchen Sie auch nicht krampfhaft, auf jede Anforderung jede Regel anzuwenden. Wenn Ihre Anforderung beispielsweise nicht das Eintreten einer fachlich oder technisch motivierten Bedingung erfordert, dann müssen Sie selbstverständlich auch keine künstliche Bedingung konstruieren oder Fallunterscheidungen analysieren. Wenn Sie sich sicher genug fühlen in der Anwendung der hoch priorisierten Regeln, dann greifen Sie noch etwas tiefer in die Trickkiste. Als geübter Anwender der wesentlichen Regeln des SOPHIST-REgelwerks beachten Sie zusätzlich unbedingt die folgenden Regeln: ■■ Klären Sie Ausnahmen vom Normalverhalten. ■■ Analysieren Sie implizite Annahmen. ■■ Formulieren Sie Vergleiche und Steigerungen mess- bzw. testbar. Und wenn Sie dann ein richtiger Experte sein wollen (oder sein müssen), dann wenden Sie die noch verbleibenden Regeln auf Ihre Anforderungen an.

Aber auch als richtiger Experte sollten Sie nie zum Perfektionisten mutieren. Streben Sie nicht völlig unreflektiert nach absolut defektfreien Anforderungen, sondern berücksichtigen Sie immer Ihre Projektrandbedingungen. Bei dem Thema Qualität liegen Theorie und Praxis häufig weit voneinander. Qualität bei der Analyse und Dokumentation von Anforderungen ist mit viel Aufwand und hohen Kosten verbunden. Perfektionismus wird somit sehr schnell zu einem Luxus, den Sie sich in den meisten Projekten nicht leisten können.

Regel 16

Regel 18

Regel 8

Hier gilt der Grundsatz: Angemessenheit statt Perfektion!

Die Erkenntnis, dass perfekte Kommunikation unmöglich ist, wird Ihnen den Projektalltag ganz erheblich erleichtern. Der möglichst kompetente Umgang mit dieser Tatsache ist einer der Faktoren, der den Erfolg im Bereich Requirements-Engineering ausmacht.

155

6 Das SOPHIST–REgelwerk

6.9

Ene, mene, muh — und defektbereinigt bist du!

Checkliste SOPHIST–REgelwerk Ich verstehe die Transformationsprozesse, die zwischen innerer Vorstellung und sprachlichem Ausdruck zum Tragen kommen. Ich kann die am häufigsten auftretenden sprachlichen Effekte in Anforderungen identifizieren. Ich weiß, auf welchem Spezifikationslevel ich welches Vorgehen beachten sollte. Ich kenne die wichtigsten Signalwörter und mir ist klar, bei welchem Signalwort ich welche Fragen stellen muss. Ich verstehe die unterschiedlichen Betrachtungswinkel (Satzbestandteile, Satz, Gesamtbild), aus denen eine Anforderung zu analysieren ist. Ich kann das SOPHIST- REgelwerk als analytische Prüftechnik auf dokumentierte Anforderungen anwenden. Ich habe ausreichend Übung in der Anwendung des SOPHISTREgelwerks und kann die wichtigsten Regeln nun auch konstruktiv während eines Stakeholder-Interviews anwenden.

156