System Scope (1.)
Zentrales Element Requirements (2.)
Requirements sind das zentrale Element im System Scope. Fast alle Elemente referenzieren diese einzelnen Anforderungen. Das möglichst so, dass die beschriebenen Arten von Änderungen jeweils nur an einer Stelle eine Veränderung der Dokumentation verursachen. Die System-Vision ist die einzige Ausnahme – ich gehe davon aus, dass eine System-Vision hinreichend stabil ist, um referenziert zu werden. Damit die Gratwanderung zur Übersicht über das System gelingt, werden Anforderungen auf einer möglichst hohen Abstraktionsebene beschrieben. Anforderungen haben die folgenden Eigenschaften:
- Sie sind eindeutig identifizierbar und referenzierbar (wird durch den Stereotyp <
> gekennzeichnet). - Sie sind einzeln versioniert (wird durch den Stereotyp <
> gekennzeichnet). Als versionierbare Objekte sind Anforderungen implizit auch veränderbar. Veränderungsdatum und Autor werden festgehalten. - title: Neben der ID haben Anforderungen auch einen Titel. Erfahrungsgemäß verändert sich der Titel des öfteren und wird daher nicht zur Referenzierung verwendet.
- state: In unserem Fall reicht die einfach Unterscheidung in [premature, mature, deprecated].
- Optional kann auf Ebene von Anforderungen zusätzlich der Geschäfts-Wert erfasst werden. Diese Größe ist für eine Kosten unabhängige Priorisierung von Anforderungen nützlich.
Die folgenden Anforderungstypen werden typischerweise unterschieden:
Non Functional Requirements (4.)
Quelle von nichtfunktionalen Anforderungen sind oftmals technische Rahmenbedingungen (Speichergröße, Netzwerkbandbreite, o.ä.) oder Performance-Vorgaben. Eine bewährte Notation für nichtfunktionale Requirements ist die „Goal oriented Requirements Language Notation“ (GRL). GRL erlaubt auch bei nicht funktionalen Anforderungen das „Warum“ zu beleuchten. Das ist in meinen Augen ganz hilfreich – denn die Umstände zu z.B. „Requests müssen in 50ms beantwortet sein“ können sich durchaus ändern. Dann ist es immer hilfreich, das Warum zu kennen. Wikipedia: http://en.wikipedia.org/wiki/Goal-oriented_Requirements_Language
UseCase (5.)
UseCases sind die klassischen Vertreter für funktionale Anforderungen. Quellen für funktionale Anforderungen sind die gewünschten fachlichen Funktionen oder werden aus gesetzlichen Rahmenbedingungen abgeleitet (z.B. Datenschutz). UseCases sind damit eng mit dem budgettragenden Stakeholder verbunden. Ein UseCase beschreibt, wie das System einem Akteur erlaubt ein Ziel zu erreichen.
- ID – die eindeutige Kennung, wird einmal ganz am Anfang vergeben.
- title – der Titel, eine kurze Zusammenfassung
- state – [premature, mature, deprecated]
- actor – wer ist der Handelnde
- stakeholdersAndInterests – wer ist Stakeholder und was sind seine Interessen
- normalFlow – der Normalfall / GoodCase
- alternativeFlow – wenn nötig, Varianten oder Fehlerfälle
Wer UseCases kennt, wird bemerken, dass die Zielebene fehlt. In unserem Fall reicht die Überblicksebene in den allermeisten Fällen aus. Wikipedia: http://en.wikipedia.org/wiki/Usecase
Aspect-oriented User Requirements Notation
Ein weitere hilfreiche Notation für funktionale Anforderungen ist die sogenannte Aspect-oriented User Requirements Notation. Mit dieser Notation lassen sich querschnittliche funktionale Anforderungen gut beschreiben. Ein typisches Beispiel für solche querschnittlichen Anforderungen sind z.B. Rechte von Rollen oder Fehlerprotokollierung. Zum Weiterlesen empfehle ich hier „Aspect-Oriented Software Development with Use Cases“ v. Ivar Jacobson & Pan-Wei NG oder Aspect-Oriented User Requirements Notation - University of Ottawa (http://www.springerlink.com/content/252645l617782770/) von G.Mussbach.
SystemInterface (6.)
SystemInterfaces oder System-Schnittstellen leiten sich meist aus funktionalen Anforderungen ab; Schnittstellen können ihren Ursprung aber auch in verwendeten Fremdsystemen haben. Elemente einer Schnittstellenbeschreibung sind:
- version: Die Version der Schnittstelle – denn es kann passieren, dass sich die Schnittstellen von Fremdsystemen ändern, ohne angeschlossene Systeme zu berücksichtigen.
- source: Das Quellsystem
- sink: Das System, das die Daten verwendet
- dataStructure: Datenstruktur für die bereitgestellten Daten
- description: Unstrukturierte Beschreibung – wann werden Daten bereitgestellt/ abgeholt, Qualität der Bereitstellung, Gültigkeitszeitraum und Fehlerbehandlung.
Über Hinweise für eine gut funktionierende Notation bin ich dankbar.
4.1.2 Acceptance Test (3.)
Im Acctepance Test im Sinne eines Abnahmetests wird beschrieben, was erfüllt sein muss, damit die Anforderung als umgesetzt gewertet wird. Während Anforderungen nach Möglichkeit auf einer hohen Abstraktionsebene formuliert sind, können in Tests wichtige Details beschrieben werden. Beispiele zur Testbeschreibung finden sich im Anhang unter 5.4 Der zugehörige Akzeptanztest.
Requirements View (7.)
Ansichten, dienen dazu, Anforderungen zu strukturieren. Ansichten entsprechen gedanklich ausdruckbaren Dokumenten, die für die entsprechende Zielgruppe zusammengestellt wurden. Um nicht in der DRY-Falle zu landen, werden hier Anforderungen ausschließlich referenziert. Um im ausdruckbaren Dokument jetzt nicht nur Links stehen zu haben, ist ein Tooling sehr hilfreich, das auch Inhalte von referenzierten Anforderungen anzeigen kann (siehe Anhang 5.6 Eine Ansicht). In einer weiteren Ausbaustufe ist die Möglichkeit zur zusätzlichen Einschränkung auf weitere Strukturelement ausgesprochen nützlich (Titel, Stakeholder, ...).
DomainArchitecture (8.)
Die Domain Architecture oder fachliche Architektur beschreibt die Unterteilung des fachlichen Problems. Neue Erkenntnisse, die während Analyse, ausprobieren oder Umsetzung entstehen, führen mit Sicherheit dazu, dass sich die Unterteilung und Strukturierung in der fachlichen Architektur verändert. Damit sich diese Veränderungen nicht so massiv auf schon bestehende Anforderungen auswirken, wird die semantische Verbindung zwischen Anforderungen und der fachlichen Architektur durch Requirements Views realisiert. Die in der fachlichen Architektur verwendeten Elemente wie Aggregate, Entitäten, Repositories, usw. sind im Domain Driven Design beschrieben.