Assumption Debt: Die unsichtbare Falle im Systems Engineering
Viele kennen bereits „Technical Debt“, doch was ist Assumption Debt? Dabei geht es nicht um unsichere oder schlechte Technologie, sondern um implizite, veraltete oder unüberprüfte Annahmen.
In diesem Artikel geht es um:
- Was ist Assumption Debt?: Implizite oder veraltete Annahmen können zu ernsthaften Problemen in der Produktentwicklung führen.
- Technical Debt: Technische Schulden entstehen durch bewusste Kompromisse, Assumption Debt dagegen oft unbemerkt.
- Warum Assumption Debt wichtig ist: Ungeprüfte Annahmen können zu Fehlfunktionen, Sicherheitsrisiken oder Projektverzögerungen führen.
- Kontext: Annahmen entstehen aus dem Systemkontext—ist dieser unklar oder verändert sich, steigt das Risiko für Assumption Debt.
- 6 Schritte zum Umgang mit Assumption Debt: Ein strukturierter Umgang mit Annahmen hilft, Risiken frühzeitig zu erkennen und zu vermeiden.
- Fazit: Wer den Kontext kennt und Annahmen systematisch behandelt, reduziert stille Risiken und erhöht die Systemqualität.
Was ist Assumption Debt?
In der Produktentwicklung müssen wir Annahmen treffen. Doch viele, für unser Produkt wichtige Annahmen, werden gar nicht festgehalten. Das ist auch völlig ok: Autos funktionieren nur mit Schwerkraft, doch niemand würde auf die Idee kommen, die Annahmen zu dokumentieren, dass wir Gravitation mit 9,81 m/s² haben.
Dennoch gibt es genug Annahmen, die dokumentiert werden sollten. Oft werden wichtige Annahmen auch festgehalten, doch die können veralten.
Solche Annahmen wirken oft wie blinde Flecken: Sie beeinflussen Architektur, Anforderungen und Entscheidungen, ohne dass sie sichtbar oder bewusst gemacht werden. Und das kann zu Problemen führen.
Eine Anekdote aus der Bahntechnik: Die Annahme, dass Passagiere nur im Wagen reisen, sollte dokumentiert und hinterfragt werden. In manchen Ländern ist es nicht ungewöhnlich, dass Passagiere auf dem Dach mitreisen. Das kann bspw. zu Problemen mit der Belüftung führen (Lufteinlass auf dem Dach wird blockiert).
Foto: Wikimedia Commons, CC BY-SA 3.0
Technical Debt
Zum besseren Verständnis hilft, sich den Unterschied zu den bekannteren Technischen Schulden vor Augen zu halten.
Technical Debt ist eine in der Informatik gebräuchliche Metapher für die Probleme von schlechter technischer Umsetzung von Software. Das passiert insbesondere in der Frühphase einer Entwicklung, wenn viele technische Fragen ungeklärt sind.
Zum Beispiel könnte sich das Team entscheiden, ein initiales Admin-Passwort vorzugeben, Es gibt genug Ansätze, auf einem anderen Weg das initiale Passwort zu setzen. Aber solange der korrekte Ansatz nicht implementiert wurde, bestehen diese technischen Schulden. Das Problem: Allzu häufig werden die technischen Schulden niemals getilgt.
Hier ein einfacher Vergleich von Technical Debt und Assumption Debt:
| Kriterium | Technical Debt | Assumption Debt |
|---|---|---|
| Ursprung | Bewusste oder pragmatische technische Kompromisse (z. B. Quick Fixes, schlechter Code) | Implizite oder ungeprüfte Annahmen |
| Erkennbarkeit | Meist sichtbar im Code, in Architektur oder Dokumentation | Oft unsichtbar, nur durch Analyse aufdeckbar |
| Bewältigung | Refactoring, Re-Engineering | Validierung, Assumptions Logs, Workshops |
| Risiko | Erhöht Wartungskosten, Instabilität | Kann zu Fehlentscheidungen oder Projektversagen führen |
| Beispiel | „Wir verzichten vorerst auf Tests.“ | „Die Umweltbedingungen bleiben konstant.“ |
Warum Assumption Debt wichtig ist
Gerade im Systems Engineering, insbesondere in sicherheitskritischen Branchen, können unerkannte Annahmen böse Folgen haben. Insbesondere handelt es sich bei Assumption Debt oft um unerkannte Mängel. Diese entstehen über die Zeit hinweg, ohne dass sie jemand klar benennt oder systematisch prüft.
Ein typisches Beispiel ist die Annahme, dass bestimmte Umweltbedingungen wie Temperatur oder Vibrationen konstant bleiben oder irrelevant seien. Wird diese Annahme nicht hinterfragt und später durch eine veränderte Einsatzumgebung widerlegt, kann das zu Ausfällen oder sicherheitskritischen Situationen führen. Noch problematischer ist, dass Annahmen häufig nicht dokumentiert werden. Sie leben in Köpfen, Meetings oder E-Mails, verschwinden mit Personalwechseln und tauchen erst dann wieder auf, wenn es zu spät ist.
Teams, die einen hohen Reifegrad haben, nutzen vernünftige Anforderungsmanagementwerkzeuge, mit denen auch Annahmen über Traceability verfolgt werden. Hier besteht die Gefahr, dass relevante Anforderungen übersehen werden.
Doch genug Organisationen haben lediglich eine dokumentenbasierte Traceability, bei der Annahmen oft gar nicht dokumentiert werden, oder durch die fehlende feingranulare Traceability veralten können.
Kontext
Annahmen entstehen in der Regel im Kontext, und sollten daher auch dort erhoben werden. Wenn der Systemkontext nicht klar, konsistent und vollständig definiert ist, dann entstehen oft auch Probleme mit den Annahmen. Dann fließen Annahmen oft in Anforderungen, Architektur oder Tests ein, als wären sie faktisch gesichert.
Besonders kritisch wird es, wenn sich der Kontext ändert—etwa durch neue Märkte, geänderte gesetzliche Vorgaben oder eine Verschiebung im Nutzungsszenario. Ohne ein strukturiertes Vorgehen zur Identifikation und Pflege von Kontextannahmen entsteht genau dann schnell Assumption Debt. Ein sauber definierter und kommunizierter Systemkontext wirkt daher wie ein Schutzfilter: Er verhindert, dass individuelle oder veraltete Annahmen unbemerkt zur Grundlage technischer Entscheidungen werden.
6 Schritte zum Umgang mit Assumption Debt
Um mit Assumption Debt umgehen zu können, müssen wir die bewusste Entscheidung treffen, diese zu verfolgen. Ihre Dokumentation, Überprüfung und Pflege muss genauso ernst genommen werden wie Anforderungen, Architekturentscheidungen oder Tests.
1. Annahmen identifizieren
Am Anfang steht die systematische Erfassung. In frühen Phasen eines Projekts (insbesondere bei Definition des Kontexts) ist es hilfreich, in jedem Meeting, bei jedem Architekturentscheid und bei jeder Anforderungsdiskussion gezielt nach Annahmen zu fragen. Typische Einstiegssätze lauten: „Was glauben wir, aber wissen es nicht sicher?“ oder „Worauf basiert diese Entscheidung genau?“ Es hilft, diese Annahmen in einer separaten Liste oder in einem eigenen Abschnitt der Systemdokumentation zu führen, oder als eigenständiger Item im RE-Werkzeug.
2. Annahmen explizit machen
Eine implizite Annahme ist kaum überprüfbar. Daher sollten alle erkannten Annahmen in klarer Sprache formuliert werden. Ein Beispiel: Statt „Das Fahrzeug wird nur auf öffentlichen Straßen betrieben.“ sollten wir hinterfragen, warum dies relevant ist. Also bspw. der Ausschluss von Offroad-Betrieb, auf Testgeländen oder in tropischen Klimazonen.
3. Annahmen bewerten
Nicht alle Annahmen sind gleich kritisch. Deshalb empfiehlt sich eine Bewertung nach zwei Kriterien: Unsicherheit und Auswirkung. Je höher die Unsicherheit und je gravierender die potenzielle Auswirkung bei Fehlschlag, desto höher die Priorität für Validierung oder Monitoring.
4. Validierung planen
Kritische Annahmen müssen so früh wie möglich validiert werden. Das kann durch Tests, Simulationen, Expertenbewertungen oder Datenanalysen geschehen. Der Validierungsaufwand sollte dabei in Relation zur Risikoeinschätzung stehen. Wichtig ist, die Validierung nicht dem Zufall oder dem Projektverlauf zu überlassen, sondern sie gezielt einzuplanen.
5. Annahmen überwachen und pflegen
Annahmen sind nicht statisch. Was heute plausibel erscheint, kann morgen durch neue Informationen überholt sein. Daher ist es wichtig, Annahmen regelmäßig zu überprüfen. Idealerweise erfolgt dies in Reviews, bei Meilensteinen oder immer dann, wenn sich Rahmenbedingungen ändern. Auch hier übernehmen RE-Werkzeuge diese Aufgabe, bei dokumentenbasiertem Arbeiten ist dies über ein Assumptions Log möglich.
6. Annahmen kommunizieren
Annahmen sollten für alle relevanten Stakeholder sichtbar sein, nicht nur für die Entwickler oder Systemarchitekten. Wenn das gesamte Team weiß, auf welchen Hypothesen ein Konzept basiert, kann es frühzeitig Hinweise auf Widersprüche oder neue Erkenntnisse geben. Das fördert nicht nur die Systemqualität, sondern auch das gemeinsame Verständnis.
Fazit
Assumption Debt ist ein oft übersehenes Projektrisiko: Es entsteht aus Annahmen, die nicht dokumentiert, veraltet oder nie hinterfragt wurden. Anders als Technical Debt ist sie selten sichtbar und entfaltet ihre Wirkung oft erst spät im Projekt.
Besonders gefährlich wird es, wenn diese Annahmen aus einem unklaren oder sich verändernden Kontext stammen. Ohne einen sauber definierten Systemkontext schleichen sich schnell Annahmen ein, die später nicht mehr nachvollziehbar sind. Damit ist der souveräne Umgang mit Assumption Debt ein wichtiger Baustein zur Reife in der Produktentwicklung.
Titelbild: Wikimedia Commons, CC BY-SA 3.0
