Requirements Engineering Methoden

Anforderungen müssen 'atomar' sein, schreibt die einschlägige Requirements-Engineering-Literatur.

Nachdem ich in der Vergangenheit viele atomare Anforderungen geschrieben habe und vor einigen Jahren dann zu Use-Cases als Dokumentationswerkzeug übergegangen bin, möchte ich dem widersprechen.
Atomare Anforderungen mögen formal toll sein, nützlich sind sie nicht.

Mein Hauptkritikpunkt an atomaren Anforderungen ist die erschwerte Lesbarkeit. Dokumentation dient in erster Linie dazu, gelesen zu werden und sollte leicht lesbar und möglichst gut verständlich sein.
Insbesondere der Kontext einer Anforderung und die Zusammenhänge zwischen den einzelnen Anforderungen sollen IMHO leicht erfassbar sein können, um es dem Leser einfach zu machen, die Komplexität zu erfassen.
Aus einer Menge atomarer Anforderungen diese Komplexität zu erfassen, ist fast unmöglich für einen untrainierten Leser.

Lt. Wikipedia soll das Kriterium für ein "Atom" die Entscheidbarkeit einer Anforderung sein.
Formal gesehen muss also in einer Anforderung alle Information enthalten sein, um zu entscheiden ob sie erfüllt ist. Das heißt, der gesamte Kontext, insbesondere alle Vorbedingungen zum Erreichen der Anforderung, müssen in der Anforderung genannt sein!?

Da das viel zu aufwendig und nicht mehr lesbar ist, ergibt sich der Kontext meist aus den umstehenden Anforderungen. Oftmals gibt es für eine Handvoll zusammenhängender Anforderungen einen Übersichtsabschnitt, der den Kontext und den Zusammenhang der Anforderungen erklärt, bevor dann die einzelnen atomaren Anforderungen aufgezählt werden.
Dieser Übersichtsabschnitt ist demnach redundant zu den umstehenden Anforderungen, er bündelt nur die Einzelpunkte mit dem Ziel der Lesbarkeit. Manchmal nennt er auch ein übergeordnetes Ziel, die atomaren Anforderungen dann die Details.

Beiden Varianten würde ich die Integration der Informationen vorziehen. Ich lasse die Detailanforderungen weg und integriere sie in den Übersichtsabschnitt!

Alle potenziellen Leser profitieren von leichter Lesbarkeit. Selbst Tester, die atomar entscheiden sollen, ob eine Anforderung erfüllt ist, profitieren von den Zusammenhängen für ihre Testfälle.
Das einzige Szenario, das mir einfällt, in dem atomare Anforderungen notwendig sind, ist die Abnahme mit dem Anwalt – eine Situation, in die ich hoffentlich nicht kommen werde...

Projektkontext
Seit ca. 2 Jahren hatten wir für einen Kunden ein System in enger Zusammenarbeit mit den Anwendern entwickelt. Eine spannende Erfahrung, weil das entstehende System trotz seiner hohen Komplexität in relativ kurzer Zeit entstand. Dem System zur Modellierung von maschinell ausgeführten Workflows lag wegen seiner Komplexität eine online/offline SOA-Architektur zugrunde.
Mit dem Rollout des Systems sollte die Weiterentwicklung formalisiert werden um eine hohe Sicherheit für ein sicheres System zu erreichen. Dazu wurde eine vollständige Spezifikation (inkl. Oberflächen-Dokumentation), automatische Tests und zur Unterstützung der Anwender ein Benutzerhandbuch (separat) erstellt.
Um folgende Ziele zu erreichen, wurden die entstehenden Artefakte verknüpft (Tracing):

• Vollständigkeit herstellen (Tests, Handbuch, Oberflächen)‏
• Vollständige Abdeckung durch Tests sicherstellen
• Änderungen konsistent dokumentieren

Lösung
Für das Tracing führten wir Verknüpfungen der Artefakte Tests, Handbuch und Oberflächen-Dokumentation auf die Anforderungen ein:

