Zurück

In den Warenkorb

Empfehlung per E-Mail versenden

Probeexemplar anfordern

Gerne schicken wir Ihnen ein Probeexemplar an die angegeben Adresse.
Basiswissen Requirements Engineering

Basiswissen Requirements Engineering

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

vonPohl, Klaus | Rupp, Chris
Deutsch, Erscheinungstermin 14.04.2015
lieferbar

eBook

23,99 €
(inkl. MwSt.)

Buch (gebunden)

29,90 €
(inkl. MwSt.)
Requirements Engineering (RE) ist eine Schlüsseldisziplin der Systementwicklung und entscheidet maßgeblich über den Erfolg oder Misserfolg eines Projekts. Fachleute, die in diesem Bereich tätig sind, sollten über ein gesichertes RE-Grundlagenwissen verfügen - so wie es im Lehrplan des 'Certified Professional for...

Informationen zum Titel

978-3-86491-673-1
Heidelberg
14.04.2015
2015
4
4. Aufl.
eBook
PDF mit digitalem Wasserzeichen
195
Heidelberg
Deutsch
19921 kB
1;Inhaltsverzeichnis;15
2;1 Einleitung und Grundlagen;21
2.1;1.1 Einleitung;21
2.1.1;1.1.1 Zahlen und Fakten im Projektalltag;21
2.1.2;1.1.2 Requirements Engineering - was ist das?;23
2.1.3;1.1.3 Einbettung des Requirements Engineering in Vorgehensmodelle;25
2.2;1.2 Kommunikationstheoretische Grundlagen;26
2.3;1.3 Eigenschaften eines Requirements Engineer;27
2.4;1.4 Arten von Anforderungen;28
2.5;1.5 Bedeutung und Kategorisierung von Qualitätsanforderungen;30
2.6;1.6 Zusammenfassung;31
3;2 System und Systemkontext abgrenzen;33
3.1;2.1 Systemkontext;33
3.2;2.2 System- und Kontextgrenzen bestimmen;34
3.2.1;2.2.1 Die Systemgrenze festlegen;35
3.2.2;2.2.2 Die Kontextgrenze bestimmen;38
3.3;2.3 Den Systemkontext dokumentieren;39
3.4;2.4 Zusammenfassung;40
4;3 Anforderungen ermitteln;41
4.1;3.1 Anforderungsquellen;41
4.1.1;3.1.1 Stakeholder und deren Bedeutung;42
4.1.2;3.1.2 Der Umgang mit Stakeholdern im Projekt;42
4.2;3.2 Anforderungskategorisierung nach dem Kano-Modell;44
4.3;3.3 Ermittlungstechniken;46
4.3.1;3.3.1 Arten von Ermittlungstechniken;46
4.3.2;3.3.2 Befragungstechniken;47
4.3.3;3.3.3 Kreativitätstechniken;48
4.3.4;3.3.4 Dokumentenzentrierte Techniken;50
4.3.5;3.3.5 Beobachtungstechniken;51
4.3.6;3.3.6 Unterstützende Techniken;52
4.4;3.4 Zusammenfassung;53
5;4 Anforderungen dokumentieren;55
5.1;4.1 Dokumentgestaltung;55
5.2;4.2 Arten der Dokumentation;56
5.2.1;4.2.1 Die drei Perspektiven von Anforderungen;57
5.2.2;4.2.2 Dokumentation von Anforderungen in natürlicher Sprache;57
5.2.3;4.2.3 Dokumentation von Anforderungen durch konzeptuelle Modelle;58
5.2.4;4.2.4 Mischform von Anforderungsdokumenten;59
5.3;4.3 Dokumentenstrukturen;59
5.3.1;4.3.1 Standardisierte Dokumentenstrukturen;59
5.3.2;4.3.2 Angepasste Standardinhalte;61
5.4;4.4 Verwendung von Anforderungsdokumenten;63
5.5;4.5 Qualitätskriterien für das Anforderungsdokument;64
5.5.1;4.5.1 Eindeutigkeit und Konsistenz;65
5.5.2;4.5.2 Klare Struktur;65
5.5.3;4.5.3 Modifizierbarkeit und Erweiterbarkeit;65
5.5.4;4.5.4 Vollständigkeit;66
5.5.5;4.5.5 Verfolgbarkeit (Traceability);66
5.6;4.6 Qualitätskriterien für Anforderungen;67
5.7;4.7 Glossar;69
5.8;4.8 Zusammenfassung;71
6;5 Anforderungen natürlichsprachig dokumentieren;73
6.1;5.1 Sprachliche Effekte;73
6.1.1;5.1.1 Nominalisierung;74
6.1.2;5.1.2 Substantive ohne Bezugsindex;75
6.1.3;5.1.3 Universalquantoren;75
6.1.4;5.1.4 Unvollständig spezifizierte Bedingungen;76
6.1.5;5.1.5 Unvollständig spezifizierte Prozesswörter;77
6.2;5.2 Konstruktion von Anforderungen mittels Satzschablone;77
6.3;5.3 Zusammenfassung;81
7;6 Anforderungen modellbasiert dokumentieren;83
7.1;6.1 Der Modellbegriff;83
7.1.1;6.1.1 Eigenschaften von Modellen;84
7.1.2;6.1.2 Konzeptuelle Modellierungssprachen;85
7.1.3;6.1.3 Anforderungsmodelle;85
7.1.4;6.1.4 Vorteile von Anforderungsmodellen;86
7.1.5;6.1.5 Kombinierter Einsatz von Anforderungsmodellen und natürlicher Sprache;86
7.2;6.2 Zielmodelle;87
7.2.1;6.2.1 Zieldokumentation mit Und-Oder-Bäumen;87
7.2.2;6.2.2 Beispiel für Und-Oder-Bäume;88
7.3;6.3 Use Cases;89
7.3.1;6.3.1 UML-Use-Case-Diagramme;89
7.3.2;6.3.2 Use-Case-Spezifikationen;92
7.4;6.4 Drei Perspektiven auf die Anforderungen;95
7.5;6.5 Anforderungsmodellierung in der Strukturperspektive;96
7.5.1;6.5.1 Entity-Relationship-Diagramme;97
7.5.2;6.5.2 UML-Klassendiagramme;99
7.6;6.6 Anforderungsmodellierung in der Funktionsperspektive;102
7.6.1;6.6.1 Datenflussdiagramme;102
7.6.2;6.6.2 Modelle der Funktionsperspektive und Kontrollfluss;104
7.6.3;6.6.3 UML-Aktivitätsdiagramme;105
7.7;6.7 Anforderungsmodellierung in der Verhaltensperspektive;109
7.7.1;6.7.1 Statecharts;109
7.7.2;6.7.2 UML-Zustandsdiagramm;111
7.8;6.8 Zusammenfassung;114
8;7 Anforderungen prüfen und abstimmen;115
8.1;7.1 Grundlagen der Prüfung von Anforderungen;115
8.2;7.2 Grundlagen der Abstimmung von Anforderungen;116
8.3;7.3 Qualitätsaspekte für Anforderungen;117
8.3.1;7.3
Requirements Engineering (RE) ist eine Schlüsseldisziplin der Systementwicklung und entscheidet maßgeblich über den Erfolg oder Misserfolg eines Projekts. Fachleute, die in diesem Bereich tätig sind, sollten über ein gesichertes RE-Grundlagenwissen verfügen - so wie es im Lehrplan des 'Certified Professional for Requirements Engineering' (CPRE) festgelegt ist. Entwickelt und eingeführt wurde das CPRE-Zertifikat vom 'International Requirements Engineering Board' (IREB e.V.). Der IREB e.V. setzt sich für die Verbesserung der Requirements-Engineering-Praxis sowie für eine qualitätsgesicherte und standardisierte Aus- und Weiterbildung ein. Dieses Lehrbuch für die Zertifizierung zum 'Foundation Level' (Version 2.2) des CPRE wurde von IREB-Mitgliedern geschrieben, die an der Entwicklung des Lehrplans beteiligt waren. Es behandelt im Einzelnen die - Ermittlung - Dokumentation - Prüfung und Abstimmung - Verwaltung von Anforderungen sowie die Werkzeugunterstützung. Das Buch eignet sich zur individuellen Vorbereitung auf die Zertifizierungsprüfung und als Begleitliteratur zu den entsprechenden Vorbereitungsschulungen. Die 4. Auflage wurde überarbeitet und ist konform zur aktuellen Ausgabe des IREB-Lehrplans Foundation Level Version 2.2. Über dem Leserkasten: Ergänzende Informationen zum Buch, zum IREB e.V. und zum CPRE finden sich unter: Dr. Klaus Pohl ist Professor für Software Systems Engineering und Direktor von 'paluno - The Ruhr Institute for Software Technology' an der Universität Duisburg-Essen. Er ist bzw. war Koordinator von mehreren internationalen und nationalen Forschungsprojekten, Vorsitzender des Programmkomitees und 'General Chair' von nationalen und internationalen Konferenzen und ist (Co-)Autor von mehr als 250 begutachteten Publikationen. Als Berater unterstützt er Industrieunternehmen und öffentliche Organisationen darin, die Requirements-Engineering-Prozesse in der Praxis weiter zu verbessern. Chris Rupp OberSOPHISTin (formal: Gründerin und geschäftsführende Gesellschafterin), Chefberaterin, Coach und Trainerin. In 25 Jahren Berufstätigkeit sammelt sich so einiges an ... ein Unternehmen ... 6 Bücher ... 55 Mitarbeiter ... ungezählte Artikel und Vorträge ... 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 bin, in Projekten mitarbeite. Gute Ideen so umzusetzen, dass Entwickler, Vertragspartner, direkt und indirekt betroffene Anwender das Gefühl haben, ein intelligentes, durchdachtes und nutzbringendes Produkt vor sich zu haben, ist die Vision die mich dabei antreibt. Dabei arbeite ich mit unterschiedlichsten Methoden und Ansätzen aus dem agilen und nicht agilen Bereich. Um die Qualifikation der Requirements-Engineers/Business-Analysten zu vereinheitlichen habe ich den IREB e. V. (International Requirements Engineering Board) gegründet. Mehr Infos über mich finden Sie unter www.sophist.de. Chris Rupp ist Autorin vieler Bücher, unter anderem 'Requirements-Engineering und -Management' (Carl Hanser Verlag München 2014) und 'UML2 glasklar' (Carl Hanser Verlag München 2012).
Prof. Dr. Klaus Pohl ist Professor für Software Systems Engineering und Direktor von "paluno - The Ruhr Institute for Software Technology" an der Universität Duisburg-Essen. Er ist bzw. war Koordinator von mehreren internationalen und nationalen Forschungsprojekten, Vorsitzender des Programmkomitees und "General Chair" von nationalen und internationalen Konferenzen und ist (Co-)Autor von mehr als 250 begutachteten Publikationen. Als Berater unterstützt er Industrieunternehmen und öffentliche Organisationen darin, die Requirements-Engineering-Prozesse in der Praxis weiter zu verbessern.

