nach oben

2022 | Buch

Kapitel lesen Erstes Kapitel lesen

Agile objektorientierte Anforderungsanalyse

Planen – Ermitteln – Analysieren – Modellieren – Dokumentieren – Prüfen

verfasst von: Hansruedi Tremp

Verlag: Springer Fachmedien Wiesbaden

Buchreihe : erfolgreich studieren

Enthalten in: Springer Professional "Wirtschaft+Technik" , Springer Professional "Technik" , Springer Professional "Wirtschaft"

Einloggen, um Zugang zu erhalten

Über dieses Buch

Basierend auf den Vorgaben des IREB (International Requirements Engineering Board) bietet das Lehrbuch einen theoretischen Überblick der relevanten Disziplinen der Anforderungsanalyse mit konkretem Praxisbezug. Nach der Verortung des Requirements Engineering-Prozesses in agilen und klassischen Vorgehensmodellen führt das Buch in die grundlegenden Themen der Ermittlung und Dokumentation von nicht-funktionalen und funktionalen Anforderungen. Ein wichtiger Bestandteil bildet die objektorientierte Analyse mit Hilfe der UML (Unified Modeling Language). Eine Einführung in das Usability Engineering hilft dem Leser, einen passenden Demonstrationsprototyp zu erstellen. Die Darlegung der Qualitätssicherung mittels der Anforderungsabstimmung und diversen formalen Prüfmethoden runden das Lehrbuch ab.

Inhaltsverzeichnis

Frontmatter

1. Prozess der Anforderungsanalyse planen

Zusammenfassung

Die Projektleiterin Beate organisiert die Kick-Off-Sitzung mit dem Kernteam. Sie eröffnet das Meeting mit folgenden Worten: „Wir freuen uns, gemeinsam ein wertvolles Softwareprodukt zu schaffen. Die Qualität des gesamten Systementwicklungsprozesses hat einen entscheidenden Einfluss auf die Qualität des Endproduktes. Deshalb möchten wir in einem ersten Schritt einen Überblick schaffen über den aktuellen Stand der Vorgehensmodelle, um dann das für uns passende auszuwählen.“ Requirements Engineer Sarah ergänzt in ihrer stets gewinnenden Art: „Wir möchten in einer ersten Phase die Anforderungen an das Produkt erarbeiten. Deshalb fokussiere ich immer wieder auf die Verortung und die Details des Prozesses der Anforderungsanalyse im Rahmen der dargelegten Projektvorgehensmodelle.“

Hansruedi Tremp

2. Systemdenken und Modellbildung verstehen

Zusammenfassung

John, unser Senior Software Engineer, führt die Gedanken zum Systemdenken und der damit verbundenen Modellbildung gleich selbst im Kick-Off-Meeting aus: „Jedes erdenkliche Ding können wir als ein System betrachten. Dies hilft uns, die wesentlichen Gesichtspunkte des Aufbaus, der Beziehungen und der Schnittstellen sauber zu abstrahieren und die Komplexität besser zu beherrschen. Damit wir die statischen und dynamischen Aspekte eines Systems visuell darlegen und auch kommunizieren können, stehen uns entsprechende Modellierungssprachen zur Verfügung. Im Rahmen von Informationssystemen hat sich die Unified Modeling Language (UML) durchgesetzt. Gerne gebe ich eine Einführung in die beiden Themenkreise.“

Hansruedi Tremp

3. Die Anforderungsanalyse initialisieren

Zusammenfassung

Beate, unsere Projektleiterin, lenkt in dem noch andauernden Kick-Off-Meeting die Aufmerksamkeit des Projektteams auf die konkreten Inhalte des Projektes: „In einem ersten Schritt ist es wichtig, dass wir alle eine gemeinsame Vision des zu erstellenden Softwareproduktes erhalten. Dazu wird uns Sarah, unsere Requirements Engineer, eine Produktbeschreibung mit einem Kontextdiagramm erstellen und erläutern.“ Sarah ergänzt dazu: „Zur Initialisierung der Anforderungsanalyse ist es entscheidend, die Anforderungsquellen zu kennen und im Rahmen einer Stakeholderanalyse alle involvierten Personen des Projektes zu identifizieren und so den Projekt-Setup sauber vornehmen.“

