Requirements Engineering – Anforderungen von Anforderungen

Lesedauer 5 Minuten

Im ersten Beitrag zum Thema Requirements Engineering wurde bereits der Begriff der Anforderung samt ISO-Definition vorgestellt. Danach behandelte ein weiterer Text verschiedene Arten von Anforderungen. Nun wird auf die Frage eingegangen, welche Anforderungen eigentlich an Anforderungen selbst zu stellen sind. 

Die Leute von der internationalen Organisation für Normung haben im ISO-Standard 29148-2018 eine ganze Reihe von Qualitätsmerkmalen für Anforderungen festgelegt. Über zwei davon soll sich dieser Beitrag Gedanken machen: Eindeutigkeit und Konformität. 

Eindeutigkeit 

Das bedeutet nichts anderes, als dass eine Anforderung klar und unmissverständlich beschreiben soll, was im Rahmen der Produktentwicklung schließlich umgesetzt wird. Klingt eigentlich trivial, ist es aber nicht. Denn nichts trennt Kunden und Entwickler so sehr wie die gemeinsame Sprache. 

Universalquantoren – immer, jeder und alle 

Wer kennt nicht die Wünsche, in denen sich Begriffe wie »Alle« und »Immer«, »Sämtliche« und »Jeder« tummeln. Dabei handelt es sich um Universalquantoren, die allgemeine Gültigkeit ausdrücken sollen, im Rahmen von Anforderungen jedoch Gift sind. Denn: Wer ist »Jeder«? Wann ist »Immer«? 

Hinterfrage diese Begriffe, und du kommst rasch dahinter, dass »Jeder« eigentlich gar nicht so viele Leute umfasst. »Immer« findet in Wirklichkeit allzu oft nur zu bestimmten Zeitpunkten statt. Und mit »Alle« wie in »Alle Daten sollen angezeigt werden« fangen wir erst gar nicht an. 

Trickreiche Menschen mögen zwar glauben, es würde reichen, sich auf den oder die »BenutzerIn« oder »KundIn« einzuschränken. Manchmal reicht das, viel öfter muss aber noch weiter gegangen werden. Denn was ist beispielsweise mit bestimmten Features eines Software-Produkts, die nur einem Administrator zur Verfügung stehen sollen und nicht jedem Gast-User? 

Selbst rechtliche oder moralische Probleme können auftreten, wenn etwas für »Jeden« möglich sein soll. In einem Webshop soll »jeder« in der Lage sein sich »alles« anzusehen und zu kaufen? Was, wenn das Sortiment auch Produkte enthält, die nur für Erwachsene gedacht sind? 

Ungenaue Begriffe und Glossar 

Ein Beispiel: Was ist mit »Neustart des Systems« gemeint? 

Dass Universalquantoren ungenau sind, sollte nun klar sein. Aber leider ist es mit ihrer Vermeidung noch nicht getan, gibt es doch eine Unzahl anderer Begriffe, unter denen jeder etwas anderes verstehen kann. 

Dafür muss zunächst klar sein, was denn eigentlich das »System« ist. Handelt es sich ums Betriebssystem, um eine Desktop-Anwendung oder um einen Server-Dienst? Aber selbst wenn das geklärt ist, wissen wir noch nicht automatisch, worum es sich bei einem Neustart handelt.  

Reicht es einen Benutzer ab- und wieder anzumelden? Oder muss ein vollständiger Reboot durchgeführt werden? Und selbst ein solcher kann sich verschieden gestalten. So gibt es etwa bei Windows die Option, einen »gesicherten Neustart« auszuführen. Apropos Windows: Wird das System denn wirklich heruntergefahren oder nicht doch nur in einen Ruhezustand versetzt? 

Schon alleine aus Gründen der Lesbarkeit kann jedoch oft nicht auf solche Begriffe verzichtet werden. Daher stellt ein Glossar ein wichtiges Werkzeug für den Requirements Engineer dar. Darin legen alle Stakeholder gemeinsam fest, was bestimmte Begriffe im Rahmen der Anforderungen bedeuten, sodass im Streitfall darauf zurückgegriffen werden kann. 

Konformität 

Ein weiteres Qualitätsmerkmal von Anforderungen besteht in Konformität. Da die menschliche Sprache zu einem guten Teil aus Wiederholungen, Ungenauigkeiten und Redundanzen besteht, ist es sinnvoll, eine klare und allgemeingültige Struktur zu verwenden. 

Anforderungen sollen kein spannungsgeladener Roman sein. Sie sollen nicht durch sprachliche Raffinesse glänzen und den Literaturnobelpreis gewinnen sie sowieso nicht. Sie haben nur einen Zweck: unmissverständlich festlegen, was bewerkstelligt werden soll. Idealerweise folgt ihre Formulierung dabei einem klar festgelegten Aufbau, für den Satzschablonen verwendet werden können. 

Satzschablonen 

Dabei handelt es sich um sprachliche Konstrukte, die nach einer Art Baukastenprinzip zusammengestellt werden. Dabei ist eine enge Verwandtschaft zu den User Storys, die im Beitrag »Und wann ist es fertig?« – Story Points im Scrum vorgestellt wurden, nicht von der Hand zu weisen. Denn in beiden Fällen wird beschrieben, wer etwas tut, was getan wird und unter welchen Bedingungen es passiert. Zusätzlich dazu legen Satzschablonen noch eine Verbindlichkeit fest. 

Verbindlichkeit 

Mit einem einzelnen Verb, grammatikalisch handelt es sich um das Prädikat des Satzes, wird festgelegt, ob  

