Anforderungsanalyse mit der Use Case-Technik

Die Comelio GmbH setzt für die Durchführung von Anwendungsfallanalysen innerhalb der Modellierungs- und Planungsphase von Softwareprojekten die Use Case-Technik ein. Die erstellten Anwendungsfälle (Use Cases) lassen sich im Projektverlauf in vielfältiger Weise nutzen und bieten während des gesamten Projektzeitraums eine umfangreiche Materialsammlung für eine geordnete und anforderungszentrierte Projektarbeit. Die Technik ist rein textbasiert, lässt sich problemlos in das Projektmanagement mit dem V-Modell in seiner jeweils gültigen und aktuellen Fassung integrieren und untermauert die Use Case- und Verhaltensdiagramme der UML mit konkreten Beschreibungen und ausformulierten Transaktionsschritten. Die Use Case-Diagramme erhalten durch sie eine textuelle Basis, welche die Übersichtsdarstellung der UML nicht gewährleistet, während die verschiedenen genutzten Verhaltensdiagramme zwar für die grafische Übersicht von Prozessbeschreibungen nützlich sind, aber nur von UML-Kundigen verstanden werden. Die textbasierten Use Cases dagegen erlauben gerade die Interaktion mit Endanwendern und sonstigen Beteiligten sowie ihre Integration in die Analyse- und Designphase, weil hier kein spezielles Vorwissen für die Lektüre der Texte notwendig ist. Sofern die Anwendungsfälle direkt von den Beteiligten erstellt werden sollen, bieten sie dennoch die Möglichkeit, sich diese Technik mit einer relativ kurzen Einarbeitungszeit zu Eigen zu machen.

Geschichte und Ursprung

Das Konzept der Use Cases ist bereits sehr alt und stammt ursprünglich aus den späten 60er Jahren und wurde von Ivar Jacobson entwickelt. Erst Ende der 80er Jahre jedoch wurde die Methode als anerkannter Bestandteil in die Anforderungsanalyse für objektorientierte Softwaresysteme übernommen. Die gleichnamigen UML-Diagramme haben grundsätzlich keine Beziehung zu den rein textbasierten Use Cases. Zwar sind Parallelen wie eine Systemgrenze, der Anwender als Akteur oder auch die Möglichkeit, Use Cases zu erweitern und einzubinden, erkennbar, doch bleibt das UML-Diagramm lediglich grafisch und bietet daher ausschließlich eine Übersicht über die einzelnen identifizierten Use Cases einer Software. Durch zusätzliche Diagramme, wobei hier insbesondere die dynamischen zu erwähnen sind, lassen sich dann ähnliche Informationen abbilden wie sie in den textbasierten Use Cases vorhanden sind. Seit 1994 hat sich hauptsächlich Alistair Cockburn für die Verbreitung der Methode in Form von verschiedenen Schriften eingesetzt und gilt heute als führender Vertreter dieser Technik.

Definition und Abgrenzung

Der Begriff Use Case lässt sich am besten mit dem deutschen Begriff Anwendungsfall übersetzen. Es handelt sich um eine Vereinbarung zwischen den von einem System betroffenen Personen, wobei das sowohl die tatsächlichen Endanwender sein können, die eine besondere Rolle in der Methode spielen, als auch die Organisatoren und Verantwortlichen im Auftragsvergabeprozess oder im Führungsbereich des Softwareprojekts, also der allgemeinen Verwaltung. Ein solcher Use Case ist ein nach einem weitgehend festen Schema verfasster Text (Aufsatz), der durch seine Struktur und seine einfachen Aussagen dazu beiträgt, die Verhaltensweisen eines Softwaresystems unter verschiedenen Bedingungen und im Laufe einer Transaktion oder bei der Bearbeitung von Anfragen darzustellen. Darstellungen mit Hilfe von Diagrammen der UML oder über Petri-Netze und Flussdiagramme können ebenfalls die Transaktionsschritte abbilden, die in den Use Case-Aufsätzen zum Ausdruck kommen, bieten aber nicht immer die Zusatzinformation für Vor- und Nachbedingungen, Trigger oder einzuhaltende Garantien. Ein wesentliches Merkmal der Use Cases ist zudem ihre einfache Erstellungsweise ohne besondere Software und auch ohne eine umfassende Schulung der Autoren oder Leser. So ist es einfach möglich, jede betroffene Person in den Analyse- und Design-Prozess einzubinden und auch Verifizierungsaktivitäten direkt an die Betroffen abzugeben, um möglichst umfangreiche Informationen und Rückmeldungen zu erhalten.

