Requirements Engineering and Cost Estimation - Anforderungen dokumentieren

Anforderungen dokumentieren

Im letzten Kapitel haben wir mit unterschiedlichen Techniken die Bedürfnisse und Wünsche der Stakeholder erarbeitet. An dieser Stelle geht es darum, das gesammelte Wissen dem Projekt entsprechend festzuhalten. ‚Anforderungen dokumentieren‘ ist somit eine weitere Kernaktivität des Requirements Engineering, die dazu dient, durch zusätzliche Informationen die Qualität der Anforderungen zu verbessern und die Kommunikation zwischen Stakeholdern zu erleichtern.

Dokumentieren wird deshalb oftmals mit Spezifizieren gleichgesetzt. Dieser Schritt beinhaltet die schriftliche Darstellung der gewünschten Systemmerkmale und ergibt dabei ein klareres Bild von Details sowie Zusammenhängen der Charakteristika.

Dokumentation dient dazu „Wissen, das in den Köpfen der verschiedenen Stakeholder steckt, zu Papier zu bringen“ . Dies betrifft nicht nur Anforderungen, sondern auch Geschäftsprozesse und Kontextinformationen.

Gründe für die Dokumentation von Requirements:

• Basis der Systementwicklung

Nur klar beschriebene Anforderungen können entsprechend entwickelt werden. Das heißt, von der Qualität der Dokumentation hängt maßgeblich der Erfolg von Softwareprojekten ab. Wenn sich widersprüchliche Informationen verteilen, führt dies über kurz oder lang zu Verwirrung und gefährden das Projekt. Ein gemeinsames Verständnis der Requirements ist daher essentiell, um Konflikte frühzeitig zu erkennen bzw. zu vermeiden.

• Rechtlich relevant

Meist sind Requirements in irgendeiner Form Bestandteil des Vertrags. Auftragnehmer wie Auftraggeber sind daran gebunden und nutzen diese für ihre wechselseitigen Forderungen. Die schriftliche Form erlaubt auch im Falle von Rechtsstreitigkeiten, diese zumindest rascher zu klären.

• Komplex

Um sich zu erinnern bzw. dem Vergessen Einhalt zu gebieten, wird in der Spezifikation das im Ermittlungsschritt gesammelte Knowhow festgehalten. Dafür ist je nach Projekt die relevante Detailtiefe festzulegen und konsistent zu erarbeiten. Nicht nur große Projekte umfassen unzählige Anforderungen mit vielschichtigen Relationen, weshalb es wichtig ist, den Überblick zu behalten. Die Menge an Requirements sowie an beteiligten Personen macht es notwendig, für die umfangreichen Informationen ein angemessenes ‚Speicher- und Arbeitsmedium‘ zu erstellen. Das menschliche Gehirn hat sich in Bezug auf diese Komplexität bzw. die Ausfallsicherheit als wenig nachhaltig herausgestellt, vor allem weil mit der Zeit Menschen, die Wissensträger sind, Projekte verlassen und mit der Materie noch nicht vertraute dazukommen.

• Zugänglichkeit für Beteiligte

Gerade weil es in Projekten unweigerlich zu inhaltlichen und personellen Veränderungen kommt, ist eine umfassende Beschreibung unumgänglich. Es erleichtert die Kommunikation zwischen Stakeholdern beträchtlich, wenn die aktuellen Informationen permanent und transparent für alle verfügbar sind. Viele Missverständnisse sind so leicht zu vermeiden und neue Personen können rasch an ‚Board‘ geholt werden.

• Einheitlichkeit der Dokumentation

Die Verschriftlichung von Informationen erlaubt eine weitere Synchronisie­rung der unterschiedlichen Menschen in der Kommunikation. Wenn verschiedene Auffassungen möglichst simpel und doch ausreichend abgebildet werden, kann sprachliche Unschärfe möglichst ausgemerzt werden und es minimieren sich Interpretationsspielräume. Die damit verbundene Reduktion von Inkonsistenzen vereinfacht notwendige Nacharbeiten und verhindert in der Folge Frustration sowie hohe Kosten.

Zu Beginn bestimmt der Requirements Engineer den Zweck und die Zielgruppe der Dokumentation. Davon hängt die Art und Weise der Spezifikation ab, um sie für die unterschiedlichen Stakeholder nachvollziehbar gestalten zu können. Ebenso gilt es, eine angemessene Detailebene und Darstellungsart auszuwählen, um auch Schnittstellen, Fachprozesse usw. abzubilden. Während der Dokumentation der Anforderungen erfolgt eine fortwährende Überprüfung hinsichtlich Zweck und Zielgruppe. Die Spezifikation ist schließlich nicht Selbstzweck, sondern ein Mittel, um das Projekt zum Erfolg zu führen. Es ist darüber hinaus wichtig, sich zu vergewissern, dass z.B. die Detailebene stimmig ist, denn Standards und Richtlinien können unterschiedlich interpretiert werden: Ein Extrem sind die berüchtigten 500 Seiten-Spezifikationen, ein anderes die minimalistischen User-Stories gemeinsam mit Diskussionen im agilen Setting.

Anforderungsdokumente

Für verschiedene Aktivitäten in Entwicklungsprojekten sind Anforderungsdokumente die Basis:

• Planung von Arbeitspaketen und Meilensteinen

• Entwurf der Systemarchitektur

• Implementierung

• Generierung von Testfällen

• Change Management

• Systemnutzung und -instandhaltung

• Vertragsgegenstand zwischen dem Vertragsnehmer und -geber

Typische Dokumentenstrukturen

Im Requirements Engineering sind keine typischen Dokumentenstrukturen vorhanden. Allgemeine Standards bieten zwar Vorlagen bzw. Orientierungspunkte , die detaillierte Struktur hängt aber vielmehr von der Organisation und/oder dem jeweiligen Projekt ab. Verschiedene Projektarten und Technologietypen erfordern individuell angepasste und dementsprechend kaum normierbare Dokumentations­strukturen. Große Organisationen gestalten für ähnliche inhaltliche oder organisatorische Projekte häufig Templates.

Anhaltspunkte bieten üblich wiederkehrende Elemente in Anforderungsdokumenten:

• Die Darstellung der Vision umfasst Ziel und Motivation des Projekts sowie Zweck und Zielgruppe des Dokuments.

• Auf der Überblicksebene sind die Verortung in der fachlichen Prozess- und IT-Landschaft bzw. dem Systemumfeld, die Kurzbeschreibung der wichtigsten Systemfunktionalität sowie die Nutzerrollen und technischen Schnittstellen zu anderen Systemen relevant.

