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

Sophist Satzschablone

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.

Management Summary

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

Sophist Satzschablone

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.

Management Summary

Wir empfehlen zum Thema Anforderung
PM Welt 2023: Mutig handeln in unsicheren Zeiten

Wie gehe ich mit den Herausforderungen fehlender Planbarkeit und Unsicherheit um? Welche Kompetenzen, Methoden und Tools sind gefordert, um sich mutig und sicher den Herausforderungen der Zukunft zu stellen? Diese und weitere spannende Themen erleben Sie am 4. Mai 2023 in München bei der PM Welt, unserer Projektmanagement-Konferenz. Seien Sie dabei! Mehr Infos

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

Ein IT-Dienstleistungsunternehmen verfügt über ein webbasiertes Reisekostensystem, über das die Reisekosten der Mitarbeiter erfasst, freigegeben und abgerechnet werden. Beim Erstellen eines Reisekostenberichts muss der Mitarbeiter die Belege über die entstandenen Reisekosten im Vorfeld einscannen und dem Reisekostenbericht als Anhang hinzufügen. Da die Mitarbeiter während einer Firmenreise nur sehr selten oder gar nicht die Möglichkeit haben, die Belege einzuscannen, werden die Reisekosten meistens mit einem Zeitverzug von mehreren Wochen erfasst. Dies führt dazu, dass die monatlichen Geschäftszahlen des Unternehmens verfälscht werden und nachträglich korrigiert bzw. angepasst werden müssen.

Um dem entgegenzuwirken, möchte das Unternehmen für das bestehende Reisekostensystem eine Smartphone-Applikation entwickeln: Mit dieser App können die Mitarbeiter ihre Reisekosten noch während der Firmenreise direkt erfassen, ohne dabei die Belege über die entstandenen Reisekosten einscannen zu müssen. Eine der zentralen und wichtigsten Funktionen der App ist, dass die Mitarbeiter ihre Belege mit dem Smartphone abfotografieren und dem Reisekostenbericht während der Erstellung als Anhang hinzufügen können.

Der erste Blick trügt

Im Zuge der Anforderungsanalyse wurde die Funktionalität genauer untersucht. Es wurde dabei bewusst festgelegt, dass an einen Reisekostenbericht maximal 20 abfotografierte Belege angehängt werden können. Anschließend wurde hierzu folgende Anforderung formuliert:

"Es ist erforderlich, dass 20 Dateianhänge hochgeladen werden können."

Die formulierte Anforderung mag auf den ersten Blick korrekt erscheinen, ist bei genauerem Hinsehen jedoch missverständlich formuliert. So ist in keiner Weise ersichtlich, dass

  • der Mitarbeiter die Belege an den Reisekostenbericht anhängen können muss, während er diesen erstellt,
  • es sich um Belege handelt, die über das Smartphone abfotografiert wurden und
  • dass maximal 20 Belege an einen Reisekostenbericht angehängt werden können.

Durch die unklare Anforderungsformulierung ist es sehr wahrscheinlich, dass der Entwickler die Anforderung ganz anderes interpretiert und umsetzt. Z.B. könnte der Entwickler die Anforderung so umsetzen, dass zwar Dateianhänge über die App hochgeladen, diese aber nicht mit dem Reisekostenbericht verknüpft werden können. Ebenso kann es passieren, dass der Entwickler die notwendige Verknüpfung mit dem Fotoalbum des Smartphones nicht berücksichtigt, sodass die abfotografierten Belege gar nicht als Dateianhang ausgewählt werden können.

Darüber hinaus wird bei der aktuellen Formulierung nicht ersichtlich, dass es sich um eine zentrale Anforderung der App handelt. Dies birgt die Gefahr, dass die Anforderung von der Projektleitung als weniger wichtig eingestuft wird und bei einem Budget-Engpass hinten herunterfällt. Auch auf die Qualitätssicherung wirkt sich unklares Formulieren negativ aus: Ähnlich wie bei den Entwicklern besteht auch bei den Testern die Gefahr, dass sie die Anforderung anders interpretieren oder sogar die falsche Umsetzung als korrekt ansehen.

