Requirements Engineering and Cost Estimation - Anforderungen ermitteln

Anforderungen ermitteln

Die Basis des Requirements Engineering ist zu wissen, was überhaupt ‚erwartet‘ bzw. ‚gewünscht‘ ist. Chris Rupp spricht vom „Hellsehen für Fortgeschrittene“ und beschreibt den Umgang mit Anforderungen in Anlehnung an das bekannte Zitat von Mark Twain „Wer nicht weiß, was er will, darf sich nicht über das wundern, was er bekommt“ . Das Ermitteln von Requirements hat daher häufig weniger mit Sammeln zu tun, als mit danach ‚graben‘. Ein guter Requirements Engineer macht es den Stakeholdern schmackhaft, ihre Informationen und ihr Wissen herauszugeben und entlockt ihnen ihre Wünsche und Bedürfnisse. Anforderungen werden, wie gesagt, in den seltensten Fällen am Silbertablett serviert, noch weniger als strukturierte Forderungen, die auf das Knowhow über das zukünftige System und dessen Umfeld aufbauen.

Das Ziel dieser Phase ist es also, mit möglichst geringem Aufwand und angepasst an die Projektrahmenbedingungen und Ziele Requirements zu erfassen, um ein System zu entwickeln, das für die Stakeholder möglichst gewinnbringend ist. Dabei gilt es, einen effizienten Weg zwischen Risikominimierung und Kostenexplosion zu finden. Meistens gelingt dies, wenn die Stakeholder ‚verzaubert‘ und für eine möglichst reibungslose Kooperation mit professionellen Mitteln ins Boot geholt werden. Das Projekt und damit der Requirements Engineer sind auf das Wissen der Beteiligten angewiesen.

Am Anfang eines Projekts sind sich Stakeholder aber oft nicht klar, was sie sich genau von einem neuen System erwarten.

The most difficult part of requirements gathering is not the act of recording what the users want; it is the exploratory, development activity of helping users figure out what they want.

Im besten Fall kennen die Projektbeteiligten die bestehenden Geschäftsprozesse und, wenn vorhanden, das aktuelle System und können somit die Ist-Situation beschreiben. Die Herausforderung ist allerdings, die Soll-Situation herauszufinden, die die existierende Situation verbessert. Beim Bewusst- und Sichtbarmachen von Bedürfnissen und Wünschen unterstützt der Requirements Engineer als Moderator, um die zur Verfügung stehende Zeit optimal zu nutzen und so viel Wissen wie möglich und damit Anforderungen herauszufiltern. Dabei ist es essentiell, zum ‚richtigen‘ Zeitpunkt die ‚richtigen‘ Fragen zu stellen und aktiv zuzuhören. Welche Techniken und Herangehensweisen die geeignetsten sind, ist vom Projekt, den Rahmen­bedingungen, den einzelnen Stakeholdern und natürlich vom zuständigen Requirements Engineer abhängig. Grundlegende Vertrautheit mit Kommunikations­theorie sowie gängigen Coachingtechniken helfen die individuellen Situationen zu meistern.

Ein Requirements Engineer entwickelt mit seinen Fragestellungen und seiner Bereitschaft zuzuhören das Produkt entscheidend mit. Dementsprechend sind die kompetentesten Personen dieser Disziplin diejenigen, denen es gelingt, eine Brücke zwischen den soziologischen (menschliche Wesen und ihre Umwelten) sowie technischen Aspekten (präzise Spezifikationen) eines Projekts zu schlagen. Innovation entsteht dort, wo über die artikulierten Wünsche der Stakeholder hinaus entwickelt wird.

Weitere Herausforderungen, die das Zusammentragen von Requirements erschweren, sind der Umfang eines gewünschten Systems, die dafür nötigen Vereinbarung und die Unbeständigkeit der Anforderungen. Eine strukturierte Herangehensweise an die Ermittlung von Requirements hilft dem Requirements Engineer diese Schwierigkeiten zu bewältigen.

Anforderungsquellen

Für die Generierung von Anforderung kann auf verschiedene Quellen zurückgegriffen werden:

