18 KiB
Przygotowanie do projektu badawczo-rozwojowego
7. Specyfikacja projektu informatycznego[wykład]
Krzysztof Jassem (2021)
Zakres systemu informatycznego
Zakres systemu to obszar tego, co projektujemy – precyzyjnie odgraniczony od tego, co leży poza projektem (np. jest zadaniem projektowym kogoś innego).Zakres funkcjonalny – zestaw usług oferowanych przez system.
Zakres projektowy – zasięg przestrzenny systemu – obejmuje zbiór sprzętu i oprogramowania, które zlecono nam wykonać.
Jak zdefiniować zakres projektu?
Zakres projektu jest stopniowo uściślany za pomocą następującyh działań:
- Określenie ogólnego zakresu projektu, a w nim:
- Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu
- Charakterystyka wykonawców
- Lista „wykonawca-cel”
- Lista „in-out”
- Specyfikacja wymagań
- Wymagania funkcjonalne
- Wymaganie niefunkcjonalne
- Opis przypadków użycia
1. Określenie ogólnego zakresu projektu
Uczestnicy i wykonawcy
Uczestnik
Uczestnik – ktoś lub coś, mający interes związany z zachowaniem systemu.Uczestnik może być osobą, firmą lub przedsiębiorstwem, programem komputerowym lub systemem komputerowym.
Wykonawca
Wykonawca to Uczestnik, który kontaktuje się z systemem.Wykonawca główny 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.
Wykonawca pomocniczy to Wykonawca z zewnątrz wykonujący usługi dla systemu (drukarka, usługa WWW, osoby, które mają dostarczyć pewne badania).
Charakterystyka wykonawców
Charakterystykę wykonawców można opisać za pomocą tabeli.
Przykład tabeli dla systemu Cybertest2:
![Lista Wykonawców](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/wykonawcy.png)
Lista Wykonawca-Cel
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.
Jeśli projektowany system dotyczy interesów uczestników niebędących wykonawcami, pożądane może być sporządzenie szerszej listy: Uczestnik – Cel.
Przykład tabeli dla systemu Cybertest2:
![Lista wykonawca-cel](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/wykonawca-cel.png)
Lista In-Out
Na podstawie listy Wykonawca-Cel, biorąc pod uwagę priorytety celów, tworzy się listę In-Out, która precyzyjnie określa zakres systemu.
2. Specyfikacja wymagań
Specyfikacja wymagań
Specyfikacja wymagań to dokument, w którym zebrano wszystkie oczekiwania stawiane przyszłemu systemowi (np. wymagania funkcjonalne i niefunkcjonalne aplikacji).Wymagania użytkownika
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.
Skierowane są do:
- menedżerów zamwiającego.
- menedżerów wykonawcy,
- potencjalnych użytkowników systemu.
Przykład wymagań użytkownika (system wspomagania tłumaczenia):
![Przykład wymagań użytkownika](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/wymagania%20u%C5%BCytkownika.png)
Wymaganie systemowe
Wymagania systemowe to sformalizowany opis oczekiwań względem systemu.
Skierowane są do:
- inżynierów zamawiającego,
- twórców oprogramowania,
- architektów systemu.
Wymagania systemowe dzielą się na:
funkcjonalne,
niefunkcjonalne
Wymagania funkcjonalne
Opisują funkcje (czynności, operacje) wykonywane przez system.
Dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem.
Przykłady wymagań funkcjonalnych (system do prowadzenia testów na wykładzie):
![Przykład wymagania funkcjonalnego](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/wymaganie%20funkcjonalne1.png)
![Przykład wymagania funkcjonalnego](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/wymaganie%20funkcjonalne2.png)
Wymagania niefunkcjonalne
- Opisują warunki, przy których system musi realizować swoje funkcje:
- Wymagania dotyczące produktu
- Wymagania dotyczące procesu
- Wymagania zewnętrzne
- Wymagania niefunkcjonalne powinny być weryfikowalne. Realizowane jest to przy pomocy systemu miar opisujących wymagane cechy systemu.
Przykłady miar wymagań niefunkcjonalnych:
![Przykłady miar wymagań niefunkcjonalnych](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/miary.png)
Przykład wymagań niefunkcjonalnych (system wspomagania tłumaczenia):
![Przykład wymagań niefunkcjonalnych](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/wymagania%20niefunkcjonalne.png)
3. Opis przypadków użycia
Przypadek użycia (PU)
Przypadek użycia określa umowę między uczestnikami systemu względem jego zachowania.- Przypadek użycia opisuje zachowanie się systemu w różnych warunkach – w odpowiedzi na żądanie wykonawcy głównego.
- Przypadek użycia reprezentowany jest przez sekwencję akcji realizowanych przez system, które dają zauważalny efekt; Akcja to operacja atomowa, czyli taka, której nie można przerwać podczas wykonywania.
Elementy składowe opisu przypadku użycia
- Wykonawca główny (który rozpoczyna wykonanie przypadku użycia)
- Poziom celu
- Warunki początkowe
- Wyzwalacz
- Gwarancje minimalne
- Gwarancja powodzenia
- Scenariusz powodzenia
- Rozszerzenia scenariusza
3.1. Przypadek użycia. Poziom celu
Poziom celu określa stopień ogólności przypadku użycia:
Poziom streszczenia – najbardziej ogólny,
Poziom użytkownika – pośredni,
Poziom podfunkcji – najbardziej szczegółowy.
Poziom streszczenia
Przypadki użycia o poziomie streszczenia pokazują kontekst, w którym występują przypadki użycia niższego poziomu:
Pokazują kolejność działania przypadków użycia niższego poziomu,
Stanowią spis treści przypadków użycia niższego poziomu (użytkownika).
Przykład przypadku użycia o poziomie streszczenia (podkreśleniem oznaczone są przypadki niższego poziomu):
![Przykład przypadku użycia o poziomie streszczenia](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/poziom%20streszczenia.png)
Poziom użytkownika
Przypadki użycia o poziomie użytkownika opisują cel, który chce osiągnąć wykonawca główny, żeby wykonać swoje zadanie.
Najczęściej spełniają warunek: „jedna osoba i jedno krótkie posiedzenie”.
Przypadki te są najbardziej warte opisania w specyfikacji.
Przykład przypadku użycia o poziomie użytkownika:
![Przykład przypadku użycia o poziomie użytkownika](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/poziom%20u%C5%BCytkownika.png)
Poziom podfunkcji
Przypadki użycia o poziomie podfunkcji opisują podcele, które są potrzebne do osiągnięcia celów użytkownika.
- Uwzględniane są w opisie przypadków tylko w sytuacjach absolutnie niezbędnych („nie musisz – nie pisz”).
- Trzy przykłady przypadków użycia o poziomie podfunkcji:
Wybierz odpowiedź na pytanie testowe.
Przejdź do następnego pytania.
Zaloguj się w systemie.
3.2. Przypadek użycia. Warunki początkowe
Warumek początkowy to proste stwierdzenie o stanie świata w chwili otwarcia przypadku użycia.
Warunek początkowy może być wyrażony za pomocą przypadków użycia, które musiały zajść przed otwarciem opisywanego przypadku.
Warunek początkowy określa, co musi być zapewnione przed zezwoleniem na przypadek użycia.
Przykład warunku początkowego (system do testów):
![Przykład warunku początkowego](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/warunek%20pocz%C4%85tkowy.png)
3.3. Przypadek użycia. Wyzwalacz
Wyzwalacz to zdarzenie, które automatycznie powoduje rozpoczęcie przypadku użycia.
Przykłady wyzwalaczy (system do testów):
![Przykłady wyzwalaczy](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/wyzwalacze.png)
3.4. Przypadek użycia. Gwarancje minimalne
Gwarancje minimalne to najmniejsze obietnice składane przez system.
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).
Zapisywane są w postaci kilku stwierdzeń, które będą na pewno prawdziwe po zakończeniu przypadku użycia.
Przykłady gwarancji minimalnych:
3.5. Przypadek użycia. Gwarancja powodzenia
Gwarancja powodzenia ustala, jakie interesy uczestników są zaspokojone po udanym zakończeniu przypadku użycia (scenariusz powodzenia).
3.6. Przypadek użycia. Scenariusz powodzenia
Scenariusz powodzenia to ciąg akcji od rozpoczęcia do zakończenia przypadku użycia, który realizuje gwarancje powodzenia. Scenariusz powodzenia opisuje najbardziej typowe zachowanie systemu i nie bierze pod uwagę zdarzeń niesprzyjających.
Wskazówki przy pisaniu scenariusza powodzenia:
1. Używaj prostych składni zdań
![Przykład prostej składni](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/prosta%20sk%C5%82adnia.png)
2. Jasno i jednoznacznie wskaż podmiot czynności
![Przykład podmiotu czynności](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/podmiot.png)
3. Pisz "z lotu ptaka"
![Przykład z lotu ptaka](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/lot%20ptaka.png)
4. Przesuwaj proces wyraźnie do przodu
![Przykład przesuwania procesu](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/proces.png)
5. Stwierdzaj "że", a nie - sprawdzaj "czy"
![Przykład stwierdzania że](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/%C5%BCe.png)
6. Wyraźnie oznaczaj przypadki użycia, do których się odwołujesz
![Przykłady odwołania](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/odwo%C5%82ania.png)
7. Stosuj iteracje, jeśli jest taka potrzeba
![Przykłady iteracji](/rjawor/aitech-pbr-rjawor/media/commit/594a088ad8f20c2f4f58b1e93ff807611ccc9e99/materia%C5%82y%20na%20PPB%20%28wyk%C5%82ad%29/obrazy/iteracje.png)
3.7. Przypadek użycia. Rozszerzenia scenariusza
Rozszerzenie scenariusza to niestandardowe zachowanie systemu, które
zaczyna się w konkretnym kroku w scenariuszu powodzenia,
gdy zdarzają się niestandardowe sytuacje – zwane warunkami rozszerzenia scenariusza.
Warunki rozszerzenia scenariusza
_Warunki rozszerzenie scenariusza* to sytuacje, w których system zachowuje się inaczej, niż to przewidziano w scenariuszu powodzenia.
Warunki rozszerzenia sformułowane są z punktu widzenia systemu (co system może wykryć, a nie - co się stało).
Jak znajdować potencjalne rozszerzenia scenariusza?
- Przemyśl alternatywne ścieżki scenariusza, np.
- Wykonawca głóny postępuje niepoprawnie
- Brak działania wykonawcy głównego
- Wykonawca pomocniczy reaguje z opóźnieniem
- Przeanalizuj wszystkie wystąpienia wyrażeń typu „System stwierdza, że...”
- Przeanalizuj sytuacje awaryjne
- Awarie wewnętrzne projektowanego systemu, które należy wykryć i obsłużyć
- Awarie wewnętrzne systemu, które wystarczy wykryć
Podsumowanie - jak stworzyć specyfikację systemu informatycznego?
- Określenie koncepcji projektu, np. w postaci prezentacji lub diagramu
- Charakterystyka wykonawców
- Lista „Wwykonawca-Cel”
- Lista „In-Out”
- Wymagania funkcjonalne
- Wymaganie niefunkcjonalne
- Opis przypadków użycia