• Bei der Dokumentation der detaillierten Anforderungen sind die Kurz­beschreibung der Systemfunktion, die Einzelheiten zu jeder Systemfunktion sowie die unterschiedlichen Arten der Requirements (funktionale Anforderungen, Qualitätsanforderungen, Randbedingungen) zu berück­sichtigen. In der Regel findet sich hier auch ein Glossar.

Qualitätskriterien für das Anforderungsdokument

Bei Anforderungsdokumenten ist auf folgende qualitative Aspekte zu achten:

• Eindeutigkeit und Konsistenz

• Klare Struktur

• Modifizierbarkeit und Erweiterbarkeit

• Vollständigkeit

• Verfolgbarkeit

Qualitätskriterien für Anforderungen

Ausgehend vom Stakeholder werden Anforderungen auf dem Weg zur Spezifikation gefiltert, analysiert, bewertet und priorisiert. Unter Bezugnahme auf Projekt- bzw. Unternehmensinterne Standards und Vorschriften soll mithilfe von Qualitätskriterien sichergestellt werden, die Dinge richtig zu tun. Dafür ist es notwendig, die aufbereiteten Requirements systematisch, in erster Linie manuell zu verifizieren und zu validieren. So können Spezifikationsmängel ausgeräumt und die Qualität verbessert werden, um schlussendlich separierte, lesbare und klar umsetzbare Anforderungen für den weiteren Prozess zur Verfügung zu stellen. Eine Orientierung, welche Qualitätskriterien ein systematisches Überprüfen der Requirements ermöglichen, bieten gängige Normen und Regelwerke. Hier sind die des IREB-Standards gelistet:

• Abgestimmt

Eine Freigabe der Anforderung ist durch alle Stakeholder erfolgt.

• Eindeutig

Die Beschreibung der Anforderung lässt keinen Interpretationsspielraum zu.

• Notwendig

Ohne die Anforderung ist die Abnahme des Zielsystems in Frage gestellt.

• Konsistent

Eine Anforderung muss in sich und zu anderen widerspruchsfrei sein.

• Prüfbar

Für die Abnahme ist die Anforderung test- bzw. messbar.

• Realisierbar

Technische Machbarkeit einer Anforderung und ihre Vereinbarkeit mit anderen Anforderungen bzw. Rahmenbedingungen (Budget, Zeitpläne usw) ist gewährleistet.

• Verfolgbar

Ein eindeutiger Identifikator macht eine Anforderung von ihrer Entstehung bis zur Abnahme nachvollziehbar.

• Vollständig

Eine Anforderung umfasst alle relevanten Informationen.

• Verständlich

Für alle Stakeholder, unabhängig vom unterschiedlichen Informationslevel und Ausgangsknowhow, ist die Anforderung konkret fassbar.

Zusätzliche Grundprinzipien der Verständlichkeit, wie kurze Sätze, überschaubare Absätze und maximal eine Anforderung pro Satz, erlauben eine Simplifizierung der Requirements und erhöhen die Lesbarkeit:

Dokumentationstechniken

Für die Beschreibung von Anforderungen an ein gewünschtes System werden in der Praxis die natürliche Sprache in Prosa sowie in strukturierter Form oder konzeptuelle Modelle benutzt. Wie schon bei den Techniken in anderen Phasen kommen oft Kombinationen zum Einsatz, um die Schwächen einzelner Heran­gehensweisen zu kompensieren.

Die Übersicht an dieser Stelle beschränkt sich auf die am häufigsten genutzten Techniken. Die unzähligen Unterkategorien bzw. ergänzenden Methoden finden sich detailliert in der Literatur .

Spezifikation in natürlicher Sprache

Die Dokumentation von Anforderungen erfolgt am häufigsten in Prosa. Vorteilhaft dabei ist vor allem die einfache Anwendung ohne (scheinbar) zusätzlichen Schulungs- und Lernaufwand für Stakeholder. Solange alle Beteiligten der verwendeten Sprache mächtig sind, gilt diese als leicht verständlich. Zudem ist sie vielseitig einsetzbar, unabhängig von Art der Anforderung oder dem jeweiligen Inhalt. Aufgrund des ‚alltäglichen Gebrauchs‘ kommt es allerdings oftmals zu Ungenauigkeit in der Formulierung bzw. ermöglicht die der Sprache inhärente Mehrdeutigkeit unzählige Interpretationen. Auf der Basis des individuellen und damit verschiedenen Vorwissens, Hintergrunds und der Erfahrung verfassen und verstehen Stakeholder Requirements unterschiedlich.

Darum ist es essentiell, auf die Eindeutigkeit Wert zu legen. Die Oberflächenstruktur (Requirement) ist sonst anders als die Tiefenstruktur, also das was im Kopf des einzelnen Menschen vorhanden ist. Sowohl beim Wahrnehmen also auch beim Darstellen von Information kommt es zu sogenannten Transformationsprozessen. Die fünf üblichsten sind:

• Normalisierung

Aus einem meist längeren Prozess, der durch ein Prozesswort dargestellt werden könnte, wird ein singuläres Ereignis und damit ein Substantiv, z.B. ‚übermitteln‘ wird zu ‚Übermittlung‘, ‚abnehmen‘ zu ‚Abnahme‘ usw.) Normalisierung ist nicht grundlegend ein Problem, solange der gemeinte Prozess umfassend bekannt und unmissverständlich ist. Hilfreich ist es, den Begriff eindeutig und interpretationsfrei im Glossar aufzunehmen. Sonst empfiehlt es sich, die Formulierung aufzudröseln.

• Substantive ohne Bezugsindex

Äußerst allgemeine Substantive wie ‚der Benutzer‘ oder ‚das System‘ bergen die Gefahr einer unvollständiger Spezifizierung in sich. Als Requirements Engineer ist es deshalb wichtig, Fragen wie ‚wer ist damit genau gemeint?‘ oder ‚was ‚macht‘ der/das im Detail?‘ zu stellen und beantworten zu lassen.

• Universalquantoren

Universalquantoren beschreiben Häufigkeiten und sind an Signalwörtern wie ‚alle‘, ‚nie‘, ‚immer‘, ‚kein‘, ‚jeder‘, ‚nichts‘ usw. zu erkennen. Sie werden verwendet, um ein bestimmtes Verhalten von einer Menge, also mehreren Objekten, zu schildern. Das Risiko dabei ist, dass das beschriebene Verhalten nicht für alle gilt, weshalb es entscheidend ist, zu hinterfragen, ob tatsächlich ‚immer‘, ‚jeder‘ usw. in dem Kontext zutreffen.

