Basiswissen Requirements Engineering E-Book

Klaus Pohl

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: Basiswissen
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 291

Beschreibung

Kompaktes Grundlagenwerk für den Requirements Engineer

• Standardwerk in 5. Auflage
• konform zum IREB-Lehrplan Version 3.0
• mit interaktiven Elementen: animierte Grafiken, Videos

Dieses Lehrbuch umfasst den erforderlichen Stoff zum Ablegen der Prüfung "Certified Professional for Requirements Engineering (Foundation Level)" nach IREB-Standard. Es vermittelt das Grundlagenwissen und behandelt die wesentlichen Prinzipien und Praktiken sowie wichtige Begriffe und Konzepte. Die Themen im Einzelnen:

- Grundlegende Prinzipien des Requirements Engineering
- Arbeitsprodukte und Dokumentationspraktiken
- Praktiken für die Erarbeitung von Anforderungen
- Prozess und Arbeitsstruktur
- Praktiken für das Requirements Management
- Werkzeugunterstützung

Das Buch eignet sich gleichermaßen für das Selbststudium, zur Vorbereitung auf die Zertifizierung sowie als kompaktes Basiswerk zum Thema in der Praxis und an Hochschulen.

Die 5. Auflage wurde komplett überarbeitet, ist konform zum IREB-Lehrplan Foundation Level Version 3.0 und wurde angereichert mit interaktiven Elementen wie animierte Grafiken und Videos.

Leseprobe

Prof. Dr. Klaus Pohl leitet die Forschungsgruppe Software Systems Engineering an der Universität Duisburg-Essen und ist geschäftsführender Direktor von paluno – The Ruhr Institute for Software Technology an der Uni DuE. Das Requirements Engineering zählt seit Anfang der 90er-Jahre zu seinen Forschungs- und Beratungsschwerpunkten. Er war der wissenschaftliche Gründungsdirektor von lero – The Irish Software Research Centre –, leitete zahlreiche Industrie- und Forschungsprojekte im Bereich Software Systems Engineering und ist (Co-)Autor von über 300 begutachteten Publikationen, darunter mehrere Bücher.

Chris Rupp ist OberSOPHISTin (formal: geschäftsführende Gesellschafterin). In 30 Jahren Berufstätigkeit sammelt sich so einiges an: ein Unternehmen, 6 Bücher, 55 Mitarbeiter und unheimlich viel Erfahrung. Meine Leidenschaft für die Projektberatung ist vermutlich schuld daran, dass ich bis heute nicht »nur« manage, sondern auch ganz nah am Kunden und an Innovationsprojekten dran bin und in Projekten mitarbeite. Gute Ideen so umzusetzen, dass alle Stakeholder das Gefühl haben, ein intelligentes und nutzbringendes Produkt vor sich zu haben, ist die Vision, die mich dabei antreibt. Mein Wissen teile ich gerne in Vorträgen, Büchern und Artikeln.

Klaus Pohl · Chris Rupp

BasiswissenRequirements Engineering

Aus- und Weiterbildung nach IREB-Standard zum Certified Professional for Requirements Engineering Foundation Level

5., überarbeitete und aktualisierte Auflage

Klaus Pohl · [email protected]

