Komplexe Anforderungen – endlose Diskussionen?

Sind Sie bei der Beschreibung Ihrer Projekt-Anforderungen in Word gerade auf der neunten Überschriften-Ebene angekommen – und fragen sich, wie das der Fachbereich jemals verstehen soll?

Hatten Sie eigentlich mal vor, dicht und möglichst agil mit den Kollegen aus der Fachabteilung zusammenzuarbeiten, um die elendigen Papierwüsten von Fachfeinspezifikationen hinter sich zu lassen?

Aber dann ist es passiert! Irgendwie wurde es immer komplexer: die Fachabteilung steigt so richtig thematisch ein und zieht immer weitere Bedingungen und Abhängigkeiten aus dem Hut. Sie schreiben und schreiben: Use Cases und Objektmodell, Geschäftsregeln und nicht-funktionale Anforderungen. Liest das eigentlich noch jemand? Irgendwie haben Sie nicht das Gefühl und müssen sich zurückhalten, auf Seite 49 mal reinzusetzen: „Wer das hier liest, bekommt vom Autor einen riesen Schoko-Eisbecher spendiert!“

Aber was hilft’s? Anforderungen müssen dokumentiert und überprüft werden – sonst versenken Sie schnell mal 100 Tage Aufwand. Dummerweise nimmt das Projekt Fahrt auf, die Hektik zu und die verfügbare Zeit ab.

Versuchen Sie es mal mit Visualisierung und Grafiken! Nicht komplexe, „feature-complete“ UML-Modelle, sondern auf einfache, greifbare Zeichnungen: Masken. Viele Benutzer können sich ganz gut vorstellen, wie Masken funktionieren – sie kennen das aus dem alten System, aus ihrem Alltag. Für sie sind Masken „greifbar“, und sie können sich einbringen: man kommt dabei von „Höcksken auf Stöcksken“ wie man in Westfalen sagt. 

Fangen Sie mit der Struktur an – entwickeln Sie schrittweise die Navigationsstruktur – von welcher Maske komme ich zu welcher Maske – und dann die Inhalte der spannendsten Masken. Wenn Sie PowerPoint-Künstler sind, können Sie sogar die Kästchen in der Struktur mit den Maskenansichten verlinken...

Bekommen Sie damit die Komplexität in den Griff? Ja – wenn Sie nicht nur die Abläufe schrittweise entwickeln, sondern sich auch zunächst auf bestimmte Aspekte beschränken. Wenn die Suchmaske Variationen für verschiedene Berechtigungen haben muss – fangen Sie erst mal mit dem einfachsten Fall an und skizzieren sie einen Durchlauf von vorne bis hinten. Wenn der passt, dann können Sie auch Variationen und Verästelungen einbauen!

Und schon haben Sie übrigens ein agiles Vorgehen, wenn Sie die ersten Ergebnisse gleich mal bauen lassen. Muss nicht perfekt sein, aber Sie glauben nicht, was Sie mit echten Masken noch mal über die Randbedingungen Ihres Systems lernen werden...

Ein Wort noch zu den Werkzeugen: es geht mit PowerPoint. Ja. Tools wie Balsamiq oder WireFrameSketcher können das viel schneller und einfacher. Aber manchmal hat man halt nur Office.

Übrigens sollte man auch stets aufpassen, dass die Masken-„Skribbles“ nicht zu perfekt sind – Benutzer erwarten dann gerne, dass die Maske genau so aussieht. Aber das bringen Sie Ihrem Fachbereich in vielen, intensiven Sprints nach und nach bei...

Projekt-Scoping

Ihr Chef hat Ihnen das Projekt übergeben mit den Worten: „Das schaffen Sie schon!“. Nach dem Durchsehen der Unterlagen haben Sie sogar Zeit gehabt, mit dem Projektteam zu sprechen – nur... irgendwie taucht aus dem Nebel keine strahlende Erkenntnis auf?

Vielleicht befolgen Sie sogar den Rat aus einem der letzten Blog-Posts und orientieren sich an den neun Bereichen: dabei fällt Ihnen dann auf, dass insbesondere der Umfang (Scope) und die Kosten nicht klar sind. Was nun?

