Sie wollen ein neues Projekt beginnen; In groben Zügen ist das zu entwickelnden Produkt auch schon festgelegt. Sie beschließen dass der Zeitpunkt gekommen ist, diese groben Ideen, Funktionen und Lösungsvorschläge zu strukturieren und aufzuschreiben. Diesen Zeitpunkt und die Fragen die sich nun stellen wollen wir nachfolgend etwas genauer beleuchten. Typische Fragen und Gedanken die Ihnen vielleicht jetzt durch den Kopf gehen könnten sind:

• Schreibt man heutzutage noch Requirements in Textform?
• Textuelle Requirements bedeuten schwere Prozesse, tausende Seiten geschriebener  Dokumente die sowieso niemand liest und versteht!
• Ein Bild sagt mehr als 1000 Worte!

Schreibt man heutzutage noch Requirements in Textform?

Ist die Dokumentation von Requirements in textueller Form noch Stand der Technik? Die Feststellung lautet hier: Ja textuelle Requirements haben ihre eindeutige Berechtigung. Nun stellt sich die Frage nach dem Warum?

Die Stärken von textuellen Requirements liegen darin, dass sich damit die einzelnen Funktionalitäten des Produktes relativ leicht dokumentieren lassen. Dies ist besonders wichtig, wenn man daran denkt, dass in der Regel auch der Nachweis der korrekten Implementierung der Funktionalität notwendig ist. Um einen möglichst vollständigen Test zu erreichen, muss jede Funktion möglichst separat getestet werden. Nur dadurch ist eine brauchbare Traceability zu  erzielen. Dies ist wiederum die zwingende Voraussetzung, um Vollständigkeit zu erreichen.

Ein weiteres Argument für die textuelle Dokumentation ist, dass sie jeder versteht. Komplexe und spezifische Modellierungssprachen oder  formale Modelle, werden in der Regel nur von einer sehr kleinen Minderheit an Ingenieuren verstanden. Das Systemteam oder Softwareteam, welches mit dem Kunden das Produkt definiert, hat in vielen Fällen nicht gleichzeitig das Know-How über eine für dieses Produkt geeignete Modellierungssprache. Die natürliche Sprache, ob Englisch oder Deutsch, hat hier den großen Vorteil, dass sie jeder der Beteiligten versteht.

Dazu kommt, dass es für viele klassische Industrieprojekte bis heute keine geeignete graphische Form der Modellierung gibt. Insbesondere Software und Systeme die den Schwerpunkt im Management und Austausch verschiedener Daten haben, lassen sich wesentlich schwerer graphisch spezifizieren, als Systeme die einen klaren mathematischen Bezug haben (z.B. alle Arten von Regelkreise).

Dazu kommt, dass meiner Erfahrung nach, graphische Modelle und Requirements umso besser sind, je näher es an die konkrete Implementierung (=Software oder Hardware) geht. Komplexe Systeme wie z.B. in Autos und Flugzeugen, lassen sich bis heute bei weitem nicht vollständig modellieren. Zum einen stehen Aufwand und Nutzen in keinem angemessenen Verhältnis,  zum anderen lassen sich technisch bei weitem nicht alle Eigenschaften so eines Produktes in graphischer Form darstellen.

Textuelle Requirements bedeuten schwere Prozesse, tausende Seiten geschriebener  Dokumente die sowieso niemand liest und versteht?

Aus dem letzten Abschnitt lässt sich schlussfolgern, dass es viele Bereiche gibt in denen textuelle Requirements alternativlos sind. Bedeutet das nun gleichzeitig, dass ich schwere Prozesse haben muss und viel Papier produziere, welches am Ende noch nicht mal gelesen und beachtet wird.

Klare Antwort: NEIN!

Keine Norm, kein funktionaler Sicherheitsstandard fordert schwere, träge, starre oder wirklichkeitsfremde Prozesse. Schon gar nicht ist das Erstellen und Pflegen von Requirements die Ursache dafür. Wie man Prozesse in die Praxis umsetzt liegt in der Hand der Organisation, des Teams und teilweise auch des einzelnen Mitarbeiters. Erfolgreich sind die Projekte, die es schaffen z.B: das Requirements Engineering mit textuellen Requirements einzuführen und trotzdem dynamisch, schnell und flexibel zu bleiben. Das gelingt dann, wenn man die Prozesse schlank hält, auf das Wesentliche reduziert und vor allem, wenn man flexibel im Denken bleibt.

Das Reduzieren auf das Wesentliche bedeutet aber z.B. dass man sich eine Strategie zurechtlegen muss. Man muss Prioritäten setzen und sich ggf. bewusst gegen eine Maßnahme und für eine andere Maßnahme entscheiden. Das Thema ‚Prozesse und was dabei aus welchen Gründen alles schief gehen kann‘ ist sehr umfangreich und kann innerhalb dieses Blogs nicht weiter behandelt werden. Auch das Argument, dass die Einführung von textuellen Requirements zu tausenden Seiten „sinnloser“ Dokumentation führt ist zu entkräften.

