Requirements Engineering für die 3 Amigos

Software beginnt als Idee, als eine Vision. Wenn der Visionär selbst Softwareentwickler ist, reicht das vielleicht schon, um ein großartiges Produkt zu entwickeln. Wenn dieser Visionär aber kein Entwickler ist, muss er das, was in seinem Hirn ist, in die Hirne anderer übertragen, die mit ihm die Software entwickeln. Und das geht nicht ohne Kommunikation.

Effiziente Kommunikation braucht schnelles Feedback, um rasch herausfinden zu können, ob die anderen die eigenen Ideen richtig verstanden haben. Deswegen entwickeln agile Teams in kurzen Sprints. Oft benutzen sie User Stories als Versprechen, über Anforderungen zu reden. Dokumentiert werden die Anforderungen in Form von Akzeptanzkriterien.

Durch das kommunikative Feedback während des Backlog Refinements und das Nutzerfeedback am Ende eines Sprints im Review können Missverständnisse relativ schnell erkannt werden.

Aber auch wenn nur ein Sprint in die falsche Richtung entwickelt wurde, sind Irrtümer in die Codebasis eingeflossen, auf denen vielleicht andere Teams schon aufgebaut und weiterentwickelt haben.

Wie kann die Codebasis vor falsch verstandenen Anforderungen geschützt werden?

Hier kommt Behaviour Driven Development (BDD) ins Spiel.

Drei Personen sind daran beteiligt, die sogenannten 3 Amigos: ein Product Owner, ein Entwickler, und ein Tester. Oder besser, da es in Scrum die letzten beiden Rollen nicht gibt: Jemand mit Fach-Knowhow, jemand mit Entwickler-Knowhow und jemand mit Test-Knowhow.

 Die 3 Amigos treffen sich, und illustrieren die Akzeptanzkriterien mit Hilfe konkreter Beispiele. Durch dieses gemeinsame Spezifizieren der Beispiele entsteht eine gemeinsame Sprache. Sie schafft die Basis für ein gemeinsames Verständnis der Anforderungen.

Konkrete Beispiele zwingen uns, sehr genau darüber nachzudenken, was wir wirklich wollen und dies auch präzise zu formulieren. Konkrete Beispiele helfen uns nicht nur dabei, herauszufinden, ob wir ein gemeinsames Verständnis eines Systemverhaltens haben, sondern auch dabei, die Dinge zu entdecken, die wir noch nicht wissen.

Abstrakt formulierte Anforderungen, auch wenn sie qualitativ hochwertig sind, sind immer interpretationsfähig und können leicht missverstanden werden. Die „richtige“ Interpretation, nämlich die, die sich der Anforderungssteller (Fachbereich) vorgestellt hat, ist effizienter mit Hilfe von konkreten Beispielen möglich.

Die konkreten Beispiele können in automatisierte Akzeptanztests überführt werden, die das Verhalten des Systems aus Sicht der Benutzer in der Fachsprache beschreiben und testen. Diese Tests können daher automatisiert prüfen, ob die Implementierung die Anforderungen erfüllt. Heute, und auch in Zukunft.

 Um die Beispiele leicht automatisieren zu können, hat sich die Gherkin-Notation eingebürgert. Sie benötigt nur wenige Schlüsselwörter wie etwa Given, When und Then, und ist damit leicht von allen Beteiligten zu verstehen. Mit dieser Notation kann man sowohl Akzeptanzkriterien für User Stories systematisch und strukturiert erheben, als auch die Akzeptanzkriterien als Input für die automatisierten Tests verwenden.

 BDD ist ein mächtiges Kommunikationswerkzeug, eine Methode, um die Kommunikation zwischen allen Beteiligten zu unterstützen und zu verbessern. BDD kann uns dabei helfen, die Hindernisse, die eine bessere Kommunikation erschweren, aus dem Weg zu räumen.

Beispiele zur Gherkin-Notation finden Sie im Blog-Beitrag meines Kollegen Bertil Muth.

Wenn Sie noch mehr zum Thema erfahren wollen, sind sie hier richtig.

Ach ja, und wenn  Sie mehr zum Thema „Anforderungen“ erfahren möchten, dann empfehle ich Ihnen, eines unserer beliebten Public Trainings zum Requirements Engineering oder Agile zu besuchen.