Eine wichtige Aufgabe des Requirements Engineers ist die Erstellung und Pflege der Systemspezifikation. Er leitet dazu Kundenanforderungen ab, spezifiziert diese auf einem angemessenen Abstraktionsniveau und bietet dadurch eine solide Arbeitsgrundlage für nachfolgende Entwicklungsaktivitäten, z.B. die Softwareentwicklung. Doch woher weiß der Requirements Engineer eigentlich, was der Kunde wirklich will?
Formulierungstipps – Teil 3
Alle Systemausgaben sollen in der Datenbank DB34 gespeichert werden. Sehen wir uns heute die oben stehende Anforderung genauer an. Dem erfahrenen Autor sollte sofort der verwendete Universalquantor „Alle“ auffallen, wodurch die Eindeutigkeit dieser Anforderung leidet. Sollen wirklich alle Systemausgaben gespeichert werden? Oder sollen nur bestimmte Fehlerfälle gespeichert werden?
Formulierungstipps – Teil 2
Das System muss rot sein. Ein Leser dieser Anforderung hat eine bestimmte Vorstellung der Farbe Rot. Viele Leser haben viele Vorstellungen – und zwar höchstwahrscheinlich unterschiedliche! Problematisch ist hier die Verwendung des Eigenschaftsworts „rot“, da es nicht eindeutig definiert ist und daher unweigerlich zu verschiedenen Interpretationen führt.
Formulierungstipps – Teil 1
Nach Drücken der Taste müssen die Daten übertragen werden. In der nun folgenden Blogserie werden wir Ihnen zahlreiche Tipps geben, wie Sie die oben genannte und weitere schwach formulierte Anforderungen verbessern können. Durch die Tatsache, dass die Anforderung im Passiv formuliert ist, wird keine Aussage darüber gemacht, wer oder was die Daten übertragen muss. Es…
Teure Anforderungen
Schwach formulierte Anforderungen können sich zu teuren Anforderungen entwickeln. Dies lässt sich durch einfache Maßnahmen vermeiden. Vielen laufen sie tagtäglich über den Weg – „Anforderungen mit Verbesserungspotential“. Zur Verdeutlichung sollen hier zwei eindrückliche Beispiele genannt sein: „Nach Drücken der Taste müssen die Daten übertragen werden.“ oder „Das System muss leicht bedienbar sein.“.