• Unvollständige spezifizierte Bedingungen

Wenn Bedingungen nicht umfassend beschrieben werden, ist von einer unvollständigen Spezifizierung von Zuständen und Ereignissen in Requirements die Rede. So ist häufig der Fall beschrieben, wenn ein Ereignis geschieht, hingegen ist in der Anforderung unberücksichtigt, was geschehen soll, wenn ein Ereignis nicht eintritt. Signalwörter sind hier ‚wenn ... dann‘, ‚falls‘, ‚im Falle von‘, ‚abhängig von‘ usw. Durch Entscheidungs­tabellen können fragmentarische Bedingungen verhindert werden.

• Unvollständige spezifizierte Prozesswörter

Einige Verben (Prozesswörter) benötigen mehr als ein Nomen für ihre komplett Darstellung, z.B. ‚übermitteln‘ verlangt nach der Klärung des ‚was‘, ‚von wo‘ sowie ‚wohin‘. Der Requirements Engineer sollte, wenn möglich, einen Bogen um derartige Passiv-Formen machen und besser auf aktive Formulierung zurückgreifen.

Natursprachliche Spezifikationen sind oft durch Skizzen, einfache Grafiken oder Tabellen ergänzt. Diese Kombinationen sind ebenfalls einfach und schnell zu erstellen, z.B. direkt in Workshops mit Stakeholdern. Nachteilig ist der meist große Interpretationsspielraum, da diese keine allgemein verständliche Semantik haben, weshalb es oft notwendig ist, bei der Entwicklung dabei gewesen zu sein, um die Darstellung umfassend zu verstehen. Übliche Anwendungsfälle, in denen natürliche Sprache genutzt wird, sind u.a. Szenarien oder Use-Case-Beschreibungen.

Um mit natürlicher Sprache strukturiert – wie mit einem Bauplan – Anforderungen zu formulieren, hilft die Konstruktion mittels Schablone (Requirements Template). Diese bietet eine Anleitung für die syntaktische Struktur eines Requirements und damit einen sich leicht anzueignenden Ansatz zur Reduzierung sprachlicher Effekte. Eine Schablone erhöht sowohl die Eindeutigkeit als auch die Qualität im Verhältnis zum zeitlichen und finanziellen Aufwand. Sie sollte allerdings nur verwendet werden, wenn die Stakeholder bereit sind, sich auf eine stark normierte Herangehensweise und starke Einschränkung der stilistischen Freiheit einzulassen. Laut IREB führen folgende fünf Schritte zur Formulierung einer Anforderung mittels Satzschablone  :

• Juristischen Verbindlichkeit festlegen

Dabei wird üblicherweise zwischen ‚rechtlich bindenden‘, ‚dringend empfohlenen‘, ‚zukünftigen‘ und ‚wünschenswerten‘ Requirements differenziert. Zum Ausdruck bringen das vor allem die Modalverben ‚muss‘, ‚sollte‘, ‚wird‘ sowie ‚kann‘.

• Kern der Anforderung (Prozess) bestimmen

Der Autor eines Requirements stellt die Aktivitäten oder Abläufe aktiv und mit Verben dar.

• Aktivität des Systems charakterisieren

Es erfolgt eine Klassifizierung in selbständige Systemaktivität, Benutzer­interaktion oder Schnittstellenanforderung.

• Objekt einfügen

Wenn notwendig, werden Prozesswörter ergänzt, um keine unvollständig spezifizierten Bedingungen zu generieren.

• Logische und zeitliche Bedingungen einfügen

Durch Konjunktionen wie z.B. ‚sobald‘, ‚während‘, ‚nachdem‘ oder ‚falls‘ und die dadurch erzeugten Nebensätze findet eine detailliertere temporale und konditionale Beschreibung von Anforderungen statt.

Dokumentation im agilen Umfeld

Anforderungen heißen im agilen Setting meist User-Storys (‚Anwendererzählung‘ oder ‚Nutzergeschichte‘) und werden in einem Product Backlog gesammelt (deshalb auch Product Backlog Item). Eine User Story beschreibt eine Anforderung bewusst kurz, aussagekräftig und umfasst in der Regel nicht mehr als zwei Sätze aus der Benutzerperspektive. Die Darstellungsform ist schablonenartig in Alltagssprache und baut zentral auf folgenden Satz auf:

Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>.

Die Rolle gibt an, wer etwas anfordert. Idealerweise verfasst der zukünftige Nutzer des Systems oder der Nutznießer der zukünftigen Lösung die User Story.

Der Anforderer wünscht sich eine konkrete Funktionalität bzw. ein Systemverhalten. Je klarer und präziser der Wunsch in der User Story geäußert wird, desto hilfreicher ist das für die Realisierung.

Warum das Requirement für den Geschäftsfall wichtig ist, erklärt der (wirtschaftliche) Nutzen, indem er den jeweiligen Wert für den Benutzer oder Kunden darlegt.

Für die Spezifikation ist die ‚Definition of Ready’ von User Storys entscheidend. Wenn diese erfüllt ist, darf eine User Story grundsätzlich in die Umsetzung weitergereicht werden, weil sie als ‚vollständig‘ beschrieben gilt. In jedem Fall gilt für User Storys während ihres ganzen Lebenszyklus: ‚A story is a promise of a conversation‘, weshalb die direkte Kommunikation zwischen den Stakeholdern enorm hoch gehalten wird.

User Storys konzentrieren sich auf das Wesentliche und bewegen sich ausschließlich im Anforderungsraum. Sie bestimmen keine technischen Lösungen, sondern lassen den Spielraum für den Lösungsweg bei den Umsetzenden. Um die Qualität einer User Story sicherzustellen, ist das Akronym ‚INVEST’ hilfreich. Es steht für die Eigenschaften einer guten Nutzergeschichte, denn die sollte independent (unabhängig von anderen), negotiable (verhandelbar), valuable (nützlich), estimable (schätzbar), small (klein) und testable (testbar) sein.

Darüber hinaus beinhaltet eine User Story eine prägnante Beschreibung des Sachverhalts, wenn unbedingt nötig, und Akzeptanzkriterien. Diese stichpunktartigen Kriterien dienen als Checkliste und legen dar, woran erkannt werden kann, dass diese User Story ‚fertig‘ ist. Sind keine Akzeptanzkriterien vorhanden, ist unklar, wie und wann die Abnahme vonstattengehen wird. Die ‚Definition of Done‘ ist in der agilen Herangehensweise essentiell.