• Stakeholder

Personen oder Organisationen, die (in)direkten Einfluss auf Requirements haben, werden als Stakeholder bezeichnet, z.B. Auftraggeber, Systemnutzer, Systembetreiber, Architekten, Entwickler, Tester usw.

• Dokumente

Darin finden sich oft entscheidende Informationen, aus denen Anforderungen gestaltet werden können, u.a. Normen und Standards, Gesetzestexte sowie branchen-/organisationspezifische Unterlagen.

• Systeme im Betrieb

Dazu gehören Alt- bzw. Vorgängersysteme oder Systeme der Konkurrenz. Meist sind in solchen Fällen Erweiterungen und/oder Änderungen gewünscht. Um dabei innovativ sein zu können, ist es notwendig, eventuell auch gegen den Wunsch mancher Stakeholder Altes hinter sich zu lassen und über den Tellerrand hinauszuschauen.

Die Einbindung von Stakeholdern ist auch laut Standish Group mit Abstand für den Projekterfolg am entscheidendsten, weshalb eine zentrale Aufgabe des Requirements Engineer die Identifikation relevanter Stakeholder ist. Auch wenn Projektbeteiligte zum Teil widersprüchliche Ziele und Anforderungen verfolgen, ist es mit guten Beziehungen zu ihnen möglich, am raschesten an die relevanten Informationen zu gelangen. Darüber hinaus gewährleistet eine intensive Zusammen­arbeit, dass weniger Überarbeitung der Anforderungen notwendig ist, sich die Entwicklungsgeschwindigkeit im Projekt erhöht, geringere Reibung zwischen den Stakeholdern stattfinden und somit ein reduziertes Risiko für den Erfolg des Projekts. Unverzichtbar ist es, die Stimme der Kunden zu verstehen und bei ihnen eine angemessene Erwartungshaltung aufzubauen, denn „der größte Fehler im Projekt [besteht] häufig darin, dem Kunden das zu geben, was er braucht, und nicht das, was er will” .

Entscheidende Produktfaktoren

Um Anforderungen bewerten zu können, ist die Bedeutung dieser für die Zufrieden­heit der Stakeholder ausschlaggebend. Das von Dr. Noriaki Kano 1978 entwickelte Kano-Modell unterteilt dafür die entscheidenden Produktfaktoren in drei Kategorien: Basisfaktoren, Leistungsfaktoren und Begeisterungsfaktoren.

Kano-Modell

Basisfaktoren

Die sogenannten ‚Must-haves‘ werden unterbewusst als selbstverständlich voraus­gesetzt und beschreiben die Bedürfnisse sowie die Notwendigkeiten. Ohne deren Erfüllung entsteht bei Stakeholdern eine massive Unzufriedenheit. Gleichzeitig macht die Bereitstellung die Kunden noch nicht zufrieden. Basisfaktoren sind schwierig zu ermitteln, weil diese oft nicht artikuliert werden, sind sie doch auf gut österreichisch ‚eh klar‘. So gilt zum Bespiel für das Mobiltelefon, das vorausgesetzt wird, dass es sich dabei um ein tragbares Gerät handelt, mit dem telefoniert werden kann und mit dem der Benutzer überall erreichbar ist. Die Gefahr bei diesen Eigenschaften ist, dass Altlasten mitgeschleppt werden, ‚weil wir das immer schon so machen!‘. Auch deshalb bieten sich für ihre Entdeckung Beobachtungstechniken bzw. dokumentenzentrierte Techniken an.

Leistungsfaktoren

Leistungsfaktoren werden bewusst und explizit gefordert, handelt es sich doch um bekannte Wünsche und damit erstrebenswerte Merkmale. Diese stellen Kunden bei Erfüllung zufrieden, da sie die ‚Vollständigkeit‘ des Systems sicherstellen. Mit wenigen nicht erfüllten Eigenschaften sind Zielsysteme für Stakeholder meist noch akzeptabel, summieren sich jedoch fehlende Features erzeugt dies Unmut. Leistungsfaktoren sind meist die zuerst entdeckten Anforderungen, weil Stakeholder sie äußern. Zur Ermittlung eignen sich daher am besten Befragungstechniken sowie die Nutzung der Konkurrenz zur Inspiration.

