Business Analysis und Requirements Engineering
Produkte und Prozesse nachhaltig verbessern
3rd Edition
Published on 10. July 2023
376 pages
978-3-446-47819-0 (ISBN)
Description
Wir alle wollen schlanke, effektive Geschäftsprozesse und optimale IT-Unterstützung. Wir finden für jedes Problem eine Lösung - wenn wir uns nur genau darauf einigen könnten, was unser Problem ist.
Das Verstehen von Problemen und das Formulieren von Anforderungen, was wir gerne anders hätten, ist das Thema dieses Buches.
Viele verschiedene Begriffe werden dafür verwendet (Business Analysis, Systemanalyse, Requirements Engineering, ...) und viele Berufsbezeichnungen für die Beteiligten.
Dieses Buch zeigt einen integrierten Ansatz zum Umgang mit Anforderungen. Es stellt Ihnen Methoden, Notationen und viele pragmatische Tipps (Best Practices) zur Verfügung, mit denen Anforderungen effektiv zwischen Auftraggebern und Auftragnehmern behandelt werden können - von Entdeckungstechniken über Dokumentationstechniken, Prüftechniken bis hin zu Verwaltungstechniken.
Die 3. Auflage ist gemäß den überarbeiteten Lehrplänen der IREB (Certified Professional for Requirements Engineering) aktualisiert.
Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches
More details
Other editions
Additional editions
Peter Hruschka
Business Analysis und Requirements Engineering
Produkte und Prozesse nachhaltig verbessern
Book
07/2023
3rd Edition
Hanser
€39.99
Available immediately
Peter Hruschka
Business Analysis und Requirements Engineering
Produkte und Prozesse nachhaltig verbessern
E-Book
07/2023
3rd Edition
Hanser
€39.99
Available for download
Person
Author
Dr. Peter Hruschka ist einer der Prinzipale der Atlantic Systems Guild (www.systemsguild.com). Peter widmet sein Arbeitsleben dem Technologietransfer, insbesondere für große Hardware-/Software-Systeme. Er ist Mitbegründer von arc42 und req42 - der Heimat für pragmatische Softwarearchitektur und agiles Requirements-Engineering. Peter hat mehr als zehn Bücher und zahlreiche Artikel über Software- und System-Engineering veröffentlicht und unterrichtet und berät weltweit. Peter lebt in Aachen.
ISNI:
ISNI:
Content
- Intro
- Inhalt
- Vorwort
- Vorwort zur dritten Auflage
- 1 Probleme, Ziele, Ideen und Visionen
- 1.1 Wovon sprechen wir?
- 1.2 Quantitative Gründe
- 1.3 Qualitative Gründe
- 1.4 Warum macht es nicht jeder richtig?
- 1.5 Zwei weitere Gründe
- 1.6 Standardisierung und Zertifizierung
- 1.7 Drei Säulen erfolgreicher Vorhaben
- 1.8 Definition: Business Analysis und?Requirements Engineering
- 1.9 Definition: Requirement
- 1.10 Arten von Anforderungen
- 1.11 Hauptaufgaben von Analytikern und?Produkt-Ownern
- 1.12 Aufgabenverteilung im Team
- 1.13 Benötigte Fähigkeiten
- 1.14 Der Aufwand für die Analyse
- 1.15 Was erleichtert die Analyse?
- 1.16 Verschiedene Vorgehensweisen
- 1.17 Zusammenfassung
- 2 Erfolgreich starten
- 2.1 Drei Zutaten zu einem erfolgreichen Projektstart
- 2.2 Ziele
- 2.3 Ziele spezifizieren
- 2.4 Stakeholder
- 2.5 Stakeholder finden
- 2.6 Die wichtigsten Stakeholder: die Nutzer
- 2.7 Weitere Quellen für Anforderungen
- 2.8 Scope und Kontext
- 2.9 Scope und Analytiker
- 2.10 Umgang mit Grauzonen
- 2.11 Darstellung der System-/Produktgrenze
- 2.12 Alternative Notationen
- 2.13 Die drei Erfolgszutaten (nochmals)
- 2.14 Zusammenfassung
- 3 Geschäftsprozesse und Produktfunktionalität
- 3.1 Anforderungen unterschiedlicher Granularität
- 3.2 Funktionale Anforderungen gliedern und?strukturieren
- 3.3 Prozesse: die Grundidee
- 3.4 Prozesse finden
- 3.5 Gliederung einer Domäne in Subdomänen
- 3.6 Empfehlungen und Warnungen
- 3.7 Zusammenfassung
- 4 Große Funktionen genauer betrachtet
- 4.1 Zerlegungskriterien
- 4.2 Wo hört man auf?
- 4.3 Top-down oder bottom-up?
- 4.4 Zusammenfassung
- Intermezzo
- 5 Anforderungen in?Umgangssprache
- 5.1 IEEE-Forderungen an Anforderungen
- 5.2 Zwischen Wahrnehmung und?Niederschrift
- 5.3 Gute umgangssprachliche Anforderungen
- 5.3.1 Das Story-Format
- 5.3.2 Alternative Satzschablonen
- 5.4 Generelle Stilregeln
- 5.5 Ein Glossar für die Daten
- 5.6 Gute Definitionen
- 5.7 Vorgehensweise bei Glossareinträgen
- 5.8 Zusammenfassung
- 6 Anforderungen modellieren
- 6.1 Use-Case-Modelle
- 6.1.1 Use Cases strukturieren
- 6.1.2 Use Cases und natürliche Sprache: ein Vergleich
- 6.1.3 Business Use Cases und Product Use Cases
- 6.1.4 Use Cases finden
- 6.1.5 Die Anzahl von Use Cases
- 6.1.6 Drei Tricks zur Vereinfachung
- 6.1.7 Use Cases beschreiben
- 6.1.8 Beschreibung auf Drachenniveau
- 6.1.9 Beschreibung auf Wellenniveau
- 6.1.10 Beschreibung auf Fischniveau
- 6.1.11 Der Stil auf Wellenniveau
- 6.1.12 Zusammenfassung Use-Case-Modelle
- 6.2 Story Maps
- 6.3 Context-Maps
- 6.4 Datenmodelle
- 6.4.1 Eine kleine Geschichte
- 6.4.2 Datenmodelle als strukturiertes Glossar
- 6.4.3 (Entity-)Klassen
- 6.4.4 Entity-Klassen-Modelle
- 6.4.5 Beziehungen
- 6.4.6 Spezielle Beziehungen
- 6.4.7 Malen oder schreiben?
- 6.4.8 Noch drei Beispiele
- 6.4.9 Abläufe und Daten
- 6.4.10 Ein Ausblick auf die Erstellung von Datenmodellen
- 6.4.11 Zusammenfassung Datenmodelle
- 6.5 Wenn die Grobspezifikation von?Prozessen nicht ausreicht .
- 6.6 Aktivitätsdiagramme
- 6.6.1 Aktivitäten zerlegen
- 6.6.2 Swimlanes und Daten
- 6.6.3 Malen oder schreiben?
- 6.6.4 Wo hört man auf?
- 6.6.5 Nochmals: top-down oder bottom-up?
- 6.7 Alternative Funktionsmodelle
- 6.7.1 Datenflussdiagramme
- 6.7.2 Ereignisgesteuerte Prozessketten (EPK)
- 6.7.3 Business Process Model and Notation (BPMN)
- 6.7.4 Zusammenfassung feinerer Funktionsmodelle
- 6.8 Verhaltensmodelle
- 6.8.1 Warum noch ein Modell?
- 6.8.2 Grundlagen von Zustandsmodellen
- 6.8.3 Aktionen und Aktivitäten
- 6.8.4 Zustandsmodelle erstellen und prüfen
- 6.8.5 Komplexe Zustandsmodelle
- 6.8.6 Ein Beispiel
- 6.8.7 Malen oder schreiben?
- 6.8.8 Zustandsmodelle und Aktivitätsdiagramme
- 6.8.9 Use Cases und Zustandsmodelle
- 6.8.10 Zusammenfassung Zustandsmodelle
- 6.9 Zusammenfassung Requirements-Modelle
- 7 Qualitätseigenschaften und Randbedingungen
- 7.1 Worum geht es hier?
- 7.2 Kategorisierungsschemata
- 7.2.1 Das Qualitätsmodell ISO?25010
- 7.2.2 Das Requirements-Template VOLERE
- 7.2.3 Das Requirementsschema ARTE für Embedded Systems
- 7.2.4 Q42 - das Qualitätsmodell von req42 und arc42
- 7.2.5 Vor- und Nachteile der Kategorisierungsschemata
- 7.3 Qualitätsanforderungen und Randbedingungen finden und zuordnen
- 7.4 Beispiele für äußere Qualitäten
- 7.5 Beispiele für innere Qualitäten
- 7.6 Beispiele für Randbedingungen
- 7.7 Messbarkeit von Anforderungen
- 7.8 Zusammenfassung
- 8 Anforderungen dokumentieren
- 8.1 Warum überhaupt dokumentieren?
- 8.2 Viele Namen und mehrere Dokumente?
- 8.3 Anforderungen an Requirements-Dokumentation
- 8.4 Beispiele für die Struktur von?Requirements-Dokumentation
- 8.5 Mindestinhalte
- 8.6 Zusammenfassung
- 9 Anforderungen ermitteln
- 9.1 Das Kano-Modell
- 9.2 Arten von Erhebungsmethoden
- 9.3 Was beeinflusst die Auswahl?
- 9.4 Beispiele für Frage-Antwort-Techniken
- 9.5 Beispiele für Beobachtungstechniken
- 9.6 Beispiele für vergangenheitsorientierte Techniken
- 9.7 Beispiele für Kreativitätstechniken
- 9.8 Erhebungstechniken und Hilfsmittel
- 9.9 Noch eine Kreativitätstechnik
- 9.10 Überblick (Reprise)
- 9.11 Zusammenfassung
- 10 Anforderungen prüfen und abstimmen
- 10.1 Quality Gates
- 10.2 Ziele der Prüfung
- 10.3 Arten der Prüfung
- 10.4 Wer sollte beteiligt sein?
- 10.5 Was wird geprüft?
- 10.6 Checklisten für inhaltliche Prüfungen
- 10.7 Was tun bei Mängeln?
- 10.8 Konfliktmanagement
- 10.9 Zusammenfassung
- 11 Requirements-Management
- 11.1 Definition: Requirements-Management
- 11.2 Vorbereitende Tätigkeiten
- 11.3 Der Requirements-Prozess
- 11.4 Rollen
- 11.5 Laufende Tätigkeiten
- 11.6 Attributierung von Requirements
- 11.7 Sichtenbildung
- 11.8 Priorisierung
- 11.9 Baselines und Releases
- 11.10 Change Management
- 11.11 Traceability
- 11.12 Zusammenfassung
- 12 Requirements-Werkzeuge
- 12.1 Kategorien von Werkzeugen
- 12.2 Leistungen von Werkzeugen
- 12.3 Stärken und Schwächen der Kategorien
- 12.4 Werkzeugauswahl
- 12.5 Einführung von Werkzeugen
- 12.6 Zusammenfassung
- Literatur
- Stichwortverzeichnis
