IREB CPRE Handbuch für Requirements Management (PDF)

Handbuch Requirements Management Practitioner | Specialist Stan Bühne Andrea Herrmann 2.1.0 | 5. April 2024 Nutzungsbedingungen 1. Jede Einzelperson und alle Seminaranbieter dürfen dieses Handbuch als Grundlage für Seminare verwenden, sofern die Inhaber der Urheberrechte als Quelle und Besitzer des Urheberrechts anerkannt und benannt werden. Des Weiteren darf dieses Handbuch zu Werbungszwecken nur mit Einwilligung des IREB e.V. verwendet werden. 2. Jede Einzelperson oder Gruppe von Einzelpersonen darf dieses Handbuch als Grundlage für Artikel, Bücher oder andere abgeleitete Veröffentlichungen verwenden, sofern die Autoren und IREB e.V. als Quelle und Besitzer des Urheberrechts genannt werden. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Die Verwertung ist – soweit sie nicht ausdrücklich durch das Urheberrechtsgesetz (UrhG) gestattet ist – nur mit Zustimmung der Berechtigten zulässig. Dies gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmung, Einspeicherung und Verarbeitung in elektronischen Systemen und öffentliche Zugänglichmachung. Gendergerechte Formulierungen Wir haben in diesem Dokument bewusst auf geschlechtsspezifische Formulierungen verzichtet. Selbstverständlich unterstützen wir als IREB geschlechtssensible Formulierungen. Wir sehen aber auch die Notwendigkeit, komplexe Sachverhalte so zu formulieren, dass sie leicht verstanden werden können. Texte, die eigentlich eine männliche und weibliche Form fordern, wären weniger gut lesbar und damit schwieriger zu verstehen. Ziel dieses Dokuments ist es jedoch, Inhalte präzise und klar darzustellen und zu vermitteln. Da wir dem Leser helfen wollen, den Fokus auf den Inhalt zu richten, verwenden wir in diesem Dokument bewusst nur die männliche Form von Personen. Dies soll nicht als Ausdruck von mangelndem Respekt verstanden werden. Danksagung Wir danken dem IREB e.V. für die Gelegenheit, dieses Buch zu schreiben sowie für die durchgängige organisatorische Unterstützung. Die IREB-Arbeitsgruppe „Requirements Management“ hat maßgeblich zur Erstellung der Inhalte beigetragen, da der von der Arbeitsgruppe erstellte Lehrplan das Grundgerüst dieses Buchs bildet und seine Mitglieder uns mit Kommentaren, Anmerkungen und Zusatzmaterial zur Seite standen. Aus diesem Grunde bedanken wir uns herzlich bei der gesamten Arbeitsgruppe (in alphabetischer Reihenfolge): Frank Engel, Sven Eselgrimm, Günter Halmans, Frank Houdek, Patrick Mäder, Alexander Rachmann, Thomas Schölzl, Amin Soesanto, Frank Stöckel und Malik Tayeh. Ein besonderer Dank geht an Prof. Dr. Martin Glinz und Dr. Thorsten Weyer, die diesem Werk durch ihre gründliche Begutachtung und ihre konstruktiven Kommentare seinen letzten Schliff gegeben haben. Requirements Management | Handbook | © IREB 2 | 273 Dieses Handbuch wurde erstellt von (in alphabetischer Reihenfolge): Stan Bühne, Dr. Andrea Herrmann. Urheberrecht © 2015-2019 des Handbuchs Requirements Management nach IREB Standard besitzen die aufgeführten Autoren. Die Rechte sind übertragen auf das IREB International Requirements Engineering Board e. V. Requirements Management | Handbook | © IREB 3 | 273 Inhaltsverzeichnis 1 Was ist Requirements Management?........................ 13 1.1 Definition des Requirements Managements........................... 13 1.2 Aufgaben im Requirements Management............................... 15 1.3 Ziele und Nutzen des Requirements Managements..................... 17 1.4 Der Requirements-Management-Plan.................................. 19 1.5 Relevante Normen.................................................. 19 1.6 Vertiefende Literatur............................................. 22 2 Requirements Information Model.......................... 23 2.1 Grundlagen (Klassifizierung von Anforderungen).................... 24 2.2 Darstellungsformen zur Dokumentation von Anforderungen............ 31 2.3 Beschreibung einer Anforderungs-Landschaft durch ein Requirements- Information-Model................................................. 32 2.4 Inhalte für den RMP............................................... 37 2.5 Vertiefende Literatur............................................. 37 3 Attributierung und Sichten bei Anforderungen............ 39 3.1 Ziele der Attributierung und Beispiele ihrer Verwendung in Managementtätigkeiten............................................. 39 3.2 Was ist ein Attributierungsschema?................................ 43 3.3 Nutzen eines Attributierungsschemas............................... 44 3.4 Entwurf eines Attributierungsschemas.............................. 46 3.5 Änderungsmanagement von Attributierungsschemata................... 57 3.6 Ziele und Arten von Sichten....................................... 59 3.7 Definition von Sichten und Risiken von Sichten.................... 62 3.8 Umsetzung einer Sicht............................................. 62 Requirements Management | Handbook | © IREB 4 | 273 3.9 Optimierung von Attributierung und Sichtenbildung................. 63 3.10 Inhalte für den RMP............................................... 65 3.11 Vertiefende Literatur............................................. 65 4 Bewertung und Priorisierung von Anforderungen........... 66 4.1 Motivation und Schwierigkeiten der Priorisierung von Anforderungen 66 4.2 Grundlagen der Bewertung.......................................... 67 4.3 Priorisierung von Anforderungen................................... 69 4.4 Zwei Typen von Priorisierungstechniken............................ 72 4.5 Ad-Hoc Priorisierungstechniken.................................... 72 4.6 Analytische Priorisierungstechniken............................... 80 4.7 Kombination von Priorisierungstechniken........................... 84 4.8 Inhalte für den RMP............................................... 85 4.9 Vertiefende Literatur............................................. 85 5 Versions- und Änderungsmanagement....................... 86 5.1 Versionierung von Anforderungen................................... 86 5.2 Änderungsmanagement für Anforderungen............................ 100 5.3 Änderungsmanagement-Prozess...................................... 106 5.4 Inhalte für den RMP.............................................. 111 5.5 Vertiefende Literatur............................................ 112 6 Verfolgbarkeit von Anforderungen....................... 113 6.1 Gründe für die Verfolgbarkeit von Anforderungen.................. 113 6.2 Unterschiedliche Verfolgbarkeits-Betrachtungen................... 115 6.3 Beziehungs-Typen für Verfolgbarkeits-Beziehungen................. 117 6.4 Darstellungsformen für Verfolgbarkeits-Beziehungen............... 122 Requirements Management | Handbook | © IREB 5 | 273 6.5 Erstellung einer Strategie zur projektspezifischen Verfolgbarkeit 132 6.6 Projektspezifische Verfolgbarkeits-Modelle erstellen und verwenden 135 6.7 Maße zur Bewertung von umgesetzter Verfolgbarkeit................ 141 6.8 Herausforderungen bei der Verfolgbarkeit zwischen textuellen und modellbasierten Artefakten....................................... 143 6.9 Inhalte für den RMP.............................................. 145 6.10 Vertiefende Literatur............................................ 145 7 Variantenmanagement für Anforderungen.................. 147 7.1 Einsatz von Varianten für Anforderungen.......................... 150 7.2 Formen expliziter Dokumentation von Varianten und deren Bewertung 154 7.3 Merkmals-Modellierung............................................ 160 7.4 Inhalte für den RMP.............................................. 167 7.5 Vertiefende Literatur............................................ 167 8 Berichtswesen im Requirements Management............... 169 8.1 Ziele und Nutzen des Berichtswesens im RM........................ 169 8.2 Etablierung eines Berichtswesens im RM........................... 171 8.3 Risiken und Probleme bei der Anwendung des Berichtswesens........ 186 8.4 Inhalte für den RMP.............................................. 188 8.5 Vertiefende Literatur............................................ 188 9 Management von Requirements Engineering Prozessen...... 189 9.1 Requirements Engineering als Prozess............................. 189 9.2 Parameter des Requirements Engineering Prozesses................. 192 9.3 Den Requirements Engineering Prozess dokumentieren............... 196 9.4 Den Requirements Engineering Prozess überwachen und steuern...... 199 Requirements Management | Handbook | © IREB 6 | 273 9.5 Prozessverbesserung für den Requirements Engineering Prozess..... 200 9.6 Inhalte für den RMP.............................................. 205 9.7 Vertiefende Literatur............................................ 205 10 Requirements Management in agilen Projekten............ 206 10.1 Vorwissen........................................................ 206 10.2 Anforderungsmanagement im Rahmen agiler Produktentwicklung....... 211 10.3 Abbildung von RM-Tätigkeiten auf Scrum-Tätigkeiten............... 214 10.4 Vertiefende Literatur............................................ 216 11 Werkzeugeinsatz im Anforderungsmanagement.............. 218 11.1 Rolle von Werkzeugen im Requirements Management.................. 218 11.2 Prinzipielle Vorgehensweise bei der Werkzeugauswahl.............. 219 11.3 Datenaustausch zwischen RM-Werkzeugen............................ 220 11.4 Inhalte für den RMP.............................................. 222 11.5 Vertiefende Literatur............................................ 222 12 Abkürzungsverzeichnis.................................. 223 13 Literaturverzeichnis................................... 224 Index..................................................... 232 Anhang A: Vorlage RMP..................................... 234 1 RE- und RM-Prozess..................................... 237 1.1 RE- und RM-Werkzeuge............................................. 237 1.2 Requirements Information Model................................... 238 1.3 Attributierungsschema............................................ 238 1.4 Priorisierung.................................................... 239 Requirements Management | Handbook | © IREB 7 | 273 1.5 Verfolgbarkeit................................................... 239 1.6 Sichten und Berichte............................................. 239 1.7 Versionierung.................................................... 240 1.8 Änderungsprozess................................................. 240 1.9 Variantenmanagement.............................................. 241 Anhang B (Werkzeugauswahl)................................ 242 1 Herausforderungen bei der Einführung und Nutzung von Werkzeugen............................................. 243 2 Kriterien für die Auswahl eines Requirements-Management- Werkzeugs.............................................. 245 3 Analyse ausgewählter Werkzeuge mittels der RMP- Bewertungskriterien.................................... 249 Anhang C (Earned-Value-Analyse)........................... 268 Requirements Management | Handbook | © IREB 8 | 273 Das IREB CPRE Modul Requirements Management Wer als Requirements Engineer, Business Analyst, Berater, Demand Manager oder Projektleiter in System- und Softwareentwicklungsprojekten arbeitet, weiß, dass es für die erfolgreiche Umsetzung eines Projektes noch lange nicht damit getan ist, seine Stakeholder zu kennen und deren abgestimmte Anforderungen anfänglich zu dokumentieren! Nein, selbst falls alle Anforderungen zu Projektbeginn gut strukturiert, abgestimmt und abgenommen waren, werden sie sich bis zum Projektende bzw. „Go Live“ ändern – und zwar immer zu den ungünstigsten Zeitpunkten. Und auch während des Betriebs ändern sich die Anforderungen und sollten zu Dokumentationszwecken bis zur Außerbetriebnahme des Systems aktuell gehalten werden. Dies liegt aber weder am Requirements Engineer bzw. an schlecht ausgewählten Methoden noch an den involvierten Stakeholdern – sondern meist einfach an der Natur der Dinge und sich im Laufe der Zeit verändernder Randbedingungen. Um in solchen Momenten ein unkontrolliertes „Fire-Fighting“ zu vermeiden und damit Sie als Requirements Manager jederzeit über den Stand der Anforderungen oder über die Auswirkung etwaiger Änderungswünsche auskunftsfähig sind, ist das Requirements Management (RM) unabdingbar, je komplexer das Projekt, umso mehr. Zum RM gehören auf der einen Seite der Medaille die bewusste Verwaltung von Anforderungen im klassischen Sinne (z.B. mittels Attributierung, Sichtenbildung, Verfolgbarkeit, etc.) sowie das Änderungsmanagement von Anforderungen. Auf der anderen Seite gehört aber auch die vorherige Planung und Überwachung der definierten Requirements Engineering (RE) Prozesse – im Sinne von: „Wie ermittele, dokumentiere und überprüfe ich meine Anforderungen, um kontinuierlich über den Status berichten zu können und um auf Änderungen geplant reagieren zu können?“ – zum RM. In diesem Handbuch für das IREB CPRE Modul Requirements Management - Practitioner - und - Specialist - möchten wir das Requirements Management aus diesem Grund von beiden Seiten betrachten. Dazu stellen wir die wesentlichen Konzepte des Requirements Management vor, beschreiben aber immer auch den notwendigen planerischen Aspekt, um eine bewusste Verwaltung von Anforderungen zu ermöglichen. Zur bewussten Verwaltung von Anforderungen (RM) muss der Requirements Manager bereits zu Beginn des RE-Prozesses folgendes planen und festlegen: ▪ Welche Anforderungsarten zu berücksichtigen sind, in welcher Darstellungsform und in welcher Detaillierung diese Anforderungen spezifiziert werden müssen ▪ Welche Fragen er auf Basis seiner Anforderungen beantworten muss und welche Sichten für die unterschiedlichen Stakeholder notwendig sind ▪ Durch welche Kriterien Anforderungen bewertet werden, um eine Priorisierung unterstützen zu können ▪ Wie Anforderungen und Anforderungs-Dokumente zu versionieren sind ▪ Wie und zu welchem Zeitpunkt mit Änderungen umgegangen werden soll ▪ Zwischen welchen Anforderungen und weiteren Entwicklungs-Artefakten Verfolgbarkeit geschaffen werden muss Requirements Management | Handbook | © IREB 9 | 273 ▪ Ob und wie Anforderungsvarianten innerhalb der Anforderungs-Spezifikation zu dokumentieren sind ▪ Welche Berichte über den Anforderungsstand gefordert sind, welche Informationen diese zu enthalten haben und über welche Quellen (z.B. aus der Dokumentation der Attribute) diese Informationen ermittelt werden können ▪ Wie der exakte RE-Prozess (bzw. Ablauf von Aktivitäten) für das Projekt auszusehen hat, und wie der Prozess überwacht und evtl. verbessert werden kann Das Ergebnis der obigen Überlegungen wird in einem Requirements Management Plan (RMP) dokumentiert. Mit dessen Hilfe können sowohl der RE-Prozess als Ganzes als auch das Berichtswesen, Priorisierungen und Änderungen (als Teil des Requirements Management) geplant und strukturiert ablaufen. Das Requirements Management wird durch den Requirements Engineer geplant und durchgeführt oder durch eine separate Rolle eines Requirements Managers. Der Requirements Manager plant, verwaltet und überwacht im Rahmen des RM den RE-Prozess mit seinen Artefakten, berichtet z.B. an den Auftraggeber bzw. Projektmanager. Der Requirements Manager koordiniert auch Änderungen. Der RMP sorgt dafür, dass der RE-Prozess aktiv überwacht werden kann und spätere Entscheidungen bewusst und nachvollziehbar getroffen werden können. Das heißt nicht, dass das RE kein iterativ-inkrementeller und kreativer Prozess ist – aber der RE-Prozess sollte kreativ und bewusst geplant sein und nicht chaotisch ablaufen! Dieses Handbuch unterstützt den Requirements Manager bei der Erstellung des RMPs, indem es die dafür nötigen Konzepte und Begriffe erklärt und passende Methoden vorstellt. Zusätzlich zeigt dieses Buch, wie RE und RM in agilen Projekten umgesetzt werden kann, denn auch in agilen Projekten werden Anforderungen dokumentiert (z.B. User Stories), und auch agile Projekte müssen mit Änderungen, Priorisierungen etc. umgehen können. In der Praxis ist ein gezieltes RM in komplexen Projekten ohne den Einsatz von Werkzeugen nur schwer vorstellbar. Daher beschreiben wir im letzten Kapitel Möglichkeiten der Unterstützung durch – sowie Grenzen von – RM-Werkzeugen. Mit diesen Themen vermittelt das Handbuch zum Modul Requirements Manangement - Practitioner - und - Spezialist - des IREB Certified Professional for Requirements Engineering (CPRE) das Rüstzeug, um Anforderungen bewusst und strukturiert zu verwalten. Viel Spaß beim Lesen! Weitere Informationen zum IREB Certified Professional for Requirements Engineering Modul Requirements Management - Practitioner - und - Specialist - finden Sie unter: http://www.ireb.org Vorwort Das vorliegende Handbuch Requirements Management nach IREB Standard ergänzt den Lehrplan des International Requirements Engineering Boards für das Modul Requirements Management Practitioner und Specialist Version 2.0.00 vom 01.07.2022 und orientiert sich am IREB-Glossar [Glin2014]. Requirements Management | Handbook | © IREB 10 | 273 Das Handbuch richtet sich sowohl an Trainingsanbieter, die Seminare zum Requirements Management Practitioner und/oder Specialist nach dem IREB-Standard anbieten wollen, als auch an Trainingsteilnehmer und interessierte Praktiker, die einen detaillierten Einblick in den Lehrstoff dieses Moduls und in das Requirements Management nach IREB Standard erhalten möchten. Dieses Handbuch ist kein Ersatz für Schulungen oder Lehrbücher zu diesem Thema. Es stellt vielmehr ein Bindeglied zwischen dem komprimiert gehaltenen Lehrplan (der lediglich die Lernziele des Moduls nennt und erläutert) und der Vielzahl an Literatur dar, die zum Thema Requirements Management in den letzten Jahrzehnten entstanden ist. Die in diesem Handbuch beschriebenen Inhalte, zusammen mit den Hinweisen auf vertiefende Literatur, sollen Trainingsanbieter dabei unterstützen, die Trainingsteilnehmer fokussiert auf die Zertifizierungsprüfung vorzubereiten. Trainingsteilnehmern und interessierten Praktikern bietet dieses Handbuch die Möglichkeit, die Kenntnisse im Bereich des Requirements Management zu vertiefen und die detaillierten Inhalte auf Basis der Literaturempfehlungen aufzuarbeiten. Darüber hinaus soll dieses Handbuch auch als Referenz dienen, um z.B. nach erfolgreicher Zertifizierung das Wissen über die verschiedenen Themenbereiche des Requirements Managements auffrischen zu können. Neben den zum Lehrplan vertiefenden und prüfungsrelevanten Inhalten, ! bietet das Handbuch in jedem Kapitel erläuternde Beispiele anhand eines durchgängigen Fallbeispiels. Das Fallbeispiel ist mit dem links stehenden Randsymbol gekennzeichnet. Diese Inhalte sind nicht direkt prüfungsrelevant, aber zum besseren Verständnis des Inhaltes durchaus zu empfehlen. Darüber hinaus bieten wir dem interessierten Leser über die Prüfung hinausgehende Informationen, welche nicht prüfungsrelevant sind. Sofern diese Inhalte in den Schreib- und Lesefluss passen, wurden diese in das jeweilige Kapitel integriert und mit einer roten Seitenmarkierung (siehe rechts) als nicht prüfungsrelevant gekennzeichnet. Die ergänzenden Inhalte in Anhang A bis C sind ebenfalls nicht prüfungsrelevant. Verbesserungs- und Korrekturvorschläge sind jederzeit herzlich willkommen! E-Mail-Kontakt: [email protected] Wir wünschen Ihnen viel Spaß beim Studium dieses Handbuchs und viel Erfolg bei der Zertifizierungsprüfung zum IREB Certified Professional for Requirements Engineering Modul Requirements Management - Practitioner - oder - Specialist. Stan Bühne Andrea Herrmann Herbst 2015 Requirements Management | Handbook | © IREB 11 | 273 Versionshistorie Version Datum Kommentar Autor 1.1.0 1. September 2019 Beseitigung von Andrea Inkonsistenzen gegenüber Herrmann, dem Lehrplan. Stefan Sturm Fehlerbehebungen im Zusammenhang mit der Übersetzung ins Englische 2.0.0 1. Juli 2022 Umstellung auf Practitioner und Specialist 2.1.0 5. April 2024 Neues Corporate Design umgesetzt Requirements Management | Handbook | © IREB 12 | 273 1 Was ist Requirements Management? Dieses Kapitel definiert zunächst, warum, für wen und wozu Requirements Management wichtig ist, welche Aufgaben dazu gehören und wer diese durchführt. 1.1 Definition des Requirements Managements Wie für so viele Begriffe gibt es auch für den Begriff „Requirements Management“ unterschiedliche Definitionen. Auch das Verhältnis des Requirements Management (RM) zum Requirements Engineering (RE) ist uneinheitlich definiert. Mal gilt RM als Teil des RE (wie im CPRE-Foundation Level [IREB2015]), mal umgekehrt RE als Teil des RM (z.B. in [Schi2001]). Das CMMI [SEI2011] dagegen sieht beide als gleichwertig. Definition 1.1: Wir definieren Requirements Management als Teil des RE. Requirements Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen: 1. Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern über die Anforderungen herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen. 2. Die Wünsche und Bedürfnisse der Stakeholder zu verstehen und zu dokumentieren. 3. Die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht [Glin2014] und [PoRu2015]. Requirements Management: Der Prozess des Verwaltens existierender Anforderungen und anforderungsbezogener Artefakte. Dies schließt insbesondere die Dokumentation, das Ändern und die Verfolgbarkeit von Anforderungen mit ein [Glin2014]. Auch das Verwalten des RE-Prozesses gehört dazu, d.h. das Planen, Steuern und Kontrollieren des RE- Prozesses. Im Folgenden nennen wir einige zusätzliche Definitionen, um die in der Fachliteratur vorhandene Vielfalt darzustellen. IREB hat sich hier auf eine klare Definition festgelegt, damit zertifizierte Requirements Manager und Requirements Engineers mit demselben Begriff immer dasselbe meinen. Eindeutige Begriffe vereinfachen nicht nur grundsätzlich die Zusammenarbeit im Berufsleben, sondern wenn, wie in der Einführung dieses Handbuchs empfohlen, zusätzlich zur Rolle des Requirements Engineer noch eine Rolle des Requirements Managers eingeführt wird, folgt aus der Definition des Verhältnisses zwischen den beiden Disziplinen RE und RM auch die Aufgabenteilung zwischen diesen beiden Rollen. Auch Ebert [Eber2012] definiert: „Requirements Management (RM) ist ein Teil des Requirements Engineering, der sich mit Pflege, Verwaltung und Weiterentwicklung von Anforderungen im Lebenszyklus befasst.“ Dieser Lebenszyklus ist im Zusammenhang mit Requirements Management | Handbook | © IREB 13 | 273 dem RE sehr wichtig. Es genügt demnach nicht, Anforderungen nur einmalig zu erheben. Anforderungen müssen über den gesamten Lebenszyklus der Software / des Systems hinweg verwaltet werden. Hierbei ist zu berücksichtigen, dass nicht nur die Software / das System selbst, sondern auch jede einzelne Anforderung einen eigenen Lebenszyklus durchläuft. Laut Pohl [Pohl2010] kann das RM in drei wesentliche Teilaktivitäten zerlegt werden: 1. Beobachtung des Systemkontextes, um Kontext-Änderungen aufzudecken 2. Verwalten und Ausführen der RE-Aktivitäten (d.h. RM als Prozessmanagement) 3. Verwaltung der Anforderungen bzw. zugehörigen Artefakte während des Entwicklungsprozesses Laut Standard ISO/IEC/IEEE 29148:2011 ISO29148 ist RM definiert als „activities that ensure requirements are identified, documented, maintained, communicated and traced throughout the life cycle of a system, product, or service“. Beim RM geht es nicht nur um die Verwaltung der Anforderungen, sondern aller damit zusammenhängender Informationen: „Maintain throughout the system life cycle the set of system requirements together with the associated rationale, decisions and assumptions.“ ([ISO15288], 6.4.2.3 b). Um die Definitionen und Empfehlungen dieses Handbuchs zu illustrieren, ! verwenden wir das Beispiel eines Online-Banking-Systems. Wir nehmen an, das System existiere bereits. Eine vollständige und qualitätsgesicherte Anforderungs-Spezifikation nach den Regeln der Kunst war die Grundlage seiner Entwicklung. Jedoch ist es damit nicht genug. Die Anforderungen an das System ändern sich durch Gesetzesänderungen (wie z.B. die SEPA- Umstellung), durch das ständige Bemühen, das Online-Banking bei gleichbleibender Benutzerfreundlichkeit noch sicherer zu machen oder bei gleichbleibender Sicherheit noch benutzerfreundlicher, durch technische Neuerungen, durch Ideen des Produktmanagements für neue Funktionalitäten oder durch Änderungen von Geschäftsprozessen innerhalb der Bank, die sich auch auf das Online-Banking auswirken. Nun gilt es, trotz dieser vielen Änderungsideen aus allen Richtungen den Überblick zu behalten, vorab abzuschätzen, welche Kosten und andere Folgen eine Idee bei ihrer Umsetzung mit sich bringen würde, und wohl begründet die Änderungen umzusetzen, zurückzustellen oder abzulehnen. Und dies unter Einbeziehung aller Stakeholder wie der IT-Abteilung, dem Produktmanagement, dem Vorstand, dem Datenschutzbeauftragten und dem Kundenbeirat. Doch auch unser Requirements Engineer ist einer der Stakeholder. Unser Requirements Engineer heißt Peter Reber. Er ist 35 Jahre alt und arbeitet bereits seit zehn Jahren bei unserer Beispiel-Bank. Er kennt alle Stakeholder sehr gut und kontaktiert sie gerne auch ohne besonderen Anlass, um zu erfahren, was es Neues gibt. Das Online-Banking wurde erfolgreich eingeführt, bevor Peter seine Tätigkeit bei der Bank aufnahm. Seitdem er von seinem Vorgänger eingearbeitet wurde, verwaltet Peter Requirements Management | Handbook | © IREB 14 | 273 alleinverantwortlich die Anforderungen des Online-Bankings gewissenhaft nach den Regeln des RE. Seine ruhigen Zeiten gehen jedoch zu Ende, als das gesamte Online-Banking auf ein neues Corporate Design mit neuen Farben, Schriftarten, Fachbegriffen und Logos umgestellt wird. Diese Gelegenheit möchte man nutzen, um neue Funktionalität einzuführen, die Sicherheit und die Benutzerfreundlichkeit zu erhöhen. Eine Gruppe von Experten soll innerhalb kurzer Zeit Änderungsanforderungen erheben oder definieren, also RE betreiben: mehrere externe Business Analysten analysieren die Geschäftsprozesse, ein Team von IT-Sicherheits-Experten betreibt Risiko- Analysen, der Usability-Experte entwirft alternative Oberflächen-Designs und verbessert die Barrierefreiheit, ein Moderator trifft sich zu einem Ideenworkshop mit dem Kundenbeirat. Diese alle betreiben RE. Peter Reber soll deren Arbeit organisieren und koordinieren. Das heißt, während die anderen RE machen, kümmert er sich um das RM. 1.2 Aufgaben im Requirements Management Wir definieren hier die Aufgaben, die zum RM gehören. Somit stellt diese Definition auch eine Rollenbeschreibung dar: Der Requirements Manager verantwortet das RM und führt die zum RM gehörigen Aufgaben selbst durch oder überwacht deren Durchführung. Drei grundsätzliche Rahmenbedingungen [RuSo2009] erhöhen die Komplexität der RM- Aufgaben: ▪ Anforderungen müssen von mehreren Personen genutzt werden ▪ Anforderungen sollen wiederverwendet werden ▪ Anforderungen ändern sich Das RM ist verantwortlich dafür, die Regeln und Techniken bereitzustellen, die benötigt werden, damit Anforderungen und andere Informationen so abgelegt werden können, dass jeder Beteiligte das findet, was er braucht. Dies muss vorab geplant werden. Darum erstellt der Requirements Manager vor dem Beginn des RE-Prozesses den Requirements- Management-Plan (RMP). Requirements Management | Handbook | © IREB 15 | 273 Definition 1-2: Der Requirements Management Plan umfasst: - Die Anforderungs-Landschaft, d.h. die zu verwaltenden Anforderungs-Artefakt-Typen und deren Detaillierungsgrad (siehe Kapitel 2) - Attribute und Sichten auf die Anforderungen (siehe Kapitel 3) - Priorisierungskriterien und -techniken (Kapitel 4) - Versionsverwaltung von Anforderungen sowie den Änderungsprozess (Kapitel 5) - Verwaltung der Verfolgbarkeit von Anforderungen (Kapitel 6) - Variantenmanagement (Kapitel 7) - Berichtswesen (Kapitel 8) - RE-Prozess und Aktivitäten für dessen Verbesserung (Kapitel 9 und 10) - Zu verwendende Werkzeuge (Kapitel 11) Dieses Handbuch behandelt in den folgenden Kapiteln die Inhalte des RMP und schlägt für die jeweils durchzuführenden Aktivitäten unterschiedliche Techniken vor. Es wird jeweils am Ende jedes Kapitels zusammengefasst, welche Inhalte der RMP enthalten soll. Während des RE-Prozesses führt das RM diese Aufgaben entsprechend des Planes aus: Sichten und Berichte werden erstellt und aktualisiert, Anforderungen für Releases ausgewählt, Änderungen systematisch verwaltet und priorisiert, Produktlinien definiert und verwaltet, Werkzeuge eingeführt und der RE-Prozess überwacht und verbessert. Das Requirements Management wird durch den Requirements Engineer geplant und durchgeführt oder durch eine separate Rolle eines Requirements Managers. Der Requirements Manager verhält sich dann zum Requirements Engineer wie der Qualitätsmanager zum Tester. Eine solche Aufgabenteilung ist gerade dann sinnvoll, wenn in einem komplexen, zeitkritischen Projekt im RE und RM so viel Arbeit anfällt, dass mehrere Personen Anforderungen erheben, abstimmen und verwalten müssen. Dann braucht es eine Rolle, welche den Prozess gestaltet und überwacht, Informationen zusammenführt und auswertet. Requirements Management | Handbook | © IREB 16 | 273 Peter Rebers erste Aufgabe ist also die Erstellung des RMPs. Er könnte auch ! organisieren, dass dieser erstellt wird. In unserem Fall erstellt Peter den RMP aufgrund seiner großen Erfahrung selbst. Er kann sich dafür Hilfe von den vielen vorhandenen RE-Experten einholen und sollte diesen Plan ohnehin mit ihnen abstimmen. Denn vielleicht haben diese spezielle Anforderungen an das Requirements Manangement. In diesem Handbuch begleiten wir Peter und sein Team Schritt für Schritt bei ihren Aufgaben. 1.3 Ziele und Nutzen des Requirements Managements Ziel des Requirements Management ist es, Anforderungen und andere Artefakte (z.B. Interview-Protokolle und Lastenheft) so zu verwalten, dass die Anforderungen mit vertretbarem Aufwand systematisch durchsucht, gruppiert, bewertet, geändert und verfolgt werden können. Dabei versucht das RM, gleichzeitig die Bedürfnisse vieler verschiedener Beteiligter zu erfüllen. Die Bedürfnisse sind dabei im Wesentlichen vom konkreten Projektkontext abhängig. So unterscheiden sich diese beispielsweise in Projekten zur kundenspezifischen Software- bzw. Produktentwicklung von internen Projekten durch die IT-Abteilung. Das RM liefert unter anderem Antworten auf die nachfolgenden Fragestellungen, basierend auf den in Klammern genannten Techniken: ▪ Welche Anforderungsarten werden unterschieden? (Anforderungs-Landschaft) ▪ Auf welchen Detaillierungsebenen werden Anforderungen dokumentiert? (Anforderungs-Landschaft) ▪ Welche Anforderungen sind bereits abgenommen? (Attributierung) ▪ Welche Anforderungen stammen aus welcher Quelle? (Attributierung) ▪ Welche Anforderungen sind dringend und wichtig und somit Kandidaten für das nächste Release? (Bewertung und Priorisierung) ▪ Welche Anforderung erzeugt zu hohe Kosten bei zu geringem Nutzen? (Bewertung und Priorisierung) ▪ Welche Anforderungen gehören zu einer bestimmten Basislinie der Software? (Versionsverwaltung) ▪ Welche Version der Anforderung wurde im System umgesetzt? (Versionierung) ▪ Wer hat die Anforderung zuletzt verändert und warum? (Versionierung) ▪ Welche technische Komponente gehört zu welcher Anforderung? (Verfolgbarkeit) ▪ Welche Testfälle gehören zu welcher Anforderung? (Verfolgbarkeit) ▪ Welche Anforderung ist Teil des ausgelieferten Systems / Produkts? (Verfolgbarkeit) ▪ Worin unterscheiden sich die beiden Varianten des Produkts? (Variantenmanagement) ▪ Welcher Anteil der Anforderungen wurde bereits umgesetzt und getestet? (Berichtswesen) ▪ Wie lange braucht ein Change Request im Durchschnitt bis zu seiner Umsetzung? (Berichtswesen) Requirements Management | Handbook | © IREB 17 | 273 ▪ Hat sich der RE-Prozess durch eine bestimmte Maßnahme verbessert? (Berichtswesen) Grundsätzlich lohnt sich RM nicht nur bei größeren Projekten, sondern auch bei kleinen. Wobei bei überschaubaren Projekten das Kernteam das RM sogar oft im Kopf erledigt und noch genau weiß, wann welche Anforderung warum geändert wurde. RM ist umso wichtiger und schwieriger [RuSo2009]… ▪... je größer die Zahl der Anforderungen ist ▪... je länger die geschätzte Lebensdauer des Produktes ist ▪ … je mehr Änderungen zu erwarten sind ▪ … je größer die Anzahl der Beteiligten am RE-Prozess ist ▪ … je schlechter die Stakeholder zu erreichen oder einzubeziehen sind ▪... je höher die Qualitätsansprüche an das System sind ▪ … je mehr Wiederverwendung betrieben werden soll ▪ … je komplexer der Entwicklungsprozess ist ▪ … je inhomogener die Stakeholder-Meinungen sind ▪ … je mehr Releases entwickelt werden ▪ … je wichtiger die Nutzung von Normen für das Projekt ist Ein gutes Requirements Management...[RuSo2009] ▪ … erhöht die Qualität von Anforderungen, Produkten und Prozessen ▪ … reduziert Projektkosten und Projektlaufzeit ▪ … vereinfacht die Überwachung komplexer Projekte während aller Phasen ▪ … verbessert die Kommunikation innerhalb der und zwischen den Teams ▪ … erhöht die Kundenzufriedenheit ▪ … reduziert das Projektrisiko RM ist eine komplexe Aufgabe: Jeder Stakeholder sollte jederzeit auf die aktuellen Informationen zugreifen können und auch über die Änderungen informiert werden, die ihn betreffen, jedoch ohne mit unnötiger Information belastet zu werden. Dies soll auch dann gelten, wenn die Stakeholder weltweit verteilt arbeiten und wenn Ansprechpartner wechseln. Gleichzeitig soll aber auch der notwendige Datenschutz beachtet werden und jeder nur auf diejenigen Daten zugreifen, die er tatsächlich für seine Arbeit benötigt. Die durch das RM gesammelten Daten führen zu einer gewissen Komplexität, die nicht nur durch die pure Menge der Anforderungen und zugehöriger Informationen entsteht, sondern auch durch deren gegenseitige Abhängigkeit und die zeitliche Dimension von Versionen und Anforderungs-Basislinien (Baselines). Das RM vereinfacht das RE: ▪ Strukturieren der Anforderungen und des Anforderungs-Dokuments (z.B. durch Attributierung, Sortieren und Filtern), ▪ Vereinheitlichen der Terminologie (z.B. mit einem Glossar), ▪ Definition klarer Prozesse und Arbeitsschritte, die durchzuführen sind (z.B. im Änderungsprozess). Requirements Management | Handbook | © IREB 18 | 273 Für Peter Reber stellt sich also die Frage nach dem Nutzen des RM nicht ! wirklich. Es ist zu erwarten, dass diese Vielzahl an Stakeholdern und Requirements Engineers eine große, vielleicht sogar zu große Anzahl an Änderungsanforderungen finden werden. Diese müssen miteinander abgestimmt und die relevantesten für das erste Release ausgewählt werden. Natürlich steht dieses Projekt wie die meisten unter Zeitdruck und besitzt nur ein vorab festgelegtes Budget. 1.4 Der Requirements-Management-Plan Im Projektmanagement kennt man seit Jahr und Tag die Notwendigkeit eines Projektmanagement-Plans [PMI2013]. Dieser Plan beschreibt, wie ein konkretes Projekt durchgeführt werden soll. Neben dem Projektplan enthält er die Planung, wie beispielsweise Risikomanagement betrieben werden soll, welche Kommunikations- und Besprechungskultur gelebt werden soll, wer welche Verantwortung übernimmt, etc. Dieser Plan ermöglicht es dem Projektmanager, alle Projektmitglieder auf denselben Kenntnisstand zu bringen, bezüglich der Frage, wie innerhalb des Projektes gearbeitet werden soll. Darüber hinaus bietet der Plan die Möglichkeit zur Kontrolle des Prozesses. Analog zum Projektmanagementplan sehen wir den Requirements-Management-Plan (RMP). Der RMP beschreibt u.a. die Planung wie der RE-Prozess aufgesetzt werden soll, wer welche Aufgaben verantwortet, welche Anforderungen wie dokumentiert werden sollen, wie diese Anforderungen verwaltet werden, ob und welche Werkzeuge zum Einsatz kommen. Der RMP beschreibt kurz gefasst kurz alle Aspekte, die im RE und RM für eine neue Entwicklung bzw. für die kontinuierliche Weiterentwicklung eines bspw. Produktes zu berücksichtigen sind. Der RMP beschreibt damit den Rahmen für den gesamten RE-Prozess. In den folgenden Kapiteln beschreiben wir die wesentlichen Inhalte der RM und geben Ihnen in jedem dieser Kapitel einen Hinweis, welche der beschriebenen Aspekte in einen RMP aufgenommen werden sollten. Im Anhang A finden Sie darüber hinaus eine mögliche Vorlage für einen RMP zur eigenen Anwendung. Hinweis: In der Praxis ist der RMP oft kein eigenständiges Dokument, sondern Bestandteil des Projektplans, des Konfigurationsmanagement-Plans oder anderer Vorgabedokumente zum Entwicklungsprozess. Die Struktur des RMP im Anhang soll im Wesentlichen dazu dienen, Ihnen für das Thema RMP einen Rahmen zu geben. 1.5 Relevante Normen Damit die Entwicklung von Software und technischen Systemen nachvollziehbar und wiederholbar in hoher Qualität erfolgt, wurden diverse Normen und Standards entwickelt. Diese beschreiben die durchzuführenden Aktivitäten, zu erstellenden Artefakte und anzuwendenden Techniken. Das RM ist von diesen Standards durchgängig als wichtiger Beitrag zur Sicherung der Ergebnisqualität anerkannt. Darum machen diese Standards auch Requirements Management | Handbook | © IREB 19 | 273 Aussagen über die Durchführung des RM. Allerdings sind die Aussagen der verschiedenen Standards nicht unbedingt miteinander konsistent und miteinander verträglich. Beispielsweise verwenden sie unterschiedliche Begriffe für ein entsprechendes Artefakt und schlagen jeweils unterschiedliche Kapitel dafür vor. Einige wichtige Normen, die den gesamten Software- oder Systementwicklungsprozess umfassen, und dabei auch Aussagen über RE und RM machen, sind die folgenden: ▪ Das Prozess-Reifegradmodell CMMI (Version 1.3) [SEI2010] betrachtet unter anderem die Prozesse „Anforderungsentwicklung (Requirements Development) “ und „Anforderungsmanagement (Requirements Management)“, wobei die zugeordneten Ziele sich teilweise deutlich von den Festlegungen des IREB unterscheiden. ▪ Die ISO 9000 / ISO 9001 [ISO9000] ist eine Norm für Qualitätsmanagement in Unternehmen. Die ISO 9001:2008 („Quality Management Systems – Requirements“) legt Mindestanforderungen an ein Qualitätsmanagementsystem fest und beschreibt beispielsweise Anforderungen an die Produktrealisierung, Messung und Verbesserung und adressiert somit Themen wie Identifizierbarkeit oder Verfolgbarkeit von Anforderungen (vgl. Clause 7.5.3 „Identification and Traceability“). ▪ In der ISO/IEC 12207:2008 [ISO12207] bzw. 15288:2008 [ISO15288] („Software life cycle processes“ bzw. „Systems and software engineering – Systems life cycle processes“) werden sämtliche Prozesse zur Entwicklung von Systemen und Software definiert. Die Aufgaben „System requirements analysis“ und „Software requirements analysis“ des ISO/IEC 12207 und „Stakeholder Requirements Definition Process“ sowie „Requirements Analysis Process“ des ISO/IEC 15288 umfassen die Tätigkeiten des RE und RM. ▪ Die IEC 61508 [DIN61508] („Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme“) beschäftigt sich mit der Definition von Anforderungen an die funktionale Sicherheit von Systemen und deren Umsetzung, einschließlich quantitativer Sicherheitsschätzungen. Insbesondere dem Thema Verfolgbarkeit wird hier eine besondere Bedeutung beigemessen. Die Norm definiert Sicherheitsintegritätsstufen (SIL) 1 bis 4, die das Gefährdungsrisiko beschreiben. ▪ Je höher die Stufe, umso höher das Gefährdungspotenzial, und damit steigen auch die Anforderungen an die Verlässlichkeit des Systems. ▪ SOX (Sarbanes-Oxley Act) [USCo2002] ist ein US-Bundesgesetz als Reaktion auf Bilanzskandale, welches die Verlässlichkeit der Berichterstattung von Unternehmen, die am öffentlichen Kapitalmarkt in den USA notiert sind, verbessern soll. Der Kern des Sarbanes-Oxley Act ist zu wissen, wer, zu welchem Zeitpunkt, welche Änderung durchführen ließ und betrifft somit auch Kernaufgaben des RM. RE und RM ist zudem beispielsweise in den folgenden Standards zu finden: ▪ VDI-Richtlinie 2519 Blatt 1 - Vorgehensweise bei der Erstellung von Lasten- /Pflichtenheften [VDI2001] ist der deutsche Standard zur Beschreibung von Lasten- und Pflichtenheften. Requirements Management | Handbook | © IREB 20 | 273 ▪ Der IEEE 830-1998 („Recommended Practice for Software Requirements Specifications“) [IEEE830] definiert Begriffe des RE und RM, insbesondere Qualitätseigenschaften von Anforderungen und die Kapitel für eine Spezifikation (“software requirements specification”). Viele dieser Definitionen sind auch in den CPRE Foundation Level eingegangen [IREB2015]. ▪ ISO/IEC/IEEE 29148:2011 („Systems and software engineering – Life cycle processes – Requirements engineering”) ISO29148 definiert Qualitätseigenschaften und Attribute von Anforderungen und empfiehlt den iterativen Umgang mit Anforderungen während des gesamten Lebenszyklus. ▪ IEEE Standard 1233 „Guide for Developing of System Requirements Specifications“ [IEEE1233] beschreibt die Entwicklung von Anforderungen, Spezifikationen und deren Verwaltung in der gesamten Produktentwicklung. Er beschreibt die Erhebung und Definition von Anforderungen, das Änderungsmanagement und die Organisation von Anforderungen im Projekt. ▪ ISO / IEC 14102:1995 („Evaluation and Selection of CASE Tools“) ISO14102 beschreibt Anforderungen an CASE Tools, d.h. Werkzeuge zur computerunterstützten Softwareentwicklung, kann aber auch speziell für die Auswahl von RE- und RM- Werkzeugen verwendet werden. ▪ ISO/IEC 25010:2011 („Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models“) [ISO25010] beschreibt zwei Qualitätsmodelle für nichtfunktionale Anforderungen – eines für „Quality in use“ und eines für die Produktqualität. Mit Hilfe dieser Qualitätsmodelle können nichtfunktionale Anforderungen an Software und Computersysteme einheitlich erhoben und spezifiziert werden. ▪ Die ISO 29110 („Lifecycle process standard for Very Small and Medium Entities (VSME)“) [ISO29110] beschreibt einen System-Lebenszyklus einschließlich RE für kleine und mittlere Einheiten, also Projekte von ca. unter 25 Personen. ▪ Die europäische Norm ISO 9241 [ISO9241], die auch als DIN-Norm anerkannt ist, beschreibt Richtlinien der Mensch-Computer-Interaktion, und zwar sowohl eine Liste von Qualitätsanforderungen, die eine benutzerfreundliche Software einhalten muss, als auch den Entwicklungs- und Prüfprozess einer solchen Software. Hinzu kommen noch branchenspezifische Normen und Standards wie DO 178 B/ED-12B und DIN EN 14160 für die Luftfahrt, IEEE/EIA Std. 12207:1998 für das Militär, FDA-535, FDA-938 und EN62304 für die Medizintechnik, EN 50128 für die Bahntechnik oder ITU X.290-X.296 (ISO/IEC 9646-x) oder ETSI ES 201 873-x (TTCN-3) für die Telekommunikation. Diese Normen gelten nicht automatisch und vor allem nicht gleichzeitig, da sie nicht vollständig miteinander verträglich sind. Jede Firma und jedes Projekt wählt die passenden Standards aus, die sie in originaler oder in angepasster Form anwenden werden. Manchmal verlangt der Kunde die Einhaltung eines bestimmten Standards. Zusätzlich zu Normen, Standards und Richtlinien sind firmenspezifische Normen des Software-Herstellers oder des Kunden zu beachten. Diese wiederum können aufbauend auf öffentlichen Standards entwickelt sein können und Aspekte des RE und RM beinhalten. Requirements Management | Handbook | © IREB 21 | 273 Peter Reber verwendet wegen seiner Verständlichkeit und Praxisnähe für ! seine Arbeit zunächst das (hier vorliegende) IREB-Handbuch zum Requirements Management, das aus Standards heraus entwickelt wurde. Außerdem gelten die Firmen-Richtlinien über die Durchführung von IT- Projekten und die neue Corporate Identity. 1.6 Vertiefende Literatur Zur Vertiefung empfehlen wir die im vorigen Abschnitt genannten Standards. Weitere Definitionen finden Sie im IREB-Glossar [Glin2014]. Requirements Management | Handbook | © IREB 22 | 273 2 Requirements Information Model In diesem Kapitel betrachten wir, wie Sie die verschiedenen Aspekte Ihrer projektspezifischen Anforderungs-Landschaft festlegen und durch ein Requirements- Information-Model beschreiben können. Im Rahmen der Dokumentation von Anforderungen stoßen wir immer wieder auf eine Vielzahl von Grundsatzfragen, die noch nichts mit den konkreten Inhalten der Anforderungen zu tun haben, aber frühzeitig festgelegt werden müssen, z.B.: ▪ Welche Anforderungsarten existieren und müssen betrachtet werden? ▪ Wie können Anforderungen nach ihrer Lösungsabhängigkeit klassifiziert werden? ▪ Wie sollen diese Anforderungen dokumentiert und dargestellt werden? ▪ Wie detailliert muss die Anforderung beschrieben werden? Diese Fragen sollten grundsätzlich bereits zu Beginn des RE geklärt werden. Aber nicht immer laufen Projekte so ideal, wie man es sich wünscht. Manchmal werden Projekte von Dritten übernommen, die keine Festlegungen dieser Art getroffen haben. Manchmal erlauben es die zum Projektstart gegebenen Randbedingungen nicht, einen RMP zu erstellen bzw. sich über die Struktur seiner Anforderungen Gedanken zu machen und man „sammelt“ in einem ersten Schritt nur, ohne die Anforderungen zu klassifizieren. Wichtig ist allerdings, dass Sie sich zu gegebener Zeit – und zwar möglichst frühzeitig – mit der Planung Ihrer Anforderungs-Landschaft beschäftigen. Denn als Requirements Manager sind Sie neben der Verwaltung der Anforderungs-Artefakte dafür zuständig, die Aktivitäten im RE-Prozess zu managen – das heißt, diese zu planen, zu überwachen und entsprechend zu steuern (Definition 1-1). Definition 2-1: Anforderungs-Artefakt nach [Glin2014][Pohl2010]: „Ein Anforderungs-Artefakt ist eine dokumentierte Anforderung“. Immer dann, wenn wir in den folgenden Kapiteln von Anforderungs-Artefakten sprechen, sprechen wir von einer dokumentierten Anforderung. Wenn wir den allgemeineren Begriff „Artefakt“ verwenden, sprechen wir hingegen von dokumentierten Artefakten auf unterschiedlichen Entwicklungsstufen, z.B. Testfälle, Architekturbeschreibungen etc. (vgl. IREB-Glossar [Glin2014]). Requirements Management | Handbook | © IREB 23 | 273 Definition 2-2: Anforderungs-Landschaft: Eine Anforderungs-Landschaft ist eine Festlegung der: 1. zu verwendenden Klassifizierung in Bezug auf die Anforderungsarten 2. zu verwendenden Klassifizierung in Bezug auf die Lösungsunabhängigkeit der Anforderung 3. notwendigen Abstraktionsebenen (Detaillierungsebenen) je Anforderungs-Artefakt-Typ 4. zu verwendenden Darstellungsformen je Anforderungs-Artefakt-Typ In den folgenden Abschnitten gehen wir auf die unterschiedlichen Dimensionen der Anforderungs-Landschaft ein und geben Hinweise, an welcher Stelle sich ein Requirements Manager Gedanken machen muss, um ein „Requirements-Information-Model“ (RIM) zur Beschreibung der Anforderungslandschaft zu erstellen. 2.1 Grundlagen (Klassifizierung von Anforderungen) Wenn wir von Anforderungen sprechen, sprechen wir oftmals von den unterschiedlichsten Ausprägungen einer Anforderung. Eine Anforderung kann sich beispielsweise durch ihren Detaillierungsgrad unterscheiden. So können Anforderungen sehr detailliert und konkret eine Funktion beschreiben oder aber auch eine sehr abstrakte Forderung an das Gesamtsystem sein. Neben ihrem Detaillierungsgrad können sich Anforderungen in ihrer Art des Inhalts unterscheiden. So kann eine Anforderung die Qualität eines Systems (z.B. Korrektheit) beschreiben oder aber funktionale Eigenschaften fordern. Darüber hinaus können sich Anforderungen in ihrer Lösungsunabhängigkeit unterscheiden, z.B. generischen Produktzielen stehen beispielsweise Anforderungen an die Datenstruktur gegenüber. Dies ist grundsätzlich nicht neu und bereits im Certified Professional for Requirements Engineering – Foundation Level angerissen worden [IREB2015]. Zur besseren Orientierung und zum gezielten Aufbau Ihrer Anforderungslandschaft wollen wir Anforderungen aus diesem Grund nach den folgenden Dimensionen klassifizieren: ▪ nach ihrer Anforderungsart ▪ nach ihrer Lösungsunabhängigkeit ▪ nach ihrer Detaillierungsebene (bzw. Abstraktionsebene) Die genannten Dimensionen sind orthogonal zueinander, d.h. auch auf einer Ebene mit einem hohen Detaillierungsgrad gibt es beispielsweise Ziele – also lösungsunabhängige Anforderungen. Requirements Management | Handbook | © IREB 24 | 273 2.1.1 Klassifizierung nach Anforderungsarten Eine Frage, die im Rahmen des Anforderungsmanagements sehr häufig gestellt wird ist: „Welche Arten von Anforderungen sind für die Erhebung und Dokumentation zu berücksichtigen?“. Diese Frage lässt sich mit einem kurzen Rückblick auf den Certified Professional for Requirements Engineering – Foundation Level beantworten [IREB2015]. ▪ Funktionale Anforderungen: Funktionale Anforderungen beschreiben die Funktionalität, die das geplante System bereitstellen soll. Diese Anforderungen beschreiben, was das geplante System leisten soll, z.B. mit welchen Daten sich ein Kunde am Geldautomaten autorisieren muss, um eine Geldabhebung zu autorisieren. Definition 2-3: Funktionale Anforderung nach [PoRu2015]: „Eine funktionale Anforderung ist eine Anforderung bezüglich des Ergebnisses eines Verhaltens, das von einer Funktion des Systems bereitgestellt werden soll.“ ▪ Qualitätsanforderungen: Qualitätsanforderungen beschreiben gewünschte Qualitäten des geplanten Systems und beeinflussen dadurch die Systemarchitektur. Diese Klasse beschreibt bspw. Anforderungen an die Zuverlässigkeit, Sicherheit, Skalierbarkeit oder Performanz des geplanten Systems bzw. einzelner Funktionen. Definition 2-4: Qualitätsanforderung nach [PoRu2015]: „Eine Qualitätsanforderung ist eine Anforderung, die sich auf ein Qualitätsmerkmal bezieht, das nicht durch funktionale Anforderungen abgedeckt wird.“ ▪ Randbedingungen: Randbedingungen sind organisatorische, gesetzliche oder technische Vorgaben (i.d.R. Einschränkungen) zur Realisierung des geplanten Systems. Dies können unterschiedlichste Bedingungen sein – angefangen von zeitlichen Vorgaben zur Umsetzung bis hin zu konkreten Technologievorgaben für die Umsetzung. Requirements Management | Handbook | © IREB 25 | 273 Definition 2-5: Randbedingung nach [PoRu2015]: „Eine Randbedingung ist eine Anforderung, die den Lösungsraum jenseits dessen einschränkt, was notwendig ist, um die funktionalen Anforderungen und die Qualitätsanforderungen zu erfüllen.“ Die Spezifika der verschiedenen Anforderungsarten sowie deren weitergehende Kategorisierung werden in der Literatur ausführlich behandelt (vgl., [Pohl2010], [PoRu2015]und [Eber2012]). Neben der oben eingeführten Klassifikation von Anforderungen findet man in der Requirements-Engineering-Literatur noch einige weitere Klassifikationen, für die häufig ein Bezug zu den drei oben genannten Anforderungsarten hergestellt werden kann, z.B.: ▪ [RuSo2009]: funktionale Anforderungen, technologische Anforderungen, Qualitätsanforderungen, Anforderungen an die Benutzeroberfläche, Anforderungen an sonstige Lieferbestandteile, Anforderungen an durchzuführende Tätigkeiten, rechtlich-vertragliche Anforderungen. ▪ [WiBe2013]: Business-Anforderungen, Businessregeln, Randbedingungen, Schnittstellenanforderungen, Features, funktionale Anforderungen, nicht-funktionale Anforderungen, Qualitätsanforderungen, System-Anforderungen, Benutzer- Anforderungen. ▪ [RoRo2014]: funktionale Anforderungen, nicht-funktionale Anforderungen, Randbedingungen. ▪ [Youn2014]: Business-Anforderungen, Benutzer-Anforderungen, Produkt- Anforderungen, Umgebungs-Anforderungen, System-Anforderungen, funktionale Anforderungen, Performance-Anforderungen, Interface-Anforderungen usw. Entscheidend für ein gutes Anforderungsmanagement ist allerdings nicht, nach welcher Klassifizierung Sie Anforderungen unterscheiden, sondern vielmehr das Bewusstsein um die Existenz verschiedener Anforderungsarten, die zur vollständigen Beschreibung der gewünschten Änderung oder des geplanten Systems berücksichtigt werden müssen. Keine der in diesem Kapitel vorgestellten Anforderungsarten stellt einen allgemeingültigen Standard dar. Die Aufstellung soll Ihnen lediglich die Bandbreite an Anforderungsarten aufzeigen, die sich über die letzten Jahre etabliert haben. Requirements Management | Handbook | © IREB 26 | 273 2.1.2 Klassifizierung nach Lösungsabhängigkeit von Anforderungen Unabhängig von der Anforderungsart weisen Anforderungen häufig eine sehr unterschiedliche Lösungsabhängigkeit auf. So finden wir in Anforderungsbeschreibungen häufig eine Vermischung von: ▪ Zielen, die durch ein System erreicht werden sollen (i.d.R. nahezu lösungsunabhängige Beschreibung des zu erreichenden Ziels, z.B. einfacher und sicherer Zugang zu Bargeld für alle Bankkunden). ▪ Systemabläufe bzw. Prozesse, die durch ein System unterstützt werden sollen (i.d.R. nur indirekter Lösungsbezug durch fachliche Vorgaben zum gewünschten Systemverhalten oder Prozessablauf, z.B. Beschreibung eines Ablaufs zur Authentifizierung am Bankautomaten). ▪ Konkrete Eigenschaften und Merkmale, die ein System erfüllen soll (i.d.R. direkte Lösungsabhängigkeit durch fachliche und operative Vorgaben zum gewünschten System, z.B. eindeutige Festlegung der relevanten Daten zur Authentifizierung eines Benutzers am Bankautomaten). Für eine bewusste Unterscheidung der Anforderungen mit unterschiedlicher Lösungsabhängigkeit empfehlen wir die explizite Klassifizierung von Anforderungs- Artefakten in Abhängigkeit zum Lösungsbezug bzw. der Lösungsabhängigkeit, z.B. in Ziele, Szenarien und lösungsabhängige Anforderungen (vgl. [Pohl2010]). Zielorientierte Beschreibungen (Ziele): ▪ Zielorientierte Beschreibungen dokumentieren (durch Ziele) die Intention des Systems, ohne dabei auf die Umsetzung (Lösung) einzugehen. Sie sind damit die abstrakteste Form einer dokumentierten Anforderung und fordern bspw., dass ein Kunde in jeder deutschen Stadt Geld von seinem Konto abheben können muss – unabhängig davon wie das umgesetzt werden kann. ▪ Ziele lassen sich beispielsweise rein textuell in natürlicher Sprache, durch Und-Oder- Bäume oder eigenständige Notationen wie z.B. i* (I-Star) beschreiben. Unabhängig von der Darstellungsform geht es bei Zielen aber vor allem darum, ein Systemverständnis zu erlangen, um so den benötigten Mehrwert des geplanten Systems zu erkennen. Szenario-orientierte Beschreibungen (Szenarien): ▪ Szenario-orientierte Beschreibungen dokumentieren (durch Szenarien) auf eine beispielhafte Art und Weise den gewünschten zu unterstützenden Ablauf aus Benutzersicht (teilweise auch aus Systemsicht). Szenarien beschreiben somit mögliche Interaktionsfolgen zur Erfüllung eines oder mehrerer Ziele. Szenarien geben hierbei oftmals den für die Anforderung notwendigen Kontext mit, indem sie bspw. den Ablauf einer Geldabhebung an einem Geldautomaten beschreiben. Szenarien umfassen aus diesem Grund in der Regel mehrere atomare Anforderungen. Requirements Management | Handbook | © IREB 27 | 273 ▪ Szenarien lassen sich beispielsweise rein textuell als eine Art Geschichte durch strukturierte Vorlagen (z.B. Use Case Templates), aber auch modellbasiert durch Aktivitätsdiagramme, Geschäftsprozessmodelle (z.B. BPMN), Sequenzdiagramme etc. beschreiben, siehe IREB CPRE Modul "Requirements Modeling" CHQW2022. Lösungsorientierte Beschreibungen (lösungsorientierte Anforderungen): ▪ Lösungsorientierte Beschreibungen dokumentieren (durch lösungsorientierte Anforderungen) konkrete Anforderungen z.B. an die Funktionalität oder Performanz eines Systems oder einzelner Komponenten. Sie beschreiben die zur Erfüllung der Ziele und zur Umsetzung der Szenarien notwendigen Daten, Funktionen, Systemverhalten, Zustände sowie die erforderliche Qualität. Sie sind damit als die „klassischen“ Anforderungen zu verstehen, die in eine Lösung münden müssen, z.B. „Das System muss dem Kunden nach einer erfolgreichen Autorisierung die Möglichkeit geben, Bargeldbeträge zwischen 50 € und 500 € abzuheben. Der ausgewählte Betrag muss glatt durch 10 € dividierbar sein, um eine Auszahlung zu ermöglichen“. ▪ Lösungsorientierte Anforderungen lassen sich entweder natürlich-sprachlich als klassische textuelle Anforderung oder über modellbasierte Notationen (z.B. UML) beschreiben. Lösungsorientierte Anforderungen umfassen in der Regel alle Anforderungen an die klassischen System-Sichten: Daten, Funktionen und Verhalten des geplanten Systems. Sie sind damit die konkretesten Beschreibungen, siehe IREB CPRE Modul "Requirements Modeling" CHQW2022. 2.1.3 Detaillierungsebenen für Anforderungen – Twin-Peaks- Model Die Detaillierung von Anforderungen ist in der Praxis nur sehr selten ein strikt sequenzieller (Wasserfall-)Prozess, der mit grobgranularen Anforderungs-Artefakten startet und diese dann schrittweise zu feingranularen Anforderungs-Artefakten macht, auf Basis derer dann im nächsten Schritt eine Systemarchitektur erstellt wird. In der Praxis gibt es in der Regel bereits zum Start auf der einen Seite sehr unterschiedliche detaillierte Anforderungen und auf der anderen Seite ein frühzeitiges Zusammenspiel von Anforderungen und Systemarchitektur, sodass es eine gegenseitige Beeinflussung von Systemarchitektur- bzw. Lösungsentscheidungen und Anforderungen gibt. Requirements Management | Handbook | © IREB 28 | 273 Abbildung 1: Twin-Peaks-Model Abbildung 1 verdeutlicht diesen Zusammenhang im sogenannten Twin-Peaks-Model [Nuse2001]. Die vertikale Achse stellt den Detaillierungsgrad der Anforderungen bzw. der Systemarchitektur dar, während die horizontale Achse die Lösungsabhängigkeit darstellt, d.h. die zunehmende Ausrichtung von der Problembeschreibung zur Implementierung. Die Abbildung zeigt, dass iterativ eine detaillierter werdende Anforderungsbeschreibung (links im Bild) und parallel dazu eine immer detaillierter werdende Systemarchitektur (rechts im Bild) entstehen und sich beide gegenseitig ergänzen. Auch wenn die Abbildung vereinfacht die gleichen Ebenen für die Detaillierung von Anforderungen und für die Systemarchitektur zeigt, sind hier durchaus unterschiedliche Detaillierungsebenen möglich. Die Abbildung soll im Wesentlichen die Notwendigkeit von unterschiedlichen Detaillierungsebenen für die Dokumentation von Anforderungen aufzeigen (vgl. auch [BBHK2014]). Eine allgemeine Einigkeit, wie viel Detaillierungsebenen auf der Anforderungsseite notwendig und sinnvoll sind, existiert leider nicht. Die notwendige Detaillierung für Anforderungen hängt von vielen Faktoren ab, wie die folgenden Beispiele verdeutlichen sollen: ▪ Systemkontext und Domäne: Soll innerhalb einer wohlbekannten Systemumgebung nur eine kleine Änderung durchgeführt werden, kann ein geringerer Detailgrad notwendig sein als bei einer vollständigen Neuentwicklung. Requirements Management | Handbook | © IREB 29 | 273 ▪ Expertise und Nähe der Beteiligten: In einem Projektumfeld mit erfahrenen und eingespielten Requirements Engineers, Architekten, Entwicklern und Testern ist oftmals eine geringere Detailstufe notwendig als bei einem verteilten Projektteam und Entwicklungsteam mit Lieferantenbeziehungen. ▪ Akzeptierte Freiheitsgrade in der Umsetzung: In einem Projektumfeld, in dem Auftraggeber und Stakeholder rein ergebnisorientiert denken und die Art und Weise wie das Ergebnis erreicht wird unerheblich ist (z.B. Darstellung der Kontobewegungen), muss der Lösungsraum durch Anforderungsdetaillierungen weniger eingeschränkt werden als in einem sicherheitskritischen Umfeld (z.B. Autorisierung beim Login). Die Anzahl der Detaillierungsebenen bzw. der Detailierungsgrad der Anforderungen ist aus diesem Grunde individuell festzulegen (z.B. projektspezifisch). Dieser kann sich sogar in Abhängigkeit des betrachteten Systemgegenstands innerhalb eines Projektes unterscheiden. Grundsätzlich gilt, dass eine Anforderung so weit detailliert wird, bis: ▪ Bei allen Stakeholdern ein gemeinsames Verständnis bezüglich der Anforderungen erreicht wurde und jedem bewusst ist, was exakt gefordert wird. Dies gilt vor allem für den Stakeholder-Kreis, der die Anforderung umsetzen soll. ▪ Die verbleibenden Freiheitsgrade für die Konstruktion der Lösung so gering sind, dass eine weitere Präzisierung mehr Kosten als Nutzen verursachen würde. Also Detaillierung der Anforderungen bis ein akzeptiertes Restrisiko besteht, dass sich aufgrund noch verbleibender Freiheitsgrade eine nicht gewünschte Lösung ergibt. ▪ Die Anforderungen soweit spezifiziert sind, dass die spätere Lösung mittels der vorliegenden Anforderungen eindeutig überprüfbar (testbar) ist, sprich, dass eine Abnahme auf Basis der Spezifikation erfolgen kann. Hinweis: in vielen Projekten haben sich drei Detaillierungsebenen bewährt – auch wenn diese in der Regel immer anders benannt sind, scheint dies ein praktikables Level zu sein (z.B. Ebene der Produkt-Anforderungen, Ebene der Benutzer-Anforderungen, Ebene der System- Anforderungen). Die Literatur bietet darüber hinaus eine Reihe von Vorschlägen zur Strukturierung der Anforderungen auf unterschiedlichen Detaillierungsebenen. ▪ [WiBe2013] schlagen die Unterteilung in „Business-Requirements“, „User Requirements“ und „System Requirements“ vor. [Eber2012] verfolgt die Detaillierung von Anforderungen über die Aufteilung nach Markt-, Produkt- und Komponentenanforderungen. ▪ [RuSo2009] beschreiben fünf Detaillierungsebenen vom groben Gesamtvorhaben mit seinen Zielen bis hin zur technischen Spezifikation und der Trennung in Hardware, Software und sonstigen Komponenten. ▪ [PHAB2012] definieren drei Detaillierungsebenen für die Domäne von eingebetteten softwareintensiven Systemen (Embedded Systems) „Functional Layer“, „Logical Layer“ und „Technical Layer“. Requirements Management | Handbook | © IREB 30 | 273 ▪ [BBHK2014] beschreiben ebenfalls drei Detaillierungsebenen „System Layer“, „Function Group Layer“, „Hardware/Software Layer“ für die Detaillierung von Anforderungen bei software-intensiven eingebetteten Systemen. 2.2 Darstellungsformen zur Dokumentation von Anforderungen Für die Dokumentation von Anforderungen existiert eine Vielzahl unterschiedlicher Darstellungsformen (bzw. Beschreibungsformen). Welche Darstellungsform für die Dokumentation von Anforderungen verwendet wird, hängt von unterschiedlichen Faktoren ab, z.B.: ▪ Zweck der Dokumentation (z.B. formale Prüfung, Review, Diskussion), ▪ Adressat der Information (z.B. Produktmanager, Architekt, Tester, Entwickler), ▪ Klassifizierung der Anforderung (z.B. Anwendungsfall, Performanz-Anforderung). Darüber hinaus ist die gewählte Darstellungsform ebenfalls von der Erfahrung und den persönlichen „Vorlieben“ desjenigen, der die Anforderung dokumentiert, abhängig. Nachfolgend wollen wir folgende Darstellungsformen zur Dokumentation unterscheiden: ▪ Textuelle Darstellung von Anforderungen durch natürliche Sprache. Natürliche Sprachen (z.B. Deutsch, Englisch, Spanisch) sind Sprachen, die im täglichen Gebrauch verwendet werden, um Informationen zu dokumentieren und auszutauschen. Bei textuellen Beschreibungen finden wir beispielsweise folgende Darstellungsformen für Anforderungen: ▪ Prosa in Reinform ▪ Satzschablonen (z.B. „DAS SYSTEM muss/sollte/wird PROZESSWORT“) ▪ Vorlagen zur Strukturierung (z.B. zur Beschreibung von Anwendungsfällen) ▪ Modellbasierte Darstellung von Anforderungen durch Modellierungssprachen: Modellierungssprachen gehören im Vergleich zu natürlichen Sprachen zu den künstlich erschaffenen Sprachen. Modellierungssprachen zur Dokumentation von Anforderungen sind beispielsweise: ▪ Unified Modeling Language (UML) ▪ Business Process Model and Notation (BPMN) ▪ Ereignisgesteuerte Prozesskette (EPK) ▪ System-Modellierungssprache (SysML) ▪ Entity-Relationship Model (ERM) ▪ Petri-Netze ▪ Formalisierte Darstellung von Anforderungen durch formale Sprachen: Formale Sprachen gehören ebenfalls zu den künstlich erschaffenen Sprachen. Bei formalen Sprachen steht die Kommunikation in der Regel nicht im Vordergrund, sondern vielmehr die widerspruchsfreie Beschreibung. Zu formalen Sprachen gehören bspw.: ▪ Mathematisch-algebraische Beschreibungen ▪ Beschreibungsformen der Mengenlehre ▪ logische Beschreibungen und Operatoren Requirements Management | Handbook | © IREB 31 | 273 Um die Dokumentation im Rahmen des RE-Prozesses – aber auch um die Verwaltung und Pflege im Rahmen des RM kontrollierbar zu gestalten – sollten Sie als Requirements Manager so früh wie möglich festlegen, welche Anforderungsart mit welcher Lösungsabhängigkeit auf welcher Detaillierungsebene durch welche Darstellungsformen persistiert werden. Legen Sie ebenfalls frühzeitig fest, in welcher Landessprache textuelle und modellbasierte Anforderungen zu dokumentieren sind, um unnötigen doppelten Aufwand für eine spätere Übersetzung zu vermeiden. Hinweis: In der Regel wird die Sprache der Anforderungen durch die Projektsprache oder die Landessprache der beteiligten Stakeholder und Lieferanten mitbestimmt. Eine Festlegung kann aber auch lauten, dass Anforderungen der Fachabteilungen in Deutsch verfasst werden, um eine bessere Beteiligung und Akzeptanz zu erlangen, und System-Anforderungen, die durch einen Lieferanten umgesetzt werden müssen, in Englisch, d.h. die Dokumentationssprache kann abhängig von der Detaillierungsebene unterschiedlich sein. 2.3 Beschreibung einer Anforderungs-Landschaft durch ein Requirements-Information-Model In diesem Kapitel beschreiben wir, wie eine Anforderungs-Landschaft beschrieben und durch ein Requirements-Information-Model (RIM) dokumentiert werden kann. Wie in Definition 2-2 erläutert, legt eine Anforderungs-Landschaft die folgenden Dimensionen fest: ▪ die zu verwendende Klassifizierung in Bezug auf die Anforderungsarten ▪ die zu verwendende Klassifizierung in Bezug auf ihre Lösungsabhängigkeit ▪ die notwendigen Detaillierungsebenen je Anforderungs-Artefakt-Typ ▪ die zu verwendenden Darstellungsformen je Anforderungs-Artefakt-Typ Zur Beschreibung der Anforderungs-Landschaft kann eine tabellarische Auflistung dienen. Hier dokumentieren Sie die unterschiedlichen Dimensionen der Anforderungs-Landschaft (Anforderungsart, Lösungsabhängigkeit, Detaillierungsebenen, Darstellungsform). Tabelle 1 zeigt ein Beispiel für eine Anforderungs-Landschaft. Requirements Management | Handbook | © IREB 32 | 273 Lösungsabhängigkeit Detaillie- Anforderungsart Gering (Ziel) Mittel (Szenario) Hoch (Lösungsorien- rungs- tierte Anf.) ebene Ebene 1: Randbedingung Geschäftsziel N.R. N.R. Geschäfts (textuell) -Ebene Qualitätsanforderun Service- N.R. N.R. g Qualität (textuell) Funktionale N.R. Geschäftsprozess Geschäftsregel Anforderung (BPMN) (textuell) Ebene 2: Randbedingung Usability / N.R. N.R. Benutzbarkeits Benutzer- -Ziel Ebene Qualitätsanforderun N.R. Benutzer-Oberfläche N.R. g (Mock-Up) Funktionale N.R. Nutzer- Nutzer-Anforderung Anwendungsfall (Use Anforderung (textuell, ER- Case Modelle) Diagramme,Vorlagen) Ebene 3: Randbedingung N.R. N.R. Schnittstellen Richtlinien System- Ebene (textuell) Qualitätsanforderun System- N.R. Systemqualität g Qualitätsziel (textuell) (textuell) Funktionale N.R. Systemanwendungsf Schnittstellenanford all (MSC, AD) e-rungen (textuell, Anforderung MSC) Tabelle 1: Beispiel für die Festlegung einer Anforderungs-Landschaft In Spalte 1 sind die Detaillierungsebenen beschrieben (hier Detaillierung 1: Geschäfts-Ebene, Detaillierung 2: Benutzer-Ebene und Detaillierung 3: System-Ebene). In Spalte 2 ist die Klassifizierung nach Anforderungsarten (hier Randbedingung, Qualitätsanforderung und funktionale Anforderung) beschrieben. In den Spalten 3-5 die Lösungsabhängigkeit der Requirements Management | Handbook | © IREB 33 | 273 Anforderung durch die Klassifizierung in (Ziele, Szenarien und lösungsorientierte Anforderungen) beschrieben. Diese Tabelle beschreibt somit alle theoretisch möglichen Kombinationen für Anforderungs-Artefakt-Typen. Über die Zellen können Sie nun auswählen, welche Anforderungs-Artefakt-Typen für Ihre Spezifikation relevant sind bzw. nicht relevant sind (N.R.). Für die relevanten Anforderungskandidaten (Anforderungsklasse) können Sie nun die gewünschten Darstellungsformen je Artefakt-Typ für Ihre Anforderungs-Landschaft festlegen (z.B. Benutzer-Ebene, lösungsorientierte Beschreibung für funktionale Anforderungen erfolgt durch Entity-Relationship Modelle oder in textueller Form). Zusätzlich haben Sie hier noch die Möglichkeit, den ausgewählten Anforderungs-Kandidaten einen dedizierten unternehmensspezifischen Bezeichner zu geben (z.B. Benutzer-Ebene, lösungsorientierte Beschreibung für funktionale Anforderungen = Benutzeranforderungen). Bei der Festlegung der Anforderungs-Landschaft ist immer zwischen dem Nutzen, den eine umfangreichere Anforderungsdokumentation bringt, und den Kosten, die dadurch entstehen, abzuwägen (vgl. [Glin2014], [Davi2005]). So kann es durchaus sein, dass Sie Anforderungen bspw. nur auf zwei Detaillierungsebenen auf Basis von Szenarien und lösungsorientierten Anforderungen beschreiben. Die Festlegung zur Anforderungs-Landschaft sollte allerdings explizit getroffen werden – und nicht irgendwie passieren – und z.B. im RMP dokumentiert werden, sodass für alle Beteiligten klar ersichtlich ist, welche Anforderungs-Artefakt-Typen auf welcher Detaillierungen-Ebene zu dokumentieren sind. Hierzu bietet sich eine tabellarische Beschreibung der Anforderungs-Landschaft an (vgl. Tabelle 1). Neben der tabellarischen Beschreibung ist die Erstellung eines Informationsmodells in Form eines Entity-Relationship Diagramms oder eines Klassendiagramms sinnvoll, um Beziehungen zwischen den Artefakt- Typen auf einer bzw. auf den unterschiedlichen Detaillierungsebenen zu beschreiben. Dieses beschreibende Informationsmodell nennen wir im Folgenden Requirements-Information- Model (RIM). Das Requirements-Information-Model kann neben den oben getroffenen Festlegungen, welche Anforderungsart mit welcher Lösungsabhängigkeit auf welcher Detaillierungsebene durch welche Form dokumentiert wird, um weitere Aspekte erweitert werden: ▪ Welche Attribute werden für welche Artefakt-Typen verwendet? (siehe Kapitel 3) ▪ Welche Sichtenbildung wird unterstützt? (siehe Kapitel 3) ▪ Welche Bewertungskriterien sind für Anforderungen vorgesehen? (siehe Kapitel 4) ▪ Welchen Rollen obliegt die Pflege und Änderung? (siehe Kapitel 5) ▪ Welche Verfolgbarkeits-Beziehungen werden zwischen Anforderungs-Artefakten sowie vor- und nachgelagerten Artefakten dokumentiert? (siehe Kapitel 6) ▪ Wie werden Varianten von Anforderungen dokumentiert? (siehe Kapitel 7) Mit diesen Informationen stellt das Requirements-Information-Model einen wesentlichen Teil des Requirements-Management-Plan (RMP) dar. Aus diesem Grund muss das RIM für alle Stakeholder im Zugriff sein und jederzeit eingesehen werden können. Requirements Management | Handbook | © IREB 34 | 273 In Abbildung 2 zeigen wir das RIM von Peter Reber. Peter Reber hat sein RIM, in ! Anlehnung an Tabelle 1, in drei Detaillierungsebenen unterteilt (Geschäfts- Ebene, Benutzer-Ebene, System-Ebene). Aus den theoretisch 27 möglichen Anforderungs-Artefakt-Typen wurden durch Peter Reber 13 ausgewählt, um die Anforderungen für das neue Banksystem zu spezifizieren. Ziele auf Geschäfts-Ebene (Detaillierungsebene 1) werden in Geschäftsziele, Geschäftsregeln, Service-Qualität und Geschäftsprozesse unterschieden. Geschäftsziele beschreiben hier i.d.R. Randbedingungen, die in der Umsetzung zu berücksichtigen sind, z.B. geplanter Starttermin, Unternehmensrichtlinien etc. Geschäftsprozesse können der Kategorie der Szenarien zugeordnet werden und beschreiben überwiegend funktionale Anforderungen. Die Geschäftsprozesse werden bei Peter durch BPMN beschrieben. Geschäftsregeln beschreiben funktionale Anforderungen auf hoher Ebene, die im Folgenden berücksichtigt werden müssen und den Lösungsraum einschränken. Unter Geschäftsregeln versteht Peter beispielsweise Begrenzungen der Höhe für Online-Überweisungen pro Tag. Abbildung 2: beispielhaftes Requirements-Information-Model Auf der Benutzer-Ebene möchte Peter Benutzbarkeits-Ziele (Usability), Anforderungen an die Benutzer Oberfläche (GUI) sowie Nutzer- Anwendungsfälle und Nutzer-Anforderungen dokumentieren. Nutzer- Requirements Management | Handbook | © IREB 35 | 273 Anwendungsfälle sollen beispielsweise durch Use Case Diagramme und Templates beschrieben werden. Aus lösungsorientierter Sicht werden Benutzer-Anforderungen und Benutzeroberflächen-Anforderungen beschrieben. Hierzu sollen Mock-Ups, textuelle Beschreibungen oder ER-Modelle genutzt werden. Auf der IT-Ebene finden sich Schnittstellen-Richtlinien, System-Qualitätsziele, System-Anwendungsfälle, Schnittstellen-Anforderungen und Systemqualitäts-Anforderungen. Die Darstellungsformen auf der System- Ebene sind stärker an die IT-Entwicklung angelehnt, sodass hier neben textuellen Anforderungen auch modellbasierte Notationen wie Aktivitätsdiagramme und Message-Sequence-Charts (Sequenzdiagramme) zum Einsatz kommen können. Im vorliegenden Modell wurde nur die Dimension der Lösungsabhängigkeit auf unterschiedlichen Detaillierungsebenen beschrieben. Die Dimension der Anforderungsart (Randbedingung, Qualitätsanforderung, funktionale Anforderung), ist in diesem Modell nur strukturell am rechten Rand dargestellt. Die entsprechende Darstellungsform wurde im RIM vollständig außen vorgelassen, da die Darstellung von mehr als zwei Dimensionen schnell unübersichtlich wird. Bei der Verwendung eines Modellierungs-Werkzeugs können Sie hier eventuell verschiedene Sichten auf das Informationsmodell anbieten, um eine Modell-Sicht nicht zu sehr zu überfrachten. Eine weitere Möglichkeit, mehr Details in ein RIM zu bringen, ist die Verwendung von Annotationen an einer Klasse, um die unterschiedlichen Dimensionen an der Klasse zu beschreiben (siehe Abbildung 3). Abbildung 3: Beispiel RIM mit Annotation der Dimensionen-Details Alternativ gibt es neben dem RIM die Möglichkeit, dass die Darstellungsformen oder die Zuordnung zu Detaillierungsebenen über eine zusätzliche tabellarische Beschreibung erfolgt (vgl. Tabelle 1). Requirements Management | Handbook | © IREB 36 | 273 Zur Prüfung des RIM können folgende Kontrollfragen angewendet werden: ▪ Prüfung auf formale Vollständigkeit: Ist für jede Anforderungsklasse ersichtlich, welche Anforderungsart dahintersteht, welche Lösungsabhängigkeit diese Anforderungsklasse hat, auf welcher Detaillierungsebene diese Anforderungsklasse existiert und in welcher Darstellungsform sie dokumentiert wird? ▪ Prüfung auf inhaltliche Zusammenhänge: Ist im RIM klar ersichtlich, welche Detaillierungsebenen existieren und wie diese zusammenhängen? Ist klar ersichtlich wie die Anforderungen auf den verschiedenen Detaillierungsebenen voneinander abhängen? ▪ Prüfung auf Angemessenheit: Ist die Gesamtheit der gewählten Anforderungsklassen geeignet, um hinreichend detaillierte, vollständige und konsistente Anforderungen zu dokumentieren, sodass die nachfolgenden Aktivitäten (z.B. Entwicklung und Test) ihrer Aufgabe vollständig nachkommen können? 2.4 Inhalte für den RMP Mit der Anforderungs-Landschaft erstellen Sie für Ihren RMP einen wesentlichen ersten Bestandteil. Mit der Anforderungs-Landschaft legen Sie fest, welche Anforderungs- Artefakt-Typen Sie berücksichtigen wollen, auf wie vielen Detaillierungsebenen Sie Anforderungen definieren wollen und in welchen Darstellungsformen welche Anforderungs- Artefakt-Typen spezifiziert werden sollen (vgl. Tabelle 1 und Abbildung 2). Durch die Beschreibung der Anforderungs-Landschaft (z.B. durch ein RIM) können Sie über den RMP dafür sorgen, dass alle am Projekt beteiligten Stakeholder ein einheitliches Verständnis bekommen, durch welche Anforderungs-Artefakt-Typen Anforderungen dokumentiert werden, auf welchen Detaillierungsebenen und mittels welcher Darstellungs-Formen Anforderungen dokumentiert werden. 2.5 Vertiefende Literatur [BBHK2014] Braun, P.; Broy, M.; Houdek, F.; Kirchmayr, M.; Müller, M.; Penzenstadler, B.; Pohl, K.; Weyer, T.: Guiding Requirements Engineering for software-intensive embedded systems in the automotive industry. Computer Science - R&D 29(1): 21-43 (2014). [Eber2012] C. Ebert: Systematisches Requirements Engineering. Dpunkt, 4. Auflage, 2012 [CHQW2022] Thorsten Cziharz, Peter Hruschka, Stefan Queins, Thorsten Weyer: Handbuch Requirements Modeling, Aus- und Weiterbildung zum IREB Certified Professional for Requirements Engineering, Advanced Level Requirements. IREB, Version 2.0.0. Juli 2022. [PHAB2012] Pohl, K., Hönninger, H., Achatz, R., Broy, M. (Eds.): Model-Based Engineering of Embedded Systems - The SPES 2020 Methodology, Springer 2012. Requirements Management | Handbook | © IREB 37 | 273 [Pohl2010] K. Pohl: Requirements Engineering: Grundlagen, Prinzipien, Techniken. Springer, 2010. [WiBe2013] K. Wiegers and J. Beatty: Software Requirements. 3rd Edition. Microsoft Press, 2013. Requirements Management | Handbook | © IREB 38 | 273 3 Attributierung und Sichten bei Anforderungen In diesem Kapitel geht es darum, wie das RM Anforderungs-Attribute festlegt und welche in Projekten benötigt werden. Außerdem geht es um das Erstellen, Nutzen und Ändern von Attributierungsschemata und Sichten. Definition 3-1: Ein Attribut ist eine charakteristische Eigenschaft einer Einheit. (aus dem IREB-Glossar [Glin2014]) Der Standard ISO/IEC/IEEE 29148:2011 ISO29148] fügt der Definition eines Attributs noch den Aspekt hinzu, wie Attribute ausgewertet werden: „eine inhärente Eigenschaft oder Charakteristikum einer Einheit, die quantitativ oder qualitativ durch einen Menschen oder automatisiert unterschieden werden kann“. Attribute sind im Zusammenhang mit dem RM also Eigenschaften der Anforderungen, z.B. der Bearbeitungsstatus (Attribut „Status“). Attribute werden als Metainformationen üblicherweise nicht mit der Anforderungsbeschreibung vermischt, sondern getrennt dokumentiert und verwaltet, z.B. in einer tabellarischen Liste von Anforderungen als eigene Spalte und in einer Anforderungsdatenbank als eigenes Feld. Nicht nur textuelle Anforderungen können Attribute haben, sondern auch Elemente eines UML-Modells [CHQW2022]. Trotz Namensgleichheit sind Anforderungs-Attribute nicht synonym zu den Attributen einer Klasse im Klassendiagramm. Diese sind Inhalt der Anforderung, aber keine Metainformation, also keine Anforderungs-Attribute im Sinne dieses Kapitels. Anforderungen aller Arten, Detaillierungsebenen und Typen können Attribute besitzen, manchmal haben sie jedoch nicht dieselben. Auch Änderungsanträge / Change Requests haben Attribute (siehe Kapitel 5). Ganze Dokumente können durch Attribute charakterisiert werden, z.B. einen Status oder eine Versionsnummer. 3.1 Ziele der Attributierung und Beispiele ihrer Verwendung in Managementtätigkeiten Wie die obigen Definitionen andeuten, dienen Attribute im RM dazu, Anforderungen zu kategorisieren und zwar im Hinblick auf Metainformationen, die z.B. für die Release-Planung oder Verwaltung nötig sind. Dadurch können Sie sich einen Überblick über die Anforderungen verschaffen. Gerade bei umfangreichen Projekten überblickt niemand mehr alle Anforderungen. Hier helfen Attribute bei jeder durchzuführenden anforderungsbezogenen Aktivität im Software Engineering, sich auf die wesentlichen Informationen zu konzentrieren, d.h. auf die betroffenen Anforderungen und deren relevante Eigenschaften. Je nach Aktivität interessiert natürlich ein anderer Auszug aus den vorhandenen Informationen. Requirements Management | Handbook | © IREB 39 | 273 Attribute einer Anforderung beantworten typischerweise eine Menge wichtiger Fragen, wie z.B.: „Wer hat eine Anforderung wann das letzte Mal geändert?“ oder „Welche Anforderungen sind für Release 1 geplant?“ oder „Wie viel Aufwand verursacht Release 1 voraussichtlich insgesamt?“. Praktischerweise schreibt man nicht alle eine Anforderung betreffenden Meta-Informationen in ein einziges Freitext-Feld. Jedes Attribut wird in einem eigenen Feld verwaltet. Oft werden hier Wertelisten vorgeben, die für alle Anforderungen einheitlich sind. Beispielsweise das Attribut „Priorität“ lässt sich leichter auswerten, wenn es nur die Werte „gering“, „normal“ und „hoch“ zulässt oder auch eine andere Abstufung bzw. Werteliste. Wäre es ein Freitextfeld, stünden hier Kommentare wie „ziemlich wichtig“ oder „Herr Meier sagt, die Anforderung sei wichtig“. Solche Inhalte unterstützen die Unterscheidung zwischen den wichtigsten und weniger wichtigen Anforderungen nicht gerade! Dies fällt viel leichter, wenn man sich durch einfaches Filtern eine Liste aller als „hoch“ eingestuften Anforderungen anzeigen lassen kann. Welches Format und welche Attributwerte beispielsweise für die Priorität am meisten Sinn machen, hängt u.a. davon ab, welche Sichten und Entscheidungen durch die Prioritäten unterstützt werden sollen (vgl. Kapitel 4). Die Attributierung von Anforderungen hat also zum Ziel, dass Teammitglieder und andere Stakeholder im Rahmen eines Requirements-Engineering-Prozesses strukturiert Informationen zu Anforderungen dokumentieren und auswerten können [Pohl2010]. Welche Attribute benötigt werden und welche Werte dort erlaubt werden, sollte man sich anfangs gut überlegen, da es ist nicht einfach, ein Attributierungsschema nachträglich zu ändern (siehe Kapitel 3.5). Leider gibt es kein Attributierungsschema, das immer und überall ideal passt. Entscheidend ist stets, welche Attribute man später auf welche Weise auswerten möchte. Verschiedene Autoren schlagen unterschiedliche Zusammenstellungen an Attributen vor, die sich nach ihrer Erfahrung praktisch bewährt haben. Zu den wichtigen Anforderungs- Attributen gehören laut CPRE Foundation Level die Attribute in Tabelle 2 und Tabelle 3 [PoRu2015]. Attributtyp Bedeutung Identifikator Kurze, eindeutige Identifikation eines Anforderungs-Artefakts in der Menge der betrachteten Anforderungen Name Eindeutiger, charakteristischer Name Beschreibung Beschreibt in komprimierter Form den Inhalt der Anforderungen Version Aktueller Versionsstand der Anforderung Autor Benennt den/ die Autor/in der Anforderung Quelle Benennt die Quelle bzw. Quellen der Anforderung Requirements Management | Handbook | © IREB 40 | 273 Attributtyp Bedeutung Begründung Beschreibt, weshalb diese Anforderung für das geplante System von Bedeutung ist Stabilität Benennt die voraussichtliche Stabilität der Anforderung. Stabilität ist dabei der Umfang, in dem künftig noch Veränderungen bzgl. dieser Anforderung erwartet werden. Mögliche Unterscheidung: "stabil", "volatil" Kritikalität Im Sinne einer Abschätzung der Schadenshöhe und Eintrittswahrscheinlichkeit Priorität Benennt die Priorität der Anforderung hinsichtlich der gewählten Merkmale zur Priorisierung, z.B. „Bedeutung für die Akzeptanz am Markt“, „Reihenfolge der Umsetzung“, „Schaden bzw. Opportunitätskosten durch Nichtrealisierung“ Tabelle 2: Häufig verwendete Attributtypen [PoRu2015]. Ein weiterer Vorschlag für eine Zusammenstellung von Attributen: Attributtyp Bedeutung Verantwortliche(r) Benennt die Person, Stakeholdergruppe bzw. Organisation(seinheit), die für diese Anforderung inhaltlich verantwortlich ist Anforderungsart Benennt abhängig vom eingesetzten Differenzierungsschema den Typ der Anforderung (z.B. „funktionale Anforderung“, „Qualitätsanforderung“ oder „Randbedingung“) Status bzgl. des Benennt den aktuellen Status des Inhalts der Anforderung, z.B. „Idee“, Inhalts „Konzept“, „detaillierter Inhalt“ Status bzgl. der Benennt den aktuellen Status der Validierung, z.B. „ungeprüft“, „in Überprüfung Prüfung“, „überprüft“, „fehlerhaft“, „in Korrektur“ Status bzgl. der Benennt den aktuellen Status der Abstimmung, z.B. „nicht Einigung abgestimmt“, „abgestimmt“, „konfliktär“ Aufwand Prognostizierter / tatsächlicher Umsetzungsaufwand dieser Anforderung Release Name und / oder Nummer des Releases, in dem die Anforderung umgesetzt werden soll Requirements Management | Handbook | © IREB 41 | 273 Attributtyp Bedeutung Juristische Gibt den Grad der juristischen Verbindlichkeit der Anforderung an, z.B. Verbindlichkeit „muss“, „soll“ und „kann“ Querbezüge Benennt die Beziehungen zu anderen Anforderungen: zum Beispiel wenn bekannt ist, dass die Realisierung dieser Anforderung die vorherige Realisierung einer anderen Anforderung voraussetzt (vgl. Kapitel 6) Allgemeine In diesem Attribut können beliebige, für relevant erachtete Informationen Informationen zu dieser Anforderung dokumentiert werden: zum Beispiel wenn die Abstimmung dieser Anforderung auf dem nächsten Treffen mit dem Auftraggeber vorgesehen ist Tabelle 3: Häufig verwendete Attributtypen [PoRu2015]. Die obige Liste enthält alle der im Standard ISO/IEC/IEEE 29148:2011 ISO29148 genannten Attribute und enthält darüber hinaus noch weitere Attribute. Für die Dokumentation der Verfolgbarkeit wäre es zusätzlich zur Dokumentation der Quelle noch nützlich, in einem weiteren Attribut zu dokumentieren, in welcher technischen Komponente eine Anforderung umgesetzt wurde (Attribut „technische Komponente“) und durch welche Testfälle die Anforderung getestet wird (Attribut „Testfälle“) (vgl. Kapitel 1). Ein weiteres Attributierungsschema mit 7 Attribut-Kategorien empfiehlt Pohl [Pohl2010]. Dieses unterscheidet die Kategorien „Identifizierbarkeit“, „Kontextbeziehungen“, „Dokumentationsaspekte“, „Inhaltsaspekte“, „Übereinstimmungsaspekte“, „Validierungsaspekte“ und „Managementaspekte“. Jede der genannten Kategorien enthält eine Reihe von möglichen Attributen. ▪ Identifizierbarkeit: Dies sind diejenigen Attribute, welche die Identifizierbarkeit eines Attributs ermöglichen. Dazu gehören die ID und der Name, der möglichst sprechend den Inhalt der Anforderung beschreibt. ▪ Kontextbeziehungen: Diese Attribute dokumentieren die Beziehungen der Anforderungen zum Kontext, z.B. die Quelle, die Begründung, außerdem die verantwortliche Person und evtl. betroffene Stakeholder, mit denen man eine Anforderungsänderung abstimmen müsste. ▪ Dokumentationsaspekte: Hier wird abgelegt, in welcher Darstellungsform eine Anforderung spezifiziert wird (Freitext, UML-Modell, Textschablone, etc.), ein Link zu einem Dokument, in dem die Spezifikationsregeln abgelegt sind, und der Validierungsstatus der Anforderung(sdokumentation) (z.B. ungeprüft / in Prüfung / partiell geprüft / überprüft / in Korrektur / freigegeben). ▪ Inhaltsaspekte: Diese Attribute dokumentieren und klassifizieren die Inhalte der Anforderung. Dazu gehören insbesondere die Beschreibung, aber auch die Anforderungsart, Anmerkungen des Erstellers, der Status des Inhalts (Idee / grober Requirements Management | Handbook | © IREB 42 | 273 Inhalt / detaillierter Inhalt) und Querbezüge zu anderen Entwicklungs-Artefakten (Verfolgbarkeits-Beziehungen). ▪ Übereinstimmungsaspekte: Diese Attribute dokumentieren die Übereinstimmung der Stakeholder, z.B. einen Übereinstimmungsstatus (nicht bekannt / konfliktär / in Übereinstimmung / übereingestimmt), einen Validierungsstatus der Übereinstimmung (ungeprüft / in Prüfung / partiell geprüft / überprüft / in Korrektur / freigegeben), ein Freitextfeld jeweils für erkannte Konflikte und Entscheidungen. ▪ Validierungsaspekte: Die Validierung überprüft die Qualität einer Anforderung im Hinblick auf die drei Dimensionen Inhalt, Dokumentation und Übereinstimmung. Hier kann dokumentiert werden: Konformität zu Eingangskriterien der Validierung (d.h.: Kann mit der Validierung begonnen werden?), Techniken zur Validierung, aktueller Validierungsschritt, Status der Validierung insgesamt (ungeprüft / in Prüfung / partiell geprüft / überprüft / in Korrektur / freigegeben). ▪ Managementaspekte: Diese Attribute dokumentieren den Status einer Anforderung und andere Managementinformationen. Dazu gehören Stabilität, Kritikalität und Priorität, juristische Verbindlichkeit und weitere Status-Informationen. Auch der Autor der Anforderung, Version, Änderungshistorie, System-Release, Soll- und Ist- Aufwand. Tipp aus der Praxis: Überlegen Sie sich frühzeitig ganz genau, welche Attribute Ihr Attributierungsschema enthalten soll, um spätere Änderungen möglichst zu vermeiden. Fügen Sie nur solche Attribute dem Attributierungsschema hinzu, die zwei Kriterien erfüllen: (1) Sie sind sicher, dass die zuständige Person während ihres Arbeitsablaufs dieses Attribut pflegen wird; (2) Es ist klar, wer wann welchen Nutzen von diesem Attribut hat, indem er es auswertet. Beide Kriterien müssen erfüllt sein, damit sich der Aufwand für die Dokumentation dieser Meta- Information lohnt. 3.2 Was ist ein Attributierungsschema? Definition 3-2: „Die Menge aller definierten Attribute für eine Klasse von Anforderungen (z.B. funktionale Anforderungen, Qualitätsanforderungen) wird als das Attributierungsschema bezeichnet.“ ([PoRu2015], Kap. 8.1.2) Ein Attributierungsschema beschreibt die für ein Projekt und/oder ein Unternehmen relevanten Attribute für Anforderungen [RuSo2009]. Zum Attributierungsschema gehören außer den Namen und der Definition der Attribute auch deren Format (Text oder Zahl? Wie viele Zeichen darf das Attribut haben?) und die Festlegung der erlaubten Werte bzw. Wertebereiche. Requirements Management | Handbook | © IREB 43 | 273 Ein Attributierungsschema für Anforderungen bereitzustellen (schablonen- bzw. template- basiert), führt zu folgende

IREB CPRE Handbuch für Requirements Management (PDF)

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue