cpre_foundationlevel_handbook_de_v1.1.2 Kapitel3.pdf

3 Arbeitsprodukte und Dokumentationspraktiken Traditionelles Requirements Engineering (RE) fordert die Erstellung einer umfassenden, vollständigen und eindeutigen Anforderungsspezifikation [IEEE830], [Glin2016]. Während es in vielen Fällen immer noch angebracht ist vollwertige Anforderungsspezifikat...

3 Arbeitsprodukte und Dokumentationspraktiken Traditionelles Requirements Engineering (RE) fordert die Erstellung einer umfassenden, vollständigen und eindeutigen Anforderungsspezifikation [IEEE830], [Glin2016]. Während es in vielen Fällen immer noch angebracht ist vollwertige Anforderungsspezifikationen zu erstellen, gibt es auch viele andere Fälle, in denen die Kosten für die Erstellung solcher Spezifikationen ihren Nutzen übersteigen. So sind z.B. vollwertige Anforderungsspezifikationen nützlich oder sogar notwendig, wenn es um die Ausschreibung oder Auslagerung des Designs und der Implementierung eines Systems geht oder wenn ein System sicherheitskritisch ist und die Einhaltung von gesetzlichen Vorschriften erforderlich ist. Auf der anderen Seite ist es unsinnig, eine umfassende Anforderungsspezifikation zu schreiben, wenn Stakeholder und Entwickler sich zusammentun, um ein System iterativ zu definieren und zu entwickeln. Daher ist es im RE entscheidend, die Dokumentation an den Projektkontext anzupassen und bei der Dokumentation von Anforderungen und anforderungsbezogenen Informationen Arbeitsprodukte auszuwählen, die einen optimalen Nutzen für das Projekt erbringen. In diesem Kapitel lernen Sie die typischen RE-Arbeitsprodukte kennen und erfahren, wie man sie erstellt. 3.1 Arbeitsprodukte im Requirements Engineering Es gibt eine Vielzahl von Arbeitsprodukten, die im RE verwendet werden. Definition 3.1. Work product: A recorded intermediate or final result generated in a work process. Wir betrachten den Begriff Artefakt als Synonym für Arbeitsprodukt. Wir ziehen den Begriff „Arbeitsprodukt” dem Begriff „Artefakt” vor, um die Tatsache auszudrücken, dass ein Arbeitsprodukt das Ergebnis der in einem Arbeitsprozess geleisteten Arbeit ist. Nach dieser Definition kann ein RE-Arbeitsprodukt alles sein, was Anforderungen ausdrückt, von einem einzelnen Satz oder Diagramm bis hin zu einer SystemAnforderungsspezifikation, die Hunderte von Seiten umfasst. Es ist auch wichtig zu beachten, dass ein Arbeitsprodukt andere Arbeitsprodukte enthalten kann. 3.1.1 Merkmale von Arbeitsprodukten Arbeitsprodukte können durch folgende Facetten beschrieben werden: Zweck, Umfang, Darstellung, Lebensdauer und Speicherung. Foundation Level | Handbuch | © IREB 33 | 174 Tabelle 3.1 gibt einen Überblick über typische Arbeitsprodukte, die im RE verwendet werden, zusammen mit ihrem jeweiligen Verwendungszweck (d.h. was das Arbeitsprodukt spezifiziert oder bereitstellt) und ihrem typischen Umfang. Die Tabelle ist in vier Gruppen gegliedert: Arbeitsprodukte für einzelne Anforderungen, zusammenhängende Sets von Anforderungen, Dokumente oder Dokumentationsstrukturen und andere Arbeitsprodukte. Es gibt viele verschiedene Möglichkeiten, ein Arbeitsprodukt darzustellen. Im RE sind Darstellungen, die auf natürlicher Sprache, Vorlagen und Modellen basieren, von besonderer Bedeutung. Diese werden in den Kapiteln 3.2, 3.3 und 3.4 diskutiert. Es gibt weitere Darstellungen, wie z.B. Zeichnungen oder Prototypen, die in Kapitel 3.7 behandelt werden. Jedes Arbeitsprodukt hat eine Lebensdauer. Dies ist der Zeitraum von der Erstellung des Arbeitsprodukts bis zu dem Punkt, an dem das Arbeitsprodukt verworfen wird oder irrelevant wird. Hinsichtlich der Lebensdauer unterscheiden wir drei Kategorien von Arbeitsprodukten: kurzlebige, sich weiterentwickelnde und langlebig Arbeitsprodukte. Kurzlebige Arbeitsprodukte werden erstellt, um die Kommunikation zu unterstützen und ein gemeinsames Verständnis zu schaffen (z.B. durch eine Skizze einer Benutzer-SystemInteraktion, erstellt in einem Workshop). Kurzlebige Arbeitsprodukte werden nach Gebrauch weggeworfen; es werden auch keine Metadaten über diese Arbeitsprodukte aufbewahrt. Sich weiterentwickelnde Arbeitsprodukte entstehen mit der Zeit in mehreren Iterationen (z. B. eine Sammlung von User Storys, die sowohl in der Anzahl als auch im Inhalt wächst). Einige Metadaten (zumindest Eigentümer, Status und Revisionshistorie) sollten für jedes sich weiterentwickelnde Arbeitsprodukt aufbewahrt werden. Je nach Bedeutung und Status eines Arbeitsprodukts müssen bei der Modifizierung eines sich weiterentwickelnden Arbeitsprodukts Verfahren zur Änderungskontrolle angewendet werden. Langlebige Arbeitsprodukte wurden als Basislinie (Baseline) erstellt oder freigegeben (z. B. ein Pflichtenheft, das Teil eines Vertrags ist, oder ein Sprint-Backlog, das in einer bestimmten Iteration implementiert wird). Zur Verwaltung eines langlebigen Arbeitsprodukts muss ein vollständiger Satz von Metadaten aufbewahrt werden, und zur Änderung muss ein sorgfältiger Änderungsprozess befolgt werden (Kapitel 6). Ein kurzlebiges Arbeitsprodukt kann zu einem sich weiterentwickelnden werden, wenn die Requirements Engineers beschließen ein Arbeitsprodukt zu behalten und weiterzuentwickeln. In diesem Fall sollten einige Metadaten hinzugefügt werden, um die Entwicklung des Arbeitsprodukts unter Kontrolle zu halten. Wenn ein sich weiterentwickelndes Arbeitsprodukt als Basislinie fixiert oder freigegeben wird, ändert sich der Status seiner Lebensdauer von sich weiterentwickelnd zu langlebig. Foundation Level | Handbuch | © IREB 34 | 174 Tabelle 3.1 Übersicht der RE-Arbeitsprodukte Arbeitsprodukt Zweck: Das Arbeitsprodukt spezifiziert / liefert Umfang* Individuelle Anforderung Eine einzelne Anforderung, typischerweise in Textform S User Story Eine Funktion oder ein Verhalten aus der Perspektive eines Stakeholders S Einzelne Anforderungen Kohärente Sätze von Anforderungen Use Case Eine Systemfunktion aus der Perspektive eines Akteurs oder Nutzers S-M Grafisches Modell Verschiedene Aspekte, zum Beispiel Kontext, Funktion, Verhalten (siehe Kapitel 3.4) M Aufgabenbeschreibung Eine Aufgabe, die ein System ausführen soll S-M Beschreibung externer Schnittstellen Der Informationsaustausch zwischen einem System und einem Akteur im Systemkontext M Epic Ein Stakeholderbedürfnis auf hoher Abstraktionsebene M Feature Ein Unterscheidungsmerkmal eines Systems S-M Dokumente oder Dokumentationsstrukturen SystemAnforderungsspezifikation Ein umfassendes Anforderungsdokument L-XL Produkt- und Sprint-Backlog Eine Liste von Arbeitsaufgaben, einschließlich Anforderungen M-L Story Map Eine visuelle Anordnung von User Storys M Vision Ein konzeptionelles Bild eines zukünftigen Systems M Eindeutige und vereinbarte gemeinsame Terminologie M Andere Arbeitsprodukte Glossar Foundation Level | Handbuch | © IREB 35 | 174 Arbeitsprodukt Zweck: Das Arbeitsprodukt spezifiziert / liefert Umfang* Textnotiz oder grafische Skizze Ein Memo für Kommunikation und Verständnis S Prototyp Eine Spezifikation durch Beispiele, insbesondere zum Verständnis, Validieren und Verhandeln von Anforderungen S-L *: S: Klein, M: Mittel, L: Groß, XL: Sehr groß **: Andere Beispiele sind: Geschäfts-Anforderungsspezifikation, DomänenAnforderungsspezifikation, Stakeholder-/Benutzer-Anforderungsspezifikation oder SoftwareAnforderungsspezifikation Heutzutage werden die meisten Arbeitsprodukte elektronisch als Dateien, in Datenbanken oder in RE-Tools gespeichert. Informelle, kurzlebige Arbeitsprodukte können auch auf anderen Medien gespeichert werden, z.B. auf Papier oder als Haft-Notizen auf einem Kanban-Board. 3.1.2 Abstraktionsebenen Anforderungen und ihre entsprechenden Arbeitsprodukte treten auf verschiedenen Abstraktionsebenen auf - von z.B. abstrakten Anforderungen an einen neuen Geschäftsprozess, bis hin zu Anforderungen auf einer sehr detaillierten Ebene, wie z.B. die Reaktion einer Softwarekomponente auf ein außergewöhnliches Ereignis. Geschäftsanforderungen, Domänenanforderungen und Stakeholder- bzw. Benutzeranforderungen treten typischerweise auf einer höheren Abstraktionsebene auf als Systemanforderungen. Wenn ein System aus einer Hierarchie von Subsystemen und Komponenten besteht, haben wir Systemanforderungen auf den entsprechenden Abstraktionsebenen für Subsysteme und Komponenten. Wenn Geschäftsanforderungen und Stakeholderanforderungen in langlebigen Arbeitsprodukten wie z.B. in Spezifikationen für Geschäftsanforderungen, Stakeholderanforderungen oder Visions-Dokumenten beschrieben werden, gehen sie der Spezifikation der Systemanforderungen voraus. In vertraglichen Situationen, in denen ein Kunde beispielsweise die Entwicklung eines Systems bei einem Lieferanten in Auftrag gibt, erstellt der Kunde häufig eine Spezifikation der Stakeholderanforderungen und gibt sie frei. Der Anbieter erstellt dann auf dieser Grundlage eine System-Anforderungsspezifikation. In anderen Projekten können sich Geschäfts-, Stakeholder- und Systemanforderungen auch gemeinsam entwickeln. Einige Arbeitsprodukte, wie einzelne Anforderungen, Skizzen oder Prozessmodelle kommen auf allen Ebenen vor. Andere Arbeitsprodukte sind speziell mit bestimmten Ebenen verbunden. Beispielsweise ist eine System-Anforderungsspezifikation mit der Systemebene verbunden. Beachten Sie, dass eine einzelne Anforderung auf einer hohen Foundation Level | Handbuch | © IREB 36 | 174 Abstraktionsebene zu mehreren detaillierten Anforderungen auf konkreteren Ebenen verfeinert werden kann. Die Wahl des richtigen Abstraktionsniveaus hängt insbesondere von dem zu spezifizierenden Gegenstand und dem Zweck der Spezifikation ab. Handelt es sich bei dem zu spezifizierenden Gegenstand beispielsweise um einen Teil des zu lösenden Problems auf niedriger Ebene, wird er auf einer eher niedrigen Abstraktionsebene spezifiziert. Es ist jedoch wichtig, Anforderungen, die auf verschiedenen Abstraktionsebenen existieren, nicht zu vermischen. Beispielsweise sollte bei der Spezifikation eines Gesundheitsinformationssystems, wenn eine detaillierte Anforderung zu Fotos auf Kundenausweisen geschrieben wird, im nachfolgenden Absatz kein allgemeines Systemziel wie z.B. die Senkung der Gesundheitskosten bei gleichzeitiger Aufrechterhaltung des gegenwärtigen Service Levels für die Kunden genannt werden. In kleinen und mittelgroßen Arbeitsprodukten (z.B. User Storys oder Use Cases) sollten die Anforderungen mehr oder weniger auf derselben Abstraktionsebene liegen. In großen Arbeitsprodukten wie einer System-Anforderungsspezifikation sollten Anforderungen auf unterschiedlichen Abstraktionsebenen getrennt gehalten werden, indem die Spezifikation entsprechend strukturiert wird (Kapitel 3.6). Anforderungen treten naturgemäß auf verschiedenen Abstraktionsebenen auf. Die Auswahl von Arbeitsprodukten, die für eine bestimmte Abstraktionsebene geeignet sind und die richtige Strukturierung von Arbeitsprodukten, die Anforderungen auf mehreren Abstraktionsebenen enthalten, ist hilfreich. 3.1.3 Detaillierungsgrad Bei der Spezifikation von Anforderungen müssen die Requirements Engineers entscheiden, in welchem Detaillierungsgrad die Anforderungen spezifiziert werden sollen. Die Entscheidung, welcher Detaillierungsgrad für eine gegebene Anforderung angemessen oder sogar optimal ist, ist jedoch eine schwierige Aufgabe. In einer Situation, in der Kunde und Lieferant eines Systems eng zusammenarbeiten, könnte es beispielsweise ausreichen, eine Anforderung an ein Dateneingabeformular wie folgt anzugeben: „Das System muss ein Formular für die Eingabe der persönlichen Daten des Kunden bereitstellen.” Im Gegensatz dazu wird in einer Situation, in der das Design und die Implementierung des Systems an einen Anbieter mit wenig oder gar keinem Domänenwissen ausgelagert werden, eine detaillierte Spezifikation des Kundenerfassungsformulars erforderlich sein. Der Detaillierungsgrad in dem Anforderungen spezifiziert werden sollten, hängt von verschiedenen Faktoren ab, insbesondere: ▪ Das Problem und der Projektkontext: Je schwieriger das Problem und je weniger vertraut die Requirements Engineers und Entwickler mit dem Projektkontext sind, desto mehr Details sind notwendig. Foundation Level | Handbuch | © IREB 37 | 174 ▪ Der Grad des gemeinsamen Verständnisses des Problems: Wenn das implizite gemeinsame Verständnis gering ist (siehe Prinzip 3 in Kapitel 2), sind explizite, detaillierte Spezifikationen erforderlich, um den erforderlichen Grad des gemeinsamen Verständnisses zu schaffen. ▪ Der den Designern und Programmierern überlassene Freiheitsgrad: Weniger detaillierte Anforderungen geben den Entwicklern mehr Freiheit. ▪ Verfügbarkeit von schnellem Stakeholder-Feedback während der Konzeption und Implementierung: Wenn schnelles Feedback verfügbar ist, reichen weniger detaillierte Spezifikationen aus, um das Risiko der Entwicklung eines falschen Systems zu kontrollieren. ▪ Kosten vs. Wert einer detaillierten Spezifikation: Je höher der Nutzen einer Anforderung ist, desto mehr können wir es uns leisten, sie im Detail zu spezifizieren. ▪ Normen und behördliche Auflagen: Auferlegte Normen und behördliche Auflagen können dazu führen, dass Anforderungen detaillierter spezifiziert werden müssen als es sonst notwendig wäre. Es gibt keinen allgemein „richtigen” Detaillierungsgrad für Anforderungen. Für jede Anforderung hängt der angemessene Detaillierungsgrad von vielen Faktoren ab. Je detaillierter die Anforderungen spezifiziert sind, desto geringer ist das Risiko, dass am Ende etwas Unerwartetes herauskommt, bzw. Features oder Eigenschaften fehlen. Die Kosten für die Spezifikation steigen jedoch mit zunehmender Detaillierung. 3.1.4 Zu berücksichtigende Aspekte Unabhängig von den verwendeten RE-Arbeitsprodukten sind bei der Spezifizierung der Anforderungen mehrere Aspekte zu berücksichtigen [Glin2019]. Da es funktionale Anforderungen, Qualitätsanforderungen und Randbedingungen gibt (siehe Kapitel 1.1), müssen Requirements Engineers als erstes bei der Dokumentation von Anforderungen sicherstellen, dass sie alle drei Arten von Anforderungen abdecken. In der Praxis neigen die Stakeholder dazu, Qualitätsanforderungen wegzulassen, weil sie sie als selbstverständlich ansehen. Sie neigen auch dazu, Randbedingungen als funktionale Anforderungen zu spezifizieren. Es ist daher wichtig, dass die Requirements Engineers dies korrigieren. Bei der Betrachtung der funktionalen Anforderungen stellen wir fest, dass sie sich auf verschiedene Aspekte beziehen, wie z.B. eine erforderliche Datenstruktur, eine erforderliche Reihenfolge von Aktionen oder die erforderliche Reaktion auf ein externes Ereignis. Wir unterscheiden zwischen drei Hauptaspekten: Struktur und Daten, Funktion und Ablauf sowie Zustand und Verhalten. Der Struktur- und Datenaspekt konzentriert sich auf die Anforderungen an die statische Struktur eines Systems und die (persistenten) Daten, die ein System kennen muss, um die erforderlichen Funktionen ausführen und die gewünschten Ergebnisse liefern zu können. Foundation Level | Handbuch | © IREB 38 | 174 Der Funktions- und Ablaufsaspekt befasst sich mit den Funktionen, die ein System zur Verfügung stellen soll, sowie mit dem Kontroll- und Datenfluss innerhalb und zwischen den Funktionen zur Erzeugung der erforderlichen Ergebnisse aus den gegebenen Eingaben. Der Zustands- und Verhaltensaspekt konzentriert sich auf die Spezifizierung des zustandsabhängigen Verhaltens eines Systems - insbesondere darauf, wie ein System auf welches externe Ereignis in Abhängigkeit vom aktuellen Zustand des Systems reagieren soll. Wenn es um Qualitätsanforderungen wie Benutzerfreundlichkeit, Zuverlässigkeit oder Verfügbarkeit geht, kann ein Qualitätsmodell - zum Beispiel das von ISO/IEC 25010 bereitgestellte Modell - als Checkliste verwendet werden. Innerhalb der Qualitätsanforderungen sind die Leistungsanforderungen von besonderer Bedeutung. Leistungsanforderungen behandeln: ▪ Zeit (z.B. für die Ausführung einer Aufgabe oder die Reaktion auf externe Ereignisse) ▪ Volumen (z.B. erforderliche Datenbankgröße) ▪ Frequenz (z.B. der Berechnung einer Funktion oder des Empfangs von Signalen von Sensoren) ▪ Durchsatz (z.B. Datenübertragungs- oder Transaktionsraten) ▪ Ressourcenverbrauch (z.B. CPU, Speicher, Bandbreite, Batterie) Manche Leute betrachten auch die erforderliche Genauigkeit einer Berechnung als Leistungsanforderung. Wann immer möglich, sollten messbare Werte angegeben werden. Wenn Werte einer Wahrscheinlichkeitsverteilung folgen, reicht es nicht aus, nur den Mittelwert anzugeben. Wenn die Verteilungsfunktion und ihre Parameter nicht spezifiziert werden können, sollten sich die Requirements Engineers bemühen, zusätzlich zu den Mittelwerten Minimal- und Maximalwerte, oder 95-Prozent-Werte zu spezifizieren. Die Dokumentation von Qualitätsanforderungen, die über Leistungsanforderungen hinausgehen, ist äußerst schwierig. Qualitative Darstellungen, wie z.B. „Das System soll sicher und einfach zu bedienen sein”, sind mehrdeutig und daher schwer zu erreichen und zu validieren. Quantitative Darstellungen sind messbar, was ein großer Vorteil im Hinblick auf die systematische Erreichung und Validierung einer Qualitätsanforderung ist. Sie werfen jedoch prinzipielle Schwierigkeiten auf (Wie können wir z.B. Sicherheit quantitativ angeben?) und können in ihrer Spezifizierung recht kostspielig sein. Operationalisierte Darstellungen stellen eine Qualitätsanforderung in Form von funktionalen Anforderungen zur Erreichung der gewünschten Qualität dar. Beispielsweise kann eine Anforderung zur Datensicherheit in Form einer Anmeldefunktion ausgedrückt werden, die den Zugriff auf die Daten einschränkt und in einer Funktion, die die gespeicherten Daten verschlüsselt. Operationalisierte Darstellungen machen Qualitätsanforderungen testbar, können aber auch vorweggenommene Designentscheidungen implizieren. Foundation Level | Handbuch | © IREB 39 | 174 Die oft zitierte Regel „Nur eine quantifizierte Qualitätsanforderung ist eine gute Qualitätsanforderung” ist veraltet und kann dazu führen, dass Qualitätsanforderungen aufgrund des hohen Aufwands bei der Quantifizierung einen niedrigen oder sogar negativen Wert haben. Stattdessen sollte ein risikobasierter Ansatz verwendet werden [Glin2008]. Qualitative Darstellungen von Qualitätsanforderungen sind in den folgenden Situationen ausreichend: ▪ Es besteht ein ausreichendes implizites gemeinsames Verständnis zwischen Stakeholdern, Requirements Engineers und Entwicklern. ▪ Stakeholder, Requirements Engineers und Entwickler einigen sich auf eine bekannte Lösung, die die Anforderungen erfüllt. ▪ Stakeholder wollen nur allgemeine Qualitätsanweisungen geben und vertrauen darauf, dass die Entwickler die Details richtig machen. ▪ Kurze Rückkopplungsschleifen sind vorhanden, sodass Probleme frühzeitig erkannt werden können. Wenn Entwickler in der Lage sind, anhand von Beispielen zu verallgemeinern, ist die Spezifizierung von Qualitätsanforderungen in Form von quantifizierten Beispielen oder Vergleichen mit einem bestehenden System ein kostengünstiger und effektiver Weg zur Dokumentation von Qualitätsanforderungen. Nur in Fällen, in denen ein hohes Risiko besteht, dass die Bedürfnisse der Stakeholder nicht erfüllt werden, insbesondere, wenn die Qualitätsanforderungen sicherheitskritisch sind, sollte eine vollständig quantifizierte Darstellung oder eine Operationalisierung in Bezug auf die funktionalen Anforderungen in Betracht gezogen werden. Bei der Spezifizierung von Randbedingungen sollten die folgenden Kategorien von Randbedingungen berücksichtigt werden: ▪ ▪ Technisch: Vorgegebene Schnittstellen oder Protokolle, Komponenten oder Frameworks, die verwendet werden müssen, usw. Rechtlich: Einschränkungen durch Gesetze, Verträge, Normen oder Vorschriften ▪ Organisatorisch: Es kann Randbedingungen in Bezug auf Organisationsstrukturen, Prozesse oder Richtlinien geben, die vom System nicht geändert werden dürfen. ▪ Kulturell: Benutzergewohnheiten und -erwartungen werden bis zu einem gewissen Grad von der Kultur geprägt, in der die Benutzer leben. Dies ist ein besonders wichtiger Aspekt, der zu berücksichtigen ist, wenn die Benutzer eines Systems aus verschiedenen Kulturen stammen oder wenn die Requirements Engineers und Entwickler in einer anderen Kultur verwurzelt sind als die Benutzer des Systems. ▪ Umweltbezogen: Bei der Spezifizierung cyber-physischer Systeme müssen möglicherweise Umgebungsbedingungen wie Temperatur, Feuchtigkeit, Strahlung oder Vibrationen als Randbedingungen betrachtet werden. Energieverbrauch und Wärmeableitung können weitere Randbedingungen darstellen. ▪ Physikalisch: Wenn ein System physikalische Komponenten umfasst oder mit ihnen interagiert, wird das System durch die Gesetze der Physik und die Eigenschaften der für die physikalischen Komponenten verwendeten Materialien eingeschränkt. Foundation Level | Handbuch | © IREB 40 | 174 ▪ Darüber hinaus stellen besondere Lösungen oder Einschränkungen, die von wichtigen Stakeholdern gefordert werden, ebenfalls Randbedingungen dar. Schließlich können Anforderungen nur im Kontext verstanden werden (Prinzip 4 in Kapitel 2). Folglich muss ein weiterer Aspekt berücksichtigt werden, den wir als Kontext und Grenze bezeichnen. Der Aspekt Kontext und Grenze umfasst die Domänenanforderungen und Domänenannahmen im Kontext eines Systems sowie die externen Akteure, mit denen das System interagiert, und die externen Schnittstellen zwischen dem System und seiner Umgebung an der Systemgrenze. Zwischen den oben genannten Aspekten gibt es viele Wechselbeziehungen und Abhängigkeiten. Beispielsweise kann eine Anfrage von einem Benutzer (Kontext), die das System über eine externe Schnittstelle (Grenze) empfängt, einen Zustandsübergang des Systems (Zustand und Verhalten) bewirken, der eine Aktion (Funktion) auslöst, gefolgt von einer weiteren Aktion (Ablauf), die Daten in einer bestimmten Struktur (Struktur und Daten) benötigt, um dem Benutzer (Kontext) innerhalb eines bestimmten Zeitintervalls (Qualität) ein Ergebnis zu liefern. Einige Arbeitsprodukte konzentrieren sich auf einen bestimmten Aspekt und abstrahieren von den anderen Aspekten. Dies gilt insbesondere für Anforderungsmodelle (Kapitel 3.4). Andere Arbeitsprodukte, wie z.B. eine System-Anforderungsspezifikation, decken all diese Aspekte ab. Wenn verschiedene Aspekte in getrennten Arbeitsprodukten oder in getrennten Kapiteln desselben Arbeitsprodukts dokumentiert sind, müssen diese Arbeitsprodukte oder Kapitel miteinander konsistent gehalten werden. Bei der Dokumentation von Anforderungen müssen viele verschiedene Aspekte berücksichtigt werden, insbesondere Funktionalität (Struktur und Daten, Funktion und Ablauf, Zustand und Verhalten), Qualität, Randbedingungen und Umgebungskontext (Kontext und Grenze). 3.1.5 Allgemeine Richtlinien für die Dokumentation Unabhängig von den verwendeten Techniken gibt es einige allgemeine Richtlinien, die bei der Erstellung von RE-Arbeitsprodukten beachtet werden sollten: ▪ Wählen Sie einen Typ von Arbeitsprodukten aus, der den beabsichtigten Zweck erfüllt. ▪ Vermeiden Sie Redundanz, indem Sie auf Inhalte verweisen, anstatt denselben Inhalt noch einmal zu wiederholen. ▪ Vermeiden sie Inkonsistenzen zwischen Arbeitsprodukten, insbesondere wenn sie verschiedene Aspekte abdecken. ▪ Verwenden Sie Begriffe konsistent, so wie im Glossar definiert. ▪ Strukturieren Sie Arbeitsprodukte angemessen, z.B. durch Verwendung von Standardstrukturen. Foundation Level | Handbuch | © IREB 41 | 174 3.1.6 Arbeitsprodukt-Planung Jeder Projektrahmen und jede Domäne ist anders, sodass für jedes Vorhaben die zu entwickelnden Arbeitsprodukte ausgewählt werden müssen. Die beteiligten Parteien, insbesondere die Requirements Engineers, Stakeholder und Projekt-/Produkteigner oder Manager müssen sich auf folgende Punkte einigen: In welchen Arbeitsprodukten sollen die Anforderungen erfasst werden und zu welchem Zweck (siehe Tabelle 3.1 gibt)? ▪ Welche Abstraktionsebenen sind zu berücksichtigen (Kapitel 3.1.2)? ▪ Bis zu welchem Detaillierungsgrad müssen Anforderungen auf jeder Abstraktionsebene dokumentiert werden (Kapitel 3.1.3)? ▪ Wie sollen die Anforderungen in diesen Arbeitsprodukten dargestellt werden (z.B. natürlichsprachig oder modellbasiert, siehe unten) und welche Notation(en) soll(en) verwendet werden? Requirements Engineers sollten die zu verwendenden RE-Arbeitsprodukte zu einem frühen Zeitpunkt im Projekt festlegen. Die frühe Definition: ▪ Hilft bei der Planung von Aufwand und Ressourcen ▪ Stellt sicher, dass geeignete Notationen verwendet werden ▪ Stellt sicher, dass alle Ergebnisse in den richtigen Arbeitsprodukten erfasst werden ▪ Stellt sicher, dass keine größere Umstrukturierung von Informationen und keine „Schlussredaktion“ erforderlich ist ▪ Es hilft, Redundanzen zu vermeiden, was zu weniger Arbeit und einfacherer Wartbarkeit führt 3.2 Natürlichsprachige Arbeitsprodukte Die natürliche Sprache, sowohl in gesprochener als auch in geschriebener Form, ist seit jeher ein zentrales Mittel zur Kommunikation von Anforderungen an Systeme. Die Verwendung natürlicher Sprache beim Schreiben von RE-Arbeitsprodukten hat viele Vorteile. Insbesondere ist die natürliche Sprache äußerst ausdrucksstark und flexibel, was bedeutet, dass fast jede denkbare Anforderung in all ihren Aspekten in natürlicher Sprache ausgedrückt werden kann. Darüber hinaus wird natürliche Sprache im täglichen Leben verwendet und in der Schule gelehrt, sodass für das Lesen und Verstehen von Anforderungen in natürlicher Sprache keine spezielle Ausbildung erforderlich ist. Die menschliche Evolution hat die natürliche Sprache als ein Mittel der gesprochenen Kommunikation zwischen direkt interagierenden Menschen geformt, bei dem Missverständnisse und fehlende Informationen schnell erkannt und korrigiert werden können. Daher ist die natürliche Sprache nicht für eine präzise, eindeutige und umfassende Kommunikation mittels schriftlicher Dokumente optimiert. Dies stellt ein großes Problem dar, wenn technische Dokumentation (wie z.B. Anforderungen) in natürlicher Sprache verfasst wird. Im Gegensatz zur Kommunikation in gesprochener natürlicher Sprache, bei der die Kommunikation kontextualisiert und interaktiv mit sofortiger Rückmeldung erfolgt, gibt es Foundation Level | Handbuch | © IREB 42 | 174 keine natürlichen Mittel zur schnellen Erkennung und Korrektur von Mehrdeutigkeiten, Auslassungen und Inkonsistenzen in geschriebenen natürlichsprachigen Texten. Im Gegenteil, es ist schwierig und kostspielig, solche Mehrdeutigkeiten, Auslassungen und Unstimmigkeiten in geschriebenen Texten zu finden, insbesondere bei Arbeitsprodukten, die eine große Menge an natürlichsprachigem Text enthalten. Das Problem kann bis zu einem gewissen Grad verringert werden, indem technische Dokumentation bewusst geschrieben wird, bewährte Regeln befolgt und bekannte Fallstricke vermieden werden. Beim Schreiben von Anforderungen in natürlicher Sprache können Requirements Engineers viele potenzielle Missverständnisse vermeiden, indem sie einige einfache Regeln anwenden: ▪ Schreiben Sie kurze und gut strukturierte Sätze. Als Faustregel gilt, eine einzige Anforderung in einem Satz in natürlicher Sprache auszudrücken. Um eine gute Struktur zu erreichen, sollten Requirements Engineers Satzschablonen verwenden (Kapitel 3.33.3). ▪ Erstellen Sie gut strukturierte Arbeitsprodukte. Neben dem Schreiben gut strukturierter Sätze (siehe oben) sollten in natürlicher Sprache verfasste Arbeitsprodukte auch als Ganzes gut strukturiert sein. Ein bewährter Weg, dies zu erreichen, ist die Verwendung einer hierarchischen Struktur aus Teilen, Kapiteln, Abschnitten und Unterabschnitten, wie sie üblicherweise in Fachbüchern verwendet wird. Dokumentvorlagen (Kapitel 3.3) helfen Ihnen, eine gute Struktur zu erreichen. ▪ Definieren und verwenden Sie konsistent eine einheitliche Terminologie. Die Erstellung und Verwendung eines Glossars (Kapitel 3.5) ist das wichtigste Mittel zur Vermeidung von Missverständnissen und Inkonsistenzen in der Terminologie. ▪ Vermeiden Sie die Verwendung ungenauer oder mehrdeutiger Begriffe und Phrasen. ▪ Kennen und vermeiden Sie die Fallstricke des fachlichen Schreibens. Beim Schreiben von technischen Dokumenten in natürlicher Sprache gibt es einige bekannte Fallstricke die vermieden werden, oder Dinge, die mit Vorsicht verwendet werden sollten (s. z.B. [GoRu2003]). Requirements Engineers sollten es vermeiden, Anforderungen zu schreiben, die folgendes enthalten: ▪ Unvollständige Beschreibungen. Verben in natürlicher Sprache haben normalerweise eine Reihe von Platzhaltern für Substantive oder Pronomen. Zum Beispiel hat das Verb „geben” drei Platzhalter dafür, wer wem was gibt. Wenn eine Anforderung in natürlicher Sprache geschrieben wird, sollten alle Platzhalter des verwendeten Verbs ausgefüllt werden. ▪ Unspezifische Substantive. Die Verwendung von Substantiven wie „die Daten” oder „der Benutzer” lässt zu viel Raum für unterschiedliche Interpretationen durch verschiedene Stakeholder oder Entwickler. Sie sollten durch spezifischere Substantive ersetzt oder durch Hinzufügung von Adjektiven oder Zuweisung eines klar definierten Typs präzisiert werden. Foundation Level | Handbuch | © IREB 43 | 174 ▪ Unvollständige Bedingungen. Bei der Beschreibung dessen, was getan werden soll, konzentrieren sich viele Menschen auf den Normalfall und lassen Ausnahmefälle außen vor. Beim fachlichen Schreiben ist dies eine Falle, in die man nicht treten sollte: Wenn etwas nur dann geschieht, wenn bestimmte Bedingungen zutreffen, dann müssen diese Bedingungen angegeben werden, wobei sowohl dann als auch sonst Klauseln vorgesehen werden sollten. ▪ Unvollständige Vergleiche. In der gesprochenen Kommunikation neigen Menschen dazu, Vergleiche zu verwenden (z. B. „die neue Videoanwendung ist viel besser”), ohne zu sagen, womit sie vergleichen, wobei sie in der Regel davon ausgehen, dass dies aus dem Kontext klar hervorgeht. Beim fachlichen Schreiben sollten Vergleiche ein Referenzobjekt enthalten, z. B. „schneller als 0,1 ms”. Es gibt noch einige weitere Dinge, mit denen Requirements Engineers vorsichtig umgehen müssen, da sie potenzielle Fallstricke darstellen: ▪ Passive Formulierung. Sätze im Passiv haben kein handelndes Subjekt. Wenn eine Anforderung im Passiv angegeben wird, kann dies dazu führen, dass nicht deutlich wird, wer für die in der Anforderung beschriebene Handlung verantwortlich ist, was zu einer unvollständigen Beschreibung führt. ▪ Universalquantoren. Universalquantoren sind Wörter wie alle, immer oder nie, die verwendet werden, um Aussagen zu treffen, die universell wahr sind. In technischen Systemen sind solche universellen Eigenschaften jedoch selten. Wann immer Requirements Engineers einen Universalquantor verwenden, müssen sie darüber nachdenken, ob sie eine wirklich universelle Eigenschaft angeben, oder ob sie stattdessen eine allgemeine Regel mit Ausnahmen (die sie ebenfalls angeben müssen) spezifizieren. Die gleiche Vorsicht sollten sie bei der Verwendung von „Entweder-Oder”-Klauseln walten lassen, die durch ihre Semantik weitere Ausnahmefälle ausschließen. ▪ Nominalisierung. Wenn ein Substantiv von einem Verb abgeleitet wird (zum Beispiel „Beglaubigung” von „beglaubigen”), nennen Linguisten dies eine Nominalisierung. Bei der Spezifizierung von Anforderungen müssen Requirements Engineers mit Nominalisierungen vorsichtig umgehen, da sich hinter einer Nominalisierung nicht spezifizierte Anforderungen verbergen können. Beispielsweise impliziert die Anforderung „Nur nach erfolgreicher Authentifizierung soll das System einem Benutzer Zugang zu (...)”, dass ein Verfahren zur Authentifizierung von Benutzern existiert. Beim Schreiben einer solchen Anforderung muss der Requirements Engineer daher prüfen, ob es auch Anforderungen an das Verfahren zur Authentifizierung legitimer Benutzer gibt. Natürliche Sprache ist ein sehr mächtiges Mittel, um Anforderungen zu formulieren. Um die inhärenten Nachteile der Verwendung natürlicher Sprache für die fachliche Dokumentation abzuschwächen, sollten Requirements Engineers bewährte Schreibregeln befolgen und bekannte Fallstricke vermeiden. Foundation Level | Handbuch | © IREB 44 | 174 3.3 Vorlagenbasierte Arbeitsprodukte Wie in Kapitel 3.2 oben erwähnt, ist die Verwendung von Vorlagen ein bewährtes Mittel, um gute, gut strukturierte Arbeitsprodukte in natürlicher Sprache zu schreiben und so einige der Schwächen der natürlichen Sprache für das fachliche Schreiben zu mildern. Eine Vorlage ist eine Art vorgefertigter Entwurf für die syntaktische Struktur eines Arbeitsprodukts. Bei der Verwendung natürlicher Sprache im RE unterscheiden wir drei Klassen von Vorlagen: Satzschablonen, Formularvorlagen und Dokumentvorlagen. 3.3.1 Satzschablonen Definition 3.2. Phrase template: A template for the syntactic structure of a phrase that expresses an individual requirement or a user story in natural language. Eine Satzschablone bietet eine Grundstruktur mit Platzhaltern, in der die Requirements Engineers die Platzhalter ausfüllen, um gut strukturierte, einheitliche Sätze zu erhalten, die die Anforderungen ausdrücken. Die Verwendung von Satzschablonen ist eine bewährte Methode, um individuelle Anforderungen in natürlicher Sprache zu formulieren und um User Storys zu schreiben. 3.3.1.1 Satzschablonen für individuelle Anforderungen Verschiedene Satzschablonen für das Schreiben individueller Anforderungen wurden z.B. in [ISO29148], [MWHN2009] und [Rupp2014] definiert. Der Standard ISO/IEC/IEEE 29148 [ISO29148] bietet eine einfache, einheitliche Vorlage für individuelle Anforderungen wie folgt: [] []. Beispiel: Wenn eine gültige Karte erkannt wird, soll das System die Meldung „Geben Sie Ihre PIN ein” auf dem Dialogbildschirm anzeigen, und zwar innerhalb von 200 ms. Bei der Formulierung einer Aktion mit dieser Vorlage werden in der Praxis häufig die folgenden Konventionen über die Verwendung von Hilfsverben verwendet: ▪ Muss bezeichnet eine obligatorische Anforderung. ▪ Sollte bezeichnet eine Anforderung, die nicht obligatorisch, aber stark erwünscht ist. ▪ Kann kennzeichnet einen Vorschlag. Foundation Level | Handbuch | © IREB 45 | 174 Wird (oder die Verwendung eines Verbs im Präsens ohne eines der oben erwähnten Hilfsverben) bezeichnet eine Sachaussage, die nicht als Anforderung gilt. Wenn es keine vereinbarten Bedeutungen für Hilfsverben in einem Projekt gibt oder wenn Zweifel bestehen, sollten Definitionen wie die oben genannten in eine Anforderungsspezifikation aufgenommen werden. EARS (Easy Approach to Requirements Syntax) [MWHN2009] bietet eine Reihe von Satzschablonen, die wie unten beschrieben an verschiedene Situationen angepasst werden. Allgegenwärtige Anforderungen (müssen immer gelten): Das soll. Ereignisgesteuerte Anforderungen (ausgelöst durch ein externes Ereignis): SOBALD|NACHDEM soll das. Unerwünschtes Verhalten (Beschreibung zu vermeidender Situationen): WENN , DANN soll das. Anmerkung: Obwohl die Schablone für unerwünschtes Verhalten der Schablone für ereignisgesteuertes Verhalten ähnlich ist, liefern Mavin et al. eine separate Schablone für letzteres und argumentieren, dass unerwünschtes Verhalten (hauptsächlich aufgrund unerwarteter Ereignisse im Kontext, wie Fehler, Angriffe oder Dinge, an die niemand gedacht hat) eine Hauptquelle für Lücken im RE ist. Zustandsorientierte Anforderungen (gelten nur in bestimmten Zuständen): SOLANGE. soll das Optionale Funktionen (nur anwendbar, wenn eine Funktion im System enthalten ist): FALLS soll das. In der Praxis können Sätze, die die Schlüsselwörter SOBALD|NACHDEM, SOLANGE und FALLS kombinieren, erforderlich sein, um komplexe Anforderungen auszudrücken. Foundation Level | Handbuch | © IREB 46 | 174 EARS wurde in erster Linie für die Spezifikation von cyber-physischen Systemen konzipiert. Es kann jedoch auch für andere Arten von Systemen angepasst werden. 3.3.1.2 Satzschablonen für User Storys Die klassische Satzschablone zum Schreiben von User Storys wurde von Cohn [Cohn2004] eingeführt: Als möchte ich , damit. Beispiel: „Als Vorgesetzter möchte ich ad hoc Anfragen an das Buchhaltungssystem stellen, damit ich die Finanzplanung für meine Abteilung durchführen kann.” Während Cohn den Teil der Vorlage als optional bezeichnet hat, ist es heute gängige Praxis, für jede User Story einen Nutzen anzugeben. Jede User Story sollte von einer Reihe von Akzeptanzkriterien begleitet werden, d.h. von Kriterien, die die Implementierung der User Story erfüllen muss, um von den Stakeholdern akzeptiert zu werden. Akzeptanzkriterien machen eine User Story konkreter und weniger mehrdeutig. Dies hilft, Umsetzungsfehler aufgrund von Missverständnissen zu vermeiden. 3.3.2 Formularvorlagen Definition 3.3. Form template: A template providing a form with predefined fields to be filled in. Formularvorlagen werden zur Strukturierung von Arbeitsprodukten mittlerer Größe wie z.B. Use Cases verwendet. Cockburn [Cock2001] führte eine beliebte Formularvorlage für Use Cases ein. [Laue2002] hat eine Vorlage für Aufgabenbeschreibungen vorgeschlagen. Foundation Level | Handbuch | © IREB 47 | 174 Tabelle 3.2 zeigt eine einfache Formularvorlage für Use Cases. Jeder Ablaufschritt kann in eine Aktion durch einen Akteur und die Reaktion durch das System unterteilt werden. Foundation Level | Handbuch | © IREB 48 | 174 Tabelle 3.2 Eine einfache Formularvorlage zum Schreiben von Use Cases Name < Eine kurze aktive Verbphrase> Vorbedingung Erfolgs-Endbedingung Fehler Endbedingung Haupt Akteur Andere Akteure Auslöser Normaler Ablauf Alternative Abläufe Erweiterungen Verwandte Informationen Formularvorlagen sind auch nützlich, um Qualitätsanforderungen in messbarer Form zu formulieren [Gilb1988]. Tabelle 3.3 stellt eine einfache Formularvorlage für messbare Qualitätsanforderungen zusammen mit einem Beispiel dar. Tabelle 3.3 Eine Formularvorlage zur Spezifikation messbarer Qualitätsanforderungen Vorlage ID Beispiel A137.2 Foundation Level | Handbuch | © IREB 49 | 174 Ziel Zimmerreservierungen sofort bestätigen Maßstab Verstrichene Zeit in Sekunden (Verhältnisskala) Messverfahren Zeitstempelung der Momente, in denen der Benutzer auf die Schaltfläche „Reservieren” drückt und wenn die Anwendung die Bestätigung angezeigt hat. Messung der Zeitdifferenz. Minimum Weniger als 5 s in mindestens 95% aller Fälle OK-Bereich Zwischen 0,5 und 3 s in mehr als 98% aller Fälle Gewünscht Weniger als 0,5 s in 100% aller Fälle 3.3.3 Dokumentvorlagen Definition 3.4. Document template: A template providing a predefined skeleton structure for a document. Dokumentvorlagen helfen bei der systematischen Strukturierung von Anforderungsdokumenten - zum Beispiel einer System-Anforderungsspezifikation. Vorlagen für RE-Dokumente finden sich in Normen, zum Beispiel in [ISO29148]. Auch die VolereVorlage von Robertson und Robertson [RoRo2012], [Vole2020] ist in der Praxis beliebt. Wenn eine Anforderungsspezifikation in die Menge von Arbeitsprodukten aufgenommen wird, die ein Kunde bestellt hat und für die er bezahlen wird, kann dieser Kunde die Verwendung von Dokumentenvorlagen vorschreiben, die von ihm geliefert werden. In Abbildung 3.1 zeigen wir ein Beispiel für eine einfache Dokumentvorlage für eine System-Anforderungsspezifikation. 3.3.4 Vorteile und Nachteile Die Verwendung von Vorlagen beim Schreiben von RE-Arbeitsprodukten in natürlicher Sprache hat große Vorteile. Vorlagen bieten eine klare, wiederverwendbare Struktur für Arbeitsprodukte, lassen sie einheitlich aussehen und verbessern so die Lesbarkeit der Arbeitsprodukte. Vorlagen helfen Ihnen auch dabei, die relevantesten Informationen zu Foundation Level | Handbuch | © IREB 50 | 174 erfassen und weniger Auslassungsfehler zu machen. Auf der anderen Seite gibt es einen potenziellen Fallstrick, wenn Requirements Engineers Vorlagen mechanisch verwenden und sich dabei auf die syntaktische Struktur statt auf den Inhalt konzentrieren und alles vernachlässigen, was nicht in die Vorlage passt. Foundation Level | Handbuch | © IREB 51 | 174 Teil Sections Teil I: Einführung Zweck des Systems Umfang der Systementwicklung Stakeholder Teil II: Systemübersicht System Vision und Ziele Systemkontext und -grenze Gesamtstruktur des Systems Merkmale der Benutzer Teil III: Systemanforderungen Hierarchisch nach der Systemstruktur organisiert, unter Verwendung eines hierarchischen Nummerierungsschemas für Anforderungen Pro Subsystem/Komponente: Funktionale Anforderungen (Struktur und Daten, Funktion und Ablauf, Zustand und Verhalten) Qualitätsanforderungen Randbedingungen Schnittstellen Referenzen Glossar (falls nicht als eigenständiges Arbeitsprodukt verwaltet) Anhänge Annahmen und Abhängigkeiten Abbildung 3.1 Eine einfache Vorlage für eine System-Anforderungsspezifikation Die Verwendung von Vorlagen beim Schreiben von RE-Arbeitsprodukten in natürlicher Sprache verbessert die Qualität der Arbeitsprodukte, vorausgesetzt, die Vorlagen werden nicht als reine syntaktische Übung missbraucht. 3.4 Modellbasierte Arbeitsprodukte Anforderungen, die in natürlicher Sprache formuliert sind, können von Menschen leicht gelesen werden, sofern sie die Sprache beherrschen. Die natürliche Sprache leidet unter Mehrdeutigkeit aufgrund der Ungenauigkeit der Semantik von Wörtern, Phrasen und Sätzen [Davi1993]. Diese Ungenauigkeit kann zu Verwirrung und Auslassungen bei Anforderungen führen. Wenn Sie textuelle Anforderungen lesen, werden Sie versuchen, sie auf Ihre eigene Foundation Level | Handbuch | © IREB 52 | 174 Weise zu interpretieren. Wir versuchen oft uns diese Anforderungen vorzustellen. Wenn die Anzahl der Anforderungen überschaubar ist, ist es möglich den Durchblick und den Überblick über die textuellen Anforderungen zu behalten. Wenn die Zahl der textuellen Anforderungen „zu groß” wird verlieren wir den Überblick. Diese Grenze ist für jede Person unterschiedlich. Die Anzahl der textuellen Anforderungen ist nicht der einzige Grund für den Verlust von Durchblick und Überblick. Dazu tragen auch die Komplexität der Anforderungen, das Verhältnis zwischen den Anforderungen und die Abstraktion der Anforderungen bei. Es kann sein, dass Sie die in natürlicher Sprache formulierten Anforderungen mehrmals lesen müssen, bevor Sie ein korrektes und vollständiges Bild erhalten, das das System erfüllen muss. Wir sind nur begrenzt in der Lage Anforderungen in natürlicher Sprache zu verarbeiten. Abbildung 3.2 Textuelle Anforderungen versus modellierte Anforderungen Ein Modell ist eine abstrakte Darstellung eines bestehenden oder zu schaffenden Teils der Realität. Die Darstellung der Anforderungen (auch) mit einem Modell (oder Bild) wird dazu beitragen, dass die Leser die Anforderungen verstehen. Eine solche schematische Darstellung eines Modells wird als Diagramm bezeichnet. Das Diagramm in Abbildung 3.2 zeigt auf einen Blick, was das System leisten muss, aber nur, wenn Sie die Modellierungssprache beherrschen. Wenn Sie das Diagramm - in diesem Fall ein UML-Aktivitätsdiagramm - nicht verstehen, ist es offensichtlich, dass das Bild nicht zum besseren Verständnis der Anforderungen beiträgt. Im nächsten Kapitel (3.4.1) wird das Konzept eines Anforderungsmodells erläutert. Die Modellierung von Geschäftsanforderungen und -zielen wird in Kapitel 3.4.6 erläutert. Eine Foundation Level | Handbuch | © IREB 53 | 174 wichtige Methode zur Beschreibung der Abgrenzung eines Systems ist das Kontextmodell. Beispiele für den Kontext sind in Kapitel 3.4.2 dargestellt. Die Kapitel 0 bis 3.4.5 enthalten eine Reihe von Beispielen für Modellierungssprachen, die im Systems Engineering in der Praxis häufig verwendet werden. 3.4.1 Die Rolle von Modellen im Requirements Engineering Wie jede Sprache besteht eine Modellierungssprache aus grammatikalischen Regeln und einer Beschreibung der Bedeutung der Sprachkonstrukte, siehe Kapitel 3.4.1.1. Obwohl ein Modell eine visuelle Darstellung der Realität ist, sind die Sprachregeln wichtig, um das Modell und die Nuancen im Modell zu verstehen. Es ist nicht immer effizient oder effektiv die Anforderungen in einem Modell zusammenzufassen. Wenn wir die Eigenschaften eines Modells verstehen, können wir besser bestimmen, wann wir welches Modell anwenden können, siehe Kapitel 3.4.1.2. So wie die natürliche Sprache Vor- und Nachteile bei der Formulierung der Anforderungen hat, so haben auch Modelle Vor- und Nachteile. Wenn wir diese Tatsachen bei der Anwendung eines Modells beachten, können wir den Mehrwert der Anwendung des „richtigen” Modells besser bestimmen. Dies wird in Kapitel 3.4.1.3 erörtert. Viele Modelle sind bereits standardisiert worden und werden in verschiedenen Anwendungsbereichen eingesetzt, siehe Kapitel 3.4.1.4. Denken Sie zum Beispiel an den Bau eines Hauses, bei dem ein Architekt ein standardisiertes Modell zur Beschreibung des Hauses verwendet. Ein Beispiel für Modelle, die von Bauarchitekten verwendet werden, sind Gebäudeinformationsmodelle (Building Information Models -BIM- [ISO19650]), die jene Elemente modellieren, die für die Planung, den Bau und die Verwaltung von Gebäuden und anderen Bauelementen erforderlich sind. Ein weiteres Beispiel ist die Elektronik, wo das Zeichnen von elektronischen Diagrammen standardisiert ist, damit Fachleute die Elektronik verstehen, berechnen und realisieren können. Um festzustellen, ob ein Diagramm korrekt angewendet wird, können wir die Qualitätskriterien eines Diagramms validieren. Diese Kriterien sind in Kapitel 3.4.1.5 beschrieben. 3.4.1.1 Syntax und Semantik Wenn Sie an eine natürliche Sprache denken, zum Beispiel an Ihre Muttersprache, wird sie durch ihre Grammatik und Semantik definiert. Die Grammatik beschreibt die Elemente (Wörter und Sätze) und die Regeln, denen die Sprache gehorchen muss. In einer Modellierungssprache wird dies die Syntax genannt, siehe Abbildung 3.3. Die Syntax beschreibt, welche Notationselemente (Symbole) in der Sprache verwendet werden. Sie beschriebt auch, wie diese Notationselemente in Kombination verwendet werden können. Foundation Level | Handbuch | © IREB 54 | 174 Abbildung 3.3 Syntax und Semantik einer Modellierungssprache Die Semantik definiert die Bedeutung der Notationselemente und legt die Bedeutung der Kombination von Elementen fest. Das Verständnis der Bedeutung der Notationselemente ist grundlegend, um das Risiko einer Fehlinterpretation des Modells zu vermeiden. 3.4.1.2 Eigenschaften eines Modells Ein Anforderungsmodell ist ein konzeptuelles Modell, das die Anforderungen an das zu entwickelnde System abbildet. Ein Modell wird auch zur Darstellung der aktuellen Situation verwendet, um die gegenwärtigen Probleme zu verstehen, zu analysieren und zu untersuchen. Konzeptuell bedeutet in diesem Zusammenhang, dass die Realität auf ihren Kern reduziert wird. Ein Modell hat einen hohen Abstraktionsgrad und reduziert die Realität auf das, was auf dieser allgemeinen Ebene relevant ist. Eine konzeptuelle Modellierungssprache kann (international) standardisiert werden und wird dann als formale Modellierungssprache bezeichnet. Ein Beispiel dafür ist die weit verbreitete und häufig angewandte Modellierungssprache UML (Unified Modeling Language). Ein Modell hat eine Reihe von Eigenschaften, die in den folgenden Abschnitten näher untersucht werden: ▪ Ein Modell wird für einen bestimmten Zweck erstellt. ▪ Ein Modell ist eine Darstellung der Wirklichkeit. ▪ Ein Modell dient dazu, Informationen zu reduzieren, damit wir die Realität besser verstehen oder uns auf einen Teil der Realität konzentrieren können. Foundation Level | Handbuch | © IREB 55 | 174 Ein Modell ist eine abstrakte Darstellung eines bestehenden oder zu schaffenden Teils der Realität. Der Begriff Realität umfasst jede denkbare Menge von Elementen, Erscheinungsformen oder Konzepten, einschließlich anderer Modelle. Der modellierte Teil der Realität wird als das Original bezeichnet. Das Verfahren zur Beschreibung des Originals kann deskriptiv oder präskriptiv sein. Die Modellierung des vorhandenen Originals wird als deskriptive Modellierung bezeichnet. Es zeigt die aktuelle Realität und spiegelt die Anforderungen wider, die erfüllt werden. Wenn noch kein Modell des Originals vorhanden ist, dann ist ein solches Modell das Ergebnis der Analyse der aktuellen Situation. Die Modellierung eines zu erstellenden Originals wird als präskriptive Modellierung bezeichnet. Es gibt an, welche zukünftige Realität erwartet oder gefordert wird. Wenn ein Modell mit deskriptiven Eigenschaften für die gegebene Situation existiert, kann daraus ein Modell mit präskriptiven Eigenschaften abgeleitet werden, indem angegeben wird, welche Anforderungen neu sind, geändert werden oder nicht mehr benötigt werden. Das präskriptive Modell beschreibt die angestrebte künftige Situation. Die Realität kann komplex sein. Wenn wir „zu viele” Details anwenden, kann ein Modell schwer zu erfassen sein. Diese komplexe Realität kann vereinfacht werden, indem die Informationsmenge im Modell reduziert wird. In einem Modell können wir irrelevante Informationen weglassen. Die Reduzierung der Informationsmenge kann uns ein besseres Verständnis der Realität ermöglichen und uns den Kern dieser Realität leichter verstehen lassen. Basierend auf dem beabsichtigten Zweck (erste Eigenschaft), für den das Modell angewendet wird, werden im Modell nur die relevanten Informationen angezeigt. Bitte beachten Sie, dass ein getrübtes oder falsches Bild der Realität entstehen kann, wenn „zu viele” Informationen weggelassen werden. Daher sollte sorgfältig geprüft werden, wie viele der Informationen weggelassen werden können, ohne die Realität zu verzerren. Foundation Level | Handbuch | © IREB 56 | 174 Es gibt verschiedene Möglichkeiten Informationen zu reduzieren: ▪ Durch Kompression oder Aggregation Das Aggregieren von Informationen ist eine Möglichkeit, Informationen abstrakter zu machen. Die Informationen werden von irrelevanten Details bereinigt und sind daher kompakter. Die Informationen sind sozusagen verdichtet. ▪ Durch Selektion Indem man nur die relevanten Informationen und nicht alles auswählt, ist es möglich das betrachtete Thema einzugrenzen. Der Schwerpunkt liegt auf einem bestimmten Teil oder einer bestimmten Anzahl von Teilen des Ganzen. Beide Arten der Informationsreduzierung können auch gemeinsam angewendet werden. Ein Modell ist eine Darstellung der Realität, und jedes Modell repräsentiert bestimmte Aspekte der Realität. Beispielsweise zeigt eine Konstruktionszeichnung die Aufteilung des Raums in einem Gebäude und ein elektrischer Schaltplan die Verdrahtung der elektrischen Schaltung. Beide Modelle stellen das Gebäude für einen bestimmten Zweck dar. Ein Modell wird für einen bestimmten Zweck in einem bestimmten Kontext erstellt. Im vorherigen Beispiel ist der Kontext der Entwurf und/oder die Realisierung eines Gebäudes. Die verschiedenen Bauzeichnungen stellen Informationen über einen bestimmten Aspekt des Gebäudes dar. Damit wird sofort klar, dass ein bestimmtes Modell nur dann verwendet werden kann, wenn es dem Zweck entspricht, für den das Modell erstellt wurde. 3.4.1.3 Vor- und Nachteile des Modellierens von Anforderungen Im Vergleich zu natürlichen Sprachen haben Modelle unter anderem die folgenden Vorteile: ▪ Die Elemente und ihre Verbindungen sind leichter zu verstehen und zu merken. Ein Bild sagt mehr als tausend Worte. Ein Bild, und auch ein Modell, kann leichter zu erfassen und zu merken sein. Beachten Sie, dass ein Modell nicht selbsterklärend ist und zusätzliche Informationen benötigt, d.h. eine Legende, Beispiele, Szenarien usw. ▪ Die Konzentration auf einen einzigen Aspekt reduziert die kognitive Anstrengung, die zum Verständnis der modellierten Anforderungen erforderlich ist. Da ein Modell einen spezifischen Zweck und eine reduzierte Informationsmenge hat, kann das Verständnis der modellierten Realität weniger Aufwand erfordern. ▪ Modellierungssprachen für Anforderungen haben eine eingeschränkte Syntax, die mögliche Mehrdeutigkeiten und Auslassungen reduziert. Foundation Level | Handbuch | © IREB 57 | 174 Da die Modellierungssprache (Syntax und Semantik) einfacher ist - d.h. eine begrenzte Anzahl von Notationselementen und strengere Sprachregeln im Vergleich zur natürlichen Sprache - ist die Gefahr von Verwechslungen und Auslassungen geringer. ▪ Höheres Potenzial für die automatisierte Analyse und Verarbeitung von Anforderungen. Da eine Modellierungssprache formaler ist (begrenzte Anzahl von Notationselementen und strengere Sprachregeln) als eine natürliche Sprache, eignet sie sich besser für die Automatisierung der Analyse oder Verarbeitung von Anforderungen. Trotz der großen Vorteile bei der Visualisierung von Anforderungen mit Modellen, haben Modelle auch ihre Grenzen. ▪ Modelle, die sich auf einzelne Aspekte konzentrieren, konsistent zu halten, ist eine Herausforderung. Wenn mehrere Modelle zur Beschreibung von Anforderungen verwendet werden, ist es wichtig diese Modelle miteinander konsistent zu halten. Dies erfordert ein hohes Maß an Disziplin und Koordination zwischen den Modellen. ▪ Informationen aus verschiedenen Modellen müssen zu einem besseren kausalen Verständnis integriert werden. Wenn mehrere Modelle verwendet werden, müssen alle Modelle verstanden werden, um ein gutes Verständnis der Anforderungen zu ermöglichen. ▪ Modelle konzentrieren sich hauptsächlich auf funktionale Anforderungen. Die Modelle zur Beschreibung von Qualitätsanforderungen und Randbedingungen sind begrenzt, sofern sie im spezifischen Kontext nicht sogar fehlen. Diese Arten von Anforderungen sollten dann in natürlicher Sprache zusammen mit den Modellen geliefert werden, zum Beispiel als separates Arbeitsprodukt. ▪ Die eingeschränkte Syntax einer grafischen Modellierungssprache impliziert, dass nicht jede relevante Information in einem Modell ausgedrückt werden kann. Da ein Modell für einen bestimmten Zweck und Kontext erstellt wird, ist es nicht immer möglich, alle Anforderungen in dem Modell oder in mehreren Modellen festzuhalten. Anforderungen, die sich nicht in Modellen ausdrücken lassen, werden dem Modell als natürlichsprachige Anforderungen oder als separates Arbeitsprodukt hinzugefügt. Daher sollten Anforderungsmodelle immer von natürlicher Sprache begleitet sein [Davi1995]. 3.4.1.4 Anwendung von Anforderungsmodellen Wie in den vorangegangenen Abschnitten angedeutet, gibt es gängige Modelle für verschiedene Anwendungsbereiche. In der Architektur gibt es z.B. Konstruktionszeichnungen, Rohrleitungspläne, Schaltpläne usw., um die Spezifikationen Foundation Level | Handbuch | © IREB 58 | 174 eines Gebäudes auszudrücken. In anderen Gebieten - zum Beispiel in der SoftwareEntwicklung - gibt es Modellierungssprachen, die in dieser Art von Kontext nützlich sind. Ein wichtiger Aspekt bei der Anwendung von Modellen ist die Verwendung von Modellen, die im jeweiligen Kontext üblich sind oder die speziell für einen bestimmten Kontext entwickelt wurden. Viele Modellierungssprachen, zum Beispiel UML [OMG2017] oder BPMN [OMG2013], wurden standardisiert. Wenn Anforderungen in einer nicht standardisierten Modellierungssprache spezifiziert werden, sollte dem Leser die Syntax und Semantik der Sprache erklärt werden, z.B. durch eine Legende. Modelle werden verwendet, um Anforderungen aus einer bestimmten Perspektive zu beschreiben. Bei der Systementwicklung werden funktionale Anforderungen in die folgenden Perspektiven kategorisiert (siehe auch Kapitel 3.1.4): ▪ Struktur und Daten Modelle, die sich auf die statischen Struktureigenschaften eines Systems oder einer Domäne konzentrieren ▪ Funktion und Ablauf Modelle, die sich auf die Abfolge von Aktionen konzentrieren, die erforderlich sind, um aus gegebenen Eingaben die gewünschten Ergebnisse zu erzielen, oder auf die zur Ausführung eines (Geschäfts-)Prozesses erforderlichen Aktionen, einschließlich des Kontroll- und Datenflusses zwischen den Aktionen und der Frage, wer für welche Aktion verantwortlich ist ▪ Zustand und Verhalten Modelle, die sich auf das Verhalten eines Systems oder den Lebenszyklus von Geschäftsobjekten im Hinblick auf zustandsabhängige Reaktionen auf Ereignisse oder die Dynamik der Interaktion von Komponenten konzentrieren Die Beschaffenheit des Systems, das modifiziert oder erstellt wird, gibt die Richtung für die zu verwendenden Modelle vor. Wenn es zum Beispiel die Aufgabe des Systems ist Informationen und Beziehungen zu verarbeiten, dann ist zu erwarten, dass es eine ganze Reihe von funktionalen Anforderungen gibt, die diese Informationen und Beziehungen beschreiben. Als Ergebnis verwenden wir eine passende Modellierungssprache, die sich zur Modellierung von Daten und ihrer Struktur eignet. Natürlich wird ein System aus einer Kombination der oben genannten Perspektiven bestehen. Daraus folgt, dass ein System aus mehreren Perspektiven modelliert werden muss. In den Kapiteln 0 bis 3.4.5 werden die verschiedenen Modelle für jede Perspektive ausführlicher erläutert. Bevor die Anforderungen erhoben und dokumentiert werden - zum Beispiel mit Modellen wird eine Bestandsaufnahme der Ziele und des Kontexts vorgenommen. Diese können ebenfalls modelliert werden, siehe Kapitel 3.4.6 bzw. 3.4.2. Die Verwendung von Modellen hilft uns vor allem in Bezug auf: Foundation Level | Handbuch | © IREB 59 | 174 ▪ ▪ Spezifizieren von (primär funktionalen) Anforderungen, um textuell erfasste Anforderungen teilweise oder sogar vollständig zu ersetzen Zerlegen einer komplexen Realität in klar definierte und sich ergänzende Aspekte; jeder Aspekt wird durch ein spezifisches Modell dargestellt, das uns hilft, die Komplexität der Realität zu erfassen ▪ Umschreiben von textuell beschriebenen Anforderungen, um ihre Verständlichkeit zu verbessern, insbesondere im Hinblick auf die Beziehungen zwischen ihnen ▪ Validieren von textuell beschriebenen Anforderungen mit dem Ziel, Auslassungen, Mehrdeutigkeiten und Inkonsistenzen aufzudecken Die Modellierung von Anforderungen hilft auch bei der Strukturierung und Analyse von Wissen. Sie können Diagramme verwenden, um Ihre eigenen Gedanken zu strukturieren und ein besseres Verständnis des Systems und seines Kontexts zu erhalten. 3.4.1.5 Qualitätsaspekte eines Anforderungsmodells Dies ist ein zusätzlicher Abschnitt, für den es keine Fragen in der CPRE Foundation Level Prüfung geben wird. Ein wesentlicher Teil der Anforderungsmodelle sind Diagramme oder grafische Darstellungen. Die Qualität eines Anforderungsmodells wird durch die Qualität der einzelnen Diagramme und ihrer gegenseitigen Beziehungen bestimmt. Die Qualität der einzelnen Diagramme wiederum wird durch die Qualität der Modellelemente innerhalb der Diagramme bestimmt. Die Qualität der Anforderungsmodelle und Modellelemente kann anhand von drei Kriterien bewertet werden [LiSS1994]: ▪ Syntaktische Qualität ▪ Semantische Qualität ▪ Pragmatische Qualität Die syntaktische Qualität drückt aus, inwieweit ein einzelnes Modellelement (grafisch oder textuell), ein Anforderungsdiagramm oder ein Anforderungsmodell, mit den syntaktischen Spezifikationen übereinstimmt. Wenn z. B. ein Modell, das die Anforderungen als Klassenmodell beschreibt, Modellierungselemente enthält, die nicht Teil der Syntax sind, oder Modellelemente unsachgemäß verwendet werden, verringert dies die syntaktische Qualität des Modells. Ein Stakeholder dieses Modells - z.B. ein Tester - könnte die Informationen, die durch das Modell dargestellt werden, falsch interpretieren. Dies könnte schließlich zu ungeeigneten Testfällen führen. Werkzeuge zur Anforderungsmodellierung bieten Möglichkeiten zur Überprüfung der syntaktischen Qualität der Modelle. Die semantische Qualität drückt aus, inwieweit ein einzelnes Modellelement (grafisch oder textuell), das Anforderungsdiagramm oder das Anforderungsmodell, den Sachverhalt korrekt und vollständig wiedergibt. Foundation Level | Handbuch | © IREB 60 | 174 Genau wie in der natürlichen Sprache gibt die Semantik den Wörtern Bedeutung. Wenn ein Begriff unterschiedliche Bedeutungen haben kann oder es mehrere Begriffe gibt, die die gleiche Bedeutung haben, kann dies zu Missverständnissen führen. Dasselbe gilt für die Semantik von Modellierungselementen. Wenn die Modellierungselemente falsch interpretiert oder falsch angewendet werden, kann es zu einer Fehlinterpretation des Modells kommen. Die pragmatische Qualität drückt aus, inwieweit ein einzelnes Modellelement (grafisch oder textuell), das Anforderungsdiagramm oder das Anforderungsmodell, für die beabsichtigte Nutzung geeignet ist, d.h. ob der Detaillierungsgrad und die Abstraktionsebene für die beabsichtigte Nutzung angemessen sind und ob ein geeignetes Modell im Hinblick auf die Domäne oder den Kontext ausgewählt wurde. Dies kann beurteilt werden, wenn der Zweck und die Stakeholder des Diagramms bekannt sind. Zwischenversionen des Modells können den interessierten Stakeholdern vorgelegt werden, um zu überprüfen, ob die Diagramme ihren Zweck erfüllen. Während der Validierung der Anforderungen wird die Qualität der verwendeten Modellierungsdiagramme bewertet, um sicherzustellen, dass diese Diagramme ihrem beabsichtigten Zweck und ihren Nutzen erfüllen. 3.4.1.6 Das Beste aus beiden Welten Wie im vorigen Kapitel erläutert, haben Anforderungen, die in textueller oder visueller/grafischer Form (d.h. über Anforderungsmodelle) ausgedrückt werden, ihre Vorund Nachteile. Durch die Verwendung sowohl textueller als auch grafischer Darstellungen der Anforderungen, können wir uns die Stärken und Vorteile beider Darstellungsformen zunutze machen. Die Ergänzung eines Modells um textuelle Anforderungen verleiht dem Modell mehr Bedeutung. Eine weitere nützliche Kombination besteht darin, dass wir Qualitätsanforderungen und Randbedingungen mit einem Modell oder einem bestimmten Modellierungselement verknüpfen können. Dies vermittelt ein vollständigeres Bild der spezifischen Anforderungen. Die Verwendung von Modellen kann auch die textuellen Anforderungen unterstützen. Das Hinzufügen von Modellen und Bildern zu den Textanforderungen unterstützt diese Modelle für ein besseres Verständnis und eine bessere Übersicht. 3.4.2 Modellierung des Systemkontexts Kapitel 2, Prinzip 4 führt den Gedanken ein, dass Anforderungen nie isoliert betrachtet werden dürfen und dass der Systemkontext, wie etwa bestehende Systeme, Prozesse und Benutzer, bei der Definition der Anforderungen für das neue oder geänderte System berücksichtigt werden muss. Kontextmodelle spezifizieren die strukturelle Einbettung des Systems in seine Umgebung, mit seinen Interaktionen mit den Nutzern des Systems sowie mit anderen neuen oder bestehenden Systemen innerhalb des jeweiligen Kontexts. Ein Kontextmodell ist keine grafische Beschreibung der Anforderungen, sondern dient dazu einige der Quellen der Foundation Level | Handbuch | © IREB 61 | 174 Anforderungen aufzudecken. Abbildung 3.4 bietet ein abstraktes Beispiel für ein System und seine Umgebung, mit seinen Schnittstellen zu den Benutzern des Systems und seinen Schnittstellen zu anderen Systemen. So helfen Kontextdiagramme sowohl Benutzer- als auch Systemschnittstellen zu identifizieren. Wenn das System mit Benutzern interagiert, müssen die Benutzerschnittstellen in einem späteren Schritt während des RE festgelegt werden. Wenn das System mit anderen Systemen interagiert, müssen die Schnittstellen zu diesen Systemen in einem späteren Schritt genauer definiert werden. Schnittstellen zu anderen Systemen sind möglicherweise bereits vorhanden oder müssen entwickelt oder modifiziert werden. Abbildung 3.4 Ein System in seinem Kontext Auch wenn es keine standardisierte Modellierungssprache für Kontextmodelle gibt, so werden Kontextmodelle häufig durch folgende Diagramme dargestellt: ▪ Datenflussdiagramme aus der strukturierten Analyse [DeMa1978] ▪ UML Use Case Diagramme [OMG2017] ▪ Hinweis: Das UML Use Case Modell besteht aus zwei Elementen: dem UML Use Case Diagramm (siehe Abbildung 3.6) und der Use Case Spezifikation (Kapitel 3.4.2.2). Dieses Kapitel konzentriert sich auf die Modellierung mit UML Use Case Diagrammen. ▪ Maßgeschneiderte Box-and-Line-Diagramme [Glin2019] Im Bereich des Systems Engineering können SysML-Blockdefinitionsdiagramme [OMG2018] angepasst werden, um Kontextmodelle auszudrücken, indem stereotype Blöcke für das System und die Akteure verwendet werden. In den nächsten beiden Unterkapiteln stellen wir die Notation von Datenflussdiagrammen (DFD) und UML Use Case Diagrammen zur Modellierung des Kontexts eines Systems vor. Foundation Level | Handbuch | © IREB 62 | 174 Diese beiden Beispiele beschreiben nicht den vollständigen Kontext, sondern heben den Kontext aus einem bestimmten Blickwinkel hervor. 3.4.2.1 Datenflussdiagramm Der Systemkontext kann aus verschiedenen Perspektiven betrachtet werden. Bei der strukturierten Analyse von Systemen [DeMa1978] ist vom Kontextdiagramm die Rede. Dieses Diagramm ist ein spezielles Datenflussdiagramm (DFD), in dem das System durch einen Prozess (das System) dargestellt wird. Abbildung 3.5 zeigt ein Beispiel für ein Kontextdiagramm. Abbildung 3.5 Beispiel eines DFD als Kontextdiagramm Das System wird zentral im Modell platziert. Es hat einen klaren Namen, damit die Leser wissen, welches System in Erwägung gezogen wird. Die Rechtecke um das System sind Terminatoren (Schnittstellen zur Umwelt): Kunde, Druckerei und Finanzverwaltung. Ein Terminator, der dem System Informationen oder Dienste zur Verfügung stellt, wird als Quelle bezeichnet. Terminator, der Informationen oder Dienste aus dem System entnimmt, wird als Senke bezeichnet. Terminator kann je nach den bereitgestellten oder abgerufenen Daten eine der beiden Rollen einnehmen, wie z.B. der Kunde im obigen Beispiel. Foundation Level | Handbuch | © IREB 63 | 174 Die Pfeile im Beispiel zeigen, wie die Informationen von den Terminatoren in das System (Quelle) und vom System zu den Terminatoren (Senken) fließen. Die Pfeile erhalten einen logischen Namen, der beschreibt, welche Informationen übertragen werden. Auf der Ebene des Kontextdiagramms werden irrelevante Details weggelassen. Der Informationsfluss zwischen dem Kunden und dem System enthält z.B. Kundendaten. Welche Informationen (Name, Geburtsdatum, E-Mail-Adresse, Telefonnummer, Lieferadresse, Rechnungsadresse usw.) die Kundendaten umfassen, muss für diese Abstraktionsebene noch nicht relevant sein. Der Informationsfluss kann aus materiellen (Materialien) und immateriellen (Informationen) Objekten bestehen. Auch gibt es auf dieser konzeptionellen Ebene (noch) keinen Hinweis darauf, wie - E-Mail, Website, Formular usw. - die Informationen bereitgestellt werden. Das Hinzufügen zusätzlicher Details zum Kontextdiagramm kann es für die beteiligten Stakeholder klarer machen und zur Verbesserung des gemeinsamen Verständnisses beitragen. Diese Details müssen für jede einzelne Situation ausgearbeitet werden. Die Verwendung eines Datenflussdiagramms zur Modellierung des Systemkontexts bietet einige Erkenntnisse über die Wechselwirkungen des Systems mit seiner Umgebung, z.B.: ▪ Die Schnittstellen zu Menschen, Abteilungen, Organisationen und anderen Systemen in der Umwelt ▪ Die (materiellen und immateriellen) Objekte, die das System aus der Umwelt erhält ▪ Die (materiellen und immateriellen) Objekte, die durch das System erzeugt und an die Umwelt abgegeben werden Ein Datenflussdiagramm zeigt eine klare Abgrenzung zwischen dem System und seiner Umgebung an. Die relevanten Benutzer und Systeme der Umwelt werden bei der Ermittlung der Anforderungen identifiziert (Kapitel 4.1). DFD Kontextdiagramme können helfen, den Kontext zu strukturieren, um ein gemeinsames Verständnis des Systemkontexts und der Systemgrenze zu erreichen. 3.4.2.2 UML Use Case Diagramm Eine andere Sicht auf den Kontext eines Systems kann aus einer funktionalen Perspektive erreicht werden. Das UML Use Case Diagramm ist ein üblicher Weg zur Modellierung der funktionalen Aspekte eines Systems und der Systemgrenzen sowie der Interaktionen des Systems mit Benutzern und anderen Systemen. Use Cases bieten eine einfache Möglichkeit die verschiedenen Funktionen innerhalb des definierten Bereichs systematisch aus Anwendersicht zu beschreiben. Dies unterscheidet sich von den Kontextdiagrammen des DFD, bei denen das System als eine große Blackbox dargestellt wird. Use Cases wurden zuerst als Methode zur Dokumentation der Funktionen eines Systems in [Jaco1992] vorgeschlagen. UML Use Cases bestehen aus Use Case Diagrammen mit zugehörigen textuellen Use Case Spezifikationen (siehe Kapitel 3.3.2). Eine Use Case Spezifikation spezifiziert jeden Use Case im Detail, indem sie z.B. die möglichen Aktivitäten des Use Case, seine Verarbeitungslogik sowie seine Vor- und Nachbedingungen der Ausführung beschreibt. Die Spezifikation von Use Cases ist im Wesentlichen textuell - zum Beispiel über Use Case Vorlagen, wie in [Cock2001] empfohlen. Foundation Level | Handbuch | © IREB 64 | 174 Wie bereits erwähnt, zeigt ein UML Use Case Diagramm die Funktionen (Use Cases) aus der Sicht der direkten Benutzer und anderer Systeme, die mit dem betrachteten System interagieren. Der Name des Use Case setzt sich in der Regel aus einem Verb und einem Substantiv zusammen. Dadurch ergibt sich eine kurze Beschreibung der vom System angebotenen Funktion, wie das Beispiel in Abbildung 3.6 zeigt. Abbildung 3.6 Beispiel für ein Kontextdiagramm unter Anwendung eines UML Use Case Diagramms Die Akteure sind die direkten Benutzer oder Systeme, die mit dem betrachteten System interagieren. Der Akteur (Benutzer oder System), der den Use Case aufruft, erhält den Nutzen, den der Use Case liefert (z.B. dem Kunden den Status einer Bestellung anzuzeigen). Die Assoziation verbindet den Akteur mit dem relevanten Use Case, aber sie dokumentiert keine Richtung oder Datenfluss (wie es in DFDs geschieht); sie drückt nur aus, dass der Akteur den Nutzen aus dem Use Case erhält. Ein UML Use Case Diagramm beschreibt die Funktionalität, die das System seiner Umgebung bietet. Die Trennung zwischen der Funktionalität im System und den Akteuren im Kontext wird mit der Systemgrenze (Rechteck um die Use Cases, z.B. „Buchbestellsystem”) visualisiert. Use Case Diagramme unterstützen die Schärfung der Systemgrenze und die Überprüfung, ob der Funktionsumfang des Systems auf einer hohen Ebene abgedeckt ist. Jeder Use Case enthält auch eine detaillierte Use Case Spezifikation, in der Vorbedingungen, Auslöser, Aktionen, Nachbedingungen, Akteure usw. dokumentiert sind. Use Cases werden in der Regel unter Verwendung einer Vorlage beschrieben (Kapitel 3.3). Wenn die Szenarien eines Use Case komplex oder groß werden, wird empfohlen, diese Szenarien mit UMLAktivitätsdiagrammen zu visualisieren, siehe Kapitel 3.4.4.1. Die detaillierte Spezifikation von Use Cases ist nicht Teil der Kontextmodellierung und kann zu einem späteren Zeitpunkt ausgearbeitet werden, wenn diese Informationen relevant werden. Foundation Level | Handbuch | © IREB 65 | 174 3.4.3 Modellierung von Struktur und Daten Für funktionale Anforderungen aus der Perspektive von Geschäftsobjekten (siehe Kapitel 3.1.4) stehen verschiedene Datenmodelle zur Verfügung. Ein (Geschäfts-)Objekt kann ein materielles oder immaterielles Objekt sein, wie z.B. ein Fahrrad, ein Pedal, eine Fahrradglocke, aber auch eine Trainingsanfrage, ein Einkaufskorb mit digitalen Produkten und so weiter. Ein (Geschäfts-)Objekt ist „etwas” in der realen Welt. Einige (oder vielleicht alle) dieser (Geschäfts-)Objekte werden von dem betrachteten System verwendet. Das System verwendet diese Objekte als Eingabe zur Verarbeitung, zur Speicherung und/oder zur Bereitstellung von Ausgaben. Datenmodelle werden verwendet, um die (Geschäfts)Objekte zu beschreiben, die dem System bekannt sein müssen. Diese Arten von Diagrammen modellieren das Objekt, die Attribute des Objekts und die Beziehungen zwischen Objekten. Der Einfachheit halber sprechen wir von der Modellierung von Strukturen und den Daten - diese stellen jedoch Informationsstrukturen zwischen (Geschäfts-)Objekten in der realen Welt dar. Es gibt eine Reihe gängiger Modelle zur Darstellung von Struktur und Daten: ▪ Entity-Relationship-Diagramme (ERD) [Chen1976] ▪ UML Klassendiagramme [OMG2017]. Siehe Kapitel ▪ SysML-Blockdefinitionsdiagramme [OMG2018]. Siehe Kapitel 3.4.6.2 Um das Konzept der Struktur- und Datenmodellierung zu erläutern, wird in diesem Kapitel das UML Klassendiagramm als Beispiel verwendet. UML, kurz für Unified Modeling Language, besteht aus einem integrierten Satz von Diagrammen. Dieser Satz von Diagrammen ist eine Sammlung bewährter Verfahren und hat sich bei der Modellierung komplexer und großer Systeme als erfolgreich erwiesen. UML wurde in den 1990er Jahren von Grady Booch, James Rumbaugh und Ivar Jacobson entwickelt und ist seit 1997 eine standardisierte Modellierungssprache. Wenn eine Vertiefung oder ein anderes Modell benötigt wird, lesen Sie die angegebene Literatur und praktizieren Sie mit der gewünschten Modellierungssprache. 3.4.3.1 UML Klassendiagramme UML ist eine Zusammenstellung unterschiedlicher Modelle, die zur Beschreibung eines Systems verwendet werden können. Eines dieser Modelle ist das Klassendiagramm. Ein Klassendiagramm stellt eine Menge von Klassen und Assoziationen zwischen ihnen dar. Wir diskutieren nur die gebräuchlichen und einfachen Notationselemente dieses Modells. Wenn eine Vertiefung gewünscht wird, verweisen wir auf die Literatur oder das CPRE Advanced Level Requirements Modeling. Foundation Level | Handbuch | © IREB 66 | 174 In der unten stehenden Übersicht finden Sie die gebräuchlichsten Notationselemente. Abbildung 3.7 Teilmenge der Modellierungselemente von UML-Klassendiagrammen In einem Klassenmodell finden Sie die Konzepte und Begriffe, die in der Domäne relevant sind. Diese Konzepte beinhalten eine klare Definition, die im Glossar enthalten ist. Durch die Verwendung von Datenmodellen wird das Glossar um Informationen über die Struktur und den Zusammenhang (Kohärenz) der Begriffe und Konzepte erweitert. Eine klare Definition und Kohärenz der verwendeten Begriffe verhindert eine Fehlkommunikation über das zu behandelnde Thema. Abbildung 3.8 zeigt ein vereinfachtes Modell des Buchbestellsystems (siehe Beispiele für den Kontext in Kapitel 3.4.2). Die statischen Informationen, die das System zur Ausführung seiner Funktion benötigt - das Bestellen eines Buches - werden modelliert. Ein Kunde bestellt ein Buch und somit werden Informationen für die Klassen Kunde, Bestellung und Buch persistiert. Ein Kunde kann eine Bestellung aufgeben, daher besteht eine Beziehung (Assoziation) zwischen Kunde und Bestellung. Ein Kunde bzw. eine Kundin kann im Laufe der Zeit mehrere Bestellungen aufgeben, und er/sie wird nur zum Kunden, wenn er/sie eine Bestellung aufgibt. Diese Information bestimmt die Multiplizität: 1 Kunde gibt 1 oder mehrere Bestellungen auf. Die Tatsache, dass ein Kunde ein Buch bestellen kann, bedeutet, dass es auch eine Beziehung zwischen den Klassen Bestellung und Buch gibt. Um das Beispiel einfach zu Foundation Level | Handbuch | © IREB 67 | 174 halten, kann der Kunde hier jeweils nur ein Buch auf einmal bestellen. Außerdem muss eine Bestellung mindestens ein Buch enthalten. Eine Bestellung, die kein Buch enthält, ist keine Bestellung. In der Klasse Buch wird auch das Attribut aufLager gepflegt. Informationen wie „Wenn der Bestand nicht ausreicht, um die Bestellung zu erfüllen, wird ein Druckauftrag an die Druckerei geschickt” können nicht modelliert werden. Dies ist eine Art von Information, die nicht in einem Klassendiagramm modelliert werden kann, da sie eine bestimmte Funktionalität des Systems beschreibt. Diese Informationen sind Teil der Anforderungen und sollten in einem anderen Arbeitsprodukt dokumentiert werden. Es kann als textuelle Anforderung hinzugefügt werden, die dem Klassendiagramm beiliegt, oder mit einem anderen Diagramm modelliert werden, z. B. einem UML-Aktivitätsdiagramm (siehe Kapitel 3.4.4.1). Abbildung 3.8 Beispiel für ein einfaches UML-Klassendiagramm 3.4.4 Modellierung von Funktion und Ablauf Funktion und Ablauf beschreiben, wie das (Teil-)System die Eingaben in Ausgaben umwandeln soll. Wir können diese Art von Anforderungen mit Modellen visualisieren, die Funktion und Ablauf abbilden. Im Gegensatz zur Datenmodellierung, die im Wesentlichen nur einen Diagrammtyp benötigt, können Funktion und Ablauf aus verschiedenen Blickwinkeln betrachtet werden. Abhängig von den Bedürfnissen der Stakeholder, den nächsten Schritt im Entwicklungsprozess zu gehen, ist möglicherweise mehr als ein Modell erforderlich, um die Anforderungen an Funktion und Ablauf zu dokumentieren. Foundation Level | Handbuch | © IREB 68 | 174 Einige gängige Modelle zur Darstellung von Funktion und Ablauf sind: ▪ UML Use Case Diagramm [OMG2017]. Siehe Kapitel 3.4.2.2 ▪ UML Aktivitätsdiagramm [OMG2017]. Siehe Kapitel 3.4.4.1 ▪ Datenflussdiagramm [DeMa1978]. Siehe Kapitel 3.4.2.1 ▪ Domänen-Story-Modelle [HoSch2020]. Siehe Kapitel 3.4.6.3 ▪ Business Process Modeling Notation (BPMN, deutsch Geschäftsprozessmodell und notation) [OMG2013]. Exkurs: BPMN Prozessmodelle werden zur Beschreibung von Geschäftsprozessen oder technischen Prozessen verwendet. BPMN wird häufig zur Darstellung von Geschäftsprozessmodellen verwendet. Um das Konzept der Funktions- und Ablaufmodellierung zu erläutern, beschränken wir uns in diesem Kapitel auf einige Beispiele von UML-Diagrammen. Wenn eine Vertiefung oder ein anderes Modell benötigt wird, so lesen Sie die angegebene Literatur und praktizieren Sie mit der entsprechenden Modellierungssprache. 3.4.4.1 UML Aktivitätsdiagramm UML Aktivitätsmodelle werden verwendet, um Systemfunktionen zu spezifizieren. Sie stellen Elemente für die Modellierung von Aktionen und den Kontrollfluss zwischen Aktionen zur Verfügung. Aktivitätsdiagramme können auch ausdrücken, wer für welche Aktion verantwortlich ist. Fortgeschrittene Modellierungselemente (die in diesem Lehrplan nicht behandelt werden) bieten Mittel zur Modellierung des Datenflusses. Ein UML-Aktivitätsdiagramm drückt den Kontrollfluss der Aktivitäten eines (Teil-)Systems aus. Ablaufsdenken entsteht durch die Visualisierung von Programmcode mit Flussdiagrammen (nach [DIN66001], [ISO5807]). Dies half Programmierern komplexe Strukturen und Abläufe in Programmen zu konzipieren und zu verstehen. Mit der Einführung der UML [OMG2017] wurde ein Modell zur Visualisierung von Aktivitäten und Aktionen aus einer funktionalen Perspektive eingeführt. Foundation Level | Handbuch | © IREB 69 | 174 In der untenstehenden Übersicht finden Sie die grundlegenden Notationselemente. Abbildung 3.9 Grundlegende Notationselemente des UML-Aktivitätsdiagramms Mit diesem Satz an grundlegenden Notationselementen können Sie ein einfaches sequenzielles Aktivitätsdiagramm erstellen. Wenn mehr Kontrolle erforderlich ist, kann das Modell durch Entscheidungen und parallele Abläufe von Aktivitäten unter Verwendung der unten aufgeführten Notationselemente erweitert werden. Abbildung 3.10 Entscheidungen und parallele Abläufe in einem UML-Aktivitätsdiagramm Aktivitätsdiagramme können verwendet werden, um die Verarbeitungslogik von Use Case Szenarien im Detail zu spezifizieren (siehe Kapitel 3.3.2). Zur Visualisierung der Szenarien werden Aktivitätsdiagramme erstellt, die Prozesse mit Aktivitäten und Verarbeitungslogik darstellen. Solange das Diagramm verständlich bleibt, kann das Hauptszenario zusammen mit den Alternativszenarien und den Ausnahmeszenarien als Teil desselben Diagramms modelliert werden. Foundation Level | Handbuch | © IREB 70 | 174 Abbildung 3.11 gibt ein einfaches Beispiel für das Buchbestellsystem. Dieser vereinfachte Handlungsablauf beginnt, wenn der Kunde seine Bestellung aufgibt. Zuerst werden die Bestellung und die Kundeninformationen validiert, um festzustellen, ob alle (notwendigen) Informationen geliefert werden. Wenn entweder die Bestellung oder die Kundeninformationen ungültig (falsch oder unzureichend) sind, wird eine Benachrichtigung an den Kunden gesendet und der Bestellvorgang abgebrochen. Das Hauptszenario ist, dass die Bestell- und Kundeninformationen gültig sind. Das Szenario, dass die Bestell- oder Kundeninformationen ungültig sind, wird als Ausnahmefluss (Ausnahmeszenario) bezeichnet und behandelt eine funktional fehlerhafte Bedingung im Prozess. Wenn sowohl die Bestell- als auch die Kundeninformationen korrekt sind, wird der Bestand überprüft. Wenn eine ausreichende Anzahl von Produkten auf Lager ist, wird die Bestellung kommissioniert und an den Kunden geschickt. Wenn nicht genügend Produkte auf Lager sind, wird ein alternativer Fluss gestartet. Es wird eine Anfrage für einen Druckauftrag an die Druckerei gesendet und eine Benachrichtigung über eine Nachlieferung wird an den Kunden gesendet. Abbildung 3.11 Beispiel für ein UML-Aktivitätsdiagramm Foundation Level | Handbuch | © IREB 71 | 174 Innerhalb des Buchbestellsystems gibt es auch andere Abläufe, die vom Bestell- und Lieferprozess getrennt sind. Beispielsweise haben die Zahlungs-, Nachlieferungs- und Rechnungsprozesse getrennte Abläufe, um eine klare Trennung der Belange zu ermöglichen. Wenn z.B. beschlossen wird, keine Produkte mehr auf Lager zu halten, dann ist der Bestellund Lieferprozess weiterhin gültig. Falls Änderungen in diesem Fluss erforderlich sind, betreffen diese Änderungen nicht die anderen Flüsse. Diese Zerlegung der Funktionalität trägt dazu bei, die Dinge einfach und klar zu halten. 3.4.5 Zustands- und Verhaltensmodellierung Funktionale Anforderungen, die das Verhalten, die Zustände und die Übergänge eines (Sub)Systems oder eines Geschäftsobjekts beschreiben, sind Anforderungen aus der Verhaltensperspektive. Ein Beispiel für einen Systemzustand ist Ein, Standby oder Aus. Ein Geschäftsobjekts kann einen Lebenszyklus haben, der eine Reihe von vorgeschriebenen Zuständen durchläuft. Beispielsweise kann sich ein Geschäftsobjekts Auftrag in folgenden Zuständen befinden Erteilt, Validiert, Bezahlt, Versandt und Abgeschlossen. Eine weit verbreitete Technik zur Beschreibung des Verhaltens eines Systems sind Zustandsdiagramme [Hare1988]. Statecharts sind Zustandsmaschinen mit Zuständen, die hierarchisch und/oder orthogonal zerlegt sind. Zustandsmaschinen, einschließlich Statecharts, können in der Modellierungssprache UML [OMG2017] mit Zustandsdiagrammen dargestellt werden. Zustandsdiagramme beschreiben Zustandsmaschinen, die endlich sind. Das bedeutet, dass diese Systeme schließlich einen Endzustand erreichen. Ein Zustandsdiagramm zeigt die Zustände, die das System oder ein Objekt annehmen kann. Es gibt auch an, wie der Zustand wechselt, d.h. den Zustandsübergang. Ein System tut von sich aus wenig. Das Wechseln des Zustands erfordert einen Trigger aus dem System oder aus der Systemumgebung. Zu den gängigen Modellen zur Darstellung von Verhalten und Zuständen gehören: ▪ Zustandsdiagramme [Hare1988] ▪ UML Zustandsdiagramm [OMG2017] 3.4.5.1 UML Zustandsdiagramm Um das Konzept der Modellierung von Verhalten und Zuständen zu erläutern, wird in diesem Kapitel das UML-Zustandsdiagramm als Beispiel verwendet. Wenn eine Vertiefung oder ein anderes Modell benötigt wird, so lesen Sie die angegebene Literatur und praktizieren Sie mit der entsprechenden Modellierungssprache. Foundation Level | Handbuch | © IREB 72 | 174 In der untenstehenden Übersicht finden Sie die grundlegenden Notationselemente. Abbildung 3.12 Grundlegende Notationselemente des UML-Zustandsdiagramms Wie zu Beginn des Kapitels besprochen, kann ein Zustandsdiagramm die Zustände deutlich machen, die ein Objekt annehmen kann. Wir sehen hier eine Möglichkeit, zusätzliche (und teilweise redundante) Informationen eines Objekts zu visualisieren. Stellen Sie sich vor, Sie bestellen ein Buch auf einer Website und möchten den Status Ihrer Bestellung verfolgen. Eine Bestellung wird in der realen Welt verwendet und wird als Geschäftsobjekt in einem Klassendiagramm (siehe Abbildung 3.8) höchstwahrscheinlich mit einem Attribut Status modelliert. Das Klassendiagramm zeigt an, dass das Attribut Status eine begrenzte Anzahl von Werten annehmen kann, wie z.B. Validiert, Bezahlt, Geliefert, Storniert und so weiter. Das Klassendiagramm beschreibt nicht die Reihenfolge der möglichen Statusänderungen. Ein Klassendiagramm beschreibt auch nicht das Verhalten des Systems in einem bestimmten „Status”. Dies kann mit einem UML-Zustandsdiagramm verdeutlicht werden, z.B. dass eine Bestellung nicht direkt in den Status Geliefert übergehen kann, ohne, dass der Kunde für den Auftrag bezahlt hat. Abbildung 3.13 zeigt ein Beispiel für ein Zustandsdiagramm des Buchbestellsystems. Im Klassendiagramm (Abbildung 3.8) des Buchbestellsystems wird ein Objekt Bestellung modelliert. Dieses Objekt hat einen Attribut Status, das eine begrenzte Anzahl von Werten einnehmen kann. Diese Werte werden im Klassendiagramm aufgelistet und erläutert. Was ein Klassendiagramm nicht beschreibt, ist der Ablauf, in der die Bestellung verarbeitet wird. Ein Zustandsdiagramm visualisiert die Zustände und Übergänge zwischen den Zuständen und macht die Abfolge des Bestellstatus deutlich. Das Zustandsdiagramm zeigt z.B., dass die Bestellung nicht gesendet werden kann, bevor sie vollständig kommissioniert ist (Übergang zwischen den Zuständen Kommissioniert und Gesendet). Und, wenn die Bestellung im Zustand Gesendet ist, kann der nächste Zustand nur Bezahlt sein. Ein Übergang von Gesendet zu Bearbeitet ist nicht möglich. Dieses Diagramm macht auch deutlich, dass die Foundation Level | Handbuch | © IREB 73 | 174 Zahlung nach dem Versand des Buches erfolgt. Sie können die Stakeholder fragen, ob dies das ist, was sie brauchen oder gefordert haben. Ein Übergang kann zum gleichen Status führen. Diese Situation ist für den Zustand Kommissioniert dargestellt. Jedes Mal, wenn die Bestellung nicht bis zur Fertigstellung kommissioniert wird, bleibt sie im gleichen Zustand, um zu verhindern, dass eine unvollständige Bestellung versendet wird. Erst wenn die Bestellung vollständig kommissioniert ist, wird sie an den Kunden gesendet. Abbildung 3.13 Beispiel für ein UML-Zustandsdiagramm Einige Monate nach der Einführung des Buchbestellsystems beschwerten sich die Kunden, dass sie nicht die Möglichkeit hatten, eine Bestellung zu stornieren. Es wurde vereinbart, dass ein Kunde die Bestellung in jedem Zustand des Bestellvorgangs stornieren kann. Die Modellierung dieser neuen Anforderung bedeutet, dass von jedem Zustand ein Übergang zu Storniert erforderlich ist. Dies könnte die Lesbarkeit des Diagramms erschweren. Das Hinzufügen einer textuellen Anforderung zur Beschreibung dieses Verhaltens könnte eine Möglichkeit sein, das Modell für das Zielpublikum einfach zu halten. 3.4.6 Ergänzende Modelle Im CPRE Foundation Level ist das Verständnis und die Anwendung von Modellen auf ausgewählte, wichtige Modelltypen beschränkt. Es gibt weitere Modelltypen, die im Requirements Engineering verwendet werden. Die folgenden Unterabschnitte enthalten einige zusätzliche Beispiele für Modelle, die ergänzend sind und in der CPRE Foundation Level Prüfung nicht abgefragt werden. 3.4.6.1 Modellierung von Zielen Geschäftsanforderungen beschreiben ein Geschäftsziel oder ein Bedürfnis. Sie beschreiben das Endergebnis, dem die Lösung entsprechen muss und mit dem das (Geschäfts-)Problem Foundation Level | Handbuch | © IREB 74 | 174 gelöst wird, siehe Kapitel 2, Prinzip 5. Um sicherzustellen, dass der Schwerpunkt auf der Lösung des Problems liegt und dass der Fokus auf der Wertschöpfung liegt, werden die Ziele sorgfältig beschrieben. Im Requirements Engineering gibt es mehrere Möglichkeiten, Ziele zu dokumentieren. Die gebräuchlichste ist die Verwendung von natürlicher Sprache (Kapitel 3.2) oder Vorlagen (Kapitel 3.3). Vorlagenbasierte Dokumentationsformulare finden Sie z.B. unter [Pich2010], [Pohl2010], oder [RoRo2012]. Es gibt auch einige modellbasierte Notationen zur Dokumentation von Zielen. Die einfachste und gebräuchlichste Notation ist ein UND/ODER-Baum [AnPC1994]. UND/ODER-Bäume ermöglichen es uns, Ziele auf verschiedenen Detailebenen zu dokumentieren und Teilziele mit Zielen durch UND- und ODER-Beziehungen zu verknüpfen. Eine UND-Verknüpfung bedeutet, dass alle Teilziele erfüllt werden müssen, um das Ziel zu erreichen. Eine ODERBeziehung wird verwendet, um auszudrücken, dass mindestens eines der Teilziele erfüllt werden muss, um das Ziel zu erreichen. Weiterführende Modellierungsansätze für Ziele finden sich in: ▪ Zielorientierte Anforderungssprache (Goal-oriented requirements language, GRL) [GRL2020] Dies ist eine Sprache, die eine zielorientierte Modellierung und Begründung von Anforderungen unterstützt, insbesondere für den Umgang mit nicht-funktionalen Anforderungen. ▪ Wissensbeschaffung in automatisierter Spezifikation (KAOS) [vLam2009] KAOS ist eine Methodik, die eine Zielmodellierung enthält. Dies ermöglicht es Analysten Anforderungsmodelle zu erstellen und Anforderungsdokumente aus KAOS-Zielmodellen abzuleiten. ▪ Das i*-Framework ist eine der populärsten ziel- und agentenorientierten Modellierungs- und Reasoning-Methoden in diesem Bereich. i* unterstützt die Erstellung von Modellen, die eine Organisation oder ein soziotechnisches System repräsentieren. [FLCC2016] bietet einen umfassenden Überblick über den i*-Rahmen und seine Anwendung. Die Dokumentation von Zielen (in textueller oder grafischer Form) ist ein wichtiger Ausgangspunkt, um Anforderungen zu ermitteln, die Anforderungen mit ihrer Begründung zu verknüpfen und Quellen - wie z.B. Stakeholder - der Anforderungen zu identifizieren. 3.4.6.2 SysML-Blockdefinitionsdiagramme Die Systems Modeling Language (SysML) [OMG2018] ist eine universelle Modellierungssprache für Systems Engineering Anwendungen. SysML ist ein Dialekt der UML, der Teile der UML wiederverwendet und erweitert. SysML kann für viele verschiedene Zwecke eingesetzt werden. Blockdefinitionsdiagramme in SysML sind eine Erweiterung des UML-Klassendiagramms. Sie können zum Beispiel angepasst werden, um Kontextdiagramme durch die Verwendung stereotyper Blöcke für das System und die Akteure auszudrücken. Blockdefinitionsdiagramme können auch Foundation Level | Handbuch | © IREB 75 | 174 verwendet werden, um die Struktur eines Systems in Form seiner konzeptionellen Einheiten und der Beziehungen zwischen ihnen zu modellieren. 3.4.6.3 Domänen-Story-Modelle Domänen-Story-Modelle können zur Modellierung von Funktionen und Abläufen verwendet werden, indem visuelle Geschichten darüber spezifiziert werden, wie Akteure mit Geräten, Artefakten und anderen Elementen in einer Domäne interagieren, typischerweise unter Verwendung domänenspezifischer Symbole [HoSch2020]. Sie dienen zum Verständnis des Anwendungsbereichs, in dem das System betrieben wird. Die Techniken sollen sehr einfach ausführbar sein, um eine Geschichte zu erzählen, eine Tafel und Haftnotizen könnten ausreichen. Versammlung der relevanten Interessengruppen, die wirklich wissen, wie das Unternehmen funktioniert, um eine sinnvolle Diskussion zu provozieren, indem Geschichten erzählt werden, die in der Domäne vorkommen. Das Erzählen von Geschichten über eine Domäne verbessert das gemeinsame Verständnis eines Geschäftsprozesses und wird zur Analyse und Lösung von Problemen in der Domäne verwendet. 3.4.6.4 UML Sequenzdiagramm Das UML-Sequenzdiagramm wird verwendet, um die Interaktion zwischen Kommunikationspartnern darzustellen und den dynamischen Aspekt von Systemen zu modellieren. Der dynamische Aspekt von Systemen, den ein Sequenzdiagramm darstellt, kann sowohl Funktion und Fluss als auch Zustand und Verhalten sein. Daher kann ein UMLSequenzdiagramm für verschiedene Zwecke verwendet werden. Die Kommunikationspartner in einem UML Sequenzdiagramm sind Akteure, Systeme, Komponenten und/oder Objekte innerhalb eines Systems. Die Interaktion zeigt die Abfolge von Nachrichten (ein Szenario) zwischen diesen Kommunikationspartnern. Die Interaktion, die zwischen den Kommunikationspartnern stattfindet, verwirklicht den Zweck eines Szenarios, bzw. (eines Teils) des Use Case. Foundation Level | Handbuch | © IREB 76 | 174 In der untenstehenden Übersicht finden Sie die grundlegenden Notationselemente. Abbildung 3.14 Grundlegende Notationselemente des UML-Sequenzdiagramms Eine Lebenslinie in einem Szenario stellt die Rolle in dem Szenario dar, d.h. die Instanz eines Akteurs. Bei der Modellierung von Sequenzdiagrammen wird der Instanzname eines Akteurs oder Objekts oft weggelassen. Die Rollen, die an der Kommunikation teilnehmen, interagieren miteinander, indem sie Nachrichten senden. Es gibt zwei Arten von Nachrichten, die in der Interaktion verwendet werden. Abbildung 3.15 Grundlegende Notationselemente zur Nachrichtenübermittlung im UML-Sequenzdiagramm Eine Nachricht kann auch von oder an Objekte(n) außerhalb des Szenarios gesendet werden. Dies wird als ausgefüllter Kreis dargestellt. Der Absender oder Empfänger dieser Art von Nachrichten kann unbekannt sein. Foundation Level | Handbuch | © IREB 77 | 174 Abbildung 3.16 Nachrichten von und zu einem Objekt außerhalb des Szenarios Abbildung 3.17 zeigt ein Modell des Szenarios, in dem ein Kunde ein Buch bestellt und dieses bestimmte Buch vergriffen ist. Der Kunde will eine Bestellung aufgeben. Wenn die Bestellung ungültig ist, wird eine Benachrichtigung über die Stornierung der Bestellung zurückgegeben. Wenn die Bestellung gültig ist, wird der Bestand überprüft, und wenn ein Buch vergriffen ist, wird ein Druckauftrag an die Druckerei geschickt. Dies ist eine synchrone Nachricht, da wir darauf warten, das Buch zu erhalten - auch wenn es einige Zeit dauern kann, das Buch zu drucken. Der Kunde erhält eine Benachrichtigung, dass das Buch vergriffen ist und nachgeliefert wird. Die Bestellung wird deaktiviert, bis das Buch von der Druckerei geliefert wird. Wenn das Buch von der Druckerei empfangen wird, wird das Bestellsystem wieder aktiviert. Der Auftrag wird kommissioniert und an den Kunden gesendet. Damit ist der Auftrag abgeschlossen und eine letzte Benachrichtigung über den Status wird an den Kunden gesendet. Abbildung 3.17 Beispiel für ein UML-Sequenzdiagramm Foundation Level | Handbuch | © IREB 78 | 174 3.5 Glossare Glossare sind ein zentrales Mittel zur Schaffung eines gemeinsamen Verständnisses der bei der Entwicklung eines Systems verwendeten Terminologie: Sie tragen dazu bei, zu vermeiden, dass Personen, die als Stakeholder oder Entwickler beteiligt sind, dieselben Begriffe auf unterschiedliche Weise verwenden und interpretieren. Ein gutes Glossar enthält Definitionen für alle Begriffe, die für das System relevant sind, etwa kontextspezifische Begriffe oder Alltagsbegriffe, die im Kontext des zu entwickelnden Systems mit besonderer Bedeutung verwendet werden. In einem Glossar sollten auch alle verwendeten Abkürzungen und Akronyme definiert werden. Wenn es Synonyme gibt (also verschiedene Begriffe, die die gleiche Sache bezeichnen), dann sollten diese als solche gekennzeichnet werden. Homonyme (d.h. identische Begriffe, die unterschiedliche Dinge bezeichnen) sollten vermieden oder zumindest im Glossar als solche gekennzeichnet werden. Es gibt eine Reihe von Regeln, die die Erstellung, Verwendung und Pflege des Glossars in einem Systementwicklungsprojekt leiten. ▪ Erstellung und Pflege. Um sicherzustellen, dass die im Glossar definierte Terminologie konsistent und immer auf dem neuesten Stand ist, ist es wichtig, dass das Glossar während des gesamten Projektverlaufs zentral verwaltet und gepflegt wird, wobei eine Person oder eine kleine Gruppe für das Glossar verantwortlich ist. Bei der Definition von Begriffen ist es wichtig, dass die Stakeholder einbezogen werden und sich auf die Terminologie einigen. ▪ Verwendung. Um den vollen Nutzen aus einem Glossar zu ziehen, muss dessen Verwendung obligatorisch sein. Arbeitsprodukte sollten auf die korrekte Verwendung des Glossars überprüft werden. Das bedeutet natürlich, dass jeder, der an einem Projekt beteiligt ist, Lesezugriff auf das Glossar haben muss. Wenn eine Organisation in mehreren Projekten verwandte Systeme entwickelt, ist es sinnvoll ein Glossar auf Unternehmensebene zu erstellen, um projektübergreifend eine konsistente Terminologie zu erreichen. Durch die Erstellung, Pflege und Verwendung eines Glossars werden Fehler und Missverständnisse bezüglich der verwendeten Terminologie konsequent vermieden. Die Arbeit mit Glossaren ist eine bewährte Standardpraxis im RE. 3.6 Anforderungsdokumente und Dokumentationsstrukturen Es genügt nicht mit Anforderungen auf der Ebene einzelner Anforderungen zu arbeiten. Anforderungen müssen in geeigneten Arbeitsprodukten zusammengefasst und gruppiert werden, seien es explizite Anforderungsdokumente oder andere RE-bezogene Dokumentationsstrukturen (wie z.B. ein Produkt-Backlog). Foundation Level | Handbuch | © IREB 79 | 174 Dokumentvorlagen (siehe Kapitel 3.3.3) können verwendet werden, um solche Dokumente mit einer klar definierten Struktur zu organisieren und damit konsistente und verwaltbare Sammlung von Anforderungen zu schaffen. Dokumentvorlagen sind in der Literatur [Vole2020], [RoRo2012] und in Normen [ISO29148] verfügbar. Vorlagen können auch aus früheren, ähnlichen Projekten, wiederverwendet werden oder von einem Kunden auferlegt werden. Eine Organisation kann auch beschließen eine Dokumentvorlage als internen Standard zu erstellen. Ein Anforderungsdokument kann auch zusätzliche Informationen und Erklärungen enthalten, z.B. ein Glossar, Abnahmebedingungen, Projektinformationen oder Merkmale der technischen Umsetzung. Häufig verwendete Anforderungsdokumente sind: ▪ Stakeholder-Anforderungsspezifikation: Deckt - betrachtet aus der Perspektive der Stakeholder - die Wünsche und Bedürfnisse der Stakeholder ab, die durch das Erstellen eines Systems erfüllt werden sollen. Wenn ein Kunde eine Anforderungsspezifikation für Stakeholder schreibt, wird diese auch als Kundenanforderungsspezifikation (Lastenheft) bezeichnet. ▪ Benutzer-Anforderungsspezifikation: Eine Teilmenge einer StakeholderAnforderungsspezifikation, die nur die Anforderungen von den Stakeholdern abdeckt, die potenzielle Benutzer eines Systems sind. ▪ System-Anforderungsspezifikation: Deckt die Anforderungen an ein zu erstellendes System und seinen Kontext ab, damit es die Wünsche und Bedürfnisse seiner Stakeholder erfüllt. Geschäfts-Anforderungsspezifikation: Beschreibt die Geschäftsziele, Zielsetzungen und Bedürfnisse einer Organisation, die durch den Einsatz eines Systems (oder einer Auswahl mehrerer Systeme) erreicht werden sollen. ▪ ▪ Visions-Dokument: Eine konzeptionelle Vorstellung eines zukünftigen Systems, das seine wichtigsten Merkmale beschreibt und die Art und Weise, wie es einen Mehrwert für seine Benutzer schafft. Häufig verwendete alternative Dokumentationsstrukturen sind: ▪ Produkt-Backlog: Eine priorisierte Liste von Arbeitsaufgaben, die alle für das Produkt benötigten und bekannten Anforderungen abdeckt ▪ Sprint-Backlog: Eine ausgewählte Teilmenge eines Produkt-Backlogs mit Arbeitsaufgaben, die als nächstes realisiert werden ▪ Story Map: Eine visuelle zweidi