Workshops im Requirements Engineering: Methoden, Checklisten und Best Practices für die Ermittlung von Anforderungen
Von Markus Unterauer
4/5
()
Über dieses E-Book
- Konkrete Beispiele für Workshop-Moderationspläne
- Workshop-Ideen speziell für agile Teams
- Checklisten und Best Practices aus der Workshop-Moderationspraxis
Ein effizientes Requirements Engineering ist Grundlage für erfolgreiche Softwareprojekte. Dieses Buch zeigt, wie Workshops zur schrittweisen Ermittlung von Anforderungen effektiv gestaltet werden können. Es liefert konkrete Antworten auf die Fragen:
- Wie gestalte ich Workshops zur Anforderungsermittlung?
- Wie moderiere ich solche Meetings und Workshops?
- Welche Fragen stelle ich? Worauf muss ich inhaltlich achten?
- Womit fange ich an? Was mache ich in den ersten Workshops? Was kommt dann?
Markus Unterauer geht dabei über eine theoretische Betrachtung allgemeiner Methoden hinaus und tief hinein in die Mühen der täglichen Arbeit als Product Owner, Projektleiter, Business Analyst oder Requirements Engineer. Die einzelnen Schritte in der Anforderungsermittlung sind entlang einer durchgängigen Vorgehensweise angeordnet.
Die 2. Auflage enthält weitere Workshop-Ideen speziell für agile Teams. Hinzugekommen sind Methoden für den Product Owner wie Impact Mapping, Story Maps, Buy a Story, T-Shirt-Sizing und Best Practices für das Story Splitting. Bisherige Kapitel wurden mit der Erfahrung der letzten fünf Jahre überarbeitet und ergänzt.
Ähnlich wie Workshops im Requirements Engineering
Ähnliche E-Books
Modellbasiertes Requirements Engineering: Von der Anforderung zum ausführbaren Testfall Bewertung: 0 von 5 Sternen0 BewertungenAgiles Requirements Engineering und Testen Bewertung: 0 von 5 Sternen0 BewertungenBessere Softwareentwicklung mit DevOps Bewertung: 0 von 5 Sternen0 BewertungenAgiles Produktmanagement mit Scrum: Erfolgreich als Product Owner arbeiten Bewertung: 3 von 5 Sternen3/5User Experience Testing 3.0: Status Quo, Entwicklung und Trends Bewertung: 0 von 5 Sternen0 BewertungenSchneller - besser - kostengünstiger: Prozess - und Risikomanagement, Prozesskostenrechnung für Klein- und Mittelstandsunternehmen Bewertung: 0 von 5 Sternen0 BewertungenScrum. Schnelleinstieg (3. Aufl.) Bewertung: 0 von 5 Sternen0 BewertungenUX-Missverständnisse: Was sich User wirklich wünschen Bewertung: 0 von 5 Sternen0 BewertungenFMEA konkret: Präventive Risikoanalyse konkret mit FMEA plus. Die Buchreihe für erfolgreiche Entwickler, Trainer und Moderatoren. Bewertung: 0 von 5 Sternen0 BewertungenUser - Interface - Design: Usability in Web- und Software-Projekten Bewertung: 0 von 5 Sternen0 BewertungenProjektmanagement: Grundlagen, Methoden und Techniken Bewertung: 0 von 5 Sternen0 BewertungenSoft Skills in der IT Bewertung: 0 von 5 Sternen0 BewertungenSoftware entwickeln mit Verstand: Was Sie über Wissensarbeit wissen müssen, um Projekte produktiver zu machen Bewertung: 4 von 5 Sternen4/5Agiles Arbeiten: Das Wesentliche kurz erklärt. Version 3.0 Bewertung: 0 von 5 Sternen0 BewertungenErfolgreich Lastenhefte schreiben: Eine Schritt-für-Schritt-Anleitung für den Mittelstand Bewertung: 0 von 5 Sternen0 BewertungenScrum: Schnelleinstieg Bewertung: 0 von 5 Sternen0 BewertungenEffektives Projektmanagement: Erfahrungen aus der Praxis Bewertung: 0 von 5 Sternen0 BewertungenGrundlagen des Projektmanagements: Methoden, Techniken und Tools für Projektleiter Bewertung: 0 von 5 Sternen0 BewertungenScrum: Agiles Projektmanagement und Scrum erfolgreich anwenden Bewertung: 0 von 5 Sternen0 BewertungenKnigge für Softwarearchitekten Bewertung: 0 von 5 Sternen0 BewertungenLeadership im Produktmanagement: Wie Sie Stakeholder und Entwicklungsteams effektiv führen Bewertung: 0 von 5 Sternen0 BewertungenProjektmanagement: - zehn Module zu ausgewählten Themen Bewertung: 0 von 5 Sternen0 BewertungenModerne Datenzugriffslösungen mit Entity Framework 6 Bewertung: 0 von 5 Sternen0 BewertungenBasiswissen Requirements Engineering: Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level Bewertung: 0 von 5 Sternen0 BewertungenIT-Management: Grundlagen und Perspektiven für den erfolgreichen Einsatz von IT im Unternehmen Bewertung: 0 von 5 Sternen0 Bewertungen
Softwareentwicklung & -technik für Sie
Programmieren lernen mit Python 3: Schnelleinstieg für Beginner Bewertung: 0 von 5 Sternen0 BewertungenDas große Python3 Workbook: Mit vielen Beispielen und Übungen - Programmieren leicht gemacht! Bewertung: 4 von 5 Sternen4/53D-Drucken für Einsteiger: Ohne Frust 3D-Drucker selbst nutzen Bewertung: 0 von 5 Sternen0 BewertungenProjekt Unicorn: Der Roman. Über Entwickler, Digital Disruption und das Überleben im Datenzeitalter Bewertung: 0 von 5 Sternen0 BewertungenSketchnotes in der IT: Abstrakte Themen mit Leichtigkeit visualisieren Bewertung: 0 von 5 Sternen0 BewertungenAgile Spiele – kurz & gut: Für Agile Coaches und Scrum Master Bewertung: 0 von 5 Sternen0 BewertungenKanban für Anfänger: Grundlegendes über den Einsatz von Kanban in der Industrie und der Softwareentwicklung Bewertung: 0 von 5 Sternen0 BewertungenAgiles Projektmanagement: Scrum für Einsteiger Bewertung: 0 von 5 Sternen0 BewertungenLean Production - Grundlagen: Das Prinzip der schlanken Produktion verstehen und in der Praxis anwenden. Schlank zur Wertschöpfung! Bewertung: 0 von 5 Sternen0 BewertungenProjektmanagement für Anfänger: Grundlagen, -begriffe und Tools Bewertung: 0 von 5 Sternen0 BewertungenZertifizierung für Softwarearchitekten: Ihr Weg zur iSAQB-CPSA-F-Prüfung Bewertung: 0 von 5 Sternen0 BewertungenQualität in IT-Architekturen: Management Bewertung: 0 von 5 Sternen0 BewertungenAgiles Coaching als Erfolgsfaktor: Grundlagen des Coachings, um Agile Teams erfolgreich zu managen Bewertung: 0 von 5 Sternen0 BewertungenAutomatisiertes Testen: Testautomatisierung mit Geb und ScalaTest Bewertung: 0 von 5 Sternen0 BewertungenFreistellen mit Adobe Photoshop CC und Photoshop Elements - Gewusst wie Bewertung: 0 von 5 Sternen0 BewertungenSoftwareentwicklungsprozess: Von der ersten Idee bis zur Installation Bewertung: 0 von 5 Sternen0 BewertungenDesign Thinking für Anfänger: Innovation als Faktor für unternehmerischen Erfolg Bewertung: 0 von 5 Sternen0 BewertungenDigital Paintbook Volume 3 Bewertung: 5 von 5 Sternen5/5Einfach Java: Gleich richtig programmieren lernen Bewertung: 0 von 5 Sternen0 BewertungenKompaktes Managementwissen: Die Grunstruktur agiler Prozesse Bewertung: 0 von 5 Sternen0 BewertungenChange Management für Anfänger: Veränderungsprozesse Verstehen und Aktiv Gestalten Bewertung: 1 von 5 Sternen1/5UML @ Classroom: Eine Einführung in die objektorientierte Modellierung Bewertung: 0 von 5 Sternen0 BewertungenEinstieg in Reguläre Ausdrücke Bewertung: 0 von 5 Sternen0 BewertungenIT Wissensmanagement: Theorie und Praxis Bewertung: 0 von 5 Sternen0 BewertungenLean Management für Einsteiger: Grundlagen des Lean Managements für Kleine und Mittelständische Unternehmen – mit Vielen Praxisbeispielen Bewertung: 0 von 5 Sternen0 BewertungenDie besten Android-Apps: Android-Systemtools - Fotografie & Freizeit - Büro-Tools, Schule und Studium Bewertung: 1 von 5 Sternen1/5Systems Engineering mit SysML/UML: Anforderungen, Analyse, Architektur. Mit einem Geleitwort von Richard Mark Soley Bewertung: 0 von 5 Sternen0 BewertungenPrinzipien des Softwaredesigns: Entwurfsstrategien für komplexe Systeme Bewertung: 0 von 5 Sternen0 BewertungenScrum: Schnelleinstieg Bewertung: 0 von 5 Sternen0 Bewertungen
Rezensionen für Workshops im Requirements Engineering
1 Bewertung0 Rezensionen
Buchvorschau
Workshops im Requirements Engineering - Markus Unterauer
1Einleitung
1.1Meine Vision für die Anforderungsermittlung
Anforderungsermittlung bedeutet, herauszufinden, was unsere Kunden wirklich brauchen. Dafür müssen wir unsere Kunden verstehen und begreifen, was sie tun. Wir müssen ihre Bedürfnisse kennen und herausfinden, wie ihnen Software helfen kann, was diese können muss und wie die wesentlichen Funktionen laufen sollen.
Ein tiefes Verständnis der Probleme, Ziele und Bedürfnisse unserer Kunden ist das Fundament für alle Anforderungen. Basierend darauf können wir gemeinsam mit Anwendern und Entwicklern herausfinden, was die Anforderungen an die neu zu erstellende oder zu ändernde Software sind. Dieses Verständnis für den Kunden und seine Anforderungen müssen wir dann zu denjenigen transportieren, die die Software bauen. Diese müssen es so umsetzen, dass das System am Ende unseren Kunden hilft, ihre Ziele zu erreichen und Probleme zu lösen. Das Verständnis für den Kunden, seine Ziele und Probleme ermöglicht mir als Requirements Engineer, die richtigen Fragen zu stellen, und dem Entwickler, die richtigen Entscheidungen bei der Umsetzung zu treffen.
Meiner Meinung nach ist es nicht immer zwingend notwendig, alles bis ins kleinste Detail vorab auszuspezifizieren. Wenn die Entwickler Erfahrung in der Fachdomäne und mit der eingesetzten Technologie haben, kann ich Detailentscheidungen getrost ihnen überlassen. Haben die Entwickler diese Erfahrung nicht oder ist ein neuer Umsetzungspartner mit im Boot, muss wesentlich genauer erhoben und spezifiziert werden. Es ist meine Aufgabe als Requirements Engineer, zu erkennen, welchen Grad an Spezifikation ein Projekt erfordert, und mein Vorgehen danach anzupassen. Ziel ist nicht die perfekteste Spezifikation oder die Verwendung einer bestimmten Methode, sondern Software, die unsere Kunden weiterbringt!
1.2Von anderen lernen
Bevor wir uns ins Ermitteln von Anforderungen für Softwaresysteme stürzen, möchte ich Ihnen eine kleine Geschichte zum Thema Umgang mit Kunden und deren Anforderungen in einem völlig anderen Umfeld erzählen:
Erinnern Sie sich noch an Ihren letzten Autokauf? Bei mir war das vor gut 15 Jahren. Ich betrat den Schauraum des Autohändlers meines Vertrauens. Sofort sprang Herr G., der Topverkäufer vor Ort, auf, kam auf mich zu und begrüßte mich herzlich. Er fragte mich freundlich, wie er mir helfen könne. »Ich brauche ein neues Auto, mein altes ist vorige Woche zusammengefallen«, brachte ich es gleich auf den Punkt. »Oje! Na dann schauen wir mal. Wo wohnen Sie denn, Herr Unterauer?«, fragte mich Herr G. Es folgte ein nettes Gespräch, in dem er sich nach meiner Wohnsituation erkundigte, meinem Job, ob ich Kinder hätte, wohin ich in Urlaub fahre und was ich gerne in meiner Freizeit mache. Kaum mal ein Wort über ein Auto. Dafür hatte Herr G. am Ende ein sehr gutes Bild davon, wie mein Alltag so aussieht und wofür ich denn ein Auto überhaupt brauche.
Erst jetzt fragte er mich, was ich mir vorgestellt hätte. Ha! Ich hatte mir schon eine genaue Liste gemacht: Nicht allzu groß sollte es sein, nicht zu teuer, mit Klimaanlage, CD-Player, geringem Verbrauch und langer Lebensdauer. Ein Sportlenkrad und Nebelscheinwerfer wollte ich auch unbedingt haben. Den Allradantrieb, der eigentlich auf meiner Liste gestanden hatte, hatte ich gedanklich während des Gesprächs schon gestrichen. Herr G. hörte sich das alles an, machte sich Notizen und zog dann einige Prospekte hervor, die er mir in die Hand drückte. »Ich möchte Ihnen mal etwas zeigen, Herr Unterauer«, sagte er und führte mich zu einem schicken Mittelklassewagen. Er beschrieb mir die Ausstattung, die Vorzüge, die ewige Lebensdauer und garantierte Pannenfreiheit des Wagens. Das gefiel mir alles sehr gut! Als ich dann allerdings auf das Preisschild schielte, begann meine linke Gesichtshälfte unkontrolliert zu zucken. Der Wagen war zwar toll und hatte alles, was ich zuvor aufgezählt hatte, war aber aufgrund der Größe und Ausstattung viel zu teuer. Herr G. reagierte sofort und bugsierte mich sachte zu einem sportlich angehauchten Kleinwagen. Was soll ich sagen: Der war es! Herr G. plauderte beim Auto noch ein wenig mit mir, hatte aber natürlich längst gemerkt, dass wir den perfekten Wagen für mich gefunden hatten.
Obwohl ich mich kaum losreißen konnte, setzten wir uns als Letztes vor den Computer von Herrn G. Jetzt ging die technische Detailarbeit los. Welches Getriebe, welche Motorisierung, welches Radio, welche Sitzbezüge, Felgen, Lackfarbe und ungefähr noch 20.000 weitere Fragen hatte Herr G. auf seiner Checkliste. Da musste ich jetzt durch. Eine halbe Stunde später verließ ich verschwitzt, aber glücklich das Autohaus. In meiner Tasche hatte ich den Kaufvertrag für mein nagelneues Auto.
Wir können für die Ermittlung von Anforderungen in Softwareprojekten eine Menge von diesem Beispiel aus dem »richtigen Leben« lernen:
Mit Zielen und Nutzen beginnen
Starten Sie wie Herr G. mit der Frage nach den Zielen und dem »Warum brauchen Sie das?«. Lernen Sie die Welt der Stakeholder kennen. Nur wenn wir das Ziel kennen, können wir die optimale Lösung finden. Unsere Stakeholder kommen mit einem bunten Mix aus Zielen, Nutzen, Problemen und konkreten technischen Lösungsideen zu uns. Es ist unsere Aufgabe, die Stakeholder etwas zu bremsen und herauszuarbeiten, was der Zweck des Systems ist, welche Ziele damit erreicht und welche Probleme gelöst werden sollen.
Anforderungen schrittweise verfeinern
Wenn Sie wissen, was die Ziele sind, erarbeiten Sie die Anforderungen vom Groben zum Feinen. Die zentrale Frage ist hier: »Was soll das System können?« Beginnen Sie mit groben Anforderungsblöcken, präzisieren Sie sie für die Planung und Budgetierung so weit, dass Sie sie schätzen können, und spezifizieren Sie sie für die Umsetzung dann detailliert aus.
Ständig dazulernen
Als Requirements Engineer lernen wir zu Beginn die Sprache der Stakeholder und was diese wollen. Unsere Stakeholder lernen, was sie wirklich brauchen und was mit der gegebenen Technologie alles möglich ist. Alle gemeinsam lernen wir, wie wir am besten zusammenarbeiten können, damit wir die Ziele erreichen. Da dieses Lernen im ganzen Projektverlauf weitergeht, ist es völlig natürlich, dass sich die Anforderungen ändern. Unsere Stakeholder dachten vielleicht zu Beginn des Projektes, sie würden für eine bestimmte Aufgabe einen gedruckten Bericht benötigen, schlussendlich stellt sich aber heraus, dass eine reine Bildschirmanzeige die bessere Lösung ist. Rechnen Sie also fix mit Änderungen!
PS: Ich habe meinen Wagen mittlerweile schon 15 Jahre und er bringt mich immer noch ohne Pannen oder größere Reparaturen überall hin. Danke Herr G.! Wenn uns das in unseren Softwareprojekten ebenso gelingt, sind wir schon einen großen Schritt weiter.
1.3Anforderungen schrittweise ermitteln
In meiner Praxis hat sich folgendes schrittweise Vorgehen zum Ermitteln von Anforderungen bewährt:
Abb. 1–1Anforderungen schrittweise ermitteln und verfeinern
Beginnen Sie damit, herauszufinden, was der Auftraggeber mit dem System erreichen will. Lernen Sie seine Welt kennen und verstehen. Je besser Ihnen dieser erste Schritt gelingt, desto bessere Fragen werden Sie stellen können und desto besser wird das neue System den Anwendern helfen, ihre Probleme zu lösen und Ziele zu erreichen. Erst danach beschreiben Sie, was das System können und wie es aussehen soll. Das Ergebnis ist ein System, das genau diejenigen Funktionen und Eigenschaften bietet, die die Anwender tatsächlich brauchen. Nicht mehr und nicht weniger. Es wird weder etwas gebaut, das dann nicht verwendet wird. Das wäre Verschwendung. Noch wird etwas weggelassen, was benötigt würde. Das würde zu mangelhaftem Nutzen führen. Das System erfüllt exakt die tatsächlichen Bedürfnisse der Anwender bei geringstmöglichen Entwicklungskosten.
Die linke Seite in Abbildung 1–1 zeigt die Fragen, die uns im Laufe der Zeit leiten. Beginnend mit dem »Warum?« über das »Was?« kommen wir erst am Ende zum technischen »Wie?« Diese Trennung verläuft nicht immer klar und eindeutig. Wenn Sie sich in einer frühen Phase in einer technischen Detaildiskussion verzetteln, ist das kein Drama. Notieren Sie die wichtigsten Punkte für später und kehren Sie dann wieder zur ursprünglichen Fragestellung zurück.
Der Mittelteil von Abbildung 1–1 beschreibt die einzelnen Themen, die Sie Schritt für Schritt bearbeiten. Beginnen Sie mit dem Systemzweck, den wesentlichen Geschäftszielen und den großen Funktionsbereichen. Diese werden oft gemeinsam mit den wichtigsten Rahmenbedingungen vom Projektsponsor vorgegeben. Aus dem Zweck und den Funktionsbereichen können Sie ableiten, wer die Stakeholder sind. Mit den Stakeholdern können Sie erarbeiten, welche konkreten Ziele erreicht und welche Probleme an der aktuellen Situation gelöst werden sollen. Beschreiben Sie auf grober Ebene die aktuelle Systemlandschaft und die fachlichen Prozesse, in die das neue System eingebettet sein wird.
Gemeinsam mit den Stakeholdern entwerfen Sie, was das System können muss und wie die fachlichen Prozesse der Anwender unterstützt werden können. Diese als Anwendungsfälle spezifizierten Funktionen bilden das zentrale Element der funktionalen Spezifikation. Zu den Anwendungsfällen ergänzen Sie die notwendigen Daten, Masken, Berichte und Schnittstellen (siehe Abb. 1–2).
Abb. 1–2Systemfunktionen als Anwendungsfälle spezifizieren und dafür Daten, Masken, Berichte und Schnittstellen beschreiben
All diese Informationen zum »Warum?« und »Was?« bilden gemeinsam eine solide Grundlage für den Entwurf des technischen Lösungskonzeptes.
1.4Anforderungsermittlung als iterativer Prozess
Diese Vorgehensweise scheint auf den ersten Blick dem klassischen »Big Design Upfront«-Ansatz zu folgen, bei dem erst das gesamte System vollständig und bis ins Detail spezifiziert werden muss, bevor mit der Umsetzung begonnen werden darf. So können Sie es zwar machen, ich empfehle es aber nicht.
Besser ist es, sich an agilen Prinzipien zu orientieren¹. Das bedeutet, Sie beginnen mit dem Systemzweck, den Zielen und den Stakeholdern. Die darauffolgenden Schritte werden stark überlappend durchgeführt, indem Sie für alle Ebenen immer erst eine Liste mit Überschriften sammeln und deren Inhalte und Details im Laufe der Zeit ausarbeiten, sobald die Umsetzung bevorsteht.
Beispielsweise erstellen Sie mit den Stakeholdern zuerst eine Liste der zu unterstützenden Geschäftsprozesse. Diese priorisieren Sie nach Nutzen. Die wichtigsten 1–5 Prozesse, die schon im ersten Release unterstützt werden müssen, sehen Sie sich nun genauer an. Nur für diese Top-5-Prozesse leiten Sie Anwendungsfälle und genaue Anforderungen ab. Diese werden dann im ersten Release umgesetzt. Während der Umsetzung beginnen Sie mit der Spezifikation des nächsten Release. Das heißt, Sie wählen aus der Liste der Geschäftsprozesse die nächsten aus, spezifizieren sie genauer, leiten Anwendungsfälle ab usw.
Das Grundprinzip dieser Vorgehensweise ist: Wir spezifizieren so spät wie sinnvoll möglich. James Shore spricht hier vom »latest responsible moment« [Shore, 2007]. Es wird lediglich das genau ausspezifiziert, was in der nächsten Zeit umgesetzt wird. Alles andere wird nur grob abgesteckt [Bergsmann, 2018] (siehe Abb. 1–3).
Abb. 1–3Je näher die Umsetzung, desto genauer wird spezifiziert (Grafik angelehnt an [Ambler & Lines, 2012] und [Bergsmann, 2018]).
Auf diese Weise vermeidet man, dass Dinge spezifiziert werden, die am Ende doch nicht gebraucht oder völlig anders umgesetzt werden. Einer meiner Kunden erzählte beispielsweise, er hatte in einem seiner Projekte Hunderte Stunden in ein 210-seitiges Spezifikationsdokument investiert. Umgesetzt wurde lediglich ein Drittel, den Rest hatten die Entwickler nicht einmal mehr gelesen. Solche »write only«-Spezifikationen wollen wir vermeiden.
Darüber hinaus verteilt sich der Aufwand für die Anforderungsermittlung besser auf das gesamte Projekt (siehe Abb. 1–4, [Bergsmann, 2018]).
Abb. 1–4Aufwand für Anforderungsermittlung verteilt sich über das ganze Projekt.
Ein weiterer wichtiger Aspekt, den wir bei der Ermittlung von Anforderungen berücksichtigen müssen, ist, dass wir und unsere Stakeholder zu Beginn gar nicht alle Anforderungen kennen. Wir können sie also auch mit noch so viel Aufwand nicht ermitteln. Unser Vorgehen muss uns also ermöglichen, ständig dazuzulernen und das bisher Erreichte zu hinterfragen und zu korrigieren. Wir müssen es dafür unseren Stakeholder so einfach wie möglich machen, Feedback zu geben und möglichst eng mitzuarbeiten [Grau & Lauenroth, o.J.]. Je besser eine Methode das Feedback und die Zusammenarbeit mit unseren Stakeholdern unterstützt, desto besser hilft sie uns in unseren Projekten.
1.5Workshops und andere Techniken
In diesem Buch geht es um den Einsatz von Workshops zur Ermittlung von Anforderungen. Neben Workshops gibt es natürlich noch zahlreiche andere Methoden und Techniken zum Ermitteln von Anforderungen, die Sie ergänzend oder alternativ zu Workshops einsetzen können. Die folgenden stellen eine kleine Auswahl dar [IREB C.-A. , 2012; Ebert, 2019]:
Diskussion und Besprechung
Die einfachste Form, ein Thema zu behandeln, ist eine simple Besprechung. Alle Teilnehmer sitzen an einem Tisch und jeder soll sich zum Thema äußern. Ein Moderator achtet darauf, dass sich alle einbringen, dass die Diskussion beim Thema bleibt, und protokolliert die Ergebnisse.
Interview und Fragebogen
Ein Interview ist eine mehr oder weniger strukturierte mündliche Befragung. Interviews können eingesetzt werden, wenn ein Thema mit einzelnen Personen im Detail beleuchtet oder die Meinungen verschiedener Personen unabhängig voneinander eingeholt und verglichen werden sollen. Ein Beispiel für den Einsatz von Interviews als Ergänzung zu Workshops ist die Detailausarbeitung von Anwendungsfällen, wie in Abschnitt 11.4 beschrieben.
Ein Fragebogen ist eine schriftliche Befragung. Der große Vorteil dabei ist, dass er statistisch auswertbare und vergleichbare Ergebnisse von einer großen Menge an Personen möglich macht. Setzen Sie ihn immer dann ein, wenn Sie rasch viele Personen, z. B. potenzielle Anwender oder Kunden, zu einem klar definierten Thema befragen wollen.
Feldbeobachtung und »In die Lehre gehen«²
Bei der Feldbeobachtung sehen Sie sich als Requirements Engineer einen Ablauf in freier Wildbahn an. Daraus leiten Sie dann Anforderungen ab. Ein Beispiel für den Einsatz einer Feldbeobachtung als Ergänzung zu Workshops finden Sie in Abschnitt 9.3.
Das »In die Lehre gehen« geht eine Stufe weiter als die Feldbeobachtung. Hier sehen Sie nicht nur zu, sondern führen den Prozess selbst aus. Natürlich lernt man so am meisten über die Anforderungen an das neue System.
FMEA (Failure Mode and Effects Analysis)
Bei einer FMEA bewerten Sie für alle Komponenten eines Systems, welche Fehler auftreten können, welche Auswirkungen diese Fehler haben und wie oft sie auftreten werden. Dafür leitet man dann Gegenmaßnahmen ab. FMEA sind im sicherheitskritischen Bereich üblich und durch Normen gefordert [Spillner, A., Roßner, T., Winter, M. & Linz, T., 2014].
Systemarchäologie
Wenn man ein bestehendes Altsystem ablösen oder erweitern