2.5.1 Funktionale Anforderungen und Qualitätsattribute der Lösung

​Funktionale Anforderungen und Qualitätsattribute der Lösung

In diesem Abschnitt erfahren Sie, was funktionale Anforderungen sind und wie sie priorisiert werden. Wir haben bereits die Identifizierung geschäftlicher Anforderungen im Rahmen der Projektinitiierung und die Anforderungen an das Projektmanagement zu Beginn der Projektplanung besprochen. Nun, im weiteren Verlauf unserer Projektplanung, richten wir unser Augenmerk auf die funktionalen Anforderungen und die Qualitätsattribute der zu erstellenden Lösung.

Lassen Sie uns zunächst rekapitulieren, was wir unter Anforderungen verstehen. Sie umfassen spezifische Merkmale oder Bedingungen, die von Stakeholdern für ein bestimmtes Element verlangt werden, um deren Bedürfnisse zu erfüllen.

Die Erstellung einer umfassenden Liste von Anforderungen stellt eine anspruchsvolle Herausforderung dar und ist eine der Kernkompetenzen im Berufsfeld des Business-Analysten.

Einige dieser Herausforderungen bei den Anforderungen umfassen:

• Erstens: Wie zuverlässig und vollständig ist die Anforderungsliste, die wir erhalten, wenn wir die Stakeholder nach ihren Bedürfnissen fragen? Wie gehen wir mit Anforderungen um, die nach der Festlegung des Fortschrittsmessungsbasisplans definiert werden?
• Zweitens: Nicht alle Anforderungen sind gleich wichtig. Einige werden unverzichtbar sein, während andere optional sein können.
• Drittens: Da die Stakeholder eine kollektive Gruppe sind, werden ihre Anforderungen vielfältig und potenziell widersprüchlich sein, entsprechend verschiedenen Interessen und Bedürfnissen. Teil der Projektmanagementarbeit ist es, einen gemeinsamen Nenner und ein akzeptables Maß an kollektiver Übereinstimmung über die Merkmale der zu entwickelnden Lösung zu erreichen.
• Viertens: Wie können wir sicherstellen, dass die Anforderungsliste effektiv angewendet wird? Wie können wir sicher sein, dass wir nicht später, vielleicht zu spät, feststellen müssen, dass wir bestimmte Anforderungen vergessen haben?

Der Prozess zur Definition funktionaler Anforderungen und Qualitätsattribute verläuft typischerweise iterativ. Er startet mit einer initialen, allgemeinen Beschreibung der Anforderungen, die nach und nach zu detaillierten Spezifikationen ausgearbeitet werden. Diese frühe Phase der Anforderungsdefinition liefert die essenziellen Informationen, die nötig sind, um die Beschreibung des Projektinhalts- und -umfangs sowie den Projektstrukturplan (WBS) zu entwickeln und eine erste Schätzung von Aufwand, Kosten und Dauer vorzunehmen. Änderungen, die nach der Genehmigung des Leistungsmessungsbasis auftreten, werden durch einen etablierten Änderungsmanagementprozess oder eine Versionskontrolle geregelt, um sicherzustellen, dass auch spätere Anforderungen, die über die Erstlieferung hinausgehen, effektiv integriert werden können, besonders wenn der Produkttyp einen inkrementellen Entwicklungsansatz unterstützt.

Das technische Wort für das Sammeln von Anforderungen von Stakeholdern wird als Anforderungserhebung bezeichnet (Requirements Elicitation auf Englisch). Um genaue Anforderungen zu erreichen, müssen die Mitglieder des Projektteams, die als Businessanalysten agieren, die richtigen Fragen stellen, aufmerksam zuhören und die Antworten dokumentieren.

Erhebung von Anforderungen

Zur Erhebung von Anforderungen bieten sich verschiedene Methoden an:

• Interviews: Eine sehr gängige Methode, die sowohl in Einzel- als auch in Gruppengesprächen durchgeführt werden kann. Bei Gruppeninterviews kann professionelle Moderation hilfreich sein. Wenn direkte Gespräche mit vielen Endnutzern nicht möglich sind, können repräsentative Stichproben in Fokusgruppen befragt werden.
• JAD (Joint Application Development): Ein intensiver Workshop, in dem Stakeholder so lange zusammenarbeiten, bis eine vollständige und von allen akzeptierte Anforderungsliste erstellt ist. Dies erinnert an das Konklave zur Papstwahl, bei dem niemand den Raum verlässt, bis eine Einigung erzielt ist.
• Fragebögen und Online-Umfragen: Eignen sich, um standardisierte Informationen von einer größeren Gruppe entfernter Stakeholder zu sammeln.
• Prototypenentwicklung: Die Erstellung von Prototypen ist eine relativ moderne Technik zur Anforderungserfassung gemäß den agilen Prinzipien. Bei diesem Ansatz erhält das Team vorläufige Anforderungen, die zur Erstellung eines Prototyps der Lösung verwendet werden. Dieser Prototyp wird dann dem Kunden präsentiert, der daraufhin zusätzliche Anforderungen auf dieser greifbareren Basis stellt. Das Team nutzt diesen Ansatz, wie im Abschnitt über iterative und inkrementelle Lebenszyklen beschrieben. Diese Zyklen setzen sich fort, bis der Kunde angibt, dass genügend Anforderungen erfüllt wurden, oder für eine vorab vereinbarte Anzahl von Iterationen.
• Beobachtung: Die gezielte Beobachtung von Nutzern im Umgang mit bestehenden Systemen kann wertvolle Einblicke in Verbesserungspotenziale und unentdeckte Bedürfnisse bieten.