• Tests -> Anforderungen
• Handbuch -> Anforderungen
• Oberflächen-Dokumentation -> Anforderungen

Wichtig für das Tracing-Konzept waren die Ziele, auf Basis derer wir festlegten, welche Informationen verlinkt werden mussten. Wir entschieden uns z. B. gegen ein Tracing innerhalb der Anforderungen, weil der Aufwand im Verhältnis zum Nutzen "Änderungen konsistent dokumentieren" unter den gegebenen Rahmenbedingungen nicht gerechtfertigt war.
Dem Kunden stellten wir das Konzept zum Tracing vor, wobei er den zusätzlichen Aufwand (jetzt und bei jeder Änderung) in Kauf nahm, die Links zu erstellen und zu warten.

Tool
Eine wichtige Erfahrung war, dass ein Tool unbedingt erforderlich war, die Ziele zu erreichen. Wir erstellten bereits Anforderungen und Tests als das Tool noch nicht einsatzbereit war. Zu dieser Zeit war es z. B. unmöglich, den Fortschritt des Projekts zu kontrollieren (Testabdeckung). Ein Tool ermöglichte außerdem, zusammenhängende Bestandteile mit hoher Sicherheit zu erkennen.
Wir setzten Microsoft SharePoint mit Listen für jedes Artefakt ein. Auswertungen führten wir mithilfe von Excel durch.

Vor einiger Zeit habe ich zusammen mit Chris Rupp und Frank Rachinger erforscht, ob sich ein Benutzerhandbuch als Spezifikation eignet (Vortragsfolien und Vortragsankündigung).
Die grundlegende Idee war, dass im Benutzerhandbuch eine funktionale Beschreibung aus Benutzersicht beschrieben ist - dieselbe Information, die schließlich auch in der Spezifikation landet. In unserem Artikel haben wir einen (theoretisch) gut funktionierenden Ansatz beschrieben, Aufwand zu sparen und dieselbe Information nur 1x zu dokumentieren - im Benutzerhandbuch.

In einem Projekt bei Spirit Link hatte ich jetzt die Gelegenheit, diesen Ansatz praktisch zu prüfen.
Vorweg: Wir haben uns zu Beginn dagegen entschieden, mit dem Benutzerhandbuch zu spezifizieren und zwei Dokumente geschrieben. Dennoch habe ich immer wieder an meine alten Forschungen gedacht und sie während des Projekts auf eine mögliche Umsetzung geprüft - immerhin hätte sie uns min. 30% des gesamten Aufwands gespart!

Wir haben uns aus folgenden Gründen dagegen entschieden:

• Benutzerhandbuch und Spezifikation haben unterschiedliche Leser.
  Das Benutzerhandbuch muss extrem gut verständlich sein, da es eine komplexe Applikation beschreibt und die Anwender teilweise wenig IT-Verständnis besitzen.
  Die Spezifikation ist für Projektbeteiligte (Auftraggeber und uns) und soll u. a. als formale Grundlage für die Weiterentwicklung dienen.
• Die Spezifikation ist eine formale Grundlage für Tests. Sie muss daher auf derselben detaillierten Abstraktionsebene komplett das gesamte System beschreiben.
• Die Sprache ist unterschiedlich - Prosa vs. Eindeutigkeit; Lesespaß vs. Exaktheit
• Die Detailtiefe ist unterschiedlich (z. B. keine Fehlerbeschreibung im Benutzerhandbuch, siehe Pyramide)

Gibt es andere Erfahrungen? Welche Voraussetzungen gibt es und wann sind diese tatsächlich einmal erfüllt?

In seinem Blog schreibt Rolf Götz über nicht-funktionale Anforderungen und die Abstraktionseben der Spezifikation ("Nonfunctional requirements and level of specification").
Zentrale Aussage des Artikels: "The higher the level of a system's requirements specification, the greater the portion of non-functional requirements."

