Inżynieria wymagań. Proces inżynierii wymagań

Transkrypt

1 Inżynieria wymagań. Proces inżynierii wymagań Dilbert by Scott Adams, tłum. własne Wykorzystane materiały: prezentacje J.E. Sienkiewicza i M.A. Płotki I. Sommerville, Inżynieria oprogramowania, WNT 2003 oraz odczyty J. Gorman Driving Development with Use Cases,

2 Ogólne zadania inżynierii wymagań Wydobycie wymagań/określenie potrzeb klienta Wyspecyfikowanie dobrych (mierzalnych, realnych, jednoznacznych itp.) wymagań Stworzenie kompletnej i spójnej listy wymagań Weryfikacja, integracja i pielęgnacja wymagań Zamodelowanie potrzeb klienta Oszacowanie złożoności, czasu powstania i kosztu stworzenia systemu Zebranie wymagań na złożony system zawsze będzie problemem trudnym technicznie i organizacyjnie

3 Źródła problemów w inżynierii wymagań Zła organizacja złe oszacowanie, rozplanowanie zadań Podatność do zmian ciągła zmiana wymagań znacznie utrudnia pracę nad projektem ( oni wciąż chcą czegoś innego, co my tak właściwie robimy pogoń za ruchomym celem), uszkodzenie struktury systemu w czasie licznych zmian Trudności w pisaniu należy dobrać język, który pozwoli opisać wymaganie tak by zostało ono zrozumiałe przez wszystkich udziałowców Brak możliwości śledzenia zmian kto, kiedy i komu podał/zmienił dane wymaganie?

4 Konsekwencje źle wyspecyfikowanych wymagań To, co klient zamówił To co, analityk zrozumiał To, co opisywał projekt To, co wykonali programiści Projekt po poprawkach i wdrożeniu To, czego klient potrzebował To, za co klient zapłacił Praktyczne zastosowanie projektu

5 Konsekwencje źle wyspecyfikowanych wymagań System może być dostarczony później i kosztować więcej niż planowano Klient i użytkownicy końcowi mogą nie być zadowoleni z systemu. Mogą w ogóle nie używać wybranych jego funkcji lub odrzucić go w całości System może działać niepewnie w normalnym użytkowaniu, generować błędy, zawieszać się itp. Koszt konserwacji i ewolucji systemu może znacząco wzrosnąć Wniosek: należy przyjrzeć się bliżej procesowi inżynierii oprogramowania,, który służy do określania, analizowania i zatwierdzania wymagań stawianych systemowi i obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych

6 Czynności procesu inżynierii wymagań Studium wykonalności Określanie i analizowanie wymagań Specyfikowanie wymagań Zatwierdzanie wymagań Raport wykonalności Dokumentacja wymagań Ogólne czynności w procesie inżynierii wymagań: studium wykonalności określanie i analizowanie wymagań specyfikowanie i dokumentowanie wymagań zatwierdzanie wymagań

7 Określanie i analizowanie wymagań Polega na pracy z klientem i użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować, pożądanej efektywności, ograniczeń sprzętowych, organizacyjnych itd. W określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych stanowisk w firmie. Pojawia się pojęcie udziałowca. Udziałowiec (ang. Stakeholder) każdy, kto ma pośredni lub bezpośredni wpływ na wymagania

8 Udziałowcy różne perspektywy

9 Proces określania i analizowania wymagań Sprawdzenie wymagań Specyfikacja wymagań Start Rozpoznanie dziedziny Nadawanie priorytetów Dokumentacja wymagań Zbieranie wymagań Usuwanie sprzeczności Klasyfikacja

