Einen entscheidenden Grundstein für den Erfolg eines Entwicklungsprojekts stellen richtig dokumentierte Anforderungen dar: Sie sorgen dafür, dass alle Projektbeteiligten das gleiche Verständnis von den Kundenwünschen haben, sodass der Kunde am Ende genau das bekommt, für das er bezahlt hat.

In Software-Entwicklungsprojekten werden funktionale Anforderungen an zu erstellende Systeme auf unterschiedlichste Art und Weise dokumentiert: Sie können z.B. in Form von konzeptuellen Modellen wie UseCase- oder Aktivitätsdiagrammen festgehalten werden. Diese haben den Vorteil, dass Anforderungen aufgrund des hohen Formalitätsgrades der Modellierungssprache sehr kompakt und eindeutig modelliert bzw. dokumentiert werden können. Voraussetzung ist allerdings, dass die Projektbeteiligten die verwendete Modellierungssprache beherrschen (s. Pohl, Rupp 2010, S. 46).

Die in der Praxis am häufigsten verwendete Dokumentationsform aber ist die natürliche Sprache. Sie hat gegenüber den konzeptuellen Modellen zwei entscheidende Vorteile (s. Pohl, Rupp 2010, S. 45):

1. Sie wird von allen Projektbeteiligten beherrscht und muss nicht erst erlernt werden.
2. Sie ist vielseitig einsetzbar, wodurch jegliche Anforderung ausgedrückt werden kann.

Stolpersteine beim Dokumentieren von Anforderungen

Allerdings hat die natürliche Sprache als Dokumentationsform auch einen großen Nachteil, der nicht selten zum Scheitern eines Einwicklungsprojekts führt: Die natürliche Sprache überlässt den Projektbeteiligten einen großen Spielraum für Interpretationen.

Dieser Interpretationsspielraum birgt die große Gefahr, dass dokumentierte Anforderungen vom Projektteam missverstanden und folglich falsch umgesetzt werden. Die Konsequenz ist, dass nicht geplante Systemanpassungen notwendig werden und das Projekt folglich nicht innerhalb des geplanten Zeit- und Budgetrahmens umgesetzt werden kann.

Die natürliche Sprache "bändigen"

Genau diese Situation habe ich als IT-Berater leider des Öfteren erlebt: Die Anforderungen werden natürlich-sprachig in ausschweifender Prosa formuliert, ohne dass dabei auf Eindeutigkeit, Vollständigkeit und Korrektheit geachtet wird. Dies führt zu Unklarheiten, sodass das Entwicklungsteam in den meisten Fällen die Anforderungen anders umsetzt, als der Kunde dies will, woraufhin dieser unzufrieden reagiert. In der Folge werden zahlreiche Diskussionen darüber geführt, wie die Anforderungen zu verstehen sind. Am Ende dieser aufreibenden Diskussionen sind in der Regel nicht nur Time, Scope und Budget des Projekts in Gefahr, sondern es ist zudem die Stimmung aller Beteiligten gedrückt und die Standpunkte sind verhärtet.

Letztendlich sind in vielen Fällen umfangreiche und aufwändige Systemanpassungen notwendig, die Projektverzögerungen und Mehrkosten verursachten. Um dem entgegenzuwirken, muss die natürliche Sprache als Dokumentationsform für Anforderungen "gebändigt" werden. Das heißt, es muss dafür gesorgt werden, dass die dokumentierten Anforderungen genau das aussagen, was der Kunde sich wünscht.

Anforderungen pragmatisch erstellen

Falls Sie ähnliche Probleme als Requirements Engineer, Entwickler oder Projektleiter bereits erlebt haben oder sich derzeit in einer solchen Situation befinden, kann Ihnen die SOPHIST-Satzschablone weiterhelfen, die in diesem Artikel vorgestellt wird. Dabei handelt es sich um eine leicht anwendbare und effektive Methode, mit der Sie in der Lage sind, die natürliche Sprache als Dokumentationsform richtig einzusetzen. Die Schablone ermöglicht es Ihnen, strukturierte Anforderungssätze in fünf Schritten eindeutig, vollständig und verständlich zu erstellen.

Bei dem Unternehmen CGI, einem kanadischen Anbieter für IT- und Geschäftsprozess-Dienstleistungen, für den ich tätig bin, wird diese Methode bereits seit Jahren erfolgreich zur Anforderungsdokumentation eingesetzt. Die Methode hat sich dort besonders in Entwicklungsprojekten bewährt, die auf einem schwergewichtigen Vorgehensmodell wie z.B. dem Wasserfallmodell basieren, und gilt seitdem als Standard für die Dokumentation von funktionalen Anforderungen.

Gründe für den Einsatz der SOPHIST-Satzschablone waren vor allem die einfache Handhabung, der effektive und effiziente Einsatz sowie die Möglichkeit, eine pragmatische und einheitliche Projektsprache zur Dokumentation von Anforderungen zu schaffen.

Ein Beispiel aus der Praxis