Basismethodik

Ein Use-Case-Aufsatz zeichnet sich insbesondere durch seine klare und einfache Struktur aus, die zu einem leichten Verständnis und einfacher Auseinandersetzung mit den Systemanforderungen führen soll. Folgende Basisstruktur ist für einen Use Case in jedem Fall einzuhalten und erfordert eine schriftliche Fixierung.

Umfang

Der Umfang (engl. scope) bezeichnet das Ausmaß der Designtätigkeit, für das im Rahmen eines Projekts Verantwortung übernommen wird. Es lässt bewusst alle Designaspekte von bereits existierenden oder von anderen verantwortlichen Einheiten abhängigen Systemen außer Betracht. Dies ermöglicht eine genaue Fokussierung der tatsächlich notwendigen Designaufgaben und ihre Bezüge untereinander. Grundsätzlich ist es relativ einfach, den Umfang eines Systems festzumachen, doch gibt es gerade in der genauen Festlegung der Systemgrenzen im Rahmen von Schnittstellenbetrachtungen, Abhängigkeiten oder Integration / Verwendung von technischen Geräten sowie beliebigen anderen Systemen wie Server, Datenbanken und Dateisystemen Konkretisierungsbedarf.

Einige Varianten des Umfangs lassen sich hier unterscheiden:

Funktionaler Umfang

Dieser Umfang bezieht sich ausschließlich auf Dienste, welche vom zu erstellenden System angeboten und genutzt werden können. Es handelt sich dabei um Aktivitäten und einzelne Transaktionen, welche alleine oder durch Benutzerinteraktion /-kontrolle durchgeführt werden. Hierbei ist insbesondere die Liste der Akteure und ihre verschiedenen Ziele hilfreich, die unterschiedlichen funktionalen Anforderungen und damit auch als Gesamtbild den funktionalen Umfang zu entdecken und zu fixieren.

Design-Umfang

Dieser Umfang bezeichnet sich auf die räumliche und technische Ausdehnung des Systems. Er charakterisiert die zu erstellenden Software- und Hardwaresysteme, ermöglicht eine Erkenntnis über die Abhängigkeiten zwischen dem Softwaresystem und anderen Soft-/Hardware-Komponenten wie Datenbanksystemen, Servern beliebiger Art und sonstigen Peripheriegeräten. Dieser Umfang ist für jeden Use Case von Bedeutung, während der funktionale Umfang direkt durch die Akteure und ihre Ziele abgebildet wird. Die verschiedenen Use Cases können je nach Zielebene oder Platzierung innerhalb des Systems unterschiedlichen Design-Umfang erfordern. Insbesondere Use Cases, die sich an System-Schnittstellen wieder finden, sind hiervon regelmäßig betroffen.

 

Primärakteur und Stakeholder

Mit einem Stakeholder wird eine Person verstanden, der an einer Vereinbarung, die ein System zu erfüllen hat, Verantwortung und Anteil hat. Mit dem Begriff Akteur ist dagegen jemand gemeint, der nicht nur allgemein Verantwortung trägt, sondern das System verwendet, Transaktionen aufruft und die verschiedenen Anwenderziele erreichen will. Damit ist der Primärakteur eine Untermenge der Stakeholder. Er ist für die Systemerstellung von herausragender Bedeutung und übertrifft zumeist die restlichen Stakeholder, was sich allerdings im Rahmen der Vertragsstellung und organisatorischen Abwicklung umkehrt. Auch der Auslöser eines Use Cases ist in vielen Fällen dieser Primärakteur, weil sein Anwenderziel im Rahmen seiner Tätigkeit erreicht werden soll.

