Anforderungen strukturieren – 4. Das Informationsmodell

Heute der 4. Teil der Serie „Anforderungen strukturieren“ mit der Frage: „Wie gestaltet man eine Struktur mit mehreren Anforderungsdokumenten, Spezifikationen und anderen Anforderungsartefakten?“. Im sogenannten Anforderungs-Informationsmodell  wird definiert, welche  Anforderungsartefakte es im Projekt geben soll (z.B. welche Spezifikationen, Anforderungssammlungen, Dokumente, Testfälle, Architekturbeschreibungen etc.), und wie diese zusammenhängen. Es geht hier also nicht nur um die Anforderungen selbst und ihre Beziehung untereinander, sondern auch um die angrenzenden Artefakte. Das heisst, wie hängen Dokumente und Informationen aus der Entwicklung mit den Anforderungen zusammen. Das können Artefakte für Test, Architektur, Design, Schnittstellen, Code etc. sein.

Die Aufgabe des Informationsmodells ist,

• die notwendigen Anforderungsartefakte darzustellen,
• Beziehungen zwischen den Anforderungsartefakten zu definieren, und
• eine Grundlage für die teamübergreifende Kommunikation darzustellen.

Dies hat zum Ziel,

• ein einheitliches Vorgehen im Team zu ermöglichen,
• Anforderungen und andere Informationen einheitlich zu Artefakten zuzuordnen,
• Anforderungen in die richtige Abstraktionsebene einzuordnen,
• verschiedene Analysen zu ermöglichen, und
• unnötige Verlinkungen und Verlinkungstypen während des Entwicklungsprozesses zu vermeiden.

Je nach Umfang der Entwicklung sehen die Informationsmodelle ganz unterschiedlich aus. Im Folgenden stelle ich beispielhaft einige Möglichkeiten vor und beleuchte einzelne Aspekte.

Ein einfaches Informationsmodell

Ein ganz einfaches Informationsmodell (Abb. 1) zeigt die Anforderungsartefakte Kundenanforderungen, Systemspezifikation und Testspezifikation.

 

Es zeigt die Beziehungen dieser Artefakte zueinander, die dokumentiert werden sollen. Hier sollen z.B. die Anforderungen in der Systemspezifikation verlinkt (= verknüpft) werden mit denen der Kundenspezifikation, und zwar in der Bedeutung „Systemanforderung xx“ erfüllt „Kundenanforderung yy“. Anforderungen sind oft 1-zu-n oder m-zu-n verknüpft. In diesem Informationsmodell sollten nur diejenigen Kundenanforderungen verlinkt werden, die durch die Systemspezifikation wirklich erfüllt sind. Genau so sind auch die einzelnen Tests mit den Anforderungen in der Spezifikation verknüpft, die sie nachweisen sollen: „Test aa“ weist „Systemanforderung bb“ nach.

Verfolgbarkeit (Traceability)

Durch das im Vorfeld definierte Informationsmodell ist jedem im Team klar, welche Artefakte benötigt werden, sowie welche Verlinkungen durchgeführt werden.

Eine sinnvolle Verfolgbarkeit zwischen Anforderungen und Artefakten wird durch eine (konsequent durchgeführte) Verknüpfung ermöglicht. Verfolgbarkeit wird sogar in gewissen Standards und Normen gefordert (z.B. ISO12207, DO187, CMMI, SOX, SPICE,…). Denn mit einer Verfolgbarkeit lassen sich vielfältige Analysen durchführen:

Analysen durch Verfolgbarkeit

Wenn das Entwicklungsteam die Informationen nach dem Informationsmodell strukturiert und verlinkt, sind im Entwicklungsprozess zu jeder Zeit aussagekräftige Analysen möglich. IREB nennt vier Analysen:

• Die Auswirkungsanalyse zeigt auf, welche Artefakte durch eine Änderung beeinflusst würden.
• Die Herkunftsanalyse zeigt auf, WARUM ein bestimmtes Artefakt (z.B. Anforderung) existiert. Damit lassen sich z.B. „unnötige“ Anforderungen erkennen, die keine „Herkunft“, also kein „Warum“ haben.
• Die Abdeckungsanalyse zeigt auf, ob bei der Erfassung der Anforderungen und der darauffolgenden Entwicklungsartefakte alles berücksichtigt wurde, z.B. ob es für jede Anforderung auch einen Test gibt.
• Die Leistungswertanalyse zeigt den Arbeitsfortschritt auf, z.B. Anzahl der freigegebenen Anforderungen.

Teile-und-herrsche

Im zweiten Beispiel, Abb. 2 zeigt das Informationsmodell, wie ein System in seine Sub-Systeme zerlegt wird. Die Dekomposition eines Systems in Subsysteme dient ja in der Entwicklung, die Komplexität des Gesamtsystems zu reduzieren. Die Zerlegung kann nach unterschiedlichen Kriterien erfolgen. Üblich ist, ein System in seine „physikalischen“ Elemente zu zerteilen. Aber auch eine Aufteilung nach anderen Kriterien (s. Teil 1) ist möglich, wie nach Funktionen, nach logischen Einheiten.

 

Die Dekomposition beinhaltet auch die Unterteilung in Abstraktionsebenen, die nach einem bestimmten Kriterium ( Teil 1) durchgeführt wurden. In Abb. 2, sowie in Abb. 3 ist das Kriterium die physikalische Detailtiefe. Interessant dabei: Die physikalische Dekomposition spiegelt sich oft auch in der Organisationsstruktur eines Unternehmens wider, also wäre gleichzeitig das Kriterium „Organisationsstrukur“ anwendbar.

Abstraktionsebenen

Das Informationsmodell dient auch der Veranschaulichung von Abstraktionsebenen (Abb. 3) oder anderen hierarchisch gegliederten Sichtweisen.

 

In Abb. 3 ist nur ein vertikaler Strang gezeigt, natürlich haben wir auch hier in einem vollständig gezeigten Informationsmodell eine Baumstruktur.

Lastenheft vs. Pflichtenheft

Die doppelte Sicht auf ein System mit Lastenheft und Pflichtenheft bietet sich dann an, wenn zwei Unternehmen oder Organisationseinheiten zusammenarbeiten, und beide dabei ihre eigene Sicht in Form einer Anforderungsspezifikation brauchen. Der Auftraggeber schreibt dabei das Lastenheft und beschreibt, WAS er haben will. Der Auftragnehmer beschreibt im Pflichtenheft das selbe System, jedoch beschreibt er, WIE er es umzusetzen gedenkt.

Die zwei Parteien müssen nicht immer Auftraggeber und -nehmer, sondern können auch zwei (entferntere) Abteilungen sein. Dann spricht man auch von „Anforderungsgeber“ und „Anforderungsnehmer“.

 

Beide Spezifikationen haben das gleiche System im Fokus, jedoch unterscheiden sie sich in ihrer Sichtweise. Auch die Verantwortlichkeit, der Autor und der Erstellungszeitpunkt in Lasten- und Pflichtenheft sind unterschiedlich.

Zuerst wird das Lastenheft erstellt. Das Pflichtenheft kommt erst später. Beide Spezifikationen werden zwischen den Organisationseinheiten abgestimmt.

Übrigens: Aus Sicht des AuftragNEHMERS beschreibt das Pflichtenheft das WAS, und das Lastenheft beschreibt dann eher das WARUM bzw. WOZU. Die lokale Sicht Warum<-Was->Wie wiederholt sich so in jeder Abstraktionsebene.

Tests, Architekturen und andere Artefakte

Im nächsten Beispiel, Abb. 5 ist ein umfangreicheres Informationsmodell mit weiteren Artefakten dargestellt. Dieses eignet sich so übrigens durchaus als generische Vorlage für Ihr Informationsmodell und findet sich so oder ähnlich häufig in der Praxis.

 

Abb. 5 zeigt die Systemspezifikation (orange) mit ihrer Dekomposition in der Mitte. Oberhalb sind die „Input“-Requirements (gelb) der verschiedenen Stakeholder dargestellt. Aus der Systemspezifikation sind die Anforderungen an die Schnittstellen in ein extra Artefakt (grün) ausgegliedert, weil dessen Lebenszyklus, Detaillierungsgrad und Verantwortlichkeiten oft stark von denen der allgemeinen Systemanforderungen abweichen. Die Architektur- und Design-Dokumente (rot), die die Architektur-Entscheidungen von Abstraktionsebene zu Abstraktionsebene enthalten, sind mit den jeweiligen Spezifikationen verlinkt. Die Architektur-Dokumente enthalten üblicherweise Modelle, die Design-Entscheidungen beschreiben. Die Test-Dokumente (blau) sind auf jeder Ebene zu denjenigen Spezifikationen verlinkt (Verknüpfung nur angedeutet), die sie verifizieren.

Viele unterschiedliche Darstellungen

… sind zu finden, je nach Projektbedürfnis und Fokus. Informationsmodelle werden auch in der Forschung verwendet, um bestimmte Aspekte im Requirements und Systems Engineering zu verdeutlichen.

Zum Abschluss zwei Informationsmodelle aus der Literatur: Abb. 6 zeigt das Informationsmodell aus einer Veröffentlichung 2016 mit dem Titel „Traceability Usage and Adaptation in Practice“ [1]. Dort sprechen sie von einem „Traceability Information Model TIM“. Hier liegt der Fokus eher auf die Darstellung der Abstraktionsebenen und der Artefakttypen.

 

Eine weitere Literaturreferenz zeigt abstrakt die Ebenen und Dimensionen in einem Ansatz zum Variantenmanagement (in Abb. 7). Hier sieht man eine moderne und umfassende Definition der Abstraktionsebenen.

 

 

 

Fazit

En Informationsmodell bietet die Möglichkeit, die Struktur der Anforderungsartefakte darzustellen und zu definieren. Die Ziele und Möglichkeiten sind vielfältig, und der Nutzen ist groß. Gestalten Sie das Informationsmodell für Ihr System am Anfang des Projektes. Das führt zu einer einheitlichen Sicht bei allen Beteiligten.

Ach ja, und wenn  Sie mehr zum Thema „Anforderungen“ erfahren möchten, dann empfehle ich Ihnen, eines unserer beliebten Public Trainings zum Requirements Engineering oder Agile zu besuchen.

 

Literatur

[1] Seiler M, Kücherer C, Paech B, Traceability Usage and Adaptation in Practice, GI-Fachgruppen-Treffen Requirements Engineering (FGRE’15), Windisch/Zürich (Switzerland), November 26-27, 2015, Softwaretechnik-Trends, Band 36, Heft 3, GI 2015 PDF Download

[2] T. Schulte, M. Schneider, Th. Dickopf, L. Mayerhofer, „Erweiterung des integrierten Konzeptes aus Prozessrahmenwerk und Beschreibungssystematik von mecPRo2 um ein modellbasiertes Variantenmanagement“, Tag des Systems Engineering 2016, Hrsg. Gesellschaft für Systems Engineering GfSE, 2016

Series Navigation

<< Anforderungen strukturieren – 3. Die Spezifikation