Begeisterungsfaktoren

Unbewusste, weil den Kunden noch gänzlich unbekannte Features werden als Begeisterungsfaktoren bezeichnet und verkörpern Sehnsüchte. Sie erzeugen einen freudigen Überraschungseffekt bzw. bringen Kunden ins Schwärmen, wenn sie bei der Nutzung entdeckt werden. Ihr Wert wird für Stakeholder erst erkennbar, wenn sie von außen herangetragen werden. Solche innovativen Merkmale schaffen häufig den entscheidenden Vorsprung vor die Konkurrenz. Mit der Zeit werden aber Begeisterungsfaktoren durch Gewöhnung zu Leistungs- und schließlich sogar zu Basisfaktoren, wie z.B. heute Internet oder ein Touchscreen am Mobiltelefon. Derartige Charakteristika sind schwer zu ermitteln, weil sie noch nicht in der aktuellen Vorstellungswelt vorhanden sind. Eingesetzt werden meist Kreativitätstechniken, wobei Vorsicht geboten ist und rechtzeitig Analysen von Risiko, Machbarkeit, Nützlichkeit und Begeisterungspotential einbezogen werden sollten.

Ermittlungstechniken

Um an das Wissen der Stakeholder und damit die gewünschten Anforderungen zu gelangen, gibt es kein universelles Rezept. Viele unterschiedliche Techniken unterstützen die Ermittlung von Funktionen, Charakteristika, Einschränkungen und Erwartungen. Diese sind je nach Projekt, Rahmenbedingungen, Menschen und/oder Organisationskultur situativ anwendbar und bewusst auszuwählen. Die Ein­schätzung, welche Technik in der gegebenen Herausforderung die effizienteste ist, erfordert ‚Fingerspitzengefühl‘ und die Erfahrung des Requirements Engineer. Auch die sozialen, gruppendynamischen und kognitiven Kompetenzen der Stakeholder haben Einfluss auf die geeignete Ermittlungstechnik, ebenso wie die Frage, ob es sich beim zu erkundenden Wissen um unterbewusstes, bewusstes oder unbewusstes handelt.

Häufig werden verschiedene Techniken mit- und nacheinander eingesetzt, um die Risikofaktoren für das Projekt zu minimieren. Die Stärken und Schwächen der einzelnen Techniken lassen sich durch die Kombination verringern.

Kreativitätstechniken

Für die Generierung einer ersten Vision eines neuen Systems oder das Entwickeln von Innovationen und Begeisterungsfaktoren kommen meist Kreativitätstechniken zum Einsatz. Weniger geeignet sind sie für das Erheben detaillierter Anforderungen. Von den zahllosen Methoden und unterschiedlichsten Varianten seien hier nur einige exemplarisch genannt:

Brainstorming

In Gruppen von fünf bis zehn Personen werden in begrenzter Zeit ohne Zensur Ideen gesammelt und kommentarlos vom Moderator häufig in Form von Mindmaps festgehalten. Verrückte Vorschläge sind dabei erwünscht, da dank ihnen das Denken die gewohnten Bahnen verlässt. Teilnehmer bereichern die eigenen Vorstellungen durch die der anderen bzw. erweitern und verändern die bereits notierten. Die Analyse der Ideen erfolgt erst im Anschluss an die Kreativsession. Besonders erfolgreich ist diese Technik in Workshops mit sehr heterogenen Gruppen. Vorteile dieses Herangehens sind die Sammlung vieler Ideen in kurzer Zeit sowie das Finden neuer Lösungsansätze durch die wechselseitige ‚Befruchtung‘ und die unzensierten Ideen. Bei schwieriger Gruppendynamik oder starkem hierarchischen Gefälle ist Brainstorming weniger hilfreich, weil die Beteiligten sich wechselseitig blockieren.

