Prozess und Arbeitsstruktur
- Andreas Meyer
Inhalt dieser Lerneinheit:
Grundlagen
Zur Gestaltung und Strukturierung der in einem gegebenen Kontext zu leistenden RE-Arbeit ist ein Prozess erforderlich. Da es keinen „one-size-fits-all“ RE-Prozess gibt (vgl. LE 1.4), muss ein maßgeschneiderter RE-Prozess konfiguriert werden, der zum gegebenen Entwicklungs- und Systemkontext passt.
Der RE-Prozess gestaltet den Informationsfluss und das Kommunikationsmodell zwischen verschiedenen Beteiligten (z.B. Kunden, Anwender, Requirements Engineers, Entwickler, Tester) und definiert auch die zu verwendenden oder zu erstellenden Arbeitsprodukte. Somit bietet der RE-Prozess den Rahmen für das Erheben, Dokumentieren, Validieren und Verwalten von Anforderungen
Einflussfaktoren
Viele Faktoren beeinflussen die Konfiguration eines RE-Prozesses. Die wichtigsten Faktoren sind:
Eignung im Gesamtprozess: Der RE-Prozess muss zum gesamten Systementwicklungsprozess passen.
Entwicklungskontext
Fähigkeit und Verfügbarkeit von Stakeholdern
Gemeinsames Verständnis
Komplexität und Kritikalität des zu entwickelnden Systems
Randbedingungen
Verfügbare Zeit und Budget
Volatilität von Anforderungen
Erfahrung der Requirements Engineers
- Quelle: Basiswissen Requirements Engineering 3.0
Eine Analyse der Einflussfaktoren gibt Aufschluss darüber, wie der RE-Prozess zu gestalten ist. Die Einflussfaktoren schränken auch den Raum der möglichen Prozesskonfigurationen ein. Wenn z.B. die Stakeholder nur zu Beginn des Projekts zur Verfügung stehen, kann kein Prozess gewählt werden, der auf kontinuierlichem Feedback der Stakeholder aufbaut.
Facetten von Requirements Engineering Prozessen
Es gibt drei entscheidende Facetten, die bei der Konfiguration eines RE-Prozesses berücksichtigt werden müssen [Glin2019].
Zeitfacette: Linear versus Iterativ
In einem linearen Prozess werden Anforderungen im Vorfeld in einer einzelnen Phase des Prozesses spezifiziert. In einem iterativen Prozess werden Anforderungen schrittweise spezifiziert, wobei mit allgemeinen Zielen und einigen anfänglichen Anforderungen begonnen wird und dann in jeder Iteration Anforderungen hinzugefügt oder geändert werden.
Kriterien für die Wahl eines linearen RE-Prozesses:
Der Entwicklungsprozess für das System ist planbasiert und weitgehend linear.
Die Stakeholder kennen ihre Anforderungen und können diese im Voraus spezifizieren.
Eine umfassende Anforderungsspezifikation ist als vertragliche Grundlage für die Fremdvergabe des Designs und der Implementierung des Systems erforderlich.
Die Regulierungsbehörden verlangen eine umfassende, formell freigegebene Anforderungsspezifikation in einem frühen Stadium der Entwicklung.
Zweckfacette: Präskriptiv versus Explorativ
In einem präskriptiven RE-Prozess stellt die Anforderungsspezifikation einen Vertrag dar: Alle Anforderungen sind verbindlich und müssen umgesetzt werden. In einem explorativen RE-Prozess sind nur die Ziele im Vorfeld bekannt, während die konkreten Anforderungen ermittelt werden müssen.
Kriterien für die Auswahl eines präskriptiven RE-Prozesses:
Der Kunde benötigt einen festen Vertrag für die Systementwicklung.
Funktionalität und Umfang haben Vorrang vor Kosten und Terminen.
Die Entwicklung des spezifizierten Systems kann ausgeschrieben oder ausgelagert werden.
Kriterien für die Auswahl eines explorativen RE-Prozesses:
Die Stakeholder haben zunächst nur eine vage Vorstellung ihrer Anforderungen.
Die Stakeholder sind stark involviert und liefern kontinuierliches Feedback.
Termine und Kosten haben Vorrang vor Funktionalität und Umfang.
Es ist nicht von vornherein klar, welche Anforderungen tatsächlich umgesetzt werden sollen und in welcher Reihenfolge sie umgesetzt werden.
Zielfacette: Kundenspezifisch versus Marktorientiert
In einem kundenspezifischen RE-Prozess wird das System von einem Kunden bestellt und von einem Lieferanten entwickelt. In einem marktorientierten RE-Prozess wird das System als Produkt oder Service für einen Markt entwickelt, ausgerichtet auf bestimmte Nutzersegmente.
Kriterien für die Wahl eines kundenspezifischen RE-Prozesses:
Das System wird hauptsächlich von der Organisation genutzt, die das System bestellt hat und für seine Entwicklung bezahlt.
Die wichtigen Stakeholder sind hauptsächlich mit der Organisation des Kunden verbunden.
Für die Stakeholder-Rollen können konkrete Personen identifiziert werden.
Der Kunde wünscht eine Anforderungsspezifikation, die als Vertrag dienen kann.
Kriterien für die Auswahl eines marktorientierten RE-Prozesses:
Die entwickelnde Organisation beabsichtigt, das System in einem bestimmten Marktsegment als Produkt oder Dienstleistung zu verkaufen.Künftige Benutzer sind nicht eindeutig identifizierbar.
Die Anforderungsingenieure müssen die Anforderungen so gestalten, dass sie den erwarteten
Bedürfnissen der Zielnutzer entsprechen.
Product Owner, Marketingpersonen, Digital Designer und Systemarchitekten sind die primären Stakeholder.
Konfigurieren eines Requirements Engineering Prozesses
In einem konkreten Systementwicklungskontext müssen die für das RE verantwortlichen Personen den anzuwendenden RE-Prozess konfigurieren. Basierend auf einer Analyse der Einflussfaktoren kann eine geeignete Kombination der in LE 5.2 beschriebenen Prozessfacetten eingesetzt werden [Glin2019]. Im Folgenden beschreiben wir drei typische Kombinationen.
Partizipativer RE-Prozess: Iterativ & explorativ & kundenspezifisch
Hauptanwendungsfall: Lieferant und Kunde arbeiten eng zusammen; Die Stakeholder sind sowohl in den RE- als auch in den Entwicklungsprozess stark eingebunden.
Typische Arbeitsprodukte: Produkt-Backlog mit User Storys und/oder Aufgabenbeschreibungen, Prototypen
Typischer Informationsfluss: Kontinuierliche Interaktion zwischen Stakeholdern, Product Ownern, Requirements Engineers und Entwicklern; kann Rückmeldungen von Anwendern beinhalten
Vertraglicher RE-Prozess: Typischerweise linear (manchmal iterativ) & präskriptiv & kundenspezifisch
Hauptanwendungsfall: Die Anforderungsspezifikation stellt die vertragliche Grundlage für die Entwicklung eines Systems durch Personen dar, die nicht an der Spezifikation beteiligt sind, und mit nur wenig Interaktion mit den Stakeholdern nach der Anforderungsphase.
Typische Arbeitsprodukte: Klassische System-Anforderungsspezifikation, bestehend aus natürlichsprachigen Anforderungen und Modellen
Typischer Informationsfluss: Hauptsächlich von den Stakeholdern zu den Requirements Engineers
Produktorientierter RE-Prozess: Iterativ & explorativ & marktorientiert
Hauptanwendungsfall: Eine Organisation spezifiziert und entwickelt Software, um sie als Produkt oder Service zu verkaufen oder zu vertreiben.
Typische Arbeitsprodukte: Produkt-Backlog, Prototypen
Typischer Informationsfluss: Interaktion zwischen Product Ownern, Marketing, Requirements Engineers, Digital Designern, Entwicklern und (vielleicht) schnellem Feedback von Kunden/Benutzern
Beachten Sie, dass es System- und Entwicklungstkontexte geben kann, bei denen keine der oben genannten Konfigurationen passt. Zum Beispiel können regulatorische Vorgaben die Verwendung eines Verfahrens vorschreiben, das mit bestimmten Normen wie ISO/IEC/IEEE 29148 [ISO29148] konform ist.
Bei der Konfiguration eines RE-Prozesses empfehlen wir ein fünfstufiges Vorgehen:
Analysieren der Einflussfaktoren
Beurteilen der Facettenkriterien
Konfigurieren des Prozesses
Arbeitsprodukte bestimmen
Geeignete Praktiken auswählen