In diesem Blog-Beitrag möchten wir Ihnen einen Prozess zur Validierung von System-Architekturen gegenüber den System-Anforderungen vorstellen, um den System-Architekten im Umgang mit den sich ständig ändernden Anforderungen und bei der Analyse der Auswirkungen dieser Änderungen (Impact-Analyse) auf die System-Architektur zu unterstützen. Dazu verwenden wir die Modellierungssprache Unified Modelling Language (UML), die Sie im optimalen Fall bereits für die modellbasierte Dokumentation Ihres Systems einsetzen. Mit Hilfe des Validierungsprozesses lassen sich reproduzierbare Validierungsergebnisse erstellen, wobei der Arbeits- und Zeitaufwand des Architekten durch Automatisierungen und Werkzeugunterstützung reduziert wird. Er lässt sich an den aktuellen Entwicklungsstand anpassen, so dass zu Beginn der Entwicklung weniger detaillierte Informationen zur Validierung verwendet werden, die dann im Laufe der Entwicklung durch immer detailliertere ersetzt werden können. Auf diese Weise erhalten Sie auch eine fortschreitende Dokumentation des Architektur-Designs. Weiterlesen
Archiv des Autors: SOPHIST
GI RE Fachgruppentreffen mit Chris Rupp in Hamburg
Auf dem diesjährigen GI Fachgruppentreffen zu Requirements Engineering möchten wir Ihnen Wege zeigen, wie man trotz englischer Sprachumstellung und Off-Shoring-Tatsachen eine gelungene Spezifikation erstellt. Weiterlesen
„Nur qualitativ hochwertige Anforderungen erzeugen hochwertige Produkte“ – Teil 1
Warum JEDER die Qualität von Anforderungen messen kann und soll
Der in der Literatur meist genannte Grund zur Einführung von Requirements Engineering ist das Sichern des Projekterfolgs. Denn zahlreiche bekannte Projekte zeigen, dass undefinierte Anforderungen häufig Ursache dafür sind, dass die festgelegten Zeit- und Budgetrahmen nicht eingehalten werden können. Belegt wird dies durch den jährlich erscheinenden CHAOS Report der Standish Group, laut dem (im Jahr 2009) nur 32% aller Projekte im IT-Umfeld erfolgreich abgeschlossen wurden. Weiterlesen
Meine 5 wichtigsten Erfolgsfaktoren im Requirements Engineering
1. Klären Sie die Ebenen von Anforderungen!
In vielen Projekten entdecke ich während Reviews und Audits vielfach redundante Beschreibungen in fachlichen Konzepten, groben Anforderungen, detaillierten Anforderungen, technischen Konzepten, u.v.m. Diese mehrfach dokumentierten und teils auch mehrfach ermittelten Informationen können teilweise durch eine von Beginn an durchdachte Dokumentenlandschaft vermieden werden. Beginnen Sie sehr früh, bevor die erste Person anfängt erste Anforderungen zu formulieren, mit der Festlegung von deutlich voneinander abgestuften Anforderungsebenen. Dazu führe ich sehr gerne einen kleinen Workshop zur Klärung der Dokumentenlandschaft durch. Während des Workshops zeigen Sie ebenso die mit Anforderungen verbundenen (u.U. nachvollziehbar verfolgten) Informationen auf. Klären Sie die Ebenen von Anforderungen (z.B. Grobkonzept und Feinspezifikation) in Ihrem Projekt immer inklusive exemplarischer Verdeutlichungen mit einem Beispiel. Vermitteln Sie die definierte Dokumentenlandschaft dann an das Projektteam. Weiterlesen
Eine kleine (User-) Geschichte – Teil III
Im letzten Beitrag ließ ich Sie mit der Fragestellung nach dem konkreten WANN und WARUM der Schneidung von User Stories alleine. Wir identifizierten vier Schneidungsaspekte: Daten, Prozess, nicht-funktionale Aspekte und technische Aspekte. Wobei wir die Schneidung nach technischen Aspekten als nicht sehr sinnvoll erachteten und diesen Schneidungsaspekt deshalb in der folgenden Betrachtung außen vor lassen. Weiterlesen