Inżynieria wymagań. Wykład 2 Proces pisania przypadków użycia. Część 3 Identyfikacja przypadków użycia

Transkrypt

1 Inżynieria wymagań Wykład 2 Proces pisania przypadków użycia Część 3 Identyfikacja przypadków użycia Opracowane w oparciu o materiały IBM (kurs REQ570: Writing Good Use Cases)

2 Znajdowanie przypadków użycia Znajdź aktorów Znajdź przypadki użycia Nazwij i skrótowo opisz znalezione przypadki użycia Naszkicuj przypadki użycia Uszczegółów przypadki użycia Stwórz diagram przypadków użycia Oszacuj wartość biznesową i techniczne ryzyko przypadków użycia 2

3 Znajdź przypadki użycia Jakie cele próbuję osiągnąć z pomocą systemu? Cel 1 Aktor Cel 2 3

4 Znajdź przypadki użycia Jakie są cele każdego aktora? Dlaczego aktor chce używać systemu? Czy aktor będzie tworzył, przechowywał, zmieniał, usuwał lub odczytywał dane w systemie? Jeżeli tak dlaczego? Czy aktor będzie potrzebował informować system o zewnętrznych zdarzeniach lub zmianach? Czy aktor będzie potrzebował być informowanym o określonych zdarzeniach w systemie? Czy system zapewnia wszystko, aby zrealizować założone cele biznesowe? 4

5 Czy logowanie jest przypadkiem użycia? Zgodnie z definicją UML logowanie nie jest przypadkiem użycia, ponieważ nie dostarcza wartości aktorowi Jednak w wielu przypadkach istnieje konieczność oddzielnego uwzględnienia logowania ponieważ: Zawiera i wiąże ono bardziej złożone zachowania Jest włączane w inne przypadki użycia Zalecenie: róbmy wyjątek i traktujmy logowanie jako oddzielny przypadek użycia Zaloguj się Użytkownik 5

6 Przypadki użycia typu CRUD Czynności typu: Create, Read, Update, Delete Usuwajmy przypadki CRUD, jeżeli dotyczą wyłącznie zarządzania danymi, a nie dostarczają rezultatów, które stanowią wartość dla aktorów Utwórz plan Należy skupić się na wartości Odczytaj plan Zapisz się na kursy Uaktualnij plan Usuń plan Nie należy mylić przypadków użycia z funkcjami 6

7 Nazwij przypadki użycia Nazwa przypadku powinna: Być unikatowa, intuicyjna i samo-wyjaśniająca Jasno i jednoznacznie definiować obserwowalny wynik wartości uzyskiwanej z przypadku użycia Być tworzona z perspektywy aktora wyzwalającego przypadek użycia Opisywać zachowanie, którego przypadek dotyczy Zaczynać się od czasownika lub prostej kombinacji czasownika z rzeczownikiem Zapisz się na kursy Wybierz kursy do prowadzenia Wskazówka: dobrze jest przeprowadzić rozeznanie, czy klienci, ich przedstawiciele, analitycy i deweloperzy rozumieją prawidłowo nazwy przypadków użycia 7

8 Opisz przypadki użycia Nazwa: Zapisz się na kursy Krótki opis: Student wybiera kursy, na które chce uczęszczać w następnym semestrze. Zostaje utworzony plan podstawowych i alternatywnych kursów. Powiązanie z aktorami: Student Zapisz się na kursy 8

9 Punkty kontrolne aktorów Czy znalazłeś wszystkich aktorów? Czy uwzględniłeś i zamodelowałeś wszystkie role w środowisku systemu? Czy każdy aktor jest związany z przynajmniej jednym przypadkiem użycia (poza logowaniem)? Czy jacykolwiek aktorzy odgrywają podobne role względem systemu?jeżeli tak, połącz ich w jednego aktora. 9

10 Punkty kontrolne przypadków użycia (1) Model przypadków użycia przedstawia zachowanie systemu; czy łatwo zrozumieć poprzez model, co robi i czemu służy system? Czy wszystkie przypadki zostały zidentyfikowane? Czy łącznie dają pełne wymagane zachowanie? Model przypadków użycia nie zawiera żadnego zbędnego zachowania; czy wszystkie przypadki można oprzeć o wymagania (traceability)? Czy wszystkie przypadki CRUD zostały usunięte? 10

11 Punkty kontrolne przypadków użycia (2) Czy wszystkie przypadki mają unikatowe, intuicyjne i wyjaśniające nazwy, tak że nie pojawią się żadne pomyłki w dalszych pracach? Czy klienci i użytkownicy rozumieją nazwy i opisy przypadków użycia? Czy skrócone opisy dają prawdziwy obraz przypadków użycia? Czy każdy przypadek związany jest z co najmniej jednym aktorem? Czy nie istnieją przypadki dotyczące bardzo podobnego zachowania lub ciągu zdarzeń? 11

12 Diagramy przypadków użycia Kanały komunikacyjne między aktorami, a przypadkami użycia Linie asocjacji reprezentują komunikację Aktor 1 Przypadek użycia Aktor 2 Aktor 3 12

13 Diagramy przypadków użycia asocjacje komunikacji Każda asocjacja reprezentuje pełną konwersację (dialog) 1. Student loguje się do systemu 2. System akceptuje logowanie 3. Student żąda informacji o kursach Student Zapisz się na kurs System katalogowania kursów 6. System umożliwia wybór kursu 7. Student wybiera kursy 4. System przekazuje żądanie 5. Katalog zwraca informacje o kursach 8. System prezentuje zaakceptowany plan 13

14 Przykładowy diagram przypadków użycia Zapisz się na kursy Student Przeglądaj katalog kursów System katalogowania kursów Przeglądaj oceny Zakończ rejestrację Wybierz kursy do prowadzenia System zarządzania płatnościami Rejestrator Pokaż studentów z kursu Wpisz oceny Profesor 14

15 Oceń wartość biznesową i ryzyko techniczne Dla każdego zidentyfikowanego przypadku znajdź porozumienie między stronami dotyczące wartości biznesowej i ryzyka technicznego Zespół biznesowy (klient?) decyduje, co ma wysoką wartość, a co nie Zespół techniczny (my?) decyduje, co jest istotne architektonicznie, a co ryzykowne 15