Was sind Geschäfts-, Stakeholder-, Lösungsanforderungen und User Stories

Was sind IT-Anforderungen?

In der Welt der Technologie streiten wir uns seit Anbeginn des Computerzeitalters über den Begriff „Anforderungen“. Jeder Unternehmensanalytiker, Projektmanager und Softwareentwickler hat seine eigene Auffassung von Anforderungen.

Manche von uns sind begeistert, manche finden sie schrecklich. Für die einen sind sie das Herz und die Seele eines Projekts, für die anderen der Fluch der Softwareentwicklung.

Grundsätzlich ist eine Anforderung aber einfach eine Aussage, die Grenzen für die Softwarelösung setzt, die den geschäftlichen Anforderungen gerecht wird.

Eine Herausforderung bei der Erfassung von Anforderungen besteht darin, dass der Detaillierungsgrad je nach Quelle unterschiedlich ist.

Einen Geschäftsinhaber oder eine hochrangige Führungskraft nach ihren Anforderungen zu fragen, ist etwas anderes als jemanden zu fragen, der direkt mit der Lösung interagieren wird, oder die Person zu fragen, die das Produkt oder die Anwendung programmieren muss.

Zu den Projektbeteiligten gehören drei verschiedene Personengruppen:

• Erstens die Führungskräfte und Sponsoren, denen das Projekt am Herzen liegt und die es zum Erfolg führen wollen.
• Die zweite Gruppe sind die Stakeholder, die die Befugnis haben, auf jedes in der Entwicklung befindliche Produkt Einfluss zu nehmen (einschließlich der Personen, die das Produkt nach seiner Freigabe nutzen werden)
• Schließlich sind da noch die Entwickler, die das Produkt entwickeln werden. Für sie sind Details über Ihre geschäftlichen Anforderungen und Ziele wichtig, damit sie ein besseres Produkt entwickeln können.

Um den Bedürfnissen aller drei Gruppen gerecht zu werden, hat das IIBA® (International Institute of Business Analysis™) drei Anforderungsebenen definiert:

• Geschäfts-Anforderungen (Business Requirements)
• Stakeholder-Anforderungen (Stakeholder Requirements)
• Lösungs-Anforderungen (Solution Requirements)

Schauen wir uns die einzelnen Level an:

Geschäftsanforderungen sind das Ergebnis einer strategischen Geschäftsanalyse (Business Analysis)

Historisch gesehen (z. B. in einem Wasserfallansatz) war die Strategic Business Analysis die Vorarbeit, die einem Projekt oder einer Initiative vorausging.

Der Zweck der strategischen Business Analyse bestand darin, den Umfang und das Ziel der vorgeschlagenen IT-Projekte klar zu definieren. Wenn die anfängliche Durchführbarkeitsanalyse ergab, dass das Projekt wahrscheinlich kein positives Ergebnis für die Organisation bringen würde, wurde es abgebrochen. Wurde das Projekt genehmigt, lieferte die strategische Geschäftsanalyse high-level Business Requirements (Geschäftsanforderungen).

Die strategische Business Analyse ist nicht nur auf die Bereitstellung von Anforderungen für neue Softwareentwicklungsprojekte beschränkt. Sie kann auch zur Unterstützung bestehender Softwareprojekte eingesetzt werden, indem sie Verbesserungsmöglichkeiten aufzeigt.

Wenn ein Unternehmen beispielsweise seit 20 Jahren ein Buchhaltungssystem verwendet und nun Funktionen wie Bestandsverfolgung oder Lagerverwaltung hinzufügen möchte, kann die Business Analyse Hinweise darauf geben, welche neuen Funktionen diese enthalten sollten und wie sie in der bestehenden Umgebung funktionieren sollten.

Strategische Business-Analyse: Definition des Fachgebiets

Bei der strategischen Geschäftsanalyse arbeitet man oft funktionsübergreifend mit Mitgliedern verschiedener Abteilungen wie Finanzen und Vertrieb sowie mit anderen Geschäftsbereichen wie Marketing oder Operations zusammen. Dabei steht immer die Wertschöpfung aus IT-Investitionen durch effektive Prozessverbesserungen und Kostensenkungen im Vordergrund.