10 Techniki pozyskiwania wymagań Studia dziedzinowe standardy, regulacje, przepisy prawne, schematy, opisy procedur i stanowisk itp. Analiza istniejącego procesu w firmie gdzie jest problem? Wywiady pozyskiwanie informacji podczas bezpośredniej rozmowy z klientem Obserwacje obserwowanie istniejącego stanu rzeczy Praca grupowa np.. burza mózgów Ankiety, kwestionariusze Prezentacje wstępnej reprezentacji zebranych wymagań (np( np.. w postaci diagramu przypadków użycia) pozostałym udziałowcom Symulacje symulowanie różnych punktów widzenia Eksperymenty Prototypowanie

11 Dlaczego określanie wymagań jest takie nudne trudne? Biznes jest zwykle prowadzony w szybko zmieniającym się środowisku (ekonomicznym, rynkowym, prawnym, politycznym, technologicznym), zatem wymagania na system ciągle się zmieniają Zwykle w procesie zbierania wymagań występuje wielu udziałowców ze znacząco różnymi celami, oczekiwaniami względem systemu oraz priorytetami (często sprzecznymi ze sobą) Udziałowcy często nie wiedzą, czego tak naprawdę oczekują od nowo tworzonego systemu komputerowego Udziałowcy mogą stawiać nierealne żądania (np.. nie uwzględniając kosztu ich wprowadzenia) Udziałowcy systemu wyrażają wymagania za pomocą własnych pojęć. Inżynier oprogramowania musi zrozumieć tak wyrażone wymagania i przełożyć je na wymagania systemowe

12 Dlaczego określanie wymagań jest takie trudne? Czynniki polityczne i ludzkie Kluczowi udziałowcy zawsze mają inne rzeczy na głowie! Opracowanie (podanie) szczegółowych wymagań dla przyszłego systemu często nie ma zbyt wysokiego priorytetu u osób, które będą dotknięte tymi wymaganiami. W związku z tym nie są w stanie wyrazić wymagań szczegółowo, robią to mało konkretnie Udziałowcy nie muszą być przekonani do końca, że tworzenie systemu jest konieczne lub uważać, że nie jest to sprawa priorytetowa. Mogą więc aktywnie bądź pasywnie odmawiać współpracy Czynniki polityczne i organizacyjne u zleceniodawcy również mają zwykle spory wpływ na system, a udziałowcy nie chcą lub nie potrafią ich określić czy uzasadnić. Z kolei twórcy systemu nie są w stanie ich zrozumieć. Decyzje dotyczące wymagań mogą być więc podejmowane na irracjonalnym gruncie, opartym o czyjeś osobiste korzyści

13 Dlaczego określanie wymagań jest takie trudne? Zmienność procesu Nie ma żadnych obiektywnych sposobów porównywania alternatywnych zestawów wymagań. Wpływ systemu na biznes jest bardzo trudny do zrozumienia, zatem nie możemy w ogólności powiedzieć, który system będzie najlepszy dla konkretnego przedsiębiorstwa Wymagany poziom szczegółowości specyfikacji różni się znacznie w zależności od rodzaju opracowywanego produktu. W celu uzyskania specyfikacji mogą być więc wykorzystywane zupełnie różne procesy obejmujące różne typy ludzi pojawiają się ograniczenia standaryzacji procesu dla systemu sygnalizacji kolejowej wymagana jest bardzo szczegółowa specyfikacja, która będzie zatwierdzana przez odpowiednie urzędy (niezależnie od zleceniodawcy) specyfikacja gry komputerowej może być z kolei scenariuszem ze zdjęciami i przykładami

14 Dlaczego określanie wymagań jest takie trudne? Na wesoło o użytkownikach końcowych ;) W pewnym momencie podczas realizacji projektu ktoś zaczyna biadolić, że trzeba określić wymagania. Wiążą się z tym rozmowy z ludźmi, którzy to ciekawe nie wiedzą, czego chcą, ale dokładnie wiedza, kiedy tego potrzebują. Tych ludzi nazywa się użytkownikami finalnymi lub po prostu kołkami. Badania wykazały, że na świecie nie ma nić głupszego niż użytkownik finalny. Diagram poniżej pokazuje inteligencję względną kilku zwykłych składników gospodarstwa domowego: Scott Adams - Zasada Dilberta Wyd. Amber, W-wa, 2001

