cpre_foundationlevel_handbook_de_v1.1.2 Kapitel2.pdf

2 Grundlegende Prinzipien des Requirements Engineering In diesem Kapitel lernen Sie neun Grundprinzipien des Requirements Engineering (RE) kennen. 2.1 Überblick über die Prinzipien RE unterliegt einer Reihe grundlegender Prinzipien, die für alle Aufgaben, Aktivitäten und Praktiken im RE gelten. Eine...

2 Grundlegende Prinzipien des Requirements Engineering In diesem Kapitel lernen Sie neun Grundprinzipien des Requirements Engineering (RE) kennen. 2.1 Überblick über die Prinzipien RE unterliegt einer Reihe grundlegender Prinzipien, die für alle Aufgaben, Aktivitäten und Praktiken im RE gelten. Eine Aufgabe ist ein kohärentes Stück Arbeit, das ausgeführt werden muss (z.B. das Ermitteln von Anforderungen). Eine Aktivität ist eine Handlung oder eine Reihe von Handlungen, die eine Person oder Gruppe ausführt, um eine Aufgabe zu erfüllen (z.B. die Identifizierung von Stakeholdern bei der Ermittlung von Anforderungen). Eine Praktik ist eine bewährte Methode zur Durchführung bestimmter Arten von Aufgaben oder Aktivitäten (z.B. die Verwendung von Interviews, um die Anforderungen der Stakeholder zu ermitteln). Die in Tabelle 2.1 aufgeführten Prinzipien bilden die Grundlage für die in den folgenden Kapiteln dieses Lehrplans vorgestellten Praktiken. Tabelle 2.1 Neun grundlegende Prinzipien des Requirements Engineering 1. Wertorientierung: Anforderungen sind Mittel zum Zweck, kein Selbstzweck 2. Stakeholder: Im RE geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen 3. Gemeinsames Verständnis: Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich 4. Kontext: Systeme können nicht isoliert verstanden werden 5. Problem - Anforderung - Lösung: Ein unausweichlich ineinandergreifendes Tripel 6. Validierung: Nicht-validierte Anforderungen sind nutzlos 7. Evolution: Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall 8. Innovation: Mehr vom Gleichen ist nicht genug 9. Systematische und disziplinierte Arbeit: Wir können im RE nicht darauf verzichten Foundation Level | Handbuch | © IREB 17 | 174 2.2 Die Erläuterung der Prinzipien 2.2.1 Prinzip 1 - Wertorientierung: Anforderungen sind ein Mittel zum Zweck, kein Selbstzweck Der Akt des Schreibens von Anforderungen ist an sich kein Ziel. Anforderungen sind nur dann nützlich - und der in Requirements Engineering investierte Aufwand ist gerechtfertigt -, wenn sie einen Mehrwert schaffen [Glin2016], [Glin2008], vgl. Kapitel 1.2. Wir definieren den Wert einer Anforderung als ihren Nutzen abzüglich ihrer Kosten. Der Nutzen einer Anforderung ist der Grad, in dem sie zum Aufbau erfolgreicher Systeme (d.h. Systeme, die die Wünsche und Bedürfnisse ihrer Stakeholder erfüllen) und zur Verringerung des Risikos von Fehlschlägen und kostspieligen Nacharbeiten bei der Systementwicklung beiträgt. Die Kosten für eine Anforderung entsprechen den Kosten für ihre Ermittlung, Validierung, Dokumentation und Verwaltung. Die Verringerung des Risikos von Nacharbeiten während der Entwicklung ist ein wesentlicher Bestandteil des Nutzens einer gut ausgearbeiteten Anforderung. Das Aufspüren und Beheben einer vergessenen oder falschen Anforderung während der Implementierung oder wenn das System bereits in Betrieb ist, kann leicht ein oder zwei Größenordnungen mehr kosten als die Anforderung von Anfang an richtig zu spezifizieren. Folglich resultiert ein erheblicher Teil des Nutzens der Anforderungen aus den Kosten, die während der Implementierung und des Betriebs eines Systems eingespart werden. Mit anderen Worten: Die Vorteile von RE sind oft langfristige Vorteile, während die Kosten unmittelbar anfallen. Dies muss bei Beginn eines neuen Projekts berücksichtigt werden. Eine kurzfristige Kostensenkung durch geringere Ausgaben für RE hat einen Preis: Sie erhöht das Risiko teurer Nacharbeiten in späteren Projektphasen erheblich. Der Wert des Requirements Engineering kann als der kumulative Wert der spezifizierten Anforderungen betrachtet werden. Da Kunden in der Regel für die zu implementierenden Systeme, aber nicht für die dafür erforderlichen Anforderungen bezahlen, ist der wirtschaftliche Wert von RE meist ein indirekter. Dieser Effekt wird dadurch verstärkt, dass der Nutzen von Anforderungen, die sich aus reduzierten Nacharbeitskosten ergeben, ein indirekter ist: Er spart Kosten bei der Implementierung und im Betrieb. Die wirtschaftlichen Auswirkungen des Requirements Engineering sind meist indirekter Natur; RE als solches erzeugt nur Kosten. Um den Wert einer Anforderung zu optimieren, müssen Requirements Engineers ein angemessenes Gleichgewicht zwischen dem Nutzen und den Kosten einer Anforderung finden. Beispielsweise erleichtern das Herausfinden und Dokumentieren des Bedarfs eines Stakeholders als Anforderung die Kommunikation dieses Bedarfs unter allen beteiligten Parteien. Dies erhöht die Wahrscheinlichkeit, dass das zu realisierende System dieses Bedürfnis schließlich befriedigen wird, was einen Nutzen darstellt. Je weniger zweideutig und Foundation Level | Handbuch | © IREB 18 | 174 je präziser die Anforderung formuliert ist, desto höher ist ihr Nutzen, denn dadurch verringert sich das Risiko kostspieliger Nacharbeiten aufgrund von Fehlinterpretationen der Anforderungen durch die Systemarchitekten und Entwicklungsteams. Andererseits steigern die Kosten zur Erhöhung des Grades an Eindeutigkeit und Präzision einer Anforderung auch die Kosten, die mit dem Ermitteln und Dokumentieren der Anforderung verbunden sind. Tatsächlich hängt die Menge an RE, die erforderlich ist, um Anforderungen mit optimalem Wert zu erreichen, von zahlreichen Faktoren ab, die durch die spezifische Situation, in der Anforderungen erstellt und verwendet werden, gegeben sind. Es liegt auf der Hand, dass das Risiko ein Systems zu realisieren, das letztendlich nicht den Wünschen und Bedürfnissen der Stakeholder entspricht, was zu Fehlschlägen oder kostspieligen Nachbesserungen führen kann, die treibende Kraft ist, die den Umfang des erforderlichen RE bestimmt. Zuallererst sollte die Kritikalität jeder Anforderung im Hinblick auf die Bedeutung der/des Stakeholder(s), die/der die Anforderung formulieren/formuliert (siehe Prinzip 2), und die Auswirkungen eines Fehlens der Anforderung bewertet werden (Abbildung 2.1). Abbildung 2.1 Beurteilung der Kritikalität einer Anforderung [Glin2008] Darüber hinaus sollten die folgenden Einflussfaktoren berücksichtigt werden: ▪ Erforderlicher Aufwand zur Spezifizierung der Anforderung ▪ Besonderheit der Anforderung (wie sehr sie zum Erfolg des Gesamtsystems beiträgt) ▪ Grad des gemeinsamen Verständnisses zwischen Stakeholdern und Entwicklern und unter den Stakeholdern ▪ Vorhandensein von Referenzsystemen (die als beispielhafte Spezifikation dienen können) ▪ Länge des Feedback-Zyklus (die Zeit zwischen dem Spezifizieren einer falschen Anforderung und dem Erkennen des Fehlers) ▪ Art der Kunden-Lieferanten-Beziehung Foundation Level | Handbuch | © IREB 19 | 174 ▪ Einhaltung gesetzlicher Vorschriften Wir fassen diese Thematik in zwei Faustregeln zusammen: ▪ Der optimale zu investierenden RE-Umfang hängt von der konkreten Situation ab und wird von vielen Einflussfaktoren bestimmt. ▪ Der Aufwand, der in RE investiert wird, sollte umgekehrt proportional zu dem Risiko sein, das Sie bereit sind einzugehen. 2.2.2 Prinzip 2 – Stakeholder: Im RE geht es darum, die Wünsche und Bedürfnisse der Stakeholder zu befriedigen Das letztendliche Ziel des Aufbaus eines Systems besteht darin, dass das System, wenn es benutzt wird, Probleme löst, die seine Benutzer lösen müssen und die Erwartungen weiterer Personen erfüllt, z.B. derjenigen, die das System bestellt und bezahlt haben, oder derjenigen, die in der Organisation, die das System benutzt, für die Sicherheit verantwortlich sind. Deshalb müssen wir die Bedürfnisse und Erwartungen derjenigen herausfinden, die ein Interesse an dem System haben, die Stakeholder des Systems [GlWi2007]. Die Kernziele von RE sind das Verständnis der Wünsche und Bedürfnisse der Stakeholder und die Minimierung des Risikos, ein System zu liefern, das diesen Wünschen und Bedürfnissen nicht gerecht wird; siehe Definition 1.2 in Kapitel 1.2. Jeder Stakeholder hat eine Rolle im Kontext des zu errichtenden Systems, z.B. Benutzer, Kunde, Auftraggeber, Betreiber oder Regulierungsbehörde. Je nach angewendetem REProzess können auch die Entwickler eines Systems Stakeholder sein. Dies ist häufig der Fall bei agiler und marktorientierter Entwicklung. Ein Stakeholder kann auch mehrere Rollen gleichzeitig ausüben. Für jede relevante Stakeholder-Rolle müssen geeignete Personen, die in dieser Rolle agieren als Repräsentanten ausgewählt werden. Für Stakeholder-Rollen mit zu vielen Einzelpersonen oder falls Einzelpersonen unbekannt sind, können Personas (fiktive Charaktere, die eine Gruppe von Benutzern mit ähnlichen Merkmalen repräsentieren) als Ersatz definiert werden. Bei bereits im Einsatz befindlichen Systemen sollten auch solche Benutzer, die Feedback über das System geben oder neue Funktionen anfordern als Stakeholder betrachtet werden. Es ist sinnvoll, die Stakeholder im Hinblick auf den Grad des Einflusses, den ein Stakeholder auf den Erfolg des Systems hat, in drei Kategorien einzuteilen: ▪ Kritisch: Die Nichtberücksichtigung dieser Stakeholder führt zu schwerwiegenden Problemen und lässt das System wahrscheinlich scheitern oder unbrauchbar werden. ▪ Schwerwiegend: Die Nichtberücksichtigung dieser Stakeholder wird sich negativ auf den Erfolg des Systems auswirken, es aber nicht zum Scheitern bringen. ▪ Geringfügig: Die Nichtberücksichtigung dieser Stakeholder wird keinen oder nur einen geringen Einfluss auf den Erfolg des Systems haben. Diese Klassifizierung ist hilfreich bei der Beurteilung der Kritikalität einer Anforderung (siehe Abbildung 2.1) und bei der Konfliktlösung mit Stakeholdern. Foundation Level | Handbuch | © IREB 20 | 174 Es reicht nicht aus, nur die Anforderungen der Endbenutzer und Kunden zu berücksichtigen. Dies würde bedeuten, dass wir kritische Anforderungen von anderen Stakeholdern übersehen könnten, was leicht dazu führen kann, dass Entwicklungsprojekte scheitern oder dass sie ihre Budgets und Fristen überschreiten. Die Einbeziehung der richtigen Personen in die entsprechenden Stakeholder-Rollen ist für erfolgreiches RE von entscheidender Bedeutung. Praktiken zur Identifizierung, Priorisierung und zur Zusammenarbeit mit Stakeholdern werden in Kapitel 4 diskutiert. Stakeholder in verschiedenen Rollen haben naturgemäß unterschiedliche Ansichten [NuKF2003] über ein zu entwickelndes System. Beispielsweise wollen die Benutzer in der Regel, dass ein System ihre Aufgaben optimal unterstützt, die Manager, die das System bestellen, wollen es zu einem vernünftigen Preis erhalten, und der Sicherheitschef der Organisation kümmert sich in erster Linie um die Sicherheit des Systems. Selbst Stakeholder in der gleichen Rolle können unterschiedliche Bedürfnisse haben. In der Gruppe der Endbenutzer haben z.B. Gelegenheitsnutzer Anforderungen an die Benutzeroberfläche, die sich stark von denen der professionellen Benutzer unterscheiden können. Infolgedessen reicht es nicht aus, nur Anforderungen von Stakeholdern zu sammeln. Es ist von entscheidender Bedeutung, Inkonsistenzen und Konflikte zwischen den Anforderungen der verschiedenen Stakeholder zu identifizieren und diese zu lösen, sei es durch Konsensfindung, durch Überstimmung (Ober-sticht-Unter), oder durch die Festlegung von Systemvarianten für Stakeholder die faktisch unterschiedliche Bedürfnisse haben; siehe Kapitel 4.3. 2.2.3 Prinzip 3 – Gemeinsames Verständnis: Erfolgreiche Systementwicklung ist ohne eine gemeinsame Basis nicht möglich Die Systementwicklung, einschließlich des RE, ist ein Vorhaben, an dem mehrere Personen beteiligt sind. Um ein solches Unterfangen zum Erfolg zu führen, brauchen die Beteiligten ein gemeinsames Verständnis des Problems und der daraus resultierenden Anforderungen [GlFr2015]. RE schafft, fördert und sichert ein gemeinsames Verständnis zwischen und innerhalb der beteiligten Parteien: Stakeholder, Requirements Engineers und Entwickler. Wir unterscheiden zwei Formen des gemeinsamen Verständnisses: ▪ Explizites gemeinsames Verständnis wird durch sorgfältig ermittelte, dokumentierte und vereinbarte Anforderungen erreicht. Dies ist das primäre Ziel von RE in planbasierten Prozessen. Foundation Level | Handbuch | © IREB 21 | 174 ▪ Implizites gemeinsames Verständnis basiert auf dem gemeinsamen Wissen über Bedürfnisse, Visionen, Kontext usw. In agilem RE, wenn die Anforderungen nicht vollständig schriftlich spezifiziert sind, ist das Vertrauen in ein gemeinsames implizites Verständnis entscheidend. Sowohl das implizite als auch das explizite gemeinsame Verständnis können falsch sein, d.h. Menschen glauben, dass sie ein gemeinsames Verständnis einer Sache haben, interpretieren diese aber in Wirklichkeit auf unterschiedliche Weise. Deshalb können wir uns nie blind auf ein gemeinsames Verständnis verlassen. Die Aufgabe des RE besteht vielmehr darin, ein gemeinsames Verständnis zu schaffen und zu fördern und dieses auch zu sichern, d.h. zu beurteilen, ob es ein echtes gemeinsames Verständnis gibt. Um den Aufwand zu begrenzen, ist es wichtig sich auf ein gemeinsames Verständnis der relevanten Dinge zu konzentrieren, d.h. jener Aspekte, die innerhalb der Kontextgrenze eines Systems liegen (vgl. Prinzip 4). Selbst bei einem perfekten gemeinsamen Verständnis können wichtige Anforderungen immer noch vergessen werden, weil niemand sie berücksichtigt hat. Abbildung 2.2 veranschaulicht verschiedene Situationen des gemeinsamen Verständnisses anhand eines einfachen Beispiels eines Paares, das in seinem Garten eine Schaukel für seine Kinder installieren möchte [Glin2019]. Die Haftnotiz in der Mitte symbolisiert eine schriftliche Spezifikation. Abbildung 2.2 Verschiedene Situationen des gemeinsamen Verständnisses - illustriert am Beispiel eines Paares, das eine Schaukel für seine Kinder installieren möchte Bewährte Praktiken um ein gemeinsamen Verständnisses zu erzielen, umfassen die Erstellung von Glossaren (Kapitel 3.5), das Erstellen von Prototypen (Kapitel 3.7) oder die Verwendung eines bestehenden Systems als Bezugspunkt. Das Hauptinstrument zur Beurteilung eines echten expliziten gemeinsamen Verständnisses im RE ist die gründliche Validierung aller spezifizierten Anforderungen (vgl. Prinzip 6 und Kapitel 4.4). Zu den Praktiken zur Bewertung des impliziten gemeinsamen Verständnisses gehören das Bereitstellen von Beispielen für erwartete Ergebnisse, das Erstellen von Prototypen, oder die Schätzung der Kosten für die Umsetzung einer Anforderung. Die Foundation Level | Handbuch | © IREB 22 | 174 wichtigste Praktik zur Verringerung der Auswirkungen eines falschen gemeinsamen Verständnisses ist die Anwendung eines Verfahrens mit kurzen Rückkopplungsschleifen (Kapitel 5). Es gibt Faktoren, die ein gemeinsames Verständnis fördern oder behindern. Fördernisse sind zum Beispiel: ▪ Domänen-Wissen ▪ Domänenspezifische Normen ▪ Frühere erfolgreiche Zusammenarbeit ▪ Vorhandensein von Referenzsystemen, die allen Beteiligten bekannt sind ▪ Gemeinsame Kultur und Werte ▪ Informiertes (nicht blindes!) gegenseitiges Vertrauen Hindernisse sind: ▪ Geografische Entfernung ▪ Von gegenseitigem Misstrauen geprägte Lieferanten-Kunden-Beziehung ▪ Outsourcing ▪ Regulatorische Randbedingungen ▪ Große und vielfältige Teams ▪ Hohe Fluktuation unter den beteiligten Personen Je geringer die Wahrscheinlichkeit und die Auswirkungen eines falschen gemeinsamen Verständnisses sind und je besser das Verhältnis zwischen Fördernissen und Hindernissen, desto mehr kann sich RE auf ein implizites gemeinsames Verständnis verlassen. Umgekehrt gilt: Je weniger Fördernisse und je mehr Hindernisse für ein gemeinsames Verständnis wir haben und je höher das Risiko und die Auswirkungen eines falschen gemeinsamen Verständnisses für eine Anforderung sind, desto mehr müssen solche Anforderungen explizit spezifiziert und validiert werden. 2.2.4 Prinzip 4 – Kontext: Systeme können nicht isoliert verstanden werden Anforderungen sind nie isoliert zu betrachten. Sie beziehen sich auf Systeme, die in einen Kontext eingebettet sind. Während der Begriff Kontext im Allgemeinen das Netzwerk von Gedanken und Bedeutungen bezeichnet, das zum Verständnis von Phänomenen oder Äußerungen erforderlich ist, hat er im RE eine besondere Bedeutung. Foundation Level | Handbuch | © IREB 23 | 174 Definition 2.1. Context (in RE): The part of a system’s environment being relevant for understanding the system and its requirements. Der Kontext eines Systems wird durch die Systemgrenze und die Kontextgrenze [Pohl2010] abgegrenzt (siehe Abbildung 2.3). Definition 2.2. Context boundary: The boundary between the context of a system and those parts of the application domain that are irrelevant for the system and its requirements. Die Kontextgrenze trennt den relevanten Teil der Umgebung eines zu entwickelnden Systems vom irrelevanten Teil, d.h. dem Teil, der das zu entwickelnde System nicht beeinflusst und daher beim Requirements Engineering nicht berücksichtigt werden muss. Definition 2.3. System boundary: The boundary between a system and its surrounding context. Die Systemgrenze grenzt das System so ab, wie es nach seiner Implementierung und Bereitstellung sein soll. Die Systemgrenze ist anfangs oft nicht klar und kann sich im Laufe der Zeit ändern. Die Klärung der Systemgrenze und die Definition der externen Schnittstellen zwischen einem System und den Elementen in seinem Kontext, mit denen es interagiert, sind originäre RE-Aufgaben. Die Systemgrenze fällt häufig mit dem Umfang einer Systementwicklung zusammen. Definition 2.4. Scope: The range of things that can be shaped and designed when developing a system. Manchmal stimmen jedoch die Grenze des Systems und sein Umfang nicht überein (siehe Abbildung 2.3). Es kann Komponenten innerhalb der Systemgrenze geben, die so wiederverwendet werden müssen, wie sie sind (d.h. sie können nicht geformt oder gestaltet werden), was bedeutet, dass sie außerhalb des Umfangs liegen. Auf der anderen Seite kann es im Systemkontext Dinge geben, die bei der Entwicklung des Systems neu gestaltet werden können, d.h. sie liegen im Umfang. Foundation Level | Handbuch | © IREB 24 | 174 Da sich die externen Schnittstellen an der Systemgrenze befinden, muss RE bestimmen, welche dieser Schnittstellen in Scope sind (d.h. sie können im Entwicklungsprozess gestaltet und entworfen werden) und welche gegeben sind und aus dem Scope fallen. Es reicht nicht aus, einfach nur die Anforderungen innerhalb der Systemgrenze zu berücksichtigen. Erstens können sich Kontextänderungen innerhalb des Scopes (Umfangs) auf die Anforderungen des Systems auswirken, wenn der Umfang Teile des Systemkontexts umfasst, wie in Abbildung 2.3 dargestellt. Wenn zum Beispiel ein Geschäftsprozess durch ein System teilweise automatisiert werden soll, kann es sinnvoll sein, den Prozess anzupassen, um seine Automatisierung zu vereinfachen. Es liegt auf der Hand, dass eine solche Anpassung Auswirkungen auf die Anforderungen des Systems hat. Abbildung 2.3 System, Kontext und Umfang Zweitens kann es im Systemkontext Phänomene der realen Welt geben, die ein System überwachen oder kontrollieren soll. Anforderungen an solche Phänomene müssen als Domänenanforderungen angegeben und adäquat auf die Systemanforderungen abgebildet werden. Zum Beispiel besteht bei einem Auto, das mit einem Automatikgetriebe ausgestattet ist, die Anforderung, dass die Parkposition nur dann eingelegt werden kann, wenn sich das Auto nicht bewegt. Im Kontext eines Softwaresystems, das das Getriebe steuert, ist dies eine Domänenanforderung. Um diese Anforderung zu erfüllen, muss das Steuerungssystem wissen, ob sich das Auto bewegt oder nicht. Das Steuerungssystem kann dieses Phänomen jedoch nicht direkt wahrnehmen. Daher muss das Phänomen der realen Welt „Auto bewegt sich nicht“ auf ein Phänomen abgebildet werden, das das Steuerungssystem erfassen kann, z.B. den Input eines Sensors, der Impulse erzeugt, wenn sich ein Reifen des Autos dreht. Die Domänenanforderung bezüglich des Einlegens der Parkposition wird dann auf eine Systemanforderung wie „Das Getriebesteuerungssystem darf das Einlegen der Parkposition nur dann ermöglichen, wenn keine Impulse von den Raddrehsensoren empfangen werden“ abgebildet. Drittens kann es Anforderungen geben, die von keiner Systemimplementierung erfüllt werden können, wenn nicht bestimmte Domänenanforderungen und Domänenannahmen im Kontext des Systems gelten. Domänenannahmen sind Annahmen über Phänomene der Foundation Level | Handbuch | © IREB 25 | 174 realen Welt innerhalb des Kontexts eines Systems. Denken Sie zum Beispiel an ein Flugsicherungssystem (FSS). Die Anforderung „A1: Das FSS muss genaue Positionen für alle vom System überwachten Flugzeuge verwalten“ ist eine wichtige Systemanforderung. Diese Anforderung kann jedoch nur erfüllt werden, wenn das Radar im Kontext des FSS die Anforderungen erfüllt, alle Flugzeuge in dem vom Radar überwachten Luftraum korrekt zu identifizieren und ihre Position korrekt zu bestimmen. Diese Anforderungen können wiederum nur erfüllt werden, wenn alle vom Radar entdeckten Flugzeuge auf die vom Radar gesendeten Abfragesignale korrekt reagieren. Darüber hinaus kann die Anforderung A1 nur erfüllt werden, wenn bestimmte Domänenannahmen im Kontext des FSS gelten, z.B., dass das Radar nicht durch einen böswilligen Angreifer blockiert wird und dass kein Flugzeug in einer Höhe fliegt, die niedriger ist als das Radar erfassen kann. RE geht über die Berücksichtigung der Anforderungen innerhalb der Systemgrenze und die Definition der externen Schnittstellen an der Systemgrenze hinaus. RE muss sich auch mit Phänomenen innerhalb des Systemkontexts befassen. Folglich muss RE auch Fragen innerhalb des Systemkontexts berücksichtigen: ▪ Wenn Änderungen innerhalb des Kontexts auftreten können, wie wirken sie sich auf die Anforderungen an das System aus? ▪ Welche Anforderungen im Kontext der realen Welt sind für das zu entwickelnde System relevant? Wie lassen sich solche Anforderungen aus der realen Welt adäquat auf die Anforderungen an das System abbilden? ▪ ▪ Welche Annahmen über den Kontext müssen gelten, damit das System richtig funktioniert und die Anforderungen in der realen Welt erfüllt werden? 2.2.5 Prinzip 5 – Problem - Anforderung - Lösung: Ein unausweichlich ineinandergreifendes Tripel Probleme, ihre Lösungen und Anforderungen sind eng und unausweichlich miteinander verflochten [SwBa1982]. Jede Situation in der Menschen mit der Art und Weise, wie sie Dinge tun, nicht zufrieden sind, kann als das Auftreten eines Problems betrachtet werden. Um dieses Problem zu beseitigen, kann ein sozio-technisches System entwickelt und eingesetzt werden. Die Anforderungen an dieses System müssen erfasst werden, um das System zu einer wirksamen Lösung des Problems zu machen. Anforderungen zu spezifizieren ist sinnlos, wenn es kein Problem zu lösen gibt oder keine Lösung entwickelt wird. Es ist auch sinnlos eine Lösung zu entwickeln, die nach einem zu lösenden Problem oder nach zu erfüllenden Anforderungen sucht. Es ist wichtig zu beachten, dass Probleme, Anforderungen und Lösungen nicht unbedingt in dieser Reihenfolge auftreten. Beispielsweise entstehen beim Entwurf eines innovativen Foundation Level | Handbuch | © IREB 26 | 174 Systems durch Lösungsideen Benutzerbedürfnisse, die als Anforderungen ausgearbeitet und in eine konkrete Lösung umgesetzt werden müssen. Probleme, Anforderungen und Lösungen können auf vielfältige Weise miteinander verflochten sein: ▪ Hierarchische Verflechtung: Bei der Entwicklung großer Systeme mit einer mehrstufigen Hierarchie von Teilsystemen und Komponenten führen Anforderungen auf hoher Ebene zu Entwurfsentscheidungen auf hoher Ebene, die wiederum Anforderungen auf niedrigerer Ebene beeinflussen, die wiederum zu Entwurfsentscheidungen auf niedrigerer Ebene führen usw. ▪ Technische Durchführbarkeit: Die Spezifizierung nicht durchführbarer Anforderungen ist eine Verschwendung von Aufwand; die Durchführbarkeit einer Anforderung kann jedoch möglicherweise erst bei der Untersuchung technischer Lösungen beurteilt werden. ▪ Validierung: Prototypen, die ein leistungsfähiges Mittel zur Validierung von Anforderungen sind, stellen Teillösungen des Problems dar. ▪ Lösungsvoreingenommenheit: Verschiedene Stakeholder können unterschiedliche Lösungen für ein bestimmtes Problem ins Auge fassen, mit der Folge, dass sie für dieses Problem unterschiedliche, widersprüchliche Anforderungen stellen. Die Verflechtung von Problemen, Anforderungen und Lösungen hat auch Konsequenzen für den Entwicklungsprozess eines Systems: ▪ Eine strikte Trennung des RE von der Systementwicklung und den Implementierungsaktivitäten ist selten möglich. Daher funktionieren strenge Wasserfall-Entwicklungsprozesse nicht gut. ▪ Dennoch sind Requirements Engineers bestrebt, Probleme, Anforderungen und Lösungen beim Denken, Kommunizieren und Dokumentieren so weit wie möglich voneinander zu trennen. Diese Trennung der Belange erleichtert die Bewältigung der RE-Aufgaben. Trotz der unausweichlichen Verflechtung von Problemen, Anforderungen und Lösungen sind Requirements Engineers bestrebt, beim Denken, Kommunizieren und Dokumentieren Anforderungs- und Lösungsbelange voneinander zu trennen. 2.2.6 Prinzip 6 – Validierung: Nicht-validierte Anforderungen sind nutzlos Wenn ein System entwickelt wird, soll das letztlich eingesetzte System die Wünsche und Bedürfnisse der Stakeholder erfüllen. Es ist jedoch sehr riskant dies erst ganz am Ende der Entwicklung zu überprüfen. Um das Risiko unzufriedener Stakeholder von Anfang an zu kontrollieren, muss die Validierung im RE beginnen (siehe Abbildung 2.4). Foundation Level | Handbuch | © IREB 27 | 174 Abbildung 2.4 Validierung [Glin2019] Definition 2.5. Validation: The process of confirming that an item (a system, a work product, or a part thereof) matches its stakeholders’ needs. Im RE ist die Validierung der Prozess, mit dem bestätigt wird, dass die dokumentierten Anforderungen den Bedürfnissen der Stakeholder entsprechen; mit anderen Worten, es wird bestätigt, ob die richtigen Anforderungen spezifiziert wurden. Validierung ist eine Kernaktivität im RE: Ohne Validierung gibt es keine Spezifikation. Bei der Validierung von Anforderungen müssen wir prüfen, ob ▪ Eine Einigung unter den Stakeholdern über die Anforderungen erreicht wurde (Konflikte gelöst, Prioritäten gesetzt) ▪ Die Wünsche und Bedürfnisse der Stakeholder durch die Anforderungen ausreichend abgedeckt werden ▪ Die Kontextannahmen (siehe Prinzip 4 oben) vernünftig sind, d.h. ob wir erwarten können, dass diese Annahmen bei der Einführung und dem Betrieb des Systems erfüllt werden können Praktiken für die Validierung von Anforderungen werden in Kapitel 4.4 diskutiert. 2.2.7 Prinzip 7 – Evolution: Sich ändernde Anforderungen sind kein Unfall, sondern der Normalfall Jedes technische System ist der Veränderung unterworfen. Bedürfnisse, Geschäftstätigkeiten und Fähigkeiten ändern sich ständig. Als natürliche Konsequenz werden sich auch die Anforderungen an Systeme ändern, von denen erwartet wird, dass sie Foundation Level | Handbuch | © IREB 28 | 174 Bedürfnisse erfüllen, Geschäftsabläufe unterstützen und technische Fähigkeiten nutzen. Andernfalls verlieren solche Systeme und ihre Anforderungen allmählich ihren Wert und werden schließlich nutzlos. Eine Anforderung kann sich ändern, während die Requirements Engineers noch weitere Anforderungen ermitteln, wenn das System in der Entwicklung ist oder wenn es eingesetzt und genutzt wird. Es gibt viele Gründe, die zu Änderungswünschen für eine Anforderung oder eine Reihe von Anforderungen an ein System führen, wie z.B.: ▪ Geänderte Geschäftsprozesse ▪ Wettbewerber, die neue Produkte oder Dienstleistungen einführen ▪ Kunden, die ihre Prioritäten oder Meinung ändern ▪ Veränderungen in der Technologie ▪ Feedback von Systembenutzern, die nach einer neuen oder geänderten Funktion fragen Erkennen von Fehlern in Anforderungen oder erkennen von fehlerhaften Domänenannahmen ▪ Darüber hinaus können sich die Anforderungen auch aufgrund von Rückmeldungen der Stakeholder bei der Validierung von Anforderungen, durch die Entdeckung von Fehlern in zuvor erhobenen Anforderungen oder durch geänderte Bedürfnisse ändern. Folglich müssen Requirements Engineers zwei scheinbar widersprüchliche Ziele verfolgen: ▪ ▪ Lassen Sie zu, dass sich die Anforderungen ändern, denn der Versuch, die Veränderung der Anforderungen zu ignorieren, wäre zwecklos. Halten Sie die Anforderungen stabil, denn ohne eine gewisse Stabilität der Anforderungen können die Kosten für Änderungen unerschwinglich hoch werden. Auch können Entwicklungsteams nicht systematisch entwickeln, wenn sich die Anforderungen täglich ändern. Requirements Engineers müssen die Evolution von Anforderungen steuern. Andernfalls wird die Evolution sie überrollen. Änderungsprozesse für Anforderungen, die beide Ziele adressieren, werden in Kapitel 6.7 erörtert. 2.2.8 Prinzip 8 – Innovation: Mehr vom Gleichen ist nicht genug Während sich RE mit der Erfüllung der Wünsche und Bedürfnisse der Stakeholder beschäftigt, machen Requirements Engineers, die nur die Rolle des Diktiergerätes der Stakeholder spielen und genau spezifizieren was die Stakeholder ihnen sagen, etwas falsch. Foundation Level | Handbuch | © IREB 29 | 174 Den Stakeholdern genau das zu geben, was sie wollen, bedeutet die Chance zu verpassen, die Dinge besser zu machen als bisher. Stellen Sie sich zum Beispiel das folgende Szenario vor. Eine Versicherungsgesellschaft möchte das Berichtssystem für ihre Vertreter erneuern. Der am häufigsten verwendete Bericht ist eine Tabelle mit 18 Spalten, die etwa doppelt so breit ist wie der Bildschirm, wenn sie auf den Laptops der Vertreter angezeigt wird. Den Bericht anzuschauen erfordert daher viel Scrollen. Die Stakeholder möchten deshalb die Möglichkeit haben, den Bericht mit Hilfe von Plus- und MinusTasten auf dem Bildschirm zu vergrößern. In dieser Situation werden gute Requirements Engineers dies nicht einfach als Anforderung festhalten. Stattdessen werden sie anfangen Fragen zu stellen. Es stellt sich heraus, dass das Unternehmen die Laptops der Vertreter durch Tablets ersetzen wird. Daher erleichtert die Implementierung von Zwei-Finger-Gesten anstelle der geforderten Tasten das Zoomen erheblich. Darüber hinaus stellt sich heraus, dass drei Spalten im Bericht mit einer geringfügigen Änderung der Berichtsregeln gestrichen werden können, wozu das Unternehmen bereit ist. Außerdem werden immer nur sechs Spalten des Berichts benötigt; die übrigen Spalten werden nur in Sonderfällen verwendet. In Anbetracht dessen würden die Requirements Engineers vorschlagen, dass die Stakeholder verlangen, dass (1) der Bericht dieselben Informationen wie im aktuellen System zeigen soll, abzüglich des Inhalts der drei eliminierten Spalten; (2) beim Öffnen des Berichts nur die sechs wichtigen Spalten in voller Breite angezeigt werden, während die anderen Spalten auf minimale Breite zusammengeklappt werden; und (3) dass die Vertreter eine zusammengeklappte Spalte durch Antippen ihrer Kopfzeile aufklappen können (und sie mit einem weiteren Antippen wieder zuklappen können). Auf diese Weise erhalten die Vertreter ein System, das nicht nur einen Workaround zur Anzeige eines übergroßen Berichts hinzufügt. Vielmehr wird das System das Problem der Vertreter mit einer innovativen Funktion zum Filtern und über eine intuitive Zoomfunktion lösen. So entsteht Innovation. Gute Requirements Engineers sind innovationsbewusst: Sie streben nicht nur danach, die Stakeholder zufrieden zu stellen, sondern auch danach sie glücklich zu machen, zu begeistern oder, dass sie sich sicher fühlen [KSTT1984]. Gleichzeitig vermeiden sie die Gefahr, zu glauben, dass sie alles besser wissen als die Stakeholder. Gute Requirements Engineers gehen über das hinaus, was ihre Stakeholder ihnen sagen. Im Kleinen gestaltet RE innovative Systeme durch das Streben nach aufregenden neuen Funktionen und Benutzerfreundlichkeit. Darüber hinaus müssen Requirements Engineers auch das große Ganze im Auge behalten und gemeinsam mit den Stakeholdern untersuchen, ob es disruptive Wege gibt, die zu groß angelegten Innovationen führen [MaGR2004]. Kapitel 4.2 erörtert verschiedene Techniken zur Förderung von Innovationen im RE. Foundation Level | Handbuch | © IREB 30 | 174 2.2.9 Prinzip 9 – Systematische und disziplinierte Arbeit: Wir können im RE nicht darauf verzichten RE ist keine Kunst, sondern eine Disziplin, die eine systematische und disziplinierte Durchführung erfordert. Unabhängig von den genutzten Entwicklungsprozessen für ein System müssen geeignete Prozesse und Praktiken zur systematischen Ermittlung, Dokumentation, Validierung und Verwaltung von Anforderungen angewendet werden. Selbst wenn ein System ad hoc entwickelt wird, verbessert ein systematischer und disziplinierter Ansatz für das RE (z.B. durch systematische Förderung des gemeinsamen Verständnisses, siehe Prinzip 3) die Qualität des daraus resultierenden Systems. Agilität und Flexibilität sind keine gültigen Entschuldigungen für einen unsystematischen, ad hoc Stil der Arbeit im RE. Es gibt jedoch weder einen universellen RE-Prozess noch einen universellen Satz von REPraktiken, die in jeder gegebenen Situation oder zumindest in den meisten Situationen gut funktionieren: Es gibt kein „one-size-fits-all“ im RE. Systematisches und diszipliniertes Arbeiten bedeutet, dass Requirements Engineers: ▪ ▪ Konfigurieren eines RE-Prozesses, der für das vorliegende Problem gut geeignet ist und sich gut in den Systementwicklungsprozess einfügt (siehe Kapitel 5). Auswahl derjenigen RE-Praktiken und Arbeitsprodukte, aus der Menge der verfügbaren Praktiken und Arbeitsprodukte, die für das jeweilige Problem, den Kontext und die Arbeitsumgebung am besten geeignet sind (siehe Kapitel 3, 4 und 6). ▪ Nicht immer das gleiche Verfahren, die gleichen Praktiken und Arbeitsprodukte verwenden ▪ Prozesse und Praktiken aus früheren erfolgreichen RE-Tätigkeiten nicht unreflektiert wiederverwenden 2.3 Weiterführende Literatur Glinz [Glin2008] erörtert den Wert von Qualitätsanforderungen und von Anforderungen im Allgemeinen [Glin2016]. Glinz und Wieringa [GlWi2007] erläutern den Begriff und die Bedeutung von Stakeholdern. Glinz und Fricker [GlFr2015] erörtern die Rolle und Bedeutung des gemeinsamen Verständnisses. Die Arbeiten von Jackson [Jack1995b] und Gunter et al. [GGJZ2000] sind grundlegend für das Problem von Anforderungen im Kontext. Die Bedeutung des Kontexts im Bereich des RE wird ebenfalls bei Pohl ([Pohl2010]) diskutiert. Gause und Weinberg [GaWe1989] diskutieren die gegenseitige Abhängigkeit von Problemen und Lösungen. Swartout und Balzer [SwBa1982] waren die ersten, die darauf hinwiesen, dass Foundation Level | Handbuch | © IREB 31 | 174 die Erstellung einer vollständigen Spezifikation vor Beginn der Implementierung selten möglich ist. Die Validierung wird in jedem RE-Lehrbuch behandelt. Grünbacher und Seyff [GrSe2005] erörtern, wie eine Einigung durch Verhandlungen über Anforderungen erreicht werden kann. Kano et al. [KSTT1984] gehören zu den ersten, die die Rolle der Innovation betonen. Maalej, Nayebi, Johann und Ruhe [MNJR2016] diskutieren die Verwendung von explizitem und implizitem Benutzer-Feedback für RE. Maiden, Gitzikis und Robertson [MaGR2004] diskutieren, wie Kreativität Innovation im RE fördern kann. Gorschek et al. [GFPK2010] skizzieren einen systematischen Innovationsprozess. Foundation Level | Handbuch | © IREB 32 | 174