Das Risiko ist also groß, dass die App am Ende nicht das kann, was sie können sollte und das Projekt somit zum Scheitern verurteilt ist. Im Folgenden erfahren Sie, wie Sie die skizzierte Anforderung richtig dokumentieren, um die geschilderten Stolperfallen zu vermeiden.

Der Baukasten der SOPHIST-Satzschablone

Bei dem hier beschriebenen Vorgehen handelt es sich um eine von der SOPHIST GmbH entwickelte Schablone bzw. Methode zur syntaktischen Dokumentation von Anforderungen (s. Rupp 2009, S.159 ff.). Diese wurde mit dem Ziel entwickelt, funktionale Anforderungen eindeutig, vollständig, verständlich und korrekt zu dokumentieren. Hierzu stellt die Methode einen Baukasten sowie einen Bauplan bereit, mit denen sich strukturierte Anforderungssätze erstellen lassen.

Die Methode basiert auf den Qualitätskriterien für gut dokumentierte Anforderungen, welche vom Institute of Electrical and Electronics Engineers (IEEE) erhoben und im Standard IEEE Std 830-1998 festgehalten wurden (vgl. EEE Std 830-1998).

Sechs Bausteine zur präzisen Formulierung

Der Baukasten der Schablone besteht aus sechs Bausteinen, die jeweils eine bestimmte semantische Bedeutung innerhalb des Anforderungssatzes haben. Diese sind der Systemname, die rechtliche Verbindlichkeit, das Prozesswort, die Prozessart, das Objekt und dessen Ergänzungen sowie die Bedingung.

  • Der Systemname identifiziert das System, für das die Anforderung erfasst wird.
  • Die rechtliche Verbindlichkeit legt fest, wie wichtig die Anforderung ist.
  • Das Prozesswort identifiziert und beschreibt die geforderte Systemfunktionalität.
  • Die Prozessart bestimmt die Art der geforderten Systemfunktionalität.
  • Das Objekt und dessen Ergänzungen beschreiben die Daten, die durch die geforderte Systemfunktionalität verarbeitet werden.
  • Die Bedingung legt den Rahmen fest, in dem die geforderte Systemfunktionalität ausgeführt wird.

Die folgende Abbildung veranschaulicht den Aufbau eines Anforderungssatzes mit den sechs Bausteinen der SOPHIST-Satzschablone.

Bild 1: Baukasten der SOPHIST-Satzschablone (s. Rupp 2009 S. 162).
Bild vergrößern

Die Anforderung aus dem Praxisbeispiel sieht gemäß der SOPHIST-Satzschablone demnach wie folgt aus:

Bild 2: Anhand der SOPHIST-Satzschablone erstellte Anforderung.
Bild vergrößern

Wie Sie zu dieser syntaktischen Dokumentation der Anforderung kommen, erfahren Sie im nächsten Abschnitt.

Der Bauplan der SOPHIST-Satzschablone

Der Bauplan der Schablone erklärt, wie ein Anforderungssatz mit den sechs Bausteinen erstellt wird. Die Anleitung besteht aus fünf aufeinanderfolgenden Schritten, in denen die einzelnen Bausteine der Satzschablone bestimmt und zusammengesetzt werden. Diese fünf Schritte sind:

  1. die rechtliche Verbindlichkeit festlegen
  2. das Prozesswort festlegen
  3. die Prozessart festlegen
  4. das Objekt und dessen Ergänzungen hinzufügen
  5. die Bedingung einarbeiten

Für den Systemnamen wird vorab ein geeignetes Subjekt festlegt; er ist für alle Anforderungen des Systems identisch. Wenn kein sprechender Systemname gefunden wird, können Sie "das System" oder ähnliche Umschreibungen verwenden.

Bild 3: Vorgehen der SOPHIST-Satzschablone (s. Rupp 2009, S.162).
Bild vergrößern

Für die Anforderung aus dem Praxisbeispiel wähle ich als Systemnamen "die App".

Schritt 1 – die rechtliche Verbindlichkeit festlegen

Als erstes wird die rechtliche Verbindlichkeit, also die vertragliche Verpflichtung der Anforderung festgelegt. Üblicherweise unterscheidet man dabei zwischen "Pflicht", "Wunsch" und "Absicht".

  • Pflicht: Es handelt sich um eine zwingend zu erfüllende Anforderung. Eine solche Anforderung ist juristisch verbindlich (vertraglich einklagbar).
  • Wunsch: Es handelt sich um eine Anforderung, von deren Umsetzung unter bestimmten Umständen abgesehen werden kann, z.B. bei hoher Komplexität und hohem Aufwand während der Implementierung. Eine solche Anforderung ist juristisch nicht verbindlich.
  • Absicht: Es handelt sich um eine Anforderung, die die Berücksichtigung einer künftigen Entwicklung fordert. Künftige Entwicklungen sind z.B. kommende Standards, Richtlinien oder Erweiterungen an das System. So kann z.B. gefordert werden, dass die App zur Erfassung der Reisekosten künftig in der Lage sein muss, den erstellten Reisekostenbericht via Email zu versenden. Diese Funktionalität wird im aktuellen Release nicht umgesetzt, muss aber in der Umsetzung vorbereitend mit berücksichtigt werden, sodass sie in einem der nächsten Releases realisiert werden kann. Eine solche Anforderung ist juristisch verbindlich.

Neben Klarheit über die vertraglichen Verpflichtung schafft das Festlegen der rechtlichen Verbindlichkeit einen entscheidenden Vorteil: Bei Ressourcen-, Budget- und terminlichen Engpässen hilft es bei der Entscheidung darüber welche Anforderungen unverzichtbar sind und welche erst in einem späteren Release umgesetzt werden können.

Um die rechtliche Verbindlichkeit auszudrücken, können die Modalverben "muss", "sollte" und "wird" verwendet werden. Dabei steht das Modalverb

  • "muss" für eine Pflicht-Anforderung,
  • "sollte" für einen Wunsch und
  • "wird" für eine Absicht.

Die rechtliche Verbindlichkeit muss in jedem Fall mit dem Kunden abgestimmt und dokumentiert werden, sodass alle Beteiligten das gleiche Verständnis von der Bedeutung der Verbindlichkeit bekommen.

Bild 4: Varianten für die rechtliche Verbindlichkeit.

Da es sich bei der Anforderung aus unserem Beispiel um eine der zentralen und wichtigsten Anforderungen handelt, wird "muss" als rechtliche Verbindlichkeit verwendet. Das erste Fragment der Anforderung ist somit fertig:

"Die App muss "

Schritt 2 – das Prozesswort festlegen

Im zweiten und zugleich wichtigsten Schritt bestimmen Sie das Prozesswort. Das Prozesswort drückt die geforderte Systemfunktionalität aus und bildet damit den Kern der Anforderung. Um die Systemfunktionalität (einen bestimmten Prozess oder Vorgang) auszudrücken, werden ausschließlich Vollverben als Prozesswörter verwendet. Vollverben sind Verben, die alleine das Prädikat eines Satzes bilden, z.B. "speichern".

Das Verwenden von Vollverben hilft, schwammige Formulierungen zu Funktionalitäten zu vermeiden, welche die Anforderung mehrdeutig, unvollständig sowie inkonsistent machen würden und dadurch dem Leser der Anforderung Spielraum für Interpretationen lässt.

Schwammige oder mehrdeutige Formulierungen erhalten Sie meist dann, wenn Sie Substantivierungen oder Funktionsverbgefüge verwenden. Substantivierungen bedeutet in diesem Zusammenhang meist, dass Verben, die Prozesse beschreiben, in Substantive umgewandelt werden, z.B. "Bestellung" oder "Archivierung". Bei Funktionsverbgefügen handelt es sich dagegen um Kombinationen aus sogenannten inhaltsarmen Verben (machen, können, haben, sein, stellen …) und sinngebenden Substantiven, z.B. "etwas zur Verfügung stellen".

Sowohl bei Substantivierungen als auch bei Funktionsverbgefügen entsteht der Effekt, dass Anforderungen oder gar ganze Prozesse getilgt – d.h. verschleiert – werden. So verbergen sich z.B. hinter dem Begriff "Bestellung" Teilprozesse wie z.B. das Zusammenstellen des Warenkorbs und die Berechnung des Gesamtpreises mit wiederum eigenen Anforderungen. Die Formulierung "etwas zur Verfügung stellen" kann die Prozesse "Anzeigen", "Drucken" oder "Versenden" beinhalten, an die ebenfalls eigene Anforderungen gestellt werden. Diese Formulierungen machen also nicht eindeutig klar, was die Kernfunktionalität der Anforderung ist.

Daher sollten Sie bei der Bestimmung des Prozessworts unbedingt darauf zu achten, aussagekräftige Vollverben zu verwenden. Dies sind solche Vollverben, die einfache, elementare Prozesse darstellen, z.B. "drucken", "anzeigen", "speichern" oder in unserem Fall "anhängen". Oftmals lässt es sich nicht vermeiden, Vollverben zu verwenden, die komplexere Prozesse widerspiegeln wie z.B. "archivieren". In diesen Fällen ist es ratsam, das Vollverb in einem Glossar eindeutig zu beschreiben und damit abzugrenzen.

Nachdem das Prozesswort festgelegt ist, kann die Anforderung um den Kern erweitert werden: die Systemfunktionalität. Unser Praxisbeispiel sieht nun folgendermaßen aus:

"Die App muss etwas anhängen."

Schritt 3 – die Prozessart festlegen

Der dritte Schritt beim Erstellen einer gut dokumentierten Anforderung ist das Festlegen der Prozessart. Hierbei wird die Art der geforderten Systemfunktionalität bestimmt, die in drei Arten klassifiziert werden kann: "selbständige Systemaktivität", "Benutzerinteraktion" und "Schnittstellenanforderung".

  • Selbständige Systemaktivität besagt, dass das System die Funktionalität selbständig, also ohne Benutzeraktion und unabhängig von Nachbarsystemen durchführt.
  • Bei einer Benutzerinteraktion stellt das System dem Benutzer eine Funktionalität zur Verfügung. Bei dieser Funktionalität findet eine Interaktion zwischen dem System und dem Benutzer des Systems statt.
  • Bei einer Schnittstellenanforderung führt das System eine Funktionalität nicht selbständig, sondern in Abhängigkeit zu einem Nachbarsystem aus. Im Falle der App könnte eine solche Funktionalität das Anzeigen einer Meldung über die Genehmigung der Reisekosten sein. Nachdem die Reisekosten vom verantwortlichen Manager genehmigt wurden, schickt das Reisekostensystem eine Nachricht an das Smartphone des Mitarbeiters. Die App empfängt diese Nachricht, verarbeitet sie und blendet anschließend eine entsprechende Meldung auf dem Display des Smartphones ein.

Bild 5: Prozessart festlegen.

Die Art der Systemfunktionalität definieren Sie, indem Sie einen bestimmten Ausdruck vor das Prozesswort stellen:

  • Bei einer Benutzerinteraktion geben Sie an dieser Stelle eine Antwort auf die Frage "Wem" bietet das System die Möglichkeit, etwas zu tun?". Sie setzen den Ausdruck "<wem?> die Möglichkeit bieten" vor das Prozesswort. Für <wem?> setzen Sie eine bestimmte Benutzerrolle oder aber eine allgemeine Benutzerbezeichnung, wie z.B. "Benutzer" ein.
  • Für eine Schnittstellenanforderung setzen Sie den Ausdruck "fähig sein" vor das Prozesswort.
  • Wenn keiner der beiden Ausdrücke vor dem Prozesswort zu finden ist, handelt es sich um eine selbständige Systemaktivität.

Demnach bieten sich zum Charakterisieren der Funktionalität "anhängen" folgende Möglichkeiten:

  • Selbstständige Systemaktivität – Die App muss etwas anhängen.
  • Benutzerinteraktion – Die App muss dem Benutzer die Möglichkeit bieten, etwas anzuhängen.
  • Schnittstellenanforderung – Die App muss fähig sein, etwas anzuhängen.

Indem Sie die Prozessart festlegen, geben Sie den Projektmitarbeitern einen Hinweis über die Komplexität und damit über den Umsetzungsaufwand der geforderten Funktionalität. So verbirgt sich hinter Schnittstellenanforderung meist eine hohe Komplexität, da Daten und Nachrichten zwischen zwei Systemen ausgetauscht werden und unter Umständen Prozesse des Nachbarsystems angepasst werden müssen. Selbständige Systemaktivtäten sind in der Regel weit weniger komplex, da die Entwickler für diese keine externen Faktoren berücksichtigen müssen. Benutzerinteraktionen können einen ähnlich hohen Umsetzungsaufwand mit sich bringen wie Schnittstellenanforderung. Das liegt daran, dass bei Benutzerinteraktionen immer auch nicht-funktionale Aspekte wie z.B. Benutzbarkeit, Performance, Fehlertoleranz oder Barrierefreiheit berücksichtigt werden müssen.

Nachdem die Prozessart ermittelt wurde, in unserem Fall eine Benutzerinteraktion, ist das Grundgerüst der Anforderung fertig:

"Die App muss dem Benutzer die Möglichkeit bieten, etwas anzuhängen."

Schritt 4 – das Objekt & dessen Ergänzung hinzufügen

Als viertes fügen Sie der Anforderung das Objekt – das "etwas" – sowie dessen Ergänzungen hinzu, für das die Systemfunktionalität gefordert wird.

Bei dem Objekt handelt es sich um die Daten, die durch die Systemfunktionalität verarbeitet werden. Ein Objekt kann z.B. ein Systembenutzer mit bestimmten Benutzerdaten, ein Produkt mit bestimmten Produktdaten oder ein Bericht mit bestimmten Berichtsdaten sein. Im vorliegenden Praxisbeispiel sind das Objekt die Belege, die an den Reisekostenbericht angehängt werden.

Durch die Ergänzungen wird das Objekt näher beschrieben, um ein möglichst genaues Bild vom Objekt selbst, aber auch von der geforderten Systemfunktionalität zu erhalten. In unserem Fall werden die folgenden drei Ergänzungen verwendet:

  • Es handelt sich um abfotografierte Belege.
  • Die Belege werden an einen Reisekostenbericht angehängt.
  • An einen Reisekostenbericht können maximal 20 Belege angehängt werden.

Mit dem Hinzufügen des Objektes und dessen Ergänzungen ist die Anforderung fast vollständig:

"Die App muss dem Benutzer die Möglichkeit bieten, maximal 20 über das Smartphone abfotografierte Belege an einen Reisekostenbericht anzuhängen."

Schritt 5 – die Bedingung einarbeiten

Mit dem letzten Schritt hin zu einer gut dokumentierten Anforderung wird die Bedingung festgelegt, unter der die geforderte Systemfunktionalität ausgeführt wird. Die Bedingung präzisiert, wie auch schon das Objekt, die geforderte Systemfunktionalität, da diese für gewöhnlich nicht fortlaufend, sondern nur unter gewissen Umständen ausgeführt wird. Wir unterscheiden dabei zwischen logischen und zeitlichen Bedingungen:

  • Logische Bedingungen werden mit der Konjunktion "falls" eingeleitet.
  • Für zeitliche Bedingungen wählen Sie die Konjunktion "wenn"; alternativ können Sie auch Konjunktionen wie "bevor", "nachdem", "um" oder "während" verwenden.

In unserem Fall soll der Mitarbeiter Belege an einen Reisekostenbericht anhängen können, während er diesen erstellt. Die Bedingung wird als Nebensatz an den Anfang der Anforderung gestellt, wodurch die rechtliche Verbindlichkeit in der Satzstellung vor den Systemnamen wandert. Nachdem die Bedingung festgelegt wurde, ist die Anforderung aus dem Praxisbeispiel komplett:

"Während der Benutzer einen Reisekostenbericht erstellt, muss die App dem Benutzer die Möglichkeit bieten, maximal 20 über das Smartphone abfotografierte Belege an den Reisekostenbericht anzuhängen."

Ein klarer Unterschied...

Im Gegensatz zu der Anforderung aus dem Praxisbeispiel, die ohne die SOPHIST-Satzschablone formuliert wurde ("Es ist erforderlich, dass 20 Dateianhänge hochgeladen werden können."), geht unserer Anforderung deutlich hervor, dass

  • der Mitarbeiter über das Smartphone abfotografierte Belege an einen Reisekostenbericht anhängen können muss,
  • er dies tun können muss, während er den Reisekostenbericht erstellt,
  • an einen Reisekostenbericht maximal 20 Belege angehängt werden können und
  • dass es sich um eine der zentralen und wichtigsten Anforderungen der App handelt.