• eine Anforderung unbedingt umzusetzen ist: »Das System muss …« 
• eine Anforderung zwar schon dokumentiert ist, aber nicht sofort, sondern in späteren Versionen realisiert wird: »Das System wird …« 

• eine Anforderung nur ein Wunsch (»nice to have«) ist: »Das System sollte …« 

Theoretisch ist auch die Verwendung anderer Verben als »muss«, »wird« und »sollte« möglich; je nach Literatur kommt manchmal auch »kann« vor. Diese stellen jedoch einen Quasi-Standard dar. Im Zweifel lohnt es sich, sie auch ins Glossar aufzunehmen, um zu dokumentieren, welche Verbindlichkeit sie festlegen.  

Was ist das System? 

In obigem Beispiel kam auch der Begriff »System« vor, der für das eigentliche Produkt oder einen Teilaspekt steht. Dabei kann es sich um eine Textverarbeitung handeln, einen Webshop, oder auch um ein physisches Objekt, z. B. ein Auto oder Mobiltelefon. So wie die Verbindlichkeit grammatikalisch mit dem Prädikat des Satzes festgelegt wird, handelt es sich hierbei um das Subjekt.  

Auch hier hilft ein Eintrag im Glossar, um klarer zu spezifizieren, was mit »System« eigentlich gemeint ist. 

Prozesswort 

Den Kern der Anforderung beschreibt man mit einem Prozesswort: Was muss (bzw. wird oder sollte) das System eigentlich tun? Sprachlich kann es sich dabei natürlich auch um mehrere Worte handeln. Wiederum gilt: Ein Eintrag im Glossar schafft im Zweifel Klarheit. 

Es wird zwischen drei Arten von Systemtätigkeiten unterschieden: 

• Selbständige Systemaktivität: Das laufende System agiert ohne äußeres Zutun. 
• Benutzerinteraktion: Es werden Funktionen zur Verfügung gestellt, die ein Anwender selbst aktiv ausführen muss. 

• Schnittstellenanforderung: Das System ist in Wartestellung und wird erst aktiv, sobald ein externer Prozess abläuft. Dabei kann es sich sowohl um Prozesse eines Fremdsystems als auch um die Aktivität eines Benutzers handeln.  

Während bei selbständigen Systemaktivitäten das Prozesswort sofort kommen kann, sind bei den beiden anderen Typen meist noch Ergänzungen erforderlich. Kenntlich gemacht werden die beiden noch durch eine eigene, eindeutige Phrase sowie, im Fall der Benutzerinteraktion, durch die Nennung eines Akteurs: 

• Benutzerinteraktion: »… [Akteur] die Möglichkeit bieten, …« 
• Schnittstellenanforderung: »… fähig sein …« 

Beispiel 

Am Beispiel einer Tabellenkalkulation wie z. B. Excel: 

• Selbständige Systemaktivität 

»Das System muss das Tabellenraster darstellen.« 

Das passiert ohne äußeres Zutun. Die Linien, aus denen sich die Spalten und Zeilen bilden, werden zu jedem Zeitpunkt dargestellt. 

• Benutzerinteraktion 

»Das System wird [Akteur] die Möglichkeit bieten, zwischen verschiedenen Arbeitsblättern zu wechseln« 

Die Arbeitsblätter sind in der Software vorhanden, ob und wie sie genutzt werden oder nicht, liegt im Ermessen der Anwender. (Beachte das das Wort »wird« an dieser Stelle. Dies würde bedeuten, dass es sich um ein Feature für die Zukunft handelt.) 

• Schnittstellenanforderung 

»Das System muss fähig sein, die Ergebnisse von Formeln in Echtzeit zu aktualisieren«. 

Sollen beispielsweise die Zahlen einer Spalte aufsummiert und das Ergebnis in einem separaten Feld angezeigt werden, »wartet« das Programm, bis eine Eingabe erfolgt. Sobald dies der Fall ist, wird die Summe automatisch neu gebildet. 

Zusätzliche Bedingungen 

Die Satzschablonen lassen sich natürlich noch erweitern. So können beispielsweise noch zeitliche oder logische Bedingungen ergänzt werden, unter denen der Prozess ausgeführt werden soll oder auch nicht. Weiterführende Beschreibungen finden sich etwa im Buch »Basiswissen Requirements Engineering« von Klaus Pohl und Chris Rupp. 

Wozu all das? 

Kombiniert mit klaren und verständlichen Begriffen (oder solchen, die zumindest im Glossar definiert sind), ermöglichen Satzschablonen eine strukturierte Formulierung und aber auch Verwaltung von Anforderungen.  

Dazu brauchst du im Grunde genommen nicht mehr als eine Excel Tabelle (wobei natürlich auch nichts gegen aufwändigere Datenbank-Lösungen spräche): Setze dazu die einzelnen Bausteine der Schablone immer an die gleiche Stelle. Damit lässt sich per Filter rasch zwischen Wünschen (»sollte«), aktuellen (»muss«) oder künftigen (»wird«) Anforderungen unterscheiden. Das Analoge gilt für die Typen von Anforderungen (»fähig sein« für Schnittstellenanforderungen, »die Möglichkeit bieten« für Benutzerinteraktionen oder das leere Feld für selbständige Systemaktivitäten).  

Und nicht zuletzt lassen sich die Anforderungen damit leicht warten und aktualisieren. Ändere »wird« auf »muss«, und schon hast du einen Wunsch in eine aktuelle Anforderung verwandelt. 

Das könnte dich auch interessieren