Anforderungen – oder: Wie man als strahlender Held den neunköpfigen gordischen Knoten reitet...

Projekterfolg steht und fällt mit Anforderungen – das ist bekannt. Aber ist das wirklich so schwierig? Eigentlich liest man doch dauernd über Requirements Engineering, zum Beispiel

• Requirements Engineering von Klaus Pohl
• Das berühmte Volere Template
• Artikel, Paper und Vorträge von Chris Rupp von der Sophist Group 

Best Practices zur Formulierung von Anforderungen finden Sie hier.

Ein paar Anforderungen zu sammeln, ist eigentlich einfach: viele Unternehmen verwenden Excel, einige hingegen spezielle Software wie Doors oder andere. Auch Ticketsysteme wie Jira werden gerne als Anforderungsverwaltung eingesetzt.

Und die Verwaltung?

Mit welchem Tool verwalten Sie als Projektleiter die wachsende Liste? Word? Excel? Wiki-Systeme wie Confluence? Ticket-Systeme wie Jira? Viele Unternehmen nutzen Excel – ist sowieso vorhanden, mittlerweile mengentauglich und jeder kennt es. Und der ein oder andere kann sogar Makros programmieren – ganz ohne IT-Abteilung!

Schnell geht mit der wachsenden Anforderungsflut die Übersicht verloren, aber halt, in Excel nutzen Sie doch einfach Auto-Filter, Pivot-Tabellen und Gruppierungen! Jetzt müssen Sie noch kurz das Feedback der Stakeholder einholen, also Datei versenden und hoffen, dass die alle nur ins vorgesehene Feld schreiben.

Dummerweise geht das mehrfach so, weil eine Antwort mitunter weitere Fragen hervorruft. Und Stakeholder gibt es mehr, als Sie dachten. Die fangen an, Antworten und Kommentare mit individuellen Farben zu markieren, weil man so einfacher auf einen Blick den Zusammenhang sieht. Oft trifft man zudem auf die Kombination aus Excel zum Filtern und Sortieren und Word zur textuellen Beschreibung.

Haben Sie das schon mal erlebt? Nach meiner Beobachtung erstellen vor allem Techniker und Ingenieure mit Vorliebe Funktionslisten: Benutzerregistrierung, Anmeldevorgang, Suchfunktion, Neuanlage von Geschäftsobjekten Typ A, Neuanlage von Geschäftsobjekten Typ B, ...

Hilft das den Stakeholdern, wenn sie die Anforderungen prüfen und freigeben sollen? Ich erinnere mich an ein Projekt, in dem die Stakeholder sich nach einigen Runden außer Stande sahen, die Beschreibungen jeweils zu prüfen und freizugeben. Wie beherrschen Sie die Komplexität? Noch mehr Makros und Filter?

Hier hilft Ihnen nur Struktur: vom Groben zum Detail, auf jeder Ebene Übersicht schaffen!
Welche Strukturierung passt zu Ihrer Anwendungsdomäne? Eine generelle Antwort ist schwierig: "Embedded Software" im Anlagenbau unterscheidet sich deutlich von Online Transactional Processing (OLTP), also Verwaltungssoftware, in Unternehmen.
Meine Domäne sind OLTP-Systeme, bei denen immer – und wirklich immer – folgende Struktur schnell Nutzen schafft:

Strukturen

Geschäftsprozesse

Womit erwirtschaftet das Unternehmen Gewinn? Oft sind durch Betriebsorganisation oder ähnliche Stakeholder Prozesse schon dokumentiert. Zudem kann man schnell in wertschöpfende Kernprozesse und unterstützende Prozesse unterscheiden. Meist erhält man eine Folge von Prozessbereichen, die auch zeitlich darstellbar sind. Beispiele:

• Produktentwicklung in einem Versicherungsunternehmen: stellt oft den ersten Schritt im Lebenszyklus eines Produktes dar, inklusive Ideenfindung, Berechnungen, Dokumentation, etc.
• Marketing des entwickelten Produktes ist der nächste Schritt: das Unternehmen bewirbt das Produkt 
• Vertrieb fokussiert sich auf die Ansprache einzelner Kunden: denen muss man natürlich den Produktpreis individuell benennen können
• Abschluss folgt dem Vertrieb, in der Versicherungsdomäne ein sehr wichtiger Prozessbereich mit vielen einzelnen Prozessen

Use Cases – Anwendungsfälle

Wer macht was mit dem System? Hier beschreiben Sie die Prozessanteile, die mit dem zu entwickelnden System umgesetzt werden. Dabei führen „Akteure“ die Schritte des Use Cases aus. Ein Use Case stellt einen abgeschlossenen Bearbeitungsschritt dar – und kann auch von einem externen Systeme als Akteur ausgeführt werden (Beispiel unten).

User Stories: hier wird’s agil... 

Man kann einen Use Case meist gut zerlegen in kleinere Teile (Login, Suchen, Ergebnisse sortieren). Das hilft bei agilen, kurzen Sprints: das Team kann die Story auch wirklich in der Zeit umsetzen, der gesamte Use Case kann in mehreren Sprints entstehen (Beispiel unten).

Nichtfunktionale Anforderungen

Gerne vergessen und immer ein Kostenfaktor: wie schnell soll eigentlich das System jeweils reagieren? Und wie viele Datensätze verarbeiten Sie denn so? Es macht ja doch einen Unterschied, ob man das System für 10.000 oder 10 Millionen Datensätze pro Stunde entwirft.

Beispiele 

Use Cases – ganz grob

• Akteur Sachbearbeiter
• Antrag erfassen: Unbearbeiteten Antrag wählen, gescannten Papierantrag anzeigen,  automatisch erfasste Daten sichtprüfen, fehlende und falsche Daten nachtragen, Antrag prüfen und freigeben.
• Akteur Zeitsteuerung
• Antragsprüfung einmal pro Tag starten: freigegebene Anträge für die Prüfung finden, jeden Antrag maschinell prüfen, Ablehnung oder Bestätigung veranlassen.
• Akteur externes System, hier Data Warehouse (DWH)
• Daten neuer Anträge exportieren an das DWH: pro Sparte Daten selektieren und verdichten, Ergebnisse exportieren, erfolgreichen Lauf vermerken.

User Stories (Beispiel Antrag erfassen)

• Als Sachbearbeiter wähle ich einen gescannten und automatisch erkannten, aber noch nicht bearbeiteten Antrag aus, um ihn zu bearbeiten und dadurch einen Vertragsabschluss vorzubereiten.
• Als Sachbearbeiter lasse ich mir den gescannten Papiereintrag anzeigen, um die automatisch erkannten Einträge zu prüfen und gegebenenfalls zu korrigieren.
• Als Sachbearbeiter vergleiche ich automatisch erkannte Feldinhalte mit dem Scan-Bild und korrigiere Fehler.
• Als Sachbearbeiter starte ich die automatische Prüfung und gebe den Antrag frei, wenn keine Probleme erkannt wurden, um den Vertragsabschluss zu ermöglichen.
• Als Sachbearbeiter starte ich die automatische Prüfung und setze den Antrag auf Wiedervorlage bei Problemen. Hiermit werden fehlerhafte Anträge nachbearbeitet.

Das wirkt auf den Leser nüchtern und langweilig? Mag sein, die Einfachheit der User Stories erlaubt aber eine Bearbeitung z.B. in einem Sprint und vermeidet Mehrdeutigkeiten. Denken Sie daran: was Sie nicht reinschreiben, wird spätestens dann vom Entwickler interpretiert.

Die oben gezeigte Struktur hilft bei der Verwaltung von Anforderungen, sowohl in traditionellen als auch in agilen Projekten! Probieren Sie es aus – und finden Sie Ihre eigene, perfekte Struktur!

Viele große Projekte versuchen zudem, sehr feine Anforderungen zu verwalten, um Nachvollziehbarkeit zu erreichen. Dies ist jedoch eine ganz andere, längliche Geschichte...