Dokumentationsmodelle

Alternativ oder zusätzlich zur Beschreibung mit natürlicher Sprache können Requirements strukturierter und formaler mit Hilfe von Modellen dokumentiert werden. Unter einem Modell wird „ein abstraktes Abbild einer existierenden oder einer noch zu schaffenden Realität“ verstanden. Zu den Eigenschaften von Modellen zählen daher, dass sie die Wirklichkeit abbilden, die Realität durch eine bestimmte Notation verkürzen sowie pragmatisch darauf zugeschnitten sind, was unbedingt dargestellt werden muss. Die Modellbildung kann, wie die Definition erwähnt, eine bereits existierende Realität beschreiben, dann ist von einem deskriptiven Modell die Rede. Dient das Modell als Vorlage für etwas, das noch nicht Realität ist, nennt man die Modellbildung präskriptiv. Bei der Verkürzung werden die Selektion und die Verdichtung unterschieden. In ersterem werden nur ausgesuchte Merkmale im Modell dargestellt. In der Verdichtung kommt es zu einer komprimierten Abbildung von Charakteristika des Gegenstandsbereiches.

Modelle sind im Gegensatz zur natürlichen Sprache nicht universell einsetzbar und erfordern sowohl vom Autor als auch vom Leser gewisse ‚Sprachkenntnisse‘, für die Stakeholder gegebenenfalls geschult werden müssen. Die kompakte Darstellung macht für mit der ‚Sprache‘ vertraute die Information allerdings verständlicher, reduziert den Interpretationsspielraum und damit die Möglichkeit von Missverständnissen. Die Kognitionsforschung bestätigt das Sprichwort ‚Ein Bild sagt mehr als 1000 Worte‘, dass also Menschen Bilder schneller wahrnehmen und sich besser merken als reinen Text. Zudem können Perspektiven in die Dokumentation einbezogen werden, wie z.B. bei einem U-Bahn- bzw. Stadtplan, die unter verschiedenen Blickwinkeln auf dieselbe Stadt schauen. Zudem bieten (bzw. fordern) Requirementsmodelle einen zweckabhängigen Grad der Abstraktion.

Üblicherweise werden im Requirements Engineering konzeptionelle Modellierungs­sprachen verwendet, die durch ihre jeweilige Syntax (Definition gültiger Modell­elemente und Kombinationen) und Semantik (Definition der Bedeutung einzelner Modellelemente) bestimmt sind.

Die Unified Modeling Language, oder kurz UML, ist eine vereinheitlichte grafische Modellierungssprache, die in der Softwareentwicklung zur Spezifikation, Konstruktion und Dokumentation genutzt wird. Entwickelt von der Object Management Group (OMG) eignet sich diese Standard-Notation für strukturelle als auch für verhaltensbasierte Modelle. Wie bei einer Sprache legt die UML Symbole bzw. Bezeichnungen für die meisten bei einer Modellierung wichtigen Begriffe fest und definiert potentielle Beziehungen zwischen diesen Begriffen.

Bei UML-Modellen wird zwischen Strukturdiagrammen, die statische Aspekte darstellen, und Verhaltensdiagrammen, die dynamische Aspekte abbilden, unterschieden. Letztere veranschaulichen das Verhalten des Systems, d.h. dessen Reaktion auf Reize von außen in Form von gewünschten Zuständen, Zustandsänderungen und generierten Ausgaben.

Zu den Strukturdiagrammen gehört neben vielen anderen das Klassendiagramm. In die Kategorie Verhaltensdiagrammen fallen unter anderem das Anwendungsfall­diagramm, das Aktivitätsdiagramm, das Sequenzdiagramm und das Zustands­diagramm.

Klassendiagramme

Diese sehr häufig verwendete Technik gehört zu den strukturellen UML-Diagrammen und bietet die wichtigste Grundlage für jede objektorientierte Lösung. Klassen­diagramme repräsentieren die statischen Strukturen eines Systems, wozu seine Klassen, Attribute, Vorgänge und Objekte gehören sowie die Beziehung zwischen den einzelnen Aspekten. Ein Klassendiagramm kann rechnerische oder organisatorische Daten in Form von Implementierungs- bzw. logischen Klassen darstellen, wobei es zu Überschneidungen kommen kann. Um komplexe Begriffssysteme von Fachgebieten strukturiert darzustellen, können ebenso Klassendiagramme verwendet werden.

Zu den wichtigsten eingesetzten Elementen gehören natürlich die fachlichen Klassen, oder auch Geschäftsobjekte genannt. In einer Klasse werden Objekte gebündelt, die ähnliche Charakteristika aufweisen. Ihre Illustration erfolgt durch ein Rechteck mit einem eindeutigen Namen zur Identifikation. Einer Klasse können Eigenschaften (Attribute) und Operationen (Methoden), die für das Objekt relevant sind, zugeteilt werden. Diese werden innerhalb des Rechtecks unter dem Namen hinzugefügt und jeweils durch waagrechte Striche von der Information darüber abgetrennt. Im hier verwendeten Beispiel gibt es unter anderem die Klasse Route mit den Charakteristika Fahrdauer und Länge. Mit Linien, auch als Kanten bezeichnet, werden Beziehungen zwischen Klassen und Unterklassen dargestellt. Die grundlegenden Relationen eines Klassendiagramms heißen Assoziationen und können mit einem Assoziationsnamen beschrieben werden, im Beispiel Prozesswörter wie berechnet oder gehört zu. Assoziationen zwischen Klassen haben meist Multiplizitäten und Rollen. Eine Multiplizität bringt die Anzahl möglicher Ausprägungen zum Ausdruck und wird mit einem minimalen und einem maximalen Wert versehen. In der UML wird dafür auch der Begriff Kardinalität verwendet. Die Multiplizitäten der Assoziation berechnet in der Grafik besagen, dass ein Navigationsgerät beliebig viele Routen berechnen kann und eine Route von beliebig vielen Navigationsgeräten abgerufen werden kann. Allerdings gehört immer ein Navigationsgerät zu jeweils einem Fahrzeug.

Beispiel für ein Klassendiagramm

