<Nazwa Projektu>

Specyfikacja przypadku użycia: <Nazwa przypadku użycia>

Wersja <1.0>

[Komentarz: Ten szablon dokumentu przeznaczony jest do wykorzystania z metodyką Rational Unified Process. Tekst zawarty w nawiasach kwadratowych i wyświetlony w kolorze niebieskim italic (styl = InfoBlue) jest przewodnikiem dla autorów i powinien być usunięty przed publikacją dokumentu. Paragrafy wprowadzane po tym stylu będą automatycznie formatowane jako normalne (styl = Tekst Podstawowy).]

[Aby zmodyfikować pola automatyczne w Microsoft Word (które są wyświetlane na szarym tle po ich wskazaniu), wybierz Plik>Właściwości i zmień pola Tytuł, Temat i Firma na wartość właściwą dla tego dokumentu. Po zamknięciu okna dialogowego, pola automatyczne będą zaktualizowane przez wybranie Edycja>Zaznacz wszystko (lub Ctrl-A) i naciśnięcie F9, przez wskazanie pola i naciśnięcie F9.Operacja ta musi być wykonana oddzielnie dla Główek i Stopek. Alt-F9 przełącza między wyświetlaniem nazw pól automatycznych i ich aktualną wartością. Szczegółowe informacje o polach automatycznych zawarte są w pomocy dla programu Word.]

Historia Dokumentu

Data	Wersja	Opis	Autor
<dd.mm.rr>	<x.x>	<szczegóły>	<nazwisko>

Spis Treści

1. Krótki opis

Specyfikacja przypadku użycia: <Nazwa przypadku użycia>

[Ten szablon przeznaczony jest do specyfikacji przypadków użycia (Ang.: Use-Case; wymaganie funkcjonalne obserwowane z otoczenia systemu informatycznego) w zakresie opisu cech wymagania. Ten dokument wykorzystywany jest w narzędziach do zarządzania wymaganiami, takich jak Rational RequisitePro, do specyfikowania i klasyfikowania wymagań we właściwościach przypadków użycia.

Diagramy przypadków użycia mogą być budowane w narzędziach do graficznego modelowania oprogramowania, takich jak Rational Rose. Raport przypadków użycia wraz ze wszystkimi cechami wymagań może być generowany z wykorzystaniem Rational SoDA. Więcej informacji zawartych jest w dziale tool mentors w dokumentacji Rational Unified Process.]

1. Krótki opis

[Opis przekazuje w sposób zwarty rolę oraz cel przypadku użycia. Pojedynczy akapit powinien być wystarczający dla tego opisu.]

2. Aktorzy

[Opis ról użytkowników systemu inicjujących i/lub korzystających z wyników realizacji przypadku użycia]

3. Podstawowy przepływ zdarzeń

