Skip to main content
main-content

2022 | Buch

Grundlagen der Anforderungsanalyse

Standardkonformes Requirements Engineering

share
TEILEN
insite
SUCHEN

Über dieses Buch

Dieses Buch zeigt ein systematisches, mit aktuellen Standards konformes Vorgehen für die gesamte Anforderungsanalyse bzw. das Requirements Engineering. Dieses Vorgehen wird durch konkrete Beispiele und zwei durchgängige, nicht zu einfache Fallstudien illustriert: das Buchportal und das Fitness-Armband. Die verwendeten Vorlagen sowie agilen und nichtagilen Techniken haben sich in der Praxis bewährt. So können Sie heute schon anfangen, diese Techniken anzuwenden!

Inhaltsverzeichnis

Frontmatter
1. Was ist Anforderungsanalyse und -verwaltung? *
Zusammenfassung
Requirements Engineering umfasst eine Menge von Tätigkeiten rund um die ingenieurmäßige Verarbeitung von Anforderungen. Requirements Engineering bzw. – deutsch – Anforderungsanalyse und -verwaltung findet überall dort statt, wo Wünsche und Bedürfnisse von Kunden oder einer Gruppe von Menschen berücksichtigt werden sollen. Uns interessiert in diesem Buch vor allem das Requirements Engineering während der ingenieurmäßigen Entwicklung von IT-Systemen, also Anforderungen an IT-Systeme.
Anforderungen sind im Grunde nichts anderes als die Beschreibung eines IT-Systems bevor es existiert. Zum ingenieurmäßigen Arbeiten gehört es dazu, dass man ein IT-System spezifiziert (also beschreibt), bevor man es entwickelt, als Grundlage für dessen Erstellung. Dies ist nötig, da technische Geräte üblicherweise nicht sehr flexibel an ständig wechselnde Wünsche des Kunden angepasst werden können und komplexe Systeme wohl durchdacht werden müssen und können.
Andrea Herrmann
2. Warum ist Anforderungsanalyse nötig und schwierig? *
Zusammenfassung
Dass in einem IT-Projekt programmiert werden muss, stellt nie jemand in Frage. Schließlich entsteht bei dieser Tätigkeit der Code, das System, das zu liefernde Ergebnis. Andere Tätigkeiten leiden jedoch an mangelnder Anerkennung, und dies trifft besonders die Anforderungsanalyse, aber auch die Qualitätssicherung und die Dokumentation. Diese Tätigkeiten benötigen ebenfalls einen nicht unerheblichen Anteil des Projektbudgets, sie produzieren jedoch scheinbar nur Papier. Tatsächlich erzeugen sie jedoch Wissen und Gewissheit. Ohne eine Anforderungsanalyse und ohne Qualitätssicherung kann nicht mal die schlichteste Internetseite in Betrieb gehen, weil immer der Programmierer erfahren muss, was gebraucht wird, und so gut wie immer Fehler passieren. Ohne Anforderungen und ohne Testen lässt sich zwar ein Produkt erstellen, aber es wird höchstwahrscheinlich weder nützlich noch gut.
Andrea Herrmann
3. Fallstudien *
Zusammenfassung
Um die Konzepte des Requirements Engineerings mit Leben zu füllen, werden wir sie anhand von zwei Fallstudien anwenden und illustrieren.
In der ersten Fallstudie, dem Buchportal, können Sie als Anforderungsanalytiker mit Ihren Ansprechpartnern beim Kunden die Anforderungen direkt besprechen und klären. Allerdings handelt es sich um Ansprechpartner, die leider keinerlei Erfahrung mit IT-Projekten haben und sich untereinander nicht einig sind. „Aber Sie machen das schon“, sagt Ihr Chef!
Das Ziel der zweiten Fallstudie besteht darin, ein neuartiges medizintechnisches Produkt zu entwickeln, das zukünftig hoffentlich möglichst viele Kunden kaufen. Sie sind der Produktmanager. Hier stellen sich wiederum ganz andere Fragen.
Andrea Herrmann
4. Ermitteln von Anforderungen *
Zusammenfassung
Das Ziel der Ermittlung von Anforderungen besteht darin, die Anforderungen zu kennen. Dazu muss man sie erfragen, finden, erfinden, rekonstruieren. Da die Anforderungen die Grundlage für Kostenschätzung und Zeitplanung, für Entwicklung und für Testen darstellen, sollten sie von Anfang an möglichst vollständig und richtig sein, also die tatsächlichen Bedürfnisse verständlich wiedergeben. Während der Ermittlung werden die Anforderungen darum oft bereits aufgeschrieben oder gezeichnet und konsolidiert.
Dabei können zahlreiche Fehler passieren, die sich teilweise später noch korrigieren lassen, teilweise aber auch nur mit teuren Nacharbeiten.
Was gilt es also zu beachten?
  • Zapfen Sie möglichst viele Quellen an, um Anforderungen zu ermitteln, so weit Ihr Budget es hergibt. Ausfiltern können Sie Anforderungen später immer noch.
  • Sammeln Sie alles: Notizen aus Literaturrecherchen, möglichst wortgetreue Besprechungsprotokolle, Fotos aus Workshops, Ideen und Gedankenblitze zwischendurch, offene Fragen, handschriftliche Skizzen vom Zeichenblock und vom Flipchart. Dieses Rohmaterial ist originaler als jede Ihrer Zusammenfassungen und Interpretationen.
  • Hören Sie gut zu! Das ist gar nicht so einfach, nachdem man sich eingelesen hat, selbst kreative Entwürfe skizziert und ähnliche Produkte schon benutzt hat. Dann passiert es ganz natürlich, dass man Anforderungen „überhört“, die nicht zu den eigenen Erwartungen passen, uminterpretiert und dem Kunden Wünsche unterstellt, die er nie gehabt hat. Gutes Zuhören ist sehr, sehr schwierig. Aber letztlich – so weh es Ihnen vielleicht tut – ist es nicht Ihre Software, sondern der Kunde bezahlt dafür, dass Sie genau seine Wünsche erfüllen. Verstehen Sie sich also als Dienstleister.
