Anforderungen spezifizieren: Die richtige Methode zur richtigen Zeit

‍Eine gute Software beginnt mit klaren Anforderungen. Je besser alle Beteiligten dasselbe Verständnis haben, desto einfacher wird die Umsetzung und desto geringer das Risiko, dass die Anwendung bei der Pilotierung und beim Rollout nicht den erwarteten Mehrwert bringt. Genau deshalb lohnt es sich, Anforderungen aus verschiedenen Blickwinkeln zu betrachten. Aus diesem Grund verfolgt healthinal einen strukturierten Prozess, um Anforderungen unterschiedlicher Nutzendengruppen zu erfassen, zu strukturieren und in die Lösungsdefinition einzubinden.

Es gibt nicht die eine Methode in der Concept Iteration, die immer passt, um diese Anforderungen zu spezifizieren. Je nach Projektphase und Ziel helfen unterschiedliche Modelle dabei, Prozesse verständlich aufzuzeigen, Zusammenhänge sichtbar zu machen oder technische Details zu beschreiben.
Am Anfang reicht oft der Blick aufs grosse Ganze. Dafür eignet sich eine Prozessübersicht, die die wichtigsten Abläufe aufzeigt und allen Beteiligten hilft, das System besser zu verstehen und einzuordnen. Sie schafft Orientierung und bildet die Grundlage für alle weiteren Modelle, die angewendet werden können für die Anforderungsspezifizierung.

Das System im Kontext verstehen

Ein solches Modell ist das Kontextdiagramm. Es zeigt, welche Personen oder Systeme mit der digitalen Anwendung interagieren und wo die Systemgrenzen liegen. So werden Schnittstellen früh sichtbar und offene Fragen können gemeinsam geklärt werden.

Prozesse visualisieren

Mit einem Aktivitätsdiagramm lassen sich Prozesse detailliert darstellen. Ein solches Diagramm zeigt, welche Aktivitäten nacheinander oder parallel stattfinden und an welchen Stellen Entscheidungen getroffen werden.
Gerade im Gespräch mit Kund:innen erleichtert diese Darstellung das gemeinsame Verständnis. So entsteht eine Lösung, die die Bedürfnisse aller Beteiligten abholt und darstellt. Missverständnisse werden früh erkannt und können direkt besprochen und adressiert werden.

Wenn die fachlichen Prozesse klarer sind, rückt die technische Umsetzung in den Mittelpunkt. Dafür eignen sich Sequenzdiagramme gut. Sequenzdiagramme zeigen, wie verschiedene Systeme oder Komponenten miteinander kommunizieren basierend auf den Erkenntnissen der vorherigen Anforderungserhebungen, die nutzer- und prozessorientiert sind. Sequenzdiagramme beschreiben die zeitliche Reihenfolge der Interaktionen und helfen Entwickler:innen dabei, Funktionen sauber zu implementieren.

‍
Die Perspektive der Benutzer

Nicht jede Anforderung ist rein technisch. Oft entscheidet die Benutzererfahrung darüber, ob eine Lösung erfolgreich ist. Deshalb ist es zentral, diese Benutzenden von Anfang an in die Lösungsentwicklung miteinzubeziehen.
Eine User Journey Map zeigt die einzelnen Berührungspunkte der verschiedenen Nutzenden mit dem System. Sie macht sichtbar, an welchen Stellen positive oder negative Erlebnisse entstehen. Dadurch lassen sich Anforderungen konsequent an den Bedürfnissen der späteren Anwender:innen ausrichten.

User Stories: klein, verständlich und umsetzbar

Wenn die Prozesse und Abläufe definiert sind, gilt es die daraus resultierenden Anforderungen einfach und nutzerorientiert zu beschreiben. Dies geschieht in Form von User Stories: Sie zeigen nicht nur, was umgesetzt werden soll, sondern insbesondere den Mehrwert und der Nutzen der Umsetzung.
Eine gute User Story folgt diesem Muster:
Als [Benutzer:in] möchte ich [Ziel], damit [Nutzen].
Der Beschreib des Nutzen ist zentral: Er macht sichtbar, welchen Mehrwert die Anforderung für die Benutzer:innen bringt. Ohne klaren Nutzen bleibt eine User Story oft zu technisch oder zu allgemein.

