Modernes Requirements Engineering ist Kommunikation – Teil 2

Sind gut und sauber formulierte Anforderungen zielführend? Sind Qualitätskriterien für Anforderungen zielführend? Im letzten Teil haben wir gesehen, dass eine recht umfangreiche Liste an Kriterien für Anforderungen und Anforderungsdokumente existiert. Damit lässt sich ganz leicht ein Heer von sogenannten Beratern und Anforderungsingenieuren beauftragen. Lohnt sich das?

Der Aufwand für gute Formulierung von Anforderungen kann bis ins Unendliche geführt werden. Berechtigterweise will keiner dafür zu viel Zeit, wenn überhaupt, investieren. Der Projektmanager möchte keine Ressourcen (kein Geld, keine Zeit, kein Personal) dafür verschwenden. Den Entwicklern selbst ist das Formulieren lästig und wird als „Overhead für Dokumentation“ ihrer, schon im Kopf detailliert vorhandenen und doch so genialen, Ideen empfunden.

Qualitätskriterien sind selbst nicht SMART

Die Kriterien für Anforderungen haben das Problem, dass sie sich selbst, bzw. nicht einmal den SMART-Kriterien entsprechen, denn sie sind z.B. nicht mess- oder prüfbar beschrieben: Wann ist denn eine Anforderung beispielsweise wirklich „verständlich“ oder „eindeutig“?

Für die richtige Interpretation der Kriterien muss dafür ein erfahrener Requirements Engineer im Vorfeld sorgen, und zwar angepasst auf das konkrete Projekt, an das Umfeld, die Phase oder Reife der Ideen zum Produkt. Ganz besonders jedoch sollte die Optimierung der Anforderungen an die jeweiligen Stakeholder der Anforderungen angepasst sein.

Stakeholder einer Anforderung

Wer ist denn ein „Stakeholder“ einer Anforderung? Das sind alle Beteiligten, Involvierten und Betroffenen dieser Anforderung. Der Requirements Ingenieur ist meist nur zu einem geringen Teil ein „Stakeholder“ der Anforderung. Normalerweise sind bei jeder Anforderung mehrere Personen betroffen oder involviert. Typischerweise betrifft eine Anforderung den Anforderungsgeber (z.B. den Product Owner), den Anforderungsempfänger (z.B. das Development Team, den Projektmanager), und – am wichtigsten und oft vergessen – den Endnutzer.

Daher können Sie als „Anforderungsschreiber“ oder auch als „Requirements Engineer“ die Anforderungen so viel nach Kriterien optimieren, wie sie wollen. Wenn Sie dabei die eigentlichen Betroffenen und Involvierten außer Acht lassen, wird das „gute Anforderungen- Schreiben“ am Ende nicht den gewünschten Effekt bringen. Gehen Sie daher viel und aktiv mit den Stakeholdern der Anforderungen in die Kommunikation! Das klingt selbstverständlich, wird jedoch in der Praxis aus meiner Erfahrung fast durchgehend nicht ausreichend beachtet.

Gute Anforderungen: 3 Grundregeln

In der Praxis bewähren sich dafür drei gute Grundregeln, die dem Requirements Engineer helfen, zu entscheiden, ob die Anforderung schon ausreichend gut formuliert ist.

Grundregel 1: konkret überprüfbar

Die Anforderung sollte so beschrieben sein, dass sie konkret überprüfbar ist (manche merken es sich auch unter: nachprüfbar, messbar, erfüllbar, verifizierbar, testbar, Akzeptanzkriterien, Abnahmekriterien, …). Der jeweilige „Anforderungsschreiber oder -geber sollte in seiner Anforderung ganz konkret die Kriterien beschreiben, unter denen er die Anforderung als „erfüllt“ erklären würde, nachdem sie einmal umgesetzt sein wird. Und diese geplante Art der Überprüfung soll konkret in der Anforderung formuliert sein. Wie detailliert diese „Messbarkeit“ beschrieben wird, hängt von der entsprechenden „Abstraktionsebene im Informationsmodell ab (siehe auch Blogs zu Informationsmodell, Anforderungen strukturieren).

Ein Marketingleiter als Anforderungsschreiber wird seine Anforderung anders nachprüfen wollen als ein Software-Designer, und das ist auch gut so.

Grundregel 2: Nur das WAS, nicht das WIE

Die Anforderung sollte das Problem, den Wunsch oder das Ergebnis der Anforderung möglichst präzise beschreiben, jedoch die zugehörige (evtl. detaillierte) Lösung soweit wie möglich nicht vorgeben. Die Anforderung sollte das „Was“ so genau beschreiben, bis die detaillierte Art der Umsetzung, also das „Wie“, für den jeweiligen Anforderungsgeber unwichtig oder „egal“ ist. Um die Details des „Wie“ kümmern sich ja dann die (kongenialen) Entwickler, Designer, Architekten und das Entwicklungsteam selbst im Laufe der Entwicklung. Wie allgemein oder wie spezifisch die Anforderung geschrieben sein sollte, variiert mit der Abstraktionsebene der jeweiligen Spezifikation. Zum Beispiel dürfen die „Business Requirements“ deutlich anders und weniger technisch, weniger lösungsorientiert formuliert sein als zugehörige „Komponentenlastenhefte“.
Zur Struktur von Anforderungen s.a. Struktur von Anforderungen und Anforderungsdokumenten (Blog–Serie Anforderungen strukturieren).