Variante Brainstorming paradox

Eine hilfreiche Technik, um Risiken und geeignete Gegenmaßnahmen zu entwickeln, ist das Zusammentragen von Vorschlägen, die nicht erreicht werden sollen. Daraus können dann Aktivitäten erarbeitet werden, um die generierten Ideen zu verhindern.

Variante Brainwriting

Dabei sammeln die Teilnehmer gemeinsam in Ruhe und schriftlich ihre Ideen.

Methode 6-3-5

Sechs Teilnehmer formulieren gleichzeitig, schriftlich drei Ideen. Das Papier wird nach gewisser Zeit, etwa drei bis fünf Minuten, an den Nachbarn weitergereicht. Der Nächste greift die bereits genannten Ideen auf und entwickelt wiederum drei Ideen. Diese Weitergabe wird insgesamt fünfmal durchgeführt, bis jeder jedes Papier einmal bearbeitet hat. Mit dieser Methode entstehen innerhalb von 30 Minuten maximal 108 Ideen (6 Teilnehmer × 3 Ideen × 6 Runden). Bei komplexer Gruppendynamik bietet sich diese Technik an, da sie schriftlich und dadurch Konflikt vermeidend ist. Die vielen Ideen in relativ kurzer Zeit werden nicht zerredet, es gibt ein direktes Feedback und die Methode ist auch per email durchführbar. Gleichzeitig fordert sie eine genaue Anleitung und der starre Ablaufmechanismus stört gelegentlich die Kreativität. Auch der vorgegebene Arbeitstakt blockiert manchmal, weil er für manche Teilnehmer zu langsam und für andere zu schnell sein kann. Oft kommt es zu Redundanzen und im ungünstigsten Fall entstehen insgesamt nur drei Ideen.

Wechsel der Perspektiven

Edward de Bono präsentierte 1986 die heute bekannteste Technik zum Verändern des Blickwinkels. Bei seiner Sechs-Hut-Methode nehmen die Teilnehmer unterschiedliche Perspektiven ein, die durch verschiedenfarbige Hüte symbolisiert werden. Dieses ‚Rollenspiel‘ eignet sich besonders zur umfassenden Beleuchtung komplexerer Aufgabenstellungen sowie zur Bewertung und Optimierung von bereits erarbeiteten Lösungen oder Ideen. Je nach Gruppe ist die Herangehensweise nicht nur effizient, sondern auch unterhaltsam. Durch das in-eine-Rolle-Schlüpfen sind differenziertere Diskussionen möglich, vor allem wenn möglichst viele und ‚extreme‘ Denkmodi berücksichtigt werden. Je nach Temperament und Intro-/Extrovertiertheit der Teilnehmer, können Standpunkte überbetont bzw. theatralisches übersteigert werden. Empfohlen werden Vorübungen, um das thematische Vorwissen zu gewährleisten, bzw. wie bei andere Gruppentechniken eine Moderation.

Analogietechniken (Bionik/Bioziation)

Vorgänge in der Natur werden auf eine vorliegende, meist technische Heraus­forderung übertragen und daraus neue Lösungsmöglichkeiten und Ideen abgeleitet. Die Rückschlüsse aus den Betrachtungen, warum die Dinge in der Natur so sind oder so reagieren, erlauben ein Durchbrechen etablierter geistiger Routinen.

Mit Assoziationen sind gedankliche Verknüpfungen auf einer Ebene gemeint. Die Bisoziation verknüpft Begriffe aus zwei typischerweise nicht zusammengehörenden Ebenen miteinander.

Befragungstechniken

Die Anrufe irgendwelcher Umfrageinstitute beweisen, dass Befragungstechniken der Klassiker zur Informationsbeschaffung sind. Sie sind für alle Detaillierungsgrade von Requirements einsetzbar, solange diese klar artikuliert sind. Mit der entsprechenden Übung kann Befragung für die Erhebung von Leistungs- und Basisfaktoren verwendet werden, etwas schwieriger, aber dennoch möglich für nicht-funktionale Anforderungen. Vorsicht ist allerdings bei der Vorbereitung bzw. eventuell der Auswertung geboten, da die Formulierung von Fragen die Antworten beeinflusst.