Interessanterweise kann sich das ändern, wenn man einen anderen Scope betrachtet.
Für die Webapplikation Online-Shop ist z. B. die Conversion Rate, also die Zahl der Bestellungen je Besucher, eine nicht-funktionale Anforderung. Sie wird gemäß Rolfs Regel in konkreteren Spezifikationen durch einen Mix aus funktionalen und nicht-funktionalen Anforderungen detailliert.
Aus Sicht des Unternehmens ist die Conversion Rate jedoch die wesentliche Funktion der Applikation, Besucher zu einem Abschluss zu bewegen, also eine funktionale Anforderung.

Wikipedia definiert "Usability" als "Gebrauchstauglichkeit" in der Gesamtbetrachtung einer Software. Dies beinhaltet funktionale und nicht-funktionale Aspekte.
Klassische Software-Ingenieure kennen als "Usability" die nicht-funktionale Anforderung, die Wikipedia im Artikel über "Software Ergonomie" als die nicht-funktionale Eigenschaft einer Software definiert, wie die vorhandenen Funktionen genutzt werden können.

Im Artikel "Goal Oriented Requirements" bei Seilevel habe ich dieselbe Diskussion über Ebenen von Anforderungen gefunden wie in meinem Artikel "Abstraktionsgrad von Anforderungen". Die Kollegen von Seilevel treffen dieselbe Aussage, dass eine Anforderung sowohl Ziel als auch Teil der Lösung sein kann, abhängig davon ob man die Anforderungen darunter oder darüber betrachtet.
Ein wichtiger Hinweis ist, dass sich durch diese Beziehung von Anforderungen zur Lösungsbeschreibung, welche wieder Anforderungen für die nächste Ebene stellt, keine hierarchische Struktur von Anforderungen ergibt. Das Ergebnis ist mehr ein in sich zusammenhängendes Netz von Anforderungen.

Beim Lesen des Wikipedia-Artikels zum Lastenheft bin ich über ein Beispiel gestolpert, das mich zum Nachdenken gebracht hat:

• Das Lastenheft enthält die Kundenforderung: "Es soll ein bemanntes Labormodul für die ISS geliefert werden, das mit dem Space Shuttle dorthin transportiert werden soll."
• Der Auftragnehmer antwortet darauf mit der Spezifikation "Ein zylinderförmiges Druckmodul mit bestimmtem Durchmesser und Länge"

Die Spezifikation passt für mich noch nicht ganz mit der Anforderung zusammen.
Die beiden Anforderungen sind auf unterschiedlichen Ebenen der Pyramide:


Da fehlt mir eine Anforderung dazwischen. Oder?
Ein zylinderförmiges Druckmodul ist sicherlich ein Teil der Lösung der Anforderung oben.
Aber: Ist es ein Teil des Labormoduls oder der Transportverpackung?
Mir fehlt der Kontext der Anforderung. Schön wäre es doch, wenn eine Anforderung auf einer höheren Ebene existiert, die mir diesen Kontext gibt!?

Oder reicht es, die Anforderungen der unteren Ebene zu sammeln, wodurch ein Gesamtbild entsteht und schließlich die Frage beantwortet wird, wie die Anforderung des Kunden gelöst wird?
Allerdings wird es aufwendig, die ganze Spezifikation lesen zu müssen, um eine Anforderung zu verstehen...

Oder ist das Kapitel "Zusammenfassung" der Spezifikation genau die mittlere Ebene?

Interessant wäre außerdem eine Anforderung eine Ebene über der Lastenheftebene. Warum brauche die ISS das bemannte Labormodul? Ist das alte zu klein? Wird das alte ersetzt? Sollen damit neue wissenschaftliche Experimente unterstützt werden?
Abhängig davon stelle ich andere Fragen als Auftragnehmer.

Ein spannender Kommentar von Rolf Götz zum Artikel "Was und Wie" regt zum Nachdenken über Service-orientierte Archtektur (SOA) und Requirements Engineering an.

