6 Praktiken für das Requirements Management PDF

6 Praktiken für das Requirements Management Anforderungen sind nicht in Stein gemeißelt, ewig gegenwärtig von der Vergangenheit bis in die Zukunft; sie sind lebendig! Sie werden im Rahmen der Anforderungsermittlung geboren, wachsen durch Dokumentation auf und werden durch Validierung geformt. Als Er...

6 Praktiken für das Requirements Management Anforderungen sind nicht in Stein gemeißelt, ewig gegenwärtig von der Vergangenheit bis in die Zukunft; sie sind lebendig! Sie werden im Rahmen der Anforderungsermittlung geboren, wachsen durch Dokumentation auf und werden durch Validierung geformt. Als Erwachsene gehen sie durch die Umsetzung zur Arbeit, und nach einem hoffentlich langen und erfolgreichen Leben im Betrieb ziehen sie sich in den Ruhestand zurück und geraten in Vergessenheit. Während ihres gesamten Lebenszyklus kümmern sich ihre Eltern, die Requirements Engineers, um sie. Wir pflegen sie in ihrer Kindheit, unterrichten sie in ihrer Jugend, begleiten sie in ihren Beziehungen und helfen ihnen, eine gute Arbeit in einem gesunden System zu finden. Das ist, was wir Requirements Management nennen. Natürlich gibt es bessere, formellere Definitionen des Requirements Management. Die Norm ISO/IEC/IEEE 29148:2018 [ISO29148] definiert Requirements Management als: „Aktivitäten, die Anforderungen während des gesamten Lebenszyklus eines Systems, Produkts oder einer Dienstleistung identifizieren, dokumentieren, aufrechterhalten, kommunizieren, nachverfolgen und verfolgen.”. Im CPRE Glossar [Glin2020], wird Requirements Management definiert als „Der Prozess der Verwaltung bestehender Anforderungen und anforderungsbezogener Arbeitsprodukte, einschließlich der Speicherung, Änderung und Verfolgung von Anforderungen.”. Das CPRE Glossar sagt uns auch, dass Requirements Management ein integraler Bestandteil des RE ist „Requirements Engineering: Das systematische und disziplinierte Vorgehen bei der Spezifikation und Verwaltung von Anforderungen mit dem Ziel,...”. Requirements Management kann auf verschiedenen Ebenen erfolgen: ▪ Den einzelnen Anforderungen ▪ Den Arbeitsprodukten, die diese Anforderungen enthalten ▪ Dem System hinsichtlich seiner Arbeitsprodukte und der darin enthaltenen Anforderungen In der Praxis wird Requirements Management in erster Linie auf der Ebene der Arbeitsprodukte durchgeführt. Gewöhnlich enthält ein Arbeitsprodukt mehrere einzelne Anforderungen (z.B. eine externe Schnittstellenbeschreibung), wohingegen andere Arbeitsprodukte nur eine einzige Anforderung enthalten (z.B. im Falle einer einzelnen User Story in einem agilen Projekt) oder sie sogar die gesamten Anforderungen für ein System darstellen (z.B. Software-Anforderungsspezifikation). Seien Sie sich bewusst, dass alle Arbeitsprodukte aller drei Ebenen verwaltet werden müssen, und stellen Sie sicher, dass Sie die Beziehungen zwischen ihnen kennen. Der obige Text umreißt das Was des Requirements Management. Der Rest dieses Kapitels ist dem Wie gewidmet: Alle Arten von Praktiken, die anwendbar sind, damit das Requirements Management funktioniert. Bevor wir in die Einzelheiten des Requirements Management eintauchen, wollen wir einige Leitprinzipien für dessen Funktionieren betrachten. Wenn man etwas verwalten will, muss man in der Lage sein, es zu erkennen, zu speichern und wiederzufinden. Daher sind eine eindeutige Identifizierung, ein angemessener Grad an Foundation Level | Handbuch | © IREB 142 | 174 Standardisierung, die Vermeidung von Redundanz, ein zentraler Speicher und ein verwalteter Zugang ein Muss. Im Kapitel 6.1 werfen wir einen kurzen Blick auf Situationen, die den Wert, die Bedeutung und den Aufwand des Requirements Management beeinflussen. Kapitel 6.2 betrachtet die Anforderungen in ihrem Lebenszyklus als Teil der Arbeitsprodukte, die Requirements Engineers und andere IT-Mitarbeiter während der Entwicklung, Implementierung und des Betriebs eines IT-Systems erstellen und verwenden. Während des Lebenszyklus einer Anforderung werden mehrere Versionen von Arbeitsprodukten (und der darin enthaltenen Anforderungen) erstellt, beginnend mit einem frühen 0.1-Entwurf der sich nach einer Reihe größerer und kleinerer Änderungen zu einer, sagen wir, 3.2-Endversion entwickelt. Die Versionskontrolle wird in Kapitel 6.3 erörtert. Bei der Entwicklung und dem Einsatz von IT-Systemen ist es nicht praktikabel auf alle Anforderungen individuell einzugehen. Daher werden kohärente Anforderungssätze als Konfigurationen und Baselines betrachtet, wie in Kapitel 6.4 erläutert. Um mit Arbeitsprodukten und Anforderungen effizient umgehen zu können, müssen wir in der Lage sein, sie zu identifizieren und Daten über sie zu sammeln. Das ist das Thema des Kapitels 6.5. Kapitel 6.6 befasst sich mit der Verfolgbarkeit von Anforderungen. Die Verfolgbarkeit ist ein besonders wichtiges Qualitätsmerkmal von Anforderungen, wie Sie vielleicht schon beim Lesen der obigen Definitionen des Requirements Management verstanden haben. Ohne Verfolgbarkeit ist es unmöglich, das tatsächliche Verhalten eines Systems mit den ursprünglichen Forderungen der Stakeholder in Beziehung zu setzen. Kapitel 6.7 befasst sich mit den Änderungen von Anforderungen, die während ihrer Lebensdauer auftreten. In den ersten Stadien ihres Bestehens können Änderungen häufig vorkommen, aber nach der Validierung sollten die Anforderungen stabil sein. Dennoch werden sich auch weiterhin Änderungen ergeben. Um diese in einer geordneten Art und Weise durchzuführen, sollte ein definierter Prozess für den Umgang mit Änderungen vorhanden sein. Von Natur aus unterscheiden sich die Anforderungen in ihrer Bedeutung und ihrem Wert. Gewöhnlich sind die Ressourcen für ihre Ausarbeitung begrenzt, sodass nicht jede Anforderung zur Umsetzung gelangt. Das bedeutet, dass die Stakeholder entscheiden müssen, wann eine bestimmte Anforderung umgesetzt wird oder ob sie überhaupt umgesetzt wird. Die in Kapitel 6.8 beschriebene Priorisierung kann diese Entscheidung untermauern. 6.1 Was ist Requirements Management? In der Einleitung haben wir bereits gesehen, dass Requirements Management die Verwaltung bestehender Anforderungen und anforderungsbezogener Arbeitsprodukte bedeutet, einschließlich der Speicherung, Änderung und Verfolgung der Anforderungen. Aber warum sollte man sie überhaupt verwalten? Foundation Level | Handbuch | © IREB 143 | 174 Wir verwalten Anforderungen, weil sie lebendige Dinge sind. Sie werden erstellt, verwendet, aktualisiert und wieder gelöscht, sowohl im Laufe ihrer Ausarbeitung als auch während ihres Bestehens. Und während dieses gesamten Lebenszyklus müssen wir sicherstellen, dass alle beteiligten Parteien Zugang zu den korrekten Versionen aller Anforderungen haben, die für sie relevant sind. Wenn wir Anforderungen nicht richtig verwalten, laufen wir Gefahr, dass einige Parteien Anforderungen übersehen, an veralteten Anforderungen festhalten, mit falschen Versionen arbeiten, Beziehungen übersehen und so weiter. Dies kann die Effizienz und Effektivität der Systementwicklung und -nutzung ernsthaft beeinträchtigen. Mit anderen Worten: Der Wert eines ordnungsgemäßen Requirements Management liegt in der verbesserten Effizienz und Effektivität eines Systems. Dies bedeutet, dass der Wert des Requirements Management nicht vom Wert des betreffenden Systems und seines Kontexts getrennt werden kann. In der Praxis können wir große Unterschiede in der Bedeutung und dem Niveau des Requirements Management und des damit verbundenen Aufwands feststellen [Rupp2014], die von einer informellen Nebentätigkeit eines Requirements Engineers mit einer Tabellenkalkulation bis hin zu einer Vollzeittätigkeit eines engagierten Requirements Engineers mit einer werkzeuggestützten Anforderungsdatenbank reichen. Ein gründlicheres Requirements Management wird benötigt bei einer größeren Anzahl von Anforderungen, Stakeholdern und Entwicklern, mit einer längeren erwarteten Lebensdauer, mehr Änderungen oder höheren Qualitätsanforderungen an das System und mit einem komplexeren Entwicklungsprozess, strengeren Standards, Normen und Vorschriften, einschließlich der Notwendigkeit eines detaillierten Prüfpfades. Oft sehen wir, dass das Requirements Management zu Beginn eines Projekts etwas vernachlässigt wird, wenn ein kleines Team an einer überschaubaren Menge von Anforderungen auf hoher Abstraktionsebene arbeitet. Später nimmt die Komplexität zu und das Team verliert den Überblick, was zu Qualitätsproblemen und verminderter Effizienz führt. Dann muss viel Mühe aufgewendet werden, um das erforderliche Maß an Kontrolle zu erreichen. Es ist effizienter, bereits zu Beginn eines Projekts einige Anstrengungen zu unternehmen, um die Ressourcen und Prozesse für das Requirements Management mit Blick auf die am Ende zu erwartenden Anforderungen einzurichten. 6.2 Verwaltung des Lebenszyklus Wie in der Einleitung erwähnt, haben Anforderungen und Arbeitsprodukte, die Anforderungen enthalten, ein Leben. Wir sehen, wie sie erstellt, ausgearbeitet, validiert, konsolidiert, implementiert, verwendet, geändert, gepflegt, überarbeitet, umgestaltet, zurückgezogen, archiviert und/oder gelöscht werden. Das ist es, was wir unter ihrem Lebenszyklus verstehen: Während ihrer Lebensdauer kann eine Anforderung in einer begrenzten Anzahl von Zuständen vorliegen und eine begrenzte Anzahl von Zustandsübergängen aufweisen, die auf expliziten Ereignissen im Kontext beruhen. Abbildung 6.1 zeigt ein vereinfachtes Zustandsdiagramm als Modell für den Lebenszyklus einer einzelnen Anforderung (nur als Überblick, Zustandsübergänge werden nicht dargestellt. Foundation Level | Handbuch | © IREB 144 | 174 So kann z.B. der Übergang vom zusammengesetzten Zustand In Entwicklung zu In Produktion durch eine Go-Live-Entscheidung des Produkteigentümers ausgelöst werden). Abbildung 6.1 Vereinfachtes Zustandsdiagramm eines Anforderungslebenszyklus Erschwerend kommt hinzu, dass Arbeitsprodukte und individuelle Anforderungen ihre eigenen unterschiedlichen Lebenszyklen haben, die sich nur teilweise überlappen. Denken Sie zum Beispiel an eine Definitionsstudie für ein Arbeitsprodukt im Zustand Zu Ändern; dies bedeutet nicht notwendigerweise, dass alle im Arbeitsprodukt enthaltenen Anforderungen geändert werden müssen. Und für dieselbe Definitionsstudie ist der Zustand Implementiert unsinnig. Nur einige Anforderungen darin werden implementiert - oder besser: ein bestimmter Code, der auf diesen Anforderungen basiert. Ein weiterer erschwerender Faktor kann darin bestehen, dass in der Praxis die Sicht auf den Lebenszyklus von Anforderungen für verschiedene Rollen unterschiedlich ist. Um Ihre Arbeit als Requirements Engineer zu verfolgen, interessieren Sie sich für andere Zustände im Vergleich zum Projektmanager und um wiederum andere Zustände im Vergleich zum Produktmanager oder einem Änderungsmanager. Im obigen Diagramm könnte Ihr Interesse bei der Validierung enden, während es für den Projektmanager erst bei der Dokumentation beginnt. Requirements Engineers managen aktiv den Lebenszyklus ihrer Arbeitsprodukte. Lebenszyklus-Management impliziert: ▪ Definieren von Lebenszyklusmodellen für Ihre Arbeitsprodukte und die darin enthaltenen Anforderungen mit Foundation Level | Handbuch | © IREB 145 | 174 ▪ Den Zuständen, die ein Arbeitsprodukt oder eine Anforderung annehmen kann ▪ Den erlaubten Übergängen zwischen diesen Zuständen ▪ Den Ereignissen, die den Übergang von einem Zustand in einen anderen auslösen ▪ Sicherstellen, dass nur explizit erlaubte Übergänge stattfinden ▪ Aufzeichnen der tatsächlichen Zustände, die die Arbeitsprodukte und Anforderungen einnehmen ▪ Aufzeichnen der tatsächlich auftretenden Übergänge ▪ Berichterstatten über diese Zustände und Übergänge In einfachen Worten: Stellen Sie sicher, dass Sie wissen, in welchem Zustand Ihre Anforderungen waren, sind und sein werden, wie sie sich ändern können und warum dies alles geschieht. Zum Beispiel könnten Sie als Requirements Engineer gebeten werden, zu berichten, wer welche Version einer Anforderung genehmigt hat, die als Input für die Entwicklungsphase freigegeben werden soll. Die Verfolgung von Anforderungszuständen in ihrem Lebenszyklus kann auch für die Erstellung von Dashboards und die Berichterstattung über den Fortschritt eines Projekts nützlich sein. Es kann ein guter Weg sein, die Arbeit zu organisieren und festzustellen, an welchen Anforderungen zuerst gearbeitet werden muss. Der Zustand eines Arbeitsprodukts unter Lebenszyklusmanagement wird oft in einem Attribut erfasst (siehe Kapitel 6.5). Es kann auch nützlich sein, das Anfangs- und Enddatum dieses Zustands in Attributen zu dokumentieren. In agilen Projekten kann der Zustand eines Arbeitsprodukts (Items) aus seiner Position im Produkt-Backlog, im Task-Backlog und/oder im Task Board abgeleitet werden. Auch die Erfüllung der Kriterien der Definition of Ready und der Definition of Done kann relevante Informationen liefern, da die Erfüllung dieser Kriterien tatsächlich bedeutet, einen nächsten Zustand zu erreichen. Die Gründlichkeit und der Detaillierungsgrad des Lebenszyklusmanagements sollten auf die Bedürfnisse des Kunden, des Projekts und des Systems zugeschnitten sein. Zum Beispiel könnten die Zustände, In Entwicklung, In Produktion und Archiviert, ausreichend sein. Bei komplexen oder kritischen Projekten benötigen Sie möglicherweise ein viel detaillierteres Modell der Zustände, strenge Verfahren für Zustandsübergänge und einen Prüfpfad, der zeigt, was während des Projekts geschah. 6.3 Versionskontrolle Sowohl bei Arbeitsprodukten als auch bei individuellen Anforderungen als Teil eines Arbeitsprodukts ist es üblich, dass sie während ihres Lebenszyklus bestimmten Veränderungen unterliegen (siehe Kapitel 6.7 für weitere Informationen über den Umgang mit diesen Änderungen). Nach jeder Änderung ist das Arbeitsprodukt anders als vorher, es ist zu einer neuen Version geworden. Wir wollen die Versionen von Arbeitsprodukten aus zwei Gründen kontrollieren: Foundation Level | Handbuch | © IREB 146 | 174 ▪ Manchmal gehen Änderungen schief. Nach einer Weile werden Fehler festgestellt, oder der beabsichtigte Nutzen wird nicht erreicht. In einem solchen Fall können wir neue Änderungen in einer nächsten Version einführen, aber wir können auch beschließen, zu einer früheren Version zurückzugehen und von dort aus fortzufahren. Oder möglicherweise bevorzugen wir bei näherer Betrachtung doch einfach die frühere Version. ▪ Wir wollen die Historie des Arbeitsprodukts kennen, seine Entwicklung von seinem Ursprung bis zu seiner heutigen Situation verstehen. Dies kann uns helfen, wenn wir über zukünftige Änderungen entscheiden müssen, oder einfach nur Fragen beantworten, warum das aktuelle Arbeitsprodukt so ist, wie es ist. Für eine Versionskontrolle sind drei Maßnahmen erforderlich: ▪ Eine Identifizierung jeder Version, um zwischen den verschiedenen Versionen eines Arbeitsprodukts zu unterscheiden. Dies ist die Versionsnummer, oft ergänzt durch ein Versionsdatum. ▪ Eine klare Beschreibung jeder Änderung. Sie müssen in der Lage sein, den Unterschied zwischen einer bestimmten Version und ihrer Vorgängerversion zu erkennen und zu verstehen. Diese Änderungsbeschreibung muss eindeutig mit der Versionsnummer verknüpft sein. ▪ Eine strikte Regelung für die Speicherung von Versionen, die es Ihnen ermöglicht, alte Versionen zu finden und abzurufen. Sofern die Speicherbeschränkungen nichts anderes vorschreiben, sollten Sie alle früheren Versionen aller Ihrer Arbeitsprodukte aufbewahren, da Sie sonst möglicherweise eine Version nicht wiederherstellen können, wenn Sie sie benötigen. Andererseits wird unbegrenzter Speicherplatz selten der Fall sein, sodass es ratsam ist auch eine Regelung für die Archivierung und Entsorgung nicht mehr verwendeter Arbeitsprodukte zu haben. In der Regel enthält ein Arbeitsprodukt mehrere Anforderungen. Wenn sich eine einzelne Anforderung in diesem Arbeitsprodukt ändert, sollten sowohl diese Anforderung als auch das Arbeitsprodukt eine neue Versionsnummer erhalten, während die unveränderten Anforderungen in diesem Arbeitsprodukt ihre alte Versionsnummer behalten. Dies kann aber bald sehr verwirrend werden. Eine praktische Lösung könnte deshalb darin bestehen, die Versionsnummerierung nur auf der Ebene des Arbeitsprodukts vorzunehmen und alle darin enthaltenen Anforderungen erben die Versionsnummer und die Änderungshistorie des Arbeitsprodukts. Versionsnummern bestehen in der Regel aus (mindestens) zwei Teilen: ▪ Version. Im Prinzip beginnt die Version bei Null, solange sich das Arbeitsprodukt in der Entstehung befindet. Wenn es formell genehmigt, freigegeben und/oder auf den Markt gebracht wird, weisen wir ihm die Version Eins zu. Danach wird die Version nur für größere, substantielle Aktualisierungen erhöht. ▪ Inkrement. Dieses beginnt meist bei eins und wird mit jeder (äußerlich sichtbaren) Änderung, sei es inhaltlich oder oft nur textuell oder redaktionell, erhöht. Ein zusätzliches Sub-Inkrement könnte nur zur Korrektur von Tippfehlern verwendet Foundation Level | Handbuch | © IREB 147 | 174 werden. Das Inkrement neun wird manchmal verwendet, um eine endgültige Version kurz vor der Genehmigung oder Freigabe zu kennzeichnen. Bei jeder formalen Änderung wird eine neue Versionsnummer vergeben. Häufig wird eine Änderung des Lebenszyklusstatus eines Arbeitsprodukts nicht als Grund für eine Erhöhung der Versionsnummer angesehen, es sei denn, sie geht mit einer inhaltlichen oder textuellen Änderung einher. Wenn z.B. eine Anforderung nach der Genehmigung den Status „validiert“ und die Versionsnummer 1.0 erhält, muss diese Versionsnummer nicht geändert werden, wenn sich der Status auf „in Umsetzung“ und anschließend auf „implementiert“ ändert. Der Status kann letztendlich in archiviert enden, aber immer noch die gleiche Versionsnummer 1.0 behalten. 6.4 Konfigurationen und Basislinien Angenommen, Sie bewahren, wie oben beschrieben, alle Versionen aller Anforderungen auf, die Sie während eines Projekts entwickeln. Sie haben dann eine sich ständig erweiternde Datenbank, die mit Anforderungen gefüllt ist, und Sie beginnen, den Überblick zu verlieren. Eines Tages kommt Ihr Kunde an Ihren Schreibtisch und fragt: „Wir haben Ihr System in allen unseren Filialen implementiert. Nun scheint es ein Problem mit den Berechnungen in unserem Büro in Barcelona zu geben. Können Sie mir sagen, auf welcher Version der Anforderungen die Berechnung dort erfolgen?” Wenn Sie diese Frage nicht beantworten können, werden Sie sich wünschen, dass Sie dem Konfigurationsmanagement mehr Aufmerksamkeit gewidmet hätten. Was ist also eine Konfiguration? Sie finden eine Definition im CPRE Glossar [Glin2020], aber kurz gesagt, für einen Requirements Engineer ist eine Konfiguration ein konsistenter Satz von logisch zusammenhängenden Arbeitsprodukten, die Anforderungen enthalten. Wir wählen diesen Satz mit einem bestimmten Zweck aus, in der Regel, um deutlich zu machen, welche Anforderungen in einer bestimmten Situation gültig sind oder waren. Dadurch werden die folgenden Eigenschaften für eine korrekte Konfiguration festgelegt: ▪ ▪ Logisch Verbunden. Das Set von Anforderungen in der Konfiguration gehört im Hinblick auf ein bestimmtes Ziel zusammen. Konsistent. Das Set von Anforderungen hat keine internen Konflikte und kann in ein System integriert werden. ▪ Eindeutig. Sowohl die Konfiguration selbst als auch ihre zugehörigen Anforderungen sind klar und eindeutig gekennzeichnet. ▪ Unveränderlich. Die Konfiguration setzt sich aus ausgewählten Anforderungen mit jeweils einer bestimmten Version zusammen, die in dieser Konfiguration nie geändert wird. ▪ Grundlage für das Zurücksetzen. Die Konfiguration ermöglicht ein Zurücksetzen auf eine frühere Konfiguration, wenn unerwünschte Änderungen aufgetreten sind. Eine Konfiguration wird wie jedes andere Arbeitsprodukt als Arbeitsprodukt mit einer eindeutigen Identifizierung, einem Status sowie einer Versionsnummer und einem Datum Foundation Level | Handbuch | © IREB 148 | 174 dokumentiert. Da eine Konfiguration jedoch per Definition unveränderlich ist, wird es immer nur eine gültige Version geben (z.B. 1.0). Eine Konfiguration hat immer zwei Dimensionen [CoWe1998]: ▪ Die Produktdimension. Diese gibt an, welche Anforderungen in dieser spezifischen Konfiguration enthalten sind. Manchmal enthält eine Konfiguration alle verfügbaren Anforderungen, aber in der Regel handelt es sich um eine bestimmte Auswahl, z.B. alle Anforderungen, die in der französischen Version eines Systems implementiert sind. Die britische Version desselben Systems könnte dann eine andere Konfiguration haben. ▪ Die Versions Dimension. In einer bestimmten Konfiguration ist jede ausgewählte Anforderung in genau einer und nur einer - Version vorhanden. Es kann die neueste Version oder eine frühere Version sein, je nach dem Zweck der Konfiguration selbst. Sobald auch nur eine einzige unterschiedliche Version einer einzigen Anforderung ausgewählt wird, handelt es sich um eine neue Konfiguration. Stellen Sie sich ein System vor, für das ein neues Release mit einigen Anforderungen in einer höheren Version implementiert wird. Dieses neue Release wird dann eine andere Konfiguration haben. Abbildung 6.2 gibt ein weiteres Beispiel für verschiedene Konfigurationen, die aus spezifischen Sätzen von Anforderungsversionen bestehen. Abbildung 6.2 Beispiel für Konfigurationen Foundation Level | Handbuch | © IREB 149 | 174 Die obige Abbildung zeigt ein Beispiel für verschiedene Konfigurationen eines bestimmten Systems. Es zeigt eine Auswahl von neun Anforderungen. Einige von ihnen befinden sich noch im Anfangsstadium der Entstehung - z.B. die Anforderung 6 mit der Version v0.1. Für andere Anforderungen gab es bereits weitere Versionen - z.B. Anforderung 1, die fertig gestellt ist und bereits ein größeres Update erfahren hat, ist nun Version v2.0. Das linke Bild zeigt die Konfiguration, die derzeit in Produktion ist. Sie besteht aus R1 v2.0, R2 v1.0, R3 v1.2 (diese Anforderung hatte nach der Implementierung zwei kleinere Aktualisierungen), R5 v2.0, R7 v1.0 und R9 v1.0. R4, R6 und R8, die sich in der Entstehung befinden, sind in dieser Konfiguration nicht vorhanden, ebenso wenig wie die neuen Versionen von R7 und R9. Das rechte Bild zeigt die Konfiguration, die gleichzeitig in der Systemtestumgebung vorhanden ist. Einige Anforderungen (R1, R2) sind gleich, einige sind nicht mehr vorhanden (R3, R5), die in der Entstehung befindlichen Anforderungen (R4, R6 und R8) sind hier enthalten, und zwei Anforderungen (R7 und R9) sind in einer höheren Version vorhanden als in der Konfiguration der Produktionsumgebung. In vielen Projekten werden einige Konfigurationen auf eine besondere Art und Weise behandelt. Diese Konfigurationen werden als Basislinien (Baselines) bezeichnet. Eine Baseline ist eine stabile, validierte und gegen Änderungen abgesicherte Konfiguration, die einen Meilenstein oder eine andere Art Haltepunkt im Projekt markiert. Ein Beispiel hierfür kann die Konfiguration am Ende der Entwurfsphase, kurz vor Beginn der Implementierungsphase, oder die Konfiguration sein, die beim Go-Live eines bestimmten Releases gültig ist. Das Sprint-Backlog in einem agilen Projekt dient als Baseline zu Beginn der nächsten Iteration. Baselines sind für Planungszwecke nützlich, da sie einen stabilen Ausgangspunkt für eine nächste Phase darstellen. Oft werden sie eingefroren und als Anker im hektischen Leben eines Projekts beiseite gelegt. Wenn bei dem Projekt etwas furchtbar schief läuft, kann das Team einen Rollback auf die Situation der Ausgangssituation durchführen und von dort aus neu beginnen. Für den Requirements Engineer ist vor allem die Konfiguration von Arbeitsprodukten, die Anforderungen enthalten, von Bedeutung. In der Praxis hat die Konfiguration innerhalb eines Projekts jedoch einen viel größeren Umfang und enthält ausgewählte Versionen der Arbeitsprodukte aller Teammitglieder, wie Anforderungen, Entwürfe, Programmcode und Testfälle. In komplexen Projekten kann das Konfigurationsmanagement eine Vollzeitbeschäftigung sein, die mit speziellen Werkzeugen ausgeführt wird. 6.5 Attribute und Sichten Als Requirements Engineer besteht Ihr Output aus allen Arten von Arbeitsprodukten, die Anforderungen enthalten. Diese Anforderungen müssen verwaltet werden, sonst verlieren Sie und Ihr Team schnell den Überblick. Um die Anforderungen zu verwalten, müssen Sie Daten über sie sammeln und pflegen - Metadaten, Daten über Daten. Metadaten machen Arbeitsprodukte greifbar und handhabbar. Durch Metadaten können Sie Informationen über die Anforderungen bereitstellen und erhalten sowie Fragen beantworten, die während und nach dem Projekt- oder Produktlebenszyklus relevant sind. Denken Sie an Fragen wie „Welche Anforderungen sind für das nächste Release geplant?” oder „Wieviel Aufwand wird Foundation Level | Handbuch | © IREB 150 | 174 dieses Release voraussichtlich erfordern?” oder „Wie viele Anforderungen haben eine hohe Priorität?” Betrachtet man die Anforderungen als Entitäten, über die Informationen erforderlich sind, so werden die Merkmale dieser Anforderungen Attribute genannt. In diesem Kapitel haben wir bereits einige gemeinsame Attribute gesehen, wie z.B. die eindeutige Identifizierung, die Versionsnummer, den Zustand, mehrere Datumswerte. Die für die Anforderungen zu definierenden Attribute hängen von den Informationsbedürfnissen der Projekt- und Systembeteiligten ab. Zu Beginn eines Projekts sollte ein Schema für Attribute festgelegt werden, das es dem Requirements Engineer ermöglicht, diese Bedürfnisse zu erfüllen. Ein guter Ausgangspunkt ist in den einschlägigen Normen zu finden. Die ISO-Norm [ISO29148] erwähnt: ▪ Identifizierung. Jede Anforderung sollte einen eindeutigen, unveränderlichen Identifikator haben, wie z.B. eine Nummer, einen Namen, eine Gedächtnisstütze. Ohne eine ordnungsgemäße Identifizierung ist ein Requirements Management unmöglich. ▪ Priorität für den Stakeholder. Die (vereinbarte) Priorität der Anforderung aus der Sicht der Stakeholder. Siehe Kapitel 6.8 für Hinweise zur Bestimmung dieser Priorität. Abhängigkeit. Manchmal gibt es eine Abhängigkeit zwischen den Anforderungen. Dies kann bedeuten, dass eine Anforderung mit niedriger Priorität zuerst umgesetzt werden sollte, weil eine andere, hochprioritäre Anforderung davon abhängt. ▪ ▪ Risiko. Hier geht es um das Potential, dass die Umsetzung der Anforderung zu Problemen führt, wie z.B. Schäden, zusätzliche Kosten, Verzögerungen, Rechtsansprüche. Dabei handelt es sich naturgemäß um eine Schätzung, die auf einem Konsens zwischen den Stakeholdern beruhen muss. ▪ Quelle. Was ist der Ursprung der Anforderung, woher kam sie? Möglicherweise benötigen Sie diese Informationen zur Validierung, Konfliktlösung, Änderung oder Löschung. Begründung. Die Begründung gibt Ihnen den Grund für die Notwendigkeit der Anforderung und die Ziele der Stakeholder an, die damit erfüllt werden sollen. Schwierigkeit. Dies ist eine Schätzung des Aufwands, der zur Umsetzung der Anforderung erforderlich ist. Sie wird für die Projektplanung und -abschätzung benötigt. ▪ ▪ ▪ Art. Dieses Attribut gibt an, ob es sich bei der Anforderung um eine funktionale Anforderung, eine Qualitätsanforderung oder um eine Randbedingung handelt. Es gibt viele Möglichkeiten, diese Informationen zu speichern. Sie kann in Dokumenten enthalten sein oder in einer Tabellenkalkulation oder Datenbank gespeichert sein, wobei die Anforderungen als Zeilen und ihre Attribute als Spalten dargestellt werden. In agilen Umgebungen können die Anforderungen auf Story-Cards festgehalten werden, wobei die Rubriken auf der Karte die Attribute sind. Wie in Kapitel 7 besprochen, sollten Requirements Management-Tools Funktionen zur Speicherung von Daten über Anforderungen und auch zur Berichterstattung bieten. Foundation Level | Handbuch | © IREB 151 | 174 Mit Hilfe von Attributen können Sie Informationen über Ihre Arbeitsprodukte und die darin enthaltenen Anforderungen bereitstellen. Der einfachste Weg, dies zu tun, ist die Erstellung eines Berichts mit allen Daten zu allen Versionen aller Anforderungen. Für alles andere als das einfachste System, wird ein solcher Bericht nutzlos sein, da niemand in der Lage sein wird, alle Informationen zu überblicken, weil sie überwältigend komplex sind. Daher sollten Sie Ihre Berichte auf der Grundlage des Informationsbedarfs Ihrer Zielgruppen anpassen. Dies geschieht unter Verwendung von Sichten [Glin2020]. Eine Sicht ist eine (oft vordefinierte) Form, die Daten Ihrer Arbeitsprodukte zu filtern und zu sortieren, resultierend in einem Bericht, der genau das zeigt, was die Zielgruppe benötigt nicht mehr und nicht weniger. Eine Sicht wird mit dem expliziten Zweck definiert, relevante Informationen für eine bestimmte Zielgruppe zu liefern. Wir unterscheiden drei Arten von Sichten: ▪ Selektive Sichten. Diese Sichten geben Auskunft über eine gezielte Auswahl von Anforderungen anstatt aller Anforderungen. Zum Beispiel eine Sicht nur auf die neuesten Versionen der Anforderungen, oder auf alle Anforderungen im Zustand validiert, oder auf die Anforderungen mit hoher Priorität für die Stakeholder. Der Schwerpunkt könnte auf einem Teilsystem liegen, oder im Gegensatz dazu, einen abstrakten Überblick über das gesamte System mit seinen High-Level Anforderungen geben. ▪ Projektive Sichten. Eine projektive Sicht zeigt eine Auswahl der verfügbaren Daten (Attribute) der Anforderungen, z.B. nur die Identifikation, die Versionsnummer und den Namen. ▪ Verdichtende Sichten. In einer verdichtenden (aggregierenden) Sicht finden Sie Zusammenfassungen, Summen oder Durchschnittswerte, die aus einer Reihe von Anforderungen berechnet werden. Ein Beispiel wäre die Gesamtzahl der Anforderungen pro Abteilung: Z.B. 4 aus dem Vertrieb, 5 aus der Logistik. Abbildung 6.3 gibt ein Beispiel für diese Art von Sichten. Foundation Level | Handbuch | © IREB 152 | 174 Abbildung 6.3 Verschiedene Arten von Sichten In den meisten Fällen wird eine Kombination von Sichten verwendet, z.B. wenn Sie eine Liste mit den IDs, Versionsnummern, Namen und Typen (= projektiv) aller Anforderungen für die Verkaufsabteilung (= selektiv) bereitstellen möchten. 6.6 Verfolgbarkeit Im Verlauf dieses Handbuchs haben wir das Thema Verfolgbarkeit (Traceability) bereits erwähnt [GoFi1994]. Ohne eine einwandfreie Verfolgbarkeit ist das Requirements Engineering kaum durchführbar, da Sie Folgendes nicht tun können: ▪ Den Nachweis erbringen, dass eine bestimmte Anforderung erfüllt ist ▪ Nachweisen, dass und mit welchen Mitteln eine Anforderung umgesetzt wurde ▪ Konformität der Produkte mit den geltenden Gesetzen und Normen zu zeigen ▪ Nach fehlenden Arbeitsprodukten suchen (z.B. herausfinden, ob Testfälle für alle Anforderungen existieren) Die Auswirkungen einer Änderung auf Anforderungen analysieren (siehe Kapitel 6.7) ▪ In vielen Fällen, insbesondere bei sicherheitskritischen Systemen, fordern Prozessstandards sogar explizit die Umsetzung der Verfolgbarkeit. Es gibt drei Arten von Fragen, die mit Hilfe der Verfolgbarkeit beantwortet werden können (siehe auch Abbildung 6.4): ▪ Rückwärtsverfolgbarkeit: Was war der Ursprung einer bestimmten Anforderung? Wo wurde sie ermittelt? Welche Quellen (Stakeholder, Dokumente, andere Systeme) wurden bei der Ermittlung analysiert? Foundation Level | Handbuch | © IREB 153 | 174 Die Rückwärtsverfolgbarkeit ist ebenso bekannt unter der Bezeichnung PreRequirements-Specification-Traceability. ▪ Vorwärtsverfolgbarkeit: Wo wird diese Anforderung verwendet? Welche Ergebnisse (programmierte Module, Testfälle, Prozeduren, Handbücher) basieren darauf? Die Vorwärtsverfolgbarkeit ist ebenso bekannt unter der Bezeichnung PostRequirements-Specification Traceability. ▪ Verfolgbarkeit zwischen Anforderungen: Hängen andere Anforderungen von dieser Anforderung ab oder umgekehrt (z.B. Qualitätsanforderungen im Zusammenhang mit einer funktionalen Anforderung)? Handelt es sich bei der Anforderung um eine Verfeinerung einer übergeordneten Anforderung (z.B. ein Epic, das in einer Reihe von User Storys verfeinert wurde, eine User Story, die mit einer Reihe von Akzeptanzkriterien versehen ist)? Wie hängen sie zusammen? Abbildung 6.4 Arten Verfolgbarkeit Es gibt mehrere Möglichkeiten, die Verfolgbarkeit zu dokumentieren. Häufig geschieht dies implizit, etwa durch die Anwendung von Dokumentstrukturen, Standardvorlagen oder Namenskonventionen. Wenn Sie alle Ihre Anforderungen mit einem Code Req-xxx-nnn identifizieren, wobei xxx für die Abteilung steht, die die Anforderung gefordert hat, wird jeder verstehen, dass Req-ver-012 eine Anforderung für die Vertriebsabteilung ist (für die Rückwärtsverfolgbarkeit). Wenn Sie ein Dokument veröffentlichen, das alle Anforderungen auflistet, die in der Version vom 1. Juli umgesetzt werden, liefern Sie implizit Informationen zur Vorwärtsverfolgbarkeit. Und wenn Sie ein Dokument mit einem speziellen Abschnitt z.B. über Preiskalkulationen schreiben, könnte das ein Beispiel für die Verfolgbarkeit zwischen Anforderungen sein. Ein Foundation Level | Handbuch | © IREB 154 | 174 weiteres Beispiel könnte ein High-Level-Modell und eine textuelle Beschreibung der damit verbundenen detaillierten Anforderungen sein. Bei komplexeren Projekten sollte die Verfolgbarkeit (auch) explizit dokumentiert werden. Zur expliziten Verfolgbarkeit dokumentieren Sie die Beziehung zwischen Arbeitsprodukten auf der Grundlage ihrer eindeutigen Identifizierung. Dies kann in verschiedenen Formen geschehen [HuJD2011]: ▪ Verwendung spezifischer Attribute wie z.B. Quelle, vorgeschlagen durch die ISONorm [ISO29148] ▪ In Dokumenten, durch Hinzufügen von Verweisen auf Vorgängerdokumente, andere Arbeitsprodukte oder individuelle Anforderungen ▪ Durch Entwicklung einer Verfolgbarkeitsmatrix in einer Tabellenkalkulation oder einer Datenbanktabelle (siehe Beispiel in Tabelle 6.1 unten) ▪ In textueller Dokumentation, unter Verwendung von Hyperlinks im Wiki-Stil ▪ Visualisierung von Verfolgbarkeitsbeziehungen in einem Verfolgbarkeitsdiagramm (Abbildung 6.4 ist eine vereinfachte Form eines solchen Diagramms) In vielen Fällen bietet ein Anforderungs- oder Konfigurationsmanagement-Tool (siehe Kapitel 7) Funktionen zur Unterstützung der Verfolgbarkeit. Die Verwaltung der Verfolgbarkeit in einem umfangreichen Projekt kann kompliziert sein, insbesondere wenn man auch Versionierung berücksichtigen muss. In einem solchen Fall ist eine gute Werkzeugunterstützung unerlässlich. Tabelle 6.1 Beispiel einer Verfolgbarkeitsmatrix Quelle A1 A2 Interview Frau Schmidt 8. Juni X X Zusammenfassender Fragebogen 12. Mai X A3 X X Betriebsvorschrift 17.a.02 X X A5 A6 A7 X X X X X Bericht der Feldbeobachtung 03. Juli API-Dokumentation HR-System v3.0.2.a A4 X X X X 6.7 Umgang mit Änderungen "Prinzip 7: Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. In agilen Prozessen werden Veränderungen zum Wettbewerbsvorteil des Kunden genutzt.“ [BeeA2001]. Die Gründungsväter der agilen Bewegung waren sich darüber im Klaren: Änderungen an Anforderungen wird es immer geben, ob man will oder nicht. Viele Menschen mögen Veränderungen überhaupt nicht, denn jede Veränderung ist ein Risiko, eine Bedrohung für die Stabilität des Projekts und des Systems. Foundation Level | Handbuch | © IREB 155 | 174 Die Änderung einer Anforderung ist jedoch kein eigenständiges Ereignis. Sie wird durch Änderungen im Systemkontext, durch neue Erkenntnisse der Stakeholder, durch das Verhalten von Konkurrenten usw. ausgelöst. Ein Gesetz tritt in Kraft und fügt dem System eine neue Randbedingung hinzu, aufgrund der wachsenden Marktnachfrage muss die Leistung des Systems verbessert werden oder ein Konkurrenzsystem wird mit einigen Begeisterungssfaktoren eingeführt, die auch Ihr Kunde wünscht. Eine Änderung sollte daher als Chance gesehen werden, ein besseres System zu erhalten, um den Nutzern mehr Wert zu bieten. Aber unabhängig von der Situation ist jede Veränderung auch ein Risiko. Sie kann Fehler einbringen, die zu Systemausfällen führen. Sie kann den Fortschritt des Projekts verzögern. Sie kann mehr Mühe und Geld erfordern als zuvor berechnet wurde. Die Benutzer mögen sie möglicherweise nicht und weigern sich mit ihr zu arbeiten. Kurz gesagt, es kann schief gehen und ein zuvor stabiles Projekt oder System beeinträchtigen. Das bedeutet jedoch nicht, dass Änderungen schlecht sind und vermieden werden sollten. Es bedeutet vielmehr, dass alle Änderungen sorgfältig gehandhabt werden müssen, um einen optimalen Wert zu akzeptablen Kosten bei minimalem Risiko zu erhalten. In der Literatur zum IT-Servicemanagement (siehe [Axelos2019]) wird Change Enablement (Förderung von Änderungen) als eine der Kernpraktiken beschrieben. Diese Praktik stellt sicher, dass Änderungen wirksam, sicher und rechtzeitig umgesetzt werden, um die Erwartungen der Stakeholder zu erfüllen. Die Praktik schafft ein Gleichgewicht zwischen Effektivität, Durchsatz, Compliance (Konformität mit Regelungen) und Risikokontrolle. Sie konzentriert sich auf drei Aspekte: ▪ Sicherstellen, dass alle Risiken richtig beurteilt worden sind ▪ Autorisierung von Änderungen um fortzufahren ▪ Steuerung der Implementierung der Änderung Change Enablement bedeutet, dass eine Organisation eine Änderungsautorität bestimmt, die über die Änderungen entscheidet und einen Prozess für den Umgang mit den Änderungen definiert. Siehe Abbildung 6.5 für einen Überblick über diesen Prozess. Diese Maßnahmen sind in der Regel abgestimmt auf den Entwicklungsansatz und den Zeitpunkt, zu dem eine Veränderung eintritt. Abbildung 6.5 Change Enablement Prozess Foundation Level | Handbuch | © IREB 156 | 174 Solange sich eine Anforderung in einem Entwurfszustand befindet, hat der Autor die Befugnis sie zu ändern und es wird kein strikter Prozess verfolgt. Sobald eine Anforderung zur weiteren Verwendung im Projekt freigegeben ist, kann der Autor nicht mehr frei entscheiden, da jede Änderung Auswirkungen auf andere Arbeitsprodukte hat, die auf dieser Anforderung basieren. Bevor entschieden wird, ob eine Änderung durchgeführt werden soll, sollte eine Folgenabschätzung durchgeführt werden, um die Aufwände und Risiken der Änderung abzuklären. Hier ist Verfolgbarkeit unabdingbar. Bei einem linearen Entwicklungsansatz wird die Änderungsautorität häufig dem Projektmanagement, einem Lenkungsausschuss oder einem Änderungsausschuss zugewiesen, und es wird ein Prozess mit einer formellen Entscheidung über die Änderung und die Planung ihrer Umsetzung verfolgt. Bei einem iterativen Entwicklungsansatz liegt die Änderungsautorität in der Regel beim Product Owner, der über die Änderung entscheidet und eine akzeptierte Änderung als neues Element (Arbeitsprodukt) in das Produkt-Backlog aufnimmt. Die weitere Implementierung wird dann wie jedes andere Element im ProduktBacklog behandelt. Sobald eine Anforderung in einem operatives System implementiert ist, sollte ein noch strengerer Prozess eingehalten werden, da jede Änderung nun Auswirkungen auf Benutzer und Geschäftsprozesse hat. Dabei wird oft zwischen Standard- (risikoarm, gut verstanden und vorautorisiert, z.B. eine Änderung des Mehrwertsteuersatzes), Normal- (basierend auf einer formalen Änderungsanfrage, geplant, bewertet und autorisiert, z.B. eine Änderung eines Algorithmus zur Preisberechnung) und Notfalländerungen (die so schnell wie möglich implementiert werden müssen, z.B. um einen Störfall zu lösen - was aber selten eine Änderung der Anforderungen beinhaltet) unterschieden. In der Regel liegt die Änderungsautorität bei einem Change Advisory Board [Math2019], in einem iterativen Ansatz wie z.B. DevOps kann eine Änderung von einem Release-Manager genehmigt werden. 6.8 Priorisierung Anforderungen selbst sind nur Konzepte in den Köpfen von Menschen. Sie erzeugen nur dann einen Wert, wenn sie in einem operativen System umgesetzt werden. Diese Umsetzung erfordert Aufwand, Zeit, Geld und Aufmerksamkeit. In den meisten Fällen sind diese Ressourcen begrenzt, was bedeutet, dass nicht alle Anforderungen umgesetzt werden können, zumindest nicht zur gleichen Zeit. Das wiederum bedeutet, dass die Stakeholder entscheiden müssen, welche Anforderungen zuerst kommen sollten und welche später (oder gar nicht) umgesetzt werden könnten. Mit anderen Worten: Priorisierung [Wieg1999]. Die Priorität einer Anforderung ist definiert als das Maß an Bedeutung, das ihr nach bestimmten Kriterien beigemessen wird [Glin2020]. Folglich müssen Sie zunächst festlegen, nach welchen Kriterien die Anforderungen bewertet werden sollen, bevor Sie eine Priorisierung vornehmen können. Bevor Sie jedoch die Kriterien zur Bewertung festlegen können, müssen Sie wissen, was das Ziel der Priorisierung ist. Dieses Ziel ist in der Regel nicht Ihr Ziel als Requirements Engineer, sondern das Ziel bestimmter Stakeholder, sodass Sie Foundation Level | Handbuch | © IREB 157 | 174 entscheiden müssen, wer die Stakeholder für diese Priorisierung sind. Und wenn Sie deren Ziel kennen, wird in der Regel klar sein, dass nicht alle Anforderungen priorisiert werden müssen, sondern nur eine bestimmte Teilmenge. Zusammenfassend können wir eine Abfolge von Schritten skizzieren, die zu befolgen sind, wenn wir Anforderungen priorisieren wollen: ▪ Festlegen der wichtigsten Ziele und Randbedingungen für die Priorisierung Der Projekt- und Systemkontext bestimmen weitgehend die Gründe für die Priorisierung. Wenn Sie beispielsweise Prioritäten setzen, um zu entscheiden, welche Funktionen im nächsten Release implementiert werden, könnten Sie sich auf den Geschäftswert konzentrieren. Wenn das Ziel darin besteht, User Storys für die nächste Iteration auszuwählen, würden Story Points und technische Abhängigkeiten stärker in den Vordergrund treten. Technische oder rechtliche Zwänge könnten die zu treffende Auswahl einschränken. ▪ Definieren der gewünschten Beurteilungskriterien Grundsätzlich bestimmen die Ziele und Randbedingungen die zu verwendenden Kriterien. Häufig verwendete Kriterien sind der Geschäftswert für die Stakeholder, die von den Nutzern wahrgenommene Dringlichkeit, der Aufwand für die Implementierung, die Risiken für die Nutzung, logische und technische Abhängigkeiten, die Rechtsverbindlichkeit einer Anforderung oder einfach die (inter)subjektive Präferenz der relevanten Stakeholder. Manchmal wird nur ein einziges Kriterium verwendet, aber eine ausgewogene Auswahl mehrerer relevanter Kriterien kann zu einem besseren Ergebnis führen. ▪ Festlegen, welche Stakeholder einbezogen werden müssen Ziele und Randbedingungen beeinflussen, welche Stakeholder Sie in die Priorisierung einbeziehen sollten, andererseits aber setzen bestimmte Stakeholder selbst diese Ziele, sodass Sie sich der wechselseitigen Abhängigkeit bewusst sein müssen. Wenn Sie zum Beispiel die Priorisierung für die Einführung eines neuen Systems vornehmen, würden Sie wahrscheinlich Vertreter des Fachbereichs und eine Gruppe zukünftiger Kunden einladen. Bei der Priorisierung des Product Backlog, um über die nächste Iteration zu entscheiden, würde hingegen das Scrum-Team einbezogen werden. ▪ Festlegen, welche Anforderungen priorisiert werden müssen Es ist eher unwahrscheinlich, dass das alle Anforderungen priorisiert werden müssen. Auch dies hängt in erster Linie von den Zielen und Randbedingungen für die Priorisierung ab. Zum Beispiel können Randbedingungen bestimmte Anforderungen als „must-haves” vorschreiben. Tatsächlich ist es nur sinnvoll Anforderungen zu priorisieren, bei denen Sie die Wahl haben, ob Sie sie in einem nächsten Schritt des Entwicklungsprozesses berücksichtigen wollen oder nicht. Das bedeutet, dass auch die Projektphase ein wichtiger Faktor ist. In einer frühen Phase könnten Sie Entwürfe in die Priorisierung einbeziehen, in einer späten Phase werden Sie die Priorisierung oft auf Anforderungen beschränken, die in einer stabilen Version vorliegen. Seien Sie sich Foundation Level | Handbuch | © IREB 158 | 174 bewusst, dass die zu priorisierenden Anforderungen je nach den Priorisierungszielen auf einem vergleichbaren Abstraktionslevel liegen sollten. In einer frühen Projektphase könnten Sie zum Beispiel Themes oder Features priorisieren, während Sie bei der Iterationsplanung User Storys priorisieren. ▪ Auswahl der Priorisierungstechnik Eine Priorisierungstechnik ist die Art und Weise, wie Ihre Stakeholder die Anforderungen priorisieren. Wie unten beschrieben wird, gibt es mehrere Techniken, die sich in Aufwand, Gründlichkeit und Detaillierungsgrad unterscheiden. Auch hier geben Ziele und Randbedingungen den Rahmen vor, aber der wichtigste Faktor ist, dass sich die beteiligten Stakeholder auf die Technik einigen, die sie anwenden wollen. Wenn nicht, werden sie das Ergebnis nicht akzeptieren, und Ihre Bemühungen, Prioritäten zu setzen, sind vergeblich. ▪ Durchführung der Priorisierung Wenn alle Vorbereitungen abgeschlossen sind, kann die eigentliche Priorisierung durchgeführt werden. Als erstes werden alle festgelegten Bewertungskriterien auf alle ausgewählten Anforderungen angewendet. Gemeinsam mit den beteiligten Stakeholdern wenden Sie dann die gewählte Priorisierungstechnik auf die bewerteten Anforderungen an. Als Ergebnis erhalten Sie eine priorisierte Liste von Anforderungen. Es könnte jedoch ein Problem geben. Verschiedene Stakeholder haben möglicherweise unterschiedliche Prioritäten, auch wenn sie sich über die bewerteten Kriterien einig sind. In diesem Fall haben Sie typischerweise einen Anforderungskonflikt, der genau wie jeder andere Konflikt gelöst werden sollte, wie in Kapitel 4.3 über Konfliktlösung beschrieben. Bei näherer Betrachtung der Priorisierungstechniken unterscheiden wir zwischen zwei Kategorien: ▪ Ad-hoc-Techniken Mit Ad-hoc-Techniken weisen Experten den ausgewählten Anforderungen aufgrund ihrer eigenen Erfahrung Prioritäten zu. Im Prinzip basiert diese Priorisierung auf einem einzigen Kriterium, nämlich der subjektiven Wahrnehmung des Experten. Wenn dieses Fachwissen auf einem hohen Niveau und für die Stakeholder akzeptabel ist, kann eine solche Technik ein schneller, billiger und einfacher Weg sein, um eine Priorisierung zu erreichen. Eine Variante bestünde darin, mehrere Experten einzuladen und eine Art durchschnittliche Priorität zu berechnen. Zu den üblichen Ad-hoc-Techniken gehören die Top-10-Rangliste und die MoSCoW-Priorisierung (Must have, Should have, Could have, Won't have this time). Die Kano-Analyse (Kapitel 4.2.1) ist ebenfalls nützlich: Die Basisfaktoren sind Must-Haves, die Leistungsfaktoren Should-Haves und die Begeisterungsfaktoren können Could- oder Won't-Haves sein. Weitere Hintergrundinformationen finden Sie z.B. bei [McIn2016]. Foundation Level | Handbuch | © IREB 159 | 174 ▪ Analytische Techniken Analytische Priorisierungstechniken verwenden einen systematischen Prozess zur Zuweisung von Prioritäten. Bei solchen Techniken weisen Experten mehreren Beurteilungskriterien (wie Nutzen, Kosten, Risiko, Zeit bis zur Umsetzung usw.) Gewichtungen zu, und anschließend werden auf der Grundlage dieser Kriterien Anforderungsprioritäten als gewichtete Ergebnisse berechnet. Solche Techniken erfordern mehr Aufwand und Zeit, haben aber den Vorteil, dass sie einen klaren Einblick in die Faktoren geben, die die Prioritäten bestimmen und in den Prozess, durch den die Prioritäten festgelegt werden. Dies kann die Akzeptanz des Ergebnisses bei den Stakeholdern fördern. Zwei Aspekte sind jedoch zu beachten. Erstens wird das Ergebnis stark von den Gewichtungsfaktoren beeinflusst, die bei der Berechnung des Ergebnisses verwendet werden. Daher muss vor der eigentlichen Priorisierung Einvernehmen zwischen den Stakeholdern über diese Gewichtungsfaktoren erzielt werden. Andernfalls könnten einige versuchen, die Gewichtungsfaktoren zu ändern, um die Prioritäten zu manipulieren. Der zweite zu berücksichtigende Aspekt ist, dass es sich bei den beurteilten Kriterien meist um Schätzungen und nicht um gemessene Fakten handelt. Und die Schätzungen liegen oft auf einer einfachen Ordinalskala wie niedrig, mittel, hoch. Die Qualität der Schätzungen ist also entscheidend für die Qualität der daraus resultierenden Priorisierung. Nichtsdestotrotz sind analytische Techniken nützlich, um eine klar untermauerte Priorisierung vorzunehmen, die von den beteiligten Stakeholdern verstanden und somit akzeptiert wird. Für eine detaillierte Erklärung der analytischen Techniken siehe [Olso2014]. Es mag verlockend sein, detaillierte, gründliche Techniken anzuwenden und viel Zeit damit zu verbringen, absolut exakte Schätzungen in Bezug auf Geld, Stunden, erwartete Verkaufszahlen usw. zu erstellen. Dies könnte dazu führen, dass Anforderung A eine berechnete Priorität von 22,76, Anforderung B von 23,12 und Anforderung C von 20,29 hat. Sie würden dann zu dem Schluss kommen, dass offensichtlich zuerst C und dann A vor B umgesetzt werden muss. Wahrscheinlich haben Sie mit dieser Berechnung jedoch nur eine Pseudo-Genauigkeit eingeführt, und es wäre besser, daraus den Schluss zu ziehen, dass diese drei Anforderungen gleich wichtig sind, was vielleicht von Anfang an Ihr Bauchgefühl gewesen sein könnte. Achten Sie immer darauf, dass der Aufwand, den Sie für die Priorisierung aufwenden, durch den Wert einer korrekten Priorisierung gerechtfertigt ist. Also behalten Sie die Ziele im Auge und erinnern Sie sich an Prinzip 1: Werteorientierung. 6.9 Weiterführende Literatur Die Lehrbücher von Pohl [Pohl2010], Davis [Davi2005], Hull, Jackson und Dick [HuJD2011], van Lamsweerde [vLam2009] und Wiegers und Beatty [WiBe2013] bieten einen umfassenden Überblick über das Anforderungsmanagement. Weitere Einsichten in das Anforderungsmanagement sind im CPRE Advanced Level Handbuch für Anforderungsmanagement von Bühne und Herrmann [BuHe2019] zusammengefasst. Foundation Level | Handbuch | © IREB 160 | 174 Cleland-Huang, Gotel und Zisman [ClGZ2012] behandeln das Thema Verfolgbarkeit eingehend. Olson [Olso2014] und Wiegers [Wieg1999] befassen sich mit Priorisierungstechniken. Foundation Level | Handbuch | © IREB 161 | 174