Andrea Herrmann
5. Anforderungsdokumentation*
Zusammenfassung
Wie oft hat Ihnen ein Dokument schon geholfen oder dessen Fehlen Probleme bereitet? Da hat man beim Einkaufen im Supermarkt etwas zu besorgen vergessen, weil es auf der Einkaufsliste fehlte. Anhand eines Besprechungsprotokolls konnten Sie nachweisen, dass Sie sich richtig erinnern. Beim Skizzieren eines Sachverhalts an der Tafel wurde klar, dass Sie und Ihr Gesprächspartner bisher aneinander vorbei geredet haben. Der Vertrag beweist, dass Sie ein Recht auf etwas haben.
Besonders wichtig ist es, so etwas Komplexes wie die Anforderungen an ein IT-System zu dokumentieren. Man spricht auch vom Spezifizieren. Eine Anforderungsspezifikation ist die Dokumentation von Anforderungen nach bestimmten Regeln.
In diesem Kapitel lernen Sie, Anforderungen auf unterschiedlichen Abstraktionsebenen zu spezifizieren, aus verschiedenen Perspektiven und mit unterschiedlichen Darstellungsformen, ob Use Case oder User Story, Entscheidungstabelle, UML-Diagramm oder Story Map.
Andrea Herrmann
6. Vorlagen für die Anforderungsspezifikation *
Zusammenfassung
Für die Spezifikation von Anforderungen werden gerne Vorlagen verwendet. In der agilen Entwicklung sind das die User Stories, während man klassisch für die vollständige und gründliche Spezifikation eines Systems eine umfangreiche Textvorlage verwendet, die oft schon ohne Inhalte zehn und mehr Seiten umfasst und ausgefüllt mehrere hundert (oder tausend).
In diesem Kapitel lernen Sie die Lastenheft-Vorlage nach IREB kennen, die wir auch für die beiden Fallstudien verwenden. Anschließend werden noch alternative Lastenheft-Vorlagen vorgestellt sowie Vorlagen für das Pflichtenheft.
Andrea Herrmann
7. Aufwand schätzen *
Zusammenfassung
Die Aufwände für ein Projekt zu schätzen, ist nicht unbedingt Teil des Requirements Engineering. Diese Aufgabe kann auch durch einen Projektleiter oder durch Entwickler durchgeführt werden. Die Anforderungen stellen aber oft die Grundlage für die Aufwands- und Kostenschätzung dar, weil zu einem frühen Zeitpunkt im Projekt keine konkreteren Informationen zur Verfügung stehen. Zuverlässiger wird die Kostenschätzung auf der Grundlage eines technischen Feinkonzeptes. Uns geht es hier jedoch nur im die Schätzung auf der Grundlage von Anforderungen.
Dazu lernen Sie die IFPUG Function Point Methode und die Use Case Points kennen, die wir auf unsere Fallstudie anwenden. Hinzu kommen agile Schätzmethoden wie Planning Poker und Bucket Estimation.
Andrea Herrmann
8. Anforderungen prüfen, verifizieren und validieren *
Zusammenfassung
Die Anforderungsprüfung hat das Ziel, die Qualität der Anforderungen sicherzustellen. Im Folgenden werden zuerst die Begriffe definiert und dann diskutiert, warum die Anforderungsprüfung regelmäßig wiederholt werden muss. Dann lernen Sie, welche Kriterien als Grundlage für die Qualitätsbewertung dienen können und anschließend einige Methoden für die Anforderungsverifikation und -Validierung wie Checklisten, Review, Perspektivenwechsel, Prototypen und Metriken.
Andrea Herrmann
9. Anforderungen priorisieren *
Zusammenfassung
Das Ziel der Anforderungspriorisierung besteht darin, zwischen wichtigen und unwichtigen Anforderungen zu unterscheiden. Ein Zwischenschritt dazu kann es sein, den Nutzen, die Kosten, die Risiken und die technische Machbarkeit der Anforderungen zu bewerten. Eine solche Priorisierung ist immer dann nötig, wenn das Budget des Projekts, Releases oder Sprints nicht für die Umsetzung aller Anforderungen genügt und diejenigen gesucht werden, die gestrichen oder auf später verschoben werden können. Gerade dann, wenn man iterativ arbeitet oder die Software in Releases (d. h. in regelmäßigen klar definierten Lieferständen) an Kunden ausliefert, muss für jede Iteration bzw. jedes Release entschieden werden, welche Anforderungen darin jeweils umgesetzt werden. Die Prioritäten von Anforderungen sind auch für den Tester interessant, damit er die wichtigsten Funktionalitäten besonders gründlich testet. Und wenn widersprüchliche Anforderungen nicht gleichermaßen gut realisiert werden können, muss man sich auf die wichtigere Anforderung konzentrieren. Oder man markiert alle sicherheitskritischen Anforderungen und unterzieht diese einer ausdrücklichen Risikobetrachtung.
In diesem Kapitel geht es um die Kriterien, nach denen Anforderungen bewertet werden können, um die verwendeten Skalentypen, verschiedene Techniken wie das Kano-Modell, paarweise Vergleiche (AHP und Bubble Sort) und die Nutzwertanalyse.
Andrea Herrmann
10. Anforderungen konsolidieren *
Zusammenfassung
Unsere Situation ist aktuell diese: Wir haben die Anforderungen ermittelt und dokumentiert, analysiert und priorisiert. Damit wissen wir genau, auf welchem Stand sich die Anforderungen befinden. Doch leider haben wir bei der Qualitätsprüfung Inkonsistenzen festgestellt, Prioritäten von Stakeholdergruppen unterscheiden sich, es gibt Zweifel an der Machbarkeit, oder der gewünschte Lieferumfang passt nicht ins vorgegebene Budget.
Diese Widersprüche und Inkonsistenzen müssen gelöst werden, also konsolidiert. Wir unterscheiden drei Arten von Widersprüchen, je nachdem, ob sie im Problem- oder Lösungsraum auftreten oder gelöst werden müssen. Dann geht es um Konsolidierungstechniken und Abstimmungsregeln. Auch das Quality Function Deployment (QFD) kann hier nützlich sein.
Andrea Herrmann
11. Anforderungen verwalten und ändern *
Zusammenfassung
In den bisherigen Kapiteln ging es darum, die Anforderungen zu ermitteln, zu dokumentieren und deren inhaltliche Qualität sicherzustellen. In einer Welt (oder einem Projekt), wo das Wasserfallvorgehen perfekt funktioniert, wären die Anforderungen nun fertig. Man würde die Anforderungen einfrieren, die dann als solide und stabile Grundlage für die nächsten Software Engineering Phasen dienen: Architektur, Programmieren, Testen. In der Realität wird es jedoch später noch Änderungen geben, sei es, weil der Kunde etwas übersehen hatte (Fehler im Problemraum) oder weil die Auftragnehmerseite die Machbarkeit falsch eingeschätzt hatte (Fehler im Lösungsraum). Es können sich jedoch auch Änderungen im Systemkontext auf die Anforderungen auswirken, beispielsweise eine Überarbeitung der zu unterstützenden Geschäftsprozesse oder der Erlass neuer Gesetze.
Wenn sich die tatsächlichen Anforderungen ändern, veralten die dokumentierten Anforderungen. Sobald man einzelne Anforderungen aktualisiert oder korrigiert, werden diese eventuell inkonsistent zu anderen Anforderungen, die mit geändert werden müssten.
Es muss also Mechanismen geben, mit deren Hilfe die Anforderungen aktuell und trotz Änderungen konsistent gehalten werden können, so dass die Stakeholder passend aufbereitete Informationen über den aktuellen Stand erhalten. Es kann auch nötig sein, Varianten von Anforderungen und ganze Produktlinien zu verwalten. Ein Hilfsmittel dafür sind Metainformationen über Anforderungen. Oft werden diese in Form von Anforderungsattributen oder Verweisen zwischen Anforderungen verwaltet. Eine Metainformation haben wir bereits kennen gelernt: die Priorität, die die Wichtigkeit einer Anforderung angibt, und als Grundlage für eine Vielzahl von anforderungsbezogenen Entscheidungen dient, wie z. B. die Releaseplanung.
Die Anforderungsverwaltung benötigt viel dringender als die Anforderungsanalyse Werkzeuge. Für die Umsetzung eines ordentlichen Anforderungsmanagements benötigen Sie ein Werkzeug, das es nicht nur erlaubt, den Anforderungen Attribute zuzuweisen und diese in Sichten darzustellen, sondern auch die Verfolgbarkeit mit Hilfe von Querverweisen zu verwalten. Die Anforderungsverwaltung weist eine Mehrdimensionalität auf über Abstraktionsebenen, Perspektiven, Abhängigkeiten, Varianten und in der zeitlichen Dimension über Versionen hinweg.
Die Anforderungsverwaltung verwaltet:
  • Attribute (Metainformationen),
  • Abhängigkeiten zwischen Anforderungen,
  • Versionen, Konfigurationen, Basislinien und Releases,
  • Varianten und Produktlinien,
  • Sichten und Berichte über Anforderungen,
  • Anforderungsänderungen,
  • den Requirements Engineering-Prozess.
