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
Schlagwortarchiv für: Funktionale Requirements
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
Im ersten Teil des Blogs habe ich den Begriff „Implizites Testen“ definiert und Ursachen dafür diskutiert.
Im zweiten Teil geht es nun um die Nachteile solcher Tests und um Lösungsansätze um möglichst diese Nachteile gar nicht erst entstehen zu lassen. Weiterlesen
In größeren sicherheitskritischen Projekten begegnet mir immer wieder mal der Ausspruch: „Naja, das Requirement A wird mit dem Test XY indirekt oder implizit nachgewiesen!“. Ist Ihnen das auch schon mal passiert? Haben Sie auch schon mal erlebt, was in späten Projektphasen passieren kann, wenn man viele Requirements indirekt getestet hat?
Der Blog definiert im Teil 1 den Begriff und er beleuchtet die Ursachen von Impliziten Testen. Weiterlesen
Spezifikation Architektur Requirement: Für immer mehr Systeme, gerade auch in der Industrieautomatisierung, müssen Forderungen der Funktionalen Sicherheit erfüllt werden. Für die Software Entwicklung ist dann in der Regel die Erfüllung der IEC61508 nachzuweisen.
Auf der anderen Seite stehen kommerzielle Anforderungen an das Produkt, welche das Entwicklungsbudget oft erheblich einschränken.
Die Lösung liegt dann in einem effizienten Entwicklungsprozess, der die sicherheits-relevanten Forderungen erfüllt. Eine Voraussetzung für eine erfolgreiche Umsetzung eines solchen Prozesses ist ein tiefgehendes Verständnis der Norm und eine klare Definition und gegenseitige Abgrenzung von Begriffen. Im nachfolgenden Blog beschäftige ich mich mit den drei Begriffen Spezifikation Architektur Requirement. Weiterlesen
Strukturelle Source Code Coverage: Wenn Sie neu in dem Bereich der Funktionalen Sicherheit tätig sind, dann werden Ihnen die Begriffe strukturelle Source Code Coverage und Requirements ziemlich schnell begegnen. Die Spezifikation von technischen Systemen mittels Requirements ist natürlich auch im nicht sicherheitskritischen Bereich sehr verbreitet. Dagegen spielt das Thema strukturelle Source Code Coverage außerhalb der Sicherheitstechnik praktisch keine Rolle.
In diesem Blog möchte ich mich mit diesen beiden Begriffen und den dahinter stehenden Prozesse beschäftigen. Insbesondere die Frage nach der gegenseitigen Abhängigkeit ist spannend. Weiterlesen
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.
Wenn ich den aktuellen Stand des Requirements Engineering reflektiere, fallen mir folgende Punkte auf:
- Es gibt inzwischen eine Vielzahl guter Werkzeuge zur Dokumentation von Requirements
- Es gibt gute und etablierte Methoden zur Erstellung von natürlich sprachlichen Requirements
- Es gibt noch relativ wenig standardisierte Methoden zum richtigen Umgang mit immer wiederkehrenden Kategorien von Requirements
Ich möchte in diesem Blog-Beitrag insbesondere den letzten Punkt der Kategorisierung von Requirements beleuchten.
In nachfolgender Darstellung versuche ich die Fragestellung grafisch zu erfassen: Weiterlesen