Nachverfolgbarkeit

Die Nachverfolgbarkeit spielt eine entscheidende Rolle im Entwicklungslebenszyklus einer umfangreichen Lösung, indem sie sicherstellt, dass alle Anforderungen über die verschiedenen Phasen hinweg verfolgt werden können. Bei inkrementellen Lebenszyklen, in denen jede Phase oder Iteration einen vollständigen Zyklus von Anforderungen, Design, Produktion und Tests umfasst, minimiert sich das Risiko, Anforderungen zu übersehen. In prädiktiven Ansätzen, die durch eine umfangreiche initiale Anforderungserhebungsphase gekennzeichnet sind, ist die Nachverfolgbarkeit unabdingbar, um die kontinuierliche Umsetzung der in der ersten Projektphase erhobenen Anforderungen durch die Design-, Entwicklungs-, Test- und Implementierungsphasen zu gewährleisten.

Ein effektives Werkzeug zur Gewährleistung der Nachverfolgbarkeit ist die Nachverfolgbarkeitsmatrix. Diese Matrix dient als visuelle Darstellung, die zeigt, wie jede Anforderung während der Designphase ein entsprechendes Designelement erhält. Weiterhin bestätigt die Matrix, dass jedes Designelement in der Produktionsphase realisiert, in der Testphase überprüft und letztlich implementiert wird. Umgekehrt hilft die Matrix dabei sicherzustellen, dass keine Elemente entworfen und produziert werden, die nicht den festgelegten Anforderungen entsprechen.

Ein beispielhafter Aufbau einer Nachverfolgbarkeitsmatrix könnte folgendermaßen aussehen:.

• Anforderung / Quelle: Jede Anforderung wird mit ihrer Quelle aufgeführt, beispielsweise von welchem Stakeholder oder aus welchem Dokument sie stammt.
• Designkomponenten: Für jede Anforderung werden die entsprechenden Designelemente aufgelistet.
• Entwicklungskomponenten: Hier werden die physischen oder digitalen Komponenten aufgeführt, die auf Basis der Designelemente entwickelt werden.
• Testkomponenten: Dieser Teil der Matrix zeigt, welche Tests durchgeführt werden, um die Erfüllung der Anforderungen zu überprüfen.

Die Nachverfolgbarkeitsmatrix ist nicht nur ein Instrument zur Überwachung, sondern auch zur Qualitätssicherung, indem sie gewährleistet, dass jede Anforderung im finalen Produkt berücksichtigt wird. Durch die Verwendung spezialisierter Softwarepakete kann die Verwaltung dieser Matrix und damit die Nachverfolgung der Anforderungen erheblich erleichtert werden.

Auswahl und Priorisierung von Anforderungen

Die MoSCoW-Methode ist eine effektive Priorisierungstechnik. Dabei steht MoSCoW für ein Akronym, das sich aus dem ersten Buchstaben jeder der vier Kategorien von Anforderungen zusammensetzt, die in absteigender Reihenfolge der Wichtigkeit klassifiziert sind. Auf Deutsch können diese vier abnehmenden Wichtigkeitsniveaus der Anforderungen als Niveau 1: Muss (unverzichtbar), Niveau 2: Sollte (wichtig), Niveau 3: Könnte (optional) und Niveau 4: Wird-nicht umgesetzt (unwesentlich) ausgedrückt werden.

Die wörtliche Übersetzung wäre „man muss haben“, „man sollte haben“, „man könnte haben“ und „man wird nicht haben“.

Die unverzichtbaren Anforderungen (Niveau 1: Muss) befinden sich auf der obersten Stufe der Wichtigkeit. Sie sind entscheidend für den Erfolg der Lösung oder Iteration. Das Fehlen auch nur einer einzigen unverzichtbaren Anforderung wird als Misserfolg angesehen. Bestimmte Anforderungen, die zunächst als wesentlich erachtet wurden, können später von den relevanten Stakeholdern herabgestuft werden, zum Beispiel wenn neue Anforderungen auftauchen, die als noch wichtiger angesehen werden.

Auf der zweiten Ebene stehen die wichtigen, jedoch nicht unverzichtbaren Anforderungen für die aktuelle Lieferung (Niveau 2: Sollte).

