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? An dieser Stelle ist es unbedingt erforderlich, sich mit
dem Stakeholder, den diese Anforderung betrifft, in Verbindung zu setzen um die offenen Fragen zu klären.

Hier also ein Verbesserungsvorschlag:

Systemfehler der Kategorie ERR1 sollen in der Datenbank DB34
gespeichert werden.

Nun muss man sich allerdings fragen, welche Verbindlichkeit diese
Anforderung aufweist, da „soll“ als verpflichtend, aber auch als optional
interpretiert werden kann. Wir empfehlen daher die Verwendung des eindeutigen
Wortes „muss“ und eine mögliche Priorisierung über ein separates Attribut oder eine Kennzeichnung der Anforderung. Die verbesserte Anforderung würde also lauten:

Systemfehler der Kategorie ERR1 müssen in der Datenbank DB34
gespeichert werden.

Wir wissen bereits, dass eine Formulierung von Anforderungen im Aktiv den Vorteil bietet, dass der Akteur der Anforderung genannt wird. Dieses Vorgehen lässt sich auch hier anwenden, denn bisher ist unklar, wer die Systemfehler der Kategorie ERR1 in der Datenbank DB34 abspeichern muss.

Die Softwarekomponente A muss die Systemfehler der Kategorie ERR1 in der Datenbank DB34 abspeichern.

Marcel Klein

Kontaktieren Sie Marcel Klein

Marcel Klein arbeitet bei der HOOD GmbH als Consultant und als Trainer im Bereich Requirements Engineering. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Prozessverbesserung sowie die Erstellung von objektorientierten Modellen. Als Trainer hat er sich vor allem auf die gute Formulierung textueller Anforderungen und die nachhaltige Etablierung von Requirements Engineering in einem Unternehmen spezialisiert. Er veröffentlicht regelmäßig zu beiden Themen Artikel und Blogs.