Requirements Engineering Methoden

Als Business Analyst und Projektleiter verbringe ich viel Zeit in Meetings mit Kollegen, Anwendern, Managern und anderen Stakeholdern. Um so wichtiger ist es, diese Meetings effektiv zu gestalten.
Aber - wer kennt das nicht? Teilnehmer sind unvorbereitet, andere diskutieren über uninteressante Dinge, das Meeting hat kein Ergebnis und ein neues Meeting zu demselben Thema muss anberaumt werden?
Folgende Regeln für effektive Meetings haben sich sehr bewährt:

• Ziel formulieren
  Ein festgelegtes Ziel hilft den Teilnehmern, sich zu fokussieren und hilft dem Moderator, das Meeting zielgerichtet zu halten.
• Agenda verteilen
  Eine vorab verteilte Agenda, ggf. mit Zeitangaben, hilft ebenfalls, die Diskussion effektiv zu halten. Als Moderator zwingt mich das Formulieren der Agenda, mir Gedanken über den effektiven Ablauf des Meetings zu machen.
• Vorbereitung
  Eine gute Vorbereitung durch den Moderator mag selbstverständlich sein. Vorher an die Teilnehmer verteilte Aufgaben helfen, das Meeting frei von Vorträgen zu halten und sich auf die Entscheidungen zu konzentrieren.
• Ergebnisse
  Die Ergebnisse werden im Meeting zusammengefasst und ggf. per Protokoll verteilt. Aufgaben für die Teilnehmer werden definiert und namentlich an einzelne Personen vergeben.

Marissa Meyer von Google hat strenge Regeln aufgestellt und wendet diese für jedes 5-Minuten-Meeting an.
Die Regel "Demonstrate Respect for People's Time" gibt wie ich finde ein gutes Selbstverständnis eines Moderators wieder. Scott Sehlhorst formuliert diese als eine der Regeln um Meetings 60% effektiver zu machen. Er gibt außerdem Verhaltenstipps, wenn sich z. B. Teilnehmer nicht vorbereiten.

In die gleiche Richtung gehen die Top 7 Strategien für produktive Meetings von Kevin Kearns.
Für Meetings, die ich selbst veranstalte, wende ich diese Regeln konsequent an - und bin im Allgemeinen zufrieden mit der Meeting-Effizienz... Schwieriger ist es natürlich in Meetings als Teilnehmer. Hier hilft es, vorher ein Ziel und eine Agenda zu fordern. Ich frage meist auch, wie ich mich vorbereiten kann. Gelingen Meetings dennoch nicht nach meiner Zufriedenheit, hilft Feedback, ggf. mit Hinweis auf die Artikel oben...

Projektkontext
In einem E-Learning-Projekt sollte ein Konzept für die Anforderung "Kopierschutz" erarbeitet werden. Das E-Learning sollte lt. Lastenheft einen "Kopierschutz" enthalten.
Für das Konzept musste zunächst die Anforderung geklärt werden (eine berühmte nicht-funktionale Anforderung, wie man sie oft findet). Viele Ansprechpartner mussten einbezogen werden, was Richtlinien für Verschlüsselung beim Unternehmen unseres Kunden sowie in den verschiedenen Ländern betraf (China, Frankreich).
Aus den zur Verfügung stehenden Alternativen konnten mit wachsender Erkenntnis die beste ausgewählt werden.

Lösung
Um die wachsenden Informationen zum Thema "Sicherheit" im Verlauf des Prozesses nicht zu vergessen, erstellte ich ein Konzept-Dokument, in dem alle Informationen von der Lastenheft-Anforderung bis zu den Begründungen für die Verwendung einer Alternative dokumentiert waren. Es enthielt die Anforderungen aller Ebenen (bis zu Umsetzungsdetails) zum Thema "Sicherheit".
Das entstehende Konzept-Dokument schrieb ich während der Erarbeitung fort und dokumentierte den jeweils aktuellen Wissensstand. Verworfene Alternativen kopierte ich mit Begründung in den Anhang.
Das Dokument diente zu jedem Zeitpunkt als Kommunikationsgrundlage mit den Stakeholdern (jeweils relevante Auszüge) sowie als Dokumentation der Entscheidungskriterien gegenüber unserem Kunden sowie der internen Entwicklung.
Nach dem Projekt diente das Konzept-Dokument in weiteren Projekten als Vorlage um das jeweilige Sicherheitskonzept zu erarbeiten. Das Dokument war sehr gut wiederverwendbar, da nicht nur das Konzept sondern der Weg dorthin dokumentiert war.