[Przypadek użycia jest aktywowany, gdy aktor coś zrobi. Aktor zawsze inicjuje przypadek użycia. Przypadek użycia opisuje co aktor robi i co robi system informatyczny w odpowiedzi na to. Jest to wyrażone w formie dialogu aktora z systemem.

Przypadek użycia opisuje co dzieje się w systemie, natomiast nie opisuje jak to się dzieje lub dlaczego. Jeżeli wymieniana jest informacja, należy wyspecyfikować, co jest przekazywane w obie strony. Na przykład nie jest jasne stwierdzenie, że aktor wprowadza dane o kliencie, jeżeli nie są one zdefiniowane. Lepiej jest powiedzieć, że aktor wprowadza nazwisko i adres klienta. Słownik terminów (lub bardziej formalnie model domenowy) jest niezbędny do całościowego zarządzania przypadkami użycia. Umożliwia on zdefiniowanie takich haseł jak informacje o kliencie, które pozwalają uczynić specyfikację przypadku użycia bardziej szczegółową i precyzyjną.

Proste alternatywy mogą być przedstawione bezpośrednio w tekście opisującym przepływ. Jeżeli do opisania co dzieje się, w przypadku wystąpienia alternatywy, wystarczające jest kilka zdań, należy to zrobić bezpośrednio w opisie tego przepływu. Jeżeli przepływ alternatywny jest bardziej skomplikowany, należy użyć oddzielnego punktu do jego opisania. Na przykład punkt Przepływy alternatywne przedstawia jak opisywać bardziej skomplikowane alternatywy.

Skomplikowane przepływy zdarzeń powinny być opisane jako podprzepływy. Głównym celem takiego przedstawienia przepływu jest zwiększenie jego czytelności. Podprzepływy mogą być wywoływane wielokrotnie z różnych miejsc. Należy pamiętać, że przypadki użycia mogą wykorzystywać podprzepływy w różnej kolejności, w sekcjach opcjonalnych, pętlach, a nawet wielokrotnie w tym samym czasie.

Należy pamiętać, że rysunek jest częsta znacznie bardziej komunikatywny niż opis słowny, chociaż nie zawsze jest w stanie przedstawić wszystko. Jeżeli zwiększy to zrozumienie, należy umieścić diagramy przepływów, aktywności lub dowolne inne rysunki. Jeżeli diagram przepływów jest przydatny do przedstawienia skomplikowanego procesu decyzyjnego, to oczywiście należy go użyć. Podobnie dla zachowania obiektu zależnego od jego stanu, diagram stanów jest czytelniejszy niż wielostronicowy opis. Należy wykorzystywać właściwe dla problemu formy prezentacji, ale należy się wystrzegać terminologii, notacji lub ilustracji, które mogą być niezrozumiałe dla czytelników dokumentu. Należy pamiętać, że celem jest wyjaśnienie, a nie zaciemnienie zagadnienia.]

4. Przepływy alternatywne

[Bardziej skomplikowane alternatywy są opisywane w oddzielnych punktach, do których odnosi się opis przepływu podstawowego. Rozumienie przepływu alternatywnego jest analogiczne do rozumienia alternatywnego zachowania się systemu - każdy alternatywny przepływ reprezentuje alternatywne zachowanie się systemu występujące zazwyczaj z powodu sytuacji wyjątkowych w głównym przepływie. Punkt może być taki długi, jak jest to potrzebne do opisania wszystkich sytuacji wyjątkowych skojarzonych z alternatywnym zachowaniem się systemu.

Należy rozpocząć każdy alternatywny przepływ linią inicjującą wskazującą, gdzie się on rozpoczyna i przy zajściu jakich warunków on występuje.

Każdy przepływ alternatywny musi kończyć się linią, która wyraźnie określa stan systemu po zakończeniu przepływu alternatywnego oraz miejsce gdzie przepływ podstawowy jest wznawiany. Musi to być jawnie wyjaśnione.

Wykorzystanie przepływów alternatywnych zwiększa czytelność przypadku użycia. Należy pamiętać, że przypadki użycia są tylko tekstowym opisem, a ich głównym celem jest udokumentowanie zachowania się systemu informatycznego w sposób jednoznaczny, zwięzły i zrozumiały.]

1. <Obszar funkcjonalności>

[Często wiele przepływów alternatywnych skojarzonych jest z tym samym obszarem funkcjonalności (na przykład specjalne funkcje bankomatu, takie jak: obsługa kart kredytowych, pokwitowań). Umieszczenie koncepcyjnie związanych podprzepływów, w jednym dobrze nazwanym punkcie, zwiększa czytelność opisu.]

1. < Pierwszy przepływ alternatywny >

[Opis przepływu alternatywnego analogiczny do opisu każdego innego przepływu zdarzeń.]

1. < Podprzepływ alternatywny >

[Przepływ alternatywny Mozę również być podzielony na podprzepływy opisane w podpunktach. Podprzepływy opisane w tych podpunktach mogą być wykorzystane tylko w jednym przepływie alternatywnym.]

2. < Drugi przepływ alternatywny >

[Zazwyczaj jest wiele przepływów alternatywnych w ramach jednego obszaru funkcjonalności. Należy opisywać je w oddzielnych punktach w celu zwiększenia czytelności dokumentu.]

