Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Transkrypt

1 Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use Cases)

2 Cele Definicje cech produktu Uściślenie dokumentu wizji Określenie pozycji produktu Identyfikacja i dokumentacja cech systemu Opracowanie modelu przypadków użycia Szkice przypadków użycia Ciąg podstawowy, ciągi alternatywne, scenariusze Organizacja modelu przypadków użycia Pakiety Opis artefaktów modelowania biznesowego jako podstawy definicji systemu 2

3 W którym miejscu dyscypliny Wymagania jesteśmy? 3

4 Czynności i artefakty (1) 4

5 Czynności i artefakty (2) Cele tego punktu workflow są: Zapewnienie spójnego zrozumienia systemu przez zespół projektowy Przeprowadzenie wysokopoziomowej analizy rezultatów zbierania potrzeb stron zainteresowanych Dokumentacja rezultatów w formalnych modelach i dokumentach Zazwyczaj definiowanie systemu wykonuje się wyłącznie w iteracjach faz rozpoczęcia (inception) i opracowania (elaboration) 5

6 Czynności i artefakty (3) Analiza problemu i zrozumienie potrzeb stron zainteresowanych tworzą wczesne wersje kluczowych definicji systemu, w tym: Dokument wizji Pierwszy szkic modelu przypadków użycia Atrybuty wymagań Podczas definiowania systemu, najwięcej uwagi należy poświęcić identyfikacji cech, aktorów i przypadków użycia 6

7 Przypomnienie cecha (1) Widoczna z zewnątrz usługa, poprzez którą system bezpośrednio wypełnia jedno lub więcej żądań Czasami żądanie spełniane jest przez więcej niż jedną cechę Przykłady: System śledzenia usterek będzie dostarczał informacje o trendzie, aby kierownik projektu mógł oceniać status projektu Bankomat pozwoli klientom wykonywać przelewy między rachunkami 7

8 Przypomnienie cecha (2) Dokument wizji (w uproszczeniu) stanowi listę cech pochodzących na przykład z burzy mózgów Cechy określają potrzeby stron zainteresowanych: Cechy opisywane są z perspektywy systemu Przypadki użycia określane są z perspektywy użytkownika Przypadki użycia stanowią rozwinięcie opisu cech Ponieważ dokument wizji ma bardzo szerokie grono odbiorców, musi być napisany tak, żeby wszyscy go zrozumieli Jednocześnie musi być wystarczająco szczegółowy, żeby zespół projektowy mógł na jego podstawie wykonać model przypadków użycia 8

9 Przypomnienie jakość wymagań Poprawny Zupełny Spójny Jednoznaczny Weryfikowalny Oznaczony pod względem ważności i stabilności Modyfikowalny Traceable Zrozumiały 9

10 Określenie pozycji produktu (1) Określenie pozycji produktu podsumowuje unikatowość pozycji produktu i jego intencji na rynku Podkreśla cele i ważność produktu Jego celem jest sprzedanie pomysłu w kilku słowach Powinno wywierać wrażenie i być precyzyjne oraz zwięzłe (około pół strony) Czasami określenie pozycji produktu określa się mianem elevator pitch : Wchodzisz do windy i masz dwie minuty sam na sam z wiceprezesem. Musisz zabłysnąć i zainteresować go produktem. Chcesz, żeby zapoznał się z dokumentem wizji, kiedy znajdzie się na jego biurku. 10

11 Określenie pozycji produktu (2) Dla (klienta docelowego), który (określenie potrzeby lub okazji), (nazwa produktu) jest (kategoria produktu), dzięki któremu (kluczowe korzyści motywujące zakup). W przeciwieństwie do (głównej konkurencyjnej alternatywy), (nazwa produktu) (określenie podstawowych różnic). Wskazówka: dobrym punktem startowym jest stwierdzenie problemu wynikające z analizy problemu 11 Moore 91

12 Pozyskiwanie wymagań oprogramowania Wymagania stron zainteresowanych Wymagania stron zainteresowanych Kluczowe wymagania i cechy pochodzące od stron zainteresowanych Dokument wizji Wymagania oprogramowania Model przyp. użycia Specyfikacja uzupełniająca Specyfikacja projektowa 12 Specyfikacja dokumentacji użytkownika

13 Model przypadków użycia Przypadek 1 Rozpoznanie modelu - opis rozpoznania - lista aktorów - lista przypaków Aktor 1 Przypadek 2 Przypadek 3 Aktor 1 Aktor 1 Spec. przypadku 1 - krótki opis - ciągi zdarzeń Spec. przypadku 2 - krótki opis - ciągi zdarzeń Spec. przypadku 2 - krótki opis 13 - ciągi zdarzeń

14 Kroki tworzenia modelu przypadków użycia Identyfikacja aktorów i przypadków użycia Krótki opis: - nie więcej niż 2 akapity - Szkic: biznesowe uzasadnienie przypadku - zarys podstawowy kilku kluczowych ciąg zdarzeń scenariuszy? - alternatywne ciągi zdarzeń Nazwij i ponumeruj kroki Wielkość przypadku użycia Nazwa przypadku użycia Skrótowy opis Za mały? Za duży? Ciąg podstawowy 1. Krok pierwszy Podziel ciąg A może to 2. Krok drugi więcej podstawowy niż na 3. Krok trzeci jeden kroki Zarys Szczegóły: przypadek? Ciągi alternatywne - szczegóły 1. Ciąg ciągów alternatywny zdarzeń 1? - struktura 2.? Ciąg ciągów alternatywny zdarzeń 2 Zarys pomaga ciągi 3. Ciąg alternatywny 3znaleźć alternatywne Przypadek - war. wstępne użycia i wyjściowe, ciągi wymagania zdarzeń specjalne,... Zidentyfikuj alternatywne 14