Aufbau
Das Dokument enthielt die folgenden Informationen:

• Lastenheft-Anforderung sowie Aussagen des Kunden
• Tiefer analysierte Anforderung: Was ist der Gegenstand des Schutzes und was ist sein Wert? Welche Gefahren-Szenarien gibt es? Welche (messbaren) Anforderungen an die Sicherheit ergeben sich daraus?
• Konzept mit verschiedenen Alternativen zu Algorithmus, Schlüsselhinterlegung und Zeitpunkt der Entschlüsselung
• Constraints durch die weltweite Verteilung (z. B. Roll-Out in Frankreich und China) und mögliche Umsetzungsvarianten

Nach und nach konkretisierten sich die Randbedingungen durch Gesprächen mit Stakeholdern, wodurch sich die Zahl der möglichen Alternativen reduzierten. Die verworfenen Alternativen verschob ich in den Anhang und dokumentierte den Grund.

Projektkontext
Ein bestehendes Portal zur Auslieferung von Dokumenten an Kunden sollte abgelöst werden. Im Vordergrund stand dabei eine vereinfachte Wartung und Pflege der Dokumente je Kunde. Das neue Portal sollte die spezifischen Eigenschaften des Kundenkreises berücksichtigen und so den Pflegeaufwand reduzieren, um identische Dokumente an verschiedene Kunden zu verteilen, die bisher für jeden Kunden separat eingestellt werden mussten. Die neue Lösung sollte diesen Schritt automatisieren.
Ein wichtiger Aspekt des Konzept war also, die Arbeitsweise effizienter zu gestalten.
Da ich zum Zeitpunkt der Konzeption erst kurz bei der GfK war, war es für mich außerdem wichtig, die Arbeitsweise der Kollegen kennen zu lernen.
Eine Herausforderung war, die Ausnahmen vollständig zu erfassen und Möglichkeiten zu deren Behandlung zur Verfügung zu stellen.

Lösung
Im Konzept fokussierte ich zunächst auf den Workflow um die zukünftige effiziente Arbeitsweise zu definieren. Sonderfälle und Ausnahmen konnten im Workflow dargestellt werden.
Zur Dokumentation nutzte ich klassische Use-Cases mit Diagramm zur Übersicht und Beschreibung für die Details des Workflows. Mithilfe der Beschreibung konnte ich den Workflow mit den Anwendern durchsprechen und Sonderfälle identifizieren sowie die Vereinfachung der Arbeitsweise deutlich machen. Unterstützend nutzte ich einfache Objektdiagramme (kein UML, sondern Powerpoint ;-)

Beispiele
Das Use-Case-Diagramm zeigt einen Überblick über die geplanten Erweiterungen. Die Use-Cases beschreiben die Workflows.


Häufig habe ich Use-Cases auf der Ebene einer Systemspezifikation eingesetzt.

Projektkontext
Für einen Kunden sollten wir eine Datenbank für medizinische Bilder erstellen, die Anwendern ermöglichen sollte, möglichst einfach das richtige Bild zu finden. Einfachheit und Geschwindigkeit der Intranet-Applikation standen für die Anwender im Vordergrund. Andere Mitarbeiter, die Editoren, bereiteten die Bilder auf und qualifizierten sie.
Unser Kunde liebte die UML. Bereits das Lastenheft enthielt Aktivitätsdiagramme. Diese Chance wollten wir nutzen und UML auch in der Zusammenarbeit mit dem Kunden einzusetzen.

Lösung
Zu Projektbeginn entschied ich mich dafür, Zustandsdiagramme zur Konzeption zu nutzen, da sie erlauben, das Verhalten aus Sicht des Systems zu spezifizieren. Wir nutzten die Diagramme zur funktionalen Spezifikation des Systems.
Ich erinnere mich gerne an die äußerst effektiven Workshops, in denen ich mit dem Kunden gemeinsam Zustandsmodelle entwickelte. Wir sprachen dieselbe Sprache – UML.
Es war einfach, Ausnahmen und Fehlerfälle zu erkennen und so die Vollständigkeit herzustellen. Das Ergebnis war eine sehr präzise Dokumentation des Systemverhaltens. Wichtig war dabei, dass die Diagramme immer durch Text ergänzt werden mussten. Ich nutzte die Möglichkeiten der UML, Informationen in den Diagrammen unterzubringen. Dennoch gab es Anforderungen, die nur textuell dokumentiert werden konnten, z. B. welche Informationen in einer Liste angezeigt werden sollten.
Wichtige Erfahrungen waren, dass das ganze Team geschult werden muss, um alle Feinheiten der Diagramme erkennen und nutzen zu können. Eine Voraussetzung für den konsequenten Einsatz von UML war, dass der Kunde diese Sprache sprach.

