Procesy Inżynierii Wymagań

1. Procesy Inżynierii Wymagań • Procesy służące do zidentyfikowania, przeanalizowania i zatwierdzenia wymagań systemowych

2. Cele • Rozumienie podstawowych czynności inżynierii wymagań • Poznanie metod określania i analizowania wymagań • Rozumienie znaczenia zatwierdzania wymagań • Rozumienie roli zarządzania wymaganiami oraz tego, jak wspomaga ono inne czynności inżynierii wymagań

3. Zawartość • Studium wykonalności • Określenie i analizowanie wymagań • Zatwierdzanie wymagań • Zarządzanie wymaganiami

4. Procesy inżynierii wymagań • Procesu używane w IW różnią się mocno w zależności od dziedziny, w której działamy i odludzi zaangażowanych w działanie organizacji i budowę systemu. • Mimo to istnieje kilka czynności wspólnych dla wszystkich sytuacji • Wydobywanie wymagań • Analiza wymagań • Zatwierdzanie wymagań • Zarządzanie wymaganiami

5. Proces inżynierii wymagań Określanie i analizowanie wymagań Studium wykonalności Specyfikowanie wymagań Zatwierdzanie wymagań Raport o wykonalności Model systemu Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań

6. Studium wykonalności • Studium wykonalności decyduje czy warto wykonać system • Krótkie opracowanie, odpowiadające na pytania • Czy system przyczyni się do realizacji celów organizacji • Czy system może być stworzony przy użyciu dostępnych technologii w ramach określonego budżetu i ograniczeń czasowych • czy system może być zintegrowany z istniejącymi systemami

7. Przeprowadzenie studium wykonalności • Określenie i zebranie informacji a następnie napisanie raportu • Pytania, które powinny być zadane • Co się stanie jeśli system nie powstanie? • Jakie problemy aktualnie występują? • Jak system pomoże w ich rozwiązaniu? • Jakie będą problemy z integracją? • Jakie nowe technologie są potrzebne? Jaki umiejętności? • Jakie udogodnienia musi wspierać system a jakich nie?

8. Wydobywanie i analiza • Czasem nazywana odkrywaniem wymagań • Angażuje technicznych budowniczych, którzy pracując z klientami wydobywają od nich wiedzę o dziedzinie, informacje o usługach, które system powinien udostępniać i ograniczenia dla działania systemu • Może angażować użytkowników końcowych, inżynierów klienta, ekspertów z dziedziny, i innych. Nazywamy ich uczestnikami

9. Problemy z analizą wymagań • Uczestnicy nie wiedzą czego naprawdę oczekują • Uczestnicy wyrażają wymagania w hermetycznym języku • Różni uczestnicy mają sprzeczne wymagania • Czynniki organizacyjne i polityczne wpływają na wymagania systemowe • Wymagania zmieniają się w czasie trwania procesu analizy. Pojawiają się nowi uczestnicy a otoczenie biznesowe się zmienia

10. Proces analizy wymagań Specyfikacja wymagań Sprawdzanie wymagań Dokumentacja wymagań Rozpoznanie dziedziny Nadawanie priorytetów Początek procesu Zbieranie wymagań Usuwanie sprzeczności Klasyfikacja

11. Czynności procesu • Rozpoznanie dziedziny • Zebranie wymagań • Klasyfikacja • Usuwanie sprzeczności • Nadawanie priorytetów • Sprawdzanie wymagań

12. Modele systemu • Różne modele mogą powstawać podczas różnych czynności analizy wymagań • Analiza wymagań może angażować trzy czynności systematyzujące, które prowadzą do trzech różnych modeli • Dzielenie. Odnajduje strukturalne (część czegoś) związki pomiędzy encjami. • Abstrakcja. Odnajduje generalizacje pomiędzy encjami • Projekcja. Identyfikuje różne spojrzenia na ten sam problem • O modelach systemu opowiem za tydzień

13. Określanie oparte na punktach widzenia • Uczestnicy miewają różne punkty widzenia na ten sam problem • Analiza z wielu perspektyw jest ważna, ponieważ nie istnieje jedynie słuszna metoda na analizowanie wymagań

