Startseite >> Wissen >> Techniken >> Use Cases - Guidelines zur Erstellung

Guidelines zur Erstellung von Use Cases

Ziel:

Die folgenden Richtlinien beschreiben ein Vorgehen und Regeln zur Erhebung und Spezifikation funktionaler Anforderungen in eingebetteten Systemen.

Beschreibung:

Grundlegende Konzepte

Use Cases

Use Cases (UC) sind eine bekannte und wichtige Technik zur Erhebung und Spezifikation funktionaler Anforderungen. Sie sind speziell geeignet, um das System aus der Perspektive des Benutzers zu verstehen. Dieses Verständnis ist unerlässlich, damit das System einmal in einem ganz bestimmten Kontext seinen Zweck erfüllt.

Damit ist eine UC-Spezifikation prinzipiell unterscheidbar von einer funktionalen Systemspezifikation: UCs beschreiben, wie ein System den Benutzer in seinen Aufgaben unterstützt, während die funktionale Systemspezifikation detailliert das Verhalten des Systems beschreibt.

Eingebettete Systeme

Eingebettete Systeme zeichnen sich im Vergleich zu Informationssystemen durch relativ einfache Interaktion mit dem Benutzer aus. Eine Benutzeraufgabe ist in diesem Bereich typischerweise eine bestimmte (Umgebungs-)Bedingung, die der Benutzer erreichen möchte. Im Allgemeinen wird das Systemverhalten dabei eher ausgelöst anstatt im engeren Sinne gesteuert. Besonderheiten in der Spezifikation des Systemverhaltens von eingebetteten Systemen wird in dieser Richtlinie Rechnung getragen, insbesondere durch die folgenden Konzepte:

  • Beschreibung der Input- und Output-Variablen
  • Unterstützende Aktoren
  • Systeminterne Aufgaben

Allgemeine Richtlinien für Textdokumente

Ergänzend zu den spezifischen Richtlinien für die schrittweise Erstellung von UCs sollten allgemeine Richtlinien für die Erstellung von (technischen) Textdokumenten beachtet werden. Die wichtigsten sind:

  • Verwendung einer passenden Terminologie mit klar definierten Begriffen und Abkürzungen.
  • Verwendung der Terminologie in konsistenter Weise, insbesondere sollten Homonyme und Synomyme vermieden werden.
  • Vermeidung unklarer Referenzen mit Pronomen („Der Mann mit dem Hut trat ein. Er war rund“ ).
  • Vermeidung von Negationen.
  • Vermeidung von Modalverben (muss, kann, soll, etc.), es sei denn, sie sind klar definiert.
  • Verwendung kurzer Sätze.

Vorgehen

Die Richtlinie besteht aus:

  1. Beschreibung einer systematischen Vorgehensweise
  2. Regeln und Anweisungen, die im Allgemeinen zu beachten sind
  3. Regeln, die speziell für UCs von eingebetteten Systemen gelten sollten

Erstellen einer Liste von Aktoren

In diesem Schritt werden zunächst alle relevanten Aktoren gesammelt. Dabei ist zu beachten, dass:

  • UC-Aktoren auf dem Abstraktionsgrad von Rollen sind
  • Aktoren sich durch ein „Interesse“ an der Systemreaktion auszeichnen

Erstellen einer Liste von Aufgaben und Visualisierung als UC-Diagramm

Aufgaben sind wesentlich durch die Ziele der Aktoren charakterisiert. Aufgaben sind ergebnisorientiert und unterscheiden sich dadurch von Funktionsbeschreibungen. Aufgaben werden zu Funktionsblöcken gruppiert.

Speziell für eingebettete Systeme ist zu beachten:

  • Aufgaben sind typischerweise eine (Umgebungs-)Bedingung, die der Benutzer erreichen will.
  • Aufgaben werden in benutzerbeeinflusste und systeminterne unterschieden.

Definition der Inputs und Outputs (monitorierte und kontrollierte Variablen) der Funktionsblöcke und Erstellung eines Kontextdiagramms

Die monitorierten und kontrollierten Variablen werden der Aufgabenbeschreibung entnommen. Sie werden zunächst in zwei getrennten Tabellen für monitorierte und kontrollierte Variablen für jeden Funktionsblock beschrieben (Name der Variable und textuelle Beschreibung).

