Share ZU:
30 March 2017 @ Dr. Thaddäus Dorsch

Anforderungen strukturieren – 1. Kriterien

This entry is part 1 of 4 in the series Anforderungen strukturieren

Die Teilnehmer unseres Trainingsangebotes bringen häufig ein konkretes Problem aus ihrem beruflichen Umfeld mit. Viele wollen wissen, wie man gute Anforderungen schreibt, andere wollen einfach die Grundlagen umfassend kennenlernen, die bei dem Umgang mit Anforderungen notwendig sind, sei es im klassischen oder agilen Umfeld.

Eine der häufigsten Fragen lautet: „Ich habe da eine Menge Anforderungen von verschiedenen Seiten in meinem Projekt. Wie strukturiere ich am besten diese heterogenen Anforderungen?

Auf diese Frage gibt es keine einfache Antwort. Mit einem „Kommt drauf an“, wird sich auch niemand zufriedengeben.

Die jeweilige Situation in den Unternehmen, Unternehmensbereichen, Projekten oder Abteilungen ist in der Regel sehr unterschiedlich. Dies betrifft Rahmenbedingungen sowie Ziele. Daher gibt es keine einheitliche „Standardlösung“ für alle. Dies ist genau so, als würden Sie gerne kochen lernen wollen. Dazu konsultieren Sie einen Koch, und bitten ihn, ihnen ein einziges, allgemein gültiges Kochrezept zu nennen, mit dem man hervorragende Speisen zubereiten kann.

Ein guter Koch und Lehrmeister wird antworten, dass er diese Frage nicht mit einem einzigen Kochrezept beantworten möchte. Würde man einen Koch in einer  Imbissbude fragen, könnte man jedoch folgendes Rezept zu hören bekommen: „Ich mache das immer so: Nimm ein Brötchen deiner Wahl. Teile das Brötchen horizontal, toaste beide Teile im Toaster. Lege dann zwischen die beiden Brötchenhälften verschiedenste Zutaten, wie Frikadellen, Wurst, eine Scheibe Käse, Salatblatt, Tomatenscheibe. Füge eine Soße hinzu, wie Ketchup oder Mayonnaise. Serviere das Ganze schließlich auf einem Teller zusammen mit einem Getränk.”

Wären Sie glücklich mit dieser Anleitung? Für den Anfang lassen sich aus solchen Vorschriften (die man verbessern und verfeinern kann) durchaus einige schmackhafte, aber auf die Dauer doch nur langweilige Burger zusammenstellen. Ein richtiger Feinschmecker-Koch wird dadurch aus Ihnen (aufgrund dieser Anleitung) bestimmt nicht.

Daher vermeide ich ein „Rezept“ für die Strukturierung von Anforderungen. Sie wollen ja mehr, als nur Burger zubereiten.

Individuelle RE-Projekte unterscheiden sich stark voneinander, so dass es unmöglich ist, eine Musterlösung zu liefern, die jeden zufriedenstellt. Hilfreich dagegen sind ein paar Grundsätze, die ich ihnen garnieren möchte mit unterschiedlichen Sichtweisen auf die Anforderungen. Prinzipien und Grundsätze helfen, besser eine individuelle Lösung zu finden. Das ist, wie wenn der Koch Ihnen erklärt, für welche Gerichte Sie welche Geräte verwenden, welche Grundsätze des guten Geschmacks helfen und welche Zutaten zum Gelingen notwendig sind, um ein ganz eigenes und gelungenes Gericht zuzubereiten.

Um zu vermeiden, dass Sie nur Burger und Sandwiches im Anforderungsmanagement kochen müssen, habe ich das Thema „Anforderungen strukturieren“ in mehrere kleine Blogs aufgeteilt. Ich werde dazu unterschiedliche Aspekte betrachten, und ich hoffe, dass Sie damit einen guten Weg zu ihrer höchstpersönlichen 5-Sterne-Anforderungsstruktur finden.

Vier Aspekte

Es gibt vier wichtige Aspekte, die Sie analysieren sollten. In den folgenden Blogs werden Sie zu jedem der folgenden Aspekte ein paar Ideen finden. Dort werde ich kurz beleuchten:

  1. Kriterien für die Anforderungsstrukturierung: Warum will oder muss man Anforderungen strukturieren, welche Kriterien sind denn in der Praxis relevant?
  2. Arten der Anforderungsstrukturierung: Welche technischen Möglichkeiten gibt es denn, Anforderungen zu strukturieren?
  3. Anforderungsstrukturierung innerhalb einer Spezifikation
  4. Das Anforderungs-Informationsmodell: Wie gestaltet man eine Struktur mit mehreren Anforderungsdokumenten, Spezifikationen und anderen Anforderungsartefakten?

