Wie Sie die natürliche Sprache bändigen Die SOPHIST-Satzschablone: Funktionale Anforderungen präzise formulieren

Um in Entwicklungsprojekten die Wünsche des Kunden bestmöglich umzusetzen, benötigen sowohl Entwickler als auch Tester exakt formulierte Anforderungen. Am leichtesten gelingt dies mit der natürlichen Sprache, da diese von allen Beteiligten verstanden wird. Nachteilig wirkt dabei, dass so formulierte Anforderungen oft Spielraum für Interpretationen lassen. Mit der SOPHIST-Satzschablone stellt Matthias Kulke eine einfach zu erlernende Methode vor, mit deren Hilfe Sie Anforderungen in wenigen Schritten eindeutig und vollständig dokumentieren können.

 

Wie Sie die natürliche Sprache bändigen Die SOPHIST-Satzschablone: Funktionale Anforderungen präzise formulieren

Um in Entwicklungsprojekten die Wünsche des Kunden bestmöglich umzusetzen, benötigen sowohl Entwickler als auch Tester exakt formulierte Anforderungen. Am leichtesten gelingt dies mit der natürlichen Sprache, da diese von allen Beteiligten verstanden wird. Nachteilig wirkt dabei, dass so formulierte Anforderungen oft Spielraum für Interpretationen lassen. Mit der SOPHIST-Satzschablone stellt Matthias Kulke eine einfach zu erlernende Methode vor, mit deren Hilfe Sie Anforderungen in wenigen Schritten eindeutig und vollständig dokumentieren können.

 

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

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
12 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 17
Kommentare 12

Alle Kommentare (12)

Dirk
Bauer

Kann man direkt mit zahlreichen - nicht optimal formulierten Anforderungen - der letzten Wochen "durchspielen". Super Artikel!

 

Rainer
Bauernschubert
Dipl. Verwaltungswirt

Sehr hilfreicher Titel für den RE und allen an der Softwareentwicklung beteiligten Personen. Auch wenn im Rahmen der agilen Softwareentwicklung die funktionalen Anforderungen mit Hilfe von User Stories dokumentiert werden, kann dabei die SOPHIST-Satzschablone angewandt werden und trägt so auch hier zu einer eindeutigen und vollständigen Deklaration bei.

 

Lars
Bottke

Diese Methode erinnert mich doch sehr an User Stories und deren Inhalts- sowie Qualitätskriterien, jedoch sind die User Stories nur im Zusammenhang (vgl. Behavior Driven Development) mit einer formalen Sprache (z.B. Gherkin) sinnvoll, da hier die Funktionalitäten als Designstrategie abgebildet resp. aufgenommen werden; ansonsten verhält es sich wie bei bereits vorhandenen Anforderung (sehr unkonkret. Ganz nett.

 

Gerhard
Friedrich
Dr.

Gut und kompakt beschrieben. Hilfreiche Methode. Der Glaube, damit Probleme quasi ein für alle mal vermeiden zu können ist entweder dem Vertriebsinteresse oder einer sympathischen, aber doch ein wenig naiven Euphorie für eine Methode geschuldet.

 

Guest

Sehr guter Artikel. Wenn das jeder als Handout bei der Anforderungserstellung hat, würde das häufig helfen.

 

Jürgen
Sturany

Sehr geehrter herr Kulke, ein wirklich erstklassiger Artikel der in knapper klarer Sprache das ausdrückt worauf es ankommt. Er liefert einen sehr guten Beitrag zur Möglichkeit der Reduktion von Missverständnissen, und zur Schaffung von gemeinsamen Verständnis. Missverständnisse und fehlendes gemeinsames Verständnis sind ja bekanntlich DIE Hauptursachen für Konflikte. Der Inhalt / die Methode gefällt mir sehr gut, denn sie liefert gleichzeitig auch Hinweise auf die Abnahmekriterien (QM). Ich werde sie im "Nicht-Softwarebereich", dem Industrieanlagenbau, ausprobieren, den mit den Anforderungen beginnt es... Danke PS: Eine interessante Beobachtung die ich oft mache: Man hat (angeblich) nie die Zeit es RICHTIG zu machen, aber immer die Zeit (und das Geld) Konflikte zu bearbeiten (ich schreibe bewußt nicht ...Konflikte zu lösen...).

 

Christoph
Zahrnt
Dr.

Wie konnte ich diese Vorgehensweise bisher nicht kennen!! Sie kann - ggf. angepasst - bei vielen Textarten helfen. Sie eignet sich hervorragend für den Auftragnehmer, wenn er eine Anforderung des Kunden beschreiben soll, etwa bei Change Requests.

 

Christoph
Zahrnt
Dr.

Zu Herrn Bottke (Nr. 6) Herr Kulke bestreitet überhaupt nicht, dass Definitionssprachen bessere Ergebnisse liefern. Aber lieber ein Spatz in der Hand, als eine Taube auf dem Dach - wobei der Spatz in diesem Fall sehr nützlich ist. Dem Beitrag keinen Stern zu geben betrachte ich als kindisch.

 

Reinhard
Riesen
dipl. Ing.

Ausserordentlich hilfreicher Artikel, Bravo!