Ich denke, bei SOA sind Anforderungen für verschiedene Kontexte wichtig.
Zum einen im Kontext des Unternehmens, fokussiert auf die Geschäftsprozesse, zum anderen im Kontext jedes einzelnen Services.
- Unternehmenskontext: Welche Anforderungen ergeben sich durch die Geschäftsprozesse im Unternehmen an eine IT-Landschaft? Eine SOA hat den expliziten Auftrag, die Geschäftsprozesse duch Komposition verschiedener Services zu unterstützen.
- Service-Kontext: Die SOA zerlegt die Anforderungen des Unternehmens in verschiene Services und bildet die Anforderungen auf jeden einzelnen Service ab.
Die SOA beantwortet das "Was" der Anforderungen des Unternehmenskontexts durch ein "Wie" aus der Kombination von Services. Für jeden Service ergeben sich neue Anforderungen "Was".

Rolf: diese Kontexte sind andere Ebenen als die Abstraktionsebenen. Innerhalb eines Kontexts können Anforderungen auf allen Abstraktionsebenen formuliert werden.

In meinem (bislang einzigen expliziten) SOA-Projekt entwickelten wir eine modellbasierte Definition von Prozessen zur Bearbeitung von elektronischem Belegverkehr. Auf oberster Ebene bilden die Prozesse für Kunden sichtbare Verarbeitungsprozesse ab. Die einzelnen Schritte des Prozesses bestehen wiederum aus (technischeren) Prozessen. Prozesse rufen tiefere Prozesse, bis am untersten Ende Code-Routinen über Webservices gerufen werden. Die Tiefe der Aufrufhierarchie ist nicht im Voraus festgelegt.
Die IT stellt Services zur Verfügung, die von den Beratern vor Ort zu kundenspezifischen Verarbeitungsprozessen zusammengestellt werden.
Unsere Leistung war es, die möglichen Strukturen zu definieren, wie Prozesse und Webservices in Zusammenhang stehen können. Wir erstellten außerdem den Editor, mit dem die Prozesse erstellt und konfiguriert werden können.
In dieser Lösung gibt es die Geschäftsprozess-Sicht, deren Anforderungen durch die Berater beim Kunden definiert werden, sowie die Service-Sicht, die durch die Techniker in der IT zur Verfügung gestellt werden.

Für mich als Business Analyst ist SOA eine Besinnung auf die Regel, dass jede Software letztlich den Geschäftsprozess unterstützen muss. Die gesamte Software eines Unternehmens muss im Rahmen der Geschäftsprozesse nützlich sein und dazu zu einer Gesamt-Unterstützung für das Geschäft komponiert werden. Die IT hat den Auftrag, die Arbeit des Unternehmens zu unterstützen.
Die zahlreichen Artikel der Computerwoche zum Thema SOA und CIO haben genau das zum Thema, z. B. im Artikel "Prozessorientierung statt Produktionstiefe".
Ed Yourdon hat in seinem Blog im Artikel "CIO Insight’s predictions of 30 top IT trends for 2007" eine interessante Studie kommentiert, deren Top 1 Trend "Process improvement will be job No. 1" und Top 8 Trend "The division between IT and business will diminish" klar die Ausrichtung auf das Geschäft beschreiben.

Scheint so, dass mein Job als Business Analyst immer spannender und wichtiger wird :-)

Nicht-funktionale Anforderungen sind nach wie vor ein schwieriges Kapitel in jedem Pflichtenheft. Ich erlebe häufig, dass Kunden nicht an Qualität denken, bevor ich sie dazu zwinge ;-)
Schlimmer ist, dass sich auch viele Analytiker schwer tun, nicht-funktionale Anforderungen zu fassen.
In meinen letzten Projekten hatte ein paar spannende Berührungspunkte mit der Dienstleistungsqualität und so sind ein paar Gedanken entstanden, die ich hier in einen Artikel gieße.
Statt dem Begriff "nicht-funktionale Anforderungen" verwende ich gerne "Dienstleistungsqualität" oder allgemein "Qualität". Die Anforderungen klingen einfach zu sehr nach dem oberen Drittel der Abstraktionspyramide.