Chris Rupp OberSOPHISTin (formal: Gründerin und geschäftsführende Gesellschafterin), Chefberaterin, Coach und Trainerin. In 25 Jahren Berufstätigkeit sammelt sich so einiges an ... ein Unternehmen ... 6 Bücher ... 55 Mitarbeiter ... ungezählte Artikel und Vorträge ... 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 bin, in Projekten mitarbeite. Gute Ideen so umzusetzen, dass Entwickler, Vertragspartner, direkt und indirekt betroffene Anwender das Gefühl haben, ein intelligentes, durchdachtes und nutzbringendes Produkt vor sich zu haben, ist die Vision die mich dabei antreibt. Dabei arbeite ich mit unterschiedlichsten Methoden und Ansätzen aus dem agilen und nicht agilen Bereich. Um die Qualifikation der Requirements-Engineers/Business-Analysten zu vereinheitlichen habe ich den IREB e. V. (International Requirements Engineering Board) gegründet. Mehr Infos über mich finden Sie unter www.sophist.de. Chris Rupp ist Autorin vieler Bücher, unter anderem "Requirements-Engineering und -Management" (Carl Hanser Verlag München 2014) und "UML2 glasklar" (Carl Hanser Verlag München 2012).
1 Einleitung und Grundlagen

Die Bedeutung des Requirements Engineering (RE) für die erfolgreiche, den Kunden zufriedenstellende Entwicklung von Systemen ist mittlerweile kaum mehr zu übersehen. In der Praxis ist es üblich, einen entsprechenden Aufwand für das Requirements Engineering einzuplanen. Immer häufiger findet man zudem die Erkenntnis, dass der Requirements Engineer eine eigenständige Rolle mit anspruchsvollen Tätigkeiten ist.
1.1 Einleitung