15 Ciągi zdarzeń Ciąg (przepływ) jest sekwencją kroków Jeden ciąg podstawowy Udany scenariusz od początku do końca Wiele ciągów alternatywnych Regularne warianty Dziwne przypadki Ciągi wyjątkowe (błędy) 15

16 Scenariusze Instancja (wystąpienie) przypadku użycia Uporządkowany zbiór ciągów zdarzeń od początku przypadku do jednego z jego końców Przepływy Przykładowe (niektóre) scenariusze 16

17 *) pakiety w UML są narzędziem ogólnym, nie należy ich kojarzyć tylko z przypadkami użycia Pakiety* (1) Sposób na logiczną organizację modelu Czasami model jest zbyt duży i zbyt skomplikowany Dowolny sposób podziału i grupowania, np.: Pakiet zawiera jednego aktora i wszystkie związane z nim przypadki użycia Pakiet zawiera przypadki użycia dotyczące danej cechy produktu Możliwe użycie podpakietów 17

18 Pakiety (2) Zalecenia: Pakiet powinien zawierać od 3 do 10 jednostek (aktorów, przyp. użycia, podpakietów) Przy mniej niż 15 jednostkach nie ma sensu wprowadzać pakietów Przy jednostek należy używać jednego poziomu pakietów Powyżej 25 jednostek powinno się użyć dwóch poziomów 18

19 Pakiety (3) Pakiet nadrzędny Pakiety przypadków użycia Aktorzy Przypadki użycia Pakiety przypadków użycia 19

20 Model biznesowy (1) Model biznesowy stanowi istotny wkład w wymagania systemowe Zrozumienie reguł i procesów biznesowych jest konieczne dla zbudowania właściwego systemu Szczególnie pomocny przy budowaniu: Dopasowanych systemów dla jednego lub kilku przedsiębiorstw jakiejś branży (np. banków, firm ubezpieczeniowych) Rodziny aplikacji dla otwartego rynku (np. systemy obsługi zamówień, systemy billingowe, systemy kontroli lotów) 20

21 Model biznesowy (2) W jego skład wchodzą 2 zasadnicze części: Model biznesowych przypadków użycia Pokazuje funkcje związane z biznesem Pozwala zidentyfikować role i produkty (deliverables) organizacji W wydobywaniu wymagań pozwala stworzyć model przypadków użycia systemu Model obiektów biznesowych Opisuje pojęcia dotyczące biznesu, charakterystyczne rodzaje danych, pracowników i ich odpowiedzialności oraz zależności między nimi Zawiera słownictwo dotyczące obiektów biznesowych Może być także wykorzystany w workflow projektowania do tworzenia diagramów klas i innych części projektowania systemu 21

22 Model biznesowy (3) Model przypadków biznesowych Model obiektów biznesowych Modelowanie biznesowe traceability Model przypadków użycia Model projektowy Model implementacyjny Rozwój i budowa systemu Model testowy 22

23 Model biznesowy (4) Model obiektów biznesowych Pokazuje elementy strukturalne w formie diagramów: encje biznesowe (produkty, dokumenty, itp.), pracowników, odpowiedzialności i zależności Widoki statyczne Widoki dynamiczne Widoki behawioralne Diagram klas Diagram współpracy Diagram aktywności Diagram sekwencji Diagram stanów 23

24 *) business worker człowiek lub system, który wykonuje jakąś pracę w danym bizesie Model biznesowy (5) Jak mapować przypadki biznesowe na przypadki użycia: Aktor biznesowy aktor systemowy Pracownik biznesowy* aktor systemowy albo przypadek użycia Aktor kiedy wchodzi w interakcję z systemem Przypadek jeżeli jego praca jest automatyzowana przez system Przypadek biznesowy podsystem lub przypadek użycia System biznesowy podsystem lub przypadek użycia 24

25 Model biznesowy (6) System lub podsystem Aktor biznesowy Przypadek biznesowy Aktor systemowy System biznesowy Przypadki użycia Podsystem Pracownik biznesowy 25

26 Model biznesowy (7) Model przypadków biznesowych klient Ubiegaj się o pożyczkę Model obiektów biznesowych Jak możemy zrealizować proces biznesowy. :Klient :Urzędnik :Specjalista Pracownicy biznesowi stają się aktorami systemowymi. :ProfilKlienta :Konto :Pożyczka Model przyp. użycia Krok 1 Zastąpienie pracownika systemem. Klient staje się aktorem. Urzędnik Syst. przyp. użycia 1 Syst. przyp. użycia 2 Specjalista Model przyp. użycia Krok 2 Mapowanie encji biznesowych na klasy analizy (jednostki danych używane w procesie biznesowym) Klient Syst. przyp. użycia 1 Syst. przyp. użycia 2 Specjalista Model analityczny ProfilKlienta Konto Pożyczka 26