Ob Sie es nun „Strategische Business Analyse“ nennen oder nicht und ob Sie „Geschäftsanforderungen“ erstellen oder nicht, jemand muss entscheiden, ob er ein bestimmtes Problem lösen oder eine Gelegenheit nutzen will.

Entscheidungsträger auf dieser Detailebene sind in der Regel leitende Angestellte oder Eigentümer der Organisation. Auf dieser hohen Ebene hat die Softwareentwicklungsmethode (SDM) nur begrenzten Einfluss auf den Entscheidungsprozess.

Ein neu gegründetes Marketingunternehmen könnte zum Beispiel folgende geschäftliche Anforderung haben:

Bis Ende 2023 werden wir unseren Marktanteil durch aggressive Nutzung von Social Media um 25 % steigern.

Diese Struktur spezifiziert:

• WAS die Organisation erreichen möchte (Marktanteil um 25 % steigern)
• WANN sie es erreichen wollen (bis Ende 2023)
• WIE sie es erreichen wollen (durch aggressive Nutzung von Social Media)

Indem Sie sowohl das Ziel (WAS) als auch den Zeitrahmen (WANN) in messbaren Begriffen ausdrücken, sind Sie besser in der Lage, Ihre Fortschritte zu messen.

Ihre Unternehmensziele sollten SMART sein

Ein guter Leitfaden für das Schreiben von Geschäftsanforderungen ist das Akronym SMART. Es steht für Specific, Measurable, Achievable, Relevant, Time-bound (Spezifisch, Messbar, Erreichbar, Relevant und Termingebunden).

Geschäftsanforderungen werden in erster Linie von der Geschäftsleitung verwendet, um zu entscheiden, ob sie bereit ist, Ressourcen zu investieren, um das gewünschte Ergebnis zu erzielen.

Was sind Stakeholder Anforderungen?

Die nächste Anforderungsstufe nach IIBA® sind die Stakeholder-Anforderungen. Stakeholder-Anforderungen drücken ein Feature, eine Funktion, einen Fakt oder ein Verhalten aus, das einer Untergruppe von Personen innerhalb der Organisation zugute kommt.

Ein Stakeholder ist entweder eine Person, eine Gruppe oder eine Organisationseinheit (z. B. eine Abteilung, ein Bereich usw.), die von dem vorgeschlagenen Softwareprodukt betroffen ist oder die Befugnis hat, dieses zu beeinflussen. Sie können innerhalb oder außerhalb der Organisation stehen, die die Initiative oder das Projekt sponsert.

Ein gutes Beispiel für eine Stakeholder-Anforderung wäre:

Ein Fluggast kann die verfügbaren Sitzplätze einsehen und nach Bezahlung des Tickets eine Präferenz auswählen.

Diese Stakeholder-Anforderung gibt an, wer der Nutzer ist (Fluggast), was der Stakeholder tun möchte (verfügbare Sitzplätze einsehen), den geschäftlichen Nutzen für den Stakeholder (Präferenz auswählen) und eine einschränkende Bedingung (nach Bezahlung des Tickets).

Sie informiert die Entwickler darüber, wer was will, warum er es will und unter welchen Umständen die Anforderung erfüllt werden kann. Das sind wichtige Schlüsselkriterien für jede Stakeholder-Anforderung.

Lösungsanforderungen: Entwickler brauchen funktionale und nicht-funktionale Anforderungen

Geschäfts- und Stakeholder-Anforderungen sind wichtig, aber sie reichen nicht aus. Wenn Softwareentwickler und andere Mitglieder des technischen Teams ein Programm erstellen wollen, benötigen sie mehr Details – die Art von Details, die das International Institute of Business Analysis (IIBA®) als Solution Requirements oder Lösungsanforderungen bezeichnet. Diese werden in zwei Subtypen unterteilt – funktionale und nicht-funktionale Anforderungen.

Funktionale Anforderungen (Functional Requirements – FR)

Funktionsanforderungen beschreiben, was das Produkt, die App oder ein Benutzer tun oder wissen muss.

Das heißt, sie beschreiben:

• Funktionen, die die Software ausführen soll, z. B. „Sitzplatz reservieren“ ODER
• Daten, die die Funktion benötigt, z. B. „Verfügbare Plätze“ oder Daten, die sie erzeugt, z. B. „Reservierter Platz“.

