Missverständnisse beim Requirements Engineering

Das Requirements Engineering ist eine Disziplin, die wie ein Übersetzer die Kluft zwischen zwei Völkern überbrückt:

• Die Fachseite spricht beispielsweise Versicherungsdeutsch oder Medizinersprache, eventuell auch BPMN oder ARIS.
• Die technischen Mitarbeiter*innen sprechen UML, Java, ABAP, XML und dergleichen.

Zu den sprachlichen Unterschieden kommen noch kulturelle, beispielsweise verschiedene Kommunikationsstile und implizites Wissen. Für die Zusammenarbeit bieten sich verschiedene Modelle an:

• Die Fachseite wird zu Informatikern ausgebildet, damit sie sich an das Entwicklungsteam anpassen kann. Diese Option ist unüblich. Der Kunde muss sich nicht an den Dienstleister anpassen, sondern umgekehrt.
• Das technische Team erlernt die Fachsprache und kommuniziert mit der Fachseite in deren Idiom. Dieses Modell finden wir in langfristigen Partnerschaften oder wenn eine Softwarefirma sich auf eine bestimmte Branche spezialisiert hat.
• Beide Seiten finden und erlernen eine gemeinsame Sprache, oder entwickeln eine. Auch diese Investition lohnt sich nur in einer langfristigen Zusammenarbeit.
• Es gibt einen Übersetzer: den Requirements Engineer oder Berater oder Analysten oder Product Owner. Diese Person muss beide Sprachen fließend sprechen, in beiden Kulturen zu Hause sein und kann außerdem noch korrekt hin- und herübersetzen.

 

Was ist ein Missverständnis?

Im Folgenden geht es um Missverständnisse, die nach meiner Erfahrung bei der Übersetzung zwischen den beiden Völkern regelmäßig auftreten. Darauf müssen Sie als Requirements Engineer oder Product Owner achten. Zunächst einmal: Was ist ein Missverständnis? Ein Sprecher sagt (oder schreibt) etwas und ein Zuhörer (oder Leser) versteht etwas. Die folgende Tabelle stellt die vier Möglichkeiten dar, die dabei auftreten können:

• Der Idealfall ist der, dass der Zuhörer tatsächlich das Richtige verstanden hat und sich dessen auch bewusst ist.
• Wenn der Zuhörer glaubt, etwas nicht verstanden zu haben, unabhängig davon, ob dies stimmt oder nicht, kann er das Thema nachverfolgen und klären. Falls es ein Problem gibt, kann es aufgedeckt und gelöst werden.
• Ein Missverständnis tritt dann auf, wenn der Zuhörer glaubt, etwas richtig verstanden zu haben, obwohl dies nicht stimmt. Es kann mehr oder weniger lange dauern, bis dies entdeckt wird.

Auf Missverständnisse im Requirements Engineering folgen Fehler in der Software, die dann aufwändig wieder behoben werden müssen. Missverständnisse lassen sich vermeiden (nicht alle, aber viele), und darum sind solche vermeidbaren Mehraufwände immer schade.

Ursachen und Gegenmaßnahmen

Am besten packt man Probleme an der Wurzel. Darum betrachten wir im Folgenden einige wichtige Ursachen von Missverständnissen und wie man diese Art von Aneinandervorbeireden vermeiden kann.