Interview

Diese zielen darauf ab, im direkten Gespräch von den einzelnen Stakeholdern möglichst präzise und unverfälschte Auskünfte über deren Anforderungen zu erhalten. Die Befragten können bei Unklarheiten sofort Rückmeldungen geben oder Fragen stellen, woraus sich häufig unerwartete Aspekte ergeben, die ebenso dokumentiert werden können. Das Interview kann flexibel und individuell an das Gegenüber angepasst werden und durch die persönliche Durchführung werden Fragen meist tatsächlich beantwortet. Es besteht allerdings die Gefahr, dass sich das Gespräch unkontrolliert ausweitet oder abgleitet und ineffizient wird. Darüber hinaus wirken zusätzlich zur Formulierung Mimik, Gestik und Tonfall auf den Stakeholder.

Fragebogen

Dabei wird ein Katalog an geschlossenen und/oder offenen Fragen zur Ermittlung von Informationen herangezogen. Wenn Umfragen elektronisch durchgeführt und automatisiert ausgewertet werden, ist dies bei einer großen Zahl von Stakeholdern möglich. Die fehlende Interaktion macht diese Herangehensweise nur für Bewertungen bzw. zur Klärung von Fragen hilfreich, bei denen mutmaßlich das relevante Knowhow bereits bekannt ist, nicht für implizites Wissen. Eine professionelle Erstellung ist entscheidend, sonst sind Fragebögen meist wenig aussagekräftig.

Dokumentenzentrierte Techniken

Wenn diejenigen Mitarbeiter mit dem Wissen über ein jahrelang genutztes System nicht mehr im Unternehmen sind, sondern nur noch Systemnutzer, erlauben dokumentenzentrierte Techniken den Zugriff auf den gesamten Umfang der Funktionalität. Unter der Voraussetzung, das Vorgängersystem ist im Detail und in guter Qualität dokumentiert, kann so das unterbewusste Wissen erhoben werden. Dabei ist zu prüfen, welche (Basis)Faktoren tatsächlich noch gebraucht, welche weggelassen und welche Teile neu kreiert werden soll.

Systemarchäologie

Eine Technik, um Informationen für ein neues System aus der Dokumentation (oder Implementierung) eines Altsystems herauszuholen, ist die Systemarchäologie. Dank Extraktionstechniken kann speziell aus dem Benutzerhandbuch oder alten Testfällen Bekanntes ‚ausgegraben‘ und wieder umgesetzt werden. Diese aufwendige Vorgangsweise erlaubt nur Aussagen über das jeweilige Vorgängersystem, nicht das zu entwickelnde System. Bei schnelllebigen Systemen oder wenn die Dokumentation qualitativ minderwertig oder veraltet ist, lohnt sich diese Methode nicht.

Wiederverwendung

‚Re-Use‘ ist eine Technik, um einmal erarbeitete Anforderungen aus einem vergangenen Projekt an die jetzigen Gegebenheiten anzupassen. Wenn es gelingt, die richtige Anforderung ausfindig zu machen und diese eine gute Dokumentation aufweist, bringt die Wiederverwendung eine enorme Kostenersparnis. Zu beachten ist allerdings die Gefahr, Fehler aus dem vorherigen System zu übernehmen. Dementsprechend muss eine intensive Kontrolle qualitative Mängel ausschließen und die Requirements auf einen entsprechenden Stand bringen.

Beobachtungstechniken

Wenn die Fachspezialisten keine Zeit haben oder nicht in der Lage sind, ihr Wissen zu formulieren, kommen Beobachtungstechniken zum Einsatz. Mit ihnen kann unterbewusstes Wissen ermittelt werden und sie werden besonders für sehr detaillierte Requirements und Basisfaktoren verwendet. Ein Risiko ist, dass vor allem bei der Erhebung aus Vorgängersystemen, alte Technologien bzw. überholte Abläufe festgehalten werden. Der neutrale Beobachter kann aber auch solche Potentiale erkennen und für das Projekt nutzen. Wichtig ist, zu bedenken, dass ein Beobachter immer schon Teil des Systems ist und dieses dadurch verändert. Außerdem liefert Beobachtung nur eine Momentaufnahme und ist für schwer zu verfolgende Prozesse sowie selten auftretende Sonderfälle, z.B. in sicherheitskritischen Bereichen, nicht geeignet.

