Anforderungsmanagement Blog
Praxisnahe Anleitungen, warum, wann und wie man Anforderungen schreibt — für Studierende und Ingenieure.
Neu bei Anforderungen? Hier anfangen
In dieser Reihenfolge lesen: von den Grundlagen bis zum Managen einer echten Spezifikation.
- 1Anforderungen 101: Warum, wann und wie man Anforderungen schreibt
- 2Wann braucht man überhaupt eine schriftliche Spezifikation?
- 3Wie man eine Anforderung schreibt, die nicht missverstanden werden kann
- 4Anforderungs-Gerüche: 10 Formulierungen, die in keine Spezifikation gehören
- 5Vorlage für eine Software-Anforderungsspezifikation (SRS): Aufbau und Beispiele
- 6Von der User Story zum Abnahmekriterium: Given/When/Then richtig gemacht
- 7Anforderungen priorisieren: MoSCoW, Kano und das Nein
- 8Nach der Spezifikation: Nachverfolgbarkeit, Versionierung und Änderungen
Grundlagen
Was Anforderungen sind, warum sie zählen und wann man sie braucht.
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.
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.
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.
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.
Anforderungen schreiben
Aus Ideen klare, prüfbare Aussagen machen.
Vorlage für eine Software-Anforderungsspezifikation (SRS): Aufbau und Beispiele
Eine SRS-Gliederung Abschnitt für Abschnitt nach ISO/IEC/IEEE 29148 und IEEE 830, mit einem Beispiel für jeden Teil und den Fehlern, die Prüfer und Gutachter am häufigsten sehen.
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.
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.
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 managen
Priorisieren, verfolgen, versionieren und Prozess und Werkzeuge wählen.
Anforderungsmanagement-Tool auswählen: Eine Checkliste mit 12 Punkten
Word, Excel oder ein eigenes Anforderungsmanagement-Tool? Zwölf Fragen, die zeigen, was Ihr Team wirklich braucht — für Entwicklungsteams und studentische Projekte.
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.
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.
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.
Branchen & Fallstudien
Embedded-, sicherheitskritische und KI-Systeme sowie echte Fehlschläge.
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.
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.
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.