Agilität und „Anforderungen“ an das Produkt

Veröffentlicht am von 0 Kommentare

Dieser Artikel über den Begriff „Requirement“ (Anforderung) hat mich im letzten Jahr zu folgendem Text inspiriert: https://medium.com/serious-scrum/the-big-misconception-in-scrum-46ff1b1780cb

Anforderungsanalyse bzw. Requirements Engineering ist im Grunde genommen ein „Handwerk“. Und wie jedes Handwerk entwickelt es sich lebendig weiter. Man kann es nicht zur Gänze in ein fixes Korsett aus Regeln und vordefinierten Abläufen pressen.

Für die Dokumentation gibt es gewisse „best practices“ wie z.B. Use Cases und/oder User Stories. Aber die Tätigkeit umfasst viel mehr als nur die geschickte Dokumentation von Daten, Funktionen und Abläufen eines IT-Systems.

Ein Zitat aus dem o.g. Artikel soll verdeutlichen, worum es mir in diesem Beitrag geht:

„What if all those requirements were not requirements at all?
As Marty Cagan puts it:
Customers think they have “requirements” but they’re just a hypothesis on what might solve some probably unstated problem.
Stakeholders have “requirements” that are really just their personal theories or assumptions on what might solve again a probably unstated problem.“

Softwareentwicklung ist ein fortgesetzter Dialog zwischen den zukünftigen Anwendern eines Systems und den IT-Fachleuten auf der Suche nach einer – unter gegebenen Rahmenbedingungen – geeigneten Lösung.
Wir produzieren keine Software in Serie, sondern wir entwickeln ein neues Produkt.

Requirements Engineering ist also ein Teil des kreativen, ja co-kreativen Dialogs, eingebettet in einen kooperativen, iterativen und inkrementellen Entwicklungs-Prozess. Am Ende dieses Prozesses sind die „Anforderungen“ mit ihren Akzeptanzkriterien im Wesentlichen dokumentiert. Die Dokumentation, z.B. in Form von User Stories, bildet die Phasen des Entwicklungsprozesses ab. Ergänzend dazu kann ein konsolidierter Stand laufend mitgeführt oder gegen Projektende nachdokumentiert werden.

Bis zum Projektende sind „Anforderungen“ oft nur Arbeitshypothesen, die es immer wieder zu verifizieren und zu hinterfragen gilt.
(Und letztlich gilt das in gewissem Ausmaß für den gesamten Lebenszyklus des IT-Systems, weil das System laufend weiterentwickelt wird und sich Anforderungen auch weiterhin verändern.)

Was steckt hinter den „Anforderungen“?

Eine zentrale Aussage aus einem Artikel über Kundenorientierung von Lothar Seiwert (der Link ist leider nicht mehr abrufbar) ist für mich die folgende:

„Kunden kaufen keine Produkte, sondern einen Nutzen.
Kunden wollen mehr als Produkte, sie wollen Lösungen.“

In der Anforderungsanalyse und im Design geht es genau darum. Zunächst gilt es, die Aufgabenstellung, die der Kunde mit Hilfe eines IT-Systems zu bewältigen hat, genauer kennenzulernen. Nach und nach lassen wir gemeinsam ein Bild einer geeigneten Systemunterstützung entstehen.

(In der Umsetzungsphase geht es darum, dieses wachsende Bild immer wieder mit der Realität abzugleichen und die Lösung auf ihre Gebrauchstauglichkeit hin zu evaluieren.
→ vgl. Lebendige Gestaltungsprozesse – Agilität, Usability, Design Thinking)

Anforderungsanalyse ist also ein fortlaufender Dialog über einen gemeinsam zu entwickelnden Gegenstand. Es ist ein zyklischer Prozess aus Analyse – Design – Umsetzung – Evaluierung/ Test. Ein Zyklus dauert idealerweise nicht länger als 4 Wochen.

Warum Arbeitshypothesen?

Die Benutzer haben eine mehr oder weniger genaue Vorstellung davon, was ihnen helfen könnte, ihre Aufgaben effizienter und effektiver zu erfüllen. Sie haben manchmal auch konkretere Vorstellungen davon, was sie brauchen, um zufriedener mit der IT-Unterstützung zu sein.

Menschen versuchen, sich Dinge vorzustellen, die sie noch nicht kennen. Sie versuchen, sich vorab schon ein Bild von der Lösung zu machen, um besser zu verstehen, was da gerade entsteht.

Diese Vorstellungen basieren auf persönlichen Erfahrungen. Grundlage bilden die Erfahrungen, welche die Menschen mit (anderen) IT-Systemen bisher schon gesammelt haben. Angenehme und unangenehme Erfahrungen.

Am Anfang des Projekts sind diese Vorstellungen von der zukünftigen Lösung noch sehr weit davon entfernt, was bis zum Ende des Prozesses entstanden sein wird.

„Wahrheit ist keine endgültige Aussage über etwas, sondern ein Schritt in die Richtung von Ent-Täuschung (undeception).“ (Erich Fromm)

Der Dialog über mögliche Lösungen hängt wesentlich von den Möglichkeiten und Rahmenbedingungen des gewählten Zielsystems ab.

