Das System ist sauber spezifiziert – und die Entwicklung stellt trotzdem Fragen, die deine Spezifikation längst beantwortet. Genau dafür gibt es im Requirements Engineering das Use-Case-Diagramm: Es zeigt auf einer einzigen Seite, was dein System für wen leistet, und zieht zugleich die Grenze zwischen System und Umwelt. Ob dein Diagramm diese Antworten liefern kann oder nur gut aussieht, entscheidet sich an vier Elementen.
Archiv des Autors: Alexander Grün
Mit KI schneller am Ziel vorbei – warum Vibe Coding Requirements Engineering nicht ersetzt
Zwei Sätze an die KI, Minuten später läuft etwas Lauffähiges – und die Frage liegt nahe, wozu man überhaupt noch Anforderungen sauber aufschreiben soll. Die unbequeme Antwort: Wer die Anforderungsarbeit weglässt, automatisiert nicht das Denken, sondern das Am-Ziel-vorbei-Bauen. Nur schneller und in größerer Menge.
User Storys schreiben – so geht’s richtig
„Als Nutzer möchte ich …” – die Schablone ist brav ausgefüllt, das Product Backlog ist voll, und trotzdem kommt aus der Entwicklung die Rückfrage: Was sollen wir hier eigentlich bauen? Der Grund ist unbequem: Eine formal perfekte User Story kann leer sein – und dieser Fehler fällt nicht im Refinement auf, sondern erst im Sprint.
Im Video zeigt dir Michael an einem durchgehenden Smart-Home-Beispiel, woran du eine gute User Story erkennst: die drei W-Fragen (Wer, Was, Wozu), warum der Wozu-Teil der wichtigste ist und trotzdem fast immer fehlt, was die sechs INVEST-Kriterien leisten – und wann das INV reicht – und wie Akzeptanzkriterien aus einer Story einen Abnahme-Anker machen.
Die Satzschablone für User Storys, die drei W-Fragen und alle Beispiele aus dem Video findest du vertieft in unserer kostenfreien Agilitätsbroschüre: https://sophist.de/5ajj
Noch mehr davon? Auf unserem YouTube-Kanal erscheint jede Woche ein neues Video zu Requirements Engineering, Systems Engineering und KI im RE – schau vorbei und lass gerne ein Abo da, dann verpasst du keines: SOPHIST GmbH
Ein Tool löst keine schlechten Anforderungen
Attribute gefüllt, Status auf „geprüft”, Traces gezogen – und trotzdem kommen aus der Entwicklung dieselben Rückfragen wie vor der Tool-Einführung. Wer ein Requirements-Management-Tool einführt und erwartet, dass die Anforderungen dadurch besser werden, löst das falsche Problem: Ein Tool kennt den Zustand einer Anforderung, nicht ihre Qualität.
Warum ein Modell mehr ist als ein Diagramm
Viele denken bei Modellierung im Requirements Engineering sofort an UML, Diagramme, Symbole und Notationen. Doch echte Modellierung beginnt nicht erst beim Zeichnen, sondern bereits bei der Frage, welche Sicht auf die Realität ein Modell überhaupt zeigen soll.
Weiterlesen