Hansruedi Tremp

4. Anforderungen ermitteln

Zusammenfassung

Die Projektvision steht und der Auftraggeber hat das Projekt im Rahmen des dargelegten Budgets frei gegeben. Sarah, unsere Requirements Engineer, bemerkt süffisant: „Die Kunst ist es, an die relevanten Anforderungen heranzukommen. Leider werden uns diese nicht auf einem Silbertablett präsentiert.“ Beate, die Projektleiterin, tröstet: „Wir kennen immerhin die Stakeholder und haben einen guten Überblick über deren Beziehungen und Interessen.“ „Das stimmt“, entgegnet Sarah. „Wir planen somit im nächsten Schritt die Anforderungsermittlung im Detail, damit wir möglichst ökonomisch die relevanten Informationen erhalten und alle betroffenen Stakeholder miteinbezogen haben. Wir müssen danach noch den Blick über den Tellerrand wagen und das gesamte Projektumfeld analysieren und alle relevanten Informationen berücksichtigen.“

Hansruedi Tremp

5. Strukturierter Anforderungskatalog pflegen

Zusammenfassung

Die ersten Interviews und Workshops sind durchgeführt. Im nächsten Projektmeeting geht Sarah, unsere Requirements Engineer, auf die gestellte Frage nach einem zentralen strukturieren Anforderungskatalog ein: „Jede erhobene Anforderung müssen wir in den Projektkontext einordnen und sauber dokumentieren. Dies lässt sich ohne ein webfähiges Anforderungsmanagement Tool nicht bewerkstelligen. Gerne gebe ich einen Überblick der möglichen zu erhebenden Attribute und der zielgruppenspezifischen Anforderungsspezifikation. Ein Blick auf die Anforderungsmanagement Tools rundet meinen Input ab.“

Hansruedi Tremp

6. Nicht-funktionale Anforderungen festlegen

Zusammenfassung

Jan, unser IT-Security Spezialist, hat im letzten Team-Meeting die Erhebung der Qualitätsanforderungen angesprochen. Sarah, unser Requirements Engineer, legt dem Team im aktuellen Meeting die nächsten Schritte dar: „Die Ermittlung der nicht-funktionalen Anforderungen ist entscheidend, ob in Zukunft das System seine Leistung zur Zufriedenheit der Anwender erbringt. Für die Festlegung der Anforderungen an die Qualität des Systems benötigen wir jedoch einige Spezialisten, die uns unterstützen, wie z. B. Jan, Julia, unsere User Interface-Spezialistin und andere. Wir orientieren uns dabei an den acht Kriterien des ISO/IEC 25010 Software Produkt Qualitätsmodell.“

Hansruedi Tremp

7. Funktionale Anforderungen spezifizieren

Zusammenfassung

Felix, unser Webservice-Entwickler hat die Frage zu dem, was das neue Softwaresystem eigentlich leisten soll, bereits in die Runde geworfen. Sarah, unsere Requirements Engineer, gibt dem Team das Big Picture für den weiteren Verlauf: „Im nächsten Schritt konzentrierten wir uns nun auf die funktionalen Anforderungen. Diese Aktivität läuft jedoch iterativ, d. h. in einer ersten Phase stellen wir funktionale Anforderungen verbal zusammen und erstellen ein Anwendungsfallmodell. Dies gibt uns einen guten Überblick über die Hauptfunktionen, die beteiligten Benutzergruppen und die Schnittstellen zu den Umsystemen. Danach arbeiten wir inkrementell weiter und beschreiben die funktionalen Anforderungen in Epics und brechen diese in User Stories herunter. Im zugeordneten Sprint zur Implementierung verfeinert und ergänzt das Scrum-Team die Anforderungen während der Realisierung.“

Hansruedi Tremp

8. Demonstrationsprototyp erstellen

Zusammenfassung