Die Aggregation und Komposition sind zwei spezielle Formen der Assoziation. Beide visualisieren die Beziehungen zwischen dem Teil und dem Ganzen, wobei die Klassen bei der Komposition eine stärkere Bindung haben als bei der Aggregation. D.h., ein Objekt, das Teil eines Ganzen ist, ist von der Existenz dieses Ganzen abhängig. Verschwindet das Ganze, löscht dies auch die Existenz des Objekts, das bis dahin Teil war. Diese Relationen werden wie eine Assoziation als Linie zwischen zwei Klassen dargestellt und bei der Aggregation zusätzlich mit einer kleinen, leeren Raute versehen, bei der Komposition mit einer gefüllten Raute. Laut Beispiel ist die Route eine Aggregation aus mindestens einem bis zu beliebig vielen Streckenabschnitten.

Ein weiteres Notationselement ist die Generalisierung, die eine gerichtete Beziehung zwischen einer allgemeinen und einer speziellen Klasse beschreibt. Dabei erfolgt die Vererbung aller Struktur- und Verhaltensmerkmale des Supertyps an Subklassen, ohne dass diese Eigenschaften bei der spezielleren Klasse explizit deklariert werden. Diese Beziehungen werden durch einen Pfeil ausgedrückt. So ist z.B. ein Navigationsgerät mit Stauumfahrung eine Unterkategorie der Superklasse Navigationsgerät und erbt als solche alle Eigenschaften der übergeordneten Klasse, im Beispiel das Attribut Identifikation.

Klassendiagramme basieren auf den Prinzipien der Objektorientierung und können aufgrund ihrer Vielseitigkeit in allen Projektphasen verwendet werden. In der Analysephase dient es als Domainmodell, um ein Abbild der Realität zu illustrieren und Anforderungen zu dokumentieren. Danach wird damit in der Designphase die Software gestaltet sowie in der Umsetzungsphase daraus der Code entwickelt. Klassendiagramme sind somit ein unentbehrlicher Bestandteil für die Anforderungsdokumentation sowie die Softwareentwicklung in Projekten. Im Requirements Engineering kommt das Klassendiagramm für statische Konzepte zum Einsatz, um Dinge (Geschäftsobjekte, Personen, Objekte, System) und deren Charakteristika, Relationen und Abhängigkeiten zu dokumentieren. Eine weitere Verwendungsmöglichkeit ist das Begriffsmodel, um Beziehungen zwischen den im Zielsystem verwendeten Begrifflichkeiten zu visualisieren. Als Ergänzung zum Glossar unterstützt ein Begriffsmodell das Verstehen des fachlichen Problems.

Klassendiagramme, ob nun für Objekte oder Begriffe, bieten Orientierung und gewähren einen detaillierten Einblick in die Struktur des zu entwickelnden Systems bzw. der Begriffsrelationen. Zu beachten gilt allerdings, dass Klassen keine Systemelemente sind, sondern Aspekte der fachlichen Umgebung. Deshalb finden sie nicht eins zu eins ihre Repräsentation im gewünschten Zielsystem. Simple Klassendiagramme sind mit etwas Vorwissen einfach und schnell zu lesen sowie mit der richtigen Software auch relativ unkompliziert zu erstellen. Dadurch sind sie eine ideale Basis für das Requirements Engineering von der ersten Visualisierung konzeptueller Inhalte über plattformunabhängige logische Modelle bis hin zu ‚Implementierungsbauplänen‘.

Die in der Folge dargestellten Dokumentationsformen gehören in die Gruppe der verhaltensbasierten UML-Diagramme:

Anwendungsfalldiagramm

Diese Form ist auch unter dem Namen Use-Case-Diagramm bekannt und beschreibt ein System, das in der Grafik durch das große Rechteck begrenzt wird, welches das System vom Außen trennt. Das System kann mit einem Namen versehen werden, im hier genutzten Beispiel handelt es sich um einen ‚Onlineshop‘. Im System außen finden sich Akteure, das sind zum einen Menschen, die mit dem System interagieren (z.B. der Kunde oder der Shop Manager), zum anderen (technische) Systeme, die mit dem Onlineshop kommunizieren, z.B. das Online-Bezahlsystem. Ein Use Case schildert eine typische Interaktion eines Users mit dem System, die zu einer angestrebten Reaktion des Systems führt. Die Akteure sind mit Linien mit den entsprechenden Aktivitäten verbunden, mit denen Kommunikation stattfindet. Jeder Punkt, an dem die Kommunikationsbeziehung die Systemgrenze kreuzt, ist ein Hinweis entweder auf eine Benutzerschnittstelle oder eine technische Schnittstelle.

Beispiel für ein Use-Case-Diagramm

Anwendungsfalldiagramme nutzen die Spezifikationen eines Use Cases und modellieren die funktionalen Bestandteile eines Systems, also das geforderte, nach außen sichtbare Verhalten des Systems. Somit sind sie Teil der Anforderungen, die das zu entwickelnde System erfüllen soll. Ein Use-Case-Diagramm kann alle Anwendungsfälle eines Systems und deren Verbindungen zueinander grafisch abbilden oder nur eine Gruppe von Use Cases mit ähnlicher Funktionalität. Einzelne Use Cases sind aber als abgeschlossene Prozesse zu betrachten, die sich nicht überschneiden sollten.

Besonders gut geeignet sind Anwendungsdiagramme für die Dokumentation eines ersten Brainstormings mit den Stakeholdern zum gewünschten System, um sich einen Überblick über die geforderten funktionalen Anforderungen zu verschaffen. Darauf aufbauend kann die Spezifikation mit anderen Diagrammtypen und natürlicher Sprache fortgesetzt werden bzw. weiter in die Tiefe gehen. Use-Case-Diagramme zählen zu den Modellklassikern, weil sie sehr einfach zu erstellen und zu verstehen sind. Da die Geschehnisse aus der Perspektive der User dargestellt werden, ist ihr Einsatz in einer frühen Phase der Anforderungserhebung und -dokumentation hilfreich. Bereits für die Abbildung von Geschäftsprozessen oder eben von (Teil)Systemprozesse erweisen sich Use Cases als das Mittel der Wahl. Dank ihnen gelingt es unkompliziert, komplexe Themen grob herunterzubrechen und die essentiellen Funktionen herauszufiltern. Damit bieten sie eine perfekte Diskussionsgrundlage für den folgenden Projektverlauf sowie eine Basis für die weitere Aufschlüsselung und Detaillierung. Zu beachten ist, dass sich Anwendungsfalldiagramme nicht eignen, um systeminterne Abläufe zu dokumentieren oder Funktionen im Detail zu erläutern.