Heute zum ersten Aspekt:

Teil 1: Kriterien für die Anforderungsstrukturierung

Warum muss man Anforderungen strukturieren, welche Kriterien sind denn in der Praxis relevant?

Ein paar häufige Kriterien möchte ich heute aufzeigen: Das Ziel von einer Sammlung von Anforderungen liegt darin, ein System soweit vollständig zu beschreiben, dass daraus erfolgreich ein Produkt (darunter verstehe ich auch Dienstleistung oder Software) entstehen kann, das die Kunden zufriedenstellt. Mit „Kunden“ meine ich alle Stakeholder des Systems, nicht nur den Endnutzer. Und das führt uns zum ersten Kriterium für die Strukturierung von Anforderungen:

Kriterium 1: Unterschiedliche Sichten der Stakeholder

Es ist üblich, die Anforderungen nach unterschiedlichen Sichten der Stakeholder zu gruppieren. Ein komplexes System lässt sich dadurch besser in den Griff bekommen, wenn man unterschiedliche Sichten auf das System einnimmt. Somit gliedern Sie die Anforderungen nach den Sichten der Stakeholder, wie zum Beispiel: Nutzeraspekte, Sicherheitsaspekte, Gesetze und Normen, Schnittstellen des Systems, Systemfunktionen, usw. Wählen Sie die Sichten so aus, dass sie zusammen alle notwendigen Aspekte des Systems abdecken.

Es gibt orthogonale Sichten, d.h. Sichten die sich ergänzen, z.B. Hardwareanforderungen und Softwareanforderungen. Die Sichten in orthogonale Sichten aufzuteilen, eignet sich dort, wo Sie eine geometrische oder physikalische Unterteilung des Systems in Subsysteme vornehmen. Hierbei denken Sie bitte an die Definition der Schnittstellen zwischen diesen Subsystemen. Mit so einer Aufteilung lassen sich Anforderungen gut in unterschiedliche Dokumente oder Kapitel aufteilen.

Meist treten dazu noch querschnittliche Sichten auf, z.B. funktionale Sichten (Kundenfunktionen, Use Cases, Nutzeranforderungen), die mehrere Subsysteme betreffen. Ein weiteres Beispiel sind Sicherheitsanforderungen. Diese eher „logischen“ Sichten ergänzen die orthogonalen Sichten sehr gut. Speziell die funktionalen Anforderungen eignen sich, um das System zu testen. Mit den querschnittlichen Sichten können Sie auf zwei Arten umgehen (auch gleichzeitig): Entweder Sie ergeben zusätzliche Anforderungen mit den Anforderungen orthogonalen Sichten, oder Sie nehmen die funktionale Sicht als Input, um weitere Anforderungen in der „orthogonalen“ Struktur zu ergänzen. Letzteres kann Sinn machen, wenn man aus konzeptuellen Modellen (wie UML Diagrammen) Anforderungen ableitet, die dann den Anforderungen der einzelnen Subsysteme zugeordnet werden.

2. Kriterium: Organisationsstruktur

Oft werden die Anforderungsspezifikationen nach Abteilungen der eigenen Organisation, der Firmenstruktur gegliedert. Dies macht nur bedingt Sinn. Gliedern Sie ihre Anforderungen lieber nach der Systemstruktur selbst. Denn Organigramme können sich ändern, ohne dass sich die Systemstruktur verändert. So vermeiden Sie das stetige Anpassen der Anforderungsstruktur an die Firmenstruktur. Eine Überlappung wird trotz allem meist vorhanden sein, da die Firmenstruktur sich durchaus an verschiedenen Sichten auf das System (s.o.) orientiert – aber eben nie konsequent durchgängig.

 

Orientieren Sie sich auch an einem weiteren Kriterium:

3. Kriterium: Lebenszyklus der Anforderungen

