Geschäftsanforderungen

Geschäftsanforderungen ( auch bekannt als Stakeholder-Anforderungsspezifikationen, StRS) beschreiben die Eigenschaften eines geplanten Systems aus Sicht des Endnutzers, ähnlich einem Einsatzkonzept ( CONOPS) . Produkte, Systeme, Software und Prozesse dienen dazu , Geschäftsanforderungen zu erfüllen oder zu realisieren. Daher werden Geschäftsanforderungen häufig im Kontext der Entwicklung oder Beschaffung von Software oder anderen Systemen diskutiert.

Drei Hauptgründe für solche Diskussionen:

1. Eine gängige Praxis ist es, Ziele oder erwartete Vorteile als „Geschäftsanforderungen“ zu bezeichnen. ^{[ 1 ]}
2. Im allgemeinen Sprachgebrauch wird der Begriff „Anforderungen“ verwendet, um die Merkmale des Produkts, Systems oder der Software zu beschreiben, die erstellt werden sollen.
3. Ein weit verbreitetes Modell behauptet, dass sich diese beiden Arten von Anforderungen nur in ihrem Detaillierungsgrad bzw. Abstraktionsgrad unterscheiden – wobei „Geschäftsanforderungen“ eher allgemein gehalten, häufig vage sind und sich in die detaillierten Produkt-, System- oder Softwareanforderungen aufschlüsseln lassen.

Laut Robin F. Goldsmith lassen sich solche Missverständnisse vermeiden, indem man erkennt, dass Geschäftsanforderungen keine Ziele sind, sondern vielmehr Ziele erfüllen (d. h. Wert schaffen), wenn sie erfüllt sind. Geschäftsanforderungen lassen sich nicht in Produkt-/System-/Softwareanforderungen zerlegen . Vielmehr stellen Produkte und ihre Anforderungen eine Antwort auf Geschäftsanforderungen dar – vermutlich die Frage, wie man was erfüllt . Geschäftsanforderungen existieren im Geschäftsumfeld und müssen ermittelt werden, während Produktanforderungen vom Menschen definiert (spezifiziert) werden. Geschäftsanforderungen beschränken sich nicht auf eine abstrakte Betrachtungsweise, sondern müssen bis ins Detail ausgearbeitet werden. Ungeachtet ihres Detaillierungsgrades sind Geschäftsanforderungen jedoch immer geschäftsrelevante Ergebnisse, die Wert schaffen, wenn sie erfüllt sind; die Ausarbeitung ins Detail verwandelt Geschäftsanforderungen niemals in Produktanforderungen. ^{[ 2 ]}

In System- oder Softwareentwicklungsprojekten benötigen Geschäftsanforderungen in der Regel die Zustimmung der Stakeholder. Dies führt typischerweise zur Erstellung oder Aktualisierung eines Produkts, Systems oder einer Software. Die Produkt-/System-/Softwareanforderungen umfassen üblicherweise sowohl funktionale als auch nicht-funktionale Anforderungen . Obwohl nicht-funktionale Anforderungen typischerweise in Verbindung mit der Produkt-/System-/Softwarefunktionalität (Funktionen und Nutzung) definiert werden, spiegeln sie oft eine Form von Geschäftsanforderungen wider, die mitunter als Einschränkungen betrachtet werden. Dazu gehören beispielsweise notwendige Leistungs-, Sicherheits- oder Schutzaspekte, die auf Geschäftsebene relevant sind.

Geschäftsanforderungen werden häufig in einem Business Requirements Document (BRD) festgehalten. Der Schwerpunkt eines BRD liegt auf dem Prozess der präzisen Erfassung, Planung und Entwicklung der Anforderungen, nicht auf deren Umsetzung. Letztere wird üblicherweise in einem Systems Requirements Specification Document (SRS oder SRD) oder einer anderen Variante wie einem Functional Specification Document beschrieben. Verwechslungen zwischen BRD und SRD können entstehen, wenn die Unterscheidung zwischen Geschäftsanforderungen und Systemanforderungen nicht beachtet wird. Daher beschreiben viele BRDs tatsächlich die Anforderungen an ein Produkt, ein System oder eine Software.

