Iterative, natürlichsprachliche Spezifikation von Anforderungen

Anbieter zum Thema

ET System electronic GmbH

MES Electronic Connect GmbH & Co. KG

IBR Leiterplatten GmbH & Co. KG

SOPHIST GmbH

Der Zweck von Grobfeatures

Während beim Einsatz von Use Cases nur die externe Sicht auf ein System berücksichtigt wird, was allerdings einen sehr sinnvollen Einstieg in eine Systemspezifikation darstellt, bieten die feingranulareren Grobfeatures die Möglichkeit, weitere, nicht den Anwender direkt betreffende Eigenschaften festzulegen. Diese, zwar abstrakte aber das System prinzipiell vollständig abdeckende Sammlung von Grobfeatures kann bereits zur Abstimmung mit weiteren Stakeholdern verwendet werden, die anhand der gröberen Use Cases kaum Aussagen betreffend ihrem Verantwortungsbereich machen konnten.

Zum Beispiel bieten Grobfeatures eine verlässlichere Grundlage für die ersten Abstimmung mit den Softwarearchitekten als Use Cases, da die vereinzeltere und vollständigere Beschreibung der Grobfeatures mögliche Softwarekomponenten und eventuelle Generalisierungen und Modularisierungen identifizierbar machen.

Es fällt relativ leicht, Grobfeatures in vorhandene, featurebasierte Spezifikationsprozesse einzubinden. Sie benötigen keine besondere Notation oder spezifische Tools; lediglich eine essenziellere Denkweise als beim üblichen Spezifizieren muss angewandt werden.

Insbesondere eignet sich der Grobfeature-Ansatz für Weiterentwicklungen einer vorhandenen featurebasierten Spezifikation. Indem man die neuen Aspekte des Systems in Form von Grobfeatures neben die essenzialisierten, vorhandenen Features stellt, liegt relativ zügig der Vollumfang des neuen Systems als Liste von (Grob-)Features vor, die dann sowohl eine Diskussionsgrundlage als auch eine Basis für weitere Spezifikations-Schritte bildet.

Weiterhin bieten Grobfeatures die Möglichkeit, eine weitere Verfeinerungsebene in die Systemspezifikation darzustellen. Anstatt jeden Aspekt sofort bis ins Detail pragmatisch zu beschreiben, erlaubet der Einsatz von Grobfeatures dem Spezifikateur mehrere Aspekte auf höherer Spezifikationsebene quasi nebeneinander zu betrachten. Wenn mehrere Eigenschaften oder Funktionen des selben Systems kurz und essenziell beschrieben und begründet werden, fallen Zusammenhänge zwischen diesen Aspekten schneller auf als wenn man sich sofort intensiv mit jedem einzelnen Feature auseinandersetzt. Sobald die Systemeigenschaften grob spezifiziert und abgestimmt sind, kann man auf einer tiefergehenderen Ebene die Details festlegen.

Zu guter Letzt bieten Grobfeatures eine weitaus nachhaltigere Grundlage zur Strukturierung als eine tiefgehend detaillierte Spezifikation. Insbesondere für langlebige und eventuell sogar mehrfach weiterentwickelte Systeme stellt die Festlegung einer Spezifikationsstruktur eine weitreichende Entscheidung dar, da alle Ergänzungen und Überarbeitungen in die vorhandene Struktur integriert werden müssen. Im Rahmen von Weiterentwicklungen ändern sich häufig die Lösungsansätze und technische Neuerungen müssen berücksichtigt werden.

Falls die vorhandene Struktur für solche Weiterentwicklungen nicht zweckmäßig ist, droht „Wildwuchs“: neue Features werden unsauber in die Struktur eingefügt, was zu sich stetig verschlechternder Les- und Wartbarkeit der Spezifikation führt. In eine schlecht zu wartende Spezifikation schleichen sich auf Dauer mehr Fehler und Qualitätsmängel ein als in eine gut lesbare Spezifikation. Eine auf essenziell formulierten Grobfeatures basierte Struktur ist weit lösungsneutraler und damit zukunftssicherer als eine auf pragmatisch formulierten Anforderungen aufgebaute. Also trägt eine anhand von Grobfeatures erstellte Struktur zum langfristigen Erhalt einer hohen Spezifikations-Qualität bei.

Grobfeatures in der Praxis

Im Rahmen des einleitend erwähnten Projektes haben sich eine Reihe von sinnvollen Vorgehensweisen und Faustregeln im Umgang mit Grobfeatures herausgestellt.

