Requirements Engineering und Management mit Modellen

Hör- und Sehbehinderte Menschen sind in unserer Welt vielfach ausgegrenzt. Sie können kaum an modernen Meetings teilnehmen, da sie beispielsweise entweder die Mundbewegungen in Conferencing Systemen nicht wahrnehmen, Präsentationen nicht verarbeiten können oder Gebärden nicht verstanden werden. Sie brauchen eine Übersetzung in einem jeweils anderen Medium, das unabhängig von dem Kommunikationsmedium der Kollegen ist, die jedoch wieder in deren Kommunikation zeitgleich einfließen kann. Wie lässt sich ein solches Produkt anhand der üblichen Requirements Engineering Methodiken entwickeln? Mit einer Modellierung in einem gemeinsamen Tool? Ein Produkt wie Ears and Eyes on Demand (E&EoD)¹, einem Dienst der mittels Smartphone-Apps mit Video und Audio Devices diese Übersetzung des Hörbehinderten bereitstellt oder dem Sehbehinderten das Auge leiht?

Die Methodik des Anforderungswesens

Es gibt einige methodische Anforderungen an die Dokumentation von Produkt-Anforderungen, die unter anderem im International Requirements Engineering Board (IREB e.V.), im International Institute of Business Analysis (IIBA) oder einzelnen Werken (eCH-0120 u.a.) beschrieben sind. Produktentwicklungen sind heute agile Entwicklungen, die sich durch eine hohe Flexibilität in der Definition und Umsetzung von Anforderungen auszeichnen. Welche wichtigen Anforderungen an eine modellgetriebene Methodik sind entscheidend? Welche modellgetriebene Methodik ist hierbei zu empfehlen?

Welche methodischen Anforderungen existieren

Methodische Verfahren, die eine modellgetriebene Entwicklungs- und Design-Methodik (UML2/SysML) begünstigen, sind bereits definiert:

• Rational Unified Process (RUP): Model Visually, Traceability entlang des Vee-Modells², werkzeugunterstützte Detaillierung (Drill-Down) vom Elementen
• Agile Unified Process (AUP): Agile Modeling: Epics, Storys, Geschäftsobjekte, Prozesse, Anwendungsfälle, Funktionale und Nicht-funktionale Anforderungen mit Beziehungen untereinander
• Agile Sprint Planning: Zerlegung von Epics, Storys in realisierbare Einheiten eines Sprints

Allgemeine Eigenschaften von Requirements in diesem Kontext sind:

• Beziehungen von Anforderungen untereinander haben eine Semantik (Multiplizität, Bedeutung, Rahmenbedingungen, Regeln), die kaum textuell dargestellt werden kann
• Intuitive Verständlichkeit grafischer, visueller Anforderungen aus Elementen und Beziehungen
• Mix aus Visualisierung und detaillierter Beschreibung (ggf. erst im Ausdruck / Export).

Das RE Modell Meta-Pattern (REMMP)

Es gibt keine einfach zu adaptierende Methodik, die innerhalb weniger Stunden definiert ist und mit der eine einfache und angepasste Methodik für die entsprechende Produktentwicklung genutzt werden kann. In unseren Projekten hat sich das RE Modell Meta-Pattern bewährt.

Ein Metamodell basierend auf dem Meta Object Facility (MOF)³ der Object Management Group (OMG) wäre das richtige Mittel, zu beschreiben, welche methodischen Anforderungen für die Dokumentation von Produkt-Anforderungen existieren. Der Nachteil ist, dass es von vielen Stakeholdern, Product Ownern und anderen im Geschäft tätigen Kollegen wegen der Abstraktion nicht verstanden wird. Wir haben statt dessen ein Meta-Pattern definiert. Alle Elemente sind so modelliert wie ihre späteren Artefakte und zeigen so eine Art abstraktes Beispiel, an dem sich jeder orientieren kann. Schließlich ist es wichtig, die Stakeholder von Anforderungen im Boot zu haben und sie zu motivieren, mit Modellen zu arbeiten, die sie intuitiv verstehen können.

Durch das REMMP wird für die modellierten Beziehungen die jeweilige Traceability oder Semantik aufgezeigt, die nur modelliert werden soll. In anderen Worten: genau diese Beziehungstypen sollten für jedes Element existieren. Entsprechend der agilen Essenz des agilen Manifests, der „Maximierung nicht getaner Arbeit“, wird für die zu erstellenden Requirements-Modelle die minimale Traceability sowie die minimal erforderliche Semantik aufgezeigt. Jede Beziehung kann darüber hinaus benannt werden und kann Anforderungen haben.

Abgrenzung zum weiteren Detail-Design

Wesentlich in vielen Requirements-Modellen ist es, den für das Business erforderlichen Teil der Anforderungen klar abzugrenzen. Das Business versteht durchaus die Modellierung und deren Artefakte wie Epics, User Stories, Anwendungsfälle, Prozesse, Features und User Requirements (oft die Representation der Nicht-funktionalen Anforderungen) sowie deren typischen Beziehungen.

Die Abgrenzung von Scope/CIM zu PIM/PSM/Code⁴ geschieht hier mit einer Use Case Realisierung als Collaboration. Das ist keine vollständige elementbezogene Traceability entsprechend dem Vee-Modell, aber es ist praktisch und allemal besser als die meisten anderen Lösungen, zumal es an dieser Stelle häufig zu einem Werkzeugbruch kommt.

Sollten auch die Testfälle modelliert werden, so ist das Meta-Pattern um einen Testcase und eine „verifies“-Beziehung zum Use Case zu erweitern.

Das weitere Detail-Design auf der Ebene von PIM/PSM/Code beginnt bei den Elementen der Use Case Realisierung Collaborationen. Hier das Vee-Modell zur Orientierung:

Anwendung des REMMP bei der Produktentwicklung

Wenn wir bei der o.a. Aufgabenstellung bleiben, so ist für die Registrierung eines Sehbehinderten folgende Modellierung möglich. Natürlich sind alle Epics, Stories auch in einer Textliste verfügbar, hier werden jedoch nur die Modellteile, die diesen Teilaspekt umfassen, dargestellt.

Das folgende Diagramm zeigt die Epics und Personas, wie es im Agile Profile vorgesehen ist:

Im Diagramm stellt eine “visually impaired” Persona mit einem Epic dar, das auf die speziellen Herausforderungen mit einer virtuellen Leihe eines Auges eingeht. Ein zweites Epic beschreibt die generelle Registrierung einer gehandikapten Person im Allgemeinen. Als Voraussetzung für die Hilfe ist eine Registrierung notwendig.

Im folgenden Diagramm wird ein Epic auf die Stories herunter gebrochen, wobei beispielhaft ein User-Requirement (Nicht-funktionale Anforderung) mit einer Story verknüpft ist:

Epics sind typischerweise zu abstrakt und wenig detailliert, so dass der Registrierungsprozess weiter in zugeordneten User Stories detailliert wird. So wird beschrieben, dass die Registrierung den Bezug Person – Gerät und den Test des Einschränkungsgrades anhand von Kriterien zusammen mit einer individuelle Einführung durch den Service Agenten umfasst.

Im folgenden Diagramm werden die Use Cases und die realisierenden Collaborationen mit logischen Komponenten (vereinfacht) dargestellt, wobei die modellierten Elemente in Swimlanes gemäß den Vee-Modell Ebenen zugeordnet werden:

Für den Registrierungs-, Test- und Verifizierungsprozess des Nutzer werden die verantwortlichen, verarbeitenden logischen Komponenten benannt. Die Darstellung zeigt, wie Epics und User Stories in Use Cases (diesen sind typischerweise Test Cases nach dem Vee-Modell zugeordnet) zerlegt und über realisierende Collaborationen logische Funktionen, in logische Komponenten herunter gebrochen werden. Somit entsteht eine saubere Zuordung der geschäftlichen Anforderungen (Epics, User Stories), der Informatik-Anforderungen (User Stories, Use Cases, Requirements) und der Realisierungsgrundlage (logische Komponenten) für die Architekten. Eine Modellierung macht dies visuell und einfach verständlich.

Anforderungen, die in dieser Form dokumentiert werden, können vom Business einfach verstanden und abgenommen werden und sind auch vom Architekt, Designer oder Entwickler gern gesehen. Da die Anforderungen auch in einer textuellen Form tabellarisch verarbeitbar sind, entsteht ein ähnlicher Erstellungskomfort wie mit einem Sheet. Es ist die Semantik zusätzlich visuell enthalten, was in einer reinen textuellen Spezifikation, wenn erforderlich, kompliziert zu beschreiben wäre.

Wie ist Ihre Erfahrung mit der Modellierung? Über Fragen oder Rückmeldungen, auch zum Venture E&EoD, das ich derzeit gründe und leite, würde ich mich sehr freuen.

 

Hinweise

[1] Ears and Eyes on Demand (E&EoD)¹ ist ein Dienst der mittels Smartphone-Apps mit Video und Audio Devices diese Übersetzung des Hörbehinderten bereitstellt oder dem Sehbehinderten das Auge leiht. www.ears-and-eyes.eu
[2] Das Vee-Model beschreibt Entwicklungsphasen mit Komplexitätsebenen, wobei die komplexen Aspekte auf den höheren Ebenen und weniger komplexe Aspekte auf den niedrigeren Ebenen angesiedelt werden. Weitere Informationen: https://en.wikipedia.org/wiki/Dual_Vee_Model
[3] Der Begriff Meta Object Facility (MOF) beschreibt eine spezielle Metadaten-Architektur, mit einem Meta-Meta-Modell. Weitere Informationen finden Sie unter https://de.wikipedia.org/wiki/Meta_Object_Facility
[4] Die Idee der modellgetriebenen Architektur (MDA für model-driven architecture) bezeichnet einen modellgetriebenen Softwareentwicklungsansatz, der auf einer klaren Trennung von Funktionalität und Technik beruht. Die MDA unterteilt dabei das Gesamtmodell in mehrere Schichten: Computation Independent Model (CIM) für die umgangssprachliche Beschreibung, Platform Independent Model (PIM) als plattformunabhängiges Modell für Geschäftsprozesse, Platform Specific Model (PSM) als plattformabhängiges Modell für Architektur und Services sowie ein Codemodell für die Zielplattform. Weitere Informationen: https://de.wikipedia.org/wiki/Modellgetriebene_Architektur