Hier ein Beispiel für eine Funktionale Anforderung:

Die Gesamtsumme der Rechnung einschließlich Lieferkosten und Steuern berechnen.

Es besagt, dass das Produkt oder die Anwendung in der Lage sein muss, eine Funktion auszuführen (Gesamtsumme berechnen), die die Lieferkosten (Daten) und Steuern (Daten) auf einer Rechnung (Daten) berechnet.

Nichtfunktionale Anforderungen (Non-functional Requirements – NFR)

Damit eine Software überhaupt von praktischem Nutzen ist, reicht es alledings  nicht aus, dass ein Programm funktional ist – es muss so funktionieren, dass es für die Menschen, die es tatsächlich benutzen, nützlich ist.

Wenn Sie zum Beispiel ein Programm schreiben, das Ihnen sagt, wie viele Kalorien Ihre Pizza hat, würde es niemand benutzen, wenn es jedes Mal 10 Minuten zum Laden bräuchte, wenn Sie die Kalorienzahl Ihres Essens überprüfen wollen. Genau aus diesem Grund sind nichtfunktionale Anforderungen so wichtig: Sie stellen sicher, dass die Software von den Personen, die sie nutzen werden, auch effektiv genutzt werden kann.

Während sich funktionale Anforderungen darauf konzentrieren, „WAS“ eine Funktion oder Komponente tun soll, beschreiben nichtfunktionale Anforderungen, auch bekannt als Non-functional Requirements oder kurz NFRs, eine Erwartung an das „WIE GUT“ der Funktion.

Der Begriff „nicht-funktional“ bedeutet, dass diese Metriken andere als funktionale Parameter beschreiben. NFRs beschreiben Qualitätsmerkmale wie Robustheit, Leistung, Benutzerfreundlichkeit, Zugänglichkeit und Attribute, die für Endbenutzer wichtig sind.

Nichtfunktionale Anforderungen sind daher ein wichtiger Bestandteil der SRS (Software Requirements Spezifikation).  

Nicht-funktionale Anforderungen werden manchmal auch als Qualitätsattribute bezeichnet

Diese Arten von Anforderungen werden in der Regel in vollständigen Sätzen ausgedrückt und mit den relevanten Business-, Stakeholder- oder Funktionsanforderungen verknüpft.

Beachten Sie beim Schreiben einer NFR die folgenden Best Practices:

• Fügen Sie Metriken ein, die sich auf Leistung und Verhalten beziehen.
• Verwenden Sie keine subjektiven Begriffe wie „einfach“ oder „klar“.
• Konzentrieren Sie sich auf die Leistung und nicht auf die Funktionalität.
• Fassen Sie sich kurz und prägnant (am besten in 1-3 Sätzen).

Wie Sie sehen, ist die Erfüllung der Kriterien einer NFR-Spezifikation eigentlich sehr einfach. Indem Sie Ihre Anforderungen mit Ihren Geschäftszielen verknüpfen, stellen Sie sicher, dass sie auch im weiteren Verlauf Ihres Projekts noch relevant und sinnvoll sind.

Wer sich eingehender mit diesem Thema befassen möchte, sollte meinen Beitrag „Funktionale und nicht-funktionale Anforderungen: Was sind sie und wie erstellt man sie?“ lesen. 

Die Herausforderung bei Lösungsanforderungen / Spezifikationen

Die Lösungsanforderungen sind die Detailstufe, die die meisten Entwickler benötigen, um mit der Programmierung zu beginnen.

In traditionellen Entwicklungsumgebungen (z. B. Wasserfall) werden alle drei Detailebenen (Geschäfts-, Stakeholder- und Lösungsanforderungen) für das gesamte Projekt erstellt, bevor eine Zeile Code geschrieben wird. Dies ermöglicht eine recht genaue Schätzung des Gesamtaufwands, der für die Bereitstellung der Lösung erforderlich ist.

Das Programmieren und Testen der gesamten digitalen Lösung kann jedoch Monate dauern. Aufgrund geänderter Geschäftsanforderungen, sich weiterentwickelnder Technologien oder Geschäftsumgebungen haben viele der angeforderten Funktionen zum Zeitpunkt ihrer Bereitstellung keine Priorität mehr.

