Systematisches Requirements Engineering (eBook)

Anforderungen ermitteln, dokumentieren, analysieren und verwalten

Christof Ebert (Autor)

eBook Download: EPUB

2022 | 7. Auflage
478 Seiten
dpunkt (Verlag)
978-3-96910-769-0 (ISBN)

Infos

Das umfassende Handbuch zum Requirements Engineering

• eingeführtes Standardwerk nun in 7. Auflage!
• hoher Praxisbezug
• direkt anwendbare Checklisten und Praxistipps

Dieses Buch beschreibt praxisorientiert und systematisch das Requirements Engineering vom Konzept über Analyse und Realisierung bis zur Wartung und Evolution eines Produkts.

Requirements Engineering mit seinen Methoden, Modellen, Notationen und Werkzeugen wird eingeführt. Ein durchgängiges Beispiel sowie viele industrielle Praxiserfahrungen illustrieren die Umsetzung. Direkt anwendbare Checklisten und Praxistipps runden jedes Kapitel ab. Lesen Sie das Buch, um

- Requirements Engineering kennenzulernen,
- Ihre Projekte und Produkte erfolgreich zu liefern,
- agile Entwicklung beispielsweise mit testorientierten Anforderungen umzusetzen,
- industrieerprobte Techniken des Requirements Engineering produktiv zu nutzen.

Diese 7. Auflage wurde in vielen Aspekten aktualisiert und berücksichtigt den aktuellen Lehrplan des IREB®-Zertifizierungsprogramms.

Christof Ebert ist Geschäftsführer von Vector Consulting Services. Er unterstützt Kunden bei Produktstrategie, Entwicklung und agiler Transformation und arbeitet in verschiedenen Aufsichtsgremien von Unternehmen. Zuvor war er zwölf Jahre bei einem IT Konzern in weltweiten Führungsaufgaben. Als Business Angel und Professor an der Universität Stuttgart und der Sorbonne in Paris stimuliert er Innovationen. Er wirkt in den Herausgeber-Komitees von Zeitschriften wie IEEE Software und dem Journal of Systems and Software. In seiner Freizeit spielt er als Musiker Keyboards und engagiert sich im sozialen Bereich. Folgen Sie ihm auf Twitter: @ChristofEbert Kontakt: [e-mail], www.christofebert.de Homepage des Buches: www.vector.com/RE-Buch

Textauszug

2Requirements Engineering – kurz und knapp

Ihr Nutzen aus diesem Kapitel:

»It isn’t that they can’t see the solution. It is that they can’t see the problem.« Der berühmte Autor Gilbert Keith Chesterton adressierte damit eine wesentliche Herausforderung. Requirements Engineering identifiziert systematisch Probleme und Ziele – bevor Lösungen vorschnell entwickelt werden. Was sollten Sie für die eigene Praxis direkt übernehmen? Welche Faustregeln helfen, um das Requirements Engineering richtig zu justieren? Worauf sollten Sie in Ihren Projekten achten? In diesem Kapitel fasse ich kurz die wichtigsten Gesetzmäßigkeiten des Requirements Engineering zusammen. Systematik heißt nicht Formalismus oder gar Dogmatismus, sondern muss sich pragmatisch auf vorliegende Probleme einstellen. Zunehmend arbeiten wir im RE agil, also flexibel und situativ. Daher zeige ich hier die Essenz des Requirements Engineering. Sie lernen, was Anforderungen sind, wie verschiedene Typen von Anforderungen ganz verschieden auf das Projekt wirken und wie Sie Requirements Engineering leben können. Ein durchgängiges Beispiel transportiert das Vorgehen immer wieder in der Praxis.

2.1Was ist eine Anforderung?

Eine Anforderung beschreibt, was der Kunde oder Benutzer vom Produkt erwartet, also Bedingungen, Attribute, Ziele und vor allem Nutzen. Anforderungen sind definiert als:

• Eine Eigenschaft oder Bedingung, die von einem Benutzer (Person oder System) zur Lösung eines Problems oder zur Erreichung eines Ziels benötigt wird.
• Eine Eigenschaft oder Bedingung, die ein System oder eine Systemkomponente erfüllen muss, um einen Vertrag, eine Norm oder andere, formell vorgegebene Dokumente zu erfüllen.
• Eine dokumentierte Repräsentation einer Eigenschaft oder Bedingung wie in den ersten beiden Punkten beschrieben.

Wenn wir hier von Produkt sprechen, umfasst dies Anwendungen, IT-Systeme, eingebettete Software bis hin zu großen IT-Lösungen. Auch Dienstleistungen sind Produkte. Die Benutzer oder Anwender des Produkts sind diejenigen, die nach der Auslieferung damit in irgendeiner Form in Berührung kommen. Wir wollen dieses »in Berührung kommen« später nochmals aufgreifen (siehe Kap. 3), denn es ist bei der Ermittlung von Anforderungen wichtig, hier die Basis nicht zu sehr einzuschränken. Beispielsweise ist es relevant, zu unterscheiden, wer exakt Kunde ist (also vertraglich in die Entstehung eingebunden ist und dafür bezahlt) und wer das Produkt später nutzt.

Wert ist, wofür ein Kunde zahlt, und keine lange Funktionsliste. RE fokussiert Anforderungen auf den zu liefernden Wert und erreichbare Ziele. Anforderungen können mehrdeutig sein, sie können überspezifiziert sein, sie können unvollständig sein, sie können kontextspezifisch sein, sie können sich widersprechen, sie können nicht machbar oder schlichtweg falsch sein. In aller Regel jedoch sind es zu viele, um unter gegebenen Randbedingungen realisiert werden zu können. Das kommt deutlich am Beispiel eines Wunschzettels zum Ausdruck (Abb. 2–1).

Abb. 2–1Anforderungen sind der »Wunschzettel« des Kunden.

Das Problem in vielen Unternehmen ist, dass zu oft Funktionen und zu selten Träume adressiert werden. Als Ingenieure sind wir darauf geeicht, Lösungen zu finden. Wir definieren Funktionen und implementieren sie. Allerdings führen solche – angenommenen – Lösungen nicht immer zum Markterfolg und zu zufriedenen Kunden. Das überrascht uns, wo doch die Lösung so viele interessante Funktionen hat. Aber hatten wir wirklich ein Problem und einen Bedarf adressiert? Werden durch unser Produkt eine Vision und ein Traum wahr oder ersticken die Benutzer in Komplexität?

Wir stürzen uns viel zu schnell auf eine Lösung, weil es das ist, was wir dank Ausbildung und unter Projektdruck als Ergebnis sehen wollen. Ein Projekt, das von einer – angenommenen – Lösung aus startet, führt dazu, dass man einer Fata Morgana nachläuft, die sich ständig ändert. Wenn es uns gelingt, die Ziele und Anforderungen zu verstehen und systematisch umzusetzen, dann können wir jedes Projekt beherrschen.

Ein Produkt ist dann erfolgreich, wenn es den Bedürfnissen seiner Benutzer und seiner Umgebung gerecht wird. Anforderungen kommunizieren diese Bedürfnisse, und Requirements Engineering ist die Disziplin, die die Behandlung von Anforderungen über den gesamten Lebenszyklus des Produkts hinweg umfasst.

Beispiel:

Apple unter Steve Jobs zeigte, wie man mit wertorientiertem Requirements Engineering hervorragende Produkte macht. Steve Jobs gelang es, Träume zu verkaufen und diese Träume in Funktionen zu übersetzen. Er schockierte seine Ingenieure regelmäßig mit der einfachen Frage: Kann man im Design noch etwas weglassen? Unnötige Funktionen sind Ballast und verursachen Kosten im gesamten Lebenszyklus. Ein Produkt war für Steve Jobs erst gut genug, wenn jede Funktion einen Wert lieferte – und die Komplexität auf ein Minimum reduziert war.

