Wie viel Anforderung ist nötig?

Fachdiskussion unter Business Analysten: Bei SEQIS beschäftigen sich täglich Experten mit der Tätigkeit der Anforderungsanalyse in Kundenprojekten. Aus der Erfahrung zeigt sich, dass die elementare Grundlage dieser Kompetenz – das Anforderungsdokument selbst – großes Diskussionspotential hinsichtlich Aussage und Wirkung auf den gesamten Entwicklungsprozess in sich birgt.

Das Schreiben einer Anforderung, Implementierung dieser in Programmcode und testen der korrekten Funktionsweise klingt wie die unausgesprochene Selbstverständlichkeit im täglichen Lauf eines Softwareentwicklungsprojekts. Die Erfahrung zeigt jedoch, dass diese vermeintliche Selbstverständlichkeit oft nicht von Beginn an gegeben ist. Speziell auf größerem Detaillevel und in komplexeren technischen und sozialen Systemen zeigt sich, dass persönliche Auffassung und Einstellung der einzelnen Rollen rund um die Softwareentwicklung erst sorgfältig aufeinander eingestellt werden müssen, ehe ein Verständnis vorliegt, das sich zumindest in mancher Hinsicht wie von selbst ergibt.

Definition ist Definitionssache

Aus Sicht des Anforderungsmanagements beruft man sich gerne auf eine sehr einfache aber auch eindeutige Faustregel um klarzustellen, was denn überhaupt durch eine Anforderung definiert werden soll. Diese Regel besagt, dass aus der Analyse eine schriftliche Vorgabe hervorgeht und was umgesetzt werden soll – während sich die Implementierung damit beschäftigt, wie diese Anforderung umgesetzt wird.

Unsere Experten sind der Meinung, dass diese Faustregel eine anschauliche Erklärung darstellt, in der Praxis jedoch selten von brauchbarem Nutzen ist. Denn selbst festzulegen, wie sich die Frage „Was ist umzusetzen?“ überhaupt abgrenzt, ist eine nicht lösbare Herausforderung. Stellen Sie sich vor, der Business Analyst erstellt ein Anforderungsdokument für einen Online-Shop. Bei oberflächlicher Betrachtung meint man, die Vorgabe, welche Produkte angeboten werden können und wie der Benutzer mit diesen interagieren kann, ist genau das, was zu entwickeln ist.

Aus Sicht des Entwicklers kann Information auf solch grobgranularer Ebene meist nicht zu einem zufriedenstellenden Ergebnis verarbeitet werden. Dieser benötigt da schon weitaus detailliertere Rahmenbedingungen, wie z.B. ob eine Einfach-Selektion (Radio-Button) oder eine Mehrfach-Selektion (Checkbox) angewandt werden soll. Für den Entwickler gibt auch diese Information noch keine Auskunft darüber, was er überhaupt tun soll. Für manch anderen handelt es sich dabei schon um die detaillierte technische Ausarbeitung, wie die gegebene Anforderung umgesetzt wird.

An diesem sehr trivialen Beispiel zeigt sich also bereits, dass Faktoren, wie besprochener Detailgrad, Rolle und persönliche Interpretation, keine ausreichende Abgrenzung zulassen, wieweit die Analysearbeit gehen und demnach die Anforderung beschrieben sein soll. Noch viel weiter entfernt ist folglich die Vorstellung, dass ohne Weiteres Selbstverständlichkeit über die Aufgaben und Ergebnisse aus Anforderungsanalyse, Entwicklung und Test herrschen kann.

Hands-On Agilität: Zuerst muss es das Team akzeptieren

Ein SEQIS Test Consultant berichtet über seine Wahrnehmung, dass in jedem Entwicklungsvorgehen die Rahmenbedingungen für effektives Arbeiten zuerst auf sozialer Ebene geschaffen werden müssen. Genauer gesagt muss ein gewisses Verständnis darüber herrschen, was ein Kollege vom anderen benötigt und was er von ihm realistisch zu erwarten hat. Bezogen auf ein Anforderungsdokument heißt es also z.B. den darin beschriebenen Detailgrad und die damit verbundene Auswirkung auf Personen, die mit diesem Dokument arbeiten müssen, zuerst zu erläutern und zumindest eine gewisse Richtung für einen gemeinsamen Arbeitsmodus zu vereinbaren. Entwicklung und Test müssen ein Gefühl dafür entwickeln, wann eine Anforderung unzureichend genau beschrieben ist, sodass weiter nachgefragt werden muss, und wann die nicht niedergeschriebene Semantik innerhalb eines Teams als Definition ausreicht. Jedem Mitglied eines Entwicklungsteams sei an diesem Punkt jedenfalls empfohlen, eher oft und wiederholt nachzufragen, als zu wenig. Viele Fragen schärfen im Weiteren das Verständnis und die Häufigkeit der Fragen wird sich reduzieren.

