Beispiel 1: Bestandsverwaltung
Vergleichen Sie schlechte und bessere Spezifikationsansätze
Schlechte Spezifikation
Projekt: Inventarsystem
Wir brauchen ein System, um unsere Bestände besser zu verwalten. Das aktuelle Tabellenkalkulationssystem funktioniert nicht gut.
Anforderungen:
- Verfolgen Sie Produkte und Mengen
- Benachrichtigungen bei niedrigem Lagerbestand anzeigen
- Berichte erstellen
- Benutzerfreundliche Oberfläche
- Sollte schnell sein
- Integration in bestehende Systeme
- Mobilkompatibel
- Sicher und zuverlässig
Benutzer:
Lagermitarbeiter, Manager und das Buchhaltungsteam werden dies nutzen.
Zeitleiste:
So schnell wie möglich – das ist dringend
Budget:
Angemessene Kosten
❌ Probleme mit dieser Spezifikation:
- Keine spezifischen Zahlen oder Kennzahlen
- Vage Begriffe wie „besser“, „benutzerfreundlich“, „schnell“
- Keine klaren Erfolgskriterien
- Fehlender Geschäftskontext
- Undefinierte Integrationen
- Keine Prioritätsstufen
Bessere Spezifikation
Projekt: Bestandsverwaltungssystem
Geschäftskontext:
Wir verwalten mehr als 500 SKUs in 3 Lagern. Derzeit verwende ich Excel, was zu einer Fehlbestellquote von 15 % und Eilbestellungen im Wert von 50.000 US-Dollar pro Monat führt.
Anforderungen (priorisiert):
[MUSS] Mengen nach SKU und Standort verfolgen
[MUSS] Benachrichtigung, wenn der Lagerbestand < 2 Wochen durchschnittlicher Umsatz beträgt
[MUSS] Täglicher Bestandsbewertungsbericht (PDF)
[MUSS] Reaktionszeit < 2 Sekunden für Suchen
[MUSS] Mobile App zum Lagerscannen
[SOLLTE] Integration mit Odoo Sales (REST API)
[SCHÖN] Vorausschauende Nachbestellungsvorschläge
Benutzer und Aktionen:
- Lagerpersonal (10): Belege scannen, Zählungen durchführen
- Manager (3): Dashboards anzeigen, Übertragungen genehmigen
- Buchhaltung (2): Bewertungsberichte erstellen
Erfolgskriterien:
- Reduzieren Sie Lagerbestände innerhalb von 3 Monaten auf <5 %
- Verarbeiten Sie mehr als 100 Transaktionen pro Stunde
- 90 % Benutzerakzeptanz ohne Schulung
✓ Warum das besser ist:
- Konkrete Zahlen und messbare Ziele
- Klarer Geschäftskontext und ROI
- Priorisierte Anforderungen (MoSCoW)
- Definierte Benutzerrollen und Aktionen
- Explizite Integrationsdetails
- Überprüfbare Erfolgskriterien
💡 Schlüssel zum Mitnehmen
Beide Spezifikationen haben eine ähnliche Länge (~200 Wörter), die bessere Version bietet jedoch eine ähnliche Länge 10x mehr umsetzbare Informationen. Es geht nicht darum, mehr zu schreiben – es geht darum Ersetzen vager Aussagen durch konkrete, messbare Anforderungen, die Entwickler erfüllen können tatsächlich umsetzen und testen.