• Die Bedeutung des Requirements Engineering ist unklar. In Schule und Studium haben viele sich angewöhnt, eine Vorlage mit beliebigen Inhalten zu befüllen, so dass kein Feld oder Kapitel leer bleibt. Kaum ein Dozent verlangt von den Studenten oder Schulungsteilnehmern, dass sie ihre eigenen Fehler noch beheben. Oder man erstellt die Spezifikation als Nachdokumentation nach der Implementierung. Im Kurs ist dieses Verhalten relativ unkritisch, da Dokument und Software nach der Bewertung weggeworfen werden. Dieses erlernte Verhalten wird in der Berufspraxis oft fortgesetzt. Dadurch verpasst man jedoch die Chance, sich vor der Implementierung ernsthaft Gedanken darüber zu machen, welche Anforderungen die Software erfüllen soll, also echte Anforderungen zu ermitteln. Was brauchen die Benutzer? Die Unterschätzung der Bedeutung des Requirements Engineering führt oft auch dazu, dass zu wenige oder die falschen Personen zugeteilt werden. Der Berufsanfänger soll sich durch Requirements Engineering einarbeiten, die Endbenutzer sollen nicht durch Workshops von der Arbeit abgehalten werden. Den Experten benötigt man woanders. Darum kann die Bedeutung des Requirements Engineerings für den Rest des Projektes nicht genügend betont werden. Hier werden verbindliche Vorgehen für die Umsetzung definiert, oder zumindest sollte das so sein.
• Verschiedene Wörter für dasselbe Ding oder dasselbe Wort für verschiedene Dinge: Bei Sprechern verschiedener Sprachen kommt dies regelmäßig vor. Dagegen hilft ein Glossar, das jedes Mal erweitert und aktualisiert wird, wenn ein weiterer Unterschied der Terminologien entdeckt wird. Dieses Glossar kann durchaus wie ein Wörterbuch die Begriffe in beiden Sprachen darstellen. Verwenden sollte man in der Spezifikation aber nur eine einzige Sprache, üblicherweise im Lastenheft die Fachsprache und im Pflichtenheft oder Entwurf die technische Sprache.
• Fehlendes Wissen aus der Fachdomäne: Kennt sich die Fachseite mit der Technik nicht aus, verursacht das weniger Schwierigkeiten als umgekehrt, wenn die technische Seite Anforderungen missversteht und implizite Annahmen nicht erraten kann. Vergessene Basismerkmale und nichtfunktionale Anforderungen kann ein branchenkennender Requirements Engineer selbst vorschlagen und gezielt erfragen. Er tut darum gut daran, sich ganz allgemein in die Anwendungsdomäne einzuarbeiten: Fachliteratur lesen, State-of-the-Art-Produkte auf dem Markt austesten.
• Unterschiedliche oder unterschiedlich viele Informationen können zu impliziten Annahmen führen, die der andere nicht erraten kann. Vermeiden lässt es sich nicht, dass nicht alle Details dokumentiert werden, denn sonst werden die Spezifikationen unhandlich umfangreich. Hier hilft nur die regelmäßige Kommunikation zwischen Fachseite und Technik bzw. mit dem Übersetzer!
• Falsche Erwartungen: Auf Messen und in Science Fiction Filmen werden bei der Fachseite überhöhte Erwartungen darüber geweckt, was technisch machbar ist. Erneut: Kommunizieren Sie viel miteinander und erstellen frühzeitig einen Prototypen, um Ihren Entwurf zu validieren und utopische Erwartungen zu erkennen und zu dämpfen.
• Vage, allgemeine Formulierungen: Die Spezifikation von Anforderungen verlangt eine geradezu mathematische Präzision und hohe Disziplin. Ein „Muss“ muss auch wirklich genau das bedeuten, Anforderungen müssen testbar sein. Der gute Requirements Engineer ist dafür ausgebildet, missverständnisvermeidend zu schreiben und zu modellieren.
• Fehlendes Wissen und fehlende Erfahrung im Requirements Engineering: Anforderungen müssen von einem Profi spezifiziert werden. Alle anderen tun sich schwer damit, selbst diejenigen Sachverhalte nach den Regeln der Kunst zu Papier zu bringen, die sie mündlich formulieren können, nicht mal als Freitext. Requirements Engineering erlernt man durch Schulungen, Übung und Feedback. Feedback über die Qualität der Anforderungen liefert spätestens der Abnahmetest. Frühzeitiger geht es durch eine regelmäßige Qualitätssicherung der Anforderungen. Auch Konsistenzchecks zwischen verschiedenen Kapiteln, Abstraktionsebenen oder zwischen Text und Bild sind ergiebig.
• Optimale Form der Spezifikation: Es gibt nicht die eine optimale Form für die Spezifikation. Ich selbst habe in jedem Projekt anders spezifiziert. Die Form folgt dem Inhalt und den Bedürfnissen der Beteiligten. Es ist sogar unnötig, dass alle Anforderungen gleich detailliert und in derselben Form dargestellt werden. Die Spezifikation ist dann fertig, wenn alle Unklarheiten und Missverständnisse ausgeräumt sind!
• Absicht und Taktik: Missverständnisse werden gerne auch absichtlich verursacht. Man kann bewusst vage formulieren, um verschiedene Interpretationen zuzulassen, z. B. weil man sich nicht festlegen möchte oder noch nicht kann oder die Tatsachen schönen will. Bei der Abnahme gilt dann natürlich die für den Kunden ungünstigere Interpretation.

 

Ein Appell

Ich plädiere dafür, dass Anforderungsspezifikationen genauso sorgfältig erstellt werden wie Vertragstexte. Es ist eine Unart, dass in der Praxis Anforderungen oft als unverbindliches Gekritzel gehandhabt werden, an das sich keiner gebunden fühlen muss.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Unter https://herrmann-ehrlich.over-blog.com bloggt Frau Dr. Andrea Herrmann regelmäßig über Requirements Engineering und Software Engineering.

Alles Wichtige über Requirements Engineering auf 37 Seiten jetzt als Download zum Mitnehmen.

Im t2informatik Blog hat Dr. Andrea Herrmann weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.