„Nach der Analyse der Anforderungen sollten alle notwendigen und vom Auftraggeber geforderten Funktionen erhoben, dokumentiert und verifiziert sein.“
Dabei ist es nicht nur notwendig die Anforderungen zu kennen, sondern diese auch zu dokumentieren. Nach der klassischen Vorgehensmethode wird dabei meist ein Pflichtenheft erstellt. Dieses Pflichtenheft umfasst im Regelfall alle notwendigen Anforderungen an das zu entwickelnde System. Es ist gut strukturiert und dient am Ende des Entwicklungsprozesses als Basis für die Abnehme des fertigen Produktes. Soweit die Theorie. Hoch komplexe Softwaresysteme – in einer dynamischen Umwelt – machen es insbesondere für den Auftraggeber zu Beginn eines Entwicklungsvorhabens sehr schwer (wenn nicht sogar unmöglich) alle Anforderungen zu kennen, geschweige diese auch formulieren zu können. Oftmals besteht nur eine vage Vorstellung, wie die künftige Software aussehen soll und welche konkreten Funktionen zu integrieren sind. Ein besseres Wissen herrscht über das zu lösende Problem vor, der Lösungsweg, in Form einer zu entwickelnden Anwendung, bleibt jedoch zunächst im Nebel. Die Entwicklungsmethoden haben sich jedoch dieser Tatsache angenommen und mit einer entsprechenden Flexibilisierung reagiert. Gemeint ist der Einsatz von agilen Methoden. Ein derzeitig sehr häufig diskutierter und in der Praxis verwendeter Ansatz ist Scrum. Als wesentliches Merkmal der Entwicklung auf der Basis einer agilen Methode ist, dass zu Beginn des Projektes noch keine Notwendigkeit besteht, alle Anforderungen an das System bis in das „letzte“ Detail zu kennen. Vielmehr sollen sich diese während der laufenden Programmentwicklung sukzessive herauskristallisieren. An dieser Stelle stellt sich die Frage, welchen Einfluss diese Veränderung der Vorgehensweise auf die Durchführung der Anforderungsanalyse hat? Ist jetzt beispielsweise eine Dokumentation hinfällig? Wird noch ein Pflichtenheft erstellt? Auf diese Fragen versuchen wir Antworten in diesem Artikel zu finden.
Vorgehensmodelle im Überblick
Prozessmodelle beschreiben die Vorgehensweise, d.h. es wird festgelegt, wann welche Entwicklungsphasen und mit welchen Ergebnissen durchgeführt werden. Sie bestimmen damit den organisatorischen Rahmen für ein Softwareentwicklungsmodell. Vorgestellt wird als erstes das evolutionäre Modell, welches sich aus dem klassischen Wasserfallmodell entwickelt hat. Das evolutionäre Modell stellte lange Zeit den Stand der Dinge dar. Es wurde durch agile Methoden (teilweise) abgelöst, hat aber heute auch noch seine Berechtigung. Das V-Modell findet häufig Verwendung bei der Auftragsentwicklung im öffentlichen Sektor, auch dieses wird kurz vorgestellt. Weitere in der Praxis angewendete Prozessmodelle basieren im Wesentlichen auf den beschriebenen Grundprinzipien, so dass guten Gewissens auf die entsprechende Fachliteratur verwiesen wird.
Evolutionärer Ansatz
Das Grundprinzip des evolutionären Prozessmodells ist einfach: Statt zu versuchen, die Anwendung in einem „Rutsch“ (Wasserfallmodell) zu erstellen, wird ein schrittweises Vorgehen gewählt. Es werden verschiedene Versionen der Anwendung entwickelt. Diese Arbeitsweise erstreckt sich über alle Entwicklungsphasen. Neue Programmfunktionen, aber auch Korrekturen oder Änderungen werden in die jeweilige Folgeversion übernommen. Fehler in der Entwicklung können so frühzeitig erkannt und beseitigt werden. Gelegentlich entstehen Änderungswünsche beim Auftraggeber auch erst dann, wenn eine konkrete Programmversion vorliegt („das habe ich mir anders vorgestellt…“). Es ist festzulegen, welche Programmversionen an den Kunden ausgeliefert und welche nur für interne Zwecke angefertigt werden. Somit ist es ebenfalls möglich, die Software stets aktuellen Gegebenheiten anzupassen (Updates). Die Wartezeit bis zur ersten lauffähigen Anwendung (wenn auch ggf. zunächst nur mit einer Teilfunktionalität) verkürzt sich. Für einzelne Produktversionen ist es denkbar, Meilensteine im Rahmen der Projektplanung zu definieren. Eine weitere Besonderheit: Eine explizite Wartungsphase entfällt, da die Aktivitäten dieser Phase ebenfalls im Rahmen einer neuen Programmversion abgewickelt werden (Abbildung 1).
V-Modell
Das V-Modell ist ein Vorgehensmodell zum Entwickeln von IT-Systemen. Es umfasst die Punkte Projektmanagement, Qualitätssicherung, Ausschreibung, Vergabe und Systementwicklung. Dieses Modell kommt meist bei der Vergabe durch öffentliche Auftraggeber zum Einsatz. Das Modell hat somit auch eine entsprechend hohe wirtschaftliche Bedeutung. Das V-Modell XT ist die Nachfolgeversion des V-Modells 97. Es ist ein wenig mit dem Wasserfallmodell vergleichbar Jedoch werden frühe mit späteren Entwicklungsphasen über Testdaten verbunden (V-förmig, siehe Abbildung 2). Das V-Modell XT ist organisationsneutral, flexibel und nach dem Baukastenprinzip strukturiert. Es wird durch Dokumentvorlagen wie beispielsweise Plan- oder Angebotsbausteine unterstützt. Die Nutzung unterliegt keiner Einschränkung und kann beliebig lizenzfrei angepasst werden. Das V-Modell XT unterstützt sowohl Projekte aus Sicht des Auftraggebers, als auch des Auftragnehmers. Das Modell geht davon aus, dass folgende Produkte während des Arbeitsprozesses erstellt werden: Projekthandbuch, Projektplan, QS-Handbuch und Produktbibliothek. Aus Sicht der Softwareentwicklung sind insbesondere sind folgenden Dokument von Interesse: Gesamtsystemspezifikation (Pflichtenheft), Systemspezifikation (Beschreibung der Schnittstellen und der funktionalen und nicht-funktionalen Anforderungen an einzelne Systemelemente), Systemarchitektur (Zerlegung des Systems in seine Bestandteile) und die Prüfspezifikationen. Eine sehr umfangreiche Dokumentation des V-Modells findet sich beispielsweise unter http://www.v-modell-xt.de/.
Scrum
Über agile Methoden im Allgemeinen und konkrete Ansätze im Speziellen werden und wurden bereits Bücher gefüllt. Dieser Beitragt beschränkt sich auf die Vorstellung von Scrum. Scrum ist ein Framework, das aus wenigen klaren Regeln besteht. Die Projektmitarbeiter müssen diese Regeln kennen und anwenden, damit das Projekt erfolgreich durchgeführt wird. Scrum kennt drei Rollen: Den Product Owner, das Team und den Scrum-Master:
- Der Product Owner repräsentiert in Scrum die Endkundenbedürfnisse. Im besten Fall ist er der Kunde selber oder ein vom Kunden bevollmächtigter Vertreter. Er trifft eigenständig und zügig qualifizierte Entscheidungen über das Produkt. Er steuert die Softwareentwicklung und arbeitet mit dem Team während des gesamten Projekts eng zusammen. Der Product Owner koordiniert die Kundenanforderungen und priorisiert sie im Product Backlog. Er definiert Anforderungen und deren Akzeptanzkriterien und nimmt die Arbeitsergebnisse des Teams ab.
- Das Team hat in Scrum die zentrale Rolle. Es führt alle Arbeiten aus, die zur Umsetzung der Anforderungen notwendig sind. Es ist von Vorteil, wenn die Mitglieder in einem Scrum-Team über ein breites Spektrum an Wissen verfügen. Dieses Wissen darf sich nicht in den Köpfen von Spezialisten konzentrieren, sondern muss gemeinsames Wissen des gesamten Teams sein oder werden. Die Team-Mitglieder bezeichnet man auch gerne als „generalistische Spezialisten“. Das Team organisiert sich selbst (empowered team), d.h. es entscheidet über eine Vielzahl von Dingen selbstverantwortlich. Hierdurch entsteht eine höhere Identifikation mit dem Projekt und das Verantwortungsgefühl steigt. Insbesondere schätzt das Team selbst die Aufwendungen für die einzelnen User Stories und es übernimmt die Verantwortung, dass diese richtig konzipiert sind. Ein wichtiger Punkt ist das „commitment“ im jeweiligen Sprint auf bestimmte User Stories; d.h. das Team entscheidet, welche und wie viele User-Stories es im nächsten Sprint umsetzen kann.
- Der Scrum-Master ist der Coach für das Team und hilft den Team-Mitgliedern Scrum richtig einzusetzen. Dies ist umso wichtiger, je weniger Erfahrung das Team selber mit Scrum hat. Der Scrum-Master hat im Projekt keine spezifischen Verantwortlichkeiten und Aufgaben, die unmittelbar mit der Umsetzung desselben zu tun haben. Wenn ein Scrum-Master seine Arbeit gut macht und das Team richtig zusammen arbeitet, wird er kaum noch benötigt. Das Team hilft sich in allen Situationen selbst.
Entscheidend für die praktische Umsetzung: Das richtige Verständnis des Ansatzes. Die alleinige Deklaration des Vorgehens als agile Methode – weil es gerade einem Hype ist – ist nicht ausreichend um zu einer erfolgreichen Anwendung zu gelangen. Eine wichtige Voraussetzung für ein effizientes Vorgehen ist das Anwenden der richtigen Tools. Es bedarf einiger Erfahrung, um ein gut funktionierendes System an Tools so miteinander zu verbinden, dass die geforderten Aufgaben bewältigt werden. Es haben sich einige Programme bewährt und sind so zusagen Standards des agilen Entwickelns geworden. Die Mitarbeiter sind zur Nutzung dieser Anwendungen anzuhalten. Die Akzeptanz bei den Entwicklern ist Voraussetzung, dass man entsprechende Vorteile daraus ziehen kann. Die Tools müssen verständlich, leicht integrierbar und von tatsächlichem Nutzen sein. Hat das Team bisher nach anderen Abläufen gearbeitet, so sind ein Umlernen und eine Umgewöhnung angesagt (Transformation zum agilen Denken). Es empfiehlt sich der Einsatz eines Coachs, mit entsprechender Projekterfahrung in agilen Methoden. Dieser kann das Team viel schneller zum agilen Denken bewegen und bei einem „Rückfall“ auch wieder auf Kurs bringen.
Ein Team kann nur funktionieren, wenn Probleme offen angesprochen werden. Probleme bei der Entwicklungsarbeit eines Mitgliedes sind als Hindernisse des gesamten Teams aufzufassen und sollen auch von diesem gelöst werden. Wichtig sind daher funktionierende Kommunikationsstrukturen. Ziel ist es, bei allen Mitgliedern im Team den gleichen Wissensstand zu erreichen und die Abhängigkeiten im Team von einzelnen Personen zu entkoppeln. Tatsächlich kann es einzelnen Mitarbeitern schwer fallen, ihr lang gehütetes „Spezialwissen“ preiszugeben.
Ein sehr wichtiger Punkt ist das Zurückblicken auf den vergangenen Sprint. Hier werden von allen Mitgliedern des Teams innerhalb eines Meetings die wichtigsten Fakten ausgewertet. Das Verbinden von Theorie und Praxis steht im Mittelpunkt. Die Theorie zur Durchführung einer solchen gemeinsamen Veranstaltung klingt gut. Die Umsetzung scheitert in der Praxis oftmals am herrschenden Zeitdruck und am fehlenden Budget für diese Treffen. Eine retrospektive Betrachtung, bei dem sich die Entwickler gemeinsam über die Erfahrungen und die neu erlangten Erkenntnisse des vergangenen Sprints austauschen, ist wichtig und sorgt für neue Synergien im Team. Dennoch empfinden Retrospektiven viele Teammitglieder als lästige Pflicht, deren Erfolg zweifelhaft erscheint. In der Tat gelingt es vielen Teams nicht wirklichen Nutzen aus Retrospektiven zu ziehen. Sie verlieren dann die Motivation für deren Durchführung und führen sie schließlich nur noch sporadisch durch oder verzichten darauf, um die Zeit für vermeintlich „Produktiveres“ zu nutzen.
Woran liegt das? Was will Scrum mit Retrospektiven erreichen? Im Gegensatz zu traditionellen Entwicklungsprozessen, die versuchen den gesamten Projektablauf zu definieren, bleibt Scrum offen und beschreibt nur die Rahmenbedingungen. Dadurch muss der Entwicklungsprozess fortlaufend an den Bedürfnissen angepasst werden (Inspect & Adapt). Diese Anpassung soll mit der Durchführung von Retrospektiven gelebt werden. Hier erfolgen Reflektionen. Es werden Verbesserungen für die laufenden Prozesse und das Produkt gefunden. Die Retrospektiven sind also der Schlüssel zum Erfolg. Sie sollten daher nicht entfallen. Für eine erfolgreiche Durchführung muss der Scrum-Master ein Gespür für das Zwischenmenschliche, für die Visionen im Team haben und die Grundprinzipien der agilen Methoden, wie zum Beispiel Selbstorganisation konsequent anwenden.
Scrum ist ein innovativer Ansatz der Projektorganisation zur effizienten Softwareentwicklung. Mit einer offenen Vorgehensweise und einen großen Ausmaß an Übernahme von Verantwortung durch das Team soll den ständigen wechselnden Anforderungen entgegengewirkt werden. Im Mittelpunkt steht das Miteinander der Mitarbeiter. Scrum ist eine Methode, die den Fokus auf den kurzfristigen Zeithorizont legt und das Langfristige nicht vernachlässigt, aber sich dort auf eine Grobplanung beschränkt. Scrum will gelebt werden, wenn es erfolgreich zum Einsatz kommen soll. Es erfordert ein Loslassen von bisherigen Strukturen und die Bereitschaft auch ungewöhnliche Wege zu gehen. Das Prinzip von Scrum ist in Abbildung 3 zusammengefasst.
Agile Anforderungsanalyse
Die Agile Analyse untersucht das zu lösende Problem, um es in überschaubare Teile zu zerlegen. Genauer gesagt in User Stories und Conditions of Satisfaction. Eine User Story beschreibt dabei ein Feature der Software. Sie hat die immer gleiche, einfache Struktur. Die Struktur zur Beschreibung wird vom Team selbst festgelegt. User Stories dienen als Kommunikationsmittel zwischen allen Projektbeteiligten.
Wichtig ist die Angabe der Conditions of Satisfaction (CoS). Sie sind die Abnahmekriterien des Kunden für das zu implementierende Feature. Einer User Story liegt folgendes Prinzip zu Grunde: „Als WER will ich WAS und WARUM machen“. Die Inhalte basieren auf der Definition von Vorbedingung, Aktion und Nachbedingung. Die Verwendung von User Stories hat die folgenden Vorteile:
- Förderung der klaren Formulierung des Nutzens einer Anforderung.
- Unterstützung der Kommunikation zwischen den Beteiligten (intern: zwischen den Teammitgliedern und extern: zwischen Kunde und Auftraggeber).
- Sind für alle Stakeholder verständlich, da diese in deren Sprache formuliert werden.
- Der Umfang einer User Story entspricht dem nächsten überblickbaren Planungsschritt.
Natürlich erfordert der Einsatz dieses Mittels auch eine entsprechende Sorgfalt. Die Verwaltung von User Stories ist anspruchsvoll, es ist ggf. der Einsatz eines spezialisierten Tools zu prüfen. Die Rückverfolgbarkeit von Änderungen an einer User Story sollte gewährleistet werden. Dieses kann man zum Beispiel erreichen, indem man ein Versionssystem für die die User Sories einführt. Ebenfalls ist darauf zu achten, dass dadurch eine umfassende Produktdokumentation dadurch nicht ersetzt wird. Aus der Verwendung von User Stories kann nicht geschlussfolgert werden, dass die Definition von Anwendungsfällen (Use Cases) nunmehr obsolet wird, vielmehr verfolgen beide Konzepte unterschiedliche Ziele und ergänzen einander (Abbildung 4).
Neben den funktionalen Anforderungen an ein System existieren auch nicht-funktionale Anforderungen. Diese definieren im weitesten Sinne die angestrebte Qualität. Dazu gehören zum Beispiel Sicherheitsanforderungen an das System, angestrebte Zuverlässigkeit (wie Verfügbarkeit bei Online-Systemen), Standards oder Vorhaben bzw. Einschränkungen bezüglich des Designs. Wo werden diese jetzt festgehalten, wenn ggf. kein Pflichtenheft mehr im klassischen Sinne existiert? Es bietet sich zum Beispiel an, diese nicht-funktionalen Anforderungen als Rahmenbedingungen zu den User Stories ergänzend zu notieren. Auch ist zu beachten, dass nicht alle User Stories auf der gleichen Bedeutungsebene für das Produkt angesiedelt sind. Kritische Spezifikationen sind entsprechend zu kennzeichnen. Dazu gehören Aussagen, welche Probleme entstehen, wenn Annahmen falsch sind. Welche Risiken bestehen, wenn Fehlfunktionen, Verzögerungen oder andere Probleme auftreten, welche eine (planmäßige) Umsetzung der Funktionalität nicht mehr erwarten lassen. Ein Beispiel: Ein Großteil der Funktionalität des Systems beruht auf einer zu implementierenden Schnittstelle zu bereits existierenden Systemen. Der Datentransfer soll über diese Schnittstelle ablaufen. Kommt es zu Problemen, die Schnittstelle rechtzeitig funktionsfähig zu realisieren, kann dieses Problem weitreichende Auswirkungen auf die Umsetzbarkeit des gesamten Projektes haben. Diese User Story sollte daher als kritisch gekennzeichnet werden.
Während die klassische Anforderungsanalyse darauf setzt, schon möglichst zu Beginn des Projektes alle Anforderungen zu kennen und festzuhalten, erlaubt die agile Analyse eine gewisse „Unwissenheit“ zu Projektstart. Folgende Grundprinzipien sind zusammenfassend festzuhalten:
- Probieren: Ein Ausprobieren ist im Entwicklungsprozess ausdrücklich erwünscht und möglich.
- Spätere Detailierung: Die Problemdefinition darf zu Beginn „lückenhaft“ sein und wird sukzessive vervollständigt. Planen und Schätzen sind immer sehr kritische Punkte in einem Projekt. Hier versucht Scrum einen alternativen Weg zu gehen. Features und Produktfunktionen, die in naher Zukunft implementiert werden, sind detailliert zu schätzen. Programmfunktionen, deren Realisierung erst in der weiteren Zukunft erfolgt, unterliegen einer gröberen Schätzung und Planung. Das Prinzip lautet horizon of predictability und meint, dass langfristige Detailplanungen nicht möglich sind und auch nicht erzwungen werden. Dieses Vorgehen minimiert den Planungsaufwand und erlaubt die Konzentration auf das Wesentliche.
- Kundenorientierung: Die Erhebung der Anforderungen erfolgt – im Übrigen wie das gesamte Projekt – auf der Basis eines kundenorientierten Ansatzes: Dabei definiert der Kunde den Wert einer bestimmten Anforderung (im Sinne einer Priorisierung). Der Kunde probiert frühzeitig bestimmte Produktfunktionen aus und gibt dazu unmittelbar ein Feedback. Werden Änderungswünsche deutlich gemacht, so werden diese entgegengenommen und deren Umsetzung geprüft. Anpassungen in den Verträgen sollten nach Möglichkeit hieraus nicht resultieren (sofern es sich im Rahmen des Entwicklungsprojektes bewegt).
- Teamarbeit und Mitbestimmung: Das gesamte Team denkt mit, d.h. bestimmte Anforderungen ergeben sich währen der laufenden Entwicklungsarbeit bzw. können erst dann spezifiziert werden. Das Team überlegt dann gemeinsam, wie bestimmte Anforderungen am besten umgesetzt werden können.
Fazit
Zusammenfassend kann man sagen, dass die Verwendung agiler Methoden – wie beispielsweise Scrum – weiterhin eine umfassende Anforderungsanalyse erfordern. Deren Schwerpunkt liegt zwar nicht mehr ausschließlich auf der ersten Projektphase, d.h. die Erhebung der Anforderungen ist nunmehr über das gesamte Projekt verteilt. Ein Pflichtenheft ist ggf. entbehrlich, dennoch besteht weiterhin eine Notwendigkeit der Dokumentation. Die Einhaltung der Qualitätskriterien bleibt die oberste Prämisse der Projektdurchführung. Die Agilität des Requirements Engineering soll primär dazu führen, dass man gegenüber Veränderungen flexibel reagiert.