Beispiele
Zustände definierten einen logischen Schritt für den Anwender. Ein Zustand wurde dabei typischer Weise zu einem Screen der Applikation, in dem bestimmte Funktionen zur Verfügung standen, die als Transitionen am Zustand notiert waren.

Das Beispiel zeigt die Funktionalität beim Ansehen eines Bildes.
Wir setzten Zustandsdiagramme natürlich auch zur Beschreibung von Objektzuständen ein.

Projektkontext
In der Konzeption einer Intranet-Applikation zum Knowledge-Management zur Projektmanagement-Unterstützung setzten wir Use-Cases ein. Darin spezifizierten wir textuell und ablauforientiert die Funktionalität des Tools und wie die Interessen der Benutzer gewahrt wurden. Wir mischten klassische Dokumenten-Management-Ansätze mit Web 2.0 Ideen um die Anwender im Sinne des Unternehmens möglichst gut zu unterstützen.
Die Use-Cases wollten wir anschließend mit der Projektleiterin auf Kundenseite durchsprechen. Die lehnte jedoch das formelle Schema der Use-Cases ab – wir hatten ein eine tabellarische Darstellung gewählt, wie z. B. von Alistair Cockburn beschrieben. Sobald sie dieses formale Schema sah, stoppte sie das Review ohne den Text zu lesen...

Lösung
Um das Konzept mit der Projektleiterin besprechen zu können, mussten wir eine andere Darstellungsform finden. Wir entschieden uns für Wireframes, eine abstrahierte Darstellung der Oberflächen, auf denen das Konzept in einer sehr konkreten Form dargestellt ist. Den Text der Use-Cases formulierten wir ohne Tabelle und weniger formal und kombinierten ihn mit den Wireframes.
Anhand der Wireframes war es einfach, mit der Projektleiterin die Anwendungsfälle durchzusprechen und das Konzept zu reviewen. Die Projektleiterin konnte die zukünftige Arbeitsweise anhand des Papier-Prototyps der Anwender leicht nachvollziehen und ihre Erfahrung aus dem Geschäfts-Alltag einbringen.

Beispiele
Im ersten Beispiel ist ein Wireframe dargestellt, mit Notizen über das funktionale Verhalten der Oberfläche.
Das zweite Beispiel zeigt das Zusammenspiel mehrerer Screens in einer Applikation in einem Flow-Chart. Hinter jedem der Boxen im Flow-Chart steht ein Wireframe. Mithilfe des Flow-Charts lässt sich der Weg des Anwenders durch die Applikation nachvollziehen und optimieren.

Vor einiger Zeit hatte ich das Vergnügen, für ein Seminar der Universität Erlangen einen Vortrag über RE-Methoden im Projektkontext zu halten. Ich habe einige der Methoden vorgestellt, die ich (beinahe) täglich in meinen Projekten einsetze und die Gründe für den Einsatz der Methoden in bestimmten Projekten beschrieben.
In den folgenden Artikeln veröffentliche ich die Berichte über die einzelnen Methoden.

Scott Sehlhorst hat auf Tyner Blain eine interessante Methode "Estimating With Use Case Points (alternativer Artikel bei methodsandtools.com) vorgestellt, um den Aufwand für ein Software-Projekt vorherzusagen. Entwickelt wurde die Methode von Gustav Karner bei Rational Software Corporation Mitte der neunziger Jahre.

1. Technische Faktoren
Im ersten Schritt werden nicht-funktionale Anforderungen bewertet. Z. B. bewirken die Faktoren verteiltes System, hohe Usability-Anforderungen, einfache Installation oder kritische Antwortzeiten einen erhöhten Aufwand.