Zunächst werden wir uns ansehen, wie Attribute, Verfolgbarkeit, Versionen und Varianten dokumentiert werden können, und danach darstellen, wie diese Informationen die weitere Anforderungsverwaltung unterstützen.
Andrea Herrmann
12. Werkzeuge *
Zusammenfassung
Im Prinzip können Sie Requirements Engineering am Flipchart und Kanban Board mit Freihandzeichnungen oder Story Cards auf papiernen Karteikarten durchführen. Aber bereits die Digitalisierung der Anforderungen bringt den Vorteil mit sich, diese zentral auf einem Computer ablegen zu können, diese mit anderen teilen zu können und sie gemeinsam oder abwechselnd Version für Version inkrementell weiter entwickeln zu können. Aber ein richtiges Requirements-Engineering-Werkzeug verwaltet Anforderungen samt ihren Attributen und Verfolgbarkeitsbeziehungen. Gerade auch die automatische Auswertung von Attributen ermöglicht es, schnell eine Übersicht über den aktuellen Stand der Anforderungen zu erstellen. Auch die Änderungsverwaltung und die Verfolgbarkeit auf der Ebene einzelner Anforderungen benötigt digitale Werkzeuge, die diese Mehrdimensionalität sinnvoll verwalten und darstellen können.
In der Praxis werden Anforderungen oft in Freitext und mit Hilfe einer normalen Textverarbeitungssoftware verarbeitet. Deren Vorteile liegen auf der Hand: Die Werkzeuge sind schon da, niemand muss sich erst einarbeiten, man kann sofort loslegen und alle können mitmachen, auch die Vertreter des Kunden. Allerdings bezahlt man diese anfänglichen Vorteile damit, dass eine strukturierte Verwaltung der Anforderungen nicht gegeben ist, insbesondere nicht die von Attributen, Traceability und Versionen. Die mehrdimensionale Komplexität der Verknüpfungen zwischen Anforderungen lässt sich „von Hand“ oder in einer einfachen Textdatei gar nicht verwalten, da Texte grundsätzlich nur eindimensional sind und Verknüpfungen zwischen den Elementen desselben Dokuments oder verschiedener Versionen dieses Dokuments nur schwer herzustellen und aktuell zu halten sind, insbesondere nicht bidirektional. Dann passieren solche Dinge wie z. B. dass Änderungen von einem Autor gemacht und von den anderen übersehen werden, eine Änderung Inkonsistenzen in die Spezifikation hineinbringt, oder dass verschiedene Beteiligte mit unterschiedlichen Versionen des Dokuments arbeiten.
Es kann ein praktischer Kompromiss sein, im Problemraum mit einem Freitextdokument und im Lösungsraum mit einem sauberen Anforderungsmodell, Attributen, Verfolgbarkeit, Änderungsverwaltung und Sichten zu arbeiten.
In diesem Kapitel diskutieren wir Kriterien für die Werkzeugauswahl und dann separat Werkzeuge für die Anforderungsermittlung, für die Spezifikation, fürs Prüfen, Verifizieren und Validieren, Priorisieren und für die agile und nichtagile Anforderungsverwaltung.
Andrea Herrmann
13. Schlusswort *
Zusammenfassung
Wir sind nun am Ende dieses Buchs über die Anforderungsanalyse angelangt. Sie haben gelernt, wie Sie Anforderungen ermitteln, von der Stakeholderanalyse, über Gespräche und Auswertung verschiedener Quellen bis zur Spezifikation. Sie wissen, wie Sie die Qualität von Anforderungen verifizieren und validieren, Anforderungen konsolidieren, priorisieren und verwalten. Theoretisch. Wenn Sie hinaus in die Realität der echten Softwareprojekte gehen, wird Sie der Praxisschock zweifach treffen: Erstens werden Sie feststellen, dass dort weniger systematisch gearbeitet wird als in diesem Lehrbuch empfohlen. Nicht versehentlich, sondern weil viele Praktiker nicht an die Wirksamkeit der dargestellten Techniken glauben. Zweitens werden Sie erfahren müssen, dass selbst bei sauberer Arbeitsweise und bestem Willen aller Beteiligten noch genügend schief gehen wird, weil die Anforderungsanalyse eine schwierige und komplexe Arbeit ist. Dabei lassen sich Fehler nicht ganz vermeiden. Hinzu kommt, dass nicht immer alle Beteiligten voll bei der Sache sind. Dies sollte jedoch nicht dazu führen, dass Sie den Glauben an die Anforderungsanalyse verlieren. Sie müssen bei der Anwendung die gelernten Techniken mit gesundem Menschenverstand und einer gewissen Gelassenheit kombinieren. Dann können Sie einschätzen, wo der Einsatz welcher Technik sinnvoll ist, und wo man auch mal fünf gerade sein lassen muss. Um die unvermeidlichen Fehler abzufangen, benötigen Sie Aufmerksamkeit, ein systematisches Vorgehen mit mehreren Qualitätssicherungsmaßnahmen und ein gutes Team. Viel Erfolg!
Andrea Herrmann
14. Anhang *
Zusammenfassung
Der Anhang enthält das Lastenheft mit den fachlichen Anforderungen an das Buchportal und das Lastenheft für die Fitness-App. So können Sie am konkreten Beispiel lernen.
Andrea Herrmann
Backmatter
Metadaten
Titel
Grundlagen der Anforderungsanalyse
verfasst von
Andrea Herrmann
Copyright-Jahr
2022
Electronic ISBN
978-3-658-35460-2
Print ISBN
978-3-658-35459-6
DOI
https://doi.org/10.1007/978-3-658-35460-2

Premium Partner