Soll ichs wirklich machen oder lass ichs lieber sein. Fragen sich nur noch Fettes Brot. Für die RE-Welt ist diese Frage seit einiger Zeit hinfällig. Sollten Sie ein treuer SOPHIST-Blogleser sein, wissen Sie warum. Wenn nicht, klicken Sie hier zum 1 Teil der Blogserie und/oder lesen Sie einfach weiter.

In diesem Blogeintrag wollen wir uns nun mit der zweiten Hälfte von negativ formulierten Anforderungen auseinandersetzen, den sogenannten inversen Anforderungen.

Definition

Dieses Konzept meint also negativ formulierte Anforderungen, die dazu dienen dem Entwickler gewisse Lösungsmöglichkeiten zu nehmen. Da inverse Anforderungen, wie der Name schon sagt, ganz normale Anforderungen sind, muss ihre Umsetzung, im zu entwickelnden System getestet und abgenommen werden. Da mögen beim ein oder anderen Blogleser die Alarmglocken läuten: Einer der Gründe, warum um negativ formuliert Anforderungen lange Zeit ein Bogen gemacht wurde, ist, dass sie angeblich nicht testbar sind. Sie haben es schon gelesen, das nicht ganz kleine, aber feine Wörtchen angeblich. Lesen Sie sich die folgende inverse, nicht-funktionale Anforderung durch:

 Das System muss so gestaltet sein, dass es kein Chlor enthält.

Eine negativ formulierte Anforderung, die testbar ist. Es gibt sie also, die negativen Anforderungen, die ich einem Tester keine grauen Haare wachsen lassen. Ein weiteres Beispiel wäre:

Das System muss so gestaltet sein, dass es bei einem Fall aus einer Höhe von bis zu 50 cm keine Kratzspuren aufweist.

Was machen Sie aber mit einer inversen Anforderung, die Sie auf oberster Ebene nicht testen können? So z. B.

            Das Systemgehäuse muss so gestaltet sein, dass es nicht rostet.

Verfeinern Sie diese Anforderung und machen Sie sie damit testbar.

Das Systemgehäuse muss so gestaltet sein, dass es zu 100% aus Aluminium besteht.

Diese neue Anforderung stellt eine Verfeinerung der ursprünglichen Anforderung dar und gibt im Grunde die Lösung dieser Anforderung vor. Wenn diese Lösung testbar ist, dann hat sich die Problematik mit der schwierigen Testbarkeit von inversen Anforderungen damit gelöst. Ob Sie als Auftraggeber hierbei diese Lösung vorgeben, oder Ihrem Auftragnehmer offene Hand lassen eine Lösung zu entwickeln und Ihnen diese in Form eines Pflichtenheftes o.ä. präsentieren ist hierbei unerheblich. Wichtig ist nur, dass Sie jede nicht testbare inverse Anforderung verfeinern.

Falls Sie sich Fragen wie Sie inverse Anforderungen nun formulieren können, dann haben wir auch auf diese Frage eine Antwort. Nutzen Sie wie gewohnt die SOPHIST Satzschablonen für funktionale oder nicht-funktionale Anforderungen und verwenden Sie als Modalverb der rechtlichen Verbindlichkeit „darf nicht“ oder „darf kein“.

In diesem Sinne: Lassen Sie es lieber nicht sein. Richtig angewendet sind sowohl inverse als auch ausgeschlossene Anforderungen eine Erleichterung Ihrer Systementwicklung. Sie kommen Ihrem natürlichen Sprachgefühl entgegen, verbessern die Verständlichkeit einer Spezifikation, sparen so Ressourcen und schützen Sie vor negativen Schwingungen im Team.

Bei Fragen oder Feedback erreichen Sie uns unter 0911 – 40 900-0 oder per Email heureka@sophist.de.