Wozu Requirements Engineering?

Glaubt man den Zahlen im Chaos Report 2006 der Standish Group, so hat sich in den zwölf Jahren zwischen 1994 und 2006 bei der erfolgreichen Abwicklung von Softwareprojekten einiges zum Besseren gewendet. Sind im Jahre 1994 noch gut 30% der untersuchten Softwareprojekte gescheitert, so waren es 2006 nur noch knapp 20%. Die Anzahl der Projekte, die mit starken Zeit- oder Budgetüberziehungen und/oder nicht zur Zufriedenheit der Kunden abgeschlossen werden konnten, verringerte sich von 53% auf 46% [ Chaos 2006 ]. Jim Johnson, Vorsitzender der Standish Group, nennt als einen von drei Gründen für die positive Entwicklung der Zahlen seit 1994 die Tatsache, dass Anforderungen besser kommuniziert würden als noch vor zehn Jahren. Interessant sind diese Zahlen, da der Umgang mit Anforderungen eines Systems eine signifikante Ursache für Projektfehlschläge bzw. für Zeit- und Budgetüberschreitungen darstellt.
1.1.1 Zahlen und Fakten im Projektalltag

Requirements Engineering als Fehlerquelle

Studien belegen, dass etwa 60% der Fehler in Systementwicklungsprojekten bereits im Requirements Engineering entstehen [ Boehm 1981 ]. Irrtümer aus dem Requirements Engineering werden jedoch oft erst in späteren Projektphasen oder im Betrieb des Systems entdeckt, da fehlerhafte oder unvollständige Anforderungen für Entwickler so interpretiert werden können, dass sie subjektiv schlüssig sind oder aus der subjektiven Perspektive der Entwickler (unbewusst) vervollständigt werden. Fehlende Anforderungen werden im Entwurf und in der Realisierung häufig nicht entdeckt, da man sich hier auf die qualitativ hochwertige Arbeit des Requirements Engineer verlässt. Es wird umgesetzt, was man aus dem Anforderungsdokument entnehmen kann oder glaubt, entnehmen zu können. Missverständliche, unvollständige oder falsche Anforderungen führen somit unausweichlich zu einem System, das wichtige Eigenschaften nicht besitzt oder Eigenschaften aufweist, die nicht gefordert wurden.