Die richtige Grösse für einen Sprint

Eine User Story sollte so gross sein, dass sie innerhalb eines Sprints umgesetzt werden kann. Ist sie zu umfangreich, wird sie schwer planbar. Dann sollte sie in kleinere Stories aufgeteilt werden. Eine gute Story ist klein genug, um sie zu verstehen, umzusetzen, zu testen und abzuschliessen. Damit schaffen Stories in sich geschlossen Mehrwert. So bleibt der Fortschritt im Sprint sichtbar und das Team kann verlässlich planen.

User Stories müssen schätzbar sein

Damit ein Team planen kann, muss schätzbar sein, wie aufwendig eine User Story in der Umsetzung ist. Dafür braucht es ein gemeinsames Verständnis: Was soll genau passieren? Welche (Spezial-)Fälle müssen berücksichtigt werden? Welche Abhängigkeiten gibt es?
Ist eine Story nicht schätzbar, fehlen meist wichtige Informationen zum Nutzen der Story oder zur geplanten Umsetzung. Dann sollte das Team die offenen Punkte zuerst klären, bevor die Story in einen Sprint eingeplant wird.

Akzeptanzkriterien schaffen Klarheit

Eine wichtige Komponente bei der Erfassung von User Stories sind die Akzeptanzkriterien. Sie beschreiben, wann eine User Story erfüllt ist. Sie machen Erwartungen greifbar und helfen beim Testen und beim Entscheiden, ob sie gemäss den Anforderungen umgesetzt wurde.
Gute Akzeptanzkriterien sind klar, konkret und überprüfbar. Sie beantworten zum Beispiel folgende Fragen:

• Was muss funktionieren?
• Welche Regeln gelten?
• Welche Fehlerfälle müssen abgefangen werden?
• Wann gilt die Story als fertig?
  ‍

Einfache Sprache für alle

User Stories sollen für alle verständlich sein. Nicht nur für Entwickler:innen, sondern auch Kund:innen, Product Owner, Fachpersonen und Tester:innen müssen sie verstehen.
Darum sollten User Stories in einfacher Sprache geschrieben sein. Fachbegriffe sind nur dann sinnvoll, wenn alle Beteiligten sie kennen. Kurze Sätze, klare Begriffe und konkrete Beispiele helfen mehr als komplizierte Formulierungen.
Eine gute User Story schafft ein gemeinsames Verständnis. Genau das ist ihr Ziel.

Fazit

Anforderungen zu spezifizieren bedeutet mehr, als Wünsche aufzuschreiben. Es geht darum, ein gemeinsames Verständnis zwischen Kund:innen, Anwender:innen und Entwickler:innen zu schaffen und die Grundlage für eine erfolgreiche Umsetzung zu legen.
Je nach Fragestellung kommen, wie oben aufgezeigt, unterschiedliche Methoden zum Einsatz. Prozessübersichten und Kontextdiagramme schaffen Orientierung. Aktivitäts- und Sequenzdiagramme machen fachliche und technische Abläufe nachvollziehbar. User Journey Maps richten den Blick auf die Bedürfnisse der Benutzer:innen und User Stories übersetzen diese Anforderungen in konkrete, umsetzbare Aufgaben. Die Spezifizierung der Anforderungen ist ein iteratives Vorgehen, innerhalb der Concept Iteration. Es wird solange iteriert, bis die Anforderungen klar und verständlich sind und sie bereit für die Entwicklung, also fürs Software Development sind.
Wer Anforderungen strukturiert erfasst und verständlich dokumentiert, reduziert Missverständnisse, vereinfacht die Zusammenarbeit und schafft die Basis für Software, die den Bedürfnissen der Benutzer:innen entspricht und langfristig nachhaltigen Mehrwert im Alltag bringt.

‍
Mehr zu dieser Blogreihe und unserem Ansatz erfährst du in den vorhergehenden Blogbeiträgen «Anforderungen erheben und priorisieren. Oder: System statt Wunschkonzert» und «Requirement Engineering: Gute Healthcare-Software beginnt lange vor dem ersten Code». Im nächsten Blogartikel beschreiben wir, wie wir Anforderungen visualisieren und damit in der Concept Iteration die Anforderungen noch einen Schritt näher an die schlussendliche Lösung heranführen.