2. <Inny obszar funkcjonalności>

[Zazwyczaj jest wiele obszarów funkcjonalności wiążących w grupy przepływy alternatywne. Należy opisywać je w oddzielnych punktach dla zwiększenia czytelności dokumentu.]

1. < Inny przepływ alternatywny >

5. Podprzepływy

1. < Pierwszy podprzepływ >

[Podprzepływ powinien być segmentem zachowania się systemu informatycznego w zakresie przypadku użycia, który posiada jasny cel i jest „atomowy”, co oznacza że wykonywane są albo wszystkie albo żadna akcja opisująca ten podprzepływ. Może występować wiele poziomów podprzepływów, ale jeżeli jest to możliwe należy tego unikać, gdyż czyni to tekst bardziej skomplikowanym i trudniejszym do zrozumienia.]

2. < Drugi podprzepływ >

[Zazwyczaj jest wiele podprzepływów w ramach przypadku użycia. Należy opisywać każdy w oddzielnym punkcie dla zwiększenia czytelności dokumentu. Wykorzystanie podprzepłów zwiększa czytelność specyfikacji przypadku użycia, jak również chroni przed dekompozycją do hierarchii przypadków użycia. Należy pamiętać, że przypadki użycia są tylko tekstowym opisem, a ich głównym celem jest udokumentowanie zachowania się systemu informatycznego w sposób jednoznaczny, zwięzły i zrozumiały.]

6. Kluczowe scenariusze

[Zestawienie najważniejszych scenariuszy wykorzystania systemu zgodnie z przypadkiem użycia. Należy podać krótką nazwę opis dla jednoznacznego zidentyfikowania każdego kluczowego scenariusza. Potencjalnie możliwych jest wiele scenariuszy z tym przypadkiem użycia. Jest ważne dla skupienia się na najważniejszych lub najczęściej dyskutowanych scenariuszach, które są zarówno przykładami wykorzystania przypadków użycia, jak i oznaką szczególnej ważności lub zainteresowania przez udziałowców.]

7. Warunki wstępne

[Warunek wstępny przypadku użycia jest stanem systemu informatycznego, w jakim musi się on znajdować, aby przypadek użycia mógł być wykonany.]

1. < Pierwszy warunek wejściowy >

8. Warunki końcowe

[Warunek końcowy przypadku użycia jest listą możliwych stanów systemu informatycznego natychmiast po zakończeniu wykonania przypadku użycia.]

1. < Pierwszy warunek końcowy >

9. Punkty rozszerzeń

[Punkty rozszerzeń przypadku użycia.]

1. <Nazwa punktu rozszerzeń>

[Lokalizacja punktu rozszerzenia w przepływie zdarzeń.]

10. Specjalne wymagania

[Wymagania specjalne są zazwyczaj niefunkcjonalnymi wymaganiami dla przypadku użycia, których nie można w łatwy i naturalny sposób wyspecyfikować w tekście opisującym przepływy zdarzeń. Specjalne wymagania mogą zawierać uwarunkowania prawne, normatywne, standardy aplikacyjne, jakościowe takie jak użyteczność, niezawodność, wydajność, pielęgnowalność. Ponadto w tym punkcie powinny być zebrane wymagania takie jak: system operacyjny i środowisko, kompatybilność, ograniczenia projektowe.]

1. < Pierwsze specjalne wymaganie >

11. Dodatkowe informacje

[Punkt powinien zawierać lub odwoływać się do wszystkich informacji, które są wymagane do wyjaśnienia przypadków użycia. Mogą to być diagramy, przykłady lub cokolwiek innego, co może być przydatne.]

Warszawa, dn. ..... r.

<Nazwa Firmy>

1/2

<Nazwa Projektu>	Wersja: <1.0>
Specyfikacja przypadku użycia: <Nazwa przypadku użycia>	Data: <dd.mm.rr>
<identyfikator dokumentu>

6/6

---