Zusammengefasst sind die Vorteile eines Use-Case-Diagramms, dass es für Stakeholder ohne umfangreiche Erklärungen nachvollziehbar ist und eine anschauliche Darstellung von Sachverhalten erlaubt. Damit können sich die Beteiligten einen Überblick über die wichtigsten Funktionen verschaffen und die weitere Requirementserhebung vereinfacht sich. So ist die Verwendung in Workshops besonders fruchtbar, um Anwendungsfälle und eine erste Skizze der zu entwickelnden Funktionalitäten zu erarbeiten. Allerdings bleibt diese Beschreibung noch ohne Details über das System selbst. Auch zur Bestimmung des Systemkontexts kann das Anwendungsfalldiagramm herangezogen werden. Nachteilig ist, dass häufig Redundanzen und Inkonsistenzen entstehen, da bei der Erstellung von Use Cases das Zielsystem funktional zerlegt und einzelne Abläufe in mehreren Anwendungsfällen relevant sind. Nicht geeignet sind Use-Case-Diagramme für nicht-funktionale Anforderungen. Ebenso stellen sie meist nur einen (oberflächlichen) Teil der Anforderung dar, weshalb es notwendig ist, noch auf andere Dokumentationsformen zurückzugreifen.

Häufig werden Anwendungsfalldiagramme durch Anwendungsfallbeschreibungen ergänzt. Dafür wird meist formularartig natürliche Sprache genutzt, wobei der Grad der Formalisierung von sehr schablonenhaft bis wenig vorgegeben variiert. Das Abfragen bestimmter Informationen schützt davor, wichtige Details zu übersehen und die strukturierte Aufbereitung ermöglicht ein rascheres, weil selektiveres Erfassen als in Prosatexten. Im Gegensatz zu den Anwendungsfalldiagrammen können auch nicht-funktionale Anforderungen in den Beschreibungen erfasst werden. Es gilt jedoch die Schilderungen generell möglichst knapp und präzise zu halten, da sonst das Risiko hoch ist, dass die Beschreibungen schnell ausufern und unübersichtlich werden. Use-Case-Beschreibungen können auch ohne ein entsprechendes Diagramm zum Einsatz kommen.

Aktivitätsdiagramme

Um Abläufe in Systemen und deren Regeln im Detail beschreiben, kommen in der Praxis häufig Aktivitätsdiagramme zum Einsatz, vor allem für komplexe Prozesse. Aufbauend auf Use-Case-Diagramme betrachten diese die Zerlegung der Schritte des Kontrollflusses in Aktivitäten, d.h. wenn alles nach Plan verläuft. Die Dokumentation der Ausführungsbedingungen von Hauptszenarien wird zudem durch Ausnahmen, mögliche Fehler bzw. zulässige Prozessalternativen ergänzt.

Je nach Einsatzzeitpunkt im Projektverlauf, kann der Detaillierungsgrad an die Gegebenheiten angepasst werden. Deshalb ist das Aktivitätsdiagramm sehr beliebt für grafisch darzustellende Geschäfts- oder Betriebsabläufe, um dort die Aktivität eines Teils oder einer Komponente im System zu veranschaulichen. Diese Art des Diagramms ist wie viele andere nicht unbedingt notwendig für die Spezifikation von Requirements. Es empfiehlt sich allerdings, die damit mögliche übersichtliche Darstellung einzubeziehen, wenn Entscheidungen, Alternativen und Ausnahme­situationen in Prozessen visualisiert werden müssen.

Aktivitätsdiagramme verwenden spezielle Formen, die mit Pfeilen verbunden werden. Zu den verwendeten Elementen in einem Aktivitätsdiagramm gehören Aktionen, die dafür stehen, was getan wird, und unterschiedliche Knoten. Die Namen dafür müssen eindeutig sein. Pro Aktivitätsdiagramm darf nur ein Startknoten, ein ausgefüllter, schwarzer Kreis, eingesetzt werden. Dieser repräsentiert das Ereignis, das den im Diagramm dargestellten Ablauf initiiert. Ein bis mehrere Endknoten sind möglich, die das Ende des Ablaufes anzeigen. Darüber hinaus gibt es Kontrollknoten, wie Entscheidungsknoten bzw. Synchronisationsknoten oder auch -balken, die die Regeln beschreiben, wann und wie Aktionen ablaufen können.

Die Beispielgrafik illustriert den Ablauf ‚zum Zielort navigieren‘ mit der Ermittlung einer Route eines Navigationsgeräts. Dabei kommt ein Entscheidungsknoten zum Einsatz, an dem sich die Frage stellt, ob Staus umfahren werden sollen oder nicht. Die Synchronisationsbalken zeigen gleichzeitig ablaufende Aktionen an. Als Fork wird eine Verzweigung in parallele Aktivitäten bezeichnet, Join heißt der Punkt, wenn die Stränge wieder zusammenkommen. Die Kanten, in Form von Pfeilen, verbinden die einzelnen Elemente und stellen die zeitliche bzw. logische Reihenfolge im Prozess dar. Aktivitäten laufen grundsätzlich nacheinander ab, d.h. erst wenn eine abgeschlossen ist, folgt die nächste. Darüber hinaus gibt es ein Hierarchisierungs­element, das wie eine Gabel aussieht, und im Beispiel in der Aktivität Verkehrsinfos erfragen vorkommt. Dieses verdeutlicht, dass eine andere Aktivität aufgerufen wird, die in einem weiteren Aktivitätsdiagramm dargestellt werden kann.

Beispiel für ein Aktivitätsdiagramm

Im Requirements Engineering werden Aktivitätsdiagramme zur Verfeinerung und Detaillierung von Use Cases verwendet. Meist gibt es zu jedem Anwendungsfall­diagramm mindestens ein oder sogar mehrere Aktivitätsdiagramme. Diese dienen der Visualisierung von Prozessen mit fachlichen Ausführungsbedingungen sowie der Darstellung für Aktionen im Fehler- und/oder Ausnahmefall in Abläufen.

Das Aktivitätsdiagramm ist auch für Stakeholder häufig eine unaufwendig zu lernende und zu verstehende Technik. Prozessregeln können damit gut beschrieben werden und der Grad der Detaillierung kann je nach Bedarf gewählt werden. Daraus ergibt sich ein sehr breites Anwendungsspektrum. Auch wenn die Grundzüge von Aktivitätsdiagrammen einfach und ohne Vorwissen zugänglich sind, kommt es in der Tiefe zu beachtlichen Variationen der Modellierung. Wenn diese zur Anwendung kommen, führt das meist dazu, dass das Diagramm von Stakeholdern nicht mehr selbstverständlich erschlossen werden kann.