Veränderlichkeit von Anforderungen

Die Begriffe „Anforderung„, „Lastenheft“ und „Pflichtenheft“ sind in der Softwareentwicklung seit vielen Jahren allgemein etabliert und üblich. Sie halten sich hartnäckig und zwar – meine Vermutung – weil der Mensch ein gewisses Bedürfnis nach Sicherheit und Kontrolle hat. Lastenheft und Pflichtenheft dienen letztlich dazu, die Anforderungen vor der Umsetzung möglichst genau festzulegen und Veränderungen „unter Kontrolle“ zu halten.

Das kostet sehr viel Zeit und Nerven und diese Vorstellung an sich ist hinderlich, denn:

Die „klassischen“ Begriffe „Lastenheft“ und „Pflichtenheft“ in der Anforderungsanalyse stellen Veränderungen als Ausnahme dar, obwohl dies der Erfahrung aus der Realität widerspricht. (Und dieser Widerspruch war schon immer spürbar.)

IT-Projekte sind komplexe Vorhaben. Lösungen werden über einen längeren Zeitraum hinweg entwickelt. IT-Projekte sind meist auch Auslöser für organisatorische Veränderungsprozesse.

Die Anforderungen verändern sich also im Projektverlauf mit hoher Wahrscheinlichkeit. Vieles kann anfangs noch nicht bis ins letzte Detail durchdacht und ausformuliert werden.

Das Gesamtbild wächst und verfeinert sich erst nach und nach – wie ein Baum, der sich unter günstigen Bedingungen aus einem Samen langsam entfaltet.

Anforderungen verändern sich, oft auch innerhalb kurzer Zeit. Der klassische Prozess mit formalen Change Requests ist oft viel zu umständlich und zu langsam, um angemessen auf diese Veränderungen zu reagieren.
Die sogenannte „Agile Softwareentwicklung“ schafft hier Abhilfe (→ vgl. Lebendige Gestaltungsprozesse – Agilität, Usability, Design Thinking).

Dialog- und Prozessorientierung

Die Aufgabe des Projektteams besteht darin, gemeinsam im Dialog die Bedürfnisse der Benutzer zu entdecken und innerhalb der Rahmenbedingungen (Zielsystem, Budget, grober Zeitrahmen, …) angemessene Lösungen zu finden.

Dazu brauchen wir Menschen, die gemeinsam folgende Fragestellungen klären wollen:

Welche Aufgaben soll das IT-System unterstützen und welche Ziele und Rahmenbedingungen sind dabei zu berücksichtigen?
(Analyse → „WOZU“ und „WAS“ der Lösung)

Welche die Eigenschaften des Zielsystems „passen“ zu den Anforderungen und welche Lösungen sind unter gegebenen Rahmenbedingungen mit vertretbarem Aufwand machbar?
(Design → das „WIE“ der Lösung)

Wie gut passt die vorgeschlagene Lösung zu den Aufgaben, so das die Anwender bei ihrer Arbeit gut unterstützt werden?
(Evaluierung →  Abgleich von WIE mit WOZU und WAS)

 

Zur Qualität der Anforderungsanalyse

Die Definition des Begriffs „Anforderung“ gem. IEEE Standard:

„Eine Anforderung ist

  1. eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
  2. eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente zu erfüllen.
  3. eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gem. Punkt 1 oder 2.“

Diese Definition sagt noch nichts darüber aus, wie die Anforderung zustande kommt.
Sie ist aber, wie der eingangs zitierte Artikel nahelegt, auch nicht völlig neutral zu sehen:

„The problem? In my 20+ yrs. experience in Software Development I have observed what Kent Beck called ”a connotation of absolutism and permanence
precluding us from having meaningful conversations. Conversations on problems, people and value.
Or, as Jeff Patton writes in this amusing anecdote “Requirements actually mean ‘shut up’ (and do)”.“

Chris Rupp stellt folgende Definitionen zur Verfügung (in „Requirements Engineering – ein Überblick“), die das Dialog- und Prozesshafte dieses Handwerks stärker hervorheben:

„Ein Stakeholder eines Systems ist eine Person oder Organisation, die (direkt oder indirekt) Einfluss auf die Anforderungen des betrachteten Systems hat.“

„Das Requirements Engineering ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist zu gewährleisten, dass:

  1. alle Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind,
  2. die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen,
  3. alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationsvorschriften spezifiziert sind.“

Ergänzt werden die Begriffe durch die Definition von „Usability“ (gem. DIN ISO 9241-11) und „User Experience“ (gem. DIN ISO 9241-210):

Usability ist das Ausmaß, in dem ein System durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.“

User Experience: Wahrnehmungen und Reaktionen einer Person, die aus der tatsächlichen und/oder der erwarteten Benutzung eines Produkts, eines Systems oder einer Dienstleistung resultieren. […] Dies umfasst alle Emotionen, Vorstellungen, Vorlieben, Wahrnehmungen, physiologischen und psychologischen Reaktionen, Verhaltensweisen und Leistungen, die sich vor, während und nach der Nutzung ergeben.“