15 Techniki i narzędzia używane w procesie inżynierii wymagań Punkty widzenia przyglądamy się systemowi z punktu widzenia przetwarzanych danych lub oferowanych usług Scenariusze opisujemy przebieg interakcji np.. między użytkownikiem a systemem Scenariusze i punkty widzenia składają się (w pewnym sensie) w tzw. model przypadków użycia (Use( Cases) Analiza strukturalna oparta głównie na formalnych metodach zapisu wymagań

16 Określanie wymagań oparte na punktach widzenia (VORD) VORD: ang. Viewpoint-Oriented Requirements Definition Zwykle systemy maja kilka różnych grup użytkowników. Należy przyjrzeć się systemowi z ich punktu widzenia. Klasyfikacja punktów widzenia: Ze względu na źródło lub przeznaczenie danych Punkt widzenia powiązany jest z użytkowaniem lub produkcją danych. Analiza polega na rozpoznawaniu wszystkich danych, miejsc ich produkcji, użytkowania i przetwarzania. Ze względu na usługi zewnętrzne W tym wypadku punkty widzenia są zewnętrzne wobec systemu. Osoby mające ten sam punkt widzenia korzystają z jednakowych usług systemu.

17 Model zewnętrznych punktów widzenia Reprezentanci zewnętrznych punktów widzenia współpracują z systemem przez otrzymywanie usług od systemu oraz przekazywanie do systemu danych i sygnałów sterujących. Punkty widzenia są zewnętrzne wobec systemu, stanowią zatem naturalny sposób strukturalizacji procesu określania wymagań. Punkty widzenia i usługi stanowią dobry sposób strukturalizacji nie tylko wymagań funkcjonalnych, ale również niefunkcjonalnych i dziedzinowych. Każda usługa może być powiązana z wymaganiami niefunkcjonalnymi lub dziedzinowymi. Dość łatwo jest stwierdzić, czy coś jest punktem widzenia, czy też nie.. Reprezentanci punktów widzenia muszą bowiem w pewien sposób oddziaływać na system.

18 Punkty widzenia a atrybuty/cele systemu Atrybuty i ogólne cele systemu odnoszą się do wszystkich punktów widzenia i są do nich prostopadłe

19 Przykład system bankomatowy System służy do wykonywania operacji bankomatowych przy użyciu karty bankomatowej z przypisanym kodem PIN W uproszczonej wersji służy klientom macierzystego banku ( własny klient ), oferując im bardziej skomplikowane usługi, oraz klientom innym banków ( obcy klient ) w ograniczonym zakresie Usługi zaawansowane obejmują np.. wypłatę i wpłatę środków, przekazywanie komunikatów do banku, wyświetlanie informacji (np( np.. o saldzie konta lub wykonanych transakcjach).

20 System bankomatowy burza mózgów Pytanie o saldo Zasoby maszyny Interfejs użytkownika Własny klient Zdalna diagnostyka Odczyt transakcji Informacje o koncie Karta skradziona Niezawodność Menedżer Koszt systemu Aktualizacja konta Baza danych klientów Dziennik komunikatów Obcy klient Zwrot karty Pielęgnacja Zamówienie oprogramowania wyciągu Przelew środków Wypłata gotówki Zdalna aktualizacja oprogramowania Rozmiar oprogramowania Drukarka Dziennik transakcji Zamówienie czeków Kasa banku Nieuprawniony użytkownik Zabezpieczenia Zatrzymanie karty Przekazywanie komunikatów Weryfikacja karty

21 System bankomatowy udziałowcy Klienci banku Klienci innych banków Dyrektorzy oddziałów banków Pracownicy obsługi klienta w oddziałach Kasa banku Administratorzy baz danych Osoby odpowiedzialne za bezpieczeństwo w banku Dział marketingu banku Inżynierowie pielęgnacji sprzętu i oprogramowania

22 System bankomatowy punkty widzenia Wszystkie PW Klient Personel banku Kasa banku Menedżer Inżynier Własny klient Obcy klient

23 System bankomatowy punkty widzenia a usługi WŁASNY KLIENT OBCY KLIENT KASA BANKU Lista usług Lista usług Lista usług Wypłata gotówki Pytanie o saldo Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Wypłata gotówki Pytanie o saldo Diagnostyka Dodanie gotówki Dodanie papieru Wysłanie komunikatu

24 System bankomatowy dane sterujące i wejściowe WŁASNY KLIENT Dane sterujące Dane wejściowe Rozpocznij transakcję Informacje z karty Anuluj transakcję PIN Zakończ transakcję Żądana kwota Wybór usługi

25 System bankomatowy opis punktów widzenia i usług Nazwa PW: Klient Usługa: Wypłata gotówki Atrybuty: Numer konta PIN Uzasadnienie: Celem zmniejszenie obciążenia okienek kasowych itp. Zdarzenia: Usługi: Rozpocznij transakcję Wybór usługi Anuluj transakcję Zakończ transakcję Wypłata gotówki Pytanie o saldo Podrzędne PW: Własny klient Obcy klient Specyfikacja: Użytkownicy wybierają usługę przez naciśnięcie przycisku wypłata gotówki. Następuje weryfikacja numeru PIN. Następnie wprowadzona zostaje żądana kwota. Jeśli na koncie są wystarczające środki, następuje wypłata gotówki. PW: Klient Wymagania niefunkcjonalne: Wypłacić gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty

26 Scenariusze (ang. scenarios) Ludzie zwykle wolą przykłady wzięte z życia od abstrakcyjnych opisów Scenariusz opis typowego przebiegu zadania wykonywanego przez użytkownika systemu (interakcji użytkownik system) Każdy scenariusz obejmuje jedną lub najwyżej kilka możliwych interakcji Na podstawie scenariuszy można wywieść wymagania systemowe

27 Cechy/atrybuty scenariusza Opis stanu systemu na początku scenariusza Opis normalnego następstwa zdarzeń scenariusza Opis tego, co może pójść źle, i jak to jest obsługiwane Informacje o innych czynnościach, które można wykonywać w tym samym czasie Opis stanu systemu po zakończeniu scenariusza Każde odrębne zdarzenie w interakcji może być udokumentowane za pomocą oddzielnego scenariusza zdarzenia Opis przepływu danych, akcji systemu i wyjątków, które mogą się pojawić

28 Przykład scenariusza system bankomatowy Zdarzenie inicjujące: wsunięto kartę do szczeliny Stan początkowy: karta w bankomacie Opis: Wyświetl listę dostępnych operacji. Po wybraniu operacji przez klienta monituj o podanie numeru PIN. Gdy wpisany numer jest poprawny, zidentyfikuj klienta. Sytuacje wyjątkowe: przekroczony limit czasu: zwróć kartę karta nieważna lub skradziona: zatrzymaj kartę niepoprawny numer PIN: zapytaj ponownie niepoprawny numer PIN podany po raz trzeci: zatrzymaj kartę Stan końcowy: użytkownik zidentyfikowany, przejdź do realizacji wybranej przez klienta operacji.

29 Model przypadków użycia (Use( Cases) Metoda oparta na scenariuszach i zewnętrznych punktach widzenia, służąca do określania wymagań i interakcji użytkownika z systemem Po raz pierwszy użyta w 1993 (I. Jacobson). Obecnie jest podstawowym elementem notacji UML Podstawowe pojęcia: przypadek użycia, aktor, relacje między przypadkami użycia bądź aktorami System widziany jest jako czarna skrzynka, zapewniająca określoną funkcjonalność Model wyraźnie rozdziela system i to, co powinien realizować (przypadki użycia i relacje między nimi), od tego, co jest poza nim (aktorzy i relacje między nimi) Metoda polega na ilustracji graficznej (diagram przypadków użycia), wspieranej odpowiednimi scenariuszami

30 Elementy notacji graficznej: przypadek użycia, aktor Aktor: abstrakcyjny użytkownik systemu, reprezentujący grupę użytkowników ków używających podobnych funkcji systemu i sposobu z nim komunikacji symbol graficzny: Przypadek użycia: ciąg interakcji pomiędzy aktorem a systemem, dostarczający aktorowi pożądanych wyników symbol graficzny: Klasyfikacja aktorów: aktor główny: używa podstawowych funkcji systemu aktor drugorzędny: używa funkcji administracyjnych i pielęgnacyjnych aktor aktywny: inicjuje przypadek użycia aktor pasywny: uczestniczy w przypadku użycia, ale go nie inicjuje

31 Podstawowe relacje Relacja komunikuje komunikuje ( communicates communicates, często reprezentowana przez zwykłe wiązanie association ) W przypadku dwukieunkowym (bez strzałki) oznacza inicjowanie przypadku użycia i ew. odbieranie wyników przez aktora. W przypadku relacji jednokierunkowej, aktor jedynie inicjuje przypadek użycia (aktor aktywny) lub w nim uczestniczy (aktor pasywny). Relacja zawiera zawiera ( include include ) Wskazuje na wspólny fragment kilku przypadków użycia, wykorzystanie wspólnego zachowania. Dawna nazwa: używa ( uses uses ). Relacja rozszerza rozszerza ( extend extend ) Rozszerza przypadek użycia o sytuację wyjątkową. Dawna nazwa: extends extends.

32 Relacje uogólnienia i inne elementy notacji Relacja uogólnienia aktora ( actor generalization ) Relacja uogólnienia przypadku użycia ( use case generalization ) Granice systemu są wyznaczane za pomocą prostokąta. Aktorzy są zwykle na zewnątrz systemu, przypadki użycia wewnątrz Możliwa jest komunikacja aktorów poza systemem W szczególności aktorem może być jakiś element systemu (np( np. wyświetlacz, timer) ) lub (rzadziej) jakieś wymaganie niefunkcjonalne/dziedzinowe

33 Przykład kompletnego diagramu Inny kompletny diagram przypadków użycia był zaprezentowany na poprzednim wykładzie

34 Przykład scenariusza Przypadek użycia: Wypłata gotówki Aktorzy: Własny klient, Obcy klient Zdarzenie inicjujące: wybranie w menu opcji wypłata oraz podanie kwoty do wypłaty Stan początkowy: karta w bankomacie Opis: Monituj o podanie numeru PIN. Gdy wpisany numer jest poprawny, zidentyfikuj klienta i sprawdź dostępne środki na koncie. Jeżeli środki są wystarczające, wypłać gotówkę. Sytuacje wyjątkowe: karta nieważna lub skradziona: zatrzymaj kartę niepoprawny numer PIN: zapytaj ponownie niepoprawny numer PIN podany po raz trzeci z kolei: zatrzymaj kartęk brak środków na koncie: wyświetl komunikat Brak środków Stan końcowy: gotówka wypłacona, saldo konta zmniejszone

35 Model przypadków użycia najczęstsze błędy Granice systemu nie są zdefiniowane bądź nie są stałe Przypadki użycia są napisane z perspektywy systemu a nie aktorów Nazwy aktorów lub przypadków użycia są niespójne Zbyt dużo przypadków użycia Zbyt skompilowana pajęczyna relacji Zbyt długi scenariusz przypadku użycia Mylący scenariusz/specyfikacja przypadków użycia Przypadki użycia nieprawidłowo opisują funkcjonalność systemu Przypadki użycia nie są zrozumiałe dla klienta Przypadki użycia nigdy nie są ukończone

36 Model przypadków użycia podsumowanie Identyfikacja granic systemu i aktorów Specyfikacja wymagań funkcjonalnych, postrzeganych przez zewnętrznych aktorów Wspomaganie walidacji wymagań Punkt wyjścia dla testów systemu Przydatność dla celów prezentacji funkcjonalności systemu zrozumiałość i komunikatywność Podstawa do tworzenia diagramów sekwencji

37 Diagram sekwencji (ang. sequence diagram) Diagram sekwencji zostanie szczegółowo omówiony na wykładzie poświęconym językowi UML

38 Sprawdzanie i zatwierdzanie wymagań Przed zatwierdzeniem specyfikacji, wymagania należy sprawdzić wykazać, że definiują system, którego chce użytkownik Sprawdzenie ważności. Czy użytkownicy są przekonani, że system powinien spełniać wyspecyfikowane funkcje? Sprawdzenie zrozumiałości. Czy klienci i użytkownicy systemu dobrze zrozumieli wymaganie? Sprawdzenie pochodzenia. Czy zaznaczone jest źródło, z którego pochodzi wymaganie? Sprawdzenie niesprzeczności. Czy wymagania nie przeczą sobie nawzajem? Sprawdzenie kompletności. Czy zdefiniowano wszystkie funkcje i ograniczenia systemu? Sprawdzenie realności. Czy wymagania można zaimplementować przy użyciu dostępnych środków? Możliwość weryfikacji. Czy wymagania systemowe są napisane tak, aby można było je zweryfikować? Sprawdzenie giętkości. Czy wymaganie może być zmienione bez znaczącego wpływu na pozostałe wymagania?

39 Zarządzanie wymaganiami Oznakowanie wymagań Każde wymaganie musi być unikatowo oznakowane tak, aby można było robić do niego odnośniki z innych wymagań i używać tego wymagania przy ocenianiu pochodzenia. Strategia śledzenia pochodzenia Należy odnotowywać zależności między wymaganiami i projektem systemu używając określonej metody. Proces zarządzania zmianami Zbiór czynności szacowania wpływu zmian na system i ich kosztu. Użycie narzędzi CASE Zarządzanie wymaganiami polega na przetwarzaniu ogromnej liczby informacji o wymaganiach. Narzędzia CASE nie są zbyt rozbudowane w inżynierii wymagań, ale pomagają np.. w weryfikacji wymagań formalnych czy tworzeniu diagramów UML.

40 Stabilność wymagań Wymagania stałe względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu Wymagania zmienne wymagania, które z dość dużym prawdopodobieństwem mogą ulec zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkowania wymagania zmieniające się: zmieniają się na skutek zmian środowiska, w którym działa firma. wymagania pojawiające się: pojawiają się w trakcie procesu tworzenia w miarę coraz lepszego rozumienia systemu przez klienta. wymagania wynikowe: wynikają z wdrożenia systemu komputerowego. wymagania zgodności: zależą od umów lub procesów gospodarczych wewnątrz firmy. Wymagania stawiane dużym systemom oprogramowania zawsze się zmieniają trzeba odnotowywać zmiany

41 Zarządzanie zmianami wymagań Zarządzanie zmianami wymagań należy stosować do wszystkich postulowanych zmian wymagań Trzy podstawowe kroki: Analiza problemu i specyfikacja zmiany. Rozpoznanie problemu z wymaganiem, konkretna propozycja zmiany Analiza zmiany i ocena kosztów. Korzystając z informacji o uzależnieniu wymagania od innych i ogólnej wiedzy o wymaganiach systemowych, ocenia się wpływ proponowanej zmiany na cały system i szacuje koszt zmiany Implementacja zmiany. W przypadku podjęcia decyzji o wprowadzeniu zmiany, modyfikuje się dokumentację wymagań oraz projekt a następnie implementuje się zmianę

42 Literatura B.W. Boehm, P.N. Papaccio, Understanding and Controling Software Cost. IEEE Press, 1988 A. Cockburn, Writing Effective Use Cases. In preparation for Addison- Wesley Longman, Materiały na stronie Materiały na stronie K. E. Wiegers, Software Requirements, 2nd Edition. Microsoft Press, 2003