14. System obsługi bankomatu • Przykład opisuje bankomat, który może dostarczać wielu usług • Upraszczamy system mówiąc, że bankomat jest własnością banku i klientom tego banku oferuje pełną gamę usług, a klientom innych banków usługi w ograniczonym zakresie • Usługi zawierają: wypłatę pieniędzy, wysłanie wiadomości do banku, wydruk stanu konta i przelew pieniędzy

15. Punkty widzenia dla bankomatu • Klienci banku • Przedstawiciele innych banków • Inżynierowie pielęgnacji sprzętu i oprogramowania • Dział marketingu banku • Dyrektorzy oddziałów banku • Administratorzy baz danych i dział bezpieczeństwa • Inżynierowie komunikacji • Pracownicy obsługi klienta w oddziałach

16. Typy punktów widzenia • Źródło lub przeznaczenie danych • Punkt widzenia odpowiedzialny za produkowanie lub użytkowanie danych. Analiza polega na rozpoznaniu wszystkich takich punktów widzenia i sprawdzeniu czy założenia dotyczące danych są poprawne • Zrąb reprezentacji • Osoba związana z konkretnym typem modelu systemu. Odpowiednie dla systemów czasu rzeczywistego. • Odbiorca usług • Punkty widzenia są zewnętrzne wobec systemu.

17. Zewnętrzne punkty widzenia • Naturalny sposób myślenia o końcowych użytkownikach systemu • Punkty widzenia w naturalny sposób porządkują wymagania • Łatwo stwierdzić czy coś jest punktem widzenia czy nie • Punkty widzenia i usługi stanowią dobry sposób na uporządkowanie wymagań niefunkcjonalnych

18. Analiza oparta na metodach • Szeroko stosowane podejście do analizy wymagań. Zależnie od zastosowanej metody uzyskamy inny stopień zrozumienia systemu • Metody koncentrują się na różnych celach. Niektóre są przeznaczone do wydobywania wymagań, inne są bliskie projektowaniu • Jako przykład przedstawię opartą na punktach widzenia metodę VORD

19. Metoda VORD Identyfikacja punktów widzenia Strukturalizacja punktów widzenia Dokumentacja punktów widzenia Przyporządkowanie punktów widzenia do systemu

20. Model procesu VORD • Identyfikacja punktów widzenia • Znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu i usług dla tych reprezentantów • Strukturalizacja punktów widzenia • Grupowanie podobnych punktów widzenia w hierarchię. Wspólne usługi są umieszczone wyżej • Dokumentowanie punktów widzenia • Udoskonalanie opisów punktów widzenia i usług • Przyporządkowywanie punktów widzenia • Przekształcanie punktów widzenia w projekt obiektowy

21. Szablony formularzy VORD Szablon do punktu widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariuszy opisujących, jak system reaguje na zdarzenia w ramach tego punktu widzenia Usługi: Odnośnik do zbioru opisów usług Podrzędne: Nazwy podrzędnych punktów Szablon do usług Odnośnik: Nazwa usługi Uzasadnienie: Przyczyna oferowania usługi Specyfikacja: Odnośnik do listy specyfikacji usług, które mogą być zapisane za pomocą różnych notacji Punkty widzenia: Lista nazw punktów widzenia, których reprezentacji korzystają z usługi Wymagania niefunkcjonalne: Odnośnik do zbioru wymagań niefunkcjonalnych ograniczających usługę Dostawca: Lista obiektów systemu oferujących tę usługę

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

23. Informacje o usługach

24. Dane wejściowe i sterujące

25. Hierarchia punktów widzenia Wszystkie PW Usługi Pytanie o saldo Wypłata gotówki Klient Personel banku Usługi Zamówienie czeków Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Właściciel konta Klient obcy Kasa Menedżer Inżynier

