Anforderungsmanagement Blog
Praxisnahe Anleitungen, warum, wann und wie man Anforderungen schreibt — für Studierende und Ingenieure.
Die 10x–100x-Regel: Was eine späte Korrektur wirklich kostet
Jeder sagt, späte Korrekturen seien teuer. Hier ist die tatsächliche Zahl, woher sie kommt und der eine Hebel, der sie verändert.
Anforderungen für KI- und datengetriebene Systeme: Spezifizieren, was man nicht vorhersagen kann
Klassische Anforderungen setzen deterministisches Verhalten voraus. Maschinelles Lernen tut das nicht. So spezifiziert man Systeme, deren Verhalten aus Daten entsteht.
Agile vs V-Modell: Wo Anforderungen jeweils leben
Agile entfernt keine Anforderungen — es verlagert sie. Wo sie in jedem Modell leben, wann welches gewinnt und wie echte Projekte beide verbinden.
Eine Anforderung ist ein Vertrag, keine Wunschliste
Die eigentliche Aufgabe der Spezifikation ist nicht Dokumentation, sondern Ausrichtung und Risikominderung. Was eine Anforderung bewirkt, wenn man sie wie einen Vertrag behandelt.
Anforderungen priorisieren: MoSCoW, Kano und das Nein
Eine Spezifikation ohne Prioritäten ist wieder nur eine Wunschliste. MoSCoW und Kano sind die beiden Werkzeuge, die aus einer Liste von Wünschen einen Plan machen.
Anforderungen für sicherheitskritische und regulierte Systeme
In regulierten Bereichen ist die Spezifikation nicht optional — sie ist der Audit-Trail. Was IEC 62304, ISO 26262 und DO-178C tatsächlich von Ihren Anforderungen verlangen.
Anforderungs-Gerüche: 10 Formulierungen, die in keine Spezifikation gehören
Verbannen Sie diese zehn Formulierungen, und Sie entfernen den größten Teil der Mehrdeutigkeit aus jedem Anforderungsdokument — mit einer konkreten Korrektur für jede.
Anforderungen in Embedded- und Firmware-Projekten: Die Spezifikation früh einfrieren
In Embedded-Systemen ist eine späte Anforderungsänderung der teuerste Fehler überhaupt — die Hardware ist gefertigt, die Firmware geflasht, die Geräte sind im Feld. Was man wann festlegen muss.
Drei echte Spezifikationen, die ein Projekt getötet haben (und was sie kosteten)
Mars Climate Orbiter, das Gepäcksystem von Denver und das Virtual Case File des FBI — drei berühmte Fehlschläge, jeder mit einer einzigen Anforderungs-Lektion.
Nach der Spezifikation: Nachverfolgbarkeit, Versionierung und Änderungen
Die Spezifikation ist der Anfang, nicht das Ende. Nachverfolgbarkeit, Baselines und Änderungsmanagement machen aus einem Dokument ein System.
Von der User Story zum Abnahmekriterium: Given/When/Then richtig gemacht
Eine User Story ohne Abnahmekriterien ist ein Wunsch. So schreiben Sie Stories und Given/When/Then-Kriterien, die ein Team tatsächlich bauen und testen kann.
Warum Projekte wirklich scheitern (Es ist fast nie der Code)
Die Entscheidung, die ein Projekt tötet, fällt meist Wochen vor der ersten Codezeile — in der Spezifikation. Hier ist, warum — und was es kostet.
Wann braucht man überhaupt eine schriftliche Spezifikation?
Nicht jedes Projekt braucht eine formale Spezifikation. Hier ist die Entscheidungsregel, die sagt, wann man eine schreiben sollte — und wann man sie weglassen und einfach bauen sollte.
Lastenheft vs Pflichtenheft: Was und Wie, sauber getrennt
Warum die deutsche Ingenieurskunst das Lastenheft (Was) vom Pflichtenheft (Wie) trennt — und wie diese Trennung den teuersten Streit im Engineering verhindert.
Wie man eine Anforderung schreibt, die nicht missverstanden werden kann
EARS-Notation, die Qualitätsmerkmale nach IEEE 29148 und die Muss/Soll/Kann-Disziplin — eine wiederholbare Vorlage für eindeutige und testbare Anforderungen.
Anforderungen 101: Warum, wann und wie man Anforderungen schreibt
Eine praxisnahe Einführung in das Anforderungsmanagement — warum schriftliche Anforderungen wichtig sind, wann man sie braucht und wie man sie eindeutig formuliert.