Zustandsdiagramm

Das Zustandsdiagramm, auch State (Machine) Diagram oder Zustandsautomat genannt, ist ein Verhaltensdiagramm, mit dem die Zustandsänderungen eines Objektes visualisiert werden. Es wird benutzt, um eine Abfolge von Zuständen, die ein Objekt während seines Lebenszyklus einnehmen kann, zu beschreiben. Diese Diagramme eignen sich zur Spezifizierung des ereignisgesteuerten Verhaltens eines Systems, eines Teilsystems oder einer Komponente sowie von Systemschnittstellen.

Besonderes Augenmerk liegt bei Zustandsdiagrammen auf den verschiedenen Zuständen des Systems, den Aktionen und zugehörigen Bedingungen, die zu einem Zustandswechsel führen, sowie den Auswirkungen des Systems auf dessen Umgebung. Ein Zustand meint einen Zeitraum, in dem ein System ein gewisses Verhalten aufweist bzw. auf das Eintreten eines festgelegten Geschehnisses wartet.

Beispiel für ein Zustandsdiagramm

Die gleichen Symbole wie im Aktivitätsdiagramm beschreiben den Beginn des Lebenszyklus eines Objektes, der ausgefüllte Startpunkt, und das Ende, der schwarze Endpunkt mit dem zusätzlichen Ring außen herum. Die Zustands­übergänge, auch Transitionen genannt, verbinden jeweils einen Quell- und einen Zielzustand und werden durch Pfeile dargestellt. Ereignisse, sogenannte Trigger, lösen Transitionen aus. Dabei werden externe, z.B. der Leser gibt das Buch zurück, oder interne Auslöser, das Buch ist kaputt, unterschieden. Daran können als Guard oder Wächterausdruck bezeichnete Bedingungen geknüpft sein, deren Erfüllung Voraussetzung für einen bestimmten Zustandswechsel ist. Die Transition wird durch diese geschützt und der Zustandswechsel kann erst durchlaufen werden, wenn der Wächterausdruck erreicht, also ‚wahr‘, ist. In der Grafik kann dem Zustandsübergang diese schriftliche Verhaltensspezifikation wie eine Bemerkung zugeordnet werden. Die Beschriftung illustriert das auslösende Ereignis, die vorab zu erfüllende Bedingung und/oder die Aktivität (Operation), die beim Zustandswechsel ausgeführt wird. All diese Beschreibungselemente sind optional und können je nach Bedarf kombiniert werden. Obwohl im angeführten Beispiel kein Rautenelement verwendet wird, kann dieses für Kreuzungen bzw. Entscheidungen eingesetzt werden. Gelegentlich umfasst ein Zustand auch mehrere Unterzustände, so dass von einem zusammengesetzten Zustand die Rede ist.

Zustandsübergange können schlecht in natürlicher Sprache abgebildet und so verständlich veranschaulicht werden. Das Zustandsdiagramm unterstützt dabei, Inkonsistenzen zu identifizieren und klare Regeln zu definieren. Im Idealfall bildet es das gesamte Verhalten eines Zustandsautomaten ab, in manchen Fällen ist es jedoch sinnvoll, Details in weiteren Diagrammen aufzuschlüsseln. Dementsprechend kommt das Zustandsdiagramm dann zum Einsatz, wenn Lebenszyklen, von der Initialisierung bis zur Freigabe, oder fachliche Zustände von Geschäftsobjekten modelliert werden sollen. Sie eignen sich auch zur Dokumentation der Informationen, welche Aktivitäten in welchen Zuständen überhaupt erlaubt sind, wodurch das Verhalten eines Objekts sichtbar und nachvollziehbar wird. Zudem dient es als Ergänzung und zum Überblick zu komplexen Prozess- oder Ablaufdiagrammen. Auch eine Bildschirmmaske kann als Zustand angenommen werden. Mit Hilfe eines Zustandsdiagramms ist es möglich, benutzerseitig durch eine Klickabfolge eines Softwaresystems zu führen.

Zustandsdiagramme sind ein wertvolles Instrument zur Modellierung von Systemen, einzelnen Komponenten oder Objekten und ihrem möglichen Verhalten. Speziell um Reaktionen auf unterschiedliche Ereignisse und die Regeln für ein spezifisches Verhalten darzustellen, sind sie hilfreich. Es ist möglich, sowohl das Gesamtsystemverhalten zu visualisieren, z.B. wie mehrere Use Cases parallel und ineinandergreifend ablaufen, als auch viele Detailebenen darzustellen. Ebenso kann es als Analysemodell zum Prüfen von Requirements bzw. zur Dokumentation des Lebenszyklus eines Requirements herangezogen werden. Zustandsdiagramme lassen sich unkompliziert und in vielen Situationen verwenden, zumal selbst ungeübte Leser sie mit ein wenig Übung leicht nachvollziehen können. Viele Menschen liegt allerdings das Denken in Abläufen eher als das in Zuständen, weshalb es eventuell zu Widerständen von Stakeholdern in Bezug auf diese Technik kommt. Besonders detaillierte Zustandsdiagramme sind meist äußerst technisch und dementsprechend nicht für alle Stakeholder geeignet. Darüber hinaus erfordert es viel Erfahrung und Modellierungsexpertise des Requirements Engineers, um zweckmäßige und fruchtbare Zustandsdiagramme zu erstellen.

Auswahl einer Dokumentationtechnik

In diesem Skriptum ist nur von einer ganz kleinen Auswahl an möglichen Techniken die Rede, weshalb es entscheidend ist, bei der vorhandenen Fülle, die sinnvollste Methode zur Dokumentation auszuwählen. In manchen Fällen erscheint die Wahl einfach, speziell wenn ein bestimmtes Vorgehensmodell eine Technik vorschreibt oder diese sich traditionell bewährt hat. Grundsätzlich bestimmen aber viele unterschiedliche Faktoren die Auswahl. Schwierigkeiten sind zu erwarten, wenn die ausgesuchte Technik nicht zu den zu visualisierenden Inhalten bzw. Rahmenbedingungen des Projekts passt oder die Stakeholder die Spezifikation nicht annehmen bzw. verstehen. Daher ist es absolut notwendig, sich rechtzeitig Gedanken über die jeweiligen Vor- und Nachteile einer Methode zu machen. Je mehr verschiedene Techniken zum Einsatz kommen, desto höher ist der Aufwand für die Nachverfolgbarkeit und Konsistenz. Alle Dokumente müssen immer aktuell, miteinander verknüpft und ohne Widerspruch sein. Außerdem entsteht unter Umständen für die Schulung der Stakeholder für jede neue Technik weiteres Investment, ebenso wenn für die Abbildung in einer Technik ein weiteres Tool notwendig ist.