26. Wzory: klient/wypłata gotówki Odnośnik: Klient Atrybuty: Numer konta, PIN Zdarzenia: Zacznij transakcję, Wybór usługi, Anuluj transakcję, Zakończ transakcję Usługi: Wypłata gotówki, Pytanie o saldo Podrzędne: Właściciel konta, Klient Obcy Odnośnik: Wypłata gotówki Uzasadnienie: Celem jest ulepszenie obsługi klienta i zmniejszenie liczby papierowych dokumentów Specyfikacja: Użytkownicy wybierają tę usługę przez naciśnięcie przycisku „wypłata gotówki”. Następnie wprowadzają żądaną kwotę. Potwierdza się ją i jeśli na koncie są odpowiednie środki, następuje wypłata Punkty widzenia: Klient Wymagania niefunkcjonalne: Wypłacić gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty Dostawca:Wypełnić później

27. Scenariusze • Scenariusze są przykładami, jak system jest używany w praktyce • Są przydatne podczas wydobywania wymagań, ponieważ ludzie rozumieją je dużo lepiej niż abstrakcyjne opisy tego, co oczekują od systemu • Scenariusze są szczególnie przydatne w dodawaniu szczegółów do ogólnych opisów

28. Opis scenariusza • Stan systemu przed rozpoczęciem scenariusza • Normalny przebieg zdarzeń scenariusza • Co może pójść źle i jak to jest obsługiwane • Inne zdarzenia, które mogą dziać się w tym samym czasie • Stan systemu po zakończeniu scenariusza

29. Scenariusze zdarzeń • Scenariusze zdarzeń mogą być używane do opisu jak system odpowiada na jakieś konkretne zdarzenie np. „początek transakcji” • VORD zawiera graficzne konwencje do przedstawiania scenariuszy zdarzeń. • Dane odbierane i przekazywane • Informacja sterująca • Obsługa wyjątków • Następne zdarzenia

30. Scenariusz zdarzenia – zacznij transakcję Wsunięto kartę Karta ważna Karta Poproś o PIN Użytkownik OK PIN Numer konta PIN Sprawdź użytkownika Numer konta Przekroczenie limitu czasu Wybierz usługę Zły PIN Zwróć kartę Wprowadź ponownie PIN Karta nieważna Zły PIN Zwróć kartę Zwróć kartę Karta skradziona Zatrzymaj kartę

31. Konwencje dla scenariuszy zdarzeń • Elipsy to dane przekazywane z i do reprezentantów punktów widzenia • Informacja sterująca wychodzi z góry prostokąta • Dane wychodzą z boku prostokąta • Wyjątki są pokazywane na dole prostokątów • Następne zdarzenie w cieniowanym prostokącie

32. Opis wyjątków • Większość metod nie posiada udogodnień do opisu wyjątków • W tym przykładzie wyjątkami są • Przekroczenie limitu czasu. Klientowi nie udało się wprowadzić kodu PIN w wyznaczonym czasie • Karta nieważna. Nie udało się rozpoznać karty • Karta skradziona. Karta została zgłoszona jako skradziona

33. Przypadki użycia • Przypadki użycia są używaną w UML-u techniką opartą na scenariuszach i definiują aktorów biorących udział w interakcji, co opisuje samą interakcję • Zbiór przypadków użycia powinien opisywać wszystkie interakcje w systemie • Diagramy przebiegów mogą służyć do dodawania szczegółowej informacji do przypadków użycia

34. Przypadek użycia - wypożyczenie Obsługa wypożyczania

35. Przypadki użycia biblioteki Obsługa wypożyczania Czytelnik Zarządzanie użytkownikami Personel biblioteki Dostawa Obsługa katalogu

36. Składnik: Składnik biblioteki Zarządzanie katalogiem Książki: Katalog Katalogujący: Personel biblioteki Sprzedawca książek Nowy Nabądź Kataloguj składnik Usuń Usuń składnik z katalogu

37. Czynniki organizacyjne i społeczne • Systemy komputerowe istnieją w otoczeniu organizacyjnym i społecznym. To może wpływać lub wręcz zdominować wymagania systemowe • Czynniki organizacyjne i społeczne oddziałują nie na jeden, ale na wszystkie punkty widzenia • Analityk powinien wyczuwać takie czynniki, ale na razie nie istnieje systematyczna metoda ich opisu