Im Kontext der Softwareentwicklung bzw. des Softwarelebenszyklus bezeichnet der Begriff „Geschäftsanforderungen“ das Konzept, die Geschäftsanforderungen von Anwendern wie Kunden, Mitarbeitern und Lieferanten frühzeitig im Entwicklungszyklus eines Systems zu erfassen und zu dokumentieren, um die Gestaltung des zukünftigen Systems zu steuern. Geschäftsanforderungen werden häufig von Business-Analysten erfasst , die Geschäftsaktivitäten und -prozesse analysieren und den Ist-Zustand untersuchen, um einen Soll-Zustand zu definieren.

Zu den Geschäftsanforderungen gehören häufig:

• Geschäftlicher Kontext, Umfang und Hintergrund, einschließlich der Gründe ^{[ 3 ]} für die Änderung
• Wichtige Geschäftspartner, die Anforderungen haben
• Erfolgsfaktoren für einen zukünftigen/Zielzustand
• Einschränkungen, die vom Unternehmen oder anderen Systemen auferlegt werden
• Geschäftsprozessmodelle und -analysen, oft unter Verwendung von Flussdiagrammen, um entweder Ist- oder Soll-Geschäftsprozesse darzustellen.
• Referenzen zu konzeptionellen Datenmodellen und Datenwörterbüchern
• Glossare von Geschäftsbegriffen und lokalem Jargon
• Datenflussdiagramme zur Veranschaulichung des Datenflusses durch die Informationssysteme (im Gegensatz zu Flussdiagrammen, die den algorithmischen Ablauf von Geschäftsaktivitäten darstellen).

Geschäftliche Anforderungen werden typischerweise von Business-Analysten in Zusammenarbeit mit anderen Projektbeteiligten definiert .

Beide Parteien können für die Ermittlung der Geschäftsanforderungen und die Entwicklung technischer Lösungen verantwortlich sein. Business-Analysten sind in der Regel an der Entwicklung des Implementierungsansatzes und dem Management der Auswirkungen auf alle Geschäftsbereiche beteiligt, einschließlich der Einbindung von Stakeholdern und des Risikomanagements.

Traditionelle BRD-Struktur - [ 4 ]

Titel Version Beschreibung der Änderung Autor Datum Inhalt Einführung Zweck Umfang Hintergrund Referenzen Annahmen und Einschränkungen Dokumentübersicht Methodik Funktionale Anforderungen Kontext Benutzeranforderungen Datenflussdiagramme Logisches Datenmodell / Datenwörterbuch Weitere Anforderungen Schnittstellenanforderungen Anforderungen an die Datenkonvertierung Hardware-/Softwareanforderungen Betriebliche Anforderungen Anhang A -

Das gängigste Format zur Erfassung von Geschäftsanforderungen ist das Business Requirements Document (BRD). Ziel des BRD ist es, die gewünschten Ergebnisse eines Systems zu definieren, unabhängig von dessen letztendlicher Gestaltung. Daher werden BRD-Dokumente durch ein Systems Reference Document (SRD) oder ein Technical Design Document (TDD) ergänzt, das Design, Technologieleistung und Infrastrukturerwartungen detailliert beschreibt. Dies umfasst auch alle (nicht-funktionalen) Technologieanforderungen zur Servicequalität, wie z. B. Leistung, Wartbarkeit, Anpassungsfähigkeit, Zuverlässigkeit, Verfügbarkeit, Sicherheit und Skalierbarkeit.

Die Entwicklung von Prototypen mit frühzeitigen Tests ermöglicht die Überprüfung der Vollständigkeit und Genauigkeit der erfassten Geschäftsanforderungen. Stakeholder werden frühzeitig eingebunden, um die Anforderungen zu definieren. Die Ergebnisse werden an die Projektentwicklungsteams weitergeleitet, die das Geschäftssystem entwickeln. Weitere Stakeholder testen und evaluieren das finale System. Für Klarheit ist es notwendig, die Anforderungen und ihre Lösungen zu dokumentieren und einen formalen Prozess zur Bestimmung der geeigneten Vorlage zu implementieren. Der Umfang der Geschäftsanforderungen beschränkt sich nicht auf die Definition des zu entwickelnden Geschäftssystems. Er umfasst auch die Planung der Verwaltung und Wartung eines laufenden Geschäftssystems sowie die Sicherstellung seiner fortlaufenden Ausrichtung an den Geschäftszielen und der Strategie. Ein Dokument mit Geschäftsanforderungen muss kontinuierlich und kontrolliert überarbeitet werden. Ein standardisiertes Format oder Vorlagen für spezifische Geschäftsfunktionen und -bereiche gewährleisten die Vollständigkeit der Geschäftsanforderungen und helfen, den Fokus auf den Umfang zu richten.