Einflussfaktoren auf die Wahl der Technik:

• Akzeptanz

Niemandem ist geholfen, wenn Stakeholder Anforderungen ignorieren oder ablehnen, weil sie mit der Dokumentationstechnik nicht umgehen können oder wollen.

• Notationskenntnis

Je nach Technik ist unterschiedliches Vorwissen notwendig. Der Requirements Engineer muss ermitteln, ob die Stakeholder, vor allem die Kunden und Nutzer, mit der ausgewählten Dokumentationstechnik vertraut sind und das geforderte Knowhow vorhanden ist.

• Spezifikationslevel

Nicht alle Dokumentationstechniken eignen sich für alle Beschreibungs­ebenen, weshalb es sinnvoll ist, vorab den benötigten Detailierungsgrad zu prüfen.

• Komplexität des zu beschreibenden Sachverhalts

Je nachdem wo die beschreibenden Personen die Schwerpunkte setzen, sind Dokumentationen häufig entweder für das gewünschte Ziel übertrieben und ausufernd oder sie entbehren jeder Vollständigkeit und reichen nicht, um die Komplexität des Projekts darzustellen. Unbedingt ist daher zu Beginn, die Angemessenheit der Dokumentationstechnik zu klären.

• Aufwand-Nutzen-Verhältnis

Aufwand und Nutzen einer speziellen Dokumentationsform müssen für die Beschreibung eines Sachverhalts adäquat sein.

• Konsistenz

Änderungen treten nicht nur nach der Fertigstellung der Anforderungs­dokumentation auf, sondern auch der Weg dorthin ist bereits ein durch­gängiger Changeprozess. Es gilt zu beachten, ob eine Technik sich rasch und unkompliziert adaptieren lässt, da schlussendlich die einzelnen Teile ineinandergreifen sollen.

• Eindeutigkeit

Je nach gewünschtem Detaillierungsgrad sind andere Techniken geeignet. Entscheidend ist, dass bei einer gewünschten simplifizierten Dokumentation nicht die Verständlichkeit auf der Strecke bleibt.

Voraussichtlich müssen in einem Projekt bei der Wahl der Dokumentationstechniken Kompromisse eingegangen werden, daher ist diese gründlich abzuwägen. Der Requirements Engineer hat dementsprechend zu klären, ob die Verwendung einer Technik einen Qualitätsgewinn bedeutet oder ob sie eher Verwirrung stiftet. Ebenso sollen Redundanzen aufgrund unterschiedlicher Herangehensweisen vermieden werden. Speziell wenn Diagramme oder andere formalisierte Dokumentationsformen zum Einsatz kommen, empfiehlt sich ein Leseleitfaden für die Spezifikation. Um von vornherein so wenig Raum wie möglich für Missverständnisse einzuräumen, werden darin alle verwendeten Modelle, die entsprechenden Notationselemente und deren Bedeutung erklärt.

In der Praxis kommen sehr häufig Mischung von Modellen und ausformuliertem bzw. strukturiertem Text zur Dokumentation zum Einsatz. Vorteilhaft ist daran, dass die Kombination die Schwächen der jeweiligen Dokumentationsformen ausgleicht. Dabei ist aber unbedingt darauf zu achten, dass zwischen den einzelnen Darstellungstechniken, vor allem bei der Überarbeitung, keine Inkonsistenzen entstehen.

Wichtig ist, egal bei welcher ausgewählten Technik, dass auf ökonomische Spezifikation Wert gelegt wird. Die am besten passende Dokumentationstechnik ist jene, die eine knappe und gleichzeitig präzise Dokumentation ermöglicht sowie den Aufwand soweit wie möglich minimalisiert. Die Kunst hierbei ist die richtige Balance zwischen Über- und Unterspezifizierung zu finden, also genau herauszufiltern, wie viel ‚genug‘ ist, um verständliche, im Detail korrekte und nicht ausufernde Darstellungen zu erhalten. Das passende Sprichwort an dieser Stelle lautet: So viel wie nötig, aber so wenig wie möglich!

Glossar

Jede Disziplin, jedes fachliche Umfeld hat seine eigene Sprache und sein eigenes Vokabular. Das Verständnis von Begriffen ist, wie bereits erwähnt, bei Menschen aus verschiedenen Gründen unterschiedlich. Je abstrakter Worte sind, desto höher ist die Wahrscheinlichkeit von Missverständnissen. So beschäftigt der Versuch einer Definition z.B. von Liebe, Familie, Heimat die ‚Philosophen‘ dieser Welt seit Jahrtausenden.

Um etwaige Missverständnisse in der Beschreibung der Anforderungen zu verhindern, ist es entscheidend, die für das Projekt relevanten Grundbegriffe zu definieren und in einem Glossar zu sammeln. Einerseits erweist sich das als hilfreich, wenn fachfremde Stakeholder beteiligt sind, andererseits beugt es auch in der eigenen Disziplin abweichende Interpretationen vor. Ein scheinbar harmloser und allgemein verständlicher Begriff wie ‚speichern‘ oder ‚archivieren‘ kann im Softwarekontext unterschiedlichste Deutungsweisen zur Folge haben.

Um eine konsistente Terminologie zu erreichen, empfiehlt es sich, frühzeitig alle in der Anforderungsdokumentation verwendeten Fachbegriffe und Abkürzungen aufzulisten, zu erklären und den Stakeholdern zugänglich zu machen. Ein Glossar zu erstellen, heißt allerdings nicht, das Rad neu erfinden zu müssen. In ähnlichen Kontexten, Organisationen und/oder Projekten zeigen sich häufig gleiche oder ähnliche Begriffe. Daher ist es sinnvoll, vorhandene Vokabularsammlungen wiederzuverwenden und zu ‚recyceln‘ bzw. sich schlau zu machen, da für manche Fachgebiete öffentlich zugängliche Definitionen vorhanden sind. Diese erlauben eine enorme Reduktion des Aufwands für Folgeprojekte.