Wir trennen daher klar zwischen Anforderung und Lösung. Eine Anforderung beschreibt ein Bedürfnis oder einen Nutzen, der erreicht werden soll. Sie beschreibt nicht, wie dieser Nutzen zu realisieren ist. Diese Implementierungssicht wird durch die Lösung beschrieben. Abbildung 2–2 veranschaulicht diesen Unterschied durch die Trennung zwischen Problemraum (oberer Teil: Marktanforderungen, Lastenheft etc.) und Lösungsraum (unterer Teil: Lösungsspezifikation, Pflichtenheft, Design, Fachkonzept etc.). Der Problemraum ist zunächst immer nur unscharf umrissen und wird im Verlauf der Lösungskonzeption eingeschränkt. Wert existiert nur im Auge des Betrachters. Daher sind Lösungen oftmals am erfolgreichsten, wenn sie nicht alle Anforderungen des Kunden adressieren. Der Erfinder und Unternehmer Henry Ford hat das früh begriffen und festgestellt: »Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie gesagt: schnellere Pferde.« Steve Jobs hat Apple damit erfolgreich gemacht, dass er innovative Lösungen lieferte und Altlasten rigoros hinterfragt und reduziert hat. Legendär sind die frühen iPhone-Telefone, die zwar kaum telefonieren konnten, aber sich hervorragend verkauften, weil sie ganz andere neue Bedürfnisse adressierten.

Abb. 2–2Anforderungen und Lösungen

Es gibt nicht die »Anforderung« schlechthin. Zu einer Anforderung gehört immer die Perspektive, aus der sie beschrieben wird. Eine Anforderung ist eine Bedingung oder eine Fähigkeit, die ein Benutzer benötigt, um ein Problem zu lösen oder um ein Ziel zu erreichen. Das heißt, sie hängt von der Perspektive ab. Ein Benutzer kann der Kunde sein, der für die Lösung bezahlt, aber es kann auch ein Entwickler sein, der daraus eine Architektur ableitet. Entsprechend unterschiedlich sind die Schwerpunkte und Inhalte, die durch diese Anforderung beschrieben werden. Was dem einen die Anforderung ist, ist dem anderen die Lösung. Man trennt daher in der Praxis unterschiedliche Arten von »Anforderungen«, beispielsweise Marktanforderungen oder Komponentenanforderungen, und vermeidet, von einer »Anforderung« ohne Präzisierung zu sprechen.

2.2Perspektiven: vom Markt zur Realisierung

Drei verschiedene Sichten auf Anforderungen werden im Laufe der Lösungskonzeption unterschieden (Abb. 2–2):

• Marktanforderungen
• Produktanforderungen
• Komponentenanforderungen

Diese drei Sichten entstehen durch Verfeinerung bzw. Abstraktion. Offensichtlich ist diese Dreiteilung rekursiv: Eine Komponentenanforderung an einen Lieferanten ist dort wiederum eine Marktanforderung.

Marktanforderungen

Marktanforderungen beschreiben Anforderungen an ein Produkt aus der Sicht des Kunden. Sie werden daher oft auch als Kunden-, Benutzer- oder Geschäftsanforderungen oder als Bedürfnisse bezeichnet. Sie beschreiben den Nutzen und die Erfahrungen mit dem Produkt in der Sprache des Kunden oder Benutzers, also warum ein Projekt überhaupt durchgeführt wird. Einziger Maßstab an Wert und Erfüllungsgrad ist daher die Wahrnehmung oder Spezifikation des Kunden. Marktanforderungen werden im Lastenheft dokumentiert.

Beispiel:

Marktanforderung_1:

Der Datentransfer muss geschützt erfolgen, um Missbrauch zu verhindern.

Viele Projekte umfassen Änderungen an Bestehendem. Marktanforderungen...

Produkt-Details

• Erscheint lt. Verlag: 27.8.2022
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik ► Software Entwicklung
• Schlagworte: Agile RE • Anforderungsmanagement • Certified Professional Requirements Engineer • CPRE • IREB • Projektmanagement • RE@Agile • requirements management • Software engineering • Software- und Systementwicklung
• ISBN-10: 3-96910-769-5 / 3969107695
• ISBN-13: 978-3-96910-769-0 / 9783969107690