Kennen Sie den alten Witz mit dem Bildhauer, der von einem begeisterten Kunstfreund gefragt wird, wie er denn so wundervolle Madonnen aus dem Stein herausarbeitet? „Ach, ich meißel’ halt alles weg, was nicht nach Madonna aussieht!“. So einfach ist es zwar nicht – der Ansatz ist aber ähnlich: ich empfehle Ihnen, ein „Scoping“ durchzuführen, also die wesentlichen Inhalte, Kosten und Dauer aus dem Nebel ans Licht zu zerren. 

Für Software-Projekte erstellen Sie iterativ folgende Artefakte:

Business Case

Lohnt sich das Endprodukt? Zumindest sollte jemand identifizieren können, was der Nutzen ist, wenn auch nicht immer in EUR.

Welche Annahmen liegen dem Szenario zu Grunde? Wenn Sie dies wissen, können Sie viel effektivere Entscheidungen treffen!

Beispiel: Sie erstellen eine Verwaltungssoftware, die nicht am Markt als Standardsoftware verfügbar ist. Mitten im Projekt stellen Sie fest, dass ein Softwarehaus mit drei Buchstaben kurz vor der Fertigstellung einer Standardsoftware steht. Was nun? Ist Ihre Lösung noch viel billiger als die neue? Welche Vorteile hat Ihre Lösung, die im Standard nicht zu finden sind? Müssen Sie sich vielleicht noch stärker auf die individuellen Features fokussieren?

Übersicht Geschäftsprozesse

In vielen großen Unternehmen werden von Organisations- oder Optimierungs- oder Prozess-Abteilungen Geschäftsprozesse erfasst, verwaltet und auf fachlicher Ebene analysiert. Dabei reicht die Bandbreite von „Bilder malen“ bis hin zu ausgewachsener BPMN-Modellierung mit direkter Verwendung in Workflow-Engines. Mein Eindruck: es wird häufiger gemalt als modelliert. Das liegt wohl auch daran, dass Fachabteilungen in fachlichen Zusammenhängen denken – nicht in Algorithmen. Sonst würden die Mitarbeiter ja auch schnell in der IT-Abteilung landen...

Gut nutzen kann man Prozess-Landkarten, Bebauungspläne usw. Gibt es bei Ihnen nicht? 

• Tragen Sie horizontal die groben wertschöpfenden Prozessbereiche auf, z.B. Marketing, Akquise / Vertrieb, Abschluss, Leistung / Bestandsverwaltung / Pflege, Austritt / Storno / Beendigung (je nach Branche halt unterschiedlich). 
• Platz für sekundäre Prozessbereiche wie Buchhaltung, Personalwesen etc. ist dann schon meist nicht mehr – die passen auch zur Not auf ein weiteres Blatt. 
• Unter jeden Prozessbereich können Sie die Systeme packen, die daran beteiligt sind.  Oder, um auf die Geschäftsprozesse zu kommen, die feineren Schritte wie „Angebot erstellen“, „Vertrag abschließen“, „Leistungsanspruch prüfen“. Das Blatt füllt sich in der Regel schnell...
• Hilfreich ist oft, die wesentlichen Prozessbeteiligten (als Rollen) in der Senkrechten zu notieren, in der ersten Spalte: dann können Sie die Prozesse schnell den Beteiligten zuordnen.

Tipp: elektronisch (PowerPoint, Visio, Zeichentools) geht das letztlich schneller als auf Papier.

Auf dieser Ebene müssen Sie vor allem herausfinden, an welchen Prozessen Ihr neues System beteiligt sein wird!

Use Case Übersicht

Die konkrete Beteiligung des Systems an den Prozessen betrachten wir dann als „Use Cases“ oder „Anwendungsfälle“. Die Grundidee ist sehr einfach: wer macht was mit dem System? Zunächst mal trägt man alle Akteure und Top-Level Use Cases in einem Diagramm zusammen. Auch wesentliche, fremde Systeme wie die Buchhaltung oder das Dokumentenarchiv sollten hier als Akteure auftauchen.

Diese Top-Level Use Cases bilden die oberste Ebene Ihrer funktionalen Gliederung. Verfeinern Sie diese Ebene durch Use Cases, für die Sie grob erfassen, was gemeint ist: „Einloggen: Benutzer kann sich einloggen mit Möglichkeit zum Password Reset“.

Meist kann man die Verfeinerungen in die Übersicht einbauen: mit einem UML-Tool können Sie z.B. farbige Bereiche einrichten, um das Lesen zu erleichtern. 

Geplante Komponenten