Grundregel 3: Gemeinsames Verständnis

Ganz wichtig: Am Ende muss mit der Anforderung erreicht sein, dass unter allen relevanten Stakeholdern der jeweiligen Anforderung ein gemeinsames und übereinstimmendes Verständnis herrscht. Dazu reicht eine theoretisch saubere Formulierung der Anforderung nicht aus. Hier kommt mehr Kommunikation ins Spiel als mancher sich das wünschen würde. Dieses „gemeinsame Verständnis“ wird natürlich im Laufe der Entwicklung die ein oder andere Abstimmung erfordern. Andererseits erlaubt dieses Kriterium auch, dass sehr „schlechte“ Anforderungen formuliert werden dürfen, falls wirklich alle (jeder der Betroffenen) genau wissen, was damit gemeint und zu entwickeln ist. Es ist natürlich gefährlich, wenn ich hier empfehle, dass auch „schlecht geschriebene“ Anforderungen erlaubt sind. Aber wenn es sich um eine Spezifikation handelt, die z.B: nur zwischen zwei Parteien ausgetauscht wird, und auch keine Wiederverwertung in der Zukunft oder von anderen „Lesern“ zu erwarten ist, dann kann auch durchaus „ein Stichpunkt“, eine grobe „User Story“ oder ein Begriff als Pseudo-Anforderung ausreichen, solange das gemeinsame Verständnis beider Parteien gewährleistet ist (und auch keine weiteren Parteien, z.B. auch in der Zukunft betroffen sind).

Intensiv kommunizieren

Gute Kommunikation ist bei allen drei Regeln wichtig, um das richtige Maß der Dinge zu finden. Wie oben schon gesagt, sind an einer Anforderung nicht nur der “Schreiber” beteiligt, sondern fast immer mehrere Stakeholder! Gerade Grundregel 3 erfordert daher eine intensive Kommunikation zwischen allen Beteiligten. Einzelgespräche helfen oft im Vorfeld der Anforderungserstellung. Ein fundiertes und finales “gemeinsames Verständnis” über eine aufgeschriebene Anforderung erreicht man üblicherweise durch ein gemeinsames Review (mit allen! notwendigen Parteien), bei dem die Übereinstimmung auch formal bestätigt werden kann (z.B. Unterschrift, setzen eines Attributs “approved”, etc.).

In der Praxis kann man oft spezielle Typen von Stakeholdern beobachten, um die sich der Requirements Engineer besonders kümmern sollte:

Stakeholder mit viel technischem Wissen, wie z.B. Entwickler, tendieren dazu, die Anforderung zu detailliert zu schreiben und sehr sehr viel – zu viel Lösung, anstatt das Problem oder das Ziel zu beschreiben.

Hierbei hilft die Frage nach dem WOZU? (auch “Warum” ist ok): Statt der detaillierten Lösung lieber den Zweck in der Anforderung beschreiben, was soll damit erreicht werden. Hiermit gelingt es, die Anforderung eine Stufe abstrakter (d.h. eine Abstraktionsebene höher) zu beschreiben. Und – unglaublich aber wahr – auch eine Abstraktionsebene höher kann man die Anforderung konkret messbar beschreiben, ohne die Lösung von vorne herein vorzugeben.

Es gibt auch Stakeholder, die zu schwammig artikulieren:

Hier hilft es oft, die Beschreibung der Messbarkeit zu präzisieren. Damit präzisiert man nicht automatisch die Lösung, gibt konkrete Abnahme- oder Akzeptanzkriterien vor und lässt den Entwicklern selbst trotzdem Freiraum für Kreativität und Innovation.

Kommunizieren ist nicht für jeden leicht

Mit den 3 Grundregeln kommen Sie leicht zu extrem gut formulierten Anforderungen. Was ist anders? Sie erfordern sehr viel mehr Kommunikation unter den Stakeholdern. Und das fällt wahrlich nicht jedem leicht. Viele geniale Experten wollen nur entwickeln, forschen oder hacken. Reden, Kommunizieren, Meetings und Dokumentieren sind für sie eher Fremdwörter. Möglicherweise kennen Sie solche Vollblut-Ingenieure, Experten oder sogar Nerds. Daher sollten Sie, in der Rolle des Requirements Engineers, Ihr Team fördern und bei der Kommunikation immer stark unterstützen.

Im nächsten Teil werde ich darauf eingehen, inwieweit gut formulierte Anforderungen wirklich zum gewünschten Ziel führen und welche Fehler dabei passieren können.

Series Navigation

<< Modernes Requirements Engineering ist Kommunikationskultur – Teil 1