Nichtfunktionale Anforderungen beschreiben, wie das System etwas leisten soll. Typische Kategorien hierfür sind:
Effizienz
Benutzbarkeit
Wartbarkeit
Sicherheit
Zuverlässigkeit
Übertragbarkeit
Kompatibilität
Meist werden sie einfach mit Text beschrieben. Beim International Requirements Engineering Board (IREB) werden die nichtfunktionalen Anforderungen auch Qualitätsanforderungen genannt.
RANDBEDINGUNGEN
Randbedingungen sind Festlegungen zu Beginn der Entwicklung, welche die Möglichkeiten der Anforderungen und der Umsetzung einschränken. Beispiele für Randbedingungen:
Vorgehensmodell (agil oder klassisch)
regulatorische Vorgaben wie Datenschutz oder Barrierefreiheit
Programmiersprache
Zeit und Budget
Randbedingungen werden vom IREB als dritte Anforderungsart neben funktionalen und Qualitätsanforderungen eingruppiert.
REQUIREMENTS ENGINEERING IN SCRUM
Alle bekannten Anforderungen sind im Product Backlog enthalten, beispielsweise als User Story.
Vorbereitungsphase: Produktvision entwickeln, Überblick über Anforderungen, nächstes Release planen, Product Backlog befüllen, ersten Sprint vorbereiten gemäß »Definition of Ready«
Sprint: Letzte Anforderungsdetails für die Umsetzung klären
Review: Fortschritt im Hinblick auf das Releaseziel begutachten und bei Bedarf Anforderungen anpassen und neue hinzufügen
Refinement: Anforderungen für den nächsten Sprint vorbereiten gemäß »Definition of Ready« und Anforderungen für nachfolgende Sprints grob vorbereiten
REQUIREMENTS ENGINEERING IN KLASSISCHEN PROJEKTEN
Der generelle Ablauf in klassischen Projekten ist planbasiert und lässt sich mit einem Wasserfall vergleichen.
STAKEHOLDERANALYSE
Vorgehen:
Identifizieren Sie die Stakeholder.
Ermitteln Sie die Ziele und Interessen der Stakeholder.
Priorisieren Sie die Stakeholder.
Ermitteln Sie ergänzende Informationen wie Kontaktdaten, Erreichbarkeit und bei Gruppen den Ansprechpartner.
Entwickeln Sie Maßnahmen zur Einbindung der Stakeholder.
Wiederholen Sie die Stakeholderanalyse regelmäßig.
Priorisierung:
Typische Stakeholder:
Anwender
Kunden, intern oder extern
zuständige Fachabteilungen
Entwickler des abzulösenden Altsystems
Betriebsrat
Datenschutzbeauftragte
Unternehmensführung
Management
die Leute, die später Schulungen zum System durchführen sollen
die Leute, die später den Support übernehmen
Marketing oder Vertrieb
Umfeld der Organisation (Außenwahrnehmung)
ANWENDUNGSFÄLLE (USE CASES)
Anwendungsfälle helfen, die funktionalen Anforderungen zu beschreiben.
Anwendungsfälle beschreiben Verwendungen eines Systems. Beispiel: »Geld abheben« benennt eine Verwendung eines Geldautomaten.
Kein Anwendungsfall wäre »Als Kunde autorisieren«! Niemand geht zum Geldautomaten, nur um sich zu autorisieren.
Anwendungsfalldiagramme geben einen Überblick über die geplante Verwendung des Systems.
Beschreibung eines Anwendungsfalles
Name
Geld abheben
Kurzbeschreibung
Ein Bankkunde hebt Bargeld von seinem Konto ab. Dabei muss der Geldautomat ein generelles Tageslimit beachten.
Fachlicher Auslöser
Der Bankkunde benötigt Bargeld.
Fachliches Ergebnis
Der Bankkunde verfügt über Bargeld.
Beteiligte Akteure
Bankkunde, Autorisierungssystem
Vorbedingungen
Der Geldautomat verfügt über eine Mindestmenge Bargeld und hat eine Verbindung zum Autorisierungssystem.
Nachbedingungen
Jede Abhebung ist verbucht.
Essenzschritte
Bankkunde autorisieren
Geldbetrag auswählen
Bargeldbestand prüfen
Verfügungsrahmen prüfen
Auszahlung buchen
Geld auszahlen
NICHTFUNKTIONALE ANFORDERUNGEN ERMITTELN
Vorgehen:
Vorstellungen der Stakeholder zu den nichtfunktionalen Anforderungen unstrukturiert erheben.
Die Ergebnisse in einen Qualitätsbaum einordnen.
Den Qualitätsbaum nutzen, um weitere nichtfunktionale Anforderungen zu identifizieren.
Die nichtfunktionalen Anforderungen priorisieren.
Die wichtigsten nichtfunktionalen Anforderungen mittels Qualitätsszenarien konkretisieren und ergänzen.
Die Priorisierung im Lichte der Qualitätsszenarien noch einmal überprüfen.
Auswirkung auf die Architektur bewerten (durch Architekturverantwortliche).
Zuordnung der nichtfunktionalen Anforderungen zu den funktionalen.
Ausschnitt aus einem Qualitätsbaum mit Qualitätsszenarien:
USER STORIES ZERLEGEN
ÜBERBLICK ÜBER ERMITTLUNGSTECHNIKEN
Einordnung nach dem Kano-Modell
Geeignet für viele Stakeholder
Verteilte Stakeholder
Gemeinsam oder einzeln
Überblick oder Details
Top-Down oder Bottom-Up
Befragungstechniken
Interview
Basismerkmale: o
Leistungsmerkmale: +
Begeisterungsmerkmale: -
Einzelne Personen oder kleine Gruppen
Erhöhter Aufwand
Mit wenigen Stakeholdern
Überblick und Details
Top-Down-Vorgehen
Fragebogen
Basismerkmale: o
Leistungsmerkmale: +
Begeisterungsmerkmale: -
Für sehr große Anzahl an Stakeholdern
Gut geeignet
Mit einzelnen Stakeholdern
Überblick und Details
Top-Down-Vorgehen
Workshop
Basismerkmale: o
Leistungsmerkmale: +
Begeisterungsmerkmale: -
Für mittelgroße Gruppen
Erhöhter Aufwand
Stakeholder arbeiten gemeinsam
Überblick
Top-Down- und Bottom-Up-Vorgehen
Beobachtungstechniken
Feldbeobachtung
Basismerkmale: +
Leistungsmerkmale: o
Begeisterungsmerkmale: -
Für mittelgroße Gruppen
Erhöhter Aufwand
Mit einzelnen Stakeholdern
Details
Bottom-Up-Vorgehen
Apprenticing
Basismerkmale: +
Leistungsmerkmale: +
Begeisterungsmerkmale: -
Für wenige Stakeholder
Erhöhter Aufwand
Mit einzelnen Stakeholdern
Details
Bottom-Up-Vorgehen
Ohne Stakeholder
Systemarchäologie
Basismerkmale: +
Leistungsmerkmale: o
Begeisterungsmerkmale: -
—
—
—
Details
Bottom-Up-Vorgehen
Wiederverwendung
Basismerkmale: +
Leistungsmerkmale: +
Begeisterungsmerkmale: -
—
—
—
Überblick und Details
Top-Down-Vorgehen
Entwurfs- und Ideenfindungstechniken
Brainstorming
Basismerkmale: o
Leistungsmerkmale: o
Begeisterungsmerkmale: +
Für mittelgroße Gruppen
Erhöhter Aufwand
Stakeholder arbeiten gemeinsam
Grobe Ideen erarbeiten, nicht für Details
Top-Down-Vorgehen
Analogietechniken
Basismerkmale: o
Leistungsmerkmale: +
Begeisterungsmerkmale: +
Für mittelgroße Gruppen
Erhöhter Aufwand
Stakeholder arbeiten gemeinsam
Ideen erarbeiten, nicht für Details
Top-Down-Vorgehen
Perspektivwechsel
Basismerkmale: o
Leistungsmerkmale: +
Begeisterungsmerkmale: +
Für mittelgroße Gruppen
Erhöhter Aufwand
Stakeholder arbeiten gemeinsam
Ideen erarbeiten, nicht für Details
Top-Down-Vorgehen
Design Thinking
Basismerkmale: o
Leistungsmerkmale: +
Begeisterungsmerkmale: +
Für mittelgroße Gruppen
Erhöhter Aufwand
Stakeholder arbeiten gemeinsam
Ideen erarbeiten und prüfen, nicht für Details
Top-Down-Vorgehen
Requirements Engineering für Dummies
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Wiley, the Wiley logo, Für Dummies, the Dummies Man logo, and related trademarks and trade dress are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries. Used by permission.
Wiley, die Bezeichnung »Für Dummies«, das Dummies-Mann-Logo und darauf bezogene Gestaltungen sind Marken oder eingetragene Marken von John Wiley & Sons, Inc., USA, Deutschland und in anderen Ländern.
Das vorliegende Werk wurde sorgfältig erarbeitet. Dennoch übernehmen Autoren und Verlag für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie eventuelle Druckfehler keine Haftung.
Marcus Winteroll studierte Philosophie in Hamburg mit Informatik und Linguistik als Nebenfächern. Anschließend promovierte er im Graduiertenkolleg »Kognitionswissenschaften« an der Universität Hamburg. Bereits neben dem Studium arbeitete er als Entwickler für einen bekannten internationalen Konzern. Nach der Promotion machte er die Arbeit rund um die Software zu seinem Hauptberuf und ging zunächst als Entwickler nach Frankfurt am Main. Weitere Stationen dort waren Qualitätssicherung, Projektleiter und Prozessmanager. Das Thema »Requirements Engineering« begleitete ihn auf all diesen Stationen. Nachdem er bereits 2003 sein erstes agiles Projekt durchführte, ließ ihn auch das Thema »Agilität« nicht mehr los.
2007 begann er als Trainer und Berater bei der oose Innovative Informatik in Hamburg und gründete gemeinsam mit einigen Kollegen 2014 die oose-Genossenschaft, die seitdem als selbstorganisiertes Unternehmen durch die Mitarbeiter geführt wird.
Er berät große und kleine Unternehmen aus allen Branchen und gibt Trainings zu den Themen »Requirements Engineering«, »Agilität« und »Geschäftsprozessmanagement«. Daneben ist er Dozent für die Masterlehrgänge »Software Engineering Leadership« und »Systems Engineering Leadership«. Auf Konferenzen ist er häufig mit Vorträgen vertreten und in Fachzeitschriften als Autor von Artikeln rund um das Thema Systementwicklung. Zudem arbeitet er bei der Standardisierungsorganisation »Object Management Group (OMG)« mit.
Einleitung
Wenn man ein System entwickeln möchte, ist es schon mal keine schlechte Idee, sich beizeiten mit der Frage zu beschäftigen, wozu das Ganze gut sein soll. Zumindest wenn man der Entwicklung eine Richtung geben und nicht nur so vor sich hin entwickeln möchte, von den Launen der Beteiligten mal in diese, mal in jene Richtung getrieben.
Es ist allerdings eine Herausforderung, die Frage nach dem Wozu schlüssig und zufriedenstellend zu beantworten. Das geht schon damit los, dass die Antwort verschiedene Ebenen hat: Wo liegt der Nutzen des Systems? Bei welchen Aufgaben soll es den Nutzern helfen? Wie muss es dafür beschaffen sein? Welche Vorgaben sind dabei einzuhalten? Und noch einiges mehr. Hinzu kommt: es ist meist gar nicht so einfach, an diese Informationen heranzukommen. Und dann erscheint das Ziel häufig auch noch allzu beweglich, sodass sich die Anforderungen immer wieder ändern.
Es ist also kein Wunder, dass sich eine ganze Disziplin um das Thema »Anforderungen« entwickelt hat, das Requirements Engineering. Aber kaum begann sich diese Disziplin zu etablieren, wurde sie auch gleich wieder herausgefordert durch das agile Vorgehen, das die Vorgehensweisen und Techniken des Requirements Engineering in Frage stellte. Auf der anderen Seite hat man dann auch in agilen Projekten festgestellt, dass es doch nicht so leicht ist, der vielfältigen Anforderungen mal so nebenbei Herr zu werden und dass Agilität allein auch nicht alle Probleme löst. Was ist also das richtige Vorgehen, welches sind die richtigen Techniken und was ist das richtige Maß an Requirements Engineering?
Über dieses Buch
Natürlich werden Sie in diesem Buch konkrete Vorgehensweisen und Techniken zum Requirements Engineering kennenlernen. Aber es geht hier auch darum, dass Sie beurteilen können, welches Vorgehen und welche Technik in welchem Kontext und in welcher Situation sinnvoll und effektiv sind. Denn die eine richtige Vorgehensweise gibt es nicht. Vielmehr müssen Sie als Requirements Engineer die spezifische Entwicklungssituation und das Umfeld berücksichtigen, um Techniken und Vorgehen darauf anzupassen. Hier gibt es so viele Möglichkeiten wie es unterschiedlichen Entwicklungsprozesse in der Praxis gibt – also gewissermaßen unendliche Welten.
Kurz: Sie lernen in diesem Buch viele bewährte Techniken und Vorgehensweisen kennen, aber Sie werden auch darin unterstützt, das richtige Beurteilungsvermögen über das angemessene Vorgehen zu entwickeln, egal ob Sie agil, klassisch oder sonst wie vorgehen.
Konventionen in diesem Buch
In der Praxis lässt sich das tatsächliche Vorgehen nicht immer klar unter agil oder klassisch einordnen. Darüber hinaus lassen sich viele Requirements-Engineering-Techniken im klassischen wie im agilen Vorgehen sinnvoll einsetzen. Daher trennt dieses Buch nicht strikt zwischen beiden Ansätzen. Wo es jedoch eindeutige Unterschiede gibt, wird selbstverständlich darauf eingegangen.
Was Sie nicht lesen müssen
Wenn Sie neu in das Thema »Requirements Engineering« einsteigen wollen, lesen Sie das Buch am besten einfach von vorne bis hinten – danach haben Sie einen guten Überblick. Und wenn Sie dann noch die Prüfung zum Certified Professional for Requirements Engineering – Foundation Level des International Requirements Engineering Board (IREB) in der aktuellen Version 3 anstreben, sind Sie auch darauf bestens vorbereitet.
Aber natürlich können Sie abhängig von Ihrem Vorwissen einzelne Abschnitte überspringen und sich auf die Themen konzentrieren, die Sie gerade interessieren. Die Kapitel sind so aufgebaut, dass sie jeweils für sich stehen; wobei ein gewisses Grundwissen meist vorausgesetzt wird, das Sie sich mithilfe des Buches aneignen können oder schon mitbringen. In dem Fall können Sie es auch als Nachschlagewerk nutzen: Mithilfe des Inhaltsverzeichnisses, des Stichwortverzeichnisses und der Querverweise können Sie die für Sie interessanten Inhalte direkt ansteuern, ohne das Buch von vorne bis hinten zu lesen beziehungsweise durchblättern zu müssen.
Törichte Annahmen über die Leser
Requirements-Engineering-Wissen müssen Sie nicht mitbringen, um dieses Buch zu verstehen, schließlich soll das Buch das ja vermitteln – nur neugierig auf das Thema müssten Sie sein. Vieles werden Sie aber besser einordnen können, wenn Sie bereits Erfahrungen in der Systementwicklung haben, egal ob Software- oder Hardwareentwicklung, egal in welcher Rolle, egal ob agil oder klassisch. Das Buch ist also genauso für Entwickler geeignet, die selbst Anforderungen erheben möchten, wie für Produktmanager, die ihre Anforderungen für das Entwicklungsteam besser strukturiert formulieren wollen.
Wie dieses Buch aufgebaut ist
Die Themen des Requirements Engineering sind in vier Teile gruppiert, die um den Top-Ten-Teil ergänzt werden.
Teil I: Requirements Engineering verstehen
Zunächst geht es darum, zu verstehen, wozu Requirements Engineering überhaupt gut ist, wer es macht und mit wem dabei zusammenzuarbeiten ist – welche Arten von Anforderungen es gibt. Zudem werden einige Fallstricke beschrieben. Ergänzend finden Sie in diesem Teil eine Übersicht über gängige Zertifizierungen.
Teil II: Vorgehen im Requirements Engineering
Wie der grundsätzliche Ablauf im Requirements Engineering aussieht, ist Thema im zweiten Teil. Hier unterscheidet sich natürlich das klassische vom agilen Vorgehen. Beides werden Sie dort kennenlernen. Letztlich müssen Sie aber Ihr Vorgehen an Ihr spezifisches Umfeld anpassen. Auch hierzu finden sie einige Hinweise.
Teil III: Anforderungsanalyse
Hier geht es um eine der zentralen Aufgaben des Requirements Engineering: Wie Sie an die Anforderungen herankommen. Dazu müssen Sie die Quellen für Anforderungen kennen, Sie benötigen Techniken, um Anforderungen zu ermitteln, und andere Techniken, um die Anforderungen besser zu verstehen und festzuhalten. Ergänzend hierzu werden Verfahren vorgestellt, mit denen Sie die Anforderungen auf ihre Eignung prüfen können, und erklärt, wie sie sich dokumentieren lassen.
Teil IV: Requirements Management
Anforderungen müssen auch organisiert werden. Wie das funktioniert, ist Thema dieses Teils. Am Ende erfahren Sie auch, inwieweit elektronische Werkzeuge Sie bei dieser Aufgabe unterstützen können und wo deren Grenzen liegen.
Teil V: Der Top-Ten-Teil
Der Top-Ten-Teil stellt Ihnen zehn grundlegende Prinzipien des Requirements Engineering vor. Dazu erfahren Sie, was alles zum Scheitern Ihres Projekts beitragen kann. Zu guter Letzt finden Sie dort zehn interessante Quellen zum Thema »Requirements Engineering«, auf die Sie einfach über das Internet zugreifen können.
Symbole, die in diesem Buch verwendet werden
Um bestimmte Informationen hervorzuheben, werden in diesem Buch die folgenden Symbole eingesetzt:
Dieses Symbol hebt Hinweise hervor, die für Ihre Arbeit als Requirements Engineer oder für das grundsätzliche Verständnis besonders hilfreich sind.
Mit diesem Symbol wird auf Zusammenhänge verwiesen, die bereits an einer früheren Stelle des Buches erklärt wurden. Manchmal wird auch nur daran erinnert, was einem der gesunde Menschenverstand ohnehin sagt.
Hier geht es um mögliche Stolpersteine im Requirements Engineering. Wenn sie diese Hinweise beherzigen, könnte Ihnen dadurch das eine oder andere Problem oder Missverständnis erspart bleiben.
Informationen, die eher zur Vertiefung dienen und nicht unbedingt für das grundlegende Verständnis notwendig sind, werden mit diesem Symbol gekennzeichnet.
Wie es weitergeht
Wenn Sie alles über Requirements Engineering wissen wollen, fangen Sie einfach mit dem ersten Teil an und bauen Ihr Wissen Kapitel für Kapitel auf. Wenn Sie selektiver vorgehen möchten, lassen Sie sich von den Themen im Inhaltsverzeichnis inspirieren und springen einfach an die Stelle, die Sie gerade am meisten interessiert – oder Sie lassen sich von Ihren Fragen entlang der vielen Querverweise durch die Themenpalette treiben.