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ściOkreś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ń KlasyfikacjaUsuwanie 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 widzeniaUczestnicy 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 bankomatuPrzykł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 bankomatuKlienci 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 danychPunkt 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 widzeniaNaturalny 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 metodachSzeroko 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 StrukturalizacjaDokumentacja punktów widzenia Przyporządkowanie punktów widzenia do systemu

20 Model procesu VORD Identyfikacja punktów widzeniaZnajdowanie 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 VORDSzablon 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 widzeniaDziennik 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 Właściciel konta Obcy klient Kasa bankuLista usług Wypłata gotówki Diagnostyka Pytanie o saldo Dodanie gotówki Zamówienie czeków Dodanie papieru Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków

24 Dane wejściowe i sterująceWŁAŚCICIEL KONTA Dane sterujące Dane wejściowe Rozpocznij transakcję Informacje z karty Anuluj transakcję PIN Zakończ transakcję Żądana kwota Wybór usługi Komunikat

25 Hierarchia punktów widzeniaWszystkie 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ówkiOdnoś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 scenariuszaNormalny 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 Zwróć kartę Zły PIN 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ówW 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życzenieObsługa wypożyczania

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

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

37 Czynniki organizacyjne i społeczneSystemy 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 etnografiaPowstał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 prototypowanieAnaliza 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 wymaganiaWeryfikowalność. 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ściWymagania w języku formalnym Raporty o sprzecznych wymaganiach Generator raportów Kompilator Baza danych wymagań

49 Zarządzanie wymaganiamiZarzą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 widzeniaKlienci 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

51 Ewolucja wymagań Wstępne Zmienione zrozumienie zrozumienie problemuwymagania Zmienione wymagania Czas

52 Wymagania stałe i zmienneWymagania stałe to względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu Wymagania zmienne to wymagania, ,które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkownika

53 Klasyfikacja wymagań zmiennychWymagania środowiskowe Wymagania, które zmieniają się na skutek zmian środowiska Wymagania pojawiające się Wymagania pojawiające się podczas lepszego zrozumienia powstającego systemu Wymagania wynikowe Wymagania, które wynikają z wdrożenia systemu komputerowego Wymagania zgodności Wymagania, które zależą od konkretnych systemów lub procesów wewnątrz firmy

54 Planowanie zarządzania wymaganiamiPodczas zarządzania wymaganiami musisz zaplanować: Oznakowanie wymagań Jak wymagania są unikatowo oznakowane Proces zarządzania zmianami Proces, który następuje po zmianie wymagania Strategia śledzenia pochodzenia Ilość informacji o zależnościach pomiędzy wymaganiami, która jest utrzymywana Użycie narzędzi CASE Narzędzie wspierające zarządzanie wymaganiami

55 Śledzenie Śledzenie opisuje związki pomiędzy wymaganiami, ich pochodzeniem i projektem systemu Informacje o pochodzeniu Wiązania pomiędzy uczestnikami i wymaganiami wraz z uzasadnieniem tych wymagań Informacje o uzależnieniu wymagań Wiązania pomiędzy zależnymi wymaganiami Informacje o uzależnieniu projektu Wiązania pomiędzy wymaganiami a częściami projektu

56 Macierz zależności

57 Narzędzia CASE Przechowywanie wymagań Zarządzanie zmianamiWymagania należy gromadzić w zabezpieczonej i administrowalnej składnicy danych Zarządzanie zmianami Proces zarządzania zmianami to proces przepływu pracy, którego stany mogą być precyzyjnie zdefiniowane przez co można go zautomatyzować Zarządzanie zależnościami Automatyczne ustalanie zależności pomiędzy wymaganiami a innymi elementami systemu

58 Zarządzanie zmianami wymagańNależy stosować do wszystkich postulowanych zmian wymagań Główne kroki Analiza problemu. Rozpoznanie problemu z wymaganiem i propozycja zmian Analiza zmiany i ocena kosztów. Szacuje efekty wprowadzenia zmiany Implementacja zmiany. Modyfikuje dokumentację wymagań i inne dokumentacje jeśli zachodzi taka potrzeba

59 Zarządzanie zmianami wymagańRozpoznany problem Skorygowane wymaganie Analiza problemu i specyfikacja zmiany Analiza zmiany i ocena kosztów Implementacja zmiany

60 Główne tezy Proces inżynierii wymagań obejmuje studium wykonalności, określanie i analizowanie wymagań, specyfikowanie i zarządzanie wymaganiami Analiza wymagań to proces iteracyjny obejmujący zrozumienie dziedziny, zbieranie wymagań, klasyfikowanie, nadawanie priorytetów, strukturalizację i zatwierdzanie Systemy mogą mięć różnych użytkowników z różnymi wymaganiami

61 Główne tezy czynniki społeczne i organizacyjne mają wpływ na wymagania systemowe Zatwierdzanie wymagań to proces sprawdzania wymagań pod względem ważności, niesprzeczności, kompletności, realności i zdatności do zatwierdzania Zmiany gospodarcze prowadzą do zmian wymagań Zarządzanie wymaganiami obejmuje planowanie i zarządzanie zmianami