Arbeitsergebnisse und Dokumentationspraktiken

Ein dokumentiertes Zwischenergebnisoder finales Ergebnis, das im Zuge eines Arbeitsprozesses entsteht.

Jede im Rahmen des RE erhobene und dokumentierte Information stellt ein Arbietsergebnis dar (damit auch jede Anforderung).

In der Praxis manchmal auch Artefakt genannt.

Arbeitsergebnisse können in anderen Arbeitsergebnissen enthalten sein.

Individuelle Anforderung in natürlicher Sprache

User Story

Use Case

Grafisches Modell

Aufgabenbeschreibung (Zusammenfassung von Anforderungen)

Externe Schnittstellenbeschreibung

EPIC

Feature (Abgrenzbare Eingenschaft des Systems

-System-,Geschäfts-,Stakeholder- oder Benutzer Anforderungsspezifikation in Form eines Anforderungsdokuments

-Product oder Sprint Backlog

-Story Map (eine Menge von User Stories die miteinander in Beziehung gesetzt wird)

-Vision (konzeptuelles Leitbild für das zukünftige System

-Glossar (eindeutige & abgestimmte Terminologie)

-Textuelle Beschreibung oder grafische Skizze (um Informationen zum besseren Verständnis zu visualisieren)

-Prototypen (Verbesserung des Verständnis bzgl. der Eingenschaften des Systems und zur Validierung der Anforderungen)

-Natürlichsprachig

-Vorlagenbasiert (auc template oder schablonenbasiert)

-Modellbasiert (z.B. Klassendiagram, UML oder Aktivitätsdiagramm)

-Zeichnungen & Prototypen

kurzlebig

-Für kurzfristig relevante Informationen,

-kein formalles Änderungsmanagement,

-Arbeitsergebniss wird nach der Nutzung nicht weiterverwendet

weiterentwickelnde Arbeitsergebnisse

-Werden erstellt und im Projektverlauf weiterentwickelt z.B. Use Cases

-Formelles Änderungsmanagement kann sinnvoll sein

Langlebig

-Über die gesamte Projektlaufzeit relevant

-z.B. Stakeholder Anforderungen, Systemanforderungen, Systemvision

-Formelles Änderungsmanagement

-Problem- und Projektkontext

-Grad des gemeinsmen Verständnis des Problems

-Freiheitsgrade für den Entwurf und die Programmierung

-Verfügbarkeit von schnellen Feedbackzyklen mit Stakeholdern

-Kosten vs. Nutzen einer detaillierten Spezifikation

-Auferlegte Standards und regulatorische Einschärnkungen

Ein Aspekt unterscheidet Anforderungen hinsichtlich Funktion, Qualität und Randbedingungen.

Bei der Dokumentation von Funktionale Anforderungen werden wiederum die Perspektiven Struktur, Funktion und Verhalten unterschieden.

Jede Perspektive kann getrennt voneinander dokumentiert werden.

-Beabsichtigter Zweck

-Redundanzen vermeiden (nicht gleiche Anforderungen in verschiedenen Arbeitsergebnissen sondern Referenzen)

-Inkonsistenzen (widersprüchlichkeiten) vermeiden

-Konsistenz von Begriffen

-Strukturierung (von Arbeitsergebnissen)

Arbeitsergebnis

-Welche Arbeitsergebnisse und zu welchem Zweck?

Abstraktionsebene:

-Welche Ebene zu welchem Zweck und welche Arbeitsergebnisse auf welcher Ebene?

Detaillierungsgrad:

-Welcher Detaillierungsgrad der Anforderungen innerhalb der Abstraktionebenen im Arbeitsergebnis?

Repräsentation:

-Wie sollen die Arbeitsergebnisse repräsentiert werden?

-Frühzeitige Planung des Aufwands und der Ressourcen wird unterstützt

-Konsumenten/innen wissen was sie erwarten können

-Späte umstrukturierung der Arbeitsergebnisse wird weitgehend vermieden

-Redundanzen werden z.T. vermieden

Vorteile

-extrem ausdrucksstark und flexibel

-es lässt sich fast jede Anforderung formulieren

-für jeden ohne Einarbeitung verständlich

Probleme

-Mehrdeutige Arbeitsergebnisse

-Aspekte werden unbeabsichtigt miteinander vermischt

-unvollständige Beschreibung (z.B. was wird von wo wohin übertragen)

-unspezifische Substantive (z.B. der registrierte Anwender anstatt nur Anwender)

-unvollständige Bedingungen (z.B. wenn… dann..)

-Unvollständige Vergleiche (z.B. innerhalb von drei Sekunden anstatt schnell)

-Passivformulierungen (Verantwortlicher wird nicht erfasst)

-Universalquantoren (generalisierte Angaben zur Häufigkeit z.B. immer oder nie) —> Am schlimmsten

-Nominalisierung ( z.B. Autorisierung wohinter sich ein komplexer Begriff verbirgt)

-Satzschablone (syntaktische Struktur für individuelle Anforderungen oder User Stories)

-Formularvorlagen (z.B. Use Case Spezifikation

-Dokumentvorlagen (z.B. Lasten und Pflichtenheft)

-Schaffen einer klaren wiedererkennbaren Struktur

-Hilfe bei der erfassung wichtigster Informationen

-Anforderungen und Spezifikationenen einheitlich aussehen lassen

-Verbesserung der Gesamtqualität von Anforderungen und Anforderungsspezifikationen

-Inhalt kann vernachlässigt werden

-In Vorlagen fehlende Aspekte werden leichter vergessen

Bauplan für einen syntaktische Struktur einer einzelnen Anforderung oder Userstory in natürlicher Sprache.

Können für funktionale Anforderungen, Qualitätsanforderungen oder Randbedingungen verwendet werden.0

Abstraktes Bild einer existierenden oder noch zu schaffenden Realität.

Eigenschaften:

-Abbild der Realität

-Verkürzung der Realität

-Pragmatische Eigenschaft

Grafische Repräsentation von Teilen der Inhalte eines Modells

Syntax:

Legt die zu verwendenden Notationselemente fest und definiert die gültigen Kombinationenen dieser Sprachkonstrukte.

Semantik:

Definiert die Bedeutung einzelner Notationelemente und bildet damit die Basis für die Interpratation von Modellen der jeweiligen Modellierungssprache.

Vorteil:

-Beziehungen zwischen den Anforderungen werden klarer

-Fokus auf auf ausgewählte Aspektet verringert die Herausforderung

-Syntax der Modellierungssprachen reduziert Mehrdeutigkeit

Nachteile:

-Konsistenz halten ist schwierig

-Aufteilung der Infos auf mehrere Modelle macht eine Integration schwierig

-Fokus liegt auf den funktionalen Anforderungen

-Nicht jede Information kann dargestellt werden

Kombi aus natürlicher Sprache und Modellen wird deshalb oft verwendet.

-Spezifikation (Natürlichsprachige Dokumenattion ersetzen)

-Dekomposition (Zerlegung der komplexen Realität in Teile)

-Paraphrasierung (umschreiben, Bessere Verständnis)

-Validierung (Überführung von natürlicher Sprache in ein modell deckt bspw. inkonsistenzen auf)

Kontextmodelle spezifizieren das System und die Akteure im Systemkontext und auch die Schnitstelle zwischen Sysem und Kontext.

Ein Kontextmodell wird durch Kontextdiagramme gebildet.

Boxes and Lines Digramm

Datenflussdiagramm

Use Case Diagramm der UML

Blockdefinitionsdiagramme der SysML

Notationelemente:

Prozesse: Funktion des Systems

Terminator: Objekte wie z.B. Personen, Rollen, Abteilungen,…)

Datenfluss: Transport von Daten zwischen Prozess und Terminator

Use Case Diagramm +Use Case Spezifikation = Use Case Model

Use Case: Für das System typische Interaktion der Akteure mit dem System

Akteur: Stehen für Personen, Rollen, Systeme und befinden sich außerhalb der systemgrenze

Systemgrenze: Separierte System von der Umgebung

Beziehungen: Kommunkationsbeziehung zwischen Use case und Akteur

Es eigenen sich verschiedene Modellierungssprachen wie z.B:

-ERM Model

-Klassendiagramme der UML

betrachtet

-die Transformation von Eingabedaten in Ausgabedatendie Transformation von Eingabedaten in Ausgabedaten

-das Ablaufverhalten von Funktionalität und Prozessen das Ablaufverhalten von Funktionalität und Prozessen

geeigentete Modellierungssprachen sind

-Aktivitätsdiagramm (UML)

-BPMN

-Datenflussdiagramm

-Domänen Story Model

-Use case Diagramm (UML)

-Modellierung von Abläufen

betrachtet

-die ein System oder Systemkomponente einnehmen kann mit den zugehörigen einnehmen kann mit den zugehörigen ZustandsübergängenZustandsübergängen

-Verhalten des Systems nach außen in diesen ZuständenVerhalten des Systems nach außen in diesen Zuständen

-Reaktionen des Systems auf EreignisseReaktionen des Systems auf Ereignisse

-Lebenszyklus von GeschäftsobjektenLebenszyklus von Geschäftsobjekten

Geeigenete Modellierungssprachen:

-Statechart

-Zustandsdiagramme

Beschreibt das Verhalten eines Elements mit Hilfe der Zustände, die es annehmen , die es annehmen kann, und der Zustandsübergänge oder Transitionen, die durch interne oder externe Ereignisse angestoßen werden.

-Helfen bei unterschiedlichen Begriffsverständnissen

-Sind Arbeitsergebnisse

-Häufig vorlagenbasiert und in natürlicher sprache

-Inhaltliche Abhängigkeiten können durch Klassendiagramme repäsentiert werden

-Kontextspezifische Begriffe

-Alltagsbegriffe

-Abkürzungen/ Akronyme

-Synonyme

-Homonyme

-Zentrale Verwaltung

-Verantwortlichkeiten klären

-Pflege über die gesamte Projektlaufzeit

-Zugänglich für alle Projektbeteiligten

-Verwendung des Glossars ist verbindlich

-Abstimmung mit Freigabe von Stakeholdern notwendig

-Einheitliche Struktur

Leichtgewichtige Anforderungsspezifikationen aus der agilen Entwicklung

-Product Backlog

-Sprint Backlog

-Story Map (User Stories)

-

-Entwicklungsprozess (konventionell/ Agil)

-Art des Projekts und Anwendungsdomäne (Wie sicherheitskritisch?)

-Vertrageliche Vereinbarungen (zw. Auftragegeben und nehmer)

-Umfang des Auftragsdokuments (Abhängig vom detaillierungsggrad der Anforderungen)

Eigenen sich zum Hinterfragen von bereits erarbeiteten Anforderungen und zur Ermittlung von Anforderungen

Z.B. User Interface Prototypen

-machen Anforderungen erlebbar

z.B:

-Wireframes (wenig Aufwand)

-Mock-Ups (mittlerer Aufwand)

-Native Prototypen (hoher Aufwand)

dienen zur sukzessiven Weiterentwicklung

Pilotsysteme die Schrittweise zum gewünschten System weiterentwickeltw erden

Ähnlich MVP in der agilen Entwicklung

Adäquat

Anforderungen für alle Stakeholder korrekt, untereinander

abgestimmt

Notwendig

Gültig / aktuell bezogen auf Systemkontext

Eindeutig

Eindeutig und nicht missinterpretierbar

formuliert, konsistent

Vollständig

Anforderungen enthält alle Informationen (in sich abgeschlossen)

Verständlich

Anforderungen für alle adressierten Stakeholder fachlich verständlich formuliert. Benutzung der Begrifflichkeiten aus Glossar

Prüfbar

Nachweis durch Test oder Messung muss möglich sein

Konsistent

Das Arbeitsergebnis muss konsistent (keine sich widersprechenden Anforderungen) und widerspruchsfrei sein

Nicht redundant

Jede Anforderung nur einmal beschrieben, keine Überdeckungen

Vollständig

alle relevanten Anforderungen sind zum Arbeitsergebnis enthalten zum Arbeitsergebnis enthalten

Modifizierbar

Geeignete, einfach erweiterbare und modifizierbare Strukturierung erlaubt modifizierbare Strukturierung erlaubt Änderungen

Verfolgbar

Enthaltene Anforderungen können zurück zu Quellen und vorwärts Richtung Umsetzung verfolgt werden

Konform

vorgebeneFormalien (Dokumentationsrichtlinien etc.) müssen erfüllt werden