Systematisches Requirements Engineering (eBook)

Anforderungen ermitteln, dokumentieren, analysieren und verwalten

Christof Ebert (Autor)

eBook Download: EPUB

2019 | 6. Auflage
496 Seiten
dpunkt (Verlag)
978-3-96088-453-8 (ISBN)

Infos

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 neues 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 6. Auflage vertieft Themen wie agile Entwicklung, Design Thinking, verteilt arbeitende Teams sowie Soft Skills. Der gesamte Inhalt, insbesondere Vorlagen, Werkzeuge, Checklisten, Praxistipps und das durchgängige Beispiel wurden überarbeitet. Alle Templates sind online verfügbar. Das Buch berücksichtigt den aktuellen Lehrplan des IREB®-Zertifizierungsprogramms. '... ein hervorragendes Buch für den praxisnahen Einstieg in die vielschichtigen Themenkomplexe der Anforderungsanalyse und des Anforderungsmanagements.' Chip.de zur 2. Auflage

Christof Ebert ist Geschäftsführer der Vector Consulting Services. Zuvor war er zwölf Jahre in Führungsaufgaben bei einem IT-Marktführer tätig, zuletzt mit weltweiter Verantwortung für Softwareplattformen. Er arbeitet in verschiedenen industriellen Boards und Aufsichtsgremien, ist Professor an der Universität Stuttgart sowie an der Sorbonne in Paris und Autor mehrerer Bücher. Seit vielen Jahren ist er in den Herausgeberkomitees von führenden Zeitschriften wie 'IEEE Software' und 'Journal of Systems and Software'.

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.

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 unmöglich oder 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 Features 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, dass man mit wertorientiertem Requirements Engineering aus Träumen 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 noch etwas weglassen? Ein Produkt war für ihn erst gut genug, wenn jede Funktion 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.

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 beziehungsweise 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 adressieren gerade auch solche Änderungen und nicht nur Projekte und Produkte auf der »grünen Wiese«. Änderungen verlangen eine genaue Abstimmung der Bedürfnisse und Nutzen mit den jeweiligen Zielgruppen oder Marktsegmenten. Häufig realisieren wir Funktionen oder Änderungen, die interessant scheinen, deren Markt aber zu klein ist. Hier ist eine Priorisierung aus betriebswirtschaftlicher Sicht wichtig.

Marktanforderungen sind Bestandteil von Verträgen, Entwicklungsaufträgen, Projektplänen, Teststrategien etc. Sie dienen als Basis für Abschätzung, Planung, Durchführung und Nachverfolgung der Projekttätigkeiten. Sie sind in der Sprache und im Kontext des Kunden formuliert. Wenn wir bei der Ermittlung der Marktanforderungen nicht aufpassen, haben wir die gleichen Schwierigkeiten, mit denen auch Eltern sich auseinandersetzen müssen, die einen Wunschzettel ihres Sprösslings in der Hand halten (Abb. 2-1). Es gibt...

Produkt-Details

• Erscheint lt. Verlag: 23.1.2019
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Themenwelt: Wirtschaft ► Betriebswirtschaft / Management ► Projektmanagement
• Schlagworte: Agile RE • agiles Requirements Engineering • Anforderungsmanagement • Certified Professional Requirements Engineer • CPRE • IREB • Projektmanagement • RE@Agile • requirements management • Software engineering • Software- und Systementwicklung
• ISBN-10: 3-96088-453-2 / 3960884532
• ISBN-13: 978-3-96088-453-8 / 9783960884538