2. Umgebungs-Faktoren
Anschließend wird in der Methode die Umgebung betrachtet, in der das Projekt abläuft. Z. B. die Erfahrung des Projektteams, die Motivation und Anforderungs-Stabilität.

3. Use-Cases
Der dritte Schritt ist die Bewertung der Komplexität der Use-Cases. Komplexere Use-Cases sind aufwendiger umzusetzen.

4. Aktoren
Zuletzt werden die Anwender des Systems bewertet. Einfache Aktoren sind Nachbarsysteme, die das System über eine definierte API ansprechen. Komplexe Aktoren sind Anwender, die das System über eine flexible (z. B. AJAX) Oberfläche nutzen.

Für die Projekte bei Spirit Link ist die Aufwandsschätzung eine ständige Herausforderung, da wir Festpreisprojekte anbieten. Schätzen wir zu niedrig, müssen wir draufzahlen, schätzen wir zu hoch, bekommen wir das Projekt nicht. Wir haben hier eigene Methoden entwickelt, um in kurzer Zeit eine relativ genaue Schätzung zu bekommen.

An Karners Methode gefällt mir gut, dass nicht-funktionale Anforderungen und "weiche" Projektfaktoren eine explizite Rolle spielen.
Im Prinzip werden bestimmte Faktoren bewertet und gewichtet, und aus dem Ergebnis der Aufwand abgeleitet. Interessant sind die Faktoren, die in der Methode einbezogen werden.
Bei der Lektüre der Artikel habe ich keine Überraschungen erlebt. Bei jedem der Faktoren ist es einleuchtend, dass er Einfluss auf den Aufwand des Projekts hat. Selten habe ich aber eine so kompakte und knackige Zusammenfassung gesehen.

Um ein Projekt planen zu können, müssen die Faktoren mit Einfluss auf den Entwicklungsaufwand bekannt sein. Als Business Analyst ist es also meine Aufgabe, die Faktoren möglichst früh in einem Projekt in Erfahrung zu bringen. Dafür ist natürlich eine Art "Checkliste" interessant, um keinen der Faktoren zu vergessen. Genau diese Liste liefert die Methode.
Um meinen Teil der Aufwände in einem Projekt zu schätzen, also die Analyse und Spezifikation, sind diese Faktoren ebenso relevant.

Seit einiger Zeit beschäftige ich mich gedanklich damit wie wir in unseren Projekten durch eine inkrementell/iterativen Vorgehensweise profitieren können.
Methodisch sind wir bei Spirit Link soweit, den nächsten Schritt im Vorgehensmodell zu gehen. Jetzt müssen die inkrementell/iterativen Prinzipien noch auf die Eigenschaften der Projekte bei Spirit Link angepasst werden. Vorteile finden sich genügend.

Wir spezifizieren Use-Cases, die sich grundsätzlich sehr gut eignen, auf Inkremente zu verteilen. Ausgehend von einer Grobanalyse können wir die ersten Inkremente planen. Unsere Zusammenarbeit mit Kunden ist typischerweise eng und partnerschaftlich. Gute Voraussetzungen eigentlich, um inkrementell/iterativ zu entwickeln.
Wir müssen die Use-Cases "nur" noch nach ihrem Wert für den Kunden sowie nach ihrem Risiko bewerten - fertig ist die Iterationsplanung (naja, so ungefähr :).

Vorteile für unsere Kunden:
- hohe Sicherheit, dass das Richtige entwickelt wird
- Einflussmöglichkeiten vor dem Rollout
- früher ROI, wie z. B. Scott Sehlhorst argumentiert

Vorteile für uns:
- Projektrisiken können früh im Projekt erkannt werden
- Höhere Effizienz durch kürzeren Abstand von Konzeption und Umsetzung
- Hohe Lernkurve innerhalb eines Projekts, nicht erst für das nächste Projekt

Dennoch bleiben einige Fragen offen:
- Können Konzept und Umsetzung in dieselben Inkremente geschnitten werden? Oder muss ich doch alles konzipieren, bevor die (iterative) Umsetzung starten kann?
- Spielt der Kunde mit? Wie verkaufen wir es dem Kunden?
- Was mache ich mit den Änderungswünschen, die der Kunde nach der ersten Iteration hat? Die Reviewzyklen und daraus folgenden Änderungen machen es ja teurer!
- Welche weiteren "agilen" Methoden müssen wir nutzen, damit inkrementell/iterativ funktioniert?