Feldbeobachtung

Diese Technik dient dazu, die Tätigkeiten, Zusammenhänge und Prozesse der Arbeit eines Stakeholders kennenzulernen und daraus Anforderungen besser ableiten zu können. In dieser Vorgangsweise besteht die Möglichkeit, nachzufragen und sich Einzelheiten erklären zu lassen. Besonders erfolgreich ist Feldbeobachtung bei automatisierten Arbeitsschritten bzw. um individuelle Herangehensweisen zu untersuchen, wenn eine Tätigkeit von verschiedenen Personen durchgeführt wird. Um nicht als Kontrolleur angesehen zu werden, bedarf es einer speziellen Achtsamkeit, vor allem wenn Videoaufnahmen zum Einsatz kommen. Falls die Beobachtung dem observierten Stakeholder unangenehm ist, verändert das nachteilig das Resultat.

Apprenticing

Um das Machtverhältnis zwischen fragendem Beobachter und antwortendem Stake­holder umzukehren, empfiehlt sich die Anwendung des Apprenticing (‚In die Lehre gehen‘). Dabei erlernt der Requirements Engineer die Tätigkeiten vom ‚Meister‘, gießt dieses Knowhow anschließend in Requirements und ist sogar in der Lage, Testfälle zu generieren. Aufgrund der ungeübten Durchführung des Beobachters können potentielle Fehlerquellen, die bei Routiniers selten auftauchen, früher entdeckt werden. Für die Technik sind Personen mit entsprechendem Fachwissen notwendig und vor allem für den ‚Lehrling‘ ist sie enorm zeit- und damit kostenintensiv.

Unterstützende Techniken

Zudem gibt es zahllose Vorgangsweisen, die Ermittlungstechniken ergänzen bzw. deren Schwächen ausgleichen, z.B. Mind Mapping, Workshops, Audio- bzw. Videoaufzeichnungen, Prototypen, Szenarien, Essenzbildung oder Use-Case Modellierung.

Für die praktische Umsetzung bietet Chris Rupp mit dem SOPHIST-REgelwerk eine weitere hilfreiche Technik. Die darin enthaltenen 18 Regeln sind beim Ermitteln und auch bei der Formulierung von Anforderungen hilfreich. Perfekte Kommunikation ist per se unmöglich und schon diese Erkenntnis kann Requirements Engineers das Leben leichter machen. Mit vertiefendem Knowhow bzw. Checklisten zur Kommunikation gestaltet sich das Arbeiten in der Praxis kompetenter und erfolgreicher.

Wahl der richtigen Ermittlungstechnik

Unterschiedlichste Faktoren wie Termin- und Budgetvorgaben beeinflussen die Wahl der richtigen Ermittlungstechnik. Auch die räumliche und zeitliche Verfügbarkeit von Stakeholdern, deren soziale, gruppendynamische und kognitive Fähigkeiten oder die Kategorisierung des zu ermittelnden Wissens nach dem Kano-Modell tragen dazu bei, welche Herangehensweise gerade geeignet ist. Weiters sind die Anforderungs­art, die Detailierungsebene sowie die jeweilige Erfahrung des Requirements Engineer und der Stakeholder mit einer Methode zu berücksichtigen. Auswirkungen zeigen sich ebenso, wenn es sich um eine Neuentwicklung oder Erweiterung eines Altsystems handelt, wenn der zu lösende Sachverhalt eine hohe Komplexität aufweist oder ein großer Systemumfang gegeben ist. Auch die Chancen und Risiken des spezifischen Projekts verursachen Kriterien, die für oder gegen Ermittlungstechniken sprechen.