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
Schlagwortarchiv für: Kategorien von Requirements
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
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
