CPRE Foundation Level Handbuch (PDF)

5 Prozess und Arbeitsstruktur Immer dann, wenn systematisch gearbeitet werden muss, ist ein Prozess erforderlich, um die Arbeitsweise und die Erzeugung von Arbeitsprodukten zu gestalten und zu strukturieren. Definition 5.1. Process: A set of interrelated activities performed in a given order to proc...

5 Prozess und Arbeitsstruktur Immer dann, wenn systematisch gearbeitet werden muss, ist ein Prozess erforderlich, um die Arbeitsweise und die Erzeugung von Arbeitsprodukten zu gestalten und zu strukturieren. Definition 5.1. Process: A set of interrelated activities performed in a given order to process information or materials. Ein Requirements Engineering (RE)-Prozess organisiert, wie RE-Aufgaben unter Verwendung geeigneter Praktiken durchgeführt und die erforderlichen Arbeitsprodukte erzeugen werden. Es gibt jedoch keinen bewährten, universellen (one-size-fits-all) RE-Prozess (siehe Kapitel 1.4). Folglich müssen Requirements Engineers einen maßgeschneiderten RE-Prozess konfigurieren, der zur gegebenen Situation passt. Der RE-Prozess gestaltet den Informationsfluss und das Kommunikationsmodell zwischen den am RE Beteiligten (z.B. Kunden, Benutzer, Requirements Engineers, Entwickler und Tester). Er definiert auch die zu verwendenden oder zu erstellenden RE-Arbeitsprodukte. Ein guter RE-Prozess bietet den Rahmen, in dem Requirements Engineers Anforderungen ermitteln, dokumentieren, abstimmen und verwalten. In diesem Kapitel lernen Sie die Faktoren kennen, die den RE-Prozess beeinflussen und wie ein entsprechender Prozess aus einer Reihe von Prozessfacetten gestaltet werden kann. 5.1 Einflussfaktoren Es gibt eine Vielzahl von Einflussfaktoren, die bei der Gestaltung eines RE-Prozesses zu berücksichtigen sind. Vor der Konfiguration eines RE-Prozesses müssen diese Faktoren untersucht und analysiert werden. Einerseits liefert eine solche Analyse Informationen darüber, wie der RE-Prozess zu gestalten ist. Wenn die Analyse z.B. zeigt, dass die Stakeholder nur eine vage Vorstellung von ihren Anforderungen haben, sollte ein RE-Prozess gewählt werden, der die Erkundung der Anforderungen unterstützt. Auf der anderen Seite schränken die Einflussfaktoren auch den Raum der möglichen Prozesskonfigurationen ein. Wenn zum Beispiel die Stakeholder nur zu Beginn eines Systementwicklungsprojekts zur Verfügung stehen, wäre ein Prozess, der auf kontinuierlichem Feedback der Stakeholder aufbaut, nicht geeignet. Im Folgenden erörtern wir wichtige Faktoren für den RE-Prozess. Eignung im Gesamtprozess. Beim Definieren oder Konfigurieren eines RE-Prozesses ist es wichtig, den für das zu entwickelnde System gewählten Gesamtentwicklungsprozess zu kennen und zu verstehen - ein RE-Prozess, der nicht zum Gesamtprozess passt, ist Unsinn. Der Gesamtprozess kann Arbeitsprodukte erfordern, die der RE-Prozess liefern muss. Die für den RE-Prozess verwendete Terminologie sollte an die Terminologie des Foundation Level | Handbuch | © IREB 129 | 174 Gesamtprozesses angeglichen werden. Insbesondere muss die Terminologie für die Arbeitsprodukte angeglichen werden. Dies trägt dazu bei, Verwirrung und Missverständnisse zu vermeiden. Es erleichtert auch die Einführung des RE-Prozesses sowie die Schulung und das Coaching der Personen, die nach diesem Prozess arbeiten müssen. Wenn das System beispielsweise mit Hilfe eines linearen, planbasierten Prozesses entwickelt wird, der sich auf die Existenz einer umfassenden System-Anforderungsspezifikation und eines Systemglossars am Ende der Anforderungsphase stützt, muss der gewählte RE-Prozess in die Anforderungsphase des Gesamtprozesses passen und die beiden erforderlichen Arbeitsprodukte bereitstellen. Entwicklungskontext. Der Entwicklungskontext beeinflusst auch den RE-Prozess. Die zu berücksichtigenden Dinge umfassen die Beziehung Kunde-Lieferant-Benutzer, die Art der Entwicklung, Vertragsfragen und Vertrauen. Bei der Analyse des Entwicklungskontexts sind eine Reihe von Fragen zu beantworten: ▪ Kunden-Lieferant-Benutzer-Beziehung: Gibt es einen bestimmten Kunden, der das System bestellt und dafür bezahlt und einen Lieferanten, der das System entwickelt? Sind Kunde und Lieferant Teil derselben Organisation, oder gehören sie verschiedenen Organisationen an? Wenn Ersteres der Fall ist, welche Personen treten dann in der Rolle des Kunden und welche als Lieferant auf? Wer sind die Benutzer des Systems? Gehören die Benutzer zur Organisation des Kunden? Wenn nicht, nutzen sie das System als Produkt oder Dienstleistung für die Interaktion mit dem Kunden (z.B. im elektronischen Geschäftsverkehr), oder kaufen sie das System als Produkt oder Dienstleistung vom Kunden (z.B. eine mobile App)? ▪ Entwicklungstyp: Was ist der organisatorische Rahmen für die Entwicklung eines Systems? Häufige Typen umfassen: ▪ Ein Lieferant spezifiziert und entwickelt ein System für einen bestimmten Kunden, der das System verwenden wird. ▪ Eine Organisation entwickelt ein System mit der Absicht, es als Produkt oder Dienstleistung an viele Kunden in einem bestimmten Marktsegment zu verkaufen. ▪ Ein Lieferant konfiguriert ein System für einen Kunden aus einem Satz vorgefertigter Komponenten. Ein Anbieter verbessert und entwickelt ein bestehendes Produkt weiter. ▪ ▪ Vertrag: Gibt es einen Vertrag oder eine ähnliche Vereinbarung, der/die Leistungen, Kosten, Fristen, Verantwortlichkeiten usw. formal definiert? Verträge können klassische Festpreisverträge zwischen einem Kunden und einem Lieferanten mit fester Funktionalität, festen Fristen und Kosten sein, oder sie geben nur einen finanziellen Rahmen vor, während die Funktionalität iterativ definiert wird. ▪ Vertrauen: Vertrauen die beteiligten Parteien einander? Wenn z.B. Kunde und Lieferant einander nicht vertrauen, müssen die Anforderungen detaillierter spezifiziert werden als es in einer Vertrauensbeziehung notwendig wäre. Verfügbarkeit und Fähigkeit der Stakeholder. Die Verfügbarkeit von Stakeholdern schränkt die Konfigurationsmöglichkeiten für den RE-Prozess ein. Beispielsweise kann ein Prozess, Foundation Level | Handbuch | © IREB 130 | 174 der eine kontinuierliche enge Interaktion mit den Stakeholdern erfordert, nicht gewählt werden, wenn die zentralen Stakeholder zu Beginn des Prozesses nur für einen kurzen Zeitraum am Anfang des Prozesses zur Verfügung stehen. Auch die Fähigkeit der Stakeholder beeinflusst den Prozess: Je weniger die Stakeholder in der Lage sind, ihre Bedürfnisse klar zum Ausdruck zu bringen und je weniger sie ihre tatsächlichen Bedürfnisse kennen, desto mehr muss der RE-Prozess der Ermittlung der Anforderungen Rechnung tragen. Gemeinsames Verständnis. Es wird nur wenig Requirements Engineering benötigt, wenn ein hohes Maß an gemeinsamem Verständnis (siehe Kapitel 2, Prinzip 3) zwischen Stakeholdern, Requirements Engineers, Designern und Entwicklern über das Problem und die Anforderungen besteht. Folglich kann der RE-Prozess umso leichtgewichtiger sein, je besser das gemeinsame Verständnis ist [GlFr2015]. Komplexität und Kritikalität. Der Detaillierungsgrad, in dem die Anforderungen spezifiziert werden müssen, hängt stark von der Komplexität und Kritikalität des zu entwickelnden Systems ab. Wenn ein System in Bezug auf Nutzungssicherheit (Safety) und Informationssicherheit (Security) komplex und/oder kritisch ist, muss der gewählte REProzess eine detaillierte Spezifikation der kritischen Anforderungen berücksichtigen, einschließlich formaler oder halbformaler Modelle und starker Validierung - zum Beispiel durch die Verifizierung von Modellen, die ein vorgeschriebenes Verhalten ausdrücken, oder durch den Bau von Prototypen. Randbedingungen. Offensichtlich schränken alle Einflussfaktoren auch den Raum der möglichen Konfigurationen des RE-Prozesses ein. Wenn wir von Randbedingungen sprechen, meinen wir jene Randbedingungen, die explizit z.B. durch den Kunden oder eine Regulierungsbehörde auferlegt werden. Solche Randbedingungen können die obligatorische Erstellung bestimmter Arbeitsprodukte und die Befolgung eines obligatorischen Prozesses zur Erstellung dieser Arbeitsprodukte implizieren. Kunden oder Aufsichtsbehörden können auch einen RE-Prozess verlangen, der mit einem bestimmten Standard übereinstimmt. Verfügbare Zeit und Budget. Wenn Zeitpläne und Budget knapp bemessen sind, müssen die Zeit und das Budget, die für RE zur Verfügung stehen, klug genutzt werden, was in der Regel die Wahl eines leichtgewichtigen RE-Prozesses voraussetzt. Die Wahl eines iterativen REProzesses hilft bei der Priorisierung von Anforderungen und der Umsetzung der wichtigsten Anforderungen innerhalb des vorgegebenen Budgets und Zeitplans. Volatilität von Anforderungen. Wenn sich viele Anforderungen mit hoher Wahrscheinlichkeit ändern werden, ist es ratsam, einen änderungsfreundlichen RE-Prozess anzuwenden. Erfahrung der Requirements Engineers. Der gewählte RE-Prozess sollte den Kompetenzen und Erfahrungen der beteiligten Requirements Engineers entsprechen. Andernfalls müssen zusätzliche Zeit und Mittel für die Schulung und Betreuung des gewählten Prozesses bereitgestellt werden. Es ist besser, einen eher einfachen Prozess zu wählen, den die Requirements Engineers richtig handhaben können als einen ausgeklügelten und komplizierten Prozess, der sie überfordert. Foundation Level | Handbuch | © IREB 131 | 174 5.2 Facetten von Requirements Engineering Prozessen Es ist eine Verschwendung von Aufwand für jedes RE-Vorhaben den RE-Prozess von Grund auf neu zu definieren. Der Prozess sollte aus bereits vorhandenen Elementen konfiguriert werden, wann immer es die Einflussfaktoren zulassen. Um eine Anleitung zur Gestaltung eines guten RE-Prozesses zu geben, beschreiben wir drei Facetten mit jeweils zwei Ausprägungen, zusammen mit Auswahlkriterien, die für jede Ausprägung zu berücksichtigen sind [Glin2019]. Später, in Kapitel 5.3, verwenden wir diese Facetten, um RE-Prozesse zu konfigurieren. Abbildung 5.1 zeigt einen Überblick über die Facetten und Ausprägungen. Abbildung 5.1 Facetten des RE-Prozesses Die Facetten können so betrachtet werden, dass sie einen dreidimensionalen Raum von Optionen zur Prozesskonfiguration umfassen. Für jede Ausprägung einer Facette gibt es Kriterien für ihre Auswahl. Die Anwendbarkeit dieser Kriterien ergibt sich aus der Analyse der Einflussfaktoren, die oben in Kapitel 5.1 erörtert wurden. Beachten Sie, dass nicht alle Kriterien erfüllt sein müssen, um eine Ausprägung einer Facette auszuwählen. 5.2.1 Zeitfacette: Linear versus Iterativ Die Zeitfacette befasst sich mit der Organisation von RE-Aktivitäten auf einer Zeitskala. Wir unterscheiden zwischen linearen und iterativen Prozessen. In einem linearen RE Prozess werden Anforderungen im Vorfeld in einer einzelnen Phase des Prozesses spezifiziert. Die Idee besteht darin, eine umfassende Anforderungsspezifikation zu erstellen, die keine oder nur geringe Anpassungen oder wenige Änderungen während der Foundation Level | Handbuch | © IREB 132 | 174 Konzeption und Implementierung des Systems erfordert. Eine im Vorfeld erstellte umfassende Anforderungsspezifikation erfordert einen umfassenden Prozess. Daher sind lineare RE-Prozesse in den meisten Fällen schwergewichtige Prozesse. Kriterien für die Wahl eines linearen RE-Prozesses: ▪ Der Entwicklungsprozess für das System ist planbasiert und weitgehend linear. ▪ Die Stakeholder sind verfügbar, kennen ihre Anforderungen und können diese im Voraus spezifizieren. ▪ Eine umfassende Anforderungsspezifikation ist als vertragliche Grundlage für die Fremdvergabe oder Ausschreibung der Konzeption und der Implementierung des Systems erforderlich. ▪ Die Regulierungsbehörden verlangen eine umfassende, formell freigegebene Anforderungsspezifikation in einem frühen Stadium der Entwicklung. In einem iterativen RE 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. Die Idee besteht darin, die Spezifikation der Anforderungen mit der Konzeption und der Implementierung des Systems zu verknüpfen. Aufgrund kurzer Rückkopplungsschleifen und der Fähigkeit, Veränderungen oder vergessene Dinge in späteren Iterationen zu berücksichtigen, können iterative REProzesse leichtgewichtige Prozesse sein. Kriterien für die Wahl eines iterativen RE-Prozesses: ▪ Der Entwicklungsprozess für das System ist iterativ und agil. ▪ Viele Anforderungen sind nicht im Voraus bekannt, sondern werden erst im Laufe der Entwicklung des Systems entstehen und sich entwickeln. ▪ ▪ Stakeholder stehen zur Verfügung, sodass kurze Rückkopplungsschleifen eingerichtet werden können, um das Risiko der Entwicklung eines falschen Systems zu mindern. Die Dauer der Entwicklung lässt mehr als nur ein oder zwei Iterationen zu. ▪ Die Möglichkeit zur leichten Änderung von Anforderungen ist wichtig. 5.2.2 Zweckfacette: Präskriptiv versus Explorativ Die Zweckfacette befasst sich mit dem Zweck und der Rolle der Anforderungen bei der Entwicklung eines Systems. Wir unterscheiden zwischen präskriptiven und explorativen REProzessen. In einem präskriptiven RE-Prozess stellt die Anforderungsspezifikation einen Vertrag dar: Alle Anforderungen sind verbindlich und müssen umgesetzt werden. Die Idee besteht darin, eine Anforderungsspezifikation zu erstellen, die ohne oder mit wenig weiterer Interaktion zwischen Stakeholdern und Entwicklern implementiert werden kann. Kriterien für die Auswahl eines präskriptiven RE-Prozesses: ▪ Der Kunde benötigt einen festen Vertrag für die Systementwicklung, oft mit fester Funktionalität, festem Umfang, festem Preis und festem Endetermin. Foundation Level | Handbuch | © IREB 133 | 174 ▪ Funktionalität und Umfang haben Vorrang vor Kosten und Terminen. ▪ Die Entwicklung des spezifizierten Systems kann ausgeschrieben oder ausgelagert werden. In einem explorativen RE-Prozess sind nur die Ziele im Vorfeld bekannt, während die konkreten Anforderungen ermittelt werden müssen. Zugrunde liegt die Idee, dass die Anforderungen häufig nicht a priori bekannt sind, sondern erst ermittelt werden müssen. 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. ▪ Der Kunde ist mit einem Rahmenvertrag über Ziele, Ressourcen und den zu zahlenden Preis für einen bestimmten Zeitraum oder eine bestimmte Anzahl von Iterationen einverstanden. ▪ Es ist nicht von vornherein klar, welche Anforderungen tatsächlich umgesetzt werden sollen und in welcher Reihenfolge sie umgesetzt werden. 5.2.3 Zielfacette: Kundenspezifisch versus Marktorientiert Die Zielfacette berücksichtigt die Art der Entwicklung: Auf welche Art von Entwicklung zielen wir mit dem RE-Prozess ab? Auf einer grundsätzlichen Ebene unterscheiden wir zwischen kundenspezifischen und marktorientierten RE-Prozessen. In einem kundenspezifischen RE-Prozess wird das System von einem Kunden bestellt und von einem Lieferanten für diesen Kunden entwickelt. Beachten Sie, dass der Lieferant und der Kunde Teil der gleichen Organisation sein können. Die Idee ist, dass der RE-Prozess die Kunden-Lieferanten-Beziehung widerspiegelt. 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. In einem marktorientierten RE-Prozess wird das System als Produkt oder Service für einen Markt entwickelt, ausgerichtet auf bestimmte Nutzersegmente. Die Idee ist, dass die Organisation, die das System entwickelt, auch den RE-Prozess steuert. Kriterien für die Auswahl eines marktorientierten RE-Prozesses: ▪ Die entwickelnde Organisation oder einer ihrer Kunden beabsichtigt, das System in einem bestimmten Marktsegment als Produkt oder Dienstleistung zu verkaufen. ▪ Künftige Benutzer sind nicht eindeutig identifizierbar. Foundation Level | Handbuch | © IREB 134 | 174 ▪ ▪ Die Requirements Engineers 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. 5.2.4 Hinweise und Warnungen Es ist wichtig zu beachten, dass die oben genannten Kriterien Heuristiken sind. Sie sollten nicht als feste Regeln betrachtet werden, die immer gelten. Beispielsweise erfolgt die Auslagerung der Entwicklung eines Systems eher mit einem präskriptiven als mit einem explorativen RE-Prozess. Dies liegt daran, dass der Vertrag zwischen Kunde und Lieferant in der Regel auf einer umfassenden Anforderungsspezifikation basiert. Es ist jedoch auch möglich, einen Outsourcing-Vertrag auf der Grundlage eines explorativen RE-Prozesses auszuhandeln. Es kann bei der Wahl bestimmter Ausprägungen von Prozessfacetten Voraussetzungen geben oder die Wahl kann Konsequenzen nach sich ziehen, die berücksichtigt werden müssen. Hier sind einige Beispiele: ▪ Lineare RE-Prozesse funktionieren nur, wenn ein durchdachtes Verfahren für sich ändernde Anforderungen vorhanden ist. ▪ Lineare RE-Prozesse implizieren lange Rückkopplungsschleifen. Es kann vom Schreiben einer Anforderung bis zur Beobachtung ihrer Auswirkungen im implementierten System Monate oder sogar Jahre dauern. Bei einem linearen REProzess muss eine intensive Validierung der Anforderungen erfolgen, um das Risiko der Entwicklung eines falschen Systems zu mindern. ▪ In einem marktorientierten Prozess ist das Feedback potenzieller Benutzer das einzige Mittel, um zu validieren, ob das Produkt tatsächlich die Bedürfnisse des anvisierten Benutzersegments erfüllt. ▪ In einem agilen Umfeld passt ein iterativer und explorativer RE-Prozess am besten. Iterationen haben eine feste Dauer (in der Regel 2-6 Wochen). Der Product Owner spielt eine zentrale Rolle im RE-Prozess, indem er die Stakeholder koordiniert, die REArbeitsprodukte organisiert und die Anforderungen an das Entwicklungsteam kommuniziert. Die drei oben erwähnten Facetten sind nicht völlig unabhängig voneinander. Die Wahl, die für eine Facette getroffen wird, kann Einfluss darauf haben, was in anderen Facetten gewählt werden kann oder sollte. Hier sind einige Beispiele: ▪ Linear und präskriptiv werden häufig zusammen gewählt, d.h. wenn Requirements Engineers sich für einen linearen RE-Prozess entscheiden, entscheiden sie sich in der Regel für einen Prozess, der sowohl linear als auch präskriptiv ist. ▪ Explorative RE-Prozesse sind typischerweise auch iterativ (und umgekehrt). ▪ Ein marktorientierter RE-Prozess lässt sich nicht gut mit einem linearen und präskriptiven Prozess kombinieren. Foundation Level | Handbuch | © IREB 135 | 174 5.2.5 Weitere Erwägungen Der Grad, in dem ein RE-Prozess etabliert und befolgt werden muss, sowie der Umfang der in diesem Prozess zu erstellenden Arbeitsprodukte hängt vom Grad des gemeinsamen Verständnisses und auch von der Kritikalität des Systems ab. Je besser das gemeinsame Verständnis und je geringer die Kritikalität ist, desto einfacher und leichtgewichtiger kann der RE-Prozess sein. Wenn wenig Zeit und Budget für RE zur Verfügung stehen, so müssen die verfügbaren Ressourcen sorgfältig eingesetzt werden. Die Wahl eines iterativen und explorativen Prozesses ist hilfreich. Darüber hinaus sollte sich der Prozess auf die Identifizierung und den Umgang mit den Anforderungen konzentrieren, die für den Erfolg des Systems entscheidend sind. Schließlich sollte der RE-Prozess der Erfahrung der Requirements Engineers entsprechen. Je geringer ihre Fähigkeiten und Erfahrungen sind, desto einfacher sollte der RE-Prozess gestaltet werden. Es ist unsinnig, einen ausgeklügelten Prozess zu definieren, wenn die beteiligten Personen diesen Prozess nicht richtig umsetzen können. 5.3 Konfigurieren eines Requirements Engineering Prozesses In einem konkreten Systementwicklungskontext müssen die Requirements Engineers oder die für das RE verantwortlichen Personen den anzuwendenden RE-Prozess auswählen. Wir empfehlen, zunächst die Einflussfaktoren zu analysieren (siehe Kapitel 5.1) und dann eine geeignete Kombination der in Kapitel 5.2 beschriebenen Prozessfacetten auszuwählen. 5.3.1 Typische Kombinationen von Facetten Drei Kombinationen von Facetten (oder Varianten davon) kommen in der Praxis häufig vor [Glin2019]. Im Folgenden beschreiben wir sie kurz und charakterisieren sie im Hinblick auf ihren Hauptanwendungsfall, typische Arbeitsprodukte und den typischen Informationsfluss. Darüber hinaus geben wir ein Beispiel. Abbildung 5.2 zeigt die drei typische Prozesskonfigurationen im Kontext der drei Facetten. Foundation Level | Handbuch | © IREB 136 | 174 Partizipativer RE-Prozess: iterativ & explorativ & kundenspezifisch Ein partizipativer RE-Prozess wird typischerweise in agilen Umgebungen gewählt, wenn es einen Kunden gibt, der ein System bestellt, und ein Entwicklungsteam, das es entwirft und implementiert. Der Schwerpunkt liegt auf der Ermittlung der Anforderungen in einer Reihe von Iterationen in enger Zusammenarbeit zwischen den Stakeholdern auf Kundenseite, den Requirements Engineers und dem Entwicklungsteam. 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, Visionen, Prototypen Typischer Informationsfluss: Kontinuierliche Interaktion zwischen Stakeholdern, Product Ownern, Requirements Engineers und Entwicklern Abbildung 5.2 Drei typische RE-Prozesskonfigurationen und ihre Bezug zu den drei Facetten Foundation Level | Handbuch | © IREB 137 | 174 Beispiel: In einem Versicherungsunternehmen hat der Fachbereich, der Firmenversicherungen an kleine und mittlere Unternehmen verkauft, eine Idee für ein neues Produkt zur Versicherung von Kunden gegen den Schaden, der durch einen Hackerangriff entsteht. Er beauftragt die ITAbteilung des Unternehmens ein Entwicklungsteam zu bilden, das die Aufgabe hat, eine neue Anwendung zu entwerfen und zu entwickeln, die das neue Versicherungsprodukt innerhalb des bestehenden Systems zur Unterstützung des Versicherungsvertriebs handhaben kann. Auch das bestehende Verwaltungssystem für Versicherungsverträge muss entsprechend angepasst werden. Abgesehen von einigen anfänglichen Anforderungen hat der beauftragende Fachbereich keine klare Vorstellung davon, wie das neue Produkt aussehen soll und wie es von den IT-Systemen des Unternehmens unterstützt werden soll. Die Unternehmens-IT hat vor einigen Jahren die agile Entwicklung für alle ihre Projekte eingeführt. In dieser Situation ist ein partizipativer RE-Prozess angebracht. Er passt zu dem agilen Gesamtprozess, den die Unternehmens-IT zur Entwicklung des neuen Systems und zur Anpassung der bestehenden Systeme einsetzen wird. Stakeholder aus dem Fachbereich und Requirements Engineers aus der Unternehmens-IT können gemeinsam die Anforderungen an das neue Versicherungsprodukt ermitteln. Da es sich um einen iterativen Prozess handelt, kann das Entwicklungsteam ein prototypisches Minimum Marketable Product (MMP) entwickeln, das dem Management des Fachbereichs bei der Entscheidung hilft, ob das geplante Produkt in ihr Portfolio aufgenommen, oder die Idee verworfen werden soll. Es besteht eine klare Kunden-Lieferanten-Beziehung zwischen dem Fachbereich und der Unternehmens-IT, sodass ein kundenorientierter RE-Prozess geeignet ist. Vertraglicher RE-Prozess: linear & präskriptiv & kundenspezifisch Ein vertraglicher RE-Prozess wird in der Regel gewählt, wenn die Entwicklung eines Systems ausgeschrieben und an einen Anbieter mit einem Vertrag auf der Grundlage einer umfassenden Anforderungsspezifikation ausgelagert wird. Er ist auch ein geeigneter REProzess in großen Systementwicklungsprojekten, die einen Entwicklungsprozess nach dem Wasserfallprinzip anwenden. 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 textuellen Anforderungen und Modellen Typischer Informationsfluss: Hauptsächlich von den Stakeholdern zu den Requirements Engineers Foundation Level | Handbuch | © IREB 138 | 174 Beispiel: Ein Automobilhersteller entwickelt eine neue KFZ-Plattform, aus der eine Familie von KFZ-Modellen abgeleitet werden soll. Eine wichtige Design-Entscheidung für die neue Plattform besteht darin, die Dutzenden von elektronischen Steuerungsgeräten (ECUs), die derzeit in den Fahrzeugen verwendet werden, abzuschaffen und durch eine einzige Steuerungseinheit zu ersetzen, die eine Reihe von Anwendungen zur Fahrsteuerung und Fahrassistenz ausführt. Ziel ist es, Hardware-Kosten einzusparen, unerwünschte Wechselwirkungen zwischen den Steuerungsgeräten zu beseitigen und sowohl Zeit als auch Aufwand für die Durchführung von Software-Updates zu reduzieren. Ingenieure, die für die elektronischen Systeme der neuen Plattform verantwortlich sind, haben ein Lastenheft für Kundenanforderungen verfasst. Das Unternehmen hat einen großen Hersteller von Kfz-Steuerungssystemen beauftragt, eine System-Anforderungsspezifikation für das neue zentralisierte Kfz-Steuerungssystem zu erstellen. Später wird der Automobilhersteller die Konzeption und die Implementierung des Systems auf der Grundlage dieser Spezifikation ausschreiben. Der Hersteller wird verlangen, dass die Implementierung in mehreren Iterationen durchgeführt wird, um das Testen und die Integration des Systems mit der neuen Fahrzeugplattform zu erleichtern. In dieser Situation ist ein vertraglicher RE-Prozess angebracht. Der Gesamtprozess ist linear: Das System wird erst nach Abschluss der Anforderungsspezifikation entworfen und implementiert. Die Tatsache, dass die Umsetzung iterativ erfolgen wird, hat keinen Einfluss auf den RE-Prozess. Abhängig von der Qualität des vorliegenden Lastenheftes und der Verfügbarkeit der Stakeholder beim Automobilhersteller sollte ein linearer oder ein iterativer RE-Prozess gewählt werden. Es liegt auf der Hand, dass ein kundenorientierter RE-Prozess erforderlich ist. Das Vorhandensein eines Lastenheftes und die Tatsache, dass die SystemAnforderungsspezifikation für die Ausschreibung der Konzeption und der Implementierung des Systems verwendet wird, erfordern einen präskriptiven RE-Prozess. Produktorientierter RE-Prozess: Iterativ & explorativ & marktorientiert Ein produktorientierter RE-Prozess wird typischerweise dann gewählt, wenn eine Organisation ein System als Produkt oder Dienstleistung für den Markt entwickelt. In den meisten Fällen geht ein produktorientierter RE-Prozess mit einem agilen Produktentwicklungsprozess einher. Der Product Owner und die Digital Designer spielen in diesem Prozess eine wichtige Rolle: Sie beeinflussen und gestalten das Produkt stark. Hauptanwendungsfall: Eine Organisation spezifiziert und entwickelt Software, um sie als Produkt oder Service zu verkaufen oder zu vertreiben Typische Arbeitsprodukte: Produkt-Backlog mit User Storys und/oder Aufgabenbeschreibungen, Visionen, Benutzer-Feedback Typischer Informationsfluss: Interaktion zwischen Product Ownern, Marketing, Requirements Engineers, Digital Designern, Entwicklern und schnellem Feedback von Kunden/Benutzern Foundation Level | Handbuch | © IREB 139 | 174 Beispiel: Ein Medienunternehmen beauftragt seine interne IT mit einer Neuentwicklung der mobilen Nachrichten-App, die das Unternehmen an Abonnenten verkauft (wobei einige Inhalte frei zugänglich sind). Anhand des Benutzer-Feedbacks besitzt das Unternehmen eine lange Liste mit Kundenkritik und Verbesserungsvorschlägen. Insbesondere kritisieren viele Benutzer, dass die vorhandene App nicht schnell genug reagiert, dass die Unterstützung für das Melden von Problemen und Vorschlägen schlecht ist und, dass sie das Zwei-Finger-Zoomen von Text oder Bildern nicht unterstützt. Auch die Marketingabteilung des Unternehmens empfindet das Layout der App als veraltet. Sie sagt voraus, dass mit einem neuen Layout mehr Abonnenten gewonnen werden könnten. Der CEO des Unternehmens hat beschlossen, dass die IT-Abteilung für das visuelle Erscheinungsbild der App mit einer externen Design-Agentur zusammenarbeiten soll. Die Geschäftsführung des Medienunternehmens möchte eine minimale Produktversion als Proof-of-Concept und dann alle drei Wochen neue Zwischenversionen, die von der Marketingabteilung und dem Vorstand des Unternehmens begutachtet werden können. In dieser Situation ist ein produktorientierter RE-Prozess am besten geeignet. Obwohl es eine Kunden-Lieferanten-Beziehung zwischen der Unternehmensleitung und der internen ITAbteilung gibt, liegt der Schwerpunkt eindeutig auf der Neuentwicklung eines Produkts im Segment der mobilen Nachrichtenanwendungen. Der RE-Prozess muss explorativ sein, da die Anforderungen, die über die Informationen in der vorhandenen Liste des BenutzerFeedbacks hinausgehen, nicht klar sind. Der gesamte Entwicklungsprozess muss entsprechend der Entscheidung der Unternehmensleitung iterativ sein. Da die Anforderungen ermittelt werden müssen, ist ein iterativer RE-Prozess hier am besten geeignet. 5.3.2 Andere RE-Prozesse Die drei oben beschriebenen Kombinationen decken viele der in der Praxis vorkommenden Situationen ab. Es kann jedoch Situationen geben, bei denen keine der oben genannten Prozess-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. In einem solchen Fall muss der RE-Prozess von Prozessexperten von Grund auf neu erstellt werden oder eine der oben genannten Konfigurationen muss so zugeschnitten werden, dass sie an die gegebene Situation angepasst ist. 5.3.3 Wie man RE-Prozesse konfiguriert Wir empfehlen ein fünfstufiges Vorgehen zur Konfiguration eines RE-Prozesses. 1. Analysieren der Einflussfaktoren. Analysieren Sie Ihre Situation im Hinblick auf die Liste der Einflussfaktoren aus Kapitel 5.1. 2. Beurteilen der Facettenkriterien. Gehen Sie auf der Grundlage der Analyse aus Schritt 1 die Liste der Auswahlkriterien für Facetten durch, die in Kapitel 5.2 aufgeführt ist. Sie Foundation Level | Handbuch | © IREB 140 | 174 können jedem Kriterium einen Wert auf einer fünfstufigen Skala (--, -, 0, +, ++) zuweisen. 3. Konfigurieren. Wenn die Analyse der Kriterien in Bezug auf die drei oben genannten typischen Konfigurationen ein eindeutiges Ergebnis liefert, wählen Sie diese Konfiguration. Andernfalls wählen Sie einen abweichend angepassten Prozess, der sich an dem allgemeinen Ziel orientiert, das Risiko der Entwicklung eines falschen Systems zu mindern. Stellen Sie sich zum Beispiel eine Situation vor, in der der Kunde verlangt, dass im Vorfeld eine System-Anforderungsspezifikation erstellt wird, was einen linearen, präskriptiven RE-Prozess erfordert. Bei Ihren ersten Treffen mit dem Kunden haben Sie jedoch festgestellt, dass der Kunde bei einem wichtigen Subsystem keine klare Vorstellung davon hat, was er bauen soll, was wiederum einen explorativen RE-Prozess erfordert. Eine mögliche Lösung könnte darin bestehen, einen vertraglichen RE-Prozess als allgemeinen Rahmen für den RE-Prozess zu wählen, aber ein Teilprojekt zu erstellen, das die Anforderungen für dieses wichtige Teilsystem schrittweise ermittelt und in zwei oder drei Iterationen (geleitet von einem partizipativen RE-Teilprozess) Prototypen erstellt, und die Ergebnisse dann in die System-Anforderungsspezifikation einfließen zu lassen. 4. Arbeitsprodukte bestimmen. Definieren Sie auf der Grundlage Ihrer Analyse und Prozesskonfiguration die wichtigsten RE-Arbeitsprodukte, die erstellt werden sollen. Stellen Sie sicher, dass die RE-Arbeitsprodukte mit den Arbeitsprodukten des gesamten Entwicklungsprozesses abgestimmt sind. 5. Geeignete Praktiken auswählen. Für die zu erfüllenden Aufgaben - z.B. die Ermittlung von Anforderungen - wählen Sie die Praktiken aus, die in der gegebenen Situation am besten geeignet sind. Viele dieser Praktiken, einschließlich der Hinweise, wo und wann sie anzuwenden sind, werden in den Kapiteln 2, 4, und 6 dieses Handbuchs vorgestellt. Es gibt keinen erprobten, universellen (one-size-fits-all) RE-Prozess. Ausgehend von einer Analyse der Einflussfaktoren muss für jedes RE-Vorhaben ein spezifischer RE-Prozess maßgeschneidert werden. Eine einfache Art des Zuschnitts ist die Konfiguration eines REProzesses aus einer Reihe von Prozessfacetten. 5.4 Weiterführende Literatur Armour [Armo2004] und Reinertsen [Rein1997], [Rein2009] teilen in ihren Veröffentlichungen ihre allgemeinen Gedanken über Prozesse und Informationsflüsse in Prozessen. Das Lehrbuch von Robertson und Robertson [RoRo2012] trägt zwar den Titel „Mastering the Requirements Process“, ist dennoch ein allgemeines Lehrbuch über alle Aspekte des RE. Wiegers und Beatty [WiBe2013] widmen ein Kapitel der Verbesserung von RE-Prozessen. Das Buch von Sommerville und Sawyer [SoSa1998] enthält eine Sammlung von guten Praktiken, die im Rahmen von RE-Prozessen verwendet werden können. Foundation Level | Handbuch | © IREB 141 | 174