Requirements Engineering: Foundation Level Handbook (PDF)

4 Praktiken für die Erarbeitung von Anforderungen In den vorangegangenen Kapiteln lernten wir etwas über die Natur von Anforderungen als Darstellung der Wünsche und Bedürfnisse von Menschen und Organisationen nach etwas Neuem (z.B. einem zu entwickelnden oder anzupassenden System), über die Prinzipi...

4 Praktiken für die Erarbeitung von Anforderungen In den vorangegangenen Kapiteln lernten wir etwas über die Natur von Anforderungen als Darstellung der Wünsche und Bedürfnisse von Menschen und Organisationen nach etwas Neuem (z.B. einem zu entwickelnden oder anzupassenden System), über die Prinzipien, die der Erstellung der Anforderungen zugrunde liegen, und über Möglichkeiten, die Anforderungen zu dokumentieren. Wir ermitteln Anforderungen, bevor wir ein System (oder einen Teil eines Systems) erstellen oder modifizieren, um zu gewährleisten, dass das System für die Personen oder die Organisation, die es angefordert haben, nützlich ist und von ihnen akzeptiert wird. Diese Anforderungen dienen als Input für ein Entwicklungsteam, das das System erstellen und implementieren wird. Kurz gesagt erfolgt Requirements Engineering explizit oder oft auch implizit wann und wo immer Menschen versuchen, etwas zu entwickeln. Im Prinzip bestimmt die Qualität der Anforderungen die Qualität des Outputs der späteren Entwicklung. Ohne entsprechende Anforderungen ist es unwahrscheinlich, dass das resultierende System nützlich sein wird. Deshalb ist es wichtig, die Anforderungen professionell auszuarbeiten. Dies erfordert eine explizite Definition des „wie”, der Praktiken, die für eine qualitativ hochwertige Ausarbeitung zu verwenden sind. Dieses Kapitel gibt einen Überblick über die Aufgaben, Aktivitäten und Praktiken, die für alle am Requirements Engineering Beteiligten relevant sind. Es beginnt mit der Suche nach potenziellen Anforderungsquellen und endet mit der Bereitstellung einer konsistenten, verständlichen und abgestimmten Reihe von Anforderungen, die als Input für die effiziente Entwicklung, Wartung und den Betrieb eines effektiven Systems genutzt werden können. Die erste Aufgabe jeder Requirements Engineering-Tätigkeit ist die Identifizierung und Analyse potenzieller Quellen für Anforderungen. Dies mag wie eine einfache und offensichtliche Aufgabe erscheinen, aber wie wir in Kapitel 4.1 sehen werden, gibt es eine ganze Reihe von Aspekten, die berücksichtigt und analysiert werden müssen. Das Übersehen einer Quelle führt unweigerlich zu schlechten oder sogar fehlenden Anforderungen und damit zu einer Qualitätsminderung des resultierenden Systems. Der nächste Schritt ist das Ermitteln der Anforderungen aus diesen Quellen. Es ist wie das Schöpfen von Wasser aus einem Brunnen: Man weiß nie, was im Eimer ist, bis man es an die Oberfläche gebracht hat. Im Requirements Engineering wird diese Aufgabe Ermittlung genannt; sie wird in Kapitel 0 erläutert. Bei der Ermittlung wandeln wir implizite Bedürfnisse, Wünsche, Erfordernisse, Forderungen, Erwartungen und dergleichen in explizite Anforderungen, die von allen beteiligten Parteien anerkannt und verstanden werden können. Wenn Sie jedoch zwei Personen nach ihren Anforderungen an ein bestimmtes System fragen, werden Sie selten genau die gleichen Antworten erhalten. Bei einer ganzen Reihe von Anforderungen, die aus verschiedenen Quellen ermittelt wurden, ist es fast sicher, dass einige von ihnen widersprüchlich sein werden. Da es unmöglich ist, widersprüchliche Foundation Level | Handbuch | © IREB 85 | 174 Anforderungen in ein und demselben System zu implementieren, wird die Konfliktlösung immer eine wichtige Aufgabe im Requirements Engineering sein, wie in Kapitel 4.3 beschrieben. Kapitel 4.4 ist der abschließenden Aufgabe im Requirements Engineering gewidmet, der Validierung von Anforderungen. Mit diesem Schritt soll sichergestellt werden, dass die Qualität des ermittelten Anforderungssatzes und der einzelnen Anforderungen innerhalb dieses Satzes gut genug ist, um eine spätere Systementwicklung zu ermöglichen. Aus der obigen Beschreibung der Aufgaben des Requirements Engineering könnte man den Eindruck gewinnen, dass sie als ein linearer Prozess mit einer strengen Abfolge von Schritten durchgeführt werden. Dies ist jedoch keineswegs die Absicht dieser Beschreibung und in der Praxis selten der Fall. Abbildung 4.1 zeigt einige Prozessschritte, die im Requirements Engineering üblich sind. Sie können parallel, in Schleifen oder sequenziell durchgeführt werden - je nachdem, was in der gegebenen Situation angemessen ist. Der Ausgangspunkt ist oft eine begrenzte Anzahl offensichtlicher Quellen. Während der Ermittlung aus diesen Quellen werden neue Quellen identifiziert, was zusätzliche Aufgaben für die Ermittlung auslöst. Wenn Konflikte auftreten, kann eine gründlichere Ermittlung erforderlich sein, um einen Weg aus dem Konflikt zu finden. Bei der Validierung kann es sich herausstellen, dass eine Quelle übersehen wurde, eine Anforderung fehlerhaft ist oder ein Konflikt unentdeckt geblieben ist, was zu einer neuen Runde von Aktivitäten zur Quellenanalyse, Ermittlung und/oder Konfliktlösung und Validierung führt. Auch während der anschließenden Systementwicklung können bestimmte Umstände zusätzliche Requirements Engineering Aufgaben erforderlich machen. Abbildung 4.1 Requirements Engineering ist kein linearer Prozess Foundation Level | Handbuch | © IREB 86 | 174 In agilen Projekten gehen iteratives und inkrementelles Requirements Engineering und Systementwicklung Hand in Hand, wobei die Anforderungen kurz vor der Entwicklung eines neuen Systems Inkrements ausgearbeitet werden. Bei solchen Projekten werden Sie oft sehen, dass ein Projekt mit einem begrenzten Produkt-Backlog von Anforderungen auf hoher Abstraktionsebene beginnt, die erst dann verfeinert und detailliert werden, sobald sie Kandidaten für die nächste Iteration sind. 4.1 Quellen für Anforderungen Anforderungen sind nicht wie Schokoriegel, die im Regal liegen, damit jeder sie nach Belieben auswählen kann. In der Einleitung zu diesem Kapitel haben wir Anforderungen mit dem Wasser verglichen, das aus einem Brunnen entnommen werden muss. Es ist ein ziemlicher Aufwand, sie an die Oberfläche zu bringen. Das erste Problem, mit dem ein Requirements Engineer konfrontiert wird ist daher: „Wo sind die Brunnen?” Da es keine Anforderung ohne Quelle gibt, ist eine der ersten Aktivitäten bei der Anforderungsermittlung das Identifizieren potenzieller Anforderungsquellen. Es reicht nicht aus, diese Quellen nur zu Beginn eines Projekts oder einer Produktentwicklung zu identifizieren, dies ist ein Prozess, der sich immer und immer wieder wiederholen wird. Bereits zu Beginn der Anforderungsausarbeitung sollte der Requirements Engineer damit befasst sein, alle relevanten Anforderungsquellen zu identifizieren, zu analysieren und einzubeziehen, da das Fehlen einer relevanten Quelle unweigerlich zu einem unvollständigen Verständnis der relevanten Anforderungen führt. Und bis zum Ende wird die Identifikation von Anforderungsquellen ein Prozess sein, der immer wieder neu überdacht werden muss. Kapitel 2, Prinzip 3 betont die Notwendigkeit eines (expliziten und impliziten) gemeinsamen Verständnisses zwischen und bei allen beteiligten Parteien den Stakeholdern, Requirements Engineers, Entwicklern. Das Verständnis über den Kontext des zu entwickelnden Systems in einem bestimmten Anwendungsgebiet ist eine Voraussetzung, um die relevanten Anforderungsquellen identifizieren zu können. Domänenwissen, frühere erfolgreiche Zusammenarbeit, gemeinsame Kultur und Werte sowie gegenseitiges Vertrauen, sind die Voraussetzungen für ein gemeinsames Verständnis, während geografische Distanz, Outsourcing, oder große Teams mit hoher Fluktuation, Hindernisse darstellen. In Kapitel 2, Prinzip 4, stellten wir den Kontext als ein Konzept vor, das für das Verständnis und die Spezifikation eines Systems und seiner Anforderungen grundlegend ist. Der Kontext wurde als jener Teil der Realität definiert, der zwischen der Systemgrenze und der Kontextgrenze liegt. Entitäten (Elemente, Gegenstände) aus diesem Kontext werden das System in irgendeiner Weise beeinflussen oder sogar mit ihm interagieren, aber sie werden nicht im System selbst enthalten sein. Die Suche nach Bedarfsquellen würde ganz simpel, indem Sie sich einfach im Kontext umschauen! Aber so einfach ist es nicht. Zu Beginn eines Entwicklungsprozesses ist der Kontext noch nicht definiert, die Systemgrenze und die Kontextgrenze müssen noch festgelegt werden. Daher ist die Suche nach Anforderungsquellen ein iterativer, rekursiver Prozess. Foundation Level | Handbuch | © IREB 87 | 174 Potenzielle Quellen werden auf ihre Beziehung zum zukünftigen System analysiert. Wenn Sie bei der Analyse einer potenziellen Quelle keinen Zusammenhang finden, bedeutet dies, dass sie Teil der irrelevanten Umgebung ist und nicht auf Anforderungen hin analysiert wird. Potenzielle Quellen, die Teil des zukünftigen Systems zu sein scheinen, sind für den Requirements Engineer ebenfalls nicht von Interesse; sie gehören den Entwicklern. Nur solche Entitäten, bei denen die Analyse eine Interaktion mit, eine Schnittstelle zu, oder einen Einfluss auf das zukünftige System erkennen lässt, die aber bei der nächsten Entwicklung (relativ) unverändert bleiben, verdienen Aufmerksamkeit als Quellen für Anforderungen. In dieser Analyse werden die Systemgrenze und die Kontextgrenze abgegrenzt, die zunächst vage sind und mit der Identifizierung von immer mehr Quellen immer schärfer werden. Je klarer der Kontext wird, desto einfacher wird es, neue Quellen zu identifizieren, die wiederum die Grenzen weiter schärfen. Die Suche nach Anforderungsquellen beginnt in der Regel mit einigen wenigen offensichtlichen Quellen, die oft vom Auftraggeber zu Beginn einer Entwicklung identifiziert werden. Eine erste Ermittlung aus diesen Quellen wird weitere potenzielle Quellen aufdecken, die dann analysiert werden, um zu entscheiden, ob sie für das System relevant sind oder nicht. Während dieser Analyse können wieder neue potenzielle Quellen auftauchen. Tatsächlich wird der Requirements Engineer bei jedem Ermittlungsvorgang weiterhin darauf bedacht sein, neue Quellen aufzuspüren. Dies kann bis zum Ende der Entwicklungsbemühungen fortgesetzt werden. Wir versuchen jedoch, die wichtigsten, relevantesten Quellen frühzeitig zu identifizieren, da alle anderen Aktivitäten des Requirements Engineering von dieser frühen Erkennung abhängen. Im Requirements Engineering unterscheiden wir drei Hauptkategorien von Quellen: ▪ Stakeholder ▪ Dokumente ▪ (Andere) Systeme Diese Kategorien werden in den folgenden Abschnitten ausführlicher behandelt. 4.1.1 Stakeholder In Kapitel 2, Prinzip 2, haben Sie etwas über den Stakeholder als Person oder Organisation erfahren, die die Anforderungen eines Systems beeinflusst oder von diesem System beeinflusst wird. Die Stakeholder eines Systems sind die Hauptquellen für Anforderungen. Noch mehr als bei anderen Quellen hat die Nichteinbeziehung eines relevanten Stakeholders erhebliche negative Auswirkungen auf die Qualität der endgültigen Anforderungen. Wenn solche Stakeholder zu spät entdeckt werden (oder ganz fehlen), kann dies zu teuren Änderungen oder am Ende zu einem nutzlosen System führen. Um ein System zu schaffen, das den Bedürfnissen aller Stakeholder gerecht wird, sollte die systematische Identifizierung der Stakeholder zu Beginn jeder Entwicklungsarbeit beginnen und die Ergebnisse sollten während der gesamten Entwicklung verwaltet werden. Stakeholder sind in einem weiten Bereich rund um das System zu finden, von direkten und indirekten Nutzern des Systems, Foundation Level | Handbuch | © IREB 88 | 174 (Geschäfts-)Managern, IT-Mitarbeitern wie etwa Entwicklern und Betreibern bis hin zu Gegnern und Konkurrenten, Regierungs- und Regulierungsinstitutionen und vielen anderen. Die Hauptfrage, um eine Person oder eine Organisation als Stakeholder zu identifizieren, lautet: „Besteht eine relevante Beziehung zwischen der Person/Organisation und dem System?” Es hilft, die Stakeholder als Menschen aus Fleisch und Blut zu sehen. Wenn Sie eine Organisation als Stakeholder identifizieren, stellen Sie sich Fragen wie die folgenden: „Kann ich eine Person identifizieren, die für diese Organisation verantwortlich ist? Wer kann als Hauptansprechpartner dieser Organisation angesehen werden? Wer vertritt diese Organisation innerhalb unseres Unternehmens?" Wenn z.B. die Regierung der Stakeholder ist, weil es um ein bestimmtes Gesetz geht, suchen Sie nach jemandem, der die Regierung als die Quelle vertritt, an die man sich bei Anforderungen wenden kann. In diesem Fall ist es nicht sehr nützlich, den Premierminister als diese Person zu identifizieren, der Leiter der internen Rechtsabteilung wäre die bessere Wahl. Abbildung 4.2 Alexanders Zwiebel-Modell Es gibt keine Standardtechnik zur Identifizierung von Stakeholdern, aber Ian Alexanders Zwiebelmodell [Alex2005] kann ein guter Anfang sein, siehe Abbildung 4.2. Dieses Modell zeigt, wie ein (Software-)System von mehreren Schichten übergeordneter soziotechnischer1 und sozialer Systeme umgeben ist, von denen jedes seine eigenen Stakeholder hat. Zu Beginn einer Anforderungsentwicklung sind einige dieser Stakeholder offensichtlich, z.B. Endbenutzer oder Kunden. Sie können als Ausgangspunkt bei der Suche nach anderen Stakeholdern dienen. Nachdem er sie als relevante Quellen identifiziert hat, wird der 1 Ein sozio-technisches System ist ein System, das Anforderungen berücksichtigt, die Hardware, Software, persönliche und gemeinschaftliche Aspekte umfassen und gleichzeitig die Interaktion zwischen den komplexen Infrastrukturen der Gesellschaft und dem menschlichen Verhalten anerkennt. Foundation Level | Handbuch | © IREB 89 | 174 Requirements Engineer ihre Beziehungen analysieren, sowohl in inneren als auch in äußeren umgebenden Systemen. Bei dieser Analyse werden neue Stakeholder gefunden, die wiederum andere (und mehr) Beziehungen haben können, die analysiert werden müssen. Man könnte dies das Schneeballprinzip nennen. Je mehr Stakeholder Sie gefunden haben, desto leichter wird es, neue zu finden. Wenn man jedoch zu Stakeholdern in Alexanders weiterem Umfeld gelangt, enden alle äußeren Beziehungen in der irrelevanten Umgebung, was bedeutet, dass sie keine neuen Quellen mehr offenbaren. Abgesehen von Stakeholdern, die sich auf andere Stakeholder beziehen, können Dokumente oft neue Stakeholder offenbaren. Gute Beispiele sind Organigramme, Prozessbeschreibungen, Marketingberichte und regulatorische Dokumente. Weitere Informationen über Dokumentation als Quelle für Anforderungen finden Sie im Kapitel 4.1.2. Checklisten mit typischen Stakeholdern und Rollen können ein nützliches Instrument sein, um zu vermeiden, dass bestimmte unauffällige potenzielle Stakeholder übersehen werden. Auch die Analyse von Stakeholdern von Altsystemen oder ähnlichen Systemen kann helfen. Als Requirements Engineer sammeln Sie eine Menge Daten über Ihre Stakeholder und pflegen diese Daten, bis Ihre Arbeit beendet ist. Sie müssen wissen, wer die Stakeholder sind, wie Sie sie erreichen können, wann und wo sie verfügbar sind, welche Fachkenntnisse sie haben und welche Bedeutung sie als Quelle haben, welche Einstellung sie zum Projekt haben und welchen Einfluss sie darauf haben, welche Rolle sie im Unternehmen, im Projekt und in ihrer Beziehung zum System spielen usw. In der Regel werden diese Informationen in einer Stakeholderliste geführt, die auf dem neuesten Stand gehalten werden muss, da Sie während aller Schritte mit allen Stakeholdern in Kontakt bleiben werden - mit einigen intensiv und sehr eng, mit anderen selten und oberflächlich. Siehe Tabelle 4.1 unterhalb für ein vereinfachtes Beispiel. Tabelle 4.1 Beispiel einer Stakeholder-Liste Name Abteilung Telefon Erreichbarkeit Rolle Einfluss Interesse Marlene Eigentümerin 482263 Nur montags Sponsor ++ o Peter Verkauf 481225 Ständig Product Owner ++ + Eva Rechtsabteilung 481237 Nicht im Juni Berater + - Hassan Logistik 242651 Ständig Benutzer o ++ Mira Service-Desk 242424 Nach 16:00 Uhr Benutzer - + 481226 Ständig Kunde ++ ++ Natalia *) * Persona, erstellt, gepflegt und vertreten durch das Kundenpanel-Team Foundation Level | Handbuch | © IREB 90 | 174 Das Pflegen einer guten, offenen Beziehung zu den Stakeholdern ist der Schlüssel, um relevante Informationen von ihnen zu bekommen. Dies stützt sich in erster Linie auf Verhaltensmerkmale wie Integrität, Ehrlichkeit und Respekt. Eine offene und häufige Kommunikation über Ihre Pläne, Ihre Aktivitäten und Ihre Ergebnisse ist unerlässlich. Möglicherweise müssen Sie Stakeholder von anfänglichen Gegnern zu Mitstreitern machen. Als Requirements Engineer müssen Sie verstehen, was die Stakeholder von Ihnen erwarten. Sie müssen Ihre Arbeit auch verkaufen, indem Sie ihnen die Vorteile Ihrer Lösung aufzeigen und die Hindernisse beseitigen, die die Stakeholder auf dem Weg zu dieser Lösung erleben oder erwarten. Leider ist es nicht ungewöhnlich, dass bestimmte (meist interne) Stakeholder negative Folgen der Veränderungen, die sich aus Ihrem Projekt ergeben, voraussehen oder tatsächlich erleben. In solchen Fällen wird es schwierig sein, ihre Mitarbeit zu erhalten, auch wenn Sie sie sicherlich brauchen werden. Eine Eskalation auf höhere Ebenen in der Organisation kann dann der einzige Weg sein, auch wenn die daraus resultierende Beziehung bei weitem nicht optimal sein wird. Stakeholder-RelationshipManagement [Bour2009] ist ein effektiver Weg, um Schwierigkeiten mit Stakeholdern entgegen zu wirken. Dies impliziert einen kontinuierlichen Prozess, um die Unterstützung und das Engagement von Stakeholdern zu gewinnen und aufrechtzuerhalten, indem die richtigen Stakeholder zum richtigen Zeitpunkt eingebunden werden und ihre Erwartungen verstanden und gehandhabt werden. Um Stakeholder in den Ermittlungsprozess einzubinden, müssen Sie sicherstellen, dass sie wissen, worum es bei dem Projekt geht und welche Rolle sie in dem Projekt einnehmen. Sie müssen ihre Bedürfnisse verstehen und versuchen, diese Bedürfnisse so weit wie möglich im Rahmen Ihrer Kompetenzen im Projekt zu berücksichtigen. Auch wenn die Stakeholder mit Respekt behandelt werden sollten, können Sie das Gleiche von den Stakeholdern verlangen, zumindest von denen, die sich aktiv am Projekt beteiligen. Das bedeutet, dass sie Zeit für Sie haben sollten, wenn Sie sie brauchen. Sie sollten die von Ihnen erbetenen Informationen sowie andere Informationen geben, von denen sie wissen, dass sie relevant sind. Ihr Feedback zu Ihren Arbeitsprodukten sollte rechtzeitig erfolgen, und sie sollten von Klatsch und Tratsch über das Projekt usw. Abstand nehmen. Probleme mit Stakeholdern entstehen typischerweise, wenn die Rechte und Pflichten des Requirements Engineers und der Stakeholder in Bezug auf das vorgeschlagene System oder das aktuelle Projekt nicht klar sind, oder wenn die jeweiligen Bedürfnisse nicht ausreichend berücksichtigt werden. Wenn Probleme auftreten, kann eine Art Stakeholder-Vereinbarung oder Stakeholder-Vertrag dazu beitragen, allen Parteien die gewünschte Klarheit zu verschaffen. Wenn dies innerhalb einer Organisation geschieht, kann die Billigung durch das obere Management zum Erfolg eines solchen Ansatzes beitragen. Foundation Level | Handbuch | © IREB 91 | 174 4.1.1.1 Ein besonderer Stakeholder: Der Benutzer Jedes System, das wir entwickeln, wird eine gewisse Interaktion mit bestimmten Benutzern haben, warum würden Sie es sonst entwickeln? Wenn Sie an den Anforderungen an ein eingebettetes technisches Teilsystem arbeiten, das in einer komplizierten Maschinerie verborgen ist, werden die Benutzer natürlich nur indirekt, über mehrere Schichten umschließender Systeme, damit interagieren. In solchen Fällen werden diese Benutzer nicht Ihre wichtigste Anforderungsquelle sein. Bei vielen Systemen haben bestimmte Menschen allerdings eine direkte Schnittstelle mit dem System - die (End-) Benutzer. Ihre Akzeptanz für das System ist entscheidend für den Erfolg des Projekts, daher sind diese Stakeholder Ihr Hauptanliegen und werden während des gesamten Requirements Engineerings besondere Aufmerksamkeit erhalten. Es gibt zwei Hauptkategorien von Benutzern: ▪ ▪ Interne Benutzer stehen in direktem Zusammenhang mit der Organisation, für die das System entwickelt wird, wie z.B. Mitarbeiter, Management, Subunternehmer. Sie sind meist zahlenmäßig begrenzt, einzeln mehr oder weniger bekannt und irgendwie in das Projekt eingebunden. Es ist relativ einfach, mit ihnen Kontakt aufzunehmen, und sie können über formelle, bestehende Kanäle erreicht, beeinflusst und motiviert werden. Externe Benutzer befinden sich außerhalb des Unternehmens, wie z.B. Kunden, Geschäftspartner, Bürgerinnen und Bürger. Ihre Zahl kann (sehr) groß sein, in vielen Fällen sind sie einzeln nicht bekannt, und sie könnten dem Projekt völlig unbewusst oder gleichgültig gegenüberstehen. Sie können sie nicht über formelle Kanäle beeinflussen. Um mit ihnen in Kontakt zu treten, müssen Sie möglicherweise besondere Dinge tun, um sie zur Teilnahme zu motivieren, z.B. Werbung machen, eine Belohnung versprechen, oder ihnen freien Zugang zu einer Beta-Version gewähren. Ein Benutzerpanel zu bilden, oder die Ansprache der Menge (manchmal gegen Bezahlung) kann ein sinnvoller Weg sein, diese Benutzer einzubeziehen. Seien Sie sich bewusst, dass es neben diesen regulären Kategorien auch relevant sein kann, auf Missetäter (Misuser) zu achten: Personen, die absichtlich versuchen auf schädliche Weise mit dem System zu interagieren, wie Hacker oder Konkurrenten. Es ist kaum möglich, mit ihnen in Kontakt zu treten oder sie zu beeinflussen, aber man kann versuchen, Maßnahmen zu entwickeln, um sie abzuschrecken, sie fernzuhalten oder vorhersehbare Missbrauchsversuche aufzudecken. Diese Kategorisierung sollte nicht allzu streng betrachtet werden. Wir können uns Projekte vorstellen, bei denen die Zahl der Benutzer außerhalb des Unternehmens gering und leicht erreichbar ist, sodass sie als intern angesehen werden können. Andererseits kann in großen Unternehmen die Entfernung zu den Benutzern so groß sein, dass sie mehr oder weniger wie Externe behandelt werden sollten. Wenn Sie einen guten Einblick in Ihren Benutzerkreis haben, sollten Sie zwischen Benutzerrollen unterscheiden. Getrennte Rollen haben in der Regel unterschiedliche Informationsbedürfnisse, nutzen das System auf ihre eigene Art und Weise und können unterschiedliche Zugriffsrechte auf Funktionen und Daten haben, wie z.B. Benutzer, die Foundation Level | Handbuch | © IREB 92 | 174 Daten eingeben, und Vorgesetzte, die diese Eingaben überprüfen. Stellen Sie in solchen Fällen sicher, dass Sie Vertreter aller relevanten Rollen in die Ermittlung einbeziehen. Häufig, insbesondere zu Beginn der Ermittlungstätigkeit, wird ein solcher Einblick fehlen. Dann ist es umso wichtiger zu erkennen, dass es so etwas wie den Benutzer nicht gibt. Der Benutzer ist keine amorphe Masse identischer Menschen, sondern vielmehr eine Ansammlung von Individuen, jedes von ihnen mit seinen eigenen Gewohnheiten, Wünschen und Bedürfnissen. Wenn ein System Tausende von Benutzern oder mehr hat, können Sie die Anforderungen natürlich nicht auf deren individuelle Bedürfnisse abstimmen. Auf der anderen Seite könnte ein Einheitsgrößen (one-size-fits-all) Ansatz, der auf den Durchschnitts-Benutzer abzielt, ebenfalls nicht funktionieren. In solchen Fällen hilft es, eine Reihe von Benutzertypen oder Benutzergruppen zu erkennen, die bestimmte, oft verhaltensbezogene Ähnlichkeiten innerhalb der Gruppe aufweisen, die sich von anderen Gruppen unterscheiden. In der Praxis funktioniert es oft am besten, drei bis sieben Gruppen zu haben. Dann werden Sie als Requirements Engineer jede Gruppe als eine unterschiedliche Quelle für Anforderungen behandeln. Eine gute Technik ist die Verwendung von Personas [Hump2017]. Personas sind fiktive Individuen, die typische Benutzergruppen eines Systems mit ähnlichen Bedürfnissen, Zielen, Verhaltensweisen oder Einstellungen beschreiben. 4.1.1.2 Personas Es gibt zwei Hauptansätze zur Schaffung von Personas: ▪ Datengesteuert Bei diesem Ansatz werden Personas mit Marketingtechniken wie Interviews, Fokusgruppen und anderen ethnografischen Datenerfassungstechniken entwickelt. Solche Personas werden qualitative Personas genannt. Wenn Personas durch eine statistische Analyse einer großen Stichprobe Ihrer Nutzerbasis entwickelt werden, werden sie als quantitative Personas bezeichnet. ▪ Phantasie Als günstigere und schnellere Alternative können Personas durch Phantasie entwickelt werden, zum Beispiel in einer Brainstorming-Sitzung mit dem Projektteam. Wir nennen sie Ad-hoc-Personas oder Proto-Personas. Als Requirements Engineer müssen Sie sich bewusst sein, dass Ad-hoc-Personas auf Phantasie und Annahmen beruhen. Diese Annahmen müssen während des gesamten Requirements Engineering-Prozesses überprüft und bestätigt werden. Foundation Level | Handbuch | © IREB 93 | 174 Abbildung 4.3 Persona-Beispiel Grundsätzlich enthalten Persona-Beschreibungen Informationen, die im Hinblick auf die Entwicklung des vorliegenden Systems relevant sind. In der Regel werden diese Informationen mit zusätzlichen Daten wie Name, Adresse, Hobbys und einer Zeichnung oder einem Porträtbild angereichert. Dies gibt dem abstrakten Begriff der Persona ein menschliches Gesicht. Es kann Ihnen helfen zu erkennen, dass sich Ihre Arbeit als Requirements Engineer nicht nur auf Fakten, sondern auch auf Emotionen bezieht. Abbildung 4.3 gibt ein Beispiel für eine PersonaBeschreibung. Wenn Sie in Ihrem Projekt Personas verwenden, kann es sinnvoll sein, einige wenige Personen zu suchen, die auf die Persona-Beschreibungen passen, und sie als Vertreter jeder Gruppe zu behandeln. In diesem Fall haben Sie echte Stakeholder, mit denen Sie kommunizieren können. Denken Sie jedoch immer daran, dass die Gruppe, die ein solcher Stakeholder vertritt, eine künstliche Gruppe ist, die es in der realen Welt nicht gibt, sondern nur im Kontext des Systems oder Projekts. 4.1.2 Dokumente Auch Dokumente können eine wichtige Quelle für Anforderungen sein. Als Requirements Engineer müssen Sie oft viel lesen, vor allem zu Beginn eines Projekts. Alle Arten von Dokumenten können relevant sein: Firmen-, domänen- und projektbezogene Dokumente, Produkt- und Prozessbeschreibungen, rechtliche und regulatorische Unterlagen usw. Wie bei den Stakeholdern können Sie zwischen internen und externen Dokumenten unterscheiden. Interne Dokumente können leicht zu bekommen sein, sind aber möglicherweise vertraulich und können ohne ausdrückliche Zustimmung nicht weitergegeben werden. Foundation Level | Handbuch | © IREB 94 | 174 Häufig müssen Sie eine Geheimhaltungsvereinbarung unterzeichnen, bevor Sie Zugang zu ihnen erhalten. Externe Dokumente können schwer zu finden sein, sind aber in der Regel öffentlich. Falls nicht, stellen Sie sicher, dass Sie Zugang zu ihnen haben und sie benutzen dürfen. Dokumente können eine gute Ausgangsbasis sein andere Quellen zu finden. Zum Beispiel kann eine interne Prozessbeschreibung bestimmte Rollen erwähnen, die an diesem Prozess beteiligt sind, was Sie wiederum zu neuen potenziellen Stakeholdern führen kann. Dokumente können jedoch auch direkte Quellen für Anforderungen sein, insbesondere solche, die von Stakeholdern leicht übersehen oder üblicherweise nicht erwähnt werden: Einschränkungen in Normen, Unternehmensrichtlinien und andere rechtliche oder behördliche Dokumente, detaillierte Anforderungen in Verfahren und Arbeitsanweisungen, brillante neue Ideen in Marketingmaterial von Wettbewerbern. Das Studium der Dokumentation kann Ihnen helfen, den Kontext des zu entwickelnden Systems zu verstehen, auch das Lesen von E-Mails zwischen Personen, die die Initiative für das Projekt ergriffen haben. Über vergleichbare Lösungen für Probleme und Ziele in anderen Unternehmen und Bereichen zu lesen, kann Ihre Phantasie anregen und eine machbare Richtung für Ihr aktuelles Projekt aufzeigen. Als Requirements Engineer sollten Sie sich bewusst sein, dass ein Dokument immer mit Personen in Verbindung steht: Dem/den Autor(en), dem (Ziel-)Publikum, einem verantwortlichen Manager oder Auditor, der die Einhaltung des Dokuments überprüft, jemandem, der Sie auf seine Existenz hingewiesen hat, usw. All diese Personen können eine Rolle als Stakeholder spielen. Es liegt an Ihnen, herauszufinden, ob dies der Fall ist oder nicht. Sie sollten immer die Gültigkeit und Relevanz eines Dokuments prüfen, und oft müssen Ihnen die Stakeholder dies bestätigen. Wenn Sie Anforderungen aus einem ungültigen oder veralteten Dokument ableiten würden, würde das aus diesen Anforderungen entwickelte System wahrscheinlich scheitern. Genau wie die Stakeholder müssen Dokumente, die als Anforderungsquellen verwendet werden, verwaltet werden. Sie können eine Dokumentenliste verwenden, vergleichbar mit der oben besprochenen Stakeholderliste. Alle Dokumente sollten in einer gemeinsamen, katalogisierten, Bibliothek mit einer eindeutigen Identifizierung aufbewahrt werden, damit sie referenziert werden können. Daten und Versionsnummern sind wichtig, um sich vor der Arbeit mit veralteten Versionen zu schützen. Sie könnten in regelmäßigen Abständen überprüfen, ob eine neuere Version veröffentlicht wurde und ob dies die Anforderungen beeinflusst. Sie sollten vorzugsweise mit finalen Versionen arbeiten, aber in der Praxis haben Sie es oft mit Entwürfen zu tun, sodass Sie auch den Status von Dokumenten erfassen müssen. Bewahren Sie alte Versionen in einem Archiv auf, denn sie können wichtig sein, um zu verstehen, wie sich ein System und seine Anforderungen entwickelt haben. Die Einrichtung einer geeigneten und genauen Verwaltung der entsprechenden Dokumente bereits zu Beginn eines Projekts erspart Ihnen später viel Arbeit beim Requirements Engineering, bei der Entwicklung und Bereitstellung. Es ist ein guter Ausgangspunkt für die Umsetzung der Verfolgbarkeit, wie in Kapitel 6.6 diskutiert. Foundation Level | Handbuch | © IREB 95 | 174 4.1.3 Andere Systeme Sie können auch andere Systeme als Quellen für Anforderungen an das gewünschte System in Betracht ziehen. Hier kann zwischen internen und externen Systemen unterschieden werden, genau wie bei den Dokumenten und mit den gleichen Überlegungen zum Zugang und zur Vertraulichkeit. Eine weitere Unterscheidung ist die zwischen ähnlichen Systemen und Schnittstellen-Systemen. Ähnliche Systeme haben bestimmte Funktionalitäten mit dem zu entwickelnden System gemeinsam. Dabei kann es sich um Vorgänger- oder Altsysteme, Konkurrenzsysteme, vergleichbare Systeme, die in anderen Organisationen verwendet werden, usw. handeln. Oft studiert man sie anhand ihrer Dokumentation, aber manchmal kann man sie auch in Aktion beobachten oder sie ausprobieren als wären sie eine Art Prototyp. Möglicherweise können Sie sich an deren Benutzer wenden, um mehr über die Funktionalitäten und Lösungen solcher Systeme zu erfahren. Vorgänger- oder Altsysteme sind oft eine gute Quelle für die Ermittlung detaillierter (funktionaler und qualitativer) Anforderungen und Randbedingungen. Seien Sie sich jedoch bewusst, dass (insbesondere technische) Randbedingungen aus der Vergangenheit möglicherweise nicht mehr relevant sind und Ihren aktuellen Lösungsraum nicht mehr einschränken. Manchmal werden ein neues System und ein Altsystem für einen bestimmten Zeitraum nebeneinander betrieben, was zu zusätzlichen Anforderungen führt, beispielsweise im Hinblick auf die gemeinsame Nutzung von Daten. Konkurrierende und vergleichbare Systeme können auf ihre Lösungseigenschaften hin untersucht werden und können eine gute Quelle für die Identifizierung von Begeisterungsfaktoren sein (siehe Kapitel 4.2.1). Schnittstellen-Systeme haben eine direkte Beziehung zu dem System, für das Sie die Anforderungen entwickeln. Sie tauschen Daten mit Ihrem System als Quelle und/oder Senke über eine Schnittstelle (synchron oder asynchron, in Echtzeit oder im Batch) aus (siehe auch Kapitel 3.4.2 zu Systemschnittstellen in der Kontextmodellierung). Die richtige Konfiguration, der richtige Inhalt und das richtige Verhalten einer solchen Schnittstelle ist oft entscheidend dafür, dass Ihr System funktioniert, deshalb müssen Sie das System im Detail verstehen. Sie können Schnittstellen-Systeme anhand ihrer Dokumentation studieren, aber da hier jedes (technische) Detail wichtig ist, können Simulationen oder Tests notwendig sein. Insbesondere bei älteren oder Legacy-Systemen können Sie sich nicht darauf verlassen, dass deren Dokumentation aktuell ist, sodass Sie einen Nachweis benötigen. Um eine Schnittstelle zu verstehen, müssen Sie auch den Kontext, die Funktionalität und das Verhalten des Schnittstellen-Systems verstehen. Es wird hilfreich sein, wenn Sie sich an Anwendungsmanager, Architekten oder Designer solcher Systeme wenden können, insbesondere wenn das Schnittstellen-System selbst aktualisiert werden muss, um die neue Schnittstelle zu ermöglichen. Seien Sie sich auch bewusst, dass ein Schnittstellen-System selbst Benutzer haben wird. Es könnte interessant sein, diese Benutzer ebenfalls als Stakeholder zu betrachten, in Anlehnung an Alexanders erweitertes Umfeld. Foundation Level | Handbuch | © IREB 96 | 174 4.2 Ermittlung von Anforderungen Wenn wir mit der Analogie der Wasserentnahme aus einem Brunnen fortfahren, sind wir jetzt an dem Punkt angelangt, an dem wir den Brunnen gefunden haben, und wir fangen an, am Seil zu ziehen, um den Eimer mit dem benötigten Wasser (oder in diesem Fall den Anforderungen) an die Oberfläche zu bringen. Das ist es, was wir Ermittlung nennen: Der Aufwand, den der Requirements Engineer betreibt, um implizite Bedürfnisse, Forderungen, Wünsche, Erfordernisse, Erwartungen - die bisher in ihren Quellen verborgen waren - in explizite, verständliche, erkennbare und überprüfbare Anforderungen zu verwandeln. Natürlich müssen wir alle Brunnen nutzen, um vollständig zu sein, und das Seil in der richtigen Weise ziehen, um sicherzustellen, dass wir das gesamte Wasser an die Oberfläche bekommen. In der Terminologie des Requirements Engineering sagen wir, dass wir die richtigen Ermittlungsstechniken anwenden sollten. Eine übliche Kategorisierung von Ermittlungstechniken ist die Unterscheidung zwischen ▪ Erhebungstechniken ▪ Entwurfs- und Ideenfindungstechniken Aus diesen Kategorien können Sie eine breite Palette von Ermittlungstechniken mit jeweils eigenen Merkmalen auswählen. Abbildung 4.4 gibt einen Überblick über die Ermittlungstechniken in ihren Kategorien und Unterkategorien. Abbildung 4.4 Ein Überblick über Ermittlungstechniken Eine entscheidende Schlüsselkompetenz des Requirements Engineers ist die Fähigkeit, unter den gegebenen Umständen die richtige (Mischung von) Techniken auszuwählen. Die Auswahl der richtigen Technik kann von vielen Faktoren abhängen, z.B: Foundation Level | Handbuch | © IREB 97 | 174 ▪ Art des Systems Ein völlig neues, innovatives System wird eher von Entwurfs- und Ideenfindungstechniken profitieren, während ein Nachfolgesystem in einer sicherheitskritischen Umgebung möglicherweise Fragetechniken und Systemarchäologie benötigt. ▪ Software-Entwicklungs-Lebenszyklusmodell In einem Wasserfallprojekt haben Sie möglicherweise umfangreiche Techniken wie Apprenticing oder Analogien eingeplant, während in einer agilen Umgebung Brainstorming, Storyboarding und Prototyping vorherrschen können. ▪ Beteiligte Personen Die Feldbeobachtung wird zum Beispiel in streng vertraulichen Unternehmen wahrscheinlich nicht geschätzt und eine breit angelegt Umfrage wird evtl. einer hohen Anzahl von Einzelinterviews vorgezogen. ▪ Organisatorischer Aufbau Eine etablierte staatliche Organisation braucht einen völlig anderen Ansatz als ein junges Startup-Unternehmen. Ein verstreutes, stark dezentralisiertes Unternehmen braucht einen anderen Ansatz als ein kompaktes Unternehmen mit einem einzigen Standort. Die besten Ergebnisse werden in der Regel durch die Kombination verschiedener Ermittlungstechniken erzielt. Einen systematischen Ansatz für ihre Auswahl finden Sie bei [CaDJ2014]. Erhebungstechniken sind - oder sollten zumindest - in der Lage sein, alle Arten von Anforderungen aufzuspüren. In der Praxis des Requirements Engineering werden jedoch explizite funktionale Anforderungen oft überbewertet, und den impliziteren Qualitätsanforderungen und Randbedingungen wird weniger Aufmerksamkeit geschenkt. Dies kann dazu führen, dass ein System - obwohl alle funktionalen Anforderungen erfüllt sind - nicht funktioniert, eine schlechte Benutzerfreundlichkeit aufweist, den architektonischen Richtlinien nicht entspricht, oder bestimmte andere Qualitätsanforderungen oder Randbedingungen nicht erfüllt und folglich nicht akzeptiert wird. Stakeholder können Quellen sein, aber oft finden Sie weitere Informationen in Dokumenten. Bei der Ermittlung von Qualitätsanforderungen kann die Anwendung einer Checkliste auf der Grundlage der Norm ISO 25010 [ISO25010] helfen, diese zu erkennen und zu quantifizieren, z.B. bei der Vorbereitung auf ein Interview. Randbedingungen können gefunden werden, indem man mögliche Einschränkungen des Lösungsraumes in Betracht zieht, z.B. technische, architektonische, rechtliche, organisatorische, kulturelle oder umweltbezogene Probleme. Relevante Dokumentation kann oft durch Mitarbeiter identifiziert werden. Foundation Level | Handbuch | © IREB 98 | 174 4.2.1 Das Kano-Modell Einer der Hauptumstände, die bei der Auswahl einer Ermittlungstechnik zu berücksichtigen sind, ist die Art und die Bedeutung einer Anforderung, die wir aufzudecken versuchen. Um mehr Einblick in die Art bestimmter Anforderungen zu erhalten, bietet sich das Kano-Modell [Verd2014] an. Dieses Modell, dargestellt in Abbildung 4.5, klassifiziert die Merkmale (Features) eines Systems in drei Kategorien: ▪ Begeisterungsfaktoren (Synonyme: Delighters, unbewusste Anforderungen) Ein Begeisterungsfaktor ist ein Merkmal, dessen sich die Kunden nicht bewusst sind, deshalb nennen wir es unbewusst. Die Kunden fragen nicht nach dem Merkmal, weil sie nicht wissen, dass es im System möglich ist - zum Beispiel ein Smartphone, das sich in einen Beamer verwandeln lässt. Am Anfang, wenn das Feature neu auf dem Markt ist, werden die meisten Kunden ihre Zweifel daran haben, aber wenn einige frühe Anwender (Early Adopters) es ausprobiert haben und anfangen, es zu verbreiten, wollen es immer mehr Leute haben. Wenn ein Begeisterungsfaktor nicht existiert, wird sich niemand beschweren, aber wenn er da ist, kann dies ein Unterscheidungsmerkmal sein, das viele Kunden anzieht. ▪ Leistungsfaktoren (Synonyme: Satisfiers, bewusste Anforderungen) Ein Leistungsfaktor ist etwas, das von den Kunden explizit verlangt wird (daher bewusste Anforderungen). Je mehr Leistungsfaktoren Sie in Ihr System einfügen können, desto höher wird die Zufriedenheit der Kunden sein. Ein Beispiel könnte die Anzahl der Objektive und Videooptionen in einem modernen Smartphone sein. Da das Hinzufügen von Leistungsfaktoren in der Regel auch höhere Kosten bedeutet, benötigen Sie oft eine Art Kosten-Nutzen-Analyse, um zu entscheiden, wie viele davon in das System aufgenommen werden. ▪ Basisfaktoren (Synonyme: Dissatisfiers, unterbewusste Anforderungen) Ein Basisfaktor ist auch ein Merkmal, nach dem die Kunden nicht fragen. Allerdings ist der Grund dafür, nicht danach zu fragen, dass das Merkmal so offensichtlich (unterbewusst) ist, dass die Kunden sich nicht vorstellen können, dass es nicht Teil des Systems ist. Diese Merkmale werden stillschweigend als „must-haves” betrachtet. Stellen Sie sich ein Smartphone ohne GPS vor. Wenn ein Basisfaktor als Merkmal eines Systems aufgenommen wird, werden die Kunden ihn nicht bemerken, weil sie glauben, dass das System ohne ihn nicht existieren kann. Wenn Sie jedoch eine solche Anforderung übersehen und aus dem System herauslassen, werden die Kunden sehr verärgert sein und sich weigern, das System zu nutzen. Das Kano-Modell betrachtet die Anforderungen aus der Perspektive des Kunden. Es konzentriert sich auf Differenzierungsmerkmale und nicht auf die geäußerten Bedürfnisse. Mit Hilfe des Kano-Modells finden Sie möglicherweise mehr Anforderungen, als wenn Sie sich nur auf die explizit formulierten Bedürfnisse der Stakeholder konzentrieren. Wie wir später in diesem Kapitel sehen werden, können alle Kategorien mit bestimmten Ermittlungstechniken verknüpft werden. Foundation Level | Handbuch | © IREB 99 | 174 Abbildung 4.5 Das Kano-Modell Tatsächlich enthält das ursprüngliche Kano-Modell zwei weitere Kategorien, die unerheblichen (oder es ist mir egal) und die Rückweisungs- (oder ich hasse) Anforderungen. Diese Kategorien werden in den meisten Requirements Engineering-Handbüchern nicht besonders beachtet, können aber trotzdem für Sie als Requirements Engineer nützlich sein. Nehmen wir zum Beispiel an, dass Entwickler dem System aus technischen Gründen eine bestimmte Funktion hinzufügen wollen. Wenn Sie nach der Analyse feststellen, dass die Kunden dieser Funktion gegenüber gleichgültig sind, ist es bedenkenlos möglich, sie in das System aufzunehmen. Wenn es sich jedoch als Rückweisungs-Anforderung herausstellt, sollten Sie die Entwickler anweisen, nach einer weniger schädlichen Alternative zu suchen, da sich die Umsetzung dieser Anforderung als kostspieliger Fehler erweisen kann. Eine interessante Beobachtung bei der Arbeit mit dem Kano-Modell ist, dass die Anforderungen dazu tendieren sich im Laufe der Zeit zu ändern. Wenn jemand ein neues Feature einführt, gibt es keine Gewissheit darüber, wie der Markt auf dieses Feature reagieren wird. Manchmal ist es den Kunden gleichgültig, und das Feature wird nur überleben, wenn es den Preis des Produkts nicht erhöht. Wenn Kunden es ablehnen, wird das Feature wahrscheinlich so schnell wie möglich aus dem Produkt entfernt. Wenn den Kunden (vielleicht anfangs einer Avantgarde) das Feature jedoch gefällt, wird es zum Begeisterungsfaktor, zu einem Alleinstellungsmerkmal, für das die Kunden bereit sind, den Preis zu zahlen. Wenn immer mehr Kunden dieses neue Feature entdecken, erleben und mögen, wird es zu einem Leistungsfaktor, der ausdrücklich gewünscht wird. Nach und nach, wenn ähnliche Systeme beginnen, dasselbe Feature zu implementieren, vergessen die Kunden möglicherweise, dass Systeme ursprünglich ein solches Feature nicht enthalten haben, und nehmen es als selbstverständlich hin, wodurch es Foundation Level | Handbuch | © IREB 100 | 174 zu einem Basisfaktor wird. Deshalb enthalten viele Systeme Funktionen, die von den Anwendern als unverzichtbar angesehen werden, ohne zu wissen, warum und folglich, ohne explizit danach zu fragen. Ein gutes Beispiel ist die Kamerafunktion bei Mobiltelefonen, für die dieser Prozess weniger als 20 Jahre dauerte. Als zum ersten Mal eine Kamera als Teil eines Mobiltelefons eingeführt wurde, waren die meisten Kunden verblüfft: Niemand hatte nach dieser Funktion gefragt, und die meisten Kunden dachten: „Wenn ich ein Foto machen will, brauche ich eine Kamera.” Einige frühe Anwender probierten es jedoch aus und entdeckten die Bequemlichkeit, Bilder ohne eine spezielle Kamera zu machen und sie sofort mit anderen Menschen teilen zu können, ohne einen Abzug machen zu müssen. Sie mochten die Kamerafunktion als Begeisterungsfaktor, und alle Marken begannen, sie in ihre Telefone zu implementieren, was sie zu einem Leistungsfaktor machte: Je besser die Bilder waren, desto zufriedener war der Benutzer. Heutzutage geht jeder beim Kauf eines neuen Mobiltelefons davon aus, dass es eine Kamerafunktion haben wird, sodass sie zu einem Basisfaktor geworden ist: „Wenn ich mit diesem Handy kein Foto machen kann, ist es nutzlos.” Wie können Sie ein bestimmtes Feature kategorisieren? Sie verwenden die Technik der Kano-Analyse. Für ein bestimmtes Feature stellen Sie zwei Fragen an eine repräsentative Gruppe potenzieller Benutzer: (1) „Was würden Sie empfinden, wenn dieses Feature im System vorhanden wäre?” und (2) „Was würden Sie empfinden, wenn dieses Feature nicht im System vorhanden wäre?” Sie lassen sie die Antworten auf einer 5-Punkte-Skala zwischen „Ich liebe es” und „Ich hasse es” bewerten und zeichnen dann die Durchschnittswerte auf der Kano-Analysematrix auf, wie in Abbildung 4.5 dargestellt. Die Zelle, die sich ergibt, zeigt Ihnen die Kano-Klassifikation für das Feature an. Abbildung 4.6 Kano-Analyse-Matrix Die nächste Frage lautet: Warum sich bei der Anforderungsermittlung mit der Kano-Analyse beschäftigen? Foundation Level | Handbuch | © IREB 101 | 174 Wie wir in den folgenden Kapiteln erläutern, benötigen Sie verschiedene Techniken, um diese verschiedenen Kategorien von Merkmalen zu finden. Von sich aus werden die Stakeholder hauptsächlich über ihre Leistungsfaktoren sprechen - ihre bewussten Anforderungen, die sie explizit einfordern. Es ist viel schwieriger, die anderen Kategorien aufzuspüren, aber glücklicherweise gibt es mehrere nützliche Techniken, um dies zu tun. 4.2.2 Erhebungstechniken Mit Hilfe von Erhebungstechniken untersuchen Sie die verschiedenen Quellen, die Sie identifiziert haben und ermitteln von dort aus die Anforderungen. Diese etablierten Techniken sind im Requirements Engineering weit verbreitet und führen überwiegend zu Leistungsfaktoren und Basisfaktoren. Die Erhebungstechniken lassen sich weiter in vier Kategorien unterteilen: ▪ Fragetechniken ▪ Kollaborationstechniken ▪ Beobachtungstechniken ▪ Artefaktbasierte Techniken Fragetechniken werden immer in einer Interaktion mit Stakeholdern eingesetzt. Der Requirements Engineer stellt den Stakeholdern entsprechende Fragen, um die Stakeholder zum Nachdenken anzuregen und Antworten zu erhalten, aus denen Anforderungen abgeleitet werden können. Beispiele für Fragetechniken sind: ▪ Interviews Aufgrund ihrer Flexibilität sind Interviews wahrscheinlich eine der am häufigsten verwendeten Ermittlungstechniken. Sie erfordern keine speziellen Werkzeuge und können verwendet werden, um allgemeinere sowie sehr spezifische Anforderungen in Erfahrung zu bringen. In der Regel handelt es sich bei einem Interview um ein Einzelgespräch zwischen einem Requirements Engineer (Interviewer) und einem einzelnen Stakeholder (Befragter), aber auch eine kleine Gruppe von Befragten ist eine Option. Anforderungen, die über ein Interview ermittelt werden, sind in der Regel Leistungsfaktoren, da der Befragte bewusste Informationen äußert. Die Interviewtechnik ist nicht übermäßig kompliziert, und die meisten Menschen haben ein gutes Verständnis davon. Sie brauchen jedoch klare Ziele und eine gute Vorbereitung, um brauchbare Ergebnisse zu erzielen. Interviews können detaillierte Informationen enthüllen und bieten Flexibilität auf der Grundlage der gegebenen Antworten. Sie sind eher zeitaufwendig, sodass diese Technik weniger geeignet ist, wenn Sie eine große Anzahl von Stakeholdern erreichen wollen. ▪ Fragebögen Bei einem Fragebogen wird eine größere Gruppe von Stakeholdern gebeten, mündlich, schriftlich oder auf einer Webseite dieselben Fragen zu beantworten, die in strukturierter Weise präsentiert werden. Quantitative Fragebögen werden dazu Foundation Level | Handbuch | © IREB 102 | 174 verwendet, Hypothesen oder zuvor ermittelte Anforderungen zu bestätigen. Sie verwenden geschlossene Fragen (nur vordefinierte Antworten sind zulässig) und können daher schnell ausgewertet werden und statistische Informationen liefern. Auf der anderen Seite verwenden qualitative Fragebögen offene Fragen und können neue Anforderungen liefern. Sie liefern tendenziell komplexe Ergebnisse und sind daher in der Regel weitaus zeitaufwendiger in der Vorbereitung und auch in der Auswertung. Im Allgemeinen sind Fragebögen eine bevorzugte Technik für große Gruppen. Seien Sie sich jedoch bewusst, dass das Entwerfen eines guten Fragebogens mit ziemlich viel Aufwand verbunden ist. Ein Fragebogen ist oft der nächste Schritt nachdem auf der Grundlage einer Reihe von Interviews vorläufigen Idee entwickelt wurden, um diese innerhalb einer größeren Gruppe zu validieren. In der Kategorie der Kollaborationstechniken finden wir alle Arten der Zusammenarbeit zwischen dem Requirements Engineer und anderen Personen (Stakeholder, Experten, Benutzer, Kunden, etc.). Einige Beispiele sind: ▪ Workshops Workshop ist ein Überbegriff für gruppenorientierte Techniken, von kleinen formlosen Meetings bis hin zu organisierten Veranstaltungen mit dutzenden oder hunderten von Stakeholdern. Eine schöne Definition lautet wie folgt: "Ein Anforderungsworkshop ist ein strukturiertes Meeting, bei dem eine sorgfältig ausgewählte Gruppe von Stakeholdern und Fachexperten zusammenarbeitet, um Ergebnisse (wie z. B. Modelle und Dokumente), die die Anforderungen der Benutzer darstellen, zu definieren, zu erstellen, zu verfeinern und zu einem Abschluss zu bringen." [Gott2002]. Mit einem Workshop können Sie in kurzer Zeit einen guten globalen Einblick erhalten, weil Sie die Interaktion zwischen den Teilnehmern nutzen. Wenn Sie weitere Einzelheiten benötigen, sind nachfolgende Interviews oder Fragebögen angebracht. Workshops können als Erhebungstechnik dienen, sie können aber auch in Kreativitätstechniken eingesetzt werden (siehe Kapitel 4.2.3). ▪ Crowd-based Requirements-Engineering Beim Crowd-basierten (auch Schwarm-basiert) Requirements Engineering (siehe [GreA2017]) wird die Ermittlung in eine partizipatorische Anstrengung mit einer Menge von Stakeholdern, insbesondere den Benutzern, verwandelt, was zu genaueren Anforderungen und letztendlich zu besserer Software führt. Die Macht der Crowd liegt in der Vielfalt der Talente und Fachkenntnisse, die in darin vorhanden sind. Da die Menge der aus der Crowd gewonnenen Daten groß sein wird, ist eine automatisierte Plattform für die Verarbeitung dieser Daten unerlässlich. Diese Plattform sollte Community-orientierte Funktionen bieten, die die Zusammenarbeit und den Wissensaustausch unterstützen und das Engagement größerer Gruppen von Stakeholdern bei der Erfassung, Analyse und Entwicklung von Software- Foundation Level | Handbuch | © IREB 103 | 174 Anforderungen sowie die Validierung und Priorisierung dieser Anforderungen auf dynamische, nutzergetriebene Weise, fördern. Beobachtungstechniken werden auch in Bezug auf Stakeholder angewandt. Die Stakeholder werden beobachtet, während sie in ihren normalen (Geschäfts-)Prozessen in ihrem üblichen Kontext ohne direkte Einmischung des Requirements Engineers tätig sind. Beobachtungstechniken sind besonders nützlich, um Basisfaktoren zu identifizieren. Es kann sein, dass Sie spezielle Aktivitäten, Abläufe, Daten usw. beobachten, die den Stakeholdern so vertraut sind, dass sie nicht erwähnt werden, und diese Aspekte daher bei den Erhebungstechniken nicht so leicht zum Vorschein kommen. Gängige Formen von Beobachtungstechniken sind: ▪ Feldbeobachtung Bei der Feldbeobachtung beobachtet der Requirements Engineer (in der Regel) die Endbenutzer in ihrer Umgebung, während diese Benutzer die Aktivitäten ausführen, für die ein System entwickelt oder verbessert werden soll. Die Feldbeobachtung wird üblicherweise in Situationen angewendet, in denen eine Interaktion die Benutzer ablenken, oder den eigentlichen Prozess stören und die Ergebnisse potenziell verfälschen würde. Sie kann auch angewendet werden, ohne dass die beobachteten Personen darüber informiert werden, z. B. mit anderen Patienten im Wartezimmer einer Arztpraxis sitzen und diese während der Wartezeit beobachten. Mit der Feldbeobachtung werden Sie in der Lage sein, (oft detaillierte) Anforderungen zu erkennen, die mit anderen Techniken nicht leicht zu finden wären, z.B. weil Handlungen und Verhaltensweisen zu kompliziert sind, um sie in Worte zu fassen. Seien Sie sich bewusst, dass die Feldbeobachtung viel Vorbereitung, ein scharfes Auge und viel Zeit erfordert. Video ist recht hilfreich, um das Verhalten der Stakeholder festzuhalten. Es kann in Verbindung mit der direkten Feldbeobachtung verwendet werden und kann diese sogar in Situationen ersetzen, in denen die tatsächliche Anwesenheit des Requirements Engineers nicht erlaubt oder gewünscht ist. Video bietet die Möglichkeit der Nachbearbeitung, um schwer zu beobachtende Handlungen und Verfahren detailliert untersuchen zu können. ▪ Apprenticing Das Apprenticing unterscheidet sich von der Feldbeobachtung dadurch, dass es partizipatorisch ist. Beim Apprenticing absolviert der Requirements Engineer (Auszubildender) ein Art Praktikum in der Umgebung, in der das vorliegende System eingesetzt werden soll (oder bereits im Einsatz ist), und erfahrene Benutzer (Meister) bringen dem Auszubildenden bei, wie die Dinge funktionieren. Der Auszubildende nimmt teil, mischt sich aber nicht ein. Er verhält sich wie ein Neuling auf dem Gebiet und darf Fehler machen und „dumme” Fragen stellen. Ziel ist es, ein tiefes Verständnis der Domäne, des Geschäfts und der Prozesse zu schaffen, bevor mit der eigentlichen Ermittlung der Anforderungen begonnen wird. Eine nachträgliche Aktivität mit Interviews und Fragebögen wird oft erforderlich sein, um die ursprünglichen Ideen zu verifizieren. Die daraus resultierenden Anforderungen können anschließend Foundation Level | Handbuch | © IREB 104 | 174 dokumentiert und validiert werden. Die optimale Dauer eines solchen Praktikums hängt von vielen verschiedenen Faktoren ab (z.B. Komplexität des Prozesses, Wiederholungshäufigkeit, zeitliche Verfügbarkeit von Meister und Auszubildendem), variiert aber in der Regel zwischen einem Tag und mehreren Wochen. Seien Sie sich bewusst, dass es in bestimmten Bereichen, wie Medizin, Luftfahrt oder Militär, schwierig oder unmöglich sein kann, ein Apprenticing zu organisieren. Bei artefaktbasierten Techniken werden nicht (direkt) Stakeholder, sondern Arbeitsprodukte wie Dokumente und Systeme oder sogar Bilder, Audio- und Videodateien als Quellen für Anforderungen verwendet. Diese Techniken können (manchmal sehr detaillierte) Leistungsfaktoren und Basisfaktoren zu Tage fördern. Es ist in der Regel eine zeitaufwändige Aufgabe, (oft schlecht strukturierte, veraltete oder teilweise irrelevante) Arbeitsprodukte im Detail zu untersuchen. Nichtsdestotrotz können artefaktbasierte Techniken nützlich sein, insbesondere dann, wenn die Stakeholder nicht ohne weiteres verfügbar sind. Einige Beispiele für artefaktbasierte Techniken sind: ▪ Systemarchäologie In der Systemarchäologie werden Anforderungen aus bestehenden Systemen - wie z.B. Altsystemen, Konkurrenzsystemen oder auch analogen Systemen - extrahiert, indem deren Dokumentation (Designs, Handbücher) oder Implementierung (Code, Kommentare, Skripte, User Stories, Testfälle) analysiert wird. Diese Technik kommt vor allem dann zum Einsatz, wenn ein bestehendes System seit vielen Jahren im Einsatz ist und nun aus welchen Gründen auch immer durch ein neues System ersetzt werden soll. Das neue System muss die gleiche Funktionalität wie das alte System oder zumindest bestimmte Teile davon abdecken. Systemarchäologie nimmt oft viel Zeit in Anspruch, kann aber detaillierte Anforderungen und Randbedingungen aufzeigen, die sonst nicht leicht zu erkennen sind. Sie werden jedoch zusätzliche Zeit benötigen, um über andere Kanäle zu prüfen, ob diese Anforderungen noch gültig und relevant sind, oder nicht. ▪ Feedback-Analyse Es gibt viele Möglichkeiten, Feedback von (potenziellen) Nutzern und Kunden zu sammeln, sei es zu einem bestehenden System oder zu einem Prototypen. FeedbackDaten können strukturiert (z.B. eine 5-Sterne-Bewertung in einem App-Store) oder unstrukturiert (wie die Kommentare zur Bewertung) sein. Sie können über WebUmfragen und Kontaktformulare, während Beta- oder A/B-Tests, in sozialen Medien oder sogar als Kundenkommentare in einem Call-Center erfasst werden. Oft ist die Datenmenge recht groß, und die Analyse ist zeitaufwendig. Das Feedback kann jedoch sehr nützlich sein, um einen Einblick in die Probleme und Vorteile des Benutzers zu gewinnen. Negative Bewertungen und kritische Anmerkungen helfen Ihnen, unbemerkte Basisfaktoren zu ermitteln. Positive Bewertungen und Komplimente geben Ihnen zusätzliche Informationen über Leistungsfaktoren. Gelegentlich können Kommentare sogar innovative Ideen enthalten, die sich in Begeisterungsfaktoren Foundation Level | Handbuch | © IREB 105 | 174 verwandeln lassen. Die Feedback-Analyse kann somit zur Anpassung bestehender Anforderungen, aber auch zur Entdeckung neuer Anforderungen führen. ▪ Wiederverwendung von Anforderungen Viele Organisationen verfügen bereits über eine große Sammlung von Anforderungen, die in der Vergangenheit für frühere Systeme ermittelt und ausgearbeitet wurden. Viele dieser Anforderungen können auch für ein neues System anwendbar sein, insbesondere Anforderungen, die aus einem übergreifenden Domänenmodell abgeleitet wurden. Daher kann die Wiederverwendung von vorhandenen Anforderungen viel Zeit und Geld sparen, weil Sie deren Ermittlung überspringen können. Dies funktioniert jedoch nur, wenn diese Sammlung bestehender Anforderungen aktuell, effektiv verwaltet, leicht verfügbar und umfassend dokumentiert ist, was leider nicht oft der Fall ist. Selbst wenn die Wiederverwendung von Anforderungen machbar ist, sollten Sie sich bewusst sein, dass Sie mit den Stakeholdern validieren müssen, ob diese wiederverwendbaren Anforderungen in der neuen Situation relevant und gültig sind, sei es direkt oder mit einigen Anpassungen. 4.2.3 Entwurfs- und Ideenfindungstechniken In der Vergangenheit konzentrierte sich das Requirements Engineering auf das Sammeln und Dokumentieren der notwendigen Anforderungen von allen relevanten Stakeholdern, indem es die im vorigen Kapitel vorgestellten Ermittlungstechniken anwandte. Der wachsende Einfluss von Software als Innovationstreiber in vielen Unternehmen erfordert nun zunehmend eine Neupositionierung des Requirements Engineering als kreative, problemlösende Tätigkeit. Dies beinhaltet die Anwendung anderer Techniken, die Stakeholder (und ihre Dokumente und Systeme) nicht mehr als die einzige Quelle von Anforderungen betrachten. Innovative Systeme brauchen neue, vielleicht disruptive Features, die sich die derzeitigen Stakeholder (noch) nicht vorstellen können. Um diesem Bedarf gerecht zu werden, sind Entwurfs- und Ideenfindungstechniken entstanden. Diese Techniken sollen die Kreativität, vor allem im Team, bei der Ideengenerierung anregen und können zusätzliche Möglichkeiten zur Ausarbeitung einer bestimmten Idee bieten. Diese Techniken können zu neuen und innovativen Anforderungen führen, die oft begeisternd sind. Innerhalb dieser weit gefassten Kategorie gibt es viele verschiedene Techniken, einige bemerkenswert einfach, andere recht aufwändig. Wir werden uns einige Beispiele aus zwei Unterkategorien ansehen: ▪ Kreativitätstechniken ▪ Entwurfstechniken Darüber hinaus werden wir uns mit dem wachsenden Bereich des Design Thinking befassen. Kreativitätstechniken stimulieren die Kreativität, um neue Anforderungen zu finden oder zu schaffen, die nicht direkt von den Stakeholdern ermittelt werden können, weil die Stakeholder sich nicht über die Machbarkeit bestimmter neuer Features oder (technischer) Innovationen bewusst sind. Diese Techniken werden in der Regel innerhalb diverser, Foundation Level | Handbuch | © IREB 106 | 174 multidisziplinärer Teams von IT-Mitarbeitern, wie Analysten, Requirements Engineers, Entwicklern, Testern, Product Ownern, Anwendungsmanagern usw. mit oder ohne Unternehmensvertreter, Benutzer, Kunden und anderen Stakeholdern angewandt. Die Techniken stimulieren unkonventionelles und freies Denken und das Ausarbeiten der Ideen aller Beteiligten. Leider garantiert keine von ihnen den Erfolg bei der Erzeugung kreativer Ergebnisse, da mehrere Mechanismen in unserem Gehirn zusammenkommen müssen, um kreative Ideen zu ermöglichen. Ein offensichtliches Beispiel, wo Kreativitätstechniken wichtig sind, ist die Spieleindustrie. Sie können die Spieler natürlich mit einer Erhebungstechnik nach ihren Anforderungen befragen und Sie werden erfahren, was die Spieler an den aktuellen Spielen mögen oder nicht mögen. Um jedoch ein erfolgreiches Spiel zu entwickeln, muss man die Spieler mit etwas Neuem überraschen, man muss ihre Begeisterungsfaktoren entdecken. Genau da passen die Kreativitätstechniken hinein. Es wurden mehrere Voraussetzungen als wichtige Faktoren für das Entstehen von Kreativität identifiziert: ▪ Zufall – und somit Zeit –, damit eine Idee entstehen kann ▪ Wissen zu dem betroffenen Thema, wodurch die Wahrscheinlichkeit steigt, dass eine wirklich relevante Idee entsteht. ▪ Motivation, da unser Gehirn nur kreativ sein kann, wenn für seinen Eigentümer ein direkter Nutzen daraus entsteht. ▪ Sicherheit, da nutzlose Ideen keine negativen Auswirkungen haben dürfen Zwei Beispiele für Kreativitätstechniken werden hier vorgestellt: ▪ Brainstorming Brainstorming (siehe [Osbo1948]) unterstützt die Entwicklung neuer Ideen für eine bestimmte Frage oder ein bestimmtes Problem. Wie bei den meisten Kreativitätstechniken, ist der entscheidende Aspekt des Brainstormings, Bewertungen zurückzustellen, indem man die Ideenfindung von der Analyse der Ideen trennt. Hier einige allgemeine Richtlinien für das Brainstorming: Quantität kommt vor Qualität. Freies Assoziieren und visionäres Denken sind ausdrücklich erwünscht. Das Übernehmen und Kombinieren von geäußerten Ideen ist erlaubt und erwünscht. Das Kritisieren von Ideen anderer Teilnehmer ist verboten, selbst dann, wenn eine Idee noch so absurd erscheint. Nach einer Brainstorming-Sitzung werden die entstandenen Ideen kategorisiert, bewertet und nach Prioritäten geordnet. Ausgewählte Ideen dienen dann als Input für die weitere Anforderungsermittlung. ▪ Analogietechnik Die Analogietechnik (siehe [Robe2001]) hilft bei der Entwicklung von Ideen für kritische und komplexe Themen. Sie verwendet Analogien, um das Denken und die Foundation Level | Handbuch | © IREB 107 | 174 Ideenfindung zu unterstützen. Ihr Erfolg oder Misserfolg wird hauptsächlich durch die Wahl einer geeigneten Analogie für das gegebene Problem beeinflusst. Die gewählte Analogie kann nahe (z.B. dasselbe Problem in einem anderen Unternehmen) oder entfernt (z.B. der Vergleich einer Organisation mit einem lebenden Organismus) vom ursprünglichen Problem sein. Die Anwendung der Analogietechnik erfolgt in zwei Schritten: Arbeiten Sie die Aspekte der gewählten Analogie im Detail aus, ohne sich auf das ursprüngliche Problem zu beziehen. Übertragen Sie alle identifizierten Aspekte der Analogie zurück auf das ursprüngliche Problem. Die sich daraus ergebenden Konzepte und Ideen werden dann als Ausgangspunkt für die weitere Anforderungsermittlung verwendet. Entwurfstechniken helfen bei der Erkundung und Ausarbeitung von Ideen, die mit Hilfe von Kreativitätstechniken entwickelt wurden, und tragen außerdem dazu bei, vage Bedürfnisse von Stakeholdern zu klären und zu konkretisieren. Sie stützen sich in hohem Maße auf visuelle oder greifbare Artefakte, die Zusammenarbeit im Team und Kundenfeedback. Beliebte Techniken in dieser Kategorie sind unter anderem: ▪ Prototyping Mit Prototyp (in Bezug auf die Anforderungsermittlung; siehe auch Kapitel 3.7 für weitere Informationen) meinen wir eine Art Zwischenarbeitsprodukt, das erstellt oder freigegeben wird, um Feedback zu erzeugen. Prototypen können von einfachen Papierskizzen bis hin zu funktionierenden Vorabversionen eines Systems reichen. Sie ermöglichen es den zukünftigen Benutzern, mehr oder weniger konkret mit dem System zu experimentieren und bestimmte, noch unklare Eigenschaften während des Requirements Engineering und vor der eigentlichen Implementierung zu untersuchen. Wie wir im Kapitel über die Validierung (4.4.2) sehen werden, werden Prototypen in erster Linie dazu verwendet, zu überprüfen, ob zuvor definierte Anforderungen korrekt umgesetzt wurden. Mit der richtigen Anleitung der Benutzer und der Analyse ihres Feedbacks kann diese Technik jedoch auch zur Ableitung neuer Anforderungen genutzt werden. Sie kann besonders nützlich sein, um nicht-funktionale Anforderungen, Basisfaktoren und Randbedingungen oder andere Merkmale zu erkennen, die in Modellen und Dokumentationen im Voraus nicht leicht verstanden oder definiert werden können. ▪ Verwendung von Szenarien und Storyboards Das Wort Szenario stammt aus dem Theater, wo es verwendet wird, um sich auf den Umriss eines Theaterstücks, einer Oper oder ähnlichem zu beziehen, wobei es eine Abfolge von Szenen mit ihren Charakteren bezeichnet. In der IT verwenden wir diesen Begriff, um einen Handlungsfluss für ein System zu beschreiben, einschließlich der beteiligten Benutzer (die wir hier gewöhnlich Akteure nennen). Anhand von Szenarien können Sie alternative Wege zur Realisierung eines Prozesses in einem System untersuchen. Aufgrund ihrer schlanken Struktur sind sie einfach zu entwickeln und Foundation Level | Handbuch | © IREB 108 | 174 lassen sich schnell ändern. Wie bei Prototypen können Szenarien und Storyboards sowohl bei der (frühen) Ermittlung als auch bei der (späteren) Validierung von Anforderungen eingesetzt werden. Szenarien können in schriftlicher oder visueller Form dokumentiert werden. Die visuelle Form eines Szenarios bezeichnet man als Storyboard. Ein Storyboard ist in der Regel eine Art Comic-Strip mit einer Reihe von Panels, die die Interaktion bestimmter Personas mit dem System zeigen. Siehe Abbildung 4.7 für ein Beispiel. Szenarien und Storyboards sind nützlich für die frühzeitige Ausarbeitung von Ideen in Bezug auf Prozesse und Aktivitäten. Abbildung 4.7 Beispiel für ein Storyboard Design Thinking ist nicht so sehr eine Technik, sondern vielmehr ein Konzept, eine Einstellung, eine Philosophie, eine Familie von Prozessen und oft ein Werkzeugkasten voller Techniken. Der Schwerpunkt liegt auf Innovation und Problemlösung. Es gibt mehrere Varianten des Design Thinking, wobei meist leichte, visuelle und agile Techniken verwendet werden. Zwei Grundprinzipien finden sich in allen Varianten wieder: ▪ Einfühlungsvermögen Der erste Schritt für Designdenker besteht darin, das wahre Problem hinter dem gegebenen Problem zu finden. Sie versuchen zu verstehen, was Stakeholder wirklich denken, fühlen und tun, wenn sie mit einem System interagieren. Deshalb bezeichnen wir Design Thinking oft als Human-Centered Design. Personas, Empathy-Mapping und Customer Co-Creation sind gängige Techniken zu diesem Zweck. Foundation Level | Handbuch | © IREB 109 | 174 ▪ Kreativität Ein gemeinsames Merkmal des Designdenkens ist der Diamant: Der Wechsel von divergentem und konvergentem Denken. Divergentes Denken zielt darauf ab, ein Thema breiter und tiefer zu erforschen, viele verschiedene Ideen zu generieren, und konvergentes Denken fokussiert, wählt aus, beschneidet, kombiniert diese Ideen zu einem einzigen abschließenden Ergebnis. Ein Grundmuster, das Double Diamond Model, ist in Abbildung 4.8 abgebildet (siehe [DeCo2007]). Eine detaillierte Behandlung des Design Thinking würde den Rahmen dieses Foundation Level Handbuchs sprengen. Abbildung 4.8 Das Double Diamond Modell 4.3 Lösung von Konflikten bezüglich Anforderungen Während der Anforderungsermittlung ermitteln Sie eine große Sammlung von Anforderungen, häufig aus unterschiedlichen Quellen, mithilfe verschiedener Techniken sowie mit unterschiedlichen Abstraktionsebenen und Detaillierungsgraden. Die von Ihnen verwendeten Ermittlungstechniken alleine garantieren nicht, dass diese Sammlung als Ganzes einen einzigen, konsistenten, vereinbarten Satz von Anforderungen bildet, der die wesentlichen Merkmale des Systems erfasst. Sowohl während als auch nach der Ermittlung einer Reihe von Anforderungen für ein bestimmtes System können Sie feststellen, dass einige der Anforderungen miteinander in Konflikt stehen: Sie können inkonsistent, inkompatibel, widersprüchlich sein. Es kann sein, dass Anforderungen untereinander in Konflikt stehen (z.B. „der gesamte Text muss schwarz auf weiß sein” versus „alle Fehlermeldungen müssen rot sein”) oder, dass einige Stakeholder eine unterschiedliche Meinung über die gleiche Anforderung haben (z.B. „alle Fehlermeldungen müssen rot sein” Foundation Level | Handbuch | © IREB 110 | 174 versus „Benutzer-Fehlermeldungen müssen rot sein, alle anderen Fehlermeldungen blau”). Da wir kein System (ggf. auch nur einen spezifischen Teil) auf der Grundlage widersprüchlicher Anforderungen entwickeln können, müssen die Konflikte gelöst werden, bevor die Entwicklung beginnen kann. Als Requirements Engineer sind Sie derjenige, der sicherstellen muss, dass alle Stakeholder zu einem gemeinsamen Verständnis (siehe Kapitel 2, Prinzip 3) des gesamten Anforderungssatzes gelangen, soweit er für sie relevant ist und, dass sie sich auf diesen Satz einigen. Aber was ist ein Konflikt? Ein Konflikt ist eine Art von Uneinigkeit zwischen Menschen: „Eine Interaktion zwischen Aktoren (Individuen, Gruppen, Organisationen usw.), wobei wenigstens ein Aktor eine Differenz bzw. Unvereinbarkeiten im Wahrnehmen und Denken bzw. Vorstellen und im Fühlen und im Wollen mit dem anderen Aktor (den anderen Aktoren) in der Art erlebt, dass beim Verwirklichen dessen, was der Aktor denkt, fühlt oder will eine Beeinträchtigung durch einen anderen Aktor (die anderen Aktoren) erfolge.“ [Glas1999]. Bei einem Anforderungskonflikt haben zwei oder mehr Stakeholder eine unterschiedliche oder sogar widersprüchliche Meinung zu einer bestimmten Anforderung oder ihre Anforderungen können nicht gleichzeitig in einem bestimmten System implementiert werden; siehe Abbildung 4.9. Abbildung 4.9 Ein Anforderungskonflikt Der Umgang mit Anforderungskonflikten kann schwierig, aufreibend und zeitintensiv sein, insbesondere wenn es um persönliche Angelegenheiten geht. Das Leugnen oder Ignorieren von Konflikten ist jedoch keine Option, sodass der Requirements Engineer aktiv nach Wegen zu deren Lösung suchen muss. Am Ende müssen alle Stakeholder alle für sie relevanten Anforderungen verstehen und ihnen zustimmen. Stimmen einige Stakeholder nicht zu, so muss dies als Anforderungskonflikt betrachtet werden, der entsprechend gelöst werden muss. Foundation Level | Handbuch | © IREB 111 | 174 4.3.1 Wie löst man einen Anforderungskonflikt? Um einen Anforderungskonflikt richtig zu lösen, sollten die folgenden Schritte befolgt werden: ▪ Konfliktidentifizierung In unserem täglichen Leben haben wir oft Konflikte. Sie geben uns ein unangenehmes Gefühl, sodass eine übliche Strategie einfach darin besteht, sie zu vermeiden, zu ignorieren oder zu leugnen. Das kann dazu führen, dass Konflikte schwer zu erkennen sind. Die meisten von ihnen neigen dazu sich zu verstecken und können nur durch sorgfältige Beobachtung aufgedeckt werden. Es gibt viele Indikatoren, auf die Sie achten können, sowohl in der Kommunikation als auch in der Dokumentation: In der Kommunikation können Sie Verhaltensweisen wie Verleugnung, Gleichgültigkeit, Pedanterie, ständiges Nachfragen nach mehr Details, absichtliche Falschinterpretationen, Verheimlichung oder Delegation beobachten. In der Dokumentation finden Sie unter Umständen Dinge wie widersprüchliche Aussagen von Stakeholdern, konträre Ergebnisse aus der Analyse von Dokumenten oder Systemen, Inkonsistenzen auf verschiedenen Detailebenen und eine uneinheitliche Verwendung von Begriffen. Wenn Sie solche Indikatoren erkennen, bedeutet dies nicht unbedingt, dass ein Anforderungskonflikt vorliegt, aber Sie sollten auf jeden Fall misstrauisch sein. Eine gründliche Diskussion mit den Stakeholdern kann dann einen verborgenen Konflikt an die Oberfläche bringen. ▪ Konfliktanalyse Wurde ein Konflikt identifiziert, so muss der Requirements Engineer zuerst klären, ob es sich dabei um einen Anforderungskonflikt handelt oder nicht. Schließlich liegt ein Anforderungskonflikt in erster Linie in der Verantwortung des Requirements Engineers, andere Konflikte können von anderen Stakeholdern, z.B. einem Abteilungsleiter oder einem Teamleiter, gelöst werden. Der Requirements Engineer sollte die Art des Anforderungskonflikts vollständig verstehen, bevor er versucht, ihn zu lösen. Das bedeutet, dass Sie mehr Informationen über den Konflikt selbst und die beteiligten Stakeholder sammeln müssen. Viele Aspekte verdienen Aufmerksamkeit: ▪ Sachverhalt: Der Umfang, das Problem oder die eigentliche Frage, die hinter dem Konflikt steht. ▪ Betroffene Anforderungen: Welche spezifischen Anforderungen sind betroffen? ▪ Beteiligte Stakeholder: Wer ist mit wem über was nicht einer Meinung? ▪ Konfliktpositionen der Stakeholder: Lassen Sie sie ihren Standpunkt so klar wie möglich darlegen, damit alle Konfliktparteien das zugrunde liegende Problem verstehen. ▪ Die Ursache des Konflikts: Was ist der Grund für die Meinungsverschiedenheiten? ▪ Die Historie des Konflikts: Was ist zuvor geschehen, das diese Meinungen jetzt beeinflusst? Foundation Level | Handbuch | © IREB 112 | 174 ▪ ▪ ▪ ▪ Folgen: Die geschätzten Kosten und Risiken, die sowohl mit der Lösung des Konflikts als auch mit der Nichtlösung des Konflikts verbunden sind. Projektrandbedingungen: Persönliche, organisatorische, inhalts- oder domänenspezifische Randbedingungen können den Lösungsraum bestimmen. Die Analyse dieser Informationen wird Ihnen helfen, die Art des Konflikts zu erkennen (weitere Informationen finden Sie im Kapitel 4.3.2) und Wege zu seiner Lösung aufzuzeigen. Konfliktlösung Sobald ein tiefgehendes Verständnis des Wesens des Anforderungskonflikts, der Haltung der beteiligten Stakeholder und der Projektrandbedingungen erreicht ist, wählt der Requirements Engineer eine geeignete Lösungstechnik aus. Es können viele Techniken verwendet werden, wie in Kapitel 4.3.3 erläutert wird. Der erste Schritt sollte immer darin bestehen, dass die gewählte Technik von den beteiligten Stakeholdern akzeptiert wird, bevor sie angewendet wird. Wenn einige Stakeholder von vornherein nicht mit der Anwendung einer bestimmten Technik einverstanden sind, werden sie das Ergebnis dieser Technik mit Sicherheit nicht akzeptieren, sodass der Konflikt am Ende nicht gelöst wird. Grundsätzlich gehört der Requirements Engineer nicht zu den beteiligten Stakeholdern, daher können und sollten Sie die ausgewählten Lösungstechniken objektiv und streng neutral anwenden und jedes Ergebnis akzeptieren, das sich aus der Anwendung der Technik ergibt. ▪ Dokumentation der Konfliktlösung Die Konfliktlösung kann die Anforderungen in einer Weise beeinflussen, die für jemanden, der nicht am Konflikt beteiligt war, nicht offensichtlich ist. Der resultierende Satz von Anforderungen mag unlogisch oder ineffizient erscheinen. Daher sollte die Konfliktlösung angemessen dokumentiert und kommuniziert werden, im Hinblick auf Aspekte wie: ▪ Annahmen in Bezug auf den Konflikt und seine Auflösung ▪ in Betracht gezogene Alternativen ▪ Randbedingungen, die die gewählte Technik und/oder Auflösung beeinflussen ▪ Die Art und Weise, wie der Konflikt gelöst wurde, inklusive der Gründe, die zur Wahl der Konfliktlösungstechnik geführt haben ▪ Entscheider und weitere Beteiligte ▪ Wenn Sie die Konfliktlösung nicht dokumentieren, könnten Stakeholder getroffene Entscheidungen im Nachhinein einfach vergessen oder ignorieren. Und später im Projekt verstehen die Entwickler möglicherweise die Logik hinter einem bestimmten Systementwurf nicht und implementieren ihn möglicherweise auf eine andere Art und Weise. Foundation Level | Handbuch | © IREB 113 | 174 Sie brauchen keine Scheu vor Anforderungskonflikten zu haben, da sie immer auftreten werden. Das sollte Sie nicht überraschen, eigentlich sollten Sie beunruhigt sein, wenn Sie keine Konflikte entdecken. Sie sind recht häufig, wenn Sie sie also nicht finden, haben Sie wahrscheinlich einige übersehen. Aber ignorieren Sie sie niemals. Wenn Sie nicht alle Anforderungskonflikte, die Ihnen auffallen, gleich lösen, werden sie später im Entwicklungsprozess hochkommen. Und wie Barry Boehm [Boeh1981] schon vor langer Zeit herausgefunden hat, gilt: Je später man ein Problem entdeckt, desto teurer wird es, es zu lösen. 4.3.2 Konflikttypen Um ein besseres Verständnis der Natur eines Konflikts zu erreichen, ist es nützlich, zwischen verschiedenen Konflikttypen zu unterscheiden. Dies hilft bei der Auswahl geeigneter Konfliktlösungstechniken. Wir unterscheiden sechs Typen von Konflikten: ▪ Sachkonflikt Ein Sachkonflikt liegt vor, wenn die Konfliktparteien tatsächlich unterschiedliche sachliche Bedürfnisse haben, die zumeist durch die beabsichtigte Nutzung des Systems in unterschiedlichen Umgebungen verursacht werden. Ein gutes Beispiel dafür ist ein System, das in verschiedenen Ländern mit jeweils eigener Gesetzgebung angewendet werden soll. Es kann schwierig sein, einen solchen Konflikt zu lösen, da die zugrundeliegende Sachlage nicht geändert werden kann. Als erstes müssen deshalb die Fakten des Sachverhalts im Detail analysiert und dokumentiert werden, und die Konfliktparteien müssen sich über den genauen Gegenstand des Konflikts einigen. ▪ Datenkonflikt Ein Datenkonflikt liegt vor, wenn einige Parteien auf inkonsistente Daten aus unterschiedlichen Quellen verweisen oder sie dieselben Daten unterschiedlich interpretieren. Dies kann auf schlechte Kommunikation, fehlende Hintergrunddaten, kulturelle Unterschiede, bestehende Vorurteile usw. zurückzuführen sein. Vor allem Abschätzungen, wie z.B. über zukünftige Verkäufe, können leicht zu einem Datenkonflikt führen, da sie oft auf Annahmen beruhen. Einen Datenkonflikt zu erkennen ist nicht einfach, denn als Requirements Engineer denken Sie vielleicht, dass Ihre eigenen Quellen richtig sind und Ihre eigene Interpretation offensichtlich ist. Aufgrund dieser Voreingenommenheit vermutet man anfangs oft einen anderen Konflikttyp. Zu verstehen, wie Menschen zu einer anderen Interpretation kommen können, erfordert viel Einfühlungsvermögen. Kommunikation - immer und immer wieder - ist der Schlüssel sowohl zur Erkennung als auch zur Lösung dieser Konflikte. ▪ Interessenkonflikt Ein Interessenkonflikt beruht auf unterschiedlichen Positionen der Konfliktparteien, die durch persönliche Ziele, Ziele in Bezug auf eine Gruppe, oder Ziele in Bezug auf Foundation Level | Handbuch | © IREB 114 | 174 eine Rolle, gebildet werden. Sie sollten die Anliegen und Bedürfnisse der beteiligten Stakeholder verstehen, bevor Sie diesen Konflikttyp lösen können. Denken Sie jedoch daran, dass bei persönlichen Interessen die Stakeholder oft nicht ihre wahren Motive offenbaren und scheinbar sachliche, aber im Wesentlichen künstliche Argumente vorbringen. Wenn es in einer Diskussion um einen Interessenkonflikt geht, können Sie beobachten, wie die Konfliktparteien versuchen, sich gegenseitig davon zu überzeugen, ihren Argumenten zu folgen und die Bedürfnisse der Rolle oder Gruppe zu verstehen. Eine Lösung kann von der Identifizierung und Stärkung gemeinsamer Interessen profitieren. Die Arbeit an einem gemeinsamen Verständnis über den Nutzen und Schaden beider Parteien kann ein Ausgangspunkt für die Suche nach einer Lösung sein. ▪ Wertekonflikt Ein Wertekonflikt beruht auf Unterschieden in den Werten und Prinzipien der beteiligten Stakeholder. Im Vergleich zu einem Interessenkonflikt ist ein Wertekonflikt individueller und bezieht sich auf eine langfristige und globale Perspektive. Werte sind stabiler als Interessen und ändern sich selten kurzfristig. Wenn ein Wertekonflikt der Grund für eine Diskussion ist, werden die Konfliktparteien betonen, warum ihre Argumente aus ihrer Sicht wichtig sind, und dabei ihre inneren Werte und Prinzipien erkennen lassen. Sie neigen dazu, auf ihren Argumenten zu beharren und sind nicht bereit aufzugeben. Um solche Konflikte zu lösen, suchen Sie nach höheren Werten, die die Parteien vereinen. Wertekonflikte sind naturgemäß schwer zu lösen, und gegenseitiges Verständnis und die Anerkennung der Prinzipien des anderen ist das Beste, was man erreichen kann. ▪ Beziehungskonflikt Ein Beziehungskonflikt beruht in der Regel auf negativen Erfahrungen mit einer anderen Partei in der Vergangenheit, oder in vergleichbaren Situationen mit ähnlichen Menschen. Häufig sind Emotionen und Missverständnisse im Spiel, was die Lösung des Konflikts sehr viel schwieriger macht. Konfliktparteien missbrauchen Diskussionen über Anforderungen, um ihren Ärger über das Verhalten des anderen auszudrücken und vergessen dabei Fakten, Zahlen und Fairness. Es wird selten helfen, die Diskussion auf die Anforderungen zurückzuführen, manchmal gelingt es aber, die Parteien über einen höheren Wert wieder zusammenzubringen. In den meisten Fällen müssen Sie das Problem an andere Stakeholder oder an eine höhere Autoritätsebene eskalieren und auch das Auswechseln von Personen ist eine mögliche Lösung. Seien Sie sich bewusst, dass ein Beziehungskonflikt oft mit anderen Konflikttypen zusammentrifft, zum Beispiel mit einem Interessenkonflikt. Die Analyse der Ursache und die Lösung des anderen Konflikttyps kann dann der beste Weg zur Verbesserung der Beziehung sein. ▪ Strukturkonflikt Wir bezeichnen einen Konflikt als strukturell, wenn er die Ungleichheit der Macht, den Wettbewerb um begrenzte Ressourcen oder strukturelle Abhängigkeiten zwischen Foundation Level | Handbuch | © IREB 115 | 174 den Parteien beinhaltet. Die daraus resultierende Unausgewogenheit (die oft nur von einer der Parteien wahrgenommen wird) führt zu Problemen bei der Kommunikation und Entscheidungsfindung. Ein weiterer Grund für solche Konflikte können Einschränkungen von Ressourcen oder Abhängigkeiten von Arbeitsprodukten sein, die von einer anderen Partei zu liefern sind. Konfliktparteien können die Diskussion über Anforderungen dazu nutzen, den Status quo entweder zu ändern oder ihn aufrechtzuerhalten. Die Hierarchie kann missbraucht werden, um Entscheidungen durchzusetzen. Auch bei strukturellen Konflikten ist häufig eine Eskalation des Problems an andere Stakeholder oder eine höhere Autoritätsebene notwendig. Die meisten Anforderungskonflikte können entweder als Sach-, Daten-, Interessen- oder Wertekonflikt eingestuft werden. Beziehungs- und Strukturkonflikte stehen oft nicht in direktem Zusammenhang mit den Anforderungen und daher ist der Requirements Engineer möglicherweise nicht die geeignete Partei, um sie zu lösen. In Wirklichkeit können die meisten Konflikte jedoch mehr als einem Konflikttyp zugeordnet werden, da verschiedene Ursachen zusammenwirken. Deshalb ist es ratsam, auf alle Typen von Konflikten zu achten, auch wenn die Lösung nicht in Ihrer alleinigen Verantwortung liegt. Wenn jemand anderes den Konflikt lösen sollte, stellen Sie sicher, dass dies auch geschieht. Solange ein Konflikt nicht gelöst wird, wird er sich weiterhin negativ auf Ihre Arbeit als Requirements Engineer auswirken. 4.3.3 Konfliktlösungstechniken Abhängig vom Konflikttyp und dem Kontext (Stakeholder, Randbedingungen usw.) wird eine geeignete Lösungstechnik ausgewählt. Zu den häufig verwendeten Techniken gehören [PoRu2015]: Einigung Eine Einigung ist das Ergebnis einer Diskussion zwischen den beteiligten Stakeholdern, die so lange fortgesetzt wird, bis sie die Standpunkte des jeweils anderen vollständig verstehen und einer von allen Parteien bevorzugten Option zustimmen. Sie kann sehr zeitaufwendig sein, insbesondere wenn mehrere Parteien beteiligt sind. Im positiven Fall wird das Ergebnis eine zusätzliche Motivation der Stakeholder darstellen, sodass das es eine gute Chance hat, langfristig Bestand zu haben. Das Streben nach einer Einigung ist bei Datenkonflikten üblich. Wenn diese Technik innerhalb eines akzeptablen Zeitrahmens keinen Erfolg bringt, können danach andere Techniken eingesetzt werden. Foundation Level | Handbuch | © IREB 116 | 174 Abbildung 4.10 Einigung Kompromiss Ein Kompromiss ist einer Einigung sehr ähnlich. Hier einigen sich die Stakeholder jedoch auf eine Option, die nicht ihre bevorzugte ist, mit der sie aber leben können, weil das Akzeptieren des Kompromisses als vorteilhafter angesehen wird als die Fortsetzung des Konflikts. Daher kann ein Kompromiss auch langfristig Bestand haben. Der Kompromiss kann neue Elemente enthalten, die in den ursprünglichen Präferenzen der Stakeholder nicht vorhanden waren und die möglicherweise vom Requirements Engineer eingeführt wurden. Ein guter Kompromiss ist eine Alternative, bei der sich alle Parteien mit der Balance wohl fühlen, Dinge aufzugeben und im Gegenzug etwas anderes zu bekommen. Ein Kompromiss ist oft der nächste Schritt, wenn eine Einigung nicht rechtzeitig erzielt werden kann. Er eignet sich für Sachkonflikte und kann auch bei Interessen- und Strukturkonflikten eingesetzt werden. Abbildung 4.11 Kompromiss Foundation Level | Handbuch | © IREB 117 | 174 Abstimmung Abstimmungen funktionieren am besten, wenn eine relativ einfache Wahl zwischen einer überschaubaren Anzahl von widersprüchlichen Anforderungen getroffen werden muss. Stakeholder, die an der Abstimmung teilnehmen (in der Regel nicht nur die Konfliktparteien, sondern alle beteiligten Stakeholder), sollten die Alternativen und die Konsequenzen ihrer Abstimmung genau kennen. Um Einflüsse durch Abhängigkeiten oder ein Ungleichgewicht der Machtverhältnisse zu vermeiden, wird am besten anonym und mit einem neutralen Moderator abgestimmt. Das Abstimmungsverfahren selbst sollte vor der eigentlichen Abstimmung zwischen den Stakeholdern vereinbart werden. Abstimmungen sind ein schnelles und einfaches Mittel zur Konfliktlösung, aber die Partei, die die Abstimmung verliert, wird enttäuscht sein und möglicherweise Aufmerksamkeit benötigen. Die Stimmabgabe kann bei den meisten Konflikttypen funktionieren und ein guter Ansatz zur Lösung von Sach- und Interessenkonflikten sein. Abbildung 4.12 Abstimmung Ober-sticht-Unter Falls eine Einigung oder ein Kompromiss nicht erreicht werden kann und mindestens eine der Konfliktparteien sich weigert, an der Abstimmung teilzunehmen, kann eine Überstimmung durch Ober-sticht-Unter eine Option sein. Sie wird oft unter Druck angewendet, wenn nicht genügend Zeit zur Verfügung steht, um passendere Techniken anzuwenden. Gewöhnlich wird eine Überstimmung dadurch erreicht, dass die Wahl zwischen widersprüchlichen Anforderungen einem Entscheidungsträger übertragen wird, der in der Autorität oder Hierarchie höher steht als alle Konfliktparteien und über genügend Macht verfügt, um die Entscheidung umsetzen zu lassen. Die Technik ist daher ein guter Weg, Interessen- und Strukturkonflikte zu lösen. In dieser Situation ist es besonders wichtig, dass der Entscheidungsträger die Alternativen, die Position der Konfliktparteien und die Konsequenzen der Entscheidung vollständig versteht. Eine Variante des Ober-sticht-Unter besteht darin, die Entscheidung an eine dritte Partei auszulagern, zum Beispiel an einen externen Experten. In diesem Fall ist es wichtig, zunächst eine Einigung zwischen den Foundation Level | Handbuch | © IREB 118 | 174 Stakeholdern über den Entscheidungsträger zu erzielen. Wie bei der Abstimmung müssen Sie vermutlich auch hier dem Verlierer gegenüber aufmerksam sein. Variantenbildung Variantenbildung (Definition von Varianten) wird häufig bei Sach-, Interessen- und Wertekonflikten in Betracht gezogen. Wir haben gesehen, dass wir widersprüchliche Anforderungen nicht in ein und demselben System umsetzen können. Definition von Varianten bedeutet, dass wir für alle widersprüchlichen Anforderungen separate Lösungen aufbauen. Dies wird in der Regel durch die Entwicklung eines Systems umgesetzt, das durch Parameter so konfiguriert werden kann, dass es die gewünschten Eigenschaften aufweist. Dies mag wie eine perfekte Lösung erscheinen, aber sie hat ihren Preis: Die Definition der Lösung nimmt viel Zeit in Anspruch, und es wird eine wachsende Komplexität (sowie zusätzliche Kosten) in das System eingebracht, sowohl für die Entwicklung als auch während des Betriebs und der Wartung. Diese Technik ist daher nur durchführbar, wenn genügend Zeit und Budget zur Verfügung stehen. Abbildung 4.13 Variantenbildung Unterstützende Techniken Zusätzlich gibt es mehrere unterstützende Techniken, die in der Regel nicht allein, sondern eher zur Unterstützung der oben genannten Techniken eingesetzt werden. In Consider-All-Facts (CAF) betrachten Sie alternative Lösungen für eine Reihe von vordefinierten Kriterien, z.B. Kosten, Zeit, Risiko, verfügbare Ressourcen. Eine Abwägung dieser Kriterien kann mehr Klarheit über die Vor- und Nachteile der Alternativen schaffen und dabei helfen, die beste Alternative zu ermitteln. Plus-Minus-Interesting (PMI, siehe [DeBo2005]) ist ein Brainstorming- und Entscheidungsinstrument. Es fördert die Prüfung von Ideen und Konzepten aus mehr als einer Perspektive und ist daher wertvoll für die Konfliktlösung. Bei PMI identifizieren die Teilnehmer (in der Regel alle beteiligten Stakeholder) zunächst alle positiven Aspekte (plus) der Alternativen, dann die negativen Aspekte (minus) und schließlich weitere interessante Foundation Level | Handbuch | © IREB 119 | 174 Punkte und Dinge, die weiter untersucht werden müssen. Die Alternative mit den meisten Pluspunkten und den wenigsten Minuspunkten ist die bevorzugte Alternative. Tatsächlich sind sowohl CAF als auch PMI Varianten der Entscheidungsmatrix, eines methodischen Ansatzes zur Konfliktlösung. Die widersprüchlichen Anforderungen werden anhand einer (größeren) Anzahl von Kriterien bewertet, woraufhin die Bewertungen der einzelnen Aspekte zur Berechnung einer (gewichteten) Bewertung der Alternativen herangezogen werden. Die höchste Bewertung gewinnt, wie die Alternative 1 im Beispiel von Tabelle 4.1 unten. Tatsächlich wird die Priorisierung (siehe Kapitel 6.8) dann als Lösungstechnik eingesetzt. Wie bereits erwähnt, werden diese Techniken in der Regel als unterstützende Techniken angesehen: Sie schaffen mehr Einblick in die Alternativen und helfen so bei der gewählten Lösungstechnik. Sie können sogar als einzige Technik eingesetzt werden, wenn alle beteiligten Stakeholder einverstanden sind, das Ergebnis zu akzeptieren. Tabelle 4.1: Beispiel für eine Entscheidungsmatrix Alternative 1: nur iOS Kriterium Alternative 2: Android & iOS Gewichtung Bewertung Gewichtet Bewertung Gewichtet Kundenbesta nd 2 3 6 4 8 Entwicklungs kosten 1 3 3 2 2 Time-toMarket 3 4 12 2 6 Ansehen 2 2 4 4 8 Benutzererle bnis 1 5 5 3 3 Summe 30 27 4.4 Validieren von Anforderungen In Kapitel 2, Prinzip 6, betonten wir die Bedeutung der Validierung der Anforderungen, um unzufriedene Stakeholder zu vermeiden. Da die Anforderungen den Ausgangspunkt für die nachfolgende Systementwicklung bilden, müssen wir ihre Qualität bereits vorab sicherstellen, um unnötigen nachgelagerten Aufwand zu vermeiden, sowohl auf der Ebene der einzelnen Anforderungen als auch der Arbeitsprodukte, die diese Anforderungen enthalten (Abbildung 4.14). Wir sollten überprüfen, inwieweit die Bedürfnisse der Stakeholder durch unsere Dokumentation abgedeckt sind, inwieweit alle Stakeholder übereinstimmen und wie Foundation Level | Handbuch | © IREB 120 | 174 wahrscheinlich unsere Annahmen über den Systemkontext sind, bevor wir Anforderungen an die Entwickler oder Lieferanten übergeben. Obwohl der Detaillierungsgrad variieren kann, gilt dies sowohl für iterative als, auch für sequenzielle Entwicklungsansätze. Abbildung 4.14 Vorgeschaltete Qualität reduziert nachgelagerten Ausschuss Die Validierung fügt dem Projekt Zeit und Kosten hinzu, sodass ihre Effizienz und Effektivität ein Anliegen des Requirements Engineers sein sollte. Deshalb ist es wichtig, Fehler, die während der Entwicklung und im Betrieb auftreten, kontinuierlich zu überwachen und zu analysieren. Wenn die Ursache für solche Mängel in den Anforderungen liegt, ist die Validierung der Anforderungen irgendwie fehlgeschlagen. Daher sollten Sie als Requirements Engineer kontinuierlich und aktiv nach Möglichkeiten zur Verbesserung suchen. 4.4.1 Wichtige Aspekte für die Validierung Was das Konzept der Validierung anbelangt, so sind bestimmte Aspekte wichtig, um den größtmöglichen Nutzen daraus zu ziehen (siehe auch [PoRu2015]): ▪ Die richtigen Stakeholder einbeziehen Als Requirements Engineer müssen Sie entscheiden, wen Sie zur Teilnahme an der Validierung einladen möchten. Ein wichtiger Aspekt, den Sie in dieser Hinsicht berücksichtigen müssen, ist der Grad der Unabhängigkeit zwischen den Personen, die an der Ermittlung der Anforderungen beteiligt sind und denjenigen, die sie validieren. Ein geringes Maß an Unabhängigkeit (Einladen von Stakeholdern, die bereits an der Ermittlung teilgenommen haben) ist kostengünstig und leicht zu organisieren, kann aber aufgrund des eigenen Fokus, blinder Flecken, widersprüchlicher Interessen oder fehlerhafter Annahmen dieser Personen bestimmte Mängel übersehen. Ein höheres Maß an Unabhängigkeit (z.B. durch die Einladung externer Prüfer oder Auditoren) erfordert mehr Zeit und Mühe bei der Organisation und Durchführung und bringt höhere (anfängliche) Kosten mit sich, kann aber auf lange Sicht effektiver sein, wenn es darum geht, mehr und schwerwiegendere Mängel zu finden. Folglich erfordert ein Foundation Level | Handbuch | © IREB 121 | 174 höheres Risiko im Projektumfang und/oder im Systemkontext ein höheres Maß an Unabhängigkeit. ▪ Trennung von Fehlererkennung und Fehlerkorrektur Es mag verlockend sein, jeden Fehler zu beheben, sobald er entdeckt worden ist. Dies erweist sich jedoch in der Regel weder als effiziente noch als effektive Arbeitsweise, da sich Mängel gegenseitig beeinflussen können. Ein später bei der Validierung festgestellter Fehler könnte die Korrektur eines früheren Fehlers ungültig machen. Eine ursprünglich als fehlerhaft markierte Anforderung könnte sich als richtig erweisen, wenn alle Anforderungen untersucht worden sind. Sie könnten sich angesichts des Aufwands, der mit der Gesamtheit der gefundenen Mängel verbunden ist, dazu entscheiden, einige (kleinere) Mängel nicht zu beheben. Und schließlich sollten sich die an der Validierung von Anforderungen beteiligten Personen darauf konzentrieren, Mängel zu finden und nicht darauf, Ideen zu entwickeln, wie diese behoben werden können. Daher lautet die Empfehlung, zunächst (einen kohärenten Satz von) Anforderungen für die Validierung auszuwählen und erst nach Prüfung des gesamten Satzes zu entscheiden, ob bestimmte festgestellte Mängel behoben werden sollen oder nicht. ▪ Validierung aus unterschiedlichen Sichten Eine ordnungsgemäße Validierung ist immer eine Gruppenleistung und keine Aktivität, die von den Requirements Engineers allein durchgeführt wird. Die besten Ergebnisse werden erzielt, wenn die Validierung von einem interdisziplinären Team durchgeführt wird, in das ausgewählte Teilnehmer ihre eigene Expertise einbringen. Im Allgemeinen können wir sagen, dass die Input-gebenden Stakeholder, die Stakeholder, die den Output erhalten und die Fachkollegen (Peers) vertreten sein sollten. Bei iterativen Projekten ist das derzeitige agile Team eine angemessene Wahl, wobei jedoch der Grad der Unabhängigkeit gering sein kann und zusätzliche Gutachter eingeladen werden sollten. Bei sequenziellen Projekten kann für jeden einzelnen Validierungsvorgang ein spezielles Team zusammengestellt werden. Je nach Projektphase ist der Input von Unternehmen, Anwendern, Entwicklern, Testern, Betreibern und Anwendungsmanagern nützlich. Manchmal können Fachexperten oder Spezialisten zu Themen wie Performanz, Sicherheit und Benutzerfreundlichkeit hinzugefügt werden. ▪ Wiederholte Validierung Bei der Durchführung sequenzieller Projekte werden die meisten Anforderungen in der Anfangsphase ermittelt und dokumentiert und am Ende dieser Phase gründlich validiert. Dies sollte jedoch nicht der einzige Zeitpunkt für eine Validierung sein. Im weiteren Verlauf des Projekts können neue Erkenntnisse dazu führen, dass die ursprünglichen Anforderungen aktualisiert, detailliert und erweitert werden. Dies könnte die Qualität, Kohärenz und Konsistenz der Anforderungen gefährden, sodass Foundation Level | Handbuch | © IREB 122 | 174 zusätzliche Validierungen erforderlich werden könnten. Diese werden oft zu Projektmeilensteinen geplant. In iterativen Projekten beinhalten viele der agilen Rituale Validierungsmaßnahmen. Sprint-Planung, Backlog-Refinement, Sprint-Reviews und sogar tägliche Stand-Ups bieten Möglichkeiten, Anforderungen zu validieren und zu verbessern. Allerdings konzentrieren sich diese Bemühungen oft auf einzelne, detaillierte Anforderungen, und das Gesamtbild kann vernachlässigt werden. Eine erste Validierung des gesamten Produkt-Backlogs zu Beginn eines Projekts oder eines Inkrements ist ein guter Anfang. Weitere nützliche Initiativen sind wiederholte Aktivitäten, um einzelne Aspekte zu vertiefen / zu härten (Hardening-Sprints) und eine zusätzliche Gesamtvalidierung zu den Releases. 4.4.2 Validierungstechniken Wie bei anderen Techniken kann der Requirements Engineer aus einem großen Werkzeugkasten von Validierungstechniken wählen, die sich in Formalität und Aufwand unterscheiden. Viele Faktoren beeinflussen die Auswahl dieser Techniken, z.B. das Softwareentwicklungs-Lebenszyklusmodell, die Reife des Entwicklungsprozesses, die Komplexität und das Risikoniveau des Systems, gesetzliche oder regulatorische Anforderungen und die Notwendigkeit eines Prüf-Protokolls. Häufig nimmt im Laufe eines Projekts der Aufwand und die Formalität gegen Ende zu, da endgültige Entscheidungen über das System und seine Umsetzung getroffen werden müssen. Sie werden auch feststellen, dass Umfang, Wert und Detaillierungsgrad des Feedbacks der Stakeholder zunehmen, je konkreter und detaillierter die zu validierenden Arbeitsprodukte werden. Dies bedingt die Anwendung verschiedener Validierungstechniken in verschiedenen Phasen des Projekts. Zu Beginn eines Projekts werden häufig kurze, leichte Validierungs- und Feedback-Zyklen bevorzugt, wie es bei agilen Ansätzen üblich ist. Das sichert die Qualität von Anfang an. Im weiteren Verlauf des Projekts werden formellere und zeitaufwändigere einmalige Techniken dominieren. Darüber hinaus ist auch eine Veränderung des Schwerpunkts der Validierungsaktivitäten zu beobachten. In frühen Phasen eines Projekts werden die Techniken meist zur Validierung der Anforderungsspezifikation eingesetzt. In späteren Phasen kann sich der Schwerpunkt der gleichen Techniken auf die Validierung ihrer Umsetzung verlagern. Im Allgemeinen unterscheiden wir drei Kategorien von Validierungstechniken (siehe Abbildung 4.15): ▪ Review-Techniken ▪ Explorationstechniken ▪ Probe-Entwicklung Review-Techniken und Probe-Entwicklung werden als statisch bezeichnet, da sie sich darauf konzentrieren, die Spezifikationen eines Systems zu analysieren, ohne es auszuführen. Bei Explorationstechniken konzentriert sich die Validierung auf das tatsächliche Foundation Level | Handbuch | © IREB 123 | 174 (oder simulierte) Verhalten des Systems im Betrieb, diese Techniken werden als dynamisch bezeichnet. Abbildung 4.15 Kategorien von Validierungstechniken Die Gemeinsamkeit der Review-Techniken besteht darin, dass si