Für einen an der Diskussion beteiligten Business Analysten ist die beinahe systematische Kommunikation ohnehin das Mittel zum Zweck. Beispielsweise bietet das agile Projektmanagement-Modell Scrum ein Rahmenwerk, das den Kommunikationsaspekt umfassend und durchdacht aufgreift. Beginnend mit der Rolle des Product Owners (PO) soll es eine Instanz geben, die als Interessensvertretung des Auftraggebers die nicht veränderbaren Rahmenbedingungen vorgibt, also Verantwortung für die Definition eines Softwareprodukts trägt. In diesem Interesse sollte der PO unbedingt auch laufend während des Lösungsdesigns für Detailfragen zur Verfügung stehen. Ausgehend von dieser wesentlichen Rolle liegt es in der Kompetenz von Analysten, Entwicklern und Testern, eine aus der Vorgabe folgende Lösung zu entwerfen und solange daran zu feilen, bis ein unter konsolidiertem Verständnis entstandenes (Teil-)Produkt vorliegt, an dessen Korrektheit zumindest innerhalb dieses Personenkreises kein nennenswerter Zweifel mehr besteht.

Werkzeuge wie Sprint-Plannings, Schätztechniken wie Planning-Poker im Rahmen der Estimation-Meetings, Retrospektiven aber auch das bereits angesprochene darüber hinausgehende Maß an proaktivem „Nachfragen“ sind die essentiellen Bestandteile, die benötigt werden, damit eine Anforderung den gewünschten Nutzen beschreiben kann. Nur durch die ständige Auseinandersetzung und Reflexion der eigenen Auffassung zu einem Thema können die bereits erwähnten Risiken durch unabgestimmte Interpretation vermindert werden, was durch eine einzelne Person – unabhängig von deren Kompetenz – nicht zu bewerkstelligen wäre.

Die Kunst, Vorgaben und Freiheiten zu wählen

Die wohl am heißesten diskutierte Frage in der Expertenrunde der SEQIS Analyse-Mannschaft ist jene nach Detailgrad des Inhaltes einer Anforderung. Ausgehend von der Tatsache, dass es ganz offenbar keine allgemeingültige Formel gibt, was eine Anforderung tatsächlich definieren soll und darüber hinaus ein enormer Einfluss durch Projektumwelt und Persönlichkeit auf eine Gruppe einwirkt, stellt sich die Frage, was der Analytiker nun im konkreten in die Anforderung schreiben soll, damit Entwicklung und Test effizient und zielgerichtet arbeiten können und der Auftraggeber gleichzeitig ein zufriedenstellendes Produkt erhält.

Zwei unserer Business Analysen berichten aus ihrer täglichen Routine, Beschreibungen – in gewisser Hinsicht Anleitungen – für Programmierer und Tester zu erstellen. Die Erkenntnisse zeigen, dass in der Praxis oft mehr nötig ist, als ein fachliches Big Picture aufzuzeichnen. Die hierzu erwähnten Erfahrungen der beiden stammen u.a. aus einem System mit verteilter Architektur zwischen Backend-Anwendungen, einer verteilenden bzw. aufbereitenden Zwischenschicht und der Weiterleitung von dort zu mehreren unterschiedlichen Client-Anwendungen.

Wie sich vermuten lässt und auch eine unserer vorhergehenden QualityNews-Ausgaben (siehe Aktuelles) bereits veranschaulicht hat, spielen Schnittstellen zwischen diesen Komponenten eine sehr zentrale Rolle. Bei Erstellen einer neuen Anforderung stellt sich nun die Frage: Ist es Aufgabe der Analyse-Rolle Know-how und Dokumentationsbasis über die doch sehr detaillierten technischen Details aufzubauen? Oder ist es eher die Rolle des Entwicklers, der, wie bereits angesprochen, ja die Anforderung (was zu erledigen ist) umsetzt (wie er es erledigt)?

Was fängt dann jedoch im Folgenden der Tester mit einem programmiernahen Modell an, wenn durch zu viel Details der inhaltliche Konsens auf fachlicher Ebene fehlt? Für unseren Analysten ist klar, dass der Blick über den Tellerrand keine Fleißaufgabe sondern eine Notwendigkeit darstellt. Zu wissen, welche Parameter einer Schnittstelle entscheidend für das Ergebnis eines Algorithmus sind, einzelne Fehlercodes zu kennen und hin und wieder auch über die Entwickler-Schulter selbst in den Programmcode zu blicken, ist gut um zu verstehen und um auf derselben Wellenlänge kommunizieren zu können.