• Jedes neu erstellte Grobfeature sollte auf seine Unteilbarkeit hin überprüft werden. Ähnlich wie in der oben genannten Definition von Features sollte gelten, dass ein Grobfeature immer exakt eine nicht weiter teilbare Systemeigenschaft repräsentiert. Beispielsweise ist es sinnvoll, die Verwendung einer Funktion von seiner Konfiguration zu trennen. Diese so genannte Vereinzelung erlaubt es, im Rahmen von Abstimmungen, Zuordnungen und potenziellen Weiterentwicklungen, die Spezifikation so modular wie möglich zu erhalten. Einzelne Funktionen lassen sich einfach herauslösen, wiederverwenden, ersetzen oder ergänzen.
• Die Bezeichnung jedes Grobfeatures sollte im Rahmen des Gesamtsystems eindeutig sein. So ist für den gesamten Spezifikationsprozess immer sofort klar, hinter welcher Bezeichnung sich welche Funktion oder Eigenschaft verbirgt - selbst wenn dieser Begriff unabhängig von seiner Struktur betrachtet wird. Weiterhin lässt sich auf der Basis eindeutiger Bezeichnungen ein Begriffsklassenmodell - also eine abstrahiert Darstellung der Zusammenhänge einzelner Aspekte des Systems - erstellen.
• Die essenzielle Beschreibung sollte weder zu lang, noch zu kurz ausfallen. Nur ein Satz, der inhaltlich keinen Mehrwert gegenüber der Bezeichnung bietet, ist zu wenig. Zu lange Beschreibungen drohen zu detailliert zu werden und machen damit die Vorteile des Grobfeature-Konzeptes zunichte.
• Die Bezeichnung eines Grobfeatures sollte möglichst keine Abkürzungen enthalten. Abkürzungen bergen das Risiko von Missverständlichkeit und beschränken die Eigenständigkeit eines Grobfeatures - denn ohne Abkürzungsverzeichnis wird die Bezeichnung unklar.
• Weder die Grobfeature-Bezeichnung noch die essenzielle Beschreibung sollten sich auf spezifische, technische Lösungen oder Konzepte beziehen. Die Wahrscheinlichkeit, dass solche Begriffe veralten, ist sehr hoch. Abstrakte Begriffe dagegen können im besten Fall sogar mehrere Lösungsgenerationen überdauern.
• Grobfeatures sollten nicht in zu vielen oder zu heterogenen Gliederungsebenen strukturiert werden. Grobfeaturegruppen möglichst Systemweit immer gleich tief zu schachteln und nicht mehr als vier Gliederungsebenen zu verwenden, erhöht merklich die Lesbarkeit des Gesamtdokumentes. Manchmal kann es sogar sinnvoll sein, eine Gliederungsebene nur in den Bezeichnungen zu verdeutlichen.
• Da eine essenzielle Beschreibung möglichst viele Weiterentwicklungen des Systems überleben soll, ist es sinnvoll, jedes sich mit hoher Wahrscheinlichkeit ändernde Element aus den Beschreibungen zu tilgen. Beispielsweise werden sich Zahlenwerte, unterstütze Sprachen, verwendete Standards, Aufzählungen, usw. haben eine relativ geringe Gültigkeitsdauer. Im weiteren Spezifikationsverlauf sind solche Festlegungen unerlässlich, aber um die Vorteile von Grobfeatures zu wahren sind unspezifische oder abstrakte Begriffe besser geeignet.
• Falls ein Satz aus der essenziellen Beschreibung ohne weiteres in eine Anforderung umgewandelt werden könnte, ist er wahrscheinlich zu detailliert oder zu lösungsorientiert. Entweder sollten solche Sätze getilgt oder durch eine abstraktere Formulierung ersetzt werden.
• Der Zeitraum, in dem anhand von Grobfeatures spezifiziert und diskutiert wird, sollte von vornherein klar begrenzt werden. Schließlich stellt eine Liste von Grobfeatures noch keine fertige Spezifikation dar und die für die folgenden Entwicklungsprozesse notwendige Detailspezifikation und deren Abstimmung ist weit zeitaufwändiger als die Erstellung von Grobfeatures.

*Hajo Hoffmann (sophist@sophist.de) unterstützt Kunden der SOPHIST GmbH als Berater und Systemanalytiker bei der Erstellung, Analyse und Optimierung von Use-Cases, Features und Anforderungen. Er sammelte vor seiner Zeit als SOPHIST umfangreiche Erfahrungen als Softwareingenieur. So kennt er viele Verfahren und Probleme aus der Entwickler-Praxis, was ihm bei der Betrachtung von Spezifikationen einen Blick „von innen“ ermöglicht.

(ID:283026)