Grundregeln für die Anwendung

Bei der Anwendung der Methode gilt es gewisse Grundregeln zu beachten, um nicht aus einer gut dokumentierten Anforderung eine schwer lesbare Anforderung zu machen (s. Rupp 2009, S. 123 sowie Pohl, Rupp 2010 S. 56):

Regel 1: Anforderungen in vollständigen Sätzen beschreiben – "Stichpunkte sind tabu"

Jede Anforderung muss vollständig ausformuliert werden. Dies trägt dazu bei, dass jede Anforderung vollständig ist und keine Informationen verloren gehen oder hineininterpretiert werden können.

Regel 2: Anforderungen in kurzen Sätzen beschreiben – "Schachtelsatz ade"

Jede Anforderung muss kurz und prägnant beschrieben werden. Lange und komplizierte Schachtelsätze sollten Sie vermeiden. Wenn eine Anforderung sehr komplex ist, muss diese in kurze und prägnante Unteranforderungen unterteilt werden. Dies erhöht die Lesbarkeit und die Verständlichkeit der Anforderung.

Regel 3: Nur eine Anforderung pro Satz formulieren – "Weniger ist mehr"

Jede Anforderung darf nur aus einem Prozesswort – das heißt aus einer geforderten Systemfunktionalität – bestehen. Jede geforderte Systemfunktionalität muss einzeln beschrieben werden. So ist gewährleistet, dass jede Anforderung vollständig, eindeutig und korrekt dokumentiert ist.

Regel 4: Begriffe konsistent verwenden – "Gleiches schreiben, gleiches meinen"

Die Begrifflichkeiten in den Anforderungen (bspw. die Prozesswörter) müssen für alle Anforderungen einheitlich verwendet werden. Verwenden Sie wenn möglich keine Synonyme und Homonyme (Wörter, die für verschiedene Begriffe stehen) wie z.B. Kohle. Beides fördert die Eindeutigkeit der Anforderungen.

Zusammenfassung

Die Vielseitigkeit der natürlichen Sprache bringt die Gefahr mit sich, dass so dokumentierte Anforderungen unterschiedlich interpretiert und folglich missverstanden werden können. Das hier vorgestellte Praxisbeispiel hat aufgezeigt, welche Missverständnisse entstehen können, wenn Anforderungen mehrdeutig und unvollständig formuliert werden. Die Konsequenz sind Systeme, die nicht den Kundenerwartungen entsprechen.

Mit der SOPHIST-Satzschablone sorgen Sie dafür, dass in ihrem Projekt die funktionalen Anforderungen eindeutig, vollständig, verständlich sowie korrekt gemäß dem Standard IEEE Std 830-1998 dokumentiert werden und legen so einen Grundstein für den Erfolg Ihres Projekts.

Alternativ können funktionale Anforderungen auch mit Hilfe der aus der agilen Softwareentwicklung bekannten User Stories oder Snow Cards aus dem Volere-Template natürlich-sprachig dokumentiert werden. Im Vergleich zur SOPHIST-Satzschablone liegt der Fokus bei diesen beiden Methoden allerdings weniger auf der Bildung von vollständigen und aussagekräftigen Anforderungssätzen, sondern vielmehr auf der vollständigen und strukturierten Erfassung bestimmter Informationen rund um die Anforderung, wie z.B. Priorität, Abnahmekriterien oder Verweise auf Zusatzinformationen.

Literatur

  • Institute of Electrical and Electronics Engineers: IEEE Recommended Practice for Software Requirements Specifications (IEEE Std 830-1998). IEEE Computer Society, New York 1998.
  • Pohl, Klaus; Rupp, Chris: Basiswissen Requirements Engineering – Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level, dpunkt.verlag, Heidelberg 2010.
  • Rupp, Chris: Requirements-Engineering und -Management – Professionelle, iterative Anforderungsanalyse für die Praxis, Hanser Verlag, München 2009.

 

DownloadDownload

Jetzt Feedback geben und mitdiskutieren!

Wir würden uns über Ihre Bewertung und/oder einen Kommentar freuen ‒ nur so können wir Ihnen in Zukunft noch bessere Inhalte liefern.

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung.
12 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 23
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.