Initiales Product-Backlog versus Anforderungssammlung
Zu Beginn des Projektes sollten am höchsten priorisierte Anforderungen in einer unstrukturierten Anforderungsliste zu jeder geplanten Applikation (Produkt) gesammelt werden, um dem Inhalt des Vorhabens abzustecken. Bei dieser Gelegenheit ist eine grobe Abschätzung der Größenordnung des verbundenen Aufwandes aus Sicht der Auftraggeber und auch aus Sicht der umsetzenden Personen auszutauschen und soweit wie möglich einzugrenzen. Dazu sollten fachliche Anforderungen, technische Anforderungen und Nichtziele entsprechend gekennzeichnet werden. Jede Anforderung wird mit einer eindeutigen Nummer gekennzeichnet.
Dabei nehmen die beteiligten Personen meist unterschiedliche Rollen ein, die in der Praxis eine andere Sprache verwenden.
Fachliche AnsprechpartnerInnen sprechen die Sprache Ihrer AnwenderInnen und der Endkunden, und haben wenig Interesse an technischen Details. EntwicklerInnen und TesterInnen bzw. Mitglieder agiler Teams müssen neben dem Verständnis der funktionalen Anforderungen auch eine geeignete technische Lösung skizzieren und damit verbundene Detailfragen klären um ein Entwicklungsprojekt starten zu können.
Im Pflichtenheft oder Backlog "smarte" Visionen und Ziele abstimmen:
Initiale Wünsche können mit Hilfe der folgenden Fragen abhängig vom Detailgrad in überprüfbare Visionen, Ziele und einzelne Anforderungen transformiert werden:
- Welche Ergebnisse wünsche ich nach dem Projektabschluss bzw. in der kommenden Auslieferung?
- Welche AnwenderInnen sollen bei welchen Aufgaben zur Erreichung welcher Ziele unterstützt werden?
- Wie können diese Ergebnisse überprüft werden? (Testkriterien)
- Bis wann sind die Ergebnisse zu liefern - bzw. welche ersten Ergebnisse bieten unmittelbaren Geschäftswert?
- Sind die geforderten Ergebnisse realistisch und andererseits anspruchsvoll genug um ein Projekt zu starten?
Brücke zwischen der fachlichen und technischen Sichtweise: Pflichten
Requirements Engineers (Analytiker) helfen, Brücken zwischen den beiden Lagern zu bauen, in dem aus einer initialen Anforderungsammlung oder aus einem ausgearbeiteten Lastenheft ausgewählte Kapitel aus einem daraus abgeleiteten Pflichtenheft für beide Zielgruppen erstellt werden. Dazu zählt eine kurze Definition der erwähnten "smarten Ziele", sowie explizit festgehaltene Nichtziele zur Abgrenzung.
Damit am Ende eine weitgehend einheitliche Sichtweise erreicht wird, ist neben dem persönlich Gespräch auch die gemeinsame schriftliche Überarbeitung der Ziele und anderer wichtiger Inhalte des Pflichtenhefts mit Hilfe eines Reviews sinnvoll. Dieser Umstand wird häufig als Ineffizienz, von Vertriebsmitarbeitern und Einkäufern auch als Inkompetenz fehlinterpretiert, die auch den damit verbundenen Mehraufwand beim Kunden bzw. beim Einkäufer erklären müssen.
Die genannten Abstimmungen finden immer im Spannungsfeld zwischen Kosten und Qualität statt, die laufend mit Augenmaß gegeneinander abzuwägen sind.
Brücke zwischen der fachlichen und technischen Sichtweise: Agile Anforderungen
Im Rahmen eines agilen Management-Frameworks wird die Rolle der Requirements Engineers (Analytiker) vom Product Owner und vom Scrum-Team (DevOps) wahrgenommen, die gemeinsam eine erste Sichtung der Anforderungen und Visionen vornehmen. Die initialen Anforderungen sollten in diesem Fall entweder in Form einer initialen Befüllung des Product-Backlogs oder in Form einer Anforderungssammlung (siehe oben) zur ersten Version des Produktes vorbereitet werden sollte.
Das initiale Backlog enthält in der Regel nur grob skizzierte Epics, User Stories und eine Vision der ersten Version des angestrebten Produktes.