Wird Müll vorgegeben, kann daraus nur noch mehr Müll entstehen: Betrachten wir das Requirements Engineering (Anforderungsanalyse) aus Qualitätssicht, sollten wir genau diesen Gedanken im Hinterkopf behalten. Denn es handelt es sich hier um einen der wichtigsten Prozessschritte im Rahmen der Software-Entwicklung.
Oftmals erfolgen Projektstarts noch ohne klare Vision oder wirklich konkrete Zielvorgaben. Werden die Anforderungen dann nicht penibel und sauber erstellt, weiß das nächste Glied in der Prozesskette häufig nicht, was im Vorfeld tatsächlich gemeint war. Diese Mehrdeutigkeiten und Ungenauigkeiten können sich zu folgenschweren Fallstricken entwickeln. Einige davon wollen wir uns hier etwas genauer ansehen.
Requirements: funktional vs. nicht funktional
Sobald im Rahmen des Requirements Engineerings ein Ziel definiert wurde, und die Business Analysten beginnen, die Wünsche der Stakeholder aufzunehmen, werden sie mit zwei verschiedenen Arten von Anforderungen konfrontiert: Stakeholder formulieren funktionale und nicht funktionale Requirements.
Funktionale Anforderungen
Funktionale Anforderungen sind Anforderungen, die direkt in der Software umgesetzt werden und in der Regel eine Funktion für den Nutzer schaffen. Ein Beispiel hierfür wäre das Ablegen eines Produktes in einen Warenkorb. Solche Requirements sind klassische Anforderungen, da sie einen Kundenutzen bzw. eine Motivation des Kunden widerspiegeln. Doch selbst hier kann es zu Problemen kommen: Wurde etwa kein gemeinsames Glossar angelegt, um ein einheitliches Verständnis zu schaffen, können die Requirements bei den Business Analysten falsch ankommen.
Quelle: Vision11
Eine weitere potenzielle Fehlerquelle: Hinsichtlich einer bestimmten Funktion herrscht ein – vermeintliches – allgemeines Einverständnis. Unter der Annahme, dass alle Beteiligten ohnehin wüssten, worum es sich handelt, werden die entsprechenden Anforderungen daher nur knapp beschrieben. Genau das ist jedoch der mögliche Fallstrick. Denn das Wissen dahinter kommt bei den nachgelagerten Abteilungen nicht an. Ihnen fehlen also wichtige Informationen, die zur korrekten Umsetzung einer User Story relevant sind. Die Fehler, die aufgrund dessen entstehen können, fallen allerdings erst im Nachgang auf – mit potenziell gravierenden Folgen für die Kosten (siehe Grafik).
Nicht funktionale Anforderungen
Im Gegensatz zu den funktionalen Requirements gibt es auch nicht funktionale Anforderungen. Erfahrungsgemäß sind gerade diese besonders vertrackt. Und sie werden auch selten explizit benannt. Beispiele hierfür: Eine Software soll wenig Speicherplatz benötigen. Oder sie soll innerhalb einer angemessenen Zeit auf Benutzereingaben reagieren. Es handelt sich also nicht um Funktionen, die der Nutzer in der Software ausführt, sondern um kontextuelle Gegebenheiten, in denen sich die Software bewegt.
Quelle: Vision11
Und genau hier liegt der springende Punkt: Da diese Anforderungen implizit angenommen werden und jeder Stakeholder davon ausgeht, dass sie selbstverständlich seien, bleiben sie oft unausgesprochen. Selbst wenn sie tatsächlich am Rande erwähnt werden sollten, kommt es dennoch vor, dass die entsprechenden Anforderungen nicht messbar definiert werden. So könnte zum Beispiel vorgegeben werden, dass eine Software „in einer angemessenen Zeit“ reagieren soll. Für den Entwickler entsteht so ein Interpretationsspielraum, der sich z. B. von einer Sekunde bis zu einer Minute erstrecken kann. Und am Ende trifft er die Entscheidung allein, da im Vorfeld keine exakte Grundlage geschaffen wurde.
Funktionale Anforderungen
Nicht funktionale Anforderungen
= Direkte Funktion im System
= Nicht direkte Funktion im System
Beispiel: Ein User möchte einen Artikel in seinen Warenkorb legen,
um am Ende alle Artikel auf einmal zu kaufen.
Beispiel: Das System soll 10.000 Transaktionen pro Minute verarbeiten können.
Requirements Engineering: Keine echte Absicherung ohne klare Basis
Am Ende soll eine Software das machen, was sich der Kunde wünscht. Deshalb setzt man auf Qualitätssicherungsmaßnahmen – oft allerdings unter der Annahme, dass sich das Funktionieren der Software durch reines Testing sicherstellen ließe. Was aber passiert, wenn unsere Negativbeispiele aus dem Requirements Engineering – also lange vor dem Testen – tatsächlich eintreten? Sehen wir uns die möglichen Folgen an:
Basierend auf den Anforderungen und deren Akzeptanzkriterien erstellt das Testmanagement die Testfälle zur Absicherung der Software. Doch diese können nicht präzise formuliert werden. Es kommt zu Fragen und Missverständnissen. Durch diese Missverständnisse können Defects übersehen werden – und so z. B. falsch positive Testergebnisse entstehen. Eine andere mögliche Folge: Es werden Fehler gefunden, die gar keine sind – und dennoch zeitaufwändig besprochen werden müssen.
In beiden Fällen handelt es sich um vermeidbare Kosten. Besonders folgenschwer sind hier die falsch positiven Tests. Denn je später Fehler im Softwareentwicklungsprozess gefunden werden, desto höher die Kosten, die sie verursachen. Schließlich müssen alle vorhergehenden Stufen nochmals durchlaufen werden, um final als gefixt zu gelten. Das bedeutet: Zurück in die Analyse, zurück in die Entwicklung, zurück zum Testen und final zurück in die Produktionsumgebung …
Kosten der Fehlerbehebung bei fortschreitendem Entwicklungsprozess
Quelle: Vision11 nach 100 Minuten für Anforderungsmanagement
QS im Requirements Engineering: Auch ein Imagefaktor
Ein weiterer, nicht zu unterschätzender Punkt: Fehler, die erst auf dem Produktivsystem gefunden werden, ziehen nicht nur zusätzliche Entwicklungskosten nach sich: Gegenüber den Endkunden kann es auch zu Imageschäden in schwer zu beziffernder Höhe kommen. Ein Beispiel: negative Bewertungen in den App Stores, wenn Kunden durch ein Update Fehler finden. Dahinter liegen oftmals nur Kleinigkeiten, die sich durch gründliche Vorarbeit im Requirements Engineering leicht hätten vermeiden lassen.
Ein weiterer Risikobereich sind gesetzliche Neuregelungen zum Datenschutz, die zu einem bestimmten Zeitpunkt in die Software integriert sein müssen: Wird dies beim Erstellen der Anforderungen nicht entsprechend berücksichtigt, und im Produktivsystem kommt es hier zu Fehlern, dann kann es richtig teuer werden.
Zusammenfassung
Risiken…
- Kundenunzufriedenheit durch späte Lieferung
- Kundenunzufriedenheit durch falsch umgesetzte Anforderung (funktional und nicht funktional)
- Kein gemeinsames Verständnis über alle Beteiligten hinweg
- Exponentieller Kostenanstieg, je später ein Fehler gefunden wird
… und wie sie sich vermeiden lassen
- Vier-Augen-Prinzip: Anforderungen aus einem zusätzlichen Blickwinkel betrachtet
- Identifikation von Doppeldeutigkeiten, Unverständlichkeiten etc.
- Software-Updates: Identifikation von Fallstricken, die sich durch Neuerungen auf die restliche Software auswirken können
- Geringere Kosten durch frühzeitige Fehlervermeidung
Wirken QS-Experten im Requirements Engineering mit, eröffnet das Vier-Augen-Prinzip hier ganz andere Blickwinkel, um Missverständlichkeiten und potenzielle Fallstricke zu erkennen. Dabei bietet es sich auch an, Qualitätsmerkmale für die Anforderungen einzuführen. So entsteht ein sehr effizienter Hebel zur Qualitätssteigerung. Schließlich müssen diese Kriterien erfüllt sein, bevor eine User Story überhaupt erst an die Entwicklung weitergegeben wird.
Fazit: Qualitätssicherung von Anfang an
Zusammenfassend lässt sich ganz klar sagen: Mangelhafte Anforderungen im Requirements Engineering können eine ganze Reihe von Problemen verursachen, die sich in den nachgelagerten Prozessen exponentiell vergrößern. Im schlimmsten Fall richten sie massive Beeinträchtigungen auf dem Produktivsystem an (z. B. defekte Funktionen) – oder es kommt sogar zu Imageschäden. Werden Qualitätssicherungsmaßnahmen bereits vor der Testphase implementiert, lässt sich all das im Vorfeld vermeiden.