Beachten Sie, dass wir in unserem Beispiel in der Einheit über Projektinitiierung die MoSCoW-Technik verwenden konnten, um die Erfolgskriterien des Projekts zu definieren. Im Projektauftrag formulierten wir, dass das Projekt als erfolgreich betrachtet wird, wenn alle unverzichtbaren Anforderungen und 80 % der wichtigen Anforderungen umgesetzt werden, ohne bereits zu diesem Zeitpunkt zu wissen, welche konkreten Anforderungen als unverzichtbar und welche als wichtig eingestuft würden.

Auf der dritten Wichtigkeitsebene stehen die optionalen Anforderungen (Niveau 3: Könnte). Sie sind wünschenswert, aber weniger wichtig und sicherlich nicht wesentlich. Sie könnten die Benutzererfahrung zu geringen Entwicklungskosten verbessern. Diese Anforderungen werden in der Regel in die Lösung aufgenommen, wenn Zeit und Ressourcen dies zulassen.

Schließlich werden die unwesentlichen Anforderungen (Niveau 4: Wird-nicht umgesetzt) der vierten Wichtigkeitsebene zugewiesen. Diese Anforderungen werden nicht umgesetzt, da sie von den Stakeholdern als am wenigsten kritisch, rentabel oder notwendig für die Lösung oder für die aktuelle Lieferung angesehen werden. Möglicherweise werden sie in späteren Versionen der Lösung erneut in Betracht gezogen.

Abschließend ein kurzes Wort zum Unterschied zwischen funktionalen Anforderungen und Qualitätsattributen, auch bekannt als nicht-funktionale Anforderungen.

Funktionale Anforderungen beziehen sich auf Aktionen, das heißt, den Prozess, den ein System durchführen muss, während Qualitätsattribute sich darauf beziehen, wie ein System sein sollte oder auf Funktionsbeschränkungen.

Die nachfolgende Tabelle bietet Beispiele von Funktionalen Anforderungen und Qualitätsattribute.

„Bitte halten Sie das Video an und schauen Sie sich die folgende Tabelle an.“

Eine weitere wichtige Unterscheidung betrifft Anforderungen und Spezifikationen, da beide Begriffe manchmal als synonym verwendet werden. Sie sind zwar ähnlich, aber nicht identisch. Spezifikationen sind detaillierter und technischer als Anforderungen. Sie enthalten spezifische Maße, Materialien, Methoden und sogar Algorithmen, die während des Entwicklungsprozesses verwendet werden. Anforderungen hingegen beschreiben die allgemeinen Funktionen, die das System oder Produkt erfüllen muss, ohne sich auf die spezifische Implementierung einzulassen.

Rekapitulieren wir die hier behandelten Begriffe folgendermaßen: Die drei Elemente – funktionale Anforderungen, Qualitätsattribute und Spezifikationen – spielen unterschiedliche, aber miteinander verbundene Rollen in der Entwicklung und dem Design von Produkten oder Systemen:

• Funktionale Anforderungen: Diese definieren, was das Produkt oder System tun soll. Sie beschreiben die spezifischen Verhaltensweisen, Funktionen und Aufgaben, die das System ausführen muss, um die Bedürfnisse der Benutzer oder Stakeholder zu erfüllen.
• Qualitätsattribute: Auch als nicht-funktionale Anforderungen bekannt, beschreiben diese, wie das Produkt oder System sein soll. Sie betreffen die allgemeinen Eigenschaften und Merkmale des Systems, wie Leistung, Zuverlässigkeit, Benutzerfreundlichkeit, Sicherheit und Wartbarkeit, die beeinflussen, wie gut das System seine Aufgaben erfüllt.
• Spezifikationen: Dies sind detaillierte, technische Beschreibungen, die angeben, wie die funktionalen Anforderungen und Qualitätsattribute umgesetzt werden sollen. Sie bieten konkrete Anweisungen und Richtlinien für die Entwicklung und das Design des Produkts oder Systems, einschließlich Materialien, Architekturen, Algorithmen und technischen Standards, die befolgt werden müssen.

Die Zusammenfassung lautet wie folgt:

• Die Liste der funktionalen Anforderungen, also was das System tun muss, und die Qualitätsattribute, also wie das System sein soll, müssen von den relevanten Stakeholdern vereinbart werden, indem sie einer Priorisierungsmethode folgen, zum Beispiel der MoSCoW-Methode.
• Es stehen verschiedene Techniken zur Erhebung von Anforderungen zur Verfügung.
• Die Unzuverlässigkeit der anfänglich gesammelten Anforderungen kann die Notwendigkeit eines weniger prädiktiven und mehr iterativen oder inkrementellen Ansatzes für das gesamte Projekt bestimmen.
• Es ist wichtig, sicherzustellen, dass die gesammelten Anforderungen tatsächlich umgesetzt werden. Dazu kann eine Nachverfolgbarkeitsmatrix verwendet werden.