Obwohl Prototyping häufig als Mittel zur Anforderungsbewertung gilt, lenkt es den Fokus in der Regel von den Geschäftsanforderungen auf das zu entwickelnde Produkt, System oder die Software. Prototypen sind funktionsfähige Software und somit drei Schritte (Produkt-/System-/Softwareanforderungen, technisches Design und Implementierung des Designs im Programmcode) von den Geschäftsanforderungen entfernt. Prototypen sind vorläufige Versionen der Software, die der Entwickler implementieren möchte. Da Prototypen relativ konkret sind, können Stakeholder, die den Prototyp testen, wertvolleres Feedback zu Aspekten der Entwicklerlösung geben. Dieses Feedback spiegelt die Interpretation des Entwicklers wider, wie die Geschäftsanforderungen erfüllt werden sollen, nicht die Geschäftsanforderungen selbst. Um frühzeitig und schnell einen Prototyp zu erstellen, wird zudem die grafische Benutzeroberfläche (GUI) betont, während die eigentliche Programmlogik vernachlässigt wird. Die eigentliche Programmlogik umfasst den Großteil der Software und beinhaltet die meisten Geschäftsanforderungen. Anders ausgedrückt: Probleme, die Prototypen aufdecken, betreffen höchstwahrscheinlich nicht die Geschäftsanforderungen.

Es ist wichtig, Änderungen der Anforderungen zu erkennen, zu dokumentieren und die Anforderungsdefinitionen aktuell zu halten. Allerdings ändern sich Geschäftsanforderungen tendenziell weniger als das Bewusstsein dafür. Eine Geschäftsanforderung kann vorhanden sein, aber von den Stakeholdern, Analysten und dem Projektteam nicht erkannt oder verstanden werden. Veränderungen werden deutlicher bei den sogenannten „Anforderungsänderungen“ – den Produkt-/System-/Softwareanforderungen. Diese spiegeln oft die vermeintlichen Wege zur Erfüllung unzureichend identifizierter Geschäftsanforderungen wider. Viele der Schwierigkeiten bei der Erfüllung von Geschäftsanforderungen spiegeln die gängige Praxis wider, fast den gesamten Aufwand für die „Anforderungen“ dem High-Level-Design eines Produkts, Systems oder einer Software zu widmen. Dies rührt daher, dass die Geschäftsanforderungen, die das Produkt/System/die Software erfüllen muss, um Wert zu schaffen, nicht ausreichend definiert werden. Entwicklungspraktiken überarbeiten das Produkt/System/die Software häufig so lange, bis sie schließlich eine Lösung finden, die scheinbar das Notwendige tut, d. h. eine Geschäftsanforderung erfüllt. Solche kostspieligen , indirekten Methoden, die auf Versuch und Irrtum beruhen, um Geschäftsanforderungen zu ermitteln, bilden die Grundlage für einen Großteil der „iterativen Entwicklung“, einschließlich der populären agilen Entwicklungsmethoden, die als „Best Practices“ angepriesen werden.

Vorlagen helfen dabei, Anfragen zu bestimmten Themen zu stellen, die häufig für Geschäftsanforderungen relevant sind. Sie können eine standardisierte Dokumentation der Geschäftsanforderungen fördern und so das Verständnis erleichtern. Vorlagen gewährleisten jedoch weder die Genauigkeit noch die Vollständigkeit der Geschäftsanforderungen. Im Gegenteil: Häufig falsch eingesetzt, wirken sich Vorlagen sogar negativ auf die Anforderungsanalyse aus, da sie dazu neigen, Oberflächlichkeit und vorwiegend mechanische Definitionen ohne fundierte Analyse zu begünstigen.