Die klassischen Gütekriterien für die Anforderungsdokumentation wie

  • Objektivität,
  • Validität und
  • Widerspruchsfreiheit

fordern eigentlich Unmögliches, denn sie basieren auf der irrigen Annahme, dass sich das Problem zur Gänze objektiv, vollständig und widerspruchsfrei beschreiben lässt.

Dies ist bei komplexen Problemen aber nicht der Fall.

Aus meiner Sicht sind Verständlichkeit der Anforderungen, dokumentierte Abnahmekriterien und die anhand dieser Abnahmekriterien evaluierte Gebrauchstauglichkeit der Lösung geeignetere Qualitätskriterien.

Mit diesem Fokus lassen sich die anderen Gütekriterien im Rahmen des kooperativen, iterativen, inkrementellen Prozesses bis zum Projektende zumindest in hohem Maße abdecken.

Was entsteht ist eine „Konvergenz in Richtung angemessener Qualität„.

Verständlichkeit der Anforderungen und des Designs

Das „Haus der Verständlichkeit“ lt. Friedemann Schulz von Thun bietet dazu eine ganz gute Orientierung:

Die Berücksichtigung dieser Aspekte erhöht die Verständlichkeit der Beschreibung von Anforderungsdokumentationen.

Visualisierung und Verlebendigung (z.B. durch Bilder der Benutzeroberfläche und Beispiele aus dem täglichen Leben der Benutzer usw.),
einfach verständliche Sprache und die Orientierung an den Begriffen der Zielgruppe sind die essenziellen Gestaltungskriterien für einzelne User Stories.

Gliederung/ Orientierung sind zudem wichtig, um nicht den Überblick über die Gesamtheit der Anforderungen im Product Backlog zu verlieren.

Kürze und Prägnanz verhindern, dass wir uns verzetteln und den Überblick verlieren. Sie helfen uns auch dabei, Verschwendung (Aufwand, der durch unübersichtliche und unverständliche bzw. redundante Beschreibungen entsteht) zu vermeiden. Verschwendung entsteht oft durch ein überhöhtes Sicherheitsbededürfnis, wenn man anfängt, jede Kleinigkeit zu dokumentieren, auch wenn sie unwichtig ist.

Gebrauchstauglichkeit der Lösung

Hinsichtlich der Evaluierung der Gebrauchstauglichkeit der Lösung können wir uns z.B. an folgenden groben Leitfäden orientieren:

Heuristiken von Jacob Nielsen (http://www.nngroup.com/articles/ten-usability-heuristics) und

die im Folgenden beschriebenen Gestaltungsgrundsätze und Designprinzipien wie z.B. Konsistenz und Ästhetik (weitere Designprinzipien finden sich in der einschlägigen Literatur und im IBUQ Lehrplan).

Aufgabenangemessenheit

Ein interaktives System ist aufgabenangemessen, wenn es den Benutzer unterstützt, seine Arbeitsaufgabe zu erledigen.

Selbstbeschreibungsfähigkeit

Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog und an welcher Stelle im Dialog er sich befindet, welche Handlungen unternommen werden können und wie diese ausgeführt werden können.

Erwartungskonformität

Ein Dialog ist erwartungskonform, wenn er den aus dem Nutzungskontext heraus vorhersehbaren Benutzerbelangen sowie allgemein anerkannten Konventionen entspricht.

Steuerbarkeit

Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.

Fehlertoleranz

Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann.
Fehlertoleranz wird mit den Mitteln erreicht:

  • Fehlererkennung und –vermeidung (Schadensbegrenzung),
  • Fehlerkorrektur oder
  • Fehlermanagement, um mit Fehlern umzugehen, die sich ereignen

Individualisierbarkeit

Ein Dialog ist individualisierbar, wenn Benutzer die Mensch-Maschine-Interaktionen und die Darstellung von Informationen ändern können, um diese an ihre individuellen Fähigkeiten und Bedürfnisse anzupassen.

Lernförderlichkeit

Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen der Nutzung des interaktiven Systems unterstützt und anleitet.

Anforderungsdokumentation als Teil der Systemdokumentation

Spätestens gegen Ende eines IT-Projekts stellt sich die Frage, ob und wie die Anforderungsdokumentation als Basis für Weiterentwicklungen dienen kann.

Aus meiner Sicht stellt die Anforderungsdokumentation mit User Stories vor allem ein Abbild des Entwicklungsprozesses dar. Sie ist zu ergänzen durch eine kurze und prägnante Zusammenfassung des jeweils letzten Standes der Anforderungen.
Das lauffähige System, der Programmcode, Systemdokumentation und Benutzerhilfen bilden zusammen mit der Anforderungsdokumentation die Basis für Weiterentwicklungen.

Die Herausforderungen in der Wartung und Weiterentwicklung ergeben sich vor allem aus der zunehmenden Komplexität von IT-Systemen.
Die Schwierigkeiten im Umgang mit der – ebenso zunehmend komplexen – Dokumentation sind nur ein Symptom in dieser Situation.

Das Thema Systemdokumentation wäre aber schon wieder einen eigenen Artikel wert.

 

 

 

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.