Agile Unternehmensanalyse unterstützt die schlanke Softwareentwicklung

Post-Mortem-Bewertungen von Millionen von IT-Projekten zeigen, dass die Mehrheit der ursprünglich definierten Funktionen nie geliefert wird. Der Aufwand für das Ermitteln, Erfassen, Klären und Erstellen der Anforderungen, die diese Funktionen definieren, stellt eine erhebliche, aber unnötige Verschwendung dar.

Lean- und agile Softwareentwicklungsphilosophien und agile Business-Analyse-Techniken wurden entwickelt, um genau dieses Problem anzugehen.

Angela and I created a 46-minute video called „What is Lean or Agile Business Analysis“ if you want to learn more.

Sind User Stories Stakeholder-Anforderungen?

Der größte Teil des vergeudeten Aufwands bei traditionellen Anforderungen wurde durch den Prozess der Übersetzung von Stakeholder-Anforderungen in Lösungsanforderungen / Software Spezifikationen verursacht.

User Stories sind eine alternative Methode, um die geschäftlichen Anforderungen von Einzelpersonen auszudrücken und diese Verschwendung zu reduzieren oder idealerweise zu eliminieren. Während das Wort „Anforderung“ etwas suggeriert, das ein absoluter Bedarf ist, ist die User Story per Definition „… eine Erinnerung an ein Gespräch zwischen einem Entwickler und einem Benutzer …“.

Diese Definition impliziert, dass eine User Story der Interpretation unterliegt. Die (dokumentierten oder nicht dokumentierten) funktionalen und nicht-funktionalen Lösungsanforderungen sind das Ergebnis dieses Gesprächs.

Um den überflüssigen Aufwand zu vermeiden, der mit der Klärung von Anforderungen verbunden ist, die nie umgesetzt werden, findet das Gespräch unmittelbar vor dem Beginn der Programmierung statt.

Das Ergebnis der User Story Methode ist eine bessere Kommunikation zwischen Stakeholdern und Entwicklern, die zu einem größeren Verständnis und Vertrauen zwischen ihnen führt.

User Stories sind eines der wertvollsten Werkzeuge in der agilen Entwicklung

Sie helfen uns, miteinander zu kommunizieren, sie helfen uns, über unser System nachzudenken, sie helfen uns bei der Planung, und beim Design des Systems.

User Stories drücken etwas aus, das die Geschäftswelt haben MÖCHTE, vorausgesetzt, die IT kann es in einem angemessenen Zeitrahmen liefern. Der Schwerpunkt liegt jedoch auf der Einfachheit. Die User Story drückt lediglich aus, was eine Rolle in der Business Community von der IT benötigt.

Der Hauptvorteil von User Stories besteht darin, dass sie den Teams helfen, sich auf die Bereitstellung von Werten zu konzentrieren, anstatt sich in technischen Details oder anderen Ablenkungen zu verlieren. Indem sie sich darauf konzentrieren, was der Kunde will, und nicht darauf, wie es gemacht wird, können die Teams zusammenarbeiten, um Lösungen schneller zu liefern.

Letztlich brauchen die Entwickler aber immer noch technische Spezifikationen. Der Unterschied in der modernen Softwareentwicklung besteht darin, dass Spezifikationen erst dann erstellt werden, wenn sie benötigt werden, und nicht schon Monate oder sogar Jahre im Voraus, wie es bei traditionellen Anforderungen der Fall war.

Es gibt noch viel mehr über User Stories zu sagen! Um mehr zu erfahren, lesen Sie bitte meinen Beitrag User Story Best Practices: Ein Leitfaden für agile Anforderungen.

Vielen Dank fürs Lesen!

Die wichtigste Erkenntnis ist, dass Sie das tun sollten, was Ihr Projekt und Ihr Team erfolgreich macht. Manchmal bedeutet das die Verwendung von Agilen User Stories, manchmal die Verwendung von Traditionellen/Wasserfall-Anforderungen und manchmal die Kombination des Besten aus beiden Welten. Der Schlüssel ist herauszufinden, was für Ihr Team und Ihr Projekt am besten funktioniert.

Welcher Anforderungsansatz gefällt Ihnen am besten, und warum?

Ich würde mich sehr freuen, wenn Sie mir Ihre Meinung in den Kommentaren mitteilen würden.