REQms

Motivation

So ziemlich jedes System lässt sich durch die globale Anforderung „tu doch einer was“ beschreiben. Als anderes Extrem ist es auch problemlos möglich, 80% der Entwicklungs-Team-Kapazität mit der Dokumentation von Anforderungen zu binden. REQms bildet hier einen funktionierenden Trade Off. Die Ziele sind:

Eine lebendige Anforderungsanalyse-Umgebung schaffen, die in einem hochdynamischen Team funktioniert.
Ein Anforderungsmanagement, das zu iterativem Vorgehen passt.
Priorisierung muss auf allen Ebenen unterstützt werden, um den Fokus zu behalten.
TestFirst ist als integraler Bestandteil verankert.

Übersicht über das System

Dokumentierte Anforderungen erleichtern die Übersicht über ein System. Damit wird es einfacher,

auf Vollständigkeit zu prüfen und
das System zu strukturieren.

Wissensvermittlung

Sobald Systeme ihre Lebensberechtigung über den ersten Entwurf hinaus bewiesen haben, wird es wichtig auch über die Vermittlung des erarbeiteten Wissens nachzudenken. Durch die gemeinsame Sprache und durch die vermittelte Übersicht sind aufgeschriebene Anforderungen für die Einarbeitung von neuen Projekt-Beteiligten der ideale Startpunkt.

Erinnerungshilfe

Auch im kooperativen Umfeld haben Verträge einen Mehrwert als Erinnerungshilfen. Aufgeschriebene Anforderungen sind in dieser Beziehung einem Vertrag sehr ähnlich – denn sie halten fest, was vereinbart war. Damit lässt sich sicher die ein oder andere Diskussion versachlichen und Frust vermeiden. Ein zweiter wichtiger Aspekt ist, dass mit notiert werden kann,

wer hatte den Wunsch (mit wem muss bei einer Änderung gesprochen werden) und
warum hat sich das Team für x-y entschieden (damit muss die ein oder andere Diskussion nicht wiederholt werden).

Ankerpunkt für Abnahmetests

TestFirst Anhänger suchen immer nach Ankerpunkten für Abnahmetests. Abnahmetests helfen hier schon vor jeglicher Realisierung, wichtige Anforderungsdetails zu konkretisieren. Die Forderungen nach Abnahmetests als integralem Bestandteil helfen dabei,

dass Anforderungen vom Verantwortlichen nochmals durchdacht werden,
dass Anforderungen damit ein erstes Mal validiert werden,
die Auswirkung einer Anforderung nochmals konkret zu beschreiben.Last but not least – Abnahmetests sind für die gesamte Systemlebensspanne als Regressionstests wichtig.

Erklären um nachzudenken

Schon längst verstanden geglaubte Zusammenhänge sind plötzlich gar nicht mehr so stringent logisch aufgebaut, sobald man mit der Aufgabe konfrontiert ist, diese einem dritten zu erklären. In solchen Situationen verändert sich regelmäßig das Bild im Kopf. Ein ähnlicher Effekt tritt auch beim Aufschreiben von Anforderungen auf. Ein Teil des Widerwillens gegen die Dokumentation von Anforderungen liegt sicher in dieser Denkarbeit begründet – und zeigt gleichzeitig auch die Notwendigkeit.

Umsetzung

Struktur

System-Scope

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. 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-orientedRequirementsLanguage

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. Weiterführende Literatur finden Sie z.B. unter

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.

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.

ProjectScope (1.)

Zentrales Element WorkPackage (9.)

Workpackages oder Arbeitspaket sind die zentralen Element im ProjectScope und referenzieren zentral auf die umzusetzenden Anforderungen im SystemScope. Auf der einen Seite stellen Arbeitspaket die Verbindung zu den referenzierten Anforderungen dar, auf der anderen Seite bieten Arbeitspakete den richtigen Punkt, um die Arbeit im Projekt zu organisieren. Alle weiteren Elemente im Projekt-Scope (Projektplan, Statusberichte, Controlling und Releasebeschreibung) referenzieren ihrerseits auf Arbeitspakete. Wichtige Bereiche im Arbeitspaket sind:

title,
goal und resultingArtefacts, um das zu erreichende Ziel zu beschreiben,
description und plannedEfford, um die Umsetzungsschritte und deren Aufwand festzuhalten,
asignee für die Personalplanung und
realEfford, um Schätzungenauigkeiten zu identifizieren.Unter https://www.domaindrivenarchitecture.org/vorlagen finden Sie eine Vorlage für Arbeitspakete.

Tests

Im Kontext von Umsetzungsprojekten sind zwei Testarten relevant, die Abnahme-Tests und zusätzlich noch Entwickler-Tests.

AcceptanceTests: Über die im Arbeitspaket referenzierten Anforderungen sind auch die betroffenen Abnahme-Tests benannt, die mit der Umsetzung bestanden werden müssen.
DevelopmentTest (10.): Zusätzlich ist es nützlich, weitere Entwicklertests zu formulieren, die nur im Rahmen des Umsetzungs-Projektes gültig sind. Bei Bedarf können ausgewählte Entwicklertests als Abnahmetest übernommen werden und gelten so über die Projektlebensdauer hinaus.

ScreenFlows

ScreenFlows sind wesentliche Elemente, um die Benutzerführung zu gestalten. Nach einer Umsetzung können Screenflows in Form von Benutzerhandbuch-Einträgen weiterhin fortbestehen.

Umsetzung mit REQms

Versionierung von Anforderungen

In REQms sind die Anforderungen versioniert … im Beispiel hier ist die Version001 stabil und in der Version002 kann weiter spezifiziert werden.

Um eine neue Version zu erstellen:

Anforderungen sind direkt referenzierbar

Per URL sind alle Anforderungen versioniert referenzierbar.

Ein UseCase

Hier ein Beispiel für einen UseCase, unten stehen die Abnahmetests.

Der zugehörige Akzeptanztest

Suche nach Anforderungen

REQms bietet auch die Möglichkeit zur Volltext-Suche:

Eine Ansicht

Hier sieht man eine Ansicht mit eingeklappten Kapiteln:

Und hier ist das Kapitel „Community Suche“ aufgeklappt … alle zugeordneten Anforderungen stehen untereinander.

Der Edit-Mode zeigt, die Anforderungen sind hier nur referenziert.

Testunterstützung

Alle Anforderungen sind TestSuites im Sinne von REQms. Damit lassen sich die Anforderungen auf beliebigen Ebenen in REQms Manier gemeinsam testen. Eine generische Fixture präsentiert die Testanweisungen dem Tester.

Als Ergebnis bekommt man eine schöne Test-Zusammenfassung für den einzelnen Test…

Und für alle durchgeführten Tests und Retests ...

Interesse?

Kontakt aufnehemen

Kontaktieren Sie uns unter buero@jerger.org.