cpre_foundationlevel_handbook_de_v1.1.2 Kapitel1.pdf

1 Einführung und Überblick In diesem Kapitel erfahren Sie, worum es beim Requirements Engineering (RE) geht und welchen Wert RE mit sich bringt. 1.1 Requirements Engineering: Was Seit Beginn der menschlichen Evolution hat der Mensch technische und organisatorische Systeme aufgebaut, die ihn bei der...

1 Einführung und Überblick In diesem Kapitel erfahren Sie, worum es beim Requirements Engineering (RE) geht und welchen Wert RE mit sich bringt. 1.1 Requirements Engineering: Was Seit Beginn der menschlichen Evolution hat der Mensch technische und organisatorische Systeme aufgebaut, die ihn bei der Erfüllung von Aufgaben oder beim Erreichen von Zielen unterstützen. Mit dem Aufkommen des Ingenieurwesens haben die Menschen auch begonnen, Systeme zu bauen, die menschliche Aufgaben automatisieren. Wann immer sich Menschen entscheiden, ein System zur Unterstützung oder Automatisierung menschlicher Aufgaben zu bauen, müssen sie sich überlegen, was gebaut werden soll. Das bedeutet, dass sie die Wünsche und Bedürfnisse der Personen oder Organisationen kennen lernen müssen, die das System nutzen, von ihm profitieren oder von ihm beeinflusst werden. Mit anderen Worten, sie müssen über die Anforderungen für dieses System Bescheid wissen. Anforderungen bilden die Grundlage für jede Entwicklung oder Weiterentwicklung von Systemen oder Teilen davon. Anforderungen bestehen immer, auch wenn sie nicht explizit erfasst und dokumentiert werden. Der Begriff Anforderung umfasst drei Bedeutungen [Glin2020]: Definition 1.1. Requirement: 1. A need perceived by a stakeholder. 2. A capability or property that a system shall have. 3. A documented representation of a need, capability, or property. Eine systematisch dargestellte Sammlung von Anforderungen - typischerweise für ein System -, die vorgegebene Kriterien erfüllt, wird als Anforderungsspezifikation bezeichnet. Wir unterscheiden zwischen drei Arten von Anforderungen: ▪ Funktionale Anforderungen betreffen ein Ergebnis oder Verhalten, das durch eine Funktion eines Systems bereitgestellt werden soll. Dazu gehören Anforderungen an Daten oder die Interaktion eines Systems mit seiner Umgebung. ▪ Qualitätsanforderungen beziehen sich auf Qualitätsaspekte, die nicht durch funktionale Anforderungen abgedeckt sind - wie z.B. Leistung (Performance), Verfügbarkeit, Sicherheit oder Zuverlässigkeit. ▪ Constraints (Randbedingungen) sind Anforderungen, die den Lösungsraum über das hinaus begrenzen, was zur Erfüllung der gegebenen funktionalen Anforderungen und Qualitätsanforderungen notwendig ist. Foundation Level | Handbuch | © IREB 10 | 174 Beachten Sie, dass der Umgang mit Anforderungen an Projekte oder Entwicklungsprozesse außerhalb des Rahmens dieses Handbuchs liegt. Die Unterscheidung zwischen funktionalen Anforderungen, Qualitätsanforderungen und Randbedingungen ist nicht immer einfach. Eine bewährte Methode, zwischen ihnen zu unterscheiden, besteht darin, nach dem Belang zu fragen, auf den sich eine Anforderung bezieht: Wenn sich der Belang auf erforderliche Ergebnisse, Verhalten oder Interaktionen bezieht, handelt es sich um eine funktionale Anforderung. Wenn es sich um ein Qualitätsmerkmal handelt, das durch die funktionalen Anforderungen nicht abgedeckt ist, handelt es sich um eine Qualitätsanforderung. Wenn sich der Belang auf die Beschränkung des Lösungsraumes bezieht, aber weder eine funktionale noch eine Qualitätsanforderung ist, handelt es sich um eine Randbedingung. Die beliebte Regel „Was das System tun soll → Funktionsanforderung vs. wie das System es tun soll → Qualitätsanforderung” führt häufig zu Fehlklassifikationen, insbesondere wenn Anforderungen sehr detailliert spezifiziert sind oder wenn Qualitätsanforderungen sehr wichtig sind. Beispielsweise ist die Anforderung „Das Kundenerfassungsformular muss Felder für den Namen und Vornamen des Kunden enthalten, die bis zu 32 Zeichen pro Feld umfassen, mindestens 24 Zeichen anzeigen, linksbündig, mit einer Schriftart von 12 pt. sanserif” eine funktionelle Anforderung, obwohl sie viele Informationen über das Wie enthält. Betrachten Sie als weiteres Beispiel ein System, das die vom Detektor eines Hochenergieteilchenbeschleunigers erzeugten Messdaten verarbeitet. Solche Detektoren produzieren enorme Datenmengen in Echtzeit. Wenn Sie einen Physiker fragen: „Was soll das System tun?", wäre eine der ersten Antworten wahrscheinlich, dass das System in der Lage sein muss, die anfallende Datenmenge zu bewältigen. Anforderungen bezüglich Datenvolumen oder Verarbeitungsgeschwindigkeit sind jedoch Qualitätsanforderungen [Glin2007] und keine funktionalen Anforderungen. Wenn zur Spezifikation und zum Management von Anforderungen ein systematischer und disziplinierten Ansatz verfolgt wird nennen wir dies Requirements Engineering (RE). Die folgende Definition des Requirements Engineering spiegelt auch wider, warum wir RE durchführen. Definition 1.2. Requirements Engineering (RE): The systematic and disciplined approach to the specification and management of requirements with the goal of understanding the stakeholders’ desires and needs and minimizing the risk of delivering a system that does not meet these desires and needs. Das Konzept der Stakeholder [GlWi2007] ist ein grundlegendes Prinzip des Requirements Engineering (siehe Kapitel 2). Foundation Level | Handbuch | © IREB 11 | 174 Definition 1.3. Stakeholder: A person or organization who influences a system’s requirements or who is impacted by that system. Beachten Sie, dass der Einfluss auch indirekt sein kann. Beispielsweise müssen einige Stakeholder möglicherweise Anweisungen ihrer Vorgesetzten oder Organisationen befolgen. In Anlehnung an die Definition im RE Glossar des CPRE [Glin2020] verwenden wir in diesem Handbuch den Begriff System in einem weiten Sinne: Definition 1.4. System: 1. In general: a principle for ordering and structuring. 2. In engineering: a coherent, delimitable set of elements that—by coordinated action—achieve some purpose. Beachten Sie, dass ein System andere Systeme oder Komponenten als Subsysteme umfassen kann. Die durch ein System erreichten Ziele können erzielt werden durch: ▪ Bereitstellen des Systems an dem/den Ort(en), an dem/denen es eingesetzt wird ▪ Verkauf/Bereitstellung des Systems an seine Benutzer als Produkt ▪ Anbieter zu haben, die den Benutzern die Fähigkeiten des Systems als Dienstleistungen anbieten Daher verwenden wir den Begriff System als Überbegriff, der Produkte, Dienstleistungen, Anwendungen/Apps oder Geräte umfasst. 1.2 Requirements Engineering: Warum Die Entwicklung von Systemen (sowohl der Aufbau neuer als auch die Weiterentwicklung bestehender Systeme) ist ein kostspieliges Unterfangen und stellt ein hohes Risiko für alle Beteiligten dar. Gleichzeitig sind praxisrelevante Systeme zu groß als dass sie von einer einzelnen Person intellektuell erfasst werden könnten. Deshalb haben Experten verschiedene Prinzipien und Praktiken entwickelt, um mit dem Risiko bei der Entwicklung eines Systems und mit der intellektuellen Komplexität von Systemen mit praktischer Relevanz umzugehen. Das Requirements Engineering liefert die Prinzipien und Praktiken für die Anforderungsperspektive. Adäquates Requirements Engineering (RE) fügt dem Prozess zur Entwicklung eines Systems einen Mehrwert [Glin2016], [Glin2008] hinzu: ▪ RE minimiert das Risiko des Scheiterns oder kostspieliger Änderungen in späteren Entwicklungsphasen. Die frühzeitige Erkennung und Korrektur falscher oder fehlender Anforderungen ist wesentlich kostengünstiger als die Korrektur von Fehlern und Foundation Level | Handbuch | © IREB 12 | 174 Nacharbeiten, verursacht durch fehlende oder falsche Anforderungen, in späteren Entwicklungsphasen oder sogar nach der Bereitstellung eines Systems. ▪ RE vereinfacht die intellektuelle Komplexität im Zusammenhang mit dem Verständnis des Problems, das ein System lösen soll und das Nachdenken über mögliche Lösungen. ▪ RE bietet eine geeignete Grundlage für die Einschätzung von Entwicklungsaufwand und -kosten. ▪ RE ist eine Voraussetzung, um das System richtig zu testen. Typische Symptome für mangelhaftes RE sind fehlende, unklare oder falsche Anforderungen, durch: ▪ Entwicklungsteams, die wegen Termindrucks direkt zur Implementierung eines Systems übergehen ▪ Kommunikationsprobleme zwischen den beteiligten Parteien - insbesondere zwischen Stakeholdern und Systementwicklern und zwischen den Stakeholdern selbst ▪ Die Annahme, dass die Anforderungen selbstverständlich sind, was in den meisten Fällen falsch ist ▪ Personen, die RE-Aktivitäten durchführen, ohne über eine angemessene Ausbildung und Fähigkeiten zu verfügen 1.3 Requirements Engineering: Wo Requirements Engineering kann auf Anforderungen an jede Art von System angewendet werden. Der dominierende Anwendungsfall für RE umfasst heutzutage jedoch Systeme, in denen Software eine wesentliche Rolle spielt. Solche Systeme bestehen aus Softwarekomponenten, physischen Elementen (technische Produkte, Computer-Hardware, Geräte (Devices), Sensoren usw.) und organisatorischen Elementen (Personen, Positionen, Geschäftsprozesse, Rechts- und Compliance-Themen). Systeme, die sowohl Software als auch physische Komponenten enthalten, werden als cyber-physische Systeme bezeichnet. Systeme, die Software, Hardware, Menschen und organisatorische Aspekte umfassen, werden als sozio-technische Systeme bezeichnet. Je nach Betrachtungsweise treten die Anforderungen in verschiedenen Formen auf: Systemanforderungen beschreiben, wie ein System an der Schnittstelle zwischen dem System und seiner Umgebung funktionieren und sich so verhalten soll, dass das System die Wünsche und Bedürfnisse der Stakeholder erfüllt. Bei reinen Softwaresystemen sprechen wir von Softwareanforderungen. Stakeholderanforderungen drücken die Wünsche und Bedürfnisse der Stakeholder aus, die durch die Entwicklung eines Systems aus der Perspektive der Stakeholder befriedigt werden sollen. Foundation Level | Handbuch | © IREB 13 | 174 Benutzeranforderungen sind eine Untermenge der Stakeholderanforderungen. Sie umfassen die Wünsche und Bedürfnisse der Benutzer eines Systems. Domänenanforderungen spezifizieren erforderliche Domäneneigenschaften eines soziotechnischen oder cyber-physischen Systems. Geschäftsanforderungen fokussieren auf die Geschäftsziele, Zielsetzungen und Bedürfnisse einer Organisation, die durch den Einsatz eines Systems (oder einer Auswahl mehrerer Systeme) erreicht werden sollen. Mit Ausnahme der Domänenanforderungen entsprechen die oben aufgeführten Erscheinungsformen den im ISO-Standard [ISO29148] definierten Anforderungen. Aufgrund ihrer Bedeutung behandeln wir die Domänenanforderungen als eine eigene Form. Die Rolle und Bedeutung der Domänenanforderungen werden in Kapitel 2.2, Prinzip 4 diskutiert. 1.4 Requirements Engineering: Wie Die Hauptaufgaben im RE sind die Ermittlung (Kapitel 4), Dokumentation (Kapitel 3), Validierung (Kapitel 4.4) und die Verwaltung (Kapitel 6) von Anforderungen. Werkzeugunterstützung (Kapitel 7) kann bei der Erfüllung dieser Aufgaben helfen. Die Anforderungsanalyse und die Lösung von Anforderungskonflikten werden als Teil der Ermittlung betrachtet. Es gibt jedoch keinen allgemeingültigen Prozess, der beschreibt, wann und wie RE bei der Entwicklung eines Systems durchgeführt werden sollte. Für jede Systementwicklung die REAktivitäten benötigt, muss aus einer breiten Palette von Möglichkeiten ein geeigneter REProzess zugeschnitten werden. Zu den Faktoren, die den Zuschnitt beeinflussen, gehören zum Beispiel: ▪ Der gesamte Systementwicklungsprozess - insbesondere linear und planbasiert vs. iterativ und agil ▪ Der Entwicklungskontext - insbesondere die Beziehung zwischen dem Lieferanten, dem/den Kunden und den Benutzern eines Systems ▪ Die Verfügbarkeit und Fähigkeit der Stakeholder Es besteht auch eine wechselseitige Abhängigkeit zwischen den zu erstellenden Anforderungs-Arbeitsprodukten (siehe Kapitel 3.1) und dem zu wählenden RE-Prozess. Weitere Einzelheiten finden sich in Kapitel 5. 1.5 Die Rolle und Aufgaben eines Requirements Engineers In der Praxis haben nur sehr wenige Personen die Berufsbezeichnung Requirements Engineer. Personen agieren in der Rolle eines Requirements Engineers, wenn sie: ▪ Als Teil ihrer Aufgaben Anforderungen ermitteln, dokumentieren, validieren und/oder verwalten Foundation Level | Handbuch | © IREB 14 | 174 ▪ Über fundierte Kenntnisse im Bereich RE verfügen, die es ihnen ermöglichen, REProzesse zu definieren, geeignete RE-Praktiken auszuwählen und diese Praktiken richtig anzuwenden ▪ In der Lage sind, die Lücke zwischen dem Problem und möglichen Lösungen zu überbrücken Die Rolle des Requirements Engineers ist Teil mehrerer von Organisationen festgelegter Aufgabenbereiche. Beispielsweise können Business Analysten, Anwendungsspezialisten, Product Owner, Systemingenieure und sogar Entwickler die Rolle eines Requirements Engineers einnehmen. Wissen und die Fähigkeiten im Bereich des RE sind auch für viele andere Berufsgruppen nützlich - zum Beispiel für Designer, Tester, Systemarchitekten oder CTOs. 1.6 Was über Requirements Engineering zu lernen ist Die Fähigkeiten, die ein Requirements Engineer erlernen muss, bestehen aus verschiedenen Elementen. Die grundlegenden Elemente werden in den folgenden Kapiteln dieses Handbuchs behandelt. Über die technischen und analytischen Fähigkeiten hinaus benötigt ein Requirements Engineer auch so genannte Soft Skills: Die Fähigkeit zuzuhören, zu moderieren, zu verhandeln und zu vermitteln sowie Einfühlungsvermögen für Stakeholder und aufgeschlossen zu sein für die Bedürfnisse und Ideen anderer. RE unterliegt einer Reihe grundlegender Prinzipien, die für alle Aufgaben, Aktivitäten und Praktiken im RE gelten. Diese Prinzipien werden in Kapitel 2 vorgestellt. Anforderungen können in verschiedenen Formen dokumentiert werden. Verschiedene Arbeitsprodukte können in unterschiedlichen Reife- und Detaillierungsgraden erstellt werden, von eher informellen und kurzlebigen bis hin zu sehr detaillierten und strukturierten Arbeitsprodukten, die strengen Repräsentationsvorschriften entsprechen. Es ist wichtig, die für die jeweilige Situation angemessene Dokumentationsform und die richtigen Arbeitsprodukte auszuwählen und die gewählten Arbeitsprodukte fachgerecht zu erstellen. Arbeitsprodukte und Dokumentationspraktiken werden in Kapitel 3 vorgestellt. Anforderungen können mit verschiedenen Praktiken ausgearbeitet (d.h. ermittelt und validiert) werden. Ein Requirements Engineer muss in der Lage sein, die Praktiken auszuwählen, die in einer bestimmten Situation am besten geeignet sind, und diese Praktiken richtig anzuwenden. Die Praktiken für die Erarbeitung von Anforderungen werden in Kapitel 4 vorgestellt. Durch das Verständnis möglicher Prozesse und Arbeitsstrukturen können Requirements Engineers eine Arbeitsweise definieren, die den spezifischen Bedürfnissen der jeweiligen Systementwicklungssituation entspricht. Prozesse und Arbeitsstrukturen werden in 5 vorgestellt. Bestehende Anforderungen können mit unterschiedlichen Praktiken verwaltet werden. Requirements Engineers sollten verstehen, welche Praktiken des Requirements Foundation Level | Handbuch | © IREB 15 | 174 Management sie bei welchen Aufgaben unterstützen. Managementpraktiken werden in Kapitel 6 vorgestellt. Werkzeuge machen RE effizienter. Requirements Engineers müssen wissen, wie REWerkzeuge sie unterstützen können und wie sie ein geeignetes Werkzeug für ihre Situation auswählen. Die Werkzeugunterstützung wird in Kapitel 7 kurz besprochen. 1.7 Weiterführende Literatur Die RE-Fachbegriffe sind im CPRE Wörterbuch der Requirements Engineering Terminologie [Glin2020] definiert. Glinz und Wieringa [GlWi2007] erläutern den Begriff der Stakeholder. Lawrence, Wiegers und Ebert [LaWE2001] diskutieren kurz die Risiken und Fallstricke des RE. Gause und Weinberg [GaWe1989] haben eines der ersten RE-Lehrbücher geschrieben, das noch immer einen Blick wert ist. Pohl [Pohl2010], Robertson und Robertson [RoRo2012]und Wiegers und Beatty [WiBe2013]sind beliebte Lehrbücher zum Thema RE. Die Kursnotizen von Glinz [Glin2019] bieten mittels Folien eine Einführung ins RE. Das Lehrbuch von van Lamsweerde [vLam2009] präsentiert einen zielorientierten Ansatz für das RE. Jackson [Jack1995] trägt eine aufschlussreiche Sammlung von Essays über Softwareanforderungen bei. Bitte beachten Sie, dass das offizielle Lehrbuch für den IREB CPRE Foundation Level Version 2.2 [PoRu2015] nicht mehr vollständig mit der Version 3.0 des CPRE Foundation Level Lehrplans, auf dem dieses Handbuch basiert, abgestimmt ist. Es bietet jedoch immer noch eine kurze Einführung ins RE und wird in Kürze aktualisiert. Es gibt auch Lehrbücher in anderen Sprachen als Englisch. So haben beispielsweise Badreau und Boulanger [BaBo2014] ein RE-Lehrbuch auf Französisch geschrieben. Die Bücher von Ebert [Eber2014] und Rupp [Rupp2014] sind beliebte auf Deutsch verfasste RE-Lehrbücher. Foundation Level | Handbuch | © IREB 16 | 174