Tips des Monats

Hier finden Sie alle Tips des Monats zum Nachschlagen; ich freue mich auch über Kommentare zu älteren Tips - schreiben Sie einfach ein Mail!

Tips des Jahres 2009

► Juni: Einfache Regeln zur Anforderungs-Qualität

► Juli: Aspekte zur Vollständigkeit von Anforderungen

► August: Gedanken zur ISO9001-Konformität

► September: Coaching – was ist das?

► Oktober: Nachdenken über Traceability

► November: Anforderungsspezifikation und Architektur

"Ist es eigentlich möglich," so fragte mich kürzlich der Mitarbeiter eines Kunden, "direkt in der Systemspezifikation festzuhalten, in welchem Subsystem eine Anforderung implementiert werden soll?"

"Natürlich," so meine Antwort, "es ist sogar ein durchaus üblicher Weg, auf diese Weise ein Grobdesign und die Allokierung von Anforderungen zu dokumentieren."

Ja, tatsächlich ist das ein einfaches und probates Mittel für diesen Grobdesign-schritt, vor allem dann, wenn man ein Datenbank-gestütztes Anforderungs-managementwerkzeug wie DOORS^® verwendet, das zum einen die Dokumentation sehr einfach macht und zum anderen wertvolle Auswertungsmöglichkeiten zur Verfügung stellt.

Die Implementierung dieser Abbildung in DOORS^® ist sehr einfach: man benötigt dazu lediglich ein zusätzliches Attribut, das die vorgesehenen Subsysteme zur Auswahl stellt, so daß die Zuordnung über wenige Mausklicks erfolgen kann.

Ist die Allokierung der Systemanforderungen auf diese Weise erst einmal doku-
mentiert, ergeben sich zum Beispiel folgende Anwendungsmöglichkeiten für diese Information:

		Die Allokierung von Anforderungen auf Subsysteme erlaubt eine grobe Abschätzung für den mutmaßlichen Umfang der Subsystem-Spezifikationen und die Komplexität der Implementierung der Subsysteme.
		Die Traceability der Systemanforderungen zu den Anforderungsspezifikationen für die einzelnen Subsysteme wird spezifischer: es läßt sich nicht nur dokumentieren, daß eine Systemanforderung sich in der Subsystemebene widerspiegelt, sondern auch, ob sie im „richtigen“ Subsystem abgebildet ist.
		Natürlich kann es sein, daß mehrere Subsysteme einen Beitrag leisten müssen, um eine Systemanforderung in ihrer Gesamtheit abzubilden. Wenn dies aber für relativ viele Systemanforderungen zutrifft (z.B. mehr als 20%), könnte das ein Hinweis darauf sein, daß solche Systemanforderungen eine zu große oder zu komplexe Funktionalität spezifizieren und sinnvollerweise in mehrere Anforderungen aufgespaltet werden sollten.
		Die Autoren der Subsystem-Spezifikationen haben es leichter, die Vorgaben für ihre Spezifikationsarbeit zu finden: sie müssen lediglich die Systemspezifikation danach filtern, welche Anforderungen für „ihr“ Subsystem allokiert sind.

Tips des Monats

Tips des Jahres 2009

► Juni: Einfache Regeln zur Anforderungs-Qualität

► Juli: Aspekte zur Vollständigkeit von Anforderungen

► August: Gedanken zur ISO9001-Konformität

► September: Coaching – was ist das?

► Oktober: Nachdenken über Traceability

► November: Anforderungsspezifikation und Architektur

Die Allokierung von Anforderungen auf Subsysteme erlaubt eine grobe Abschätzung für den mutmaßlichen Umfang der Subsystem-Spezifikationen und die Komplexität der Implementierung der Subsysteme.

Die Traceability der Systemanforderungen zu den Anforderungsspezifikationen für die einzelnen Subsysteme wird spezifischer: es läßt sich nicht nur dokumentieren, daß eine Systemanforderung sich in der Subsystemebene widerspiegelt, sondern auch, ob sie im „richtigen“ Subsystem abgebildet ist.

Die Autoren der Subsystem-Spezifikationen haben es leichter, die Vorgaben für ihre Spezifikationsarbeit zu finden: sie müssen lediglich die Systemspezifikation danach filtern, welche Anforderungen für „ihr“ Subsystem allokiert sind.

► Dezember: Gedanken zur Standardisierung

Tips des Jahres 2010

Tips des Jahres 2011