Kosten von Fehlern im Requirements Engineering

Je später ein Fehler in den Anforderungen im Verlauf des Entwicklungsprojekts behoben wird, umso höher sind die damit verbundenen Kosten. So wird beispielsweise für die Beseitigung eines Anforderungsfehlers, der erst beim Programmieren entdeckt wird, ein um ca. den Faktor 20 höherer Aufwand notwendig, als wenn derselbe Fehler während des Requirements Engineering behoben worden wäre - für die Fehlerbeseitigung in der Abnahmephase des Systems geht man von dem Faktor 100 aus [ Boehm 1981 ].

Symptome und Gründe für mangelhaftes Requirements Engineering

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, hat dies häufig zur Folge, 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 resultiere
Kundenmitteilung
EU-Datenschutzgrundverordnung

Die DSGVO stärkt die Datenschutzrechte europaweit für uns alle. Bei vub haben wir aus diesem Anlass unsere Datenschutzerklärung grundlegend verändert:

  • Wir stellen noch übersichtlicher dar, wie und wofür wir personenbezogene Daten verarbeiten (wenn überhaupt, denn das Verwerten Ihrer persönlichen Daten ist überhaupt nicht unser Geschäft!).
  • Wir informieren in unserer neuen Datenschutzerklärung über die Kundenrechte.
  • Wir haben die Datenschutzerklärung übersichtlicher gestaltet.
  • Ab dem 25. Mai 2018 können Sie in Ihrem Kundenkonto unter „meine Einstellungen“ den gewünschten Datenschutz selbst einstellen.

Bei Fragen wenden Sie sich bitte jederzeit an unseren vub-Kundenservice und Ihre bekannten Ansprechpartner unter premiumservice@vub.de.

Bestätigung