Schön, dass Sie ja sagen zum zweiten Teil unserer Blogserie zu negativ formulierten Anforderungen. Dieser Beitrag beschäftigt sich mit der ersten Gruppe negativ formulierter Anforderungen: den ausgeschlossenen Aspekten. Einer Definition folgen Beispiele und Szenarien, in denen die Anwendung von ausgeschlossenen Aspekten sinnvoll ist.

Definition

Soweit so gut. Wann es nun aber Sinn macht, ausgeschlossene Aspekte zu formulieren, verdeutlicht die Abbildung 1 (Sie erinnern sich vielleicht an den ersten Teil dieser Blogserie, einen Freifahrtsschein zum Schreiben negativer Anforderungen wollen wir Ihnen nicht ausstellen).

Abbildung 1 verdeutlicht, dass es nur sinnvoll ist, Funktionalitäten oder Eigenschaften eines Systems auszuschließen, falls diese Funktionalitäten oder Eigenschaften innerhalb des Systemkontexts des betrachteten Systems liegen könnten. Dafür ist es in einem ersten Schritt nötig, sich ein Verständnis des Systemkontexts zu erarbeiten. Im Requirements Engineering ist eine klassische Abgrenzung des Kontexts Gang und Gäbe. Oftmals werden aber nur die Aspekte dokumentiert, die innerhalb des Systemkontexts liegen. Funktionalitäten, die nicht umgesetzt werden sollen, werden allerdings in den seltensten Fällen dokumentiert. In unseren Augen kann dies zu Verwirrungen führen und man sollte daher abwägen, ob es einer besseren Verständlichkeit dient, einzelne Funktionen oder Eigenschaften explizit auszuschließen.

Ein Beispiel: Sie entwickeln ein Online-Auktionsportal. Durch eine saubere und strukturierte Systemkontextanalyse haben Sie erkannt, welche Schnittstellen Ihr System haben wird und welche gesetzlichen Normen Sie bei der Umsetzung beachten müssen. Sie haben verstanden was ihr zu spezifizierendes System in Zukunft leisten soll und haben dies alles fein säuberlich dokumentiert. Nun ist es natürlich nicht mehr nötig zu beschreiben, dass Ihr Portal kein Brot backen soll. Diese Informationen helfen beim Verständnis des Systems relativ wenig, sofern sich alle Beteiligten darüber im klaren sind, dass man an der Entwicklung eines Auktionsportals beteiligt ist, und nicht an der Entwicklung einer automatisierten Backstraße. Worauf Sie aber dringend Wert legen sollten, ist die Dokumentation des Fakts, dass über Ihr Online-Portal keine Bücher gehandelt werden können. Diese Funktionalität ist nämlich durchaus denkbar und man sollte daher explizit darauf hinweisen, dass diese Funktionalität, obwohl sie aus fachlicher Sicht in den Kontext des zu entwickelnden Systems passt, eben doch nicht Teil des Systems sein wird.

Im Folgenden stellen wir Ihnen einige weitere Szenarien vor, in denen die Dokumentation der ausgeschlossenen Aspekte hilfreich sein kann.

Falls Ihr zu spezifizierendes System ein bestehendes Altsystem ablöst und falls dieses bestehende Altsystem über eine Funktionalität verfügt, die vom zu spezifizierenden System nicht abgedeckt wird, so sollten Sie diesen ausgeschlossenen Aspekt dokumentieren. Der Grund ist ein ganz einfacher: Sie vermeiden Missverständnisse. Ein Entwickler z. B., der mit dem Altsystem bestens vertraut ist, wundert sich dann nicht, dass er mit dem neuen System eben nicht mehr seine Büchersammlung erweitern kann (und entwickelt die Funktionalität aus lauter Herzensschmerz nicht einfach mit).

Es kann auch sein, dass das zu spezifizierende System einen bisher von einer natürlichen Person durchgeführten Vorgang teilweise ablöst. In diesem Fall sollten Sie den nicht umzusetzenden Vorgang durch einen negativ formulierten Aspekt schriftlich festhalten. Auch in diesem Szenario geht es darum, implizite Annahmen zu vermeiden.

Vielleicht sind Ihnen auch nicht enden wollende Diskussionen über ein System vertraut. Anforderungen abzustimmen und sich auf ein gemeinsames Ziel zu einigen fördern das Grauwerden des Haupthaares ganz gewaltig. Sollten letztendlich Funktionalitäten oder Eigenschaften eines Systems, die anfangs noch angedacht oder erwünscht waren, beim Erstellen der Spezifikation nicht mehr aktuell sein, raten wir Ihnen, auch diesen Sachverhalt als ausgeschlossenen Aspekt zu dokumentieren. (Sie vermeiden so weitere graue Haare.)

Potential, Ihre Nerven zu strapazieren, hat auch folgendes Szenario: Es wird ein System in der x-ten Generation entwickelt und hat nicht, wie man annehmen könnte, eine Funktionalität, die bisher schlichtweg in allen vorgelagerten Systementwicklungen vorhanden gewesen ist. Wenn das der Fall ist, dokumentieren Sie es.

Ähnlich ist auch unser letztes Beispielszenario: Abheben von der Konkurrenz wollen wir uns alle. Wenn Ihr zu spezifizierendes System nicht über eine Funktionalität verfügt, die die gesamte Konkurrenz baut, machen Sie den Unterschied mit einem dokumentierten ausgeschlossenen Aspekt deutlich.

Alle Szenarien haben eins gemeinsam: Sie raten zum Dokumentieren ausgeschlossener Aspekte, um Missverständnisse und eine spätere, teure Fehlerkorrektur zu vermeiden.

Abschließend ein Hinweis zur Formulierung ausgeschlossener Aspekte. Da ausgeschlossene Aspekte keine Anforderungen an das zu spezifizierende System sind (schließlich wollen wir ja nicht, dass etwas umgesetzt wird), ist es auch nicht nötig, sie nach Satzschablone zu formulieren. Weiterhin empfehlen wir auf die Verwendung der vom Ingenieursverband IEEE vorgeschlagenen Modalverben der rechtlichen Verbindlichkeit wie muss, sollte oder wird (oder eben muss nicht, soll nicht, oder wird nicht) zu verzichten. Damit grenzen Sie ausgeschlossene Aspekte noch weiter von Ihren Anforderungen ab und machen damit auch noch deutlicher, dass diese Teile der Spezifikation nicht getestet werden müssen.

Zu Ihren Praxiserfahrungen sagen wir jedoch ganz sicher nicht nein! Also, greifen Sie zum Telefon (0911 40 900 0) oder mailen Sie an heureka@sophist.de.

Hier finden Sie den 1. Teil  und den 3. Teil dieser Blogserie.