38. Przykład • Zastanówmy się nad systemem, który powinien pozwalać wyższej kadrze zarządzającej na dostęp do informacji z pominięciem średniej kadry • Status menedżerów. Menedżerowie mogą myśleć, że są zbyt ważni, ,by używać klawiatury. To może ograniczać interfejs • Zadania menedżerów. Menedżerowie mogą nie mieć wystarczająco dużo czasu, żeby nauczyć się obsługiwać system • Opór organizacyjny. Średni menedżerowie mogą celowo podawać mylące lub niekompletne informacje, aby nie okazało się, że ich znaczenie w firmie maleje

39. Etnografia • Socjologowie spędzają dużo czasu obserwując jak ludzie rzeczywiście pracują • Ludzie nie muszą wyjaśniać jak pracują • Mogą być zaobserwowane czynniki społeczne i organizacyjne • Studia etnograficzne zazwyczaj pokazują, że organizacja pracy jest bardziej skomplikowana niż modele systemu

40. Szczegółowa etnografia • Powstała podczas informatyzacji systemu kontroli lotów • Łączy etnografię i prototypowanie • Tworzenie prototypów prowadzi do powstania pytań na które odpowiada etnografia • Problemem etnografii jest to, że obserwuje ona istniejące działania, które mogą mieć podstawy historyczne nie istotne w chwili obecnej

41. Etnografia i prototypowanie Analiza etnograficzna Narady Szczegółowa etnografia Ocena prototypu Ogólne tworzenie systemu Prototypowanie systemu

42. Zakres etnografii • Wymagania opisują jak ludzie pracują, zamiast definiować jak ludzie powinni pracować • Wymagania są wydobywane z zakresu pracy i obowiązków pracujących ludzi

43. Zatwierdzanie wymagań • Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik • Błędy w wymaganiach kosztują tak dużo, że warto te wymagania zatwierdzać • Poprawianie błędów w wymaganiach może kosztować sto razy więcej niż poprawianie błędów w implementacji

44. Sprawdzenia wymagań • Ważność. Czy system rzeczywiście dostarcza funkcji, które najlepiej spełniają potrzeby użytkownika? • Spójność. Czy wymagania nie są sprzeczne? • Kompletność. Czy są wszystkie wymagania? • Realność. Czy można zaimplementować wszystkie wymagania? • Weryfikowalność. Czy można je zweryfikować?

45. Techniki zatwierdzania wymagań • Przeglądy wymagań • Systematyczne analizy wymagań • Prototypowanie • Przedstawianie klientom działającego modelu systemu • Generowanie testów • Tworzenie testów dla sprawdzenia czy wymagania są weryfikowalne • Automatyczne sprawdzanie niesprzeczności • Sprawdzanie niesprzeczności wymagań wyrażonych w strukturalnej lub formalnej notacji

46. Przeglądy wymagań • Powinny odbywać się regularnie dopóki formułowane są nowe wymagania • Powinny być wykonywane przez zespół składający się z pracowników obu stron • Mogą być formalne (udokumentowane) lub nieformalne. Dobra komunikacja między twórcami, klientami i użytkownikami daje dobre efekty i pozwala na identyfikację problemów we wczesnych fazach

47. Lista sprawdzeń dla wymagania • Weryfikowalność. Czy wymaganie można praktycznie sprawdzić? • Zrozumiałość. Czy wymaganie jest zrozumiałe? • Pochodzenie. Czy wiadomo skąd pochodzi wymaganie? • Giętkość. Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe.

48. Automatyczne sprawdzanie niesprzeczności Raporty o sprzecznych wymaganiach Wymagania w języku formalnym Generator raportów Kompilator Baza danych wymagań

49. Zarządzanie wymaganiami • Zarządzanie wymaganiami to proces zarządzania zmianami wymagań podczas zbierania wymagań i tworzenia systemu • Wymagania są praktycznie zawsze niekompletne i sprzeczne • Nowe wymagania pojawiają się podczas trwania przedsięwzięcia ze względu na zmiany w otoczeniu i lepsze zrozumienie systemu • Różne punkty widzenia mają różne i często sprzeczne wymagania

50. Zmiany wymagań • Ważność wymagań zależy od punktu widzenia • Klienci systemu mogą wyrażać wymagania z perspektywy biznesowej co może być sprzeczne z wymaganiami użytkowników końcowych • Otoczenie biznesowe i techniczne zmienia się w trakcie trwania przedsięwzięcia