Anforderungen strukturieren – 2. Techniken

Im letzten Blog „Anforderungen  strukturieren – 1. Kriterien“ haben wir vorgestellt, welche Kriterien für die Strukturierung von Anforderungen relevant sind. Heute stellen wir Ihnen im 2. Teil dieser Blog-Serie ein paar Ideen und Konzepte vor, die die Anforderungsstrukturierung ermöglichen. Wir wollen die Frage beantworten: „Welche technischen Möglichkeiten gibt es, um Anforderungen zu strukturieren?“

Dazu stelle ich Ihnen folgende Techniken vor:

1. Implizit
2. Kapitel
3. Dokumente
4. Attribuierung
5. Verlinkung
6. Reihenfolge

Wenn wir Anforderungen gruppieren, legen wir bestimmte Kriterien an, wie wir im letzen Blogbeitrag dieser Serie beschrieben haben. Mit einem Beispiel von ausgewählten Anforderungen aus einer Spezifikation für eine “intelligente Armbanduhr” wollen wir das verdeutlichen:

...

Kundenanf-2:

Die Uhr soll bei sportlichen Tätigkeiten unterstützen.

Kundenanf-3:

Die Uhr muss die Herzfrequenz des Trägers messen können.

Kundenanf-5:

Die Uhr muss als Taschenrechner verwendbar sein.

Kundenanf-7:

Das Armband der Uhr muss vom Benutzer ausgetauscht werden können.

Kundenanf-19:

Die wasserdichte Version der Uhr darf maximal 7% schwerer sein 
als die nicht-wasserdichte Uhr.

...

1. “Ohne” Technik: Implizit:

In einer impliziten Strukturierung werden verschiedene Gruppen namentlich im Fließtext erwähnt. Sie sind allerdings nicht ausdrücklich als „Gruppe“ identifiziert, sondern sie müssen vom Leser als Gruppeneinteilung interpretiert werden. In diesem Fall werden die Anforderungen für die Funktion in Anforderungen für Funktionen der Uhr („Die Uhr muss…“) und an das Armband („Das Armband der Uhr muss…“) gruppiert. Außerdem wird zwischen den Varianten Uhr allgemein, wasserdichte Uhr und nicht-wasserdichte Uhr implizit unterschieden.

Der Gegensatz zu „implizit“ ist „explizit“: Es wird ausdrücklich eine Gruppierung vorgenommen. Alle folgenden Techniken sind explizite Techniken:

Technik 2: Kapitel

Um Anforderungen nach Kriterien zu gruppieren, kann man eine Kapitelstruktur verwenden. Eine Strukturierung durch das Einordnen der Anforderungen in verschiedene Kapitel und Unterkapitel könnte im Beispiel so aussehen:

Kap. 1: Ziele

Kundenanf-2: Die Uhr soll bei sportlichen 
             Tätigkeiten unterstützen.

Kap. 2: Nutzerfunktionen 

   Kundenanf-3: Die Uhr muss die Herzfrequenz des
                Trägers messen können.

   Kundenanf-5: Die Uhr muss als Taschenrechner 
                verwendbar sein.

Kap. 3: Anforderungen an das Design

Kundenanf-7: Das Armband der Uhr muss vom 
             Benutzer ausgetauscht werden können.

Kap. 4: Anforderungen an die Systemkomponenten

Kundenanf-19: Die wasserdichte Version der Uhr 
              darf maximal 7% schwerer sein 
              als die nicht-wasserdichte Uhr.

Eine Kapitelstruktur bietet die Möglichkeit, nach mehr als einem Kriterium zu gruppieren. Die Hauptkapitel lassen sich weiter nach Belieben untergruppieren.

Kapitelstrukturen sind besonders nützlich, wenn man Textverarbeitungsprogramme als RE-Tool benutzt. Spezielle RE-Tools bieten jedoch noch weitere technische Möglichkeiten.

Technik 3: Dokumente

Bei einer großen Menge von Anforderungen macht es Sinn, Anforderungen nicht nur in Kapitel, sondern auch in verschiedene Dokumente aufzuteilen. Als “Dokument” betrachte ich nicht nur das physikalische Dokument aus Papier und Bleistift/Druckertinte, sondern auch das elektronische “Dokument” in einem Computer. Hier kann man “Dokumente” in unterschiedlichen Formaten erzeugen, abhängig vom Programm, das man benutzt. In Textverarbeitungsprogrammen sind es Textdateiein, in Excel sind es Tabellen und Tabellenblätter, in DOORS sind es Module, und so weiter. Jedes Tool hat da seine eigenen “Dokumente”.

Besonders hilfreich ist die Trennung in Dokumente, wenn der „Lebenszyklus der Anforderungssets“ stark unterschiedlich ist. Zum Beispiel stehen die Anforderungen, die Ziele beschreiben, schon früher fest, als die konkreten Designanforderungen.

Des Weiteren empfiehlt es sich auch, wenn verschiedene „Detaillierungsgrade bzw. Abstraktionsebenen“ vorhanden sind. Oft sind diese zwei Kriterien Lebenszyklus und Abstraktion stark verknüpft. Zum Beispiel ist es sinnvoll, Anforderungen an das Gesamtsystem („Uhr“) und Anforderungen an die entsprechenden Komponenten („Armband“) in zwei Dokumente zu trennen. Die Anforderungen an das gesamte System stehen meist früher fest, weil sie auf einer höheren Abstraktionsebene formuliert sind. Die konkreteren Anforderungen an die Komponenten entstehen oft danach, oder werden im Detail erst später fertig.