Aus der tabellarischen Beschreibung kann zur besseren Visualisierung ein Kontextdiagramm erzeugt werden, das jedem Funktionsblock die Inputs und Outputs zuordnet.

Folgende Regeln und Hinweise sollten bei diesem Schritt beachtet werden:

  • Variablen, die sowohl monitoriert als auch kontrolliert werden, werden in beiden Tabellen geführt.
  • V erwendung komplexer Variablen. Eine Differenzierung in die detaillierte Systemreaktion sollte hier nicht vorgenommen werden.
  • Inputs durch Aktoren werden nach dem Schema <object> input bezeichnet.
  • Abstraktion von Inputs aufgrund technischer Probleme und Ausnahmebedingungen.
  • Inputs, die zusammen eine Aufgabe auslösen, werden nicht getrennt aufgeführt.
  • Abstraktion von Details der Benutzungsschnittstelle.

Verfeinerung der Aufgaben entsprechend der monitorierten und kontrollierten Variablen und Verfeinerung der UC- und Kontextdiagramme

In diesem Schritt werden die Aufgaben verfeinert, um Verhaltensvariationen darzustellen. Dies wird allgemein durch die Einführung von Sub-UCs und die Verwendung von Include- und Extents-Beziehungen zwischen UCs erzielt.

Das übergeordnete Kriterium, wie eine Verhaltensvariation zu beschreiben ist, ist die Verständlichkeit, wobei folgende Regeln angewendet werden sollten:

  • Wenn die Variation eine hohe Auftretenshäufigkeit hat und in deutlich anderem Systemverhalten endet, sollte der ursprüngliche UC durch mehrere UCs ersetzt werden, die je eine Variation ausdrücken.
  • Bei hoher Auftretenshäufigkeit und geringfügig anderem Systemverhalten sollten die Variationen durch neue UCs ausgedrückt werden. Diese verfeinerten UCs stellen die Variation dar und werden mit dem Haupt-UC durch Includes- oder Extends-Beziehungen verknüpft.
  • Bei geringer Auftretenshäufigkeit werden keine UCs hinzugefügt, sondern Ausnahmen (Exceptions) in der textuellen UC-Beschreibung (Schritt 5) eingefügt.

Die Verfeinerung der UCs macht im Allgemeinen eine Überarbeitung der Kontextdiagramme und der tabellarischen Darstellung der Variablen notwendig.

Ausfüllen des UC-Templates für jeden identifizierten UC

Für jeden identifizierten UC wird im letzten Schritt eine textuelle Beschreibung angelegt, die den UC vollständig beschreibt und einen leichten Zugriff auf bestimmte Aspekte des UCs ermöglicht. Für die Beschreibung sollte das folgende Template verwendet werden:

Use Case Bezeichnung der UCs
Aktoren Aktoren, mit denen der UC verknüpft ist
Ziel Ziel oder Endzustand, das/den die Aktoren mit dem UC verfolgen
Vorbedingungen Bedingungen, die vor der Ausführung der UCs erfüllt sein müssen
Interaktionsfolge Folge von einzelnen Interaktionsschritten zwischen System und Aktor, die zur Erreichung des Ziels (Aktor) notwendig sind
Ausnahmen Ereignisse oder Bedingungen, die zu einem Abbruch der normalen Interaktionsfolge führen
Regeln Detaillierung des Systemverhaltens bezüglich der genauen Regeln, denen das Systemverhalten in UC unterliegt
Qualitätsbeschränkungen Qualitätsanforderungen, die für diesen UC relevant sind

Monitorierte Variablen

Auflistung aller monitorierten Variablen, die in der Interaktionsfolge oder dem Kontextdiagramm dieses UCs aufgeführt sind
Kontrollierte Variablen Auflistung aller kontrollierten Variablen, die in der Interaktionsfolge oder dem Kontextdiagramm dieses UCs aufgeführt sind
Nachbedingungen Ergebnis der erfolgreichen Ausführung des UC gemäß der Interaktionsfolge


Diese Technik erfüllt folgende Praktiken:

Funktionale Anforderungen erheben
Standards und Dokumentenstruktur benutzen

Literaturverweis:

Guidelines - Creating Use Cases for Embedded Systems