Zunächst ist es so, dass große Dokumente an dieser Stelle nur entstehen, wenn auch sehr viele Requirements geschrieben werden. Ja, das passiert in der Praxis immer wieder, aber es muss nicht so sein! Nach meiner Erfahrung werden heutzutage branchenübergreifend eher zu viel als zu wenig Requirements geschrieben. Wenn man diese Projekte analysiert sieht man, dass diese große Anzahl an Requirements deutlich mehr Probleme verursacht, als dadurch gelöst werden. Die Gründe hierfür wiederum sind darin zu suchen, dass keine Strategie und keine Vorgehensweise erstellt wird. Die großen Dokumente entstehen nicht per se durch das Requirements Engineering, sondern durch falsche bzw. keine passenden Vorgehensweisen und Strategien.

Wenn solch große Dokumente aus den genannten Gründen entstehen, ist klar dass sie tendenziell nicht lesbar und nicht brauchbar sind. Ein Requirementsdokument das mit einer klaren Strategie erstellt wurde, wird im Projekt in der Regel auch oft genutzt.

Ein Bild sagt mehr als 1000 Worte!

Dieser Satz ist sicher richtig und kann aufgrund der allgemeinen Lebenserfahrung aus verschiedensten Bereichen bestätigt werden. Wenn dem so ist, warum schreiben wir dann die Requirements in Textform auf, anstatt Bilder zu benutzen? Diese Frage ist sehr berechtigt, bedarf aber einer etwas ausführlicheren Antwort. Eine einfache Antwort würde der hinter der Frage stehenden Komplexität nicht gerecht.

Zunächst ist es so, dass im Bereich der Embedded Systeme die Verwendung von Bildern meist ein Zeichen dafür ist, dass die Requirements eher aus der Architektur und dem Design entstanden sind. Rein funktionale Requirements werden meist eher in textueller Form beschrieben. Warum ist das so?

Nun, eine Software oder Systemarchitektur lässt sich nun mal wesentlich leichter in Bildern ausdrücken. Die Darstellung eines Datenflusses ist in textueller Form nur extrem umständlich zu beschreiben. In einem Bild sind dafür nur ein paar einfache Striche mit Richtungspfeilen notwendig.

Wiederum lassen sich einzelne Funktionalitäten, vor allem in Form von Atomic-Requirements, sehr leicht in Text beschreiben. Der größte Nachteil von Bildern, für den Zweck Requirements zu schreiben, ist dass sie sehr schnell, sehr komplexe Zusammenhänge darstellen. Das ist zwar auf den ersten Blick ein enormer Vorteil, gilt aber nicht mehr, wenn man versucht diese komplexen Zusammenhänge vollständig zu testen. Bilder und Grafiken zu testen bedeutet sehr schnell, sehr viele Testfälle und dadurch entsteht oft ein Traceability Problem. Welcher Teil des Bildes ist mit welchen Testfällen verifiziert? Dementsprechend schwierig wird es, eine Vollständigkeit nachzuweisen.

Aus meiner Sicht, bedeutet das aber keine Entweder-Oder-Entscheidung. Vielmehr halte ich es für eine extrem vorteilhafte Aufteilung, wenn man ganz bewusst die Funktionalität eher in textuellen Requirements formuliert und gleichzeitig, parallel dazu die Architektur und das Design mit Bildern und Grafiken erstellt.

Diese eindeutige Trennung hat in Bezug auf die Klarheit, Nachvollziehbarkeit, Verständlichkeit und Testbarkeit enorme Vorteile. Für mich ist die Nichtbeachtung dieser Tatsache eine wesentliche Ursache für sehr viele Probleme im Requirements Engineering. Leider wird oft gar keine Architektur erstellt, da man annimmt, allein textuelle Requirements, welche die Architektur, Design und Funktionalität beinhalten, seien ausreichend und zielführend.

Fazit:

Dokumentieren Sie noch, oder spezifizieren Sie schon?

Alle diejenigen, die ohne viel Strategie und Überlegung Requirements erstellen und dies (ausschließlich) mit der Motivation tun, eine Norm oder einen Standard zu erfüllen, sind eher beim Dokumentieren. In diesem Fall besteht eine große Wahrscheinlichkeit, dass im Bereich des Requirements Engineerings enormes Verbesserungspotential vorhanden ist.

Eher auf der Seite des Spezifizierens befinden Sie sich, wenn Sie sich eine klare Requirements- und Traceability Strategie überlegt und erarbeitet haben. Dies bedeutet dann auch, dass Sie ganz bewusst textuelle Requirements und grafische Requirements an der für sie jeweils richtigen Stelle verwenden und einsetzen. Mit großer Wahrscheinlichkeit werden Sie dann auch weniger Wiederholungsläufe beim Testen haben, was ein bedeutendes Zeichen für hohe Produktqualität darstellt.

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).