Weiters verbirgt sich oft noch auf solch einer Detailtiefe Potential zu grundlegenden Design- oder Interpretationsfehlern, deren Behebungskosten ja bekanntlich früher im Entwicklungsprozess weitaus kostengünstiger sind. Ein weiterer Test Consultant und Requirements Engineer bereichert die Runde durch seine Erfahrungen aus Sicht des Entwicklers: „Als Entwickler will ich nicht, dass mir jemand Algorithmen oder Datenmodelle vorgibt, jedoch möchte ich gerne Schnittstellendefinitionen, Mock-Ups oder auch Use-Cases erhalten.“ Eine klare Ansage also, die im Grundsatz dem zuvor beschriebenen Ansatz folgt und auch von unserem Systemanalyse 3.0-Fachmann unterstützt wird. Er hält die Sache so, dass Analyseergebnisse, die doch stark auf die technische Kompetenz hin zeigen, ganz klar als Vorschläge deklariert sind. Dadurch ist einer der möglichen Lösungswege auf jeden Fall schon mal vorhanden, Verbesserungsvorschläge haben aber immer Platz und sind auch erwünscht. Hier schließt sich nun auch wieder der Kreis zum notwendigen Maß an Kommunikation und Abstimmung, denn nur das gemeinsame Bild, resultierend aus unterschiedlichen Know-how Gebieten und Blickwinkeln, kann einer qualifizierten und konsolidierten Aussage des gesuchten „Bestmöglichen“ entsprechen.

Anforderer als stille Drahtzieher Ihres Projektes

Bei SEQIS agieren Business Analysten laufend im Projektalltag und sind somit unmittelbar und maßgeblich am Geschehen der Softwareentwicklung beteiligt. Unsere Erfahrungen von serverseitigen Anwendungen bis zur Mobile App zeigen, dass speziell im agilen Projektvorgehen das bloße Vorlegen von Anforderungsdokumenten ohne ein Einbinden in einen sinnvoll abgestimmten Prozess in vielerlei Hinsicht keine wünschenswerten Ergebnisse nach sich zieht.

Einer unserer Analysten musste feststellen, dass jede Definition nur so gut ist wie das Verständnis darüber, wie mit dieser umzugehen ist. Ist dies nicht gegeben, folgen nicht selten weitaus teurere Nacharbeiten aufgrund von unterschiedlicher Auffassung und zu geringer, manchmal aber auch zu detaillierter Tiefe der Anforderungsbeschreibung. Letztlich muss vor allem der Tester ein klares Bild des Soll-Verhaltens haben, um überhaupt ein aussagekräftiges Urteil über den Qualitätsstand abgeben zu können. Inhaltlich korrekte aber unvorteilhaft beschriebene Anforderungen sowie der fehlende „rote Faden“, die dieses Verständnis trüben und dadurch die Unabhängigkeit des Testers angreifen, können im Extremfall erheblichen Schaden in einer späteren Phase des Produktlebenszyklus verursachen, deren Behebungskosten wiederum vielfach höher sind, als sie es zum Zeitpunkt der Anforderungsdokumentation gewesen wären.

Unser Systemanalyse 3.0-Experte steuert der vorangehenden Diskussion einen weiteren ernstzunehmenden Faktor bei: Analyse ist per Definition auch ein Reifeprozess, daher ist eine der größten Gefahren, zu spät und an der falschen Stelle mit der Arbeit zu beginnen. Soll in einem Team etwas entwickelt werden, muss schon zuvor eine gut gehärtete Konzept-Basis vorliegen, die dann in einem finalen Schritt verfeinert und umgesetzt werden kann. Alternativ ist es aber möglich, die Analyse schon im Grobstadium an ein Entwicklungsteam zu übergeben. Dies hat den Vorteil, dass die letztendlich Tätigen der Umsetzung schon früh einbezogen werden, um relevanten Input zu geben und so das Risikopotential frühzeitig einzudämmen. Bei diesem Vorgehen muss aber jedenfalls eine sehr gute übergreifende Überwachungsinstanz agieren, um auf der Metaebene weiterhin das richtige Ziel zu verfolgen.

Eine Erfahrung jedenfalls können viele der Anforderer von SEQIS bestätigen: Durch die so elementare Stellung eines Anforderungsdokuments hat dieses einen enorm großen Hebel auf Prozessparameter wie Zeit und Qualität. Auch der Ersteller der Anforderung hat durch seine Eingliederung in der Prozesskette eine zentrale Stellung und damit ein breites Beobachtungsspektrum, das weit über die fachliche Systembeschreibung hinausgeht. Die Anforderungen in Ihrem Projekt richtig umzusetzen (hier sei bewusst unterschieden zu „die richtige Anforderung umsetzen“) und die umgebenden Einflüsse und Abläufe individuell einzustellen und laufend zu reflektieren erfordert viel Feingefühl, Vorarbeit und einen ausgeprägten Werkzeugkasten an Soft-Skills. Jedoch kommt nach Forming, Storming und Norming ja bekanntlich das, was dem großen Bestreben entspricht: Performing.