Gerade wenn es darum geht, ob ich Anforderungen in ein oder mehrere Dokumente, Module etc. gruppiere, ist dieses Kriterium hilfreich. So zum Beispiel hat die Hardware in der Regel einen längeren und weniger häufigen Erneuerungszyklus als die dazugehörigen Softwareversionen.

Zum Beispiel könnten Sie Anforderungen an die Schnittstellen, getrennt von den anderen Systemanforderungen, halten. Wenn die Systemanforderungen (zumindest die auf höherer Abstraktionsebene) feststehen, werden sich voraussichtlich die Details der Schnittstellen noch öfter ändern. Vielleicht ist es sicher, dass das System eine Datenschnittstelle zur Wartung haben muss (Systemanforderung), jedoch noch nicht, welcher Typ des Anschlusses es werden soll, mit welcher Spannung und welchem Strom. Und welche Signale da darüber laufen und wie diese aussehen, wird möglicherweise erst sehr spät in der Software-Implementierung festgelegt.

Anforderungssätze, die sich unterschiedlich schnell ändern, oder zu unterschiedlichen Zeitpunkten oder unterschiedlich oft freigegeben werden, sollte man in unterschiedlichen Gruppen, Modulen oder Dokumenten halten.

4. Kriterium: Anforderungsform oder -art.

Wenn man Gruppen von Anforderungen hat, die eine unterschiedliche Art, Sprache oder Form haben, weil sie an verschiedene Stakeholder gerichtet sind, dann kann man durchaus die Anforderungen diesbezüglich strukturieren. Anforderungen mit vielen CAD Zeichnungen sind für die Mechaniker gedacht und können in „Mechanik-Spezifikation“ zusammengefasst werden.

Vorsicht! Nach rein formalen Kriterien würde ich die Anforderungen nicht gruppieren. Es gibt jedoch einen deutlichen Hinweis, wenn die Form extrem unterschiedlich ist. Hat man z.B. textuelle Prosa-Anforderungen und Anforderungen in stark technischer Sprache gemischt, lässt sich vermuten, dass die Anforderungen sortiert und getrennt werden sollten.

Die häufig gemachte Unterscheidung zwischen funktionalen Anforderungen und den sog. Qualitätsanforderungen bzw. nicht-funktionalen Anforderungen würde ich nicht strikt trennen. Thematisch gehören diese oft zusammen. Funktionale Anforderungen sind gut testbar, und können so für die Entwicklung weiterbenutzt werden. Qualitätsanforderungen haben die Eigenschaft, dass sie meist noch weiter detailliert werden müssen. Dabei können durchaus weitere funktionale Anforderungen entstehen.

5. Kriterium: Abstraktionsebene

Eine wichtige Unterscheidung ist die Abstraktionsebene, d.h. die Detailebene, die den Lösungsraum immer weiter einschränkt.
Wieviel Details sind spezifiziert, so dass auf der jeweiligen Ebene die AnfordVerfolgbarkeit von Anforderungenerung nach der  Implementierung erfolgreich getestet (verifiziert) werden kann.

Betrachten wir folgendes Beispiel.

Eine Anforderung auf höchster Abstraktionsebene, „Vorstandsziele“ heisst:

„Das Gehäuse muss rot sein.“

Für die Produktanforderungen formuliert jedoch der Produktmanager die gleiche Anforderung schon präziser:

„Das Gehäuse muss rot in RAL 3001 sein.“

Für die Lackierer mag es immer noch ungenügend sein. Es ist ihm nicht klar, ob matt oder glänzend, und auch nicht, in welcher Stärke. Daher könnte die Anforderung auf der Ebene einer „Lackier-Spezifikation“ heissen:

„Das Gehäuse muss rot glänzend, mit Farbregister RAL 841-GL lackiert sein, 
in einer Dicke von 1,o mm.“

Die Abstraktionsebenen werden im 4. Teil “Informationsmodell” noch näher beleuchtet.

Ich freue mich, wenn Sie meiner kleinen Serie folgen, und ich hoffe auch auf Ihre Rückmeldungen und Erfahrungen damit.  Es wäre spannend, auch Ihre Sicht kennenzulernen. Bitte benutzen Sie dazu die hier im Blog vorgesehene Kommentarfunktion.

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 ZertifizierungCPRE Advanced Level, oder das Training zum Certified Agile Requirements Specialist (CARS), es ist sicher etwas für Sie dabei. 

Series NavigationAnforderungen strukturieren – 2. Techniken >>

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.