Du bist hier: / Software Requirements

Schlagwortarchiv für: Software Requirements

Requirements Engineering 2.0 – Ansätze wie die Methode weiterentwickelt werden muss!

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.

Weiterlesen

/von

Requirement Engineering für Embedded- und IT-Systeme – Es wird Zeit das sich die Embedded Community der Unterschiede bewusst wird!

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

/0 Kommentare/von

Requirement Engineering – Aspekte die schon in der Theorie zu kurz kommen!

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

/0 Kommentare/von

Implizites Testen – Eine gute Idee (Teil 2)?

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

/0 Kommentare/von

Implizites Testen – Eine gute Idee (Teil 1)?

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

/1 Kommentar/von

User Stories – Die besseren Requirements?

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

/1 Kommentar/von

Wieviele Requirements Ebenen sind sinnvoll?

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

/1 Kommentar/von

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