Geschäftsanforderungen werden aufgrund der Vielzahl an Stakeholdern, die an ihrer Definition beteiligt sind, oft voreilig festgelegt, was zu Interessenkonflikten führen kann. Die Konsensfindung kann sich als heikel und mitunter sogar politisch erweisen. Eine weniger häufige, aber dennoch größere Herausforderung stellen verteilte Teams mit Stakeholdern an verschiedenen Standorten dar. Vertriebsmitarbeiter sind naturgemäß näher an ihren Kunden, Produktionsmitarbeiter näher an den Fertigungsstätten und Finanz- und Personalabteilung sowie die Geschäftsleitung näher am Firmensitz. In einem System, das beispielsweise Vertriebs- und Produktionsnutzer einbezieht, kann es zu Zielkonflikten kommen: Die eine Seite möchte maximale Funktionen bieten, die andere hingegen die Produktionskosten minimieren . Solche Situationen führen oft zu einem Konsens, der maximale Funktionen zu angemessenen und rentablen Produktions- und Vertriebskosten bietet.

Um diese Herausforderungen zu bewältigen, wird die frühzeitige Einbindung der Stakeholder durch die Präsentation von Prototypen und die gemeinsame Arbeit erreicht. Stakeholder-Workshops sind üblich – entweder als moderierte Sitzungen oder in Form von offenen Gesprächsrunden –, um einen Konsens zu erzielen, insbesondere bei sensiblen Geschäftsanforderungen und potenziellen Interessenkonflikten. Die Komplexität eines Geschäftsprozesses spielt dabei eine Rolle. Dies kann spezialisiertes Wissen erfordern, um rechtliche oder regulatorische Anforderungen, interne unternehmensweite Richtlinien wie Branding oder die Verpflichtungen des Unternehmens zur sozialen Verantwortung zu verstehen. Die Analyse von Geschäftsanforderungen beschränkt sich nicht nur darauf, das „Was“ eines Geschäftsprozesses und das „Wie“ zu erfassen, um seinen Kontext zu liefern. Auch die Umsetzung in die Konzeption und den Aufbau eines funktionierenden Systems muss berücksichtigt werden. In dieser Phase müssen die Geschäftsanforderungen technische Details und die Machbarkeit einbeziehen.

Eine maßgeschneiderte Lösung ist nicht immer für alle neuen Geschäftsanforderungen erforderlich. Oftmals stehen standardisierte Prozesse und Produkte zur Verfügung, die mit einigen Anpassungen oder Individualisierungen die Geschäftsanforderungen erfüllen können. Das Zielsystem ist häufig durch eine bestimmte Technologieauswahl, ein Budget oder bereits eingesetzte Produkte eingeschränkt.

Schließlich kann die Standardisierung des Formats Schwierigkeiten bereiten. Mehrere Projekte mit unterschiedlichen Formaten, die zu Variationen in Struktur und Inhalt eines Anforderungsdokuments führen, machen dieses aus Sicht der Nachvollziehbarkeit und Verwaltbarkeit ineffektiv. Tatsächlich kann es bei der Erstellung einer Vorlage für die funktionsübergreifende Anforderungserhebung schwierig sein, dass verschiedene Rollen mit sich ergänzendem Wissen innerhalb eines gemeinsamen Formats arbeiten. Daher ist es entscheidend, dass auch nicht spezialisierte oder nicht fachkundige Stakeholder zusätzliche Anforderungen über Anhänge und weitere Dokumente einreichen können, um ihren Spezifikationsbereich abzudecken. Die Berücksichtigung verschiedener Nuancen und die Erreichung der optimalen Lösung bleibt die größte Herausforderung für ein effektives Anforderungsmanagement.

Beinhaltet die folgenden Schritte:

1. Geschäftsdefinition
2. Geschäftsbereich(e) verstehen
3. Organisationsziele
4. Kernkompetenz

• Lebenszyklus der Systementwicklung
• Systemtechnik
• Softwareentwicklungsprozess
• Business-Analyst
• Software-Anforderungsspezifikation
• Anforderungsanalyse
• Erfordernis
• Software-Prototyping
• Geschäftsanalyse

• Beal, Adriana. Anforderungen sind das, was wir tun müssen, um ein Ziel zu erreichen. www.bealprojects.com , 2012
• Goldsmith, Robin F. Die Ermittlung realer Geschäftsanforderungen für den Erfolg von Softwareprojekten . Artech House, 2004.
• Project Management Institute (2021). Ein Leitfaden zum Projektmanagement-Wissensbestand (PMBOK Guide) . Project Management Institute (7. Aufl.). Newtown Square, PA. ISBN 978-1-62825-664-2Die{{cite book}}CS1 Wartung: Standort des fehlenden Herausgebers ( Link )
• Robertson, Suzanne und James C. Robertson. Mastering the Requirements Process . 2. Auflage, Addison-Wesley, 2006.