Chris Rupp · [email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Layout & Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

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.

ISBN:

Print        978-3-86490-814-9

PDF         978-3-96910-247-3

ePub       978-3-96910-245-9

mobi       978-3-96910-246-6

5., überarbeitete und aktualisierte Auflage 2021

Copyright © 2021 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Die Zertifizierung zum Certified Professional for Requirements Engineering (CPRE)

Im Jahre 2006 wurde das International Requirements Engineering Board (IREB e.V.) gegründet. Es setzt sich aus unabhängigen, weltweit anerkannten Expertinnen und Experten aus den Bereichen Industrie, Beratung, Forschung und Lehre zusammen. Die Mitglieder des Boards haben gemeinsam einen Lehrplan für den Bereich Requirements Engineering erarbeitet und ein darauf basierendes Zertifizierungsmodell zum CPRE (Certified Professional for Requirements Engineering), entwickelt. Ziel ist es, eine qualitätsgesicherte Standardisierung der Aus- und Weiterbildung im Requirements Engineering und damit letztlich eine breite Verbesserung der täglichen Requirements-Engineering-Praxis zu erreichen.

Seit 2007 haben über 70.000 Personen in 84 Ländern die Prüfung im CPRE Foundation Level abgelegt; davon waren über 55.000 Personen erfolgreich, d.h. wurden zertifiziert (Stand 12/2020). Am Zertifizierungsprozess sind vier Hauptakteure beteiligt: das International Requirements Engineering Board (IREB), die anerkannten Trainingsprovider, die Zertifizierungsstellen in den einzelnen Ländern und natürlich die Kursteilnehmer bzw. die zu prüfenden Personen. Abbildung 1 zeigt die Struktur und Aufgabenverteilung im Rahmen der Zertifizierung zum »Certified Professional for Requirements Engineering« (CPRE).

Abb. 1Struktur und Aufgabenverteilung bei der Zertifizierung zum CPRE

Das IREB erarbeitet den Lehrplan, erstellt die zugehörigen Prüfungsfragen, definiert und regelt das Prüfungsverfahren, beauftragt Zertifizierungsstellen mit der Prüfungsabnahme und listet anerkannte Trainingsprovider auf seiner Webseite, die Schulungsmaßnahmen zum »Certified Professional for Requirements Engineering« anbieten. In den einzelnen Ländern führen vom IREB beauftragte Zertifizierungsstellen die Prüfungen für das Zertifikat durch.

Formell besitzt der IREB-Lehrplan den gleichen Charakter wie die Lehrpläne anderer etablierter Aus- und Weiterbildungsstandards (z.B. ISTQB Certified Tester) und berücksichtigt dabei einschlägige internationale Normen der ISO und des IEEE. Der Lehrplan für den »Foundation Level« umfasst das Grundlagenwissen zum Requirements Engineering auf den Gebieten Ermittlung, Dokumentation, Prüfung und Verwaltung von Anforderungen. Der fachliche Inhalt des IREB-Zertifikats kann im öffentlich zugänglichen Lehrplan nachgelesen werden. Durch seinen Lehrplan gibt das IREB genau den Umfang, den Inhalt und die Zeit für die Erreichung der Lernziele sowie die Themen der praktischen Übungen vor. Des Weiteren sind auf den Internetseiten des IREB auch das vollständige aktuelle Glossar, ein Handbuch und nähere Informationen zu den Prüfungsmodalitäten nachschlagbar.

Weitere Informationen zum International Requirements Engineering Board (IREB e.V.) und zum »Certified Professional for Requirements Engineering« finden sich auf der Internetseite des IREB:

http://www.ireb.org

Vorwort

Liebe Leserin, lieber Leser,

mit diesem Buch halten Sie die nunmehr 5. Auflage des Lehrbuches für die Zertifizierung zum Certified Professional for Requirements Engineering – Foundation Level in Ihren Händen. Eine Übersicht über das IREB sowie die Zertifizierungsprozesse finden Sie im vorangehenden Abschnitt »Die Zertifizierung zum Certified Professional for Requirements Engineering (CPRE)«. Ergänzend zu diesem Buch sollten Sie die auf der Internetseite des IREB (http://www.ireb.org) veröffentlichten Informationen zur Vorbereitung auf die Zertifizierungsprüfung beachten.

Neuauflage: Signifikante Anpassungen!

Bei der 5. Auflage handelt es sich um eine signifikante Überarbeitung der bisherigen Auflagen. Dies hat u.a. folgende Gründe:

Neuer Lehrplan (Version 3.0) für IREB CPRE Foundation Level

Das International Requirements Engineering Board e.V. (IREB) hat 2020 einen signifikant überarbeiteten Lehrplan für den CPRE Foundation Level herausgebracht. Die 5. Auflage basiert auf diesem Lehrplan. Hierdurch hat sich unter anderem auch die Struktur des Buches geändert.

Erklärendes Beispiel

Die teilweise theoretischen Inhalte des Buches veranschaulichen wir mit einem Beispiel aus der Entwicklung eines Smart-Home-Systems (SHS) für die Familie Meyer. Eine Einführung in das Beispiel finden Sie nach dem Vorwort.

Videos

Ein Bild sagt mehr als tausend Worte. Wir haben daher für zentrale Sachverhalte erklärende Videos erstellt. Für diese Videos finden Sie an den entsprechenden Stellen im Buch einen Weblink. Einfach den auf den Link klicken und schon läuft das Video auf Ihrem Tablet, Handy oder PC. Oder Sie geben die Linkinformation in Ihren Browser ein und gelangen somit ebenfalls zum entsprechenden Video.

www.cpre-buch.de/pk1v1

Animierte GIFs

Neben den Videos haben wir animierte GIFs zur Erläuterung einiger Sachverhalte erstellt. Auch für die animierten GIFs finden Sie einen entsprechenden Link an den entsprechenden Stellen. Einfach darauf klicken oder den Link eingeben und schon läuft die Animation auf Ihrem Tablet, Handy oder PC.

www.cpre-buch.de/pk3a1

Kernfakten – Weblinks

Die Essenz eines jeweiligen Abschnitts haben wir als Kernfakten noch einmal kurz und prägnant zusammengefasst. Sie finden die entsprechenden Inhalte unter dem jeweils angegebenen Weblink. Die Weblinks bieten Ihnen auch die Möglichkeit, an Aktualisierungen des Buches teilzuhaben. Sobald sich signifikante, prüfungsrelevante Sachverhalte oder Wissenselemente ändern, finden Sie die aktuellste Information auf der entsprechenden Webseite, die verlinkt ist. Der Link hat folgende Form:

www.cpre-buch.de/pk1w1

Exkurs-Boxen

An zahlreichen Stellen haben wir Praxistipps und weiterführende Informationen zu einem Thema in sogenannten Exkurs-Boxen hinzugefügt. Sie erkennen eine Exkurs-Box anhand ihres Designs:

Exkurs: Beispiel Exkurs

Nützliche Praxistipps, wertvolle Hintergrundinformationen, vertiefendes Wissen

Ziel des Buches

Ziel des Buches ist es, Sie bei der Vorbereitung auf die Zertifizierungsprüfung zum »Certified Professional for Requirements Engineering« zu unterstützen. Wir hoffen, dass die oben genannten Neuerungen und signifikanten Überarbeitungen Sie dabei noch besser als bisher unterstützen. Das Buch eignet sich sowohl für Ihre individuelle Vorbereitung auf die Zertifizierungsprüfung als auch als Begleitliteratur zu den von den Trainingsprovidern angebotenen einschlägigen Vorbereitungsschulungen.

Grundlagen für dieses Buch

Unsere Entscheidung, dieses Buch gemeinsam zu verfassen, kam nicht von ungefähr. Mit dem vorliegenden Buch werden langjährige Praxiserfahrungen mit Lehr- und Forschungserkenntnissen zum Thema Requirements Engineering speziell für den Foundation Level des »Certified Professional for Requirements Engineering« zusammengeführt.

Das vorliegende Buch basiert auf den zwei folgenden Büchern zum Themengebiet »Requirements Engineering« der beiden Hauptautoren ([Rupp 2020], [Pohl 2010]).

Wir haben auf eine vollständige Referenzierung der beiden oben genannten Bücher in den Kapiteln dieses Buches weitgehend verzichtet. Zu den einzelnen, im vorliegenden Buch behandelten Themengebieten finden Sie in diesen beiden Büchern detaillierte, ergänzende und weiterführende Informationen.

Neben unseren beiden Büchern und Erfahrungen basiert der Inhalt dieses Buches auf dem IREB-CPRE-Lehrplan für Foundation Level 3.0 [IREB-Lehrplan 2020]. Für Begriffsdefinitionen stützen wir uns auf das IREB-Glossar [IREB-Glossar 2020] und zitieren dieses an entsprechenden Stellen. Eine weitere Quelle ist das IREB-Handbuch für den CPRE Foundation Level [IREB-Handbuch 2020], das wir selbstverständlich an den entsprechenden Stellen auch referenzieren – nicht jedoch an den Stellen, an denen das Handbuch auf den Inhalten der vorherigen Auflagen dieses Buches basiert.

Errata & Feedback

Wie bei jedem Buch, so wird auch dieses Buch einige unvermeidbare potenzielle Unverständlichkeiten oder sogar Fehler(chen) enthalten. Sie finden die Errata zu dieser Auflage unter www.cpre-buch.de/errata.

Ihr Feedback bzw. Ihre Rückfragen zu Inhalten zu diesem Buch können Sie uns über www.cpre-buch.de/feedback mitteilen.

Danksagungen für bisherige Auflagen

Neben den vielen Neuerungen basiert diese Auflage selbstverständlich auch auf den vorausgegangenen Auflagen dieses Buches. Für die Unterstützung bei der Erstellung dieser Auflagen möchten wir uns noch einmal bei den Mitgliedern des IREB für ihre damalige Mitarbeit bedanken. Namentlich sind dies: Karol Frühauf, Emmerich Fuchs (†), Prof. Dr. Martin Glinz, Rainer Grau, Colin Hood, Dr. Frank Houdek, Dr. Peter Hruschka, Prof. Dr. Barbara Paech, Dirk Schüpferling und Dr. Thorsten Weyer. Darüber hinaus haben Rainer Joppich, Dr. Kim Lauenroth, Urte Pautz, Christian Pikalek, Nelufar Ulfat-Bunyadi, Philipp Schmidt und Dr. Bastian Tenbergen zu den vorherigen Auflagen beigetragen.

Danksagungen für die aktuelle Auflage

Auch bei dieser Ihnen vorliegenden Auflage hatten wir viel Unterstützung erhalten. Unser besonderer Dank gilt Dr. Marian Daun, Christof Martin, Dr. Stefan Queins, Alexander Rauh und Dr. Thorsten Weyer für deren inhaltliche Beiträge und das unermüdliche Engagement, ohne das die Erstellung dieses Buches nicht möglich gewesen wäre. Bedanken möchten wir uns zudem für die Unterstützung bezüglich der Integration, des Layouts und des Reviews bei Patricia Aluko Obe, Roland Kluge, Sebastian Fickert, Birgit Kremer, David Nawzad und Simon Tegethoff.

Ein herzliches Dankeschön für die tatkräftige Unterstützung geht an Christa Preisendanz vom dpunkt.verlag sowie an die Lektorin Ursula Zimpfer.

Klaus Pohl und Chris RuppEssen und Nürnberg, im Dezember 2020

Unter Mitwirkung von

Dr. Marian Daun arbeitet als wissenschaftlicher Assistent an der Universität Duisburg-Essen. Er forscht und lehrt seit über 10 Jahren im Bereich Requirements Engineering. Seine Schwerpunkte liegen in der modellbasierten Spezifikation und der Validierung von Anforderungen. Marian Daun ist Co-Autor von über 80 begutachteten wissenschaftlichen Publikationen. Er ist als Gutachter, Programmkomiteemitglied und -vorsitzender für international angesehene Konferenzen und Fachzeitschriften tätig.

Christof Martin ist seit mehr als fünf Jahren Berater bei der SOPHIST GmbH und begleitet deren Kunden rund um das Thema Requirements Engineering. Dabei kann er auf zahlreiche Erfahrungen aus erfolgreichen Systems-Engineering- und agilen Projekten zurückgreifen. Er verfolgt dabei stets das Ziel, den Menschen möglichst praxisnahes Wissen zu vermitteln, um ihnen die Arbeit zu erleichtern. Christof ist außerdem Co-Autor der 7. Auflage des Buches Requirements-Engineering und -Management.

Dr. Stefan Queins ist seit mehr als 15 Jahren Berater und Trainer bei der SOPHIST GmbH. Seine Schwerpunkte liegen in der Anpassung von Produktentwicklungsprozessen und in der modellbasierten Systementwicklung. Stefan ist Co-Autor des Buches UML 2 glasklar und Gründungsmitglied der Arbeitsgruppe CPRE Advanced Level Requirements Modeling des IREB.

Alexander Rauh arbeitet seit mehr als sieben Jahren als Berater und Trainer für die SOPHIST GmbH. Als Berater definiert Alexander Entwicklungsprozesse für die Systementwicklung in unterschiedlichen technischen Bereichen und unterstützt die Kunden von SOPHIST bei der Einführung dieser Prozesse. Als Trainer vermittelt er Wissen im Bereich des Systems Engineering mit den Schwerpunkten der modellbasierten Dokumentation von Anforderungen und Architektur. Außerdem ist Alexander Trainer für die Inhalte des IREB-Lehrplans für den CPRE Advanced Level Requirements Modeling.

Dr. Thorsten Weyer leitete von 2011 bis 2020 die Gruppe »Requirements Engineering und konzeptueller Entwurf« bei paluno – The Ruhr Institute for Software Technology. Er ist Mitglied im IREB e.V. und leitet dort die Arbeitsgruppe »Requirements Modeling«. Von 2015 bis 2019 war er darüber hinaus stellvertretender Vorsitzender des IREBBeirats. Dr. Thorsten Weyer ist aktuell als Systemarchitekt bei der Schaeffler AG tätig (mehr zur Person unter: www.thorsten-weyer.de).

Unsere Familie Meyer

Um die Inhalte des vorliegenden Buches für Sie nachvollziehbarer zu machen, haben wir die teils theoretischen Inhalte mit Beispielen hinterlegt. Diese beziehen sich auf die Entwicklung eines Smart-Home-Systems (SHS), das hier kurz eingeführt werden soll.

Familie Meyer möchte mehr Zeit für sich haben und plant deswegen, ihr Haus zu einem Smart Home aufzurüsten. Robert Meyer, seine Frau Lina und ihre Tochter Johanna haben viel diskutiert, um herauszufinden, was denn in ihrem neuen Zuhause für sie wichtig ist. Schnell hat sich herausgestellt, dass die Sicherheit ein großes Thema ist. Aber sie möchten nicht nur eine konventionelle Alarmanlage installieren. Ihr Haus soll mehr können. Sie stellen sich z. B. die Frage, wie das Haus zuverlässig erkennen kann, ob ein Einbrecher im Haus ist oder doch nur Robert nachts den Kühlschrank plündern will. Und kann das Haus im Ernstfall nicht direkt die Polizei benachrichtigen?

Ein weiteres wichtiges Thema für sie ist der Zugang zu ihrem Haus. So wollen Lina und Robert vermeiden, mit vollen Einkaufstaschen bepackt nach ihrem Haustürschlüssel suchen zu müssen. Auch ihre Kinderbetreuung und der Vater von Robert sollen einen personalisierten Zugang zu dem Haus erhalten.

Aber die Liste geht noch weiter. Klima- und Lichtsteuerung sollten doch machbar sein. Und können sie nicht noch mehr Energiekosten einsparen? Da die Anschaffung eines Elektroautos ansteht, könnte man doch eine Photovoltaik-Anlage installieren?

Mit diesen und vielen weiteren Ideen und Wünschen gehen Lina und Robert zur Firma Schlauhaus, die ihnen ihr Haus aufrüsten soll. Doch zunächst wollen Lina und Robert natürlich wissen, was denn alles im Rahmen ihres Budgets realisierbar ist, was sie eventuell vergessen haben und welche tollen Überraschungen die Firma Schlauhaus für sie bereithält.

Man kann der Familie Meyer nur wünschen, dass die Firma Schlauhaus das vorliegende Buch gelesen hat, weil deren erste Aufgabe darin besteht, das zu tun, was wir als Requirements Engineering bezeichnen.

Inhaltsübersicht

1 Einleitung und Grundlagen

2 Grundlegende Prinzipien des Requirements Engineering

3 Arbeitsergebnisse und Dokumentationspraktiken

4 Praktiken für die Erarbeitung von Anforderungen

5 Prozess und Arbeitsstruktur

6 Praktiken für das Requirements Management

7 Werkzeugunterstützung

Anhang

Videoverzeichnis

Animationsverzeichnis

Kernfaktenverzeichnis

Literatur

Index

Inhaltsverzeichnis

1 Einleitung und Grundlagen

1.1 Requirements Engineering – Was?

Exkurs: Qualitätsanforderungen

Exkurs: Randbedingungen (Constraints)

1.2 Requirements Engineering – Warum?

Exkurs: Kommunikationsprobleme

1.3 Requirements Engineering – Wo?

Exkurs: Ziele und Szenarien

1.4 Requirements Engineering – Wie?

1.5 Die Rolle und Aufgaben eines Requirements Engineer

Exkurs: Persönlichkeitsprofil eines Requirements Engineer

1.6 Was über Requirements Engineering zu lernen ist

2 Grundlegende Prinzipien des Requirements Engineering

2.1 Neun grundlegende Prinzipien

2.1.1 Prinzip 1: Wertorientierung – Anforderungen sind Mittel zum Zweck, kein Selbstzweck

Exkurs: Anforderungen sind kein Selbstzweck

2.1.2 Prinzip 2: Stakeholder – Im Requirements Engineering geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen

2.1.3 Prinzip 3: Gemeinsames Verständnis – Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich

Exkurs: Wichtige Anforderungsquellen zusätzlich zu Stakeholdern

Exkurs: Gemeinsames Verständnis schaffen

2.1.4 Prinzip 4: Kontext – Systeme können nicht isoliert verstanden werden

Exkurs: Probleme mit getrennter Umfang-(Scope-)Abgrenzung

2.1.5 Prinzip 5: Problem · Anforderung · Lösung – Ein unausweichlich ineinandergreifendes Tripel

Exkurs: Twin-Peaks-Modell

2.1.6 Prinzip 6: Validierung – Nicht validierte Anforderungen sind nutzlos

Exkurs: Validierung

2.1.7 Prinzip 7: Evolution – Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall

Exkurs: Änderungen vs. Stabilität

2.1.8 Prinzip 8: Innovation – Mehr vom Gleichen ist nicht genug

2.1.9 Prinzip 9: Systematische und disziplinierte Arbeit – im Requirements Engineering unverzichtbar

Exkurs: Auswahl von Praktiken und Techniken

2.2 System und Kontextabgrenzung

2.2.1 Systemkontext

2.2.2 System- und Kontextgrenzen bestimmen

Exkurs: Dokumentation des Systemkontexts

3 Arbeitsergebnisse und Dokumentationspraktiken

3.1 Arbeitsergebnisse im Requirements Engineering

3.1.1 Merkmale von Arbeitsergebnissen

3.1.2 Kategorien und Abstraktionsebenen

3.1.3 Detaillierungsgrad von Anforderungen

3.1.4 Aspekte von Arbeitsergebnissen

3.1.5 Allgemeine Dokumentationsrichtlinien

3.1.6 Planung der zu verwendenden Arbeitsergebnisse

3.2 Natürlichsprachige Arbeitsergebnisse

Exkurs: Sprachliche Effekte durch Transformation

3.2.1 Dokumentationsrichtlinien für natürlichsprachige Anforderungen

3.2.2 Sprachliche Effekte, auf die zu achten ist

3.3 Vorlagenbasierte Arbeitsergebnisse

3.3.1 Satzschablonen

Exkurs: Schritt für Schritt zur Anforderung

3.3.2 Formularvorlagen

Exkurs: Vorlagenbasierte Spezifikation von Use Cases

3.3.3 Dokumentvorlagen

Exkurs: Standardisierte Dokumentvorlagen

3.4 Modellbasierte Arbeitsergebnisse

3.4.1 Die Rolle von Modellen im Requirements Engineering

Exkurs: Eigenschaften von Modellen

Exkurs: Modellierungssprachen

3.4.2 Kontextmodellierung

Exkurs: Zielmodellierung im Requirements Engineering

Exkurs: Kontextmodellierung mit SysML-Blockdiagrammen

3.4.3 Modellierung von Struktur und Daten

Exkurs: Fortgeschrittene Modellierung von Struktur und Daten

3.4.4 Modellierung von Funktion und Ablauf

Exkurs: Use-Case-Modelle und -Diagramme

3.4.5 Modellierung von Zustand und Verhalten

Exkurs: Fortgeschrittene Zustandsmaschinendiagramme

Exkurs: Integration der Perspektiven auf funktionale Anforderungen

3.5 Glossare

3.5.1 Grundlagen von Glossaren

3.5.2 Regeln für den Umgang mit einem Glossar

3.6 Dokumentationsstrukturen für Anforderungen

3.7 Prototypen im Requirements Engineering

3.7.1 Explorative Prototypen

3.7.2 Evolutionäre Prototypen

3.8 Qualitätskriterien für Arbeitsergebnisse und Anforderungen

3.8.1 Qualitätskriterien für einzelne Anforderungen

3.8.2 Qualitätskriterien für ein Menge von Anforderungen

4 Praktiken für die Erarbeitung von Anforderungen

4.1 Quellen für Anforderungen

4.1.1 Stakeholder und deren Bedeutung

4.1.2 Der Umgang mit Stakeholdern im Projekt

Exkurs: Personas

Exkurs: Stakeholder-Relationship-Management

4.1.3 Weitere Anforderungsquellen

4.2 Ermittlung von Anforderungen

4.2.1 Anforderungskategorisierung nach dem Kano-Modell

4.2.2 Arten von Ermittlungstechniken

4.2.2.1 Erhebungstechniken

Exkurs: Befragungstechniken

Exkurs: Kollaborationstechniken als Hilfstechniken

Exkurs: Beobachtungstechniken

4.2.2.2 Entwurfs- und Ideenfindungstechniken

Exkurs: Kreativitätstechniken

4.2.2.3 Auswahl der richtigen Ermittlungstechnik

Exkurs: Szenarien

4.3 Abstimmung und Konfliktlösung

4.3.1 Konfliktidentifikation

4.3.2 Konfliktanalyse

4.3.3 Konfliktlösung

4.3.4 Dokumentation der Konfliktlösung

4.4 Validieren von Anforderungen

4.4.1 Grundlagen der Validierung von Anforderungen

Exkurs: Qualitätsaspekte von Anforderungen

Exkurs: Qualitätsaspekt »Inhalt«

Exkurs: Qualitätsaspekt »Dokumentation«

4.4.2 Wichtige Aspekte der Anforderungsvalidierung

Exkurs: Qualitätsaspekt »Abgestimmtheit«

Exkurs: Auswahl der Validierer

4.4.3 Reviewtechniken zur Validierung von Anforderungen

4.4.3.1 Walkthrough

Exkurs: Konzentration auf Aufdeckung von Fehlern

Exkurs: Stellungnahme als Sonderfall

4.4.3.2 Inspektion

Exkurs: Rollen bei einer Inspektion

Exkurs: Assistenztechniken zur Unterstützung des Reviews

4.4.4 Explorationstechniken

4.4.4.1 Prüfung durch Prototypen

Exkurs: Durchführung einer Prüfung mittels Prototyping

4.4.4.2 Prüfung durch kontrollierte Experimente

4.4.4.3 Probe-Entwicklung (Konstruktion von Entwicklungsartefakten)

Exkurs: Wechsel der Dokumentationsform

5 Prozess und Arbeitsstruktur

5.1 Einflussfaktoren

5.1.1 Eignung des Gesamtprozesses

5.1.2 Entwicklungskontext

5.1.3 Fähigkeiten und Verfügbarkeit von Stakeholdern

5.1.4 Gemeinsames Verständnis

5.1.5 Komplexität und Kritikalität des zu entwickelnden Systems

5.1.6 Vorgegebene Randbedingungen

5.1.7 Verfügbare Zeit und Budget

5.1.8 Volatilität der Anforderungen

5.1.9 Erfahrungen des Requirements Engineer

5.2 Facetten der Requirements-Engineering-Prozesskonfiguration

5.2.1 Zeitfacette: linear versus iterativ

5.2.2 Zweckfacette: präskriptiv versus explorativ

5.2.3 Zielfacette: kundenspezifisch versus marktorientiert

5.2.4 Hinweis und Warnungen

5.3 Konfigurieren eines Requirements-Engineering-Prozesses

5.3.1 Partizipativer Requirements-Engineering-Prozess: iterativ, explorativ und kundenspezifisch

5.3.2 Vertraglich regulierter Requirements-Engineering-Prozess: typischerweise linear, präskriptiv und kundenspezifisch

5.3.3 Produktorientierter Requirements-Engineering-Prozess: iterativ, explorativ und marktorientiert

5.3.4 Weitere zu berücksichtigende Aspekte

6 Praktiken für das Requirements Management

6.1 Was ist Requirements Management?

6.2 Verwaltung des Lebenszyklus

6.3 Versionskontrolle

6.4 Konfigurationen und Basislinien

Exkurs: Dimensionen von Anforderungskonfigurationen

Exkurs: Basislinien

6.5 Attribute und Sichten

6.5.1 Attribuierung von natürlichsprachigen Anforderungen und Anforderungsmodellen

Exkurs: Attribuierungsschemata

6.5.2 Sichten auf Anforderungen

Exkurs: Selektive Sicht

Exkurs: Verdichtende Sicht

6.6 Verfolgbarkeit von Anforderungen

Exkurs: Nutzen und Arten der Verfolgbarkeit

6.6.1 Verwendungszweckbezogene Definition der Verfolgbarkeit

6.6.2 Repräsentation der Verfolgbarkeit

6.7 Umgang mit Änderungen

Exkurs: Change Control Board

Exkurs: Änderungsantrag für Anforderungen

6.8 Priorisierung von Anforderungen

6.8.1 Vorgehen zur Priorisierung von Anforderungen

6.8.2 Techniken zur Priorisierung von Anforderungen

7 Werkzeugunterstützung

7.1 Werkzeuge im Requirements Engineering

Exkurs: Nutzung von nicht für das Requirements Engineering entwickelten Werkzeugen

Exkurs: Requirements-Management-Werkzeuge

Exkurs: Spezialisierte Werkzeuge für das Requirements Management

Exkurs: Standard-Büroanwendungen

Exkurs: Modellierungswerkzeuge

7.2 Werkzeugeinführung

Anhang

Videoverzeichnis

Animationsverzeichnis

Kernfaktenverzeichnis

Literatur

Index

1 Einleitung und Grundlagen

Die Bedeutung des Requirements Engineering für die erfolgreiche, den Kunden1 zufriedenstellende Entwicklung von Systemen ist mittlerweile nicht mehr zu übersehen. In der Praxis ist es üblich, einen entsprechenden Aufwand für das Requirements Engineering einzuplanen. Der Requirements Engineer ist dementsprechend meist eine eigenständige Rolle im Projekt mit anspruchsvollen Tätigkeiten.

1.1 Requirements Engineering – Was?

Um ein Entwicklungsprojekt zum Erfolg zu führen, muss zunächst bekannt sein, was die Anforderungen an das System sind.

Definition 1–1:Anforderung

Eine Anforderung ist:

(1) Ein notwendiges Bedürfnis eines Stakeholders.(2) Eine Fähigkeit oder Eigenschaft, die ein System erfüllen muss.(3) Eine dokumentierte Repräsentation eines Bedürfnisses, einer Fähigkeit oder Eigenschaft.

Übersetzta aus [IREB-Glossar 2020]

a. Die Begriffe sind im IREB-Glossar sowohl in Deutsch als auch in Englisch angegeben, die Definition aber nur in Englisch.

Die Bedeutung der Stakeholder

Stakeholder (Interesseneigner) ist einer der zentralen Begriffe im Requirements Engineering. Stakeholder dienen u.a. als wichtigste Quellen für Anforderungen, und das Übersehen eines Stakeholders hat häufig zur Konsequenz, dass die ermittelten Anforderungen an das System lückenhaft sind [Macaulay 1993]. Stakeholder sind also alle diejenigen Personen oder Organisationen, die Anforderungen in irgendeiner Weise beeinflussen. Das können natürliche Personen sein, die das System später nutzen werden (z.B. Nutzer oder Administrator), und natürliche Personen, die Interesse an dem System haben, es aber nicht nutzen werden oder sollen (z.B. das Management oder Hacker, vor denen man das System schützen muss). Stakeholder können aber auch juristische Personen oder Institutionen sein, die allerdings durch natürliche Personen vertreten werden müssen, die die Anforderungen des betrachteten Systems beeinflussen bzw. definieren können.

Definition 1–2:Stakeholder (Interesseneigner)

Ein Stakeholder ist eine Person oder Organisation, die Einfluss auf die Anforderungen des Systems hat oder auf die das System Auswirkungen hat.

Übersetzt aus [IREB-Glossar 2020]

Anforderungen werden für eine Vielzahl von Dingen erhoben, die im Requirements Engineering häufig alle vereinfacht als Systeme bezeichnet werden. Hierzu zählen:

Dem Kunden zur Verfügung gestellte Produkte

Hierunter werden häufig klassische Softwaresysteme verstanden, die an den Kunden ausgeliefert werden. Daneben finden sich vermehrt Systeme mit einem Softwareanteil, die aber auch Hardware oder mechatronische Bestandteile umfassen.

Dem Kunden zur Verfügung gestellte Dienstleistungen

Neben den zuvor angesprochenen Systemen, die als Produkt an den Kunden ausgeliefert werden, zählen hierzu beispielsweise Services, die zur Verfügung gestellt werden.

Andere Arbeitsergebnisse

Neben Softwareprodukten und Dienstleistungen können Stakeholder aber auch Anforderungen an andere Systeme definieren. Dies können u.a. Arbeitsprodukte, Geräte, Hardwarebauteile oder beliebige Subsysteme oder Komponenten eines Systems umfassen, die benötigt werden, um ein bestimmtes Ziel der Stakeholder zu erreichen.

Zusammensetzungen oder Bestandteile der oben genannten Dinge. Also beispielsweise Komponenten oder sonstige Zulieferungen für Systeme des Kunden.

Ziel des Requirements Engineering

Dem Requirements Engineering im Entwicklungsprozess kommt die Aufgabe zu, die Anforderungen der Stakeholder zu ermitteln, zweckmäßig zu dokumentieren, zu überprüfen und abzustimmen sowie die dokumentierten Anforderungen über den gesamten Lebenszyklus des Systems hinweg zu verwalten.

Definition 1–3:Requirements Engineering

Das Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit dem Ziel, die Wünsche und Bedürfnisse der Stakeholder zu verstehen und die Gefahr zu minimieren, ein System auszuliefern, das diese Wünsche und Bedürfnisse nicht erfüllt.

Übersetzt aus [IREB-Glossar 2020]

Im Allgemeinen unterscheidet man zwischen drei Arten von Anforderungen:

Funktionale Anforderungen

Qualitätsanforderungen

Randbedingungen (Constraints)

Funktionale Anforderungen legen die Funktionalität fest, die das geplante System zur Verfügung stellen soll. Sie werden typischerweise in Funktions-, Verhaltens- und Strukturanforderungen unterteilt.

Definition 1–4:Funktionale Anforderung

Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses oder des Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll.

Übersetzt aus [IREB-Glossar 2020]

Qualitätsanforderungen legen gewünschte Qualitäten des zu entwickelnden Systems fest und beeinflussen häufig – in größerem Umfang als die funktionalen Anforderungen – die Gestalt der Systemarchitektur. Typischerweise beziehen sich Qualitätsanforderungen auf die Performance, die Verfügbarkeit, die Zuverlässigkeit, die Skalierbarkeit oder die Portabilität des betrachteten Systems.

Definition 1–5:Qualitätsanforderung

Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.

Übersetzt aus [IREB-Glossar 2020]

Zusammenhang zwischen funktionalen Anforderungen und Qualitätsanforderungen

Qualitätsanforderungen stehen häufig mit verschiedenen funktionalen Anforderungen in Beziehung. Qualitätsanforderungen können etwa funktionale Anforderungen weiter konkretisieren oder ihre Umsetzung wird durch funktionale Anforderungen beschrieben. Dennoch empfiehlt es sich, Qualitätsanforderungen und funktionale Anforderungen getrennt voneinander zu spezifizieren. Zudem sollte der Bezug von Qualitätsanforderungen und funktionalen Anforderungen nachvollziehbar dokumentiert werden, um eine größtmögliche Nachvollziehbarkeit zu erreichen.

Exkurs: Qualitätsanforderungen

In der Praxis werden die Qualitätsanforderungen eines Systems häufig nur unzureichend dokumentiert und zwischen Stakeholdern abgestimmt. Dies gefährdet den Projekterfolg oder die spätere Akzeptanz des entwickelten Systems erheblich. Der Requirements Engineer sollte daher im Entwicklungsprozess eines Systems möglichst frühzeitig besonderes Augenmerk auf die Ermittlung, Dokumentation und Abstimmung der Qualitätsanforderungen legen.

Typischerweise werden sehr unterschiedliche Qualitäten eines Systems der Anforderungsart »Qualitätsanforderung« zugeordnet. Um auf strukturierte Art und Weise mit den Qualitätsanforderungen eines Systems umgehen zu können, wurden verschiedenste Kategorisierungen von Qualitätsanforderungen vorgeschlagen. Beispielsweise schlägt der Standard [ISO/IEC 25010:2011] eine Kategorisierung für Qualitätsanforderungen vor, die als Standardstruktur für die Dokumentation von Qualitätsanforderungen und als Checkliste zur Ermittlung und Überprüfung von Qualitätsanforderungen dienen kann. Typische Kategorien dieses Standards sind:

Anforderungen, die die Leistung des Systems definieren, insbesondere das Antwortzeitverhalten und der Ressourcenverbrauch.Anforderungen, die die Sicherheit des Systems definieren, beispielsweise die Nachweisbarkeit, Authentizität, Vertraulichkeit und Integrität, aber auch der Schutz des Nutzers vor körperlichen Schäden.Anforderungen, die die Zuverlässigkeit der Funktionalität des Systems definieren, insbesondere in Bezug auf Verfügbarkeit, Fehlertoleranz und Wiederherstellbarkeit.Anforderungen, die die Benutzbarkeit des Systems definieren, insbesondere in Bezug auf Barrierefreiheit, Erlernbarkeit und Bedienbarkeit.Anforderungen, die die Änderbarkeit (Wartbarkeit) des Systems definieren, insbesondere in Bezug auf die Wiederverwendbarkeit, Analysierbarkeit, Modifizierbarkeit und Prüfbarkeit.Anforderungen, die die Übertragbarkeit des Systems definieren, insbesondere in Bezug auf Anpassbarkeit, Installierbarkeit und Austauschbarkeit.

Anforderungen einiger der o.g. Kategorien werden vorherrschend für einzelne Funktionen definiert (z.B. Leistung, Zuverlässigkeit), andere meist für das gesamte System gefordert (z.B. Änderbarkeit, Übertragbarkeit). Qualitätsanforderungen werden gegenwärtig meist in natürlicher Sprache formuliert, da eine formalere Beschreibung nur mit viel Aufwand und Expertise durchgeführt werden kann. In einigen Fällen, beispielsweise bei der Entwicklung sicherheitskritischer Systeme, werden aber auch formalere Beschreibungen eingesetzt, um eine höhere Nachweisbarkeit zu erreichen. So können Qualitätsanforderungen in Form von Modellen bzw. als Erweiterungen gängiger Modellierungsansätze dokumentiert werden.

Der Requirements Engineer sollte sicherstellen, dass die Qualitätsanforderungen möglichst objektiv an dem entwickelten System überprüfbar sind. Dies erfordert in der Regel, dass die geforderten Qualitäten durch quantitative Angaben konkretisiert werden. Beispielsweise könnte eine Qualitätsanforderung in Bezug auf die geforderte Leistung des Systems festlegen, dass die Abarbeitung einer Anfrage auf keinen Fall mehr als 4 Sekunden in Anspruch nehmen darf. Qualitätsanforderungen können hierbei durch zusätzliche funktionale Anforderungen konkretisiert werden. Oder eine Qualitätsanforderung bezüglich der Sicherheit des Systems kann durch die Forderung nach der Verschlüsselung der Ausgabedaten präzisiert und verfeinert werden. Die geforderte Verschlüsselung der Ausgabedaten stellt dabei eine funktionale Anforderung dar, die die geforderten Sicherheitseigenschaften des Systems umsetzt.

Constraints oder Randbedingungen (auch: Rahmenbedingungen) können von den Projektbeteiligten nicht beeinflusst werden. Randbedingungen können sich sowohl auf das betrachtete System beziehen (z.B. »Das System soll durch Webservices realisiert werden«) als auch auf den Entwicklungsprozess des Systems (z.B. »Das System soll bis spätestens Mitte 2024 am Markt verfügbar sein«). Randbedingungen werden, im Gegensatz zu funktionalen Anforderungen und Qualitätsanforderungen, nicht umgesetzt, sondern schränken die Umsetzungsmöglichkeiten, d.h. den Lösungsraum im Entwicklungsprozess, ein.

Definition 1–6:Randbedingung (Constraint)

Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.

Übersetzt aus [IREB-Glossar 2020]

Eine Randbedingung ist also in der Regel eine organisatorische oder technologische Vorgabe, die die Art und Weise einschränkt, wie das betrachtete System realisiert werden kann.

Exkurs: Randbedingungen (Constraints)

Um Randbedingungen näher zu betrachten und zu unterscheiden, existieren verschiedene Klassifikationen. In [Robertson und Robertson 2012] werden Randbedingungen in technische Einschränkungen und Einschränkungen des Entwicklungsprozesses unterschieden.

Des Weiteren können Randbedingungen auch im Hinblick auf ihren Ursprung unterschieden werden. So existieren beispielsweise:

Einschränkungen aufgrund des kulturellen UmfeldsRechtliche RahmenbedingungenOrganisatorische EinschränkungenEinschränkungen aufgrund der physikalisch technischen Umgebung des zu entwickelnden SystemsRahmenbedingungen, die sich aus dem definierten Vorgehen im Projekt ergeben

Eine derartige Strukturierung von Randbedingungen hilft beim Erheben von Anforderungen, aber auch bei ihrer Verwaltung.

Kernfakten 1–1:Requirements Engineering – Was

www.cpre-buch.de/pk1w1

1.2 Requirements Engineering – Warum?

Problemverständnis schärfen und Testfälle ableiten

Requirements Engineering trägt dazu bei, dass eine Problemstellung früher und besser verstanden wird. Dies ermöglicht es, die Kosten bei einem späteren Aufdecken von Fehlern zu minimieren. Außerdem legen gute Anforderungen die Grundlage, um nachzuweisen, dass das System die Anforderungen wie gewünscht realisiert. Hierzu werden direkt aus den Anforderungen Testfälle gewonnen, die es ermöglichen, Defekte im System aufzudecken.

Anforderungen zur Projektplanung und Kostenschätzung

Anforderungen leisten daneben einen nicht zu unterschätzenden Beitrag zur Projektplanung. Wie wir später sehen werden, erlauben explizit dokumentierte Anforderungen eine Priorisierung und damit eine Projektplanung vorzunehmen. Anhand dieser Priorisierungen und Planungsdokumente lassen sich dann, basierend auf dem zu erwartenden Aufwand für die Umsetzung der Anforderungen, die Kosten der einzelnen Arbeitspakete und damit des gesamten Entwicklungsprojekts besser schätzen.

Zusammengefasst bietet Requirements Engineering laut [IREB-Lehrplan 2020] einen Mehrwert bei der Entwicklung und Weiterentwicklung eines Systems, indem:

das Risiko, ein falsches System zu entwickeln, verringert wird;

ein besseres Verständnis des Problems erzeugt wird;

die Grundlage für die Schätzung von Entwicklungsaufwand und Kosten gelegt wird;

die Voraussetzung für das Testen des Systems geschaffen wird.

Symptome und Gründe für fehlerhafte Anforderungen

Symptome für mangelhaftes Requirements Engineering sind ebenso zahlreich wie ihre Ursachen. Häufig fehlen Anforderungen oder sie sind unklar formuliert. Wenn beispielsweise die Anforderungen nicht genau den Kundenwunsch widerspiegeln oder die Anforderungen zu ungenau beschrieben und damit verschiedenartig interpretierbar sind, kann dies zur Folge haben, dass das erstellte System nicht den Erwartungen der Auftraggeber bzw. Nutzer entspricht.

Der häufigste Grund für fehlerhafte Anforderungen ist die falsche Annahme der Stakeholder, dass vieles selbstverständlich ist und nicht explizit genannt werden muss. Es entstehen Kommunikationsprobleme zwischen den Beteiligten, die oft aus unterschiedlichem Erfahrungs- bzw. Wissenstand resultieren. Erschwerend kommt hinzu, dass besonders der Auftraggeber in vielen Fällen kurzfristige Ergebnisse in Form eines produktiven Systems erhalten möchte.

Zusammengefasst sind die typischsten Ursachen für mangelhaftes Requirements Engineering laut [IREB-Lehrplan 2020]:

Direkt mit der Entwicklung des Systems zu beginnen, ohne eine ausreichende Verständnisgrundlage geschaffen zu haben.

Kommunikationsprobleme zwischen den beteiligten Parteien (siehe Exkurs)

Die Annahme, dass die Anforderungen selbstverständlich sind und keiner weiteren Erläuterung bedürfen bzw. gar nicht erst erfasst werden müssen.

Unzureichende Ausbildung und Fähigkeiten des Requirements Engineer

Exkurs: Kommunikationsprobleme

Anforderungen müssen kommuniziert werden. In den meisten Fällen bedient man sich hierbei eines allen Kommunikationspartnern zugänglichen, regelgeleiteten Mediums – der Sprache.

Damit die Übertragung von Informationen von einem Individuum zu einem anderen funktioniert, wird ein gemeinsamer Code benötigt. Der Sender verschlüsselt seine Botschaft, die der Empfänger dann wieder entschlüsseln muss. Ein solcher gemeinsamer Code ist Menschen gegeben, die die gleiche natürliche Sprache (z.B. Deutsch) sprechen, den gleichen kulturellen Hintergrund haben und auf ähnliche Erfahrungen zurückgreifen können. Je ähnlicher der kulturelle und Bildungshintergrund, das Fachgebiet und der Arbeitsalltag sind, umso besser klappt der Austausch von Informationen. Da dies häufig unter den Stakeholdern nicht gegeben ist, ist es sinnvoll, sich zunächst auf eine gemeinsame Sprache und deren Verwendung zu einigen. Das kann z. B. der Einsatz eines Glossars (siehe Abschnitt 3.5) sein, in dem alle wichtigen Begriffe erläutert werden, oder die Einigung auf eine formalere Beschreibungssprache, z. B. die Unified Modeling Language (UML) der OMG (siehe Abschnitt 3.4).

Ein weiterer Faktor ist die Art des Kommunikationsmediums. Bei mündlicher Kommunikation beruht der Kommunikationserfolg stark auf Redundanz (z.B. Sprache und Gestik oder Sprache und Tonfall) sowie auf Rückkopplung. Bei schriftlicher Kommunikation wird redundanzarm und ohne (oder mit wenig direkter) Rückkopplung kommuniziert.

Zusätzlich zu den Problemen der unterschiedlichen Begriffswelten und Kommunikationsmedien ist meist zu beobachten, dass Informationen gar nicht oder nicht adäquat weitergegeben werden. Dies lässt sich oftmals auf natürliche Vorgänge zurückführen, die bei der Wahrnehmung des Menschen und der Kommunikation des Wahrgenommenen immer mehr oder weniger ausgeprägt auftreten: die Fokussierung und die Vereinfachung.

Die Fokussierung geschieht primär unter zwei Gesichtspunkten. Zum einen wird man immer auf das fokussieren, was einem wichtig ist. Zum anderen kann man nur auf das fokussieren, was einem bewusst ist. Das heißt, unbewusste Informationen gehen verloren.

Kommunikation, die auf dem Ausdruck von Wissen basiert, ist notwendigerweise vereinfachend. Ein Autor setzt beim Leser ein gewisses Vorwissen voraus. Diese Vereinfachungen im Ausdruck sind es, die im Zusammenhang mit Anforderungen problematisch werden, da sie Anforderungen unterschiedlich interpretierbar machen. In Kapitel 3 wird näher auf die Darstellung von Anforderungen in natürlicher Sprache und mit Modellen eingegangen.

Die Bedeutsamkeit von gutem Requirements Engineering

Die steigende Bedeutung von Systemen mit einem signifikanten Softwareanteil in industriellen Projekten sowie die Notwendigkeit, innovativere, individuellere und umfangreichere Systeme schneller, besser und mit höchster Qualität auf den Markt zu bringen, setzen ein leistungsfähiges Requirements Engineering voraus. Fehlerfreie und ausreichend vollständige Anforderungen sind die Basis für eine erfolgreiche Systementwicklung. Bereits im Requirements Engineering müssen potenzielle Risiken aufgedeckt, und, wenn es geht, behoben werden, um einen erfolgreichen Projektablauf zu ermöglichen. Fehler und Lücken in Anforderungsdokumenten müssen frühzeitig erkannt werden, um langwierige Änderungsprozesse zu vermeiden.

Kernfakten 1–2:Requirements Engineering – Warum

www.cpre-buch.de/pk1w2

1.3 Requirements Engineering – Wo?

Neben der Unterscheidung in funktionale Anforderungen, Qualitätsanforderungen und Randbedingungen wird eine Reihe anderer Klassifizierungen von Anforderungen in der Praxis verwendet. Diese können unternehmensspezifisch, projektspezifisch oder aufgrund anderer Vorgaben entstehen. Dies gilt beispielsweise für die in diversen Standards definierten Anforderungsklassen (z.B. CMMI [SEI 2006], SPICE [ISO/IEC 15504-5]) oder in Bezug auf die Klassifikation über Attributwerte von Anforderungen, etwa für den Detaillierungsgrad, die Priorität oder die rechtliche Verbindlichkeit von Anforderungen.

Klassifikation von Anforderungen

Häufig findet sich die Unterscheidung zwischen Systemanforderungen und Nutzeranforderungen. Daneben sind aber auch weitere Unterscheidungen gängig. Eine häufig verwendete Klassifikation von Anforderungen ist die Unterscheidung zwischen Systemanforderungen, Stakeholder-Anforderungen, Nutzeranforderungen, Domänenanforderungen und Geschäftsanforderungen [IREB-Lehrplan 2020].

Systemanforderungen

beschreiben, was das System leisten soll. Somit können Systemanforderungen als die »klassischen« Anforderungen aufgefasst werden, die dann in funktionale Anforderungen an das System, Anforderungen an die Qualität des Systems und Randbedingungen für Systemausführung und -entwicklung unterschieden werden.

Stakeholder-Anforderungen

beschreiben aus der Sicht eines Stakeholders, was dieser mit dem System erreichen will. Stakeholder-Anforderungen eignen sich, um Anforderungen aus unterschiedlichen Perspektiven zu erfassen und zu dokumentieren. Im Zuge der Definition von Systemanforderungen müssen basierend auf diesen Stakeholder-Anforderungen u.a. die Anforderungen der verschiedenen Stakeholder konsolidiert werden, Konflikte identifiziert und aufgelöst werden (siehe

Abschnitt 4.3

).

Benutzeranforderungen

beschreiben aus der Nutzerperspektive, was die Benutzer mit dem System erreichen wollen bzw. wie dieses genutzt werden soll. Nutzeranforderungen können als eine Unterkategorie der Stakeholder-Anforderungen aufgefasst werden, da die Nutzer eine spezifische Gruppe von Stakeholdern sind.

Domänenanforderungen

beschreiben Anforderungen (häufig Randbedingungen), die von dem jeweiligen Umfeld, in dem das System eingesetzt werden soll, vorgegeben werden.

Geschäftsanforderungen

beschreiben Anforderungen, die eng mit dem gewünschten Business Value verzahnt sind. Geschäftsanforderungen werden im Allgemeinen von der Organisation vorgegeben. Außerdem umfassen Geschäftsanforderungen wirtschaftliche Zielgrößen und Budgetbeschränkungen.

Exkurs: Ziele und Szenarien

Neben der Unterscheidung von Anforderungen entsprechend verschiedener Bereiche wird häufig zwischen weiteren Anforderungsarten unterschieden. Eine hilfreiche Unterscheidung ist hierbei die Unterteilung in:

ZieleSzenarienLösungsorientierte Anforderungen

Dies bringt die unterschiedliche Granularität von Anforderungen zum Ausdruck. Mit Zielen und Szenarien werden zwei Anforderungsarten in den Fokus gerückt, die im Gegensatz zu sehr detaillierten technischen Anforderungen auf das Verständnis des Problemraums hinwirken.

Unter einem Ziel versteht man die intentionale Beschreibung eines von Stakeholdern (z.B. Personen oder Organisationen) gewünschten charakteristischen Merkmals des zu entwickelnden Systems bzw. des zugehörigen Entwicklungsprojekts. Ziele werden somit sehr nah an der ursprünglichen Intention der Stakeholder definiert. Damit eignen sich Ziele sehr gut, um in frühen Phasen erste Anforderungen zu erheben und diese bereits zu validieren und zwischen den verschiedenen Stakeholdern abzustimmen.

Szenarien werden genutzt, um beispielhafte Beschreibungen für Ziele oder Anforderungen zu definieren. Diese tauchen direkt in die Lebensrealität der Stakeholder ein und sind damit sehr gut geeignet, Detailwissen der Stakeholder zu erfragen und mit dem Verständnis des Requirements Engineer und den initialen Anforderungen abzugleichen. Eine bekannte Form von Szenarien sind User Stories. User Stories beschreiben ein aus Nutzerperspektive dargestelltes Bedürfnis und sind Ausdruck des Wertes/Nutzens, wenn dieses erfüllt ist.

Kernfakten 1–3:Requirements Engineering – Wo

www.cpre-buch.de/pk1w3

Hinweis: Requirements-Engineering-Prozess vs. Systementwicklungsprozess