Qualität gibt es auf jeder Ebene
Qualität ist kein Ding von Lastenheften, die im Pflichtenheft durch eine funktionale Spezifikation "gelöst" werden.
Sicher gibt es Anforderungen, z. B. zur Sicherheit, die im Pflichtenheft (teilweise) durch Funktionalität gelöst werden, z. B. durch ein Login.
Im Allgemeinen gibt es aber auf jeder Ebene von Anforderungen ein "wie gut". (Siehe auch den lesenswerten Kommentar von Rolf Götz zum "Was und Wie".)
Z. B. lässt sich die Sicherheit nicht nur als Funktion beschreiben, die Sicherheitslücken schließt, sondern eben auch als Qualität des Codes, der keine Lücke offen lässt.
Ein anderes Beispiel ist die Erweiterbarkeit, die ein Kriterium von gutem Code ist.

Qualitätsanforderungen sind Risikofaktoren
Eine vergessene funktionale Anforderung führt zu Ärger und zu Nachbesserung. Eine vergessene Qualitätsanforderung führt zum Scheitern des Projekts!
In einem unserer Projekte plante unser Kunde eine Lösung für die interne Nutzung, besann sich dann gegen Ende des Projekts jedoch darauf, sie auch über das Internet jedermann zugänglich zu machen. Die Funktionalität blieb dieselbe, die Software musste nur ins Internet gestellt werden.
Niemand denkt an Sicherheitsaspekte, die plötzlich so wichtig werden wie die Funktionalität.
Plötzlich werden Qualitätsabteilungen hellhörig, die IT des Unternehmens wurde aufmerksam. Vorher unbeteiligte Personen schalten sich ein und die Software wird politisch relevant, die Kreise werden größer. Mit einem Mal ist eine erfolgskritische Anforderung "Sicherheit" relevant!
Unser Kunde ist baff und wir reden plötzlich mit vielen Menschen statt mit einem Kunden. Die Software muss (fast) neu geschrieben werden...

Qualitätsanforderungen sind einfach
Zumindest auf hoher Abstraktionsebenen ist es einfach, Qualitätsanforderungen aufzustellen. Damit sind zumindest die größten Risiken eines Projekts abgedeckt. Ich nutze eine Checkliste mit wenigen Aspekten wie Sicherheit, Usability, Effizienz, um die Anforderungen zu prüfen. Checklisten bieten z. B. DIN 66272 oder Volere.
Eine größere Herausforderung ist, die Qualität der Software messbar zu machen. Ich finde das Prinzip von GQM praktisch, ein anderer Ansatz ist Planguage von Tom Gilb.

Auf der EuroIA zeigte mir Casper Honijk in irgendeiner Diskussion ein Bild über Abstraktionsebenen von Anforderungen, das genauso wie meins aussah!
Was mich bestätigt, dass ich auf dem richtigen Weg bin :-)


Casper nutzt die Namen der Ebenen für die Kommunikation über seinen Konzeptions-Prozess mit seinen Kunden. Z. B. macht er deutlich, dass ein Lastenheft des Kunden nur die "Needs" beschreibt, bis zum Requirements aber noch viel Arbeit auch des Kunden nötig ist.

Interessant fand ich, dass er die verschiedenen Ebenen verknüpft und eine durchgängige Traceability erzeugt. (Würde mich sehr interessieren, dies in Aktion zu sehen – ich bin nicht überzeugt, dass Traceability grundsätzlich funktioniert!)
Auf diese Weise ist z. B. sichergestellt, dass ohne Needs keine Requirements entstehen. Findet der Analytiker kein Bedürfnis, wird auch keine Software dazu erstellt.

Die Namen der Ebenen sind einerseits eine gute Idee, allerdings würde ich sie anders benennen...
Gut, weil sie die Kommunikation mit Anwendern unterstützen. Die Namen sind einfach weitere Bezeichnungen neben "Lastenheft" und "Pflichtenheft".
Ich hätte die Needs "Requirements" genannt. Huch, die stehen ja wo anders...

Ein wundervoller Artikel von Mark Twain, Die schreckliche deutsche Sprache, in dem er die Untiefen und Besonderheiten der deutschen Sprache beschreibt. Absolut lesenswert für alle, die sich mit der deutschen Sprache beschäftigen.