Hier noch ein paar Links zum Thema (ohne gründliche Recherche):
Scott Sehlhorst über Timeboxes
Craig Larmans Artikel über UP (Unified Process) aus seinem Buch "Applying UML and Patterns" und über "Iterative & Evolutionary" aus "Agile and Iterative Development - A Manager's Guide"

Im Podcast Interview von Christian Höcht beleuchtet Dr. Gernot Starke die Aufgaben und das Zusammenspiel von Projektleiter, Software-Architekt und Analytiker.
Ich finde das Interview hörenswert, weil Gernot Starke einige wichtige Aspekte der Projektarbeit in klaren Worten beschreibt. Außerdem der trockene Humor von Gernot Starke und die unkonventionellen Fragen von Christian Höcht.

Highlights:

• Der Projektleiter ist ein Katalysator für Kommunikation im Projekt. Er ist dafür verantwortlich, dass die richtigen Leute miteinander kommunizieren.
• Der Analytiker beantwortet nur einen Teil der Fragen. Der technische Projektleiter ist dafür verantwortlich, dass die Detailfragen der Umsetzung geklärt werden.
• Der technische Projektleiter kennt und betreut alle Projektbeteiligten persönlich.
• Der technische Projektleiter trifft Lösungsentscheidungen. Diese betreffen teilweise die Oberfläche / Usability.
• Heute ist es Standard, dass Anforderungen notwendig sind.

Klassische textuelle Spezifikationen sind für viele Stakeholder nicht gut verständlich. Sie tun sich schwer, sie in ihre Problemstellung zu übersetzen.
Ein Papierprototyp mit Wireframes zeigt, wie die spätere Anwendung aussehen wird. Insbesondere für Kunden und Anwender bieten sie die Möglichkeit, die Anwendung durchzuspielen und ermöglichen ihnen, das Konzept zu prüfen.

In unseren Projekten setzten wir die Wireframes ursprünglich lediglich als Präzisierung einer vorhandenen funktionalen Spezifikation sowie zur Usability-Konzeption ein.
Inzwischen nutzen wir Wireframes in der frühen Konzeptionsphase um das Konzept von Stakeholdern prüfen zu lassen. Use-Cases werden durch Abfolgen von Wireframes beschrieben. Der Konzepter spielt Anwendungsfälle mit den Stakeholdern durch und beschreibt das Verhalten der Anwendung.
Die Wireframes können dabei so weit gehen, das nicht sichtbare Verhalten in Notizen zu dokumentieren und können so sogar die funktionale Spezifikation umfassen.

Ich nutze gerne textuell beschriebene Use-Case-Szenarien als strukturiertes Vorgehen, um ein Konzept zu entwerfen. Zur Kommunikation mit Kunden und Anwendern verwende ich dennoch fast ausschließlich die Wireframes. In einem Workshop lese ich Use-Cases und zeige dem Kunden die Wireframes.

Warum sind Use-Case-Szenarien so schwer verständlich? Sie beschreiben einen typischen Ablauf eines Anwenders in seiner Sprache. Von allen textuellen Spezifikationen finde ich Use-Cases am leichtesten verständlich (siehe Artikel).
Trotzdem tun sich Stakeholder schwer! Weil die Use-Cases eine Abstraktion beschreiben, die für Stakeholder ungewohnt ist.
In unseren typischen Projekten sind Stakeholder schließlich keine erfahrenen Software-Ingenieure, sondern Anwender. Marketing-Leiter, Geschäftsprozess-Experten oder Projektleiter, die nur selten RE-Hintergrund besitzen.
Wirklich vorstellen können sich Anwender eine Applikation nur anhand eines Prototypen. Wireframes sind nah genug an der Anwendung, um als (Papier-)Prototyp den Anwendern zu vermitteln, wie die Anwendung funktioniert. Sie können dann ihren Arbeitsablauf mit der neuen Anwendung verbildlichen und Stolpersteine und Erleichterungen erkennen.

Wireframes können in unterschiedlichen Abstraktionstiefen erstellt werden (siehe Abstraktionsebenen). Ich erstelle bereits in einer Grobkonzeption Wireframes, die einen Ablauf verdeutlichen. Mit den richtigen Werkzeugen geht das sehr schnell und ich bekomme sehr schnelles Feedback von den Stakeholdern.