"Zakres systemu to obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co leży poza projektem (np. jest zadaniem projektowym kogoś innego).\n",
"\n",
"Zakres <b> funkcjonalny </b>– zestaw usług oferowanych przez system.\n",
"\n",
"Zakres <b> projektowy </b>– zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.\n",
"</div>"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"# Jak zdefiniować zakres projektu?\n",
"\n",
"Zakres projektu jest stopniowo uściślany za pomocą następującyh działań:\n",
"\n",
"1. Określenie ogólnego zakresu projektu, a w nim:\n",
"\n",
" * Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu\n",
"<b> Wykonawca </b> to Uczestnik, który kontaktuje się z systemem.\n",
"\n",
"<b> Wykonawca główny </b> to Wykonawca, który kontaktuje się z systemem w celu uzyskania jednej z jego usług. Wykonawca główny najczęściej rozpoczyna przypadek użycia. \n",
"\n",
"<b> Wykonawca pomocniczy </b> to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).\n",
"Na podstawie charakterystyki wykonawców oraz zakresu systemu tworzy się listę **Wykonawca - Cel**, w której dla każdego typu wykonawców określa się cele, jakie wykonawca stawia przed systemem. \n",
"\n",
"Jeśli projektowany system dotyczy interesów uczestników niebędących wykonawcami, pożądane może być sporządzenie szerszej listy: **Uczestnik – Cel**. \n",
"Specyfikacja wymagań to dokument, w którym zebrano wszystkie oczekiwania stawiane przyszłemu systemowi (np. wymagania funkcjonalne i niefunkcjonalne aplikacji).\n",
" \n",
"</div>"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### Wymagania użytkownika\n",
"**Wymagania użytkownika** to ogólny opis oczekiwań względem systemu w języku naturalnym, będacy rezultatem wstępnych rozmów wykonawcy z zamawiającym lub użytkownikiem.\n",
"Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.\n",
"\n",
"<ul>\n",
"<li>Przypadek użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie wykonawcy głównego.\n",
" <li>Przypadek użycia reprezentowany jest przez sekwencję <b> akcji </b> realizowanych przez system, które dają zauważalny efekt; Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.</li>\n",
"</ul>\n",
"</div>"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"## Elementy składowe opisu przypadku użycia \n",
"1. Wykonawca główny (który rozpoczyna wykonanie przypadku użycia)\n",
"2. Poziom celu\n",
"3. Warunki początkowe\n",
"4. Wyzwalacz\n",
"5. Gwarancje minimalne\n",
"6. Gwarancja powodzenia\n",
"7. Scenariusz powodzenia\n",
"8. Rozszerzenia scenariusza"
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### 3.1. Przypadek użycia. Poziom celu\n",
"Poziom celu określa stopień ogólności przypadku użycia:\n",
" * Poziom streszczenia – najbardziej ogólny,\n",
" * Poziom użytkownika – pośredni,\n",
" * Poziom podfunkcji – najbardziej szczegółowy.\n",
" \n",
"#### Poziom streszczenia\n",
"Przypadki użycia o poziomie streszczenia pokazują kontekst, w którym występują przypadki użycia niższego poziomu:\n",
" * Pokazują kolejność działania przypadków użycia niższego poziomu,\n",
" * Stanowią spis treści przypadków użycia niższego poziomu (użytkownika).\n",
" \n",
"Przykład przypadku użycia o poziomie streszczenia (podkreśleniem oznaczone są przypadki niższego poziomu):\n",
"\n",
"<img src=\"obrazy/poziom streszczenia.png\" alt=\"Przykład przypadku użycia o poziomie streszczenia\" width=400px>\n",
"\n",
"#### Poziom użytkownika\n",
"Przypadki użycia o poziomie użytkownika opisują cel, który chce osiągnąć wykonawca główny, żeby wykonać swoje zadanie. \n",
" * Najczęściej spełniają warunek: „jedna osoba i jedno krótkie posiedzenie”.\n",
" * Przypadki te są najbardziej warte opisania w specyfikacji.\n",
" \n",
"Przykład przypadku użycia o poziomie użytkownika:\n",
"\n",
"<img src=\"obrazy/poziom użytkownika.png\" alt=\"Przykład przypadku użycia o poziomie użytkownika\" width=400px>\n",
"\n",
"#### Poziom podfunkcji\n",
"Przypadki użycia o poziomie podfunkcji opisują podcele, które są potrzebne do osiągnięcia celów użytkownika.\n",
" * Uwzględniane są w opisie przypadków tylko w sytuacjach absolutnie niezbędnych („nie musisz – nie pisz”).\n",
" * Trzy przykłady przypadków użycia o poziomie podfunkcji:\n",
" > Wybierz odpowiedź na pytanie testowe. \n",
" > Przejdź do następnego pytania. \n",
" > Zaloguj się w systemie. "
]
},
{
"cell_type": "markdown",
"metadata": {},
"source": [
"### 3.2. Przypadek użycia. Warunki początkowe\n",
"**Warumek początkowy** to proste stwierdzenie o stanie świata w chwili otwarcia przypadku użycia. \n",
" * Warunek początkowy może być wyrażony za pomocą przypadków użycia, które musiały zajść przed otwarciem opisywanego przypadku. \n",
" * Warunek początkowy określa, co musi być zapewnione przed zezwoleniem na przypadek użycia. \n",
" \n",
" Przykład warunku początkowego (system do testów):\n",
"**Gwarancje minimalne** to najmniejsze obietnice składane przez system.\n",
" * Są realizowane zarówno wtedy, gdy cel wykonawcy głównego jest spełniony (scenariusz powodzenia) i gdy nie jest on spełniony. (Szczególnie w tym drugim przypadku minimalne gwarancje są istotne).\n",
" * Zapisywane są w postaci kilku stwierdzeń, które będą na pewno prawdziwe po zakończeniu przypadku użycia.\n",
