<Projektname>
Anwendungsfallspezifikation: <Anwendungsfallname>
Version <1.0>
[Anmerkung: Die folgende Vorlage ist für den Rational Unified Process bestimmt. Blau und kursiv dargestellte Texte (style=InfoBlue) in eckigen Klammern sind Anleitungen für den Autor und sollten vor der Veröffentlichung des Dokuments gelöscht werden. Ein auf diesen Stil folgender Absatz wird automatisch auf den normalen Stil (style=Body Text) gesetzt.]
Revisionsprotokoll
Datum |
Version |
Beschreibung |
Autor |
<dd/mmm/jj> |
<x.x> |
<Details> |
<Name> |
|
|
|
|
|
|
|
|
|
|
|
|
Inhaltsverzeichnis
2.2.1 < Erster alternativer Ablauf >
2.2.2 < Zweiter alternativer Ablauf >
3.1 < Erste spezielle Anforderung >
6.1 <Name des Erweiterungspunkts>
Anwendungsfallspezifikation:
<Anwendungsfallname>
[Die folgende Vorlage wird für eine Anwendungsfallspezifikation bereitgestellt, die die Eigenschaften des Anwendungsfalls beschreibt. Verwenden Sie dieses Dokument mit einem Tool für Anforderungsmanagement wie Rational RequisitePro, um die Anforderungen in den Eigenschaften des Anwendungsfalls angeben und markieren zu können.
Die Anwendungsfalldiagramme können mit einem Tool für visuelle Modellierung wie Rational Rose entwickelt werden. Mit Rational SoDA kann ein Anwendungsfallbericht (mit allen Eigenschaften) generiert werden. Weitere Informationen hierzu finden Sie in den Toolmentoren in Rational Unified Process.]
[Die Beschreibung vermittelt in knappen Worten den Zweck des Anwendungsfalls. Ein Absatz reicht für diese Beschreibung aus.]
[Dieser Anwendungsfall beginnt, wenn der Akteur etwas tut. Anwendungsfälle werden immer von einem Akteur eingeleitet. Der Anwendungsfall beschreibt, was der Akteur tut und wie das System darauf reagiert. Die Beschreibung muss sich wie ein Dialog zwischen Akteur und System lesen.
Der Anwendungsfall beschreibt, was im System passiert, aber nicht wie und nicht warum. Wenn Informationen ausgetauscht werden, müssen Sie genau beschreiben, was übergeben wird. Es ist beispielsweise nicht sehr aufschlussreich zu sagen, dass der Akteur Kundendaten eingibt. Sagen Sie besser, dass der Akteur den Namen und die Adresse des Kunden eingibt. Ein Glossar ist häufig hilfreich, um die Komplexität des Anwendungsfalls verwaltbar zu halten. Dort können Sie Dinge wie die Kundeninformationen definieren, damit der Anwendungsfall nicht mit Details überladen wird.
Einfache Alternativen können im Text des Anwendungsfalls dargelegt werden. Wenn es nur ein paar Sätze erfordert, um zu beschreiben, was passiert, wenn es eine Alternative gibt, dokumentieren Sie dies direkt im Abschnitt Ereignisablauf. Wenn der alternative Ablauf komplexer ist, verwenden Sie einen separaten Abschnitt und beschreiben Sie ihn dort. Ein Unterabschnitt Alternativer Ablauf beschreibt beispielsweise, wie komplexere Alternativen beschrieben werden.
Ein Bild sagt manchmal mehr als tausend Worte, obwohl es keinen Ersatz für reine, klare Prosa gibt. Wenn es zur Transparenz beiträgt, steht es Ihnen frei, grafische Darstellungen von Benutzerschnittstellen, Prozessabläufen oder andere Abbildungen in den Anwendungsfall einfügen. Wenn ein Flussdiagramm hilfreich ist, um einen komplexen Entscheidungsprozess darzustellen, sollten Sie es unbedingt verwenden! Bei zustandsabhängigem Verhalten kann ein Zustandsübergangsdiagramm das Verhalten eines Systems häufig besser veranschaulichen als Seiten über Seiten von Text. Verwenden Sie das richtige Darstellungsmedium für Ihr Problem, aber achten Sie darauf, keine Terminologie, Notationen oder Abbildungen zu verwenden, die die Zielgruppe nicht versteht. Denken Sie daran, dass Ihr Ziel ist, Transparenz zu schaffen.]
[Komplexere Alternativen werden in einem separaten Abschnitt beschrieben, auf die der Unterabschnitt Basisablauf des Abschnitts Ereignisablauf dann verweist. Stellen Sie sich die Unterabschnitte Alternativer Ablauf wie alternatives Verhalten vor. Jeder alternative Ablauf stellt alternatives Verhalten dar, das sich gewöhnlich aus Ausnahmen ergibt, die im Hauptablauf auftreten. Sie können so lang wie nötig sein, um die Ereignisse zu beschreiben, die dem alternativen Verhalten zugeordnet sind. Wenn ein alternativer Ablauf endet, werden die Ereignisse des Hauptereignisablaufs fortgeführt.]
[Alternative Abläufe können weiter in Teilabschnitte gegliedert werden, sofern sie dadurch klarer verdeutlicht werden können.]
[In jedem Anwendungsfall kann und wird es wahrscheinlich auch eine Reihe alternativer Abläufe geben. Beschreiben Sie jeden alternativen Ablauf separate, um die Verständlichkeit zu gewährleisten. Durch die Verwendung alternativer Abläufe verbessert sich die Lesbarkeit des Anwendungsfalls. Alternative Abläufe verhindern außerdem, dass Anwendungsfälle in Hierarchien von Anwendungsfällen zerlegt werden. Vergessen Sie nicht, dass Anwendungsfälle nur Beschreibungen sind. Ihr Hauptzweck ist es, das Verhalten des Systems in einer deutlichen, prägnanten und verständlichen Form zu dokumentieren.]
[Eine spezielle Anforderung ist normalerweise eine nicht funktionale Anforderung, die für einen bestimmten Anwendungsfall gilt, sich jedoch nicht ohne großen Aufwand in den Text für den Ereignisablauf des Anwendungsfalls integrieren lässt. Beispiele für spezielle Anforderungen sind gesetzliche Vorschriften und Ausführungsbestimmungen, Anwendungsstandards und Qualitätsattribute des zu erstellenden Systems, einschließlich Anforderungen an die Benutzerfreundlichkeit, Zuverlässigkeit, Leistung und Servicefreundlichkeit. Zusätzlich sollten in diesen Abschnitt weitere Anforderungen aufgenommen werden.Dazu gehören Betriebssysteme und Umgebungen, Kompatibilitätsanforderungen und Designeinschränkungen.]
[Eine Vorbedingung für einen Anwendungsfall ist der Status, den das System vor Ausführung eines Anwendungsfalls haben muss.]
[Eine Nachbedingung für einen Anwendungsfall ist eine Liste möglicher Status, die das System unmittelbar nach Beendigung des Anwendungsfalls haben kann.]
[Erweiterungspunkte des Anwendungsfalls]
[Definition der Position des Erweiterungspunktes im Ablauf der Ereignisse]