Share ZU:
27 September 2018 @ Dr. Thaddäus Dorsch

Wie detailliert muss ich spezifizieren?

Dieser Frage widme ich mich heute, eine der oft gestellten Fragen in unseren Kursen.

Der Ausgangspunkt

Der Ausgangspunkt des Ganzen ist zuerst das zu spezifierende System. Was umfasst das System, für das Anforderungen formuliert werden sollen? Ist dies einmal klar umrissen, mit System, Systemkontext und irrelevanter Umgebung, dann stellt sich die Frage:

Auf welcher Abstraktionsebene möchte ich spezifizieren?

Diese Frage hängt eng mit der Architektur (auch bezeichnet als Design, Systemstruktur) zusammen, die als Grundlage für die Spezifikation dient. Habe ich mir noch keine Gedanken über Lösungen und Lösungsansätze (u.a. die Architektur) gemacht, bewege ich mich auf der Ebene der Vision (bewege mich also ganz stark im “Problembereich”). Es existiert nur eine ungefähre Vorstellung von der Basis-Architektur des Systems. Bin ich auf Systemebene, und habe ich schon detaillierte Vorgaben, wie die Struktur meines Systems aussieht, agiere ich im Bereich der Komponenten-, Detail- oder technischen Lösungsebene (d.h. ich agiere stark im “Lösungsbereich”).
Zum Thema “Abstraktionsebenen” kann ich übrigens folgende Blogbeiträge empfehlen: Gedanken lesen, Strukturieren und Traceability und Anforderungen strukturieren mit dem Informationsmodell.

Die Frage der Abstraktionsebene wird normalerweise von den Fachexperten, Designern oder Architekten vorgegeben.

Twin Peaks oder Zic-Zac Modell

Im idealen Wasserfallvorgehen werden zuerst die Anforderungen in allen Detailebenen entwickelt. Danach wird die Systemarchitektur entworfen. Dies entspricht häufig nicht der Realität [Pohl 2010], [Cleland-Huang et al. 2013] und stellt sich als unpraktikabel heraus.

Die Architekturebenen werden üblicherweise schrittweise und iterativ entwickelt, genauso wie die zugehörigen Anforderungen. Wie das vor sich geht, verdeutlicht das Twin-Peaks oder Zic-Zac Modell:

Die Anforderungen und die Architektur eines Systems prägen einander gegenseitig. Zuerst existieren abstrakte Anforderungen (u.a. Ziele, Vision, etc.), aus denen eine erste Grobarchitektur des Systems entsteht. Aus dieser Architektur ergeben sich dann detailliertere Anforderungen, aus denen wiederum die Architektur verfeinert wird, usw.

Abb. 1 zeigt diesen Zusammenhang  im sog. Twin-Peaks-Modell nach [Nuseibeh 2001]. Vertikal ist der Detaillierungsgrad der Systembeschreibung aufgetragen. Die horizontale Achse beschreibt die zunehmende Ausrichtung von der Problembeschreibung zur Implementierung.

 

Twin Peaks Modell
Abb. 1: Twin Peaks Modell nach [Cleland-Huang et al. 2013]
Iterativ entsteht eine detaillierter werdende Anforderungsbeschreibung und
parallel eine stabiler werdende Architektur des Systems (vgl. auch [ALRM]).

Je nach Fortschritt der wechselseitigen Entwicklung der Anforderungen und der Systemarchitektur existiert immer eine der Spezifikation zugrundegelegte “Basisarchitektur”.

Hat man die grundlegenden “Randbedingungen”, die die vorhandene Basisarchitektur stellt, identifiziert, kann man mit weiteren Anforderungen die Entwicklung des Systems vorantreiben.

Die Form der Anforderung ist dabei übrigens völlig egal. Sie kann agil, klassisch, textuell, modellbasiert usw. sein.

Aber wie genau muss ich nun spezifizieren?

3 wesentliche Kriterien

Dazu helfen 3 wesentliche Kriterien, an denen man sich orientieren kann. Diese sind auf jegliche Form, Typ oder Abstraktion einer Anforderung anwendbar, d.h. sie helfen bei Visionen, Zielen, Szenarien, User Stories, Epics, Use Case Diagrammen, etc.

Kriterium 1: lösungsneutral wie möglich

Schreibe die Anforderungen so, dass die restlichen Freiheitsgrade für die Lösung unerheblich sind und immer zur geforderten Lösung und Zielerfüllung führen.

Das WAS sollte in der Anforderung gut beschrieben sein, basierend auf der zugrundeliegenden Basisarchitektur. Das WIE sollte nur soweit beschrieben sein, dass es “unerheblich” ist, wie die Anforderung im Weiteren umgesetzt oder detailliert wird.  Das WIE wird erst in der tieferliegenden Ebene beschrieben. Siehe auch unseren Blogbeitrag Unschärfe zulassen, oder wie weit können Sie in die Zukunft schauen und Langfristig dokumentieren im agilen Umfeld.

Kriterium 2: gemeinsames Verständnis