Eine Menge von nicht-funktionalen und funktionalen Anforderungen sind erhoben. Julia, unsere UX-Entwicklerin, legt dem Team den nächsten Vertiefungsschritt dar: „Die beschriebenen Anwendungsfälle und User Stories sind für das Verständnis der Anwender zu abstrakt. Mit einem Demonstrationsprototypen, heute oft auch Wireframe genannt, haben wir die Möglichkeit, ein konkretes Look and Feel zu geben, welches die Validierung entscheidend unterstützt. Dabei müssen wir uns mit den speziellen Aktivitäten des Usability Engineering auseinandersetzen, wie z. B. das Visual und Interaction Design.“

Hansruedi Tremp

9. Informationsanalyse vornehmen

Zusammenfassung

Die funktionalen Anforderungen sind in der ganzen Breite des Problemraumes und der aktuell notwendigen Tiefe erhoben und dokumentiert. Am Teammeeting meldet sich Jonas, unser Datenbankspezialist, und führt uns die nächsten Schritte aus: „Es wird Zeit, die ganze Thematik objektorientiert zu analysieren und in einem ersten Schritt die Informationsanalyse mittels des Klassendiagramms vorzunehmen. Wir können uns dem Thema in mehreren Detaillierungsstufen nähern. Zuerst gibt uns das Geschäftsobjektdiagramm einen Überblick. Mit dem Fachklassendiagramm erfassen wir danach alle aus dem Business relevanten Klassen mit den dazugehörigen Eigenschaften und Beziehungen. Dies gibt uns die Basis für die Datenhaltung in einem Datenbankmanagementsystem. In den einzelnen Scrum-Sprints können wir die relevanten Bereiche aus dem Fachklassendiagramm weiter in einem umfassenden Analyseklassendiagramm detaillieren und dann den Schritt in den Entwurf der Software und der Erstellung des Entwurfsklassendiagramms für die unmittelbare Programmierung vornehmen.“

Hansruedi Tremp

10. Dynamisches Analysemodell erarbeiten

Zusammenfassung

Im Rahmen der OOA – Objektorientierten Analyse steht die erste Version des Fachklassendiagramms. Julia, unsere UX-Entwicklerin, meldet sich beim heutigen Meeting zu Worte: „Für die Verwendung der Service-Schnittstelle möchte ich mit Felix zusammen die Objektinteraktion genauer untersuchen und grafisch in einem Sequenzdiagramm darstellen.“ Felix, unser Webservice-Entwickler stimmt zu: „Genau, da bin ich gerne mit dabei. Weiter analysiere ich den Prozessablauf einiger wichtiger Anwendungsfälle und zeichne diese mittels eines Aktivitätsdiagramms auf.“ Jonas, unser Datenbankspezialist, ergänzt: „Da wir am Erstellen des dynamischen Analysemodells sind, möchte ich mit Sarah zusammen die Zustände und Übergänge der zentralen Klassen mit dem Zustandsdiagramm untersuchen.“

Hansruedi Tremp

11. Qualität sicherstellen

Zusammenfassung

Sämtliche Lieferobjekte der Anforderungsanalyse sind in der ganzen Breite und der aktuell notwendigen Tiefe erstellt. Manfred, unser Testmanager, hat in diesem Teammeeting das Wort: „Um den Erfolg der Implementation zu garantieren, müssen wir die Qualität aller erstellten Dokumente, Modelle und Demonstrationsprototypen sicherstellen. Wir untersuchen und konsolidieren zuerst allfällige Konflikte. Danach unterziehen wir die wichtigen Artefakte den entsprechenden Reviews und Walkthroughs, um sowohl die Verifikation als auch die Validierung vorzunehmen. Dabei erstellen wir auch die Testspezifikationen für den Acceptance Test und machen uns über die Testplanung erste Gedanken.“

Hansruedi Tremp

Backmatter

Titel: Agile objektorientierte Anforderungsanalyse
verfasst von: Hansruedi Tremp
Verlag: Springer Fachmedien Wiesbaden
Electronic ISBN: 978-3-658-37194-4
Print ISBN: 978-3-658-37193-7
DOI: https://doi.org/10.1007/978-3-658-37194-4