Viele Bücher sind in den letzten 30 Jahren geschrieben worden zum Thema Requirements Engineering. Viele haben sich mit dem Thema beschäftigt. Die Methode wurde entworfen und verbessert. Der große Erfolg dieser Bemühungen liegt darin, dass das Bewusstsein für das Thema in einem breiten Fachpublikum bewusst gemacht wurde. Es gibt heute kaum noch jemanden der grundlegend bestreiten würde, dass Requirements Engineering für Software lastige Embedded Systeme und IT-Systeme sinnvoll ist. Andererseits kann auch festgestellt werden, dass die praktische Umsetzung von Requirements Engineering in den Projekten immer noch deutliche Mängel aufweist. An dieser Stelle setzt der nachfolgende Beitrag an. Anhand einiger ausgewählter Themen des Requirements Engineering zeige ich Differenzen auf, zwischen den Vorgaben in der Methodenbeschreibung, und dem Bedarf in der Praxis. Mögliche Lösungen werden angedeutet, sind aber nicht Bestandteil dieses Beitrags. Hier geht es zunächst einmal „nur“ um die Schärfung des Bewusstseins für die Problematik.
Requirement- und Test Traceability: Standen Sie auch schon mal vor folgender Situation: Ihr sicherheitsgerichtetes Projekt steht kurz vor dem Abschluss, und Sie haben nahezu alle Teilprodukte untereinander in Beziehung gesetzt („verlinkt“). Es wurde erheblicher Aufwand in die Traceability gesteckt!
In einem Audit (z.B. interne QS, Kunde, Behörde) sollen Sie aufzeigen, welche Software Requirements sich aus welchen System Requirements herleiten. Jedes Software Requirement ist auf eines oder mehrere System Requirements verlinkt und auch jedes System Requirement ist auf ein oder mehrere Software- oder Hardware Requirements verlinkt. Weiterlesen
Wenn man den Büchermarkt, Publikationen oder auch Konferenzen zum Thema Requirements Management und -Engineering (RE) analysiert, stellt man fest, dass mehr als 90% davon die Methode Requirements Engineering aus dem Blickwinkel von IT-Software Systemen betrachten. Es gibt nur ganz wenig Veröffentlichungen die das Thema aus dem Blickwinkel von Embedded Systemen betrachten. Es ist einerseits das große Verdienst einiger Pioniere aus der IT-Entwicklung dass überhaupt Vorgehensweisen für das RE diskutiert und etabliert wurden in den letzten 20 Jahren. Andererseits führt es in der Entwicklung von Embedded Systemen immer wieder zu Problemen, weil diese Vorgehensweisen unreflektiert übernommen werden. Requirement Engineering für Embedded- und IT-Systeme unterscheidet sich mehr als man zunächst annehmen würde! Weiterlesen
In den meisten Publikationen zum Thema Requirements liegt der Schwerpunkt auf den Management Aspekten. Viel diskutiert sind die Thema Erfassen und Verwalten von Requirements. Im nachfolgenden Blog arbeite ich heraus, welche wichtigen Aspekte immer wieder zu kurz kommen. Meine Betrachtungen starten mit der Definition von Requirement Engineering im Buch „Basiswissen – Requirement Engineering“ (Klaus Pohl, Chris Rupp). Weiterlesen
Das Buch „User Stories“ von Mike Cohn (ISBN 978-3-8266-5898-3) hat mich inspiriert, einmal mehr über den Bezug zwischen User Stories und Requirements nachzudenken. In der Software Entwicklung werden agile Methoden in den letzten Jahren oft bevorzugt eingesetzt. Die klassischen Vorgehensweisen, insbesondere das Wasserfallmodell und auch das V-Modell, scheinen etwas aus der „Mode“ zu kommen.
Konsequenter Weise werden damit User Stories gegenüber den „klassischen“ Requirements auch bevorzugt eingesetzt. Helfen die User Stories aber wirklich, bessere Software Qualität abzuliefern? Gibt es nicht auch viele Aspekte, bei denen es gar keine Unterschiede gibt? Weiterlesen
Wenn es in den Entwicklungsprojekten mit Requirements mühsam wird, wird Test Driven Development (TDD) oft als die Lösung propagiert. Ist das wirklich die Lösung? Falls ja, warum hat sich TDD bis heute nicht wirklich flächendeckend in der Softwareentwicklung durchgesetzt? Im Folgenden möchte ich meine Gedanken dazu darlegen.
Qualität kostet Geld! Viele können vermutlich diesem Statement zustimmen. Das Statement wird sich auch kaum widerlegen lassen – schon deswegen nicht, weil es sehr allgemein formuliert ist.
Bezogen auf den Software Entwicklungsprozess wird aber oft der sehr vereinfachte Schluss gezogen, dass jede Maßnahme der Qualitätssicherung einfach nur teuer ist.
Ich möchte im nachfolgenden Blog einmal etwas genauer hinschauen und das Review von Requirements aus wirtschaftlicher Sicht betrachten. Lohnen sich Requirements Reviews, so wie sie in allen Standards der Funktionalen Sicherheit gefordert werden, aus wirtschaftlicher Sicht?
„Zeit ist Geld“ ist hier zunächst einmal das Motto, d.h. im ersten Schritt müssen wir überlegen, wie lange das Review eines Requirements im Durchschnitt dauert. Nun, ich gehe davon aus, dass Sie lieber Leser, hier durchaus sehr unterschiedliche Erfahrungen gemacht haben. Ich werde nachfolgend versuchen, trotzdem einen Wert herzuleiten. Weiterlesen
In meinen täglichen Projekten in der Automobilbranche und der Automatisierungstechnik treffe ich immer wieder auf die Frage, wie viele Requirement Ebenen denn nun geschrieben werden müssen. Das ist eine spannende Frage, insbesondere wenn man viel Erfahrung mit Luftfahrtprojekten hat.
Daher möchte ich in diesem Blogbeitrag dieses Thema einmal etwas näher beleuchten. Zunächst möchte ich die Vorgaben der FuSi-Standards IEC 61508, ISO 26262 und DO 178B/C vergleichen. Abschließend gebe ich noch Projekterfahrungshinweise, die auf meiner mehr als 15 jährigen Erfahrung beruhen.
Aus meiner Sicht unterteilt sich eine gute Software Spezifikation in zwei wesentliche Teile: Architektur/Design und textuelle Requirements.
Die Architektur beschreibt, meist überwiegend in grafischer Form, die Struktur und den Aufbau der Software. Insbesondere werden auch Daten- und Kontrollflüsse dargestellt. Der Schwerpunkt von textuellen Requirements wiederum liegt auf der Beschreibung der Funktionalität, sowie den zeitlichen Anforderungen an das System.
Die Ausgangsfrage dieses Blogs bezieht sich auf die Anzahl der Ebenen von textuellen Requirements. Nicht mitgezählt wird hier die Ebene der System-Requirements, welche immer vorhanden sein muss.
Weiterlesen
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!
Meiner Beobachtung nach bekommt das Requirements Engineering im Allgemeinen nicht die angemessene Aufmerksamkeit. Wenn man Software und/oder Hardware Projekte betrachtet die Scheitern, ist ein fehlendes, oder falsches Requirements Engineering in vielen Fällen eine Hauptursache.
Wenn man einen Schritt weiter geht und sich die Arten von möglichen Requirements betrachtet, dann kann man in einem ersten Schritt, ganz grob eine Einteilung in Funktionale und Nicht-funktionale Requirements vornehmen.