Was müssen Sie eigentlich programmieren, so im Groben? Anfangs fällt dies vielen Beteiligten schwer, weil sie geistig von „Anforderung“ auf „Lösung“ umschalten müssen.

Tipp: Beginnen Sie „außen“: wo sind die „Schnittstellen“ des Systems? Arbeiten Sie sich dann nach „innen“ vor:

• GUI und menschliche Interaktion: Hier finden Sie schnell GUI-Komponenten und meist auch gleich die darunter liegenden Logik-Komponenten.
• Schnittstellen von und zu anderen Systemen: Wie funktionieren die? Zum Einlesen von Dateien brauchen Sie beispielsweise mindestens eine Importkomponente – welche Komponente jedoch führt die fachliche Logik aus?

Aus diesen Überlegungen bestimmen Sie ziemlich schnell Aussagen zu Abhängigkeiten, Umfang und Kosten:

• Erstellen Sie eine Matrix aus Use Cases und Komponenten: im Kreuzungspunkt eine „1“, falls die Komponente im Use Case verwendet wird, sonst eine „0“.
• Denken Sie sehr intensiv nach über Komponenten, die keine oder wenige Einsen haben...
• Lassen Sie erfahrene Architekten oder Entwickler die Komponenten schätzen – in Projekttagen.
• Parallel dazu können Sie durch Komplexitätsfaktoren versuchen, den Aufwand für die Use Cases zu schätzen und mit Aufwandsklassen zu multiplizieren:

Einfach: 2 PT
Mittel: 5 PT
Komplex: 10 PT

• Der Trick: die Trennung von Klassifikation und Zahlen führt zu besseren Schätzungen!
• Zu guter Letzt vergleichen Sie die Schätzungen für Use Cases und Komponenten – und finden Sie heraus, warum es an welcher Stelle Unterschiede gibt.

Der Plan

Wenn Sie die ersten Hürden überwunden haben, müssen Sie natürlich eine Vorstellung über den Ablauf gewinnen – welche Komponenten / Use Cases etc. bauen Sie zuerst?

Wenn Sie agil planen, brauchen Sie nicht alles herunter zu brechen und zu verfeinern! Nur die wichtigen Teile – wenn Sie herausgefunden haben, welche das sind...

Anforderungen formulieren - Best practices

Eigentlich ist es nicht schwierig, die grundlegenden syntaktischen und grammatikalischen Bedingungen anzuwenden:

Formulierungen im Aktiv
Auch wenn es nicht nach superkorrektem Formaldeutsch klingt:

• Richtig: „Der Benutzer markiert die freizugebenden Einträge und bestätigt die Freigabe“ 
• Behördendeutsch: „Durch die Markierung und anschließende Bestätigung initiiert der Benutzer die Freigabe“

Ungenauigkeiten vermeiden
Vermeiden von Abschwächungen und ungenauen Quantifizierungen, zur Abschreckung:

• „Das neue System muss alles können, was das alte System auch konnte“
• „Das System verschickt die Reports in der Regel täglich“
• „Grundsätzlich zeigt das System dem Benutzer nur aussagekräftige Fehlermeldungen“

Einfache, klare Sätze

• Richtig: „Das System zeigt... Der Benutzer gibt ein...“
• Falsch: "Nachdem das System die Liste anzeigt, gibt der Benutzer einen Suchbegriff zur Verfeinerung ein" 

Hier empfiehlt sich der Translator-Test: wenn es so einfach ist, dass man es z.B. mit Google Translate vom Deutschen ins Englische übersetzen kann, ohne dass es zu peinlich wird, dann ist es einfach genug! Abgesehen davon, dass Sie vielleicht nicht jedem Übersetzungsdienst sagen möchten, womit Sie sich gerade beschäftigen...


Priorität und Verbindlichkeit

Pro Anforderung festlegen:

• Richtig: Soll, Muss, Kann
• Falsch: „Das System sollte das jeweils aktuelle Datum auf jede Seite des Reports ausgeben“ - die Klassifizierung kann sich schneller ändern, als Sie die Grammatik anpassen können!

Soweit – so einfach. Im Prinzip.

In der Praxis muss man meist Fachleuten mit tiefem Fachwissen solche einfachen Regeln immer und immer wieder nahebringen, oft verwechseln gerade ungeübte Anwender epische Romantexte mit nützlichem Informationsgehalt.
Und: interessante Nebensatzkonstruktionen sollte man Herrn Kafka und Kollegen überlassen.

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...