Unterschiedliche Lebenszyklen von Anforderungssets können auch auf derselben Abstraktionsebene sein. Ein typischer Fall sind  Schnittstellenbeschreibungen. Sie existieren normal innerhalb der Systemanforderungen. Hier können zwei getrennte Dokumente von Vorteil sein. Schnittstellenanforderungen will man vielleicht später noch präzisieren, während die allgemeinen Systemanforderungen schon längst festgelegt und abgestimmt sein sollten.

Technik 4: Attribute

RE-Tools bieten das vorteilhafte Konzept von Attributen. Das bedeutet, für alle Anforderungen gibt es zusätzliche einheitliche Kategorien, um ergänzende Informationen hinzuzufügen. Einfach gesagt, in einer Tabelle mit Anforderungen in den Zeilen gibt es Spalten, in denen man zusätzliche Informationen ablegen kann. Diese Attribute lassen sich nutzen, um Anforderungen Gruppen zuzuordnen.

 Die Uhr muss die Herzfrequenz des
 Trägers messen können.

Funktion

Standard

Kundenanf-5

 Die Uhr muss als Taschenrechner 
 verwendbar sein.

Funktion

Standard

Kundenanf-7

 Das Armband der Uhr muss vom 
 Benutzer  ausgetauscht werden 
 können.

Komponente

Standard

Kundenanf-19

 Die wasserdichte Version der 
 Uhr darf  maximal 7% schwerer 
 sein  als die nicht-wasser-
 dichte Uhr.

System

Premium

Attribute sind eine sehr vorteilhafte und effiziente Möglichkeit, Anforderungen zu verschiedenen Gruppen zuzuordnen. Durch die tabellarische Form bleibt es sehr übersichtlich. Mit Datenbanken lassen sich spezielle Sichten bilden, in denen man entweder Anforderungen nach bestimmten Kriterien oder Gruppen filtert und anzeigt.

Technik 5: Verlinken

Eine weitere Möglichkeit, die RE-Tools bieten, ist die Verlinkung, bzw. Verknüpfung. Anforderungen werden dabei logisch (und oft auch graphisch) mit einem anderen Element (oft aus einem anderen Dokument) verknüpft.

Will man zum Beispiel die Uhrenanforderungen nach Nutzerszenarien gruppieren, kann man das mit Verknüpfungen der Anforderungen und der Szenarien (in einem zweiten Dokument) realisieren:

Der Vorteil von Verlinkung ist, dass die Gruppierung, also hier die Nutzerszenarien, viel zusätzliche Informationen wie Beschreibungen der Szenarien, Bildern etc. enthalten kann. Dies ist bei der Technik “Attribuierung” nicht so einfach möglich, denn hier ordnet man nur ein Schlagwort oder einen Begriff zu. Verlinkung kann man auch gut mit anderen Techniken der Strukturierung kombinieren.

Technik 6: Reihenfolge

Eine einfache Art der Strukturierung ist die Reihenfolge, allgemeiner: die örtliche Gruppierung.

In einer Liste ordnet man die Anforderungen in ihrer Reihenfolge, bezüglich eines Kriteriums, z.B. der “Wichtigkeit”. Dann stehen oben die wichtigsten und unten die unwichtigsten Anforderungen.

Vorteil der Reihenfolge ist, dass man eine (unendlich) fein abgestufte Gruppierung abbilden kann. Die Reihenfolge lässt auch schnelle Änderungen ohne viel Aufwand zu.

In der agilen Entwicklung wird diese Technik bei Scrum angewandt. Die umzusetzenden Anforderungen stehen in einer Liste von Anforderungen, die dort „Backlog“ genannt werden. Ganz oben stehen die Anforderungen, die für den nächsten Sprint am meisten relevant sind. Weiter unten stehen die nicht so wichtigen oder noch nicht so detailliert formulierten Anforderungen.

Die “Reihenfolge” funktioniert nur für ein bis zwei Kriterien gleichzeitig, z.B. „zeitliche Dringlichkeit“ (1 Kriterium), oder „Wichtigkeit für Umsetzung im nächsten Sprint“ und „Detaillierungsgrad“ (wie im „Backlog“ bei Scrum).

Generell lassen sich die Anforderungen auch 2-dimensional gruppieren, z.B. als Post-Its auf einem Task-Board oder in einem Kanban-Board. In der agilen Entwicklung wird dies benutzt, um die Anforderungen, die gerade umgesetzt werden, nach Umsetzungsgrad und ein bis zwei weiteren Kriterien umzusetzen. Ein Beispiel zeigt das folgende Bild für die Gruppierung nach den Kriterien Umsetzungsgrad (horizontal) und Wichtigkeit (vertikal):

Fazit

Jede Technik hat seine Vorteile. Und besonders durch kombinieren der verschiedenen Strukturierungstechniken bekommt man extrem viel Übersichtlichkeit in seine Anforderungen. Dabei unterstützen RE-Tools mit speziellen Möglichkeiten der Strukturierung. Wir unterstützen sie dabei natürlich auch, wenn sie es wünschen!

Im nächsten Teil geht es dann darum, wie und nach welchen Kriterien man Anforderungen innerhalb einer Spezifikation strukturieren kann.

Wenn Sie sich weiter mit dem Thema “Anforderungen” auseinandersetzen möchten, empfehle ich Ihnen, eines unserer beliebten Trainings zum Requirements Engineering zu besuchen. Ob der Intensivworkshop zur IREB® CPRE-Foundation Level Zertifizierung, CPRE Advanced Level, oder das Training zum Certified Agile Requirements Specialist (CARS), es ist sicher etwas für Sie dabei. 

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.