Schreibe die Anforderungen so, dass  gemeinsames Verständnis über alle Stakeholder in Bezug auf die Anforderungen erreicht wurde. Jedem soll klar sein, was gefordert wird. Wenn alle Beteiligten mit dieser Anforderung einverstanden sind, das Gleiche verstehen, und die richtige Umsetzung damit sichergestellt ist, dann ist es egal, wie “gut” die Anforderung geschrieben ist.
Hier könnte der Blogartikel Requirements Engineering für die 3 Amigos von Uwe Valentini für Sie interessant sein.

An dieser Stelle ist noch einmal zu hinterfragen, was das Ziel der Anforderung sein soll. Anforderungen dienen immer der Kommunikation, die jedoch unterschiedliche Reichweiten haben kann. Dient sie nur zur kurzzeitigen Kommunikation und Unterstützung der Umsetzung, und wird sie nur “intern” im Entwicklungsteam verwendet, genügt ein gemeinsames Verständnis des “Schreibers” und des “Lesers” bzw. “Empfängers” der Anforderung. Dies ist oft bei User Stories aus einem Backlog im agilen Umfeld der Fall.  Soll jedoch die Anforderung zum Wissensspeicherung, Wiederverwendung und Wissenstransfer dienen, sind auch “zukünftige Leser” der Anforderung als Stakeholder involviert, und eine eher ausführlich und allgemein verständliche Formulierung kann sehr wichtig sein. Siehe auch unseren Blogbeitrag Langfristig dokumentieren im agilen Umfeld.

Kriterium 3: Testbarkeit

Als drittes Kriterium sollte die Anforderung soweit spezifiziert sein, dass diese gegen die spätere Lösung eindeutig von den jeweiligen Stakeholdern überprüfbar und/oder testbar ist.

Das Entscheidende beim Spezifizieren ist doch, dass ein Produkt entsteht. Insofern hilft es sehr, die Kriterien zur “Abnahme” in die Anforderung mit aufzunehmen. Was sind also die Kriterien, so dass die Stakeholder mit der Umsetzung zufrieden sein werden? Wie soll die Anforderung konkret getestet werden? Speziell bei User Stories ist es üblich, Akzeptanzkriterien hinzuzufügen. Damit wird auf einfache Weise die Testbarkeit gewährleistet. Hierzu empfehle ich den Blogbeitrag von Philip Stolz Anforderungen mit User Stories und Akzeptanzkriterien.

Fazit

Anforderungen und Systemarchitektur bedingen sich gegenseitig und entwickeln sich iterativ weiter. Dadurch entwickeln sich Anforderungen (und Architekturbeschreibungen) auf unterschiedlichen Abstraktionsebenen. Orientieren Sie sich auf jeder Ebene an drei Kriterien, wenn Sie Anforderungen erfolgreich formulieren wollen:

  • Die Anforderung ist so lösungsneutral wie möglich und beschreibt nur das “WAS”. Die Umsetzung (das “WIE”) ist nur so detailliert wie nötig.
  • Ein gemeinsames Verständnis aller Stakeholder ist erreicht
  • Die Anforderung is eindeutig testbar.

So sollte es nun leichter sein, die richtige Detailtiefe einer Anforderung zu finden.

Möchten Sie mehr zum Thema “Anforderungen” erfahren? Dann empfehle ich Ihnen, eines unserer beliebten Public Trainings zum Requirements Engineering oder Agile zu besuchen.

Literatur

[ALRM]   IREB, CPRE Advanced Level Requirements Management – Lehrplan, https://www.ireb.org/de/downloads/#syllabus-cpre-advanced-level-requirements-management

[Pohl 2010] K. Pohl: Requirements Engineering – Fundamentals, Principles, Techniques. Springer, 2010

[Nuseibeh 2001] B. Nuseibeh: Weaving the Software Development Process between Requirements and Architecture. In: Proc. of ICSE2001 Workshop STRAW-01, Toronto, May 2001.

[Cleland-Huang et al. 2013] J. Cleland-Huang, R. S. Hanmer, S. Supakkul, and M. Mirakhorli: The
Twin Peaks of Requirements and Architecture. IEEE Software, vol. 30, no. 2, pp. 24-29, MarchApril, 2013

 

Dr. Thaddäus Dorsch

Kontaktieren Sie Dr. Thaddäus Dorsch

Dr. Thaddäus Dorsch ist als Trainer, Berater und Coaching im Bereich Requirements Engineering und agiler Systementwicklung bei der HOOD Group tätig. Seine Schwerpunkte sind modernes Systems Engineering und effizienter Umgang mit Anforderungen, Vorbereitet sein auf den digitalen Wandel, sowie neu Ansätze in der Systemtheorie und die Kombination von klassischen und agilen Denkweisen und Techniken. Thaddäus Dorsch schöpft aus seiner langjähriger Erfahrung in der Systementwicklung in den verschiedensten Branchen wie Telekommunikation und Biotech, Automotive, Mobilfunk, Luft- und Raumfahrt, Verteidigung, Print und Multimedia.