Neben dem Akteur-Begriff lässt sich auch noch der Begriff der Rolle verwenden. Wie auch bei Datenbanksystemen oder anderen Servern besteht die Möglichkeit, dass mehrere konkrete Individuen unterschiedlichen Rollen zugeordnet werden und auch mehrere Rollen nacheinander im Rahmen einer Verwendung des Systems eingenommen werden können. Die Rollen gruppieren die Benutzerarten und ihre Berechtigungen, mit dem System umzugehen. Sie bilden eine Zwischenschicht, die für die Planung von Sicherheitsaspekten und für den Aufbau der grafischen Benutzeroberfläche nützlich ist.

In besonderen Fällen kann es auch zu Benennung von Sekundärakteuren oder unterstützenden Akteuren kommen. Die beiden synonym zu verwendenden Begriffe charakterisieren Akteure, die in irgendeiner Weise Informationen übermitteln oder als externe Beteiligte auftreten.

Symbole für die Abbildung von Zielebenen und Design-Umfang in Use CasesSymbole für die Abbildung von Zielebenen und Design-Umfang in Use Cases

Zielebenen

Anwendungsfälle lassen sich durch ihre unterschiedlichen Zielebenen charakterisieren. Diese Einteilung erlaubt es, einem Use Case einen Detaillierungs- und Präzisionsgrad innerhalb des gesamten Systems zuzuordnen. Gleichzeitig haben die verschiedenen Ebenen eine organisatorische und strukturierende Wirkung auf das Datenmaterial, das für die Projektkoordination von Vorteil ist, indem zwischen sehr oberflächlichen, mehr zusammenfassenden Zielen und solchen unterschieden werden kann, die genau eine vollständige Transaktion erfordern. Eine zu detaillierte Darstellung der Ziele auf einer reinen Funktionsebene ist meistens nicht notwendig und in vielen Fällen eher hinderlich, da systemische (Sub-)Funktionen meistens ausdrücklich auf die Implementierung, die genaue Benutzerführung oder den Maskenaufbau verweisen, was im Rahmen der Design- und Analysephase zumeist nicht angestrebt wird.

Zielebenen bei Anwender Zielen von Use CasesZielebenen bei Anwender Zielen von Use Cases

Folgende Zielebenen lassen sich unterscheiden:

Anwenderziele

Die Anwenderziele stellen die wesentlichen Ziele innerhalb der gesamten Use Cases für ein System dar. Sie werden vom Primärakteur zur Erledigung seiner betrieblichen Aufgaben verfolgt und stellen in vielen Fällen eine vollständige Transaktion oder einen gesamten Arbeitsprozess dar. Sie bilden die fundamentalen Geschäftsprozesse ab und benötigen eine gewisse Zeit, die deutlich über das Nutzen einer einfachen Subfunktion hinausgeht. Das grafische Symbol ist eine Welle.

Überblicksziele

Auf der Überblicksebene befinden sich Ziele, deren Umsetzung mehr strategischer und zusammenfassender Natur ist. Sie umschließen gewöhnlich mehrere Anwenderziele und erlauben die Abbildung von einem Anwendungskontext und charakterisieren die Blöcke, aus denen ein System sich zusammensetzt. In zeitlicher Hinsicht dauert ihre Umsetzung wesentlich länger als die Anwenderziele. Die beiden grafischen Symbole sind die Wolke für sehr überblicksartige und zusammenfasse Ziele und der Drachen für die Abbildung von zusammenfassenden Anwenderzielen.

Subfunktionen

Die Ziele in der Unterwasserebene bilden die Subfunktionen oder sogar die einzelnen Operationen des Systems. Sie erlauben keinesfalls das Erreichen eines Anwenderziels und stellen auch keinen elementaren Geschäftsprozess dar, sondern werden bspw. von mehreren Anwenderzielen aufgerufen und eingeschlossen. Die beiden grafischen Symbole für die Subfunktionen sind der Fisch mit der Darstellung von Subfunktionen und die Muschel mit noch tiefer liegenden Operationen, deren Detaillierungsgrad für gewöhnlich zu groß ist, da sie schon direkt die Implementierung betreffen und nicht nur analytischer Natur sind.

 

Zielebenen bei Anwender Zielen von Use CasesZielebenen bei Anwender Zielen von Use Cases

Zusätzliche Use Case-Angaben

Neben den erwähnten grundlegenden Inhalten eines Use Case-Aufsatzes lassen sich weitere Angaben machen, deren Auftreten vom jeweiligen Use Case selbst abhängt. Sie lassen sich in wenigen Worten beschreiben.

Vorbedingung

Mit Vorbedingungen werden Bedingungen und Zustände angegeben, welche das System vor dem Aufruf eines Use Case und damit vor Beginn eines Prozesses bereit stellt und aufweist. Man kann sich darauf verlassen, dass sie erfüllt sind und die erwähnten Werte, Bedingungen oder Zustände tatsächlich zur Nutzung bereit stehen und vom Use Case in keiner Weise überprüft werden müssen.

Invarianten

Mindestgarantien, welche ein System erfüllen muss, wenn das Ziel des Primärakteurs nicht erfüllt werden kann, werden als Invarianten bezeichnet. Sie werden erfüllt, wenn das eigentliche Use Case-Ziel erfüllt wird, sind aber vor allen Dingen dann von Bedeutung, wenn das Hauptziel gerade nicht erreicht wird. Sie stellen im konkreten Anwendungszusammenhang in vielen Fällen Logging- und Protokoll-Informationen dar.

Nachbedingungen

Sobald ein Use Case zu einem erfolgreichen Ende gebracht wurde und damit das Hauptziel des Primärakteurs erreicht wurde, beschreiben die Nachbedingungen die Interessen der Stakeholder nach einem erfolgreichen Prozessverlauf. Sie ergänzen normalerweise die Invarianten um die für den Geschäftsbetrieb relevanten Bestätigungsinformationen zum erfolgreichen Verlauf eines Prozessen und den dazugehörigen Datensatz in der Datenbank.

Trigger

Löst ein spezifisches Ereignis einen Use Case aus, so lässt sich dies als Trigger bezeichnen. Entweder stellt der Trigger den ersten Schritt eines Use Case dar oder er liegt sogar noch vor diesem in zeitlicher Reihenfolge.

 

Nutzen von Use Cases

Auf der Ebene der Primärakteure ergeben sich unterschiedliche Vorteile durch den Einsatz der Use Case-Technik:

  • Man konzentriert sich auf die Personen, die direkt mit dem System arbeiten werden und kann damit aus den Erkenntnissen ihrer Ziele, Fähigkeiten und Hintergründe die Oberflächen, Fehlerbehandlungen und Benutzerführung erstellen.
  • Man erhält eine Strukturierung der Akteure und ihrer unterschiedlichen Ziele fest. Dies erleichtert die Erstellung von Benutzergruppen, die Planung von Sicherheitsebenen und Algorithmen zur Umsetzung der Sicherheitsstrategien. Zusätzlich lassen sich Softwareteile erkennen, indem sie einzelnen Zielbereichen oder Benutzergruppen zugeordnet werden.
  • Man kann Arbeitspakete aus zusammenhängenden oder in einem bestimmten Sinnzusammenhang auftretende Use Cases ableiten und für die Projektkoordination, die Aufgabenverteilung und auch die zeitliche Planung des Projekts nutzen.

Der vollständige Nutzen von Use Cases entfaltet sich nicht unmittelbar im Rahmen ihrer Erstellung, d.h. in der Design- und Analysephase, sondern erst zu einem großen Teil während des Projekts.

So lassen sich die Unit Tests für eine Verifizierung des Klassenaufbaus zwar grundlegend schon mit den Use Cases planen, doch die eigentliche Umsetzung, Erstellung und natürlich Ausführung der Testläufe gelingt erst nach Erstellung der zu testenden Einheiten. Hier können für die Gestaltung von Testdaten, Fehlerszenarien oder Übergabeparameter die fehlerhaften Eingabedaten erkannt werden, während für den Testabschluss sowohl der Erfolgsfall als auch über die Mindestgarantien der Misserfolgsfall und seine Enddaten getestet werden können.

Auch solche Ziele wie Organisation und Durchführung von Mitarbeiterschulungen oder Erstellung von gruppenbezogenen Handbüchern gelingt erst nach Fertigstellung und sogar erst nach Auslieferung der Software. Hierbei helfen allerdings die verschiedenen Use Cases ebenfalls, die man dann nach den verschiedenen Primärakteur-Gruppen und Rollen untersucht.

Weiterer Nutzen betrifft nicht wie in verschiedenen oben erwähnten Vorteilen die Datenstrukturen, die geschrieben oder übergeben werden, sondern den Masken-/GUI-Aufbau sowie die Erstellung von Transaktionen und Prozessen mit Hilfe von GUI-orientierter Benutzerführung und natürlich auch entsprechenden Softwaretechniken wie Datenbank-Transaktionen oder Thread-Programmierung.

Die Projekt steuernde Komponente von Use Cases entfaltet ihren Nutzen ebenfalls nicht nur zu Projektbeginn, wenn die Aufgaben verteilt werden, sondern ermöglicht auch eine Arbeitskontrolle und fortschreitende Arbeitsvergabe in Form von einzelnen Use Cases oder Use Case-Paketen entlang der gesamten Zeitschiene. Dies setzt eine objektorientierte Umsetzung der Use Case-Aufsätze in ein entsprechendes Klassendiagramm der UML bzw. überhaupt eine objektorientierte Kristallisation der Use Case-Inhalte voraus. Die Projektkoordination und auch das Projektcontrolling kann sich allerdings dennoch der Use Cases bedienen.

Der Hauptteil der Use Case-Erstellung sollte natürlich im Vorfeld der Programmierarbeiten fertig gestellt werden und nicht erst im Rahmen des Projekts erfolgen. In Ausnahmenfällen kann dies für Zusatzanforderungen oder vergessene Anforderungen auch während des Projektes geschehen. Dadurch ist zunächst im Rahmen der Design-Arbeiten eine große textuelle Datenmenge zu erstellen. Sie wird allerdings nicht nur als Vorarbeit für die Umsetzung in UML genutzt, sondern dient vielmehr während des Projektes als Datensteinbruch, der immer wieder durchgearbeitet und auf unterschiedliche Informationen hin gesiebt wird.

Vorteile von Use Cases im Nabe-Speiche-ModellVorteile von Use Cases im Nabe-Speiche-Modell

Umsetzung in Comelio-Projekten

Die Bedeutung von Use Cases wird von der Comelio GmbH als wesentlich für erfolgreiches Projektmanagement verstanden. Sie lassen sich teilweise in agil geführten Projekten durch intensive Kundeneinbeziehung vermeiden. Allerdings hat die Erfahrung gezeigt, dass echtes agiles Vorgehen von vielen Auftraggebern nicht tatsächlich gewollt ist, sondern mehr aus falsch verstandenem Kostenbewusstsein vorgeschlagen wird. Daher bietet die Comelio GmbH nicht nur als Dienstleistung die Erstellung von Anwendungsfallanalysen und entsprechenden Interviews und Texterfassung an, sondern steht auch bereit, um ihren Kunden die Technik in Form einer Schulung / Beratungsveranstaltung zu vermitteln. Dies senkt grundsätzlich die Kosten, da dann die eigenen Mitarbeiter in die Lage versetzt werden, die Anwendungsfälle zu notieren. Insbesondere hier ist die vorgeschlagene Methode hilfreich, weil sie kein besonderes Vorwissen erfordert und auch innerhalb eines Tages vermittelt werden kann und nach einigen Testläufen zu guten Ergebnissen führt.

Aus den erstellten Use Case-Aufsätzen können dann in einem iterativen Prozess Prototypen, GUI-Elemente und Masken sowie Transaktionen / Prozesse abgeleitet werden. Sie werden Teil des Projekthandbuchs und des Vertrages und ermöglichen beiden Seiten, einen hohen Grad an Klarheit und Verständnis zu erreichen, was der Umfang der Arbeitsaufgabe ist.