Inżynieria Oprogramowania 3. Inżynieria wymagań

Prezentacja na temat: "Inżynieria Oprogramowania 3. Inżynieria wymagań"— Zapis prezentacji:

1 Inżynieria Oprogramowania 3. Inżynieria wymagań
26/03/2017 Inżynieria Oprogramowania 3. Inżynieria wymagań Leszek J Chmielewski Wydział Zastosowań Informatyki i Matematyki SGGW lchmiel.pl

2 Literatura Ian Sommerville, Inżynieria oprogramowania - rozdział 6

3 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

4 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

5 Wymagania... 1/3 W wymaganiach stawianych systemowi oprogramowania
ustala się co system powinien robić definiuje się ograniczenia działania i implementacji Wymagania funkcjonalne charakterystyki usług, które system ma oferować albo opisy sposobu przeprowadzania obliczeń Wymagania niefunkcjonalne wymagania produktowe: ograniczają system wymagania procesu: dotyczą procesu tworzenia wymagania zewnętrzne: zwykle są powiązane z pojawiającymi się właściwościami systemu, a zatem stosują się do systemu jako całości

6 Wymagania... 2/3 Wymagania użytkownika Wymagania systemowe
przeznaczone dla osób, które mają używać i zaopatrywać się w system język naturalny, tabele i diagramy, zrozumiałe Wymagania systemowe precyzyjne i jednoznaczne można je zapisać w języku strukturalnym; może to być strukturalna postać języka naturalnego, język podobny do języka oprogramowania wysokiego poziomu lub specjalny język do specyfikowania wymagań

7 Wymagania... 3/3 Dokumentacja wymagań
jest uzgodnionym zapisem wymagań systemowych należy nadać jej odpowiednią strukturę, aby mogła być używana zarówno przez klientów systemu, jak i twórców oprogramowania

8 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

9 Proces inżynierii wymagań
Wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych Cztery ogólne czynności wysokiego poziomu: studium wykonalności określanie i analizowanie w. specyfikowanie i dokumentowanie w. zatwierdzanie w.

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

11 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

12 Studium wykonalności Wynik: raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu S.W.: krótkie, skumulowane opracowanie Odpowiedzi: Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?

13 Przykładowe pytania w S.W.
Jak firma poradziłaby sobie, jeśli system nie byłby zaimplementowany? Jakie problemy występują w obecnie przyjętych procesach i jak nowy system ma pomóc w ich eliminacji? Jaki byłby bezpośredni wkład systemu w osiąganie celów gospodarczych? Czy można przekazywać informacje do i z innych systemów przedsiębiorstwa? Czy system wymaga technologii, których wcześniej w firmie nie stosowano? Co system musi wspomagać, a czego nie musi?

14 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

15 Określanie i analizowanie wymagań
Techniczni wykonawcy oprogramowania pracują z klientem i użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować, pożądanej efektywności, ograniczeniach sprzętowych itd. W określaniu i analizowaniu wymagań mogą wziąć udział osoby z różnych stanowisk w firmie Uczestnik: każdy, kto powinien mieć wpływ na wymagania systemowe (pośredni, bezpośredni)

16 Problemy analizy wymagań
Uczestnicy często nie wiedzą, czego tak naprawdę oczekują od systemu komputerowego Uczestnicy w naturalny sposób wyrażają wymagania za pomocą własnych pojęć Różni uczestnicy stawiają różne wymagania (uwaga: oponenci, destruktorzy!) Czynniki polityczne mogą mieć wpływ na system (uwaga: wpływy w firmie!) Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest zmienne (uwaga: polityka firmy, prawo!)

17 Proces ustalania wymagań
Specyfikacja wymagań Sprawdzenie wymagań Nadawanie priorytetów Rozpoznanie dziedziny Początek procesu Dokumentacja wymagań Usuwanie sprzeczności Zbieranie wymagań Klasyfikacja

18 Czynności procesu Rozpoznanie dziedziny Zbieranie wymagań Klasyfikacja
Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań Specyfikacja Dokumentacja

19 Modelowanie systemu Określanie i analizowanie wymagań jest procesem iteracyjnym z ustawicznym przekazywaniem informacji zwrotnej między czynnościami Cykl procesu rozpoczyna się od rozpoznania dziedziny, a kończy na sprawdzeniu wymagań Stopień zrozumienia dziedziny przez analityków rośnie z każdym cyklem Aż wszyscy są zadowoleni

20 Określanie oparte na punktach widzenia
Średnie i wielkie systemy mają zwykle kilku różnych użytkowników Wielu uczestników w jakiś sposób interesuje się wymaganiami systemowymi Pomaga odkryć wszystkie funkcje systemu

21 System bankomatowy - przykład
Służy do automatycznego dokonywania operacji bankomatowych Wersje: uproszczona: dla wielu zwykłych klientów skomplikowana: dla wybranych klientów Usługi obejmują: wypłatę, wpłatę przekazywanie informacji

22 Uczestnicy systemu bankomatowego
Obecni klienci banku Przedstawiciele innych banków Dyrektorzy oddziałów banków Pracownicy obsługi klienta w oddziałach Administratorzy baz danych Osoby odpowiedzialne za bezpieczeństwo w banku Dział marketingu banku Inżynierowie pielęgnacji sprzętu i oprogramowania

23 Różne punkty widzenia Źródło lub przeznaczenie danych
Osoba mająca taki punkt widzenia użytkuje lub produkuje dane Analiza polega na rozpoznawaniu wszystkich takich punktów widzenia, danych, które są produkowane lub użytkowane, oraz przeprowadzanym przetwarzaniu Zrąb reprezentacji Osoba mająca taki punkt widzenia jest związana z konkretnym typem modelu systemu Odbiorca usług W tym wypadku punkty widzenia są zewnętrzne wobec systemu; osoby mające ten punkt widzenia korzystają z usług systemu.

24 Model zewnętrznych punktów widzenia
Reprezentanci tych 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ń Dość łatwo jest stwierdzić, czy coś jest punktem widzenia, czy nie reprezentanci punktów widzenia muszą bowiem w pewien sposób oddziaływać na system Punkty widzenia i usługi stanowią dobry sposób strukturalizacji wymagań niefunkcjonalnych każda usługa może być powiązana z wymaganiami niefunkcjonalnymi

25 Etapy metody VORD VORD: Viewpoint-Oriented Requirements Definition
Identyfikacja punktów widzenia Strukturalizacja punktów widzenia Dokumentacja punktów widzenia Przyporządkowywanie punktów widzenia do systemu

26 Etapy metody VORD c.d. Identyfikacja punktów widzenia
znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu, oraz wyszukiwanie szczególnych usług oferowanych reprezentantom konkretnych punktów widzenia Strukturalizacja punktów widzenia grupowanie podobnych punktów widzenia w hierarchie Dokumentacja punktów widzenia udoskonalanie opisu znalezionych punktów widzenia i usług Przyporządkowywanie punktów widzenia do systemu znajdowanie obiektów w projekcie obiektowym za pomocą związanej z punktami widzenia informacji o usługach

27 Szablony punktów widzenia i usług
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ć opisane za pomocą różnych notacji Punkty Lista nazw punktów widzenia, widzenia: których reprezentanci korzy- stają z usługi Wymagania Odnośnik do zbioru wymagań niefunkcjo- niefunkcjonalnych ogranicza- nalne: jących usługę Dostawca: Odnośnik do listy obiektów systemu, które oferują tę usługę Szablon do punktów widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariu- szy zdarzeń opisujących, jak system reaguje na zdarzenia w ramach tego punktu widzenia Usługi: Odnośnik do zbioru opisów usługi Podrzędne Nazwy podrzędnych PW: punktów widzenia

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

29 Przykład: Usługi przypisane do punktów widzenia
KASA BANKU WŁAŚCICIEL KONTA OBCY KLIENT Lista usług Lista usług Lista usług Wypłata gotówki Pytania o saldo Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków Wypłata gotówki Pytania o saldo Diagnostyka Dodanie gotówki Dodanie papieru Wysłanie komunikatu

30 Dane wejściowe i sterujące związane z punktami widzenia
WŁAŚCICIEL KONTA Dane sterujące Dane wejściowe Rozpocznij transakcje Informacje z karty Anuluj transakcje PIN Zakończ transakcje Żądana kwota Wybór usługi Komunikat

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

32 Opis punktu widzenia klienta i opis usługi wypłaty 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 PW: Właściciel konta Odnośnik: Wypłata gotówki Uzasadnienie: Celem jest ulepszenie obsługi klienta i zmniejszenie liczby dokumentów papierkowych 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 PW: Klient Wymagania niefunkcjonalne: Wypłacić gotówkę najpóźniej po 1 minucie od potwierdzenia kwoty Dostawca: Wypełnić później

33 Scenariusze Ludzie zwykle wolą przykłady wzięte z życia niż abstrakcyjne opisy Inżynierowie wymagań mogą skorzystać z informacji zebranych w trakcie dyskusji do formułowania rzeczywistych wymagań systemowych Scenariusze są szczególnie użyteczne przy uszczegóławianiu opisu wymagań Są opisami przykładowych sesji interakcyjnych Każdy scenariusz obejmuje jedną lub najwyżej kilka możliwych interakcji

34 Cechy 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

35 Scenariusze zdarzeń Scenariusze zdarzeń są używane w VORD (Viewpoint-Oriented Requirements Definition) do dokumentowania zachowania systemu, gdy zajdą konkretne zdarzenia Każde odrębne zdarzenie w interakcji, takie jak wsunięcie karty do bankomatu albo wybranie usługi, może być udokumentowane za pomocą oddzielnego scenariusza zdarzenia Obejmują opis przepływu danych, akcji systemu i wyjątków, które mogą się pojawić Przykład: schemat ze scenariuszem zdarzenia „Zacznij transakcję”

36 Konwencje dla diagramów scenariuszy zdarzeń
Wsunięto kartę Dane odbierane i przekazywane do reprezentantów punktów widzenia: elipsy Informacja sterująca wchodzi w prostokąt od góry, a opuszcza z dołu Dane opuszczają prostokąty z prawej strony Jeśli dane nie są otoczone elipsą, to są to dane wewnętrzne dla systemu Wyjątki są pokazywane na dole prostokątów. Jeśli tych wyjątków jest kilka, to oznacza się je prostokątem Nazwa następnego zdarzenia oczekiwanego po zakończeniu scenariusza: w cieniowanym prostokącie Karta ważna Karta Poproś o PIN Użytkownik OK PIN Numer konta PIN Sprawdź użytkownika Numer konta Czas przekroczony Wybierz usługę Zły PIN Zwróć kartę Ponownie wprowadzić Karta nieważna Zwróć kartę Zły PIN Zwróć kartę Karta skradziona Zatrzymaj kartę

37 Przypadki użycia Przypadek użycia jest metodą opartą na scenariuszach, służącą do określania wymagań Po raz pierwszy użyto jej w metodzie Objectory (Jacobson i inni, 1993). Obecnie stała się podstawowym elementem notacji UML do opisywania obiektowych modeli systemu W najprostszej postaci w przypadku użycia definiuje się aktorów biorących udział w interakcji i wskazuje typ tej interakcji

38 Przypadek użycia: Wypożyczanie
Obsługa wypożyczania

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

40 Diagramy przebiegu Diagramy przebiegu mogą służyć do dodawania szczegółowej informacji do przypadku użycia Zdefiniowane w UML Przedstawia się aktorów biorących udział w interakcji obiekty w systemie, z którymi komunikują się aktorzy operacje powiązane z tymi obiektami Rysunek: przykład takiego diagramu - interakcja obejmującą nabywanie i katalogowanie książek w bibliotece

41 Diagram przebiegu zarządzania katalogiem
Składnik: Składnik biblioteki Książki: Katalog Sprzedawca książek Katalogujący: Personel biblioteki : Nowy Nabądź Kataloguj składnik Usuń Usuń składnik z katalogu

42 Opis przykładu Pokazano dwa obiekty klas Składnik biblioteki i Katalog, które biorą udział w przypadku użycia Zarządzanie katalogiem Akcje są wykonywane w kolejności z góry na dół, a etykietki na strzałkach między aktorami i obiektami są nazwami operacji Po zakupie książki, wykonuje się zatem operację Nowy na katalogu Nabądź i na Składniku. Gdy książka jest już dostępna, na Składniku wykonuje się operację Kataloguj składnik.

43 Etnografia To metoda obserwacji, która może służyć do rozpoznawania wymagań społecznych i organizacyjnych Analityk pogrąża się w środowisku pracy, w którym system będzie używany Obserwuje codzienną pracę i odnotowuje podstawowe zadania wykonywane przez pracowników Zaleta: pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie

44 Skoncentrowana etnografia
Rozwinięta w projekcie badającym proces kontroli lotów Łączy etnografię z prototypowaniem Prototypowanie pomaga w pokierowaniu etnografią przez identyfikowanie problemów i pytań, które potem mogą być rozważone przez etnografa Wada etnografii: bada istniejące zachowania, które mogą mieć historyczne podłoże, które nie jest już odpowiednie

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

46 Cele etnografii Opis wymagań wynikających z rzeczywistego sposobu pracy osób, a nie ze sposobu zalecanego formalne definicje procesów Opis wymagań, które wynikają z kooperacji i świadomości czynności innych osób

47 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

48 Zatwierdzanie wymagań
Zatwierdzanie wymagań polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik Ponieważ błędy w dokumentacji wymagań mogą przyczynić się do poważnych kosztów powtarzania prac po sukcesywnym wykrywaniu tych błędów w trakcie tworzenia lub nawet po rozpoczęciu korzystania z systemu

49 Sprawdzenie wymagań Sprawdzenie ważności. Użytkownik może być przekonany, że system powinien spełniać pewne funkcje. Sprawdzenie niesprzeczności. Wymagania zapisane w dokumentacji nie powinny być sprzeczne. Sprawdzenie kompletności. Dokumentacja wymagań powinna zawierać wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia zamierzone przez użytkownika systemu. Sprawdzenie realności. Znając obecną wiedze techniczną, należy sprawdzić, czy wymagania mogą być naprawę zaimplementowane. Możliwość weryfikacji. Aby uniknąć późniejszych sporów między klientem a zleceniobiorcą, wymagania systemowe zawsze powinny być napisane tak, aby można było je weryfikować.

50 Modele zatwierdzania wymagań
Przeglądy wymagań Zespół recenzentów systematycznie analizuje wymagania. Prototypowanie W tym podejściu do zatwierdzania przedstawia się użytkownikom i klientom wykonywalny model systemu. Generowanie testów Idealnie byłoby, aby wymagania dało się testować. Zautomatyzowane sprawdzanie sprzeczności Jeśli wymagania wyrażono w modelu systemu za pomocą strukturalnej lub formalnej notacji, to narzędzia CASE mogą sprawdzić niesprzeczność systemu.

51 Przeglądy wymagań Przegląd wymagań jest ręcznym procesem, w którym wielu czytelników, zarówno ze strony klienta, jak i zleceniobiorcy, sprawdza dokumentację wymagań w poszukiwaniu anomalii i pominięć. Można też zorganizować go w większej skali z wieloma uczestnikami sprawdzającymi różne części dokumentacji. Przeglądy wymagań mogą być formalne albo nieformalne. Przeglądy nieformalne polegają na tym, że zleceniobiorcy rozmawiają o wymaganiach z największą liczbą uczestników, jak to jest możliwe.

52 Sprawdzenie wymagań Możliwość weryfikacji. Czy wymaganie wyrażono tak, aby można je praktycznie sprawdzić? Zrozumiałość. Czy klienci i użytkownicy systemu właściwie zrozumieli wymaganie? Pochodzenie. Czy jawnie zaznaczono źródło, z którego pochodzi wymaganie? Giętkość. Czy wymaganie może być zmienione bez znaczącego wpływu na inne wymagania systemowe?

53 Zautomatyzowane sprawdzanie niesprzeczności wymagań
Wymagania zapisane w języku formalnym Raport o błędach w wymaganiach Procesor wymagań Analizator wymagań Baza danych wymagań

54 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

55 Zarządzanie wymaganiami
Wymagania stawiane wielkim systemom oprogramowania zawsze się zmieniają Jedną z przyczyn takiej sytuacji jest to, że systemy te są zwykle budowane po to, aby rozwiązać problemy „złośliwe” W trakcie procesu tworzenia oprogramowania stopień zrozumienia problemu stale się zmienia Zmiany te mają zwrotny wpływ na wymagania

56 Wymagania stawiane wielkim systemom
Z wielkich systemów korzysta zwykle bardzo urozmaicona społeczność użytkowników. Różni użytkownicy stawiają różne wymagania i przypisuje im inne priorytety i może to prowadzić do zmiany wymagań. Ludzie, którzy płacą za system, i jego użytkownicy to zwykle różni klienci. Klienci systemu formułują wymagania wynikające z ograniczeń organizacyjnych i budżetowych. Te wymagania mogą być w konflikcie z wymaganiami użytkowników. Otoczenie technologiczne i gospodarcze systemu zmienia się. Te zmiany muszą być odzwierciedlone w samym systemie.

57 Ewolucja wymagań Zmienione Wstępne rozumienie zrozumienie problemu
wymagania Wstępne wymagania Czas

58 Wymagania stałe i zmienne
Wymagania stałe to względnie stabilne wymagania, które wynikają z podstawowej działalności firmy i bezpośrednio odnoszą się do dziedziny systemu w szpitalu zawsze będą wymagania dotyczące pacjentów, lekarzy, pielęgniarek, terapii, itp. Wymagania zmienne to wymagania, które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkowania np. wymagania, które wynikają z polityki zdrowotnej rządu

59 Klasyfikacja wymagań zmiennych
Wymagania zmieniające się Zmieniają się na skutek zmian środowiska, w którym działa firma Wymagania pojawiające się (emerging) Pojawiają się w trakcie procesu tworzenia 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

60 Planowanie zarządzania wymaganiami
W trakcie tej fazy zarządzania wymaganiami należy podjąć decyzje dotyczące następujących zagadnień: 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. Proces zarządzania zmianami Zbiór czynności szacowania wpływu i kosztu zmian. Strategie śledzenia pochodzenia Strategie definiują zależności między wymaganiami i projektem systemu. Użycie narzędzi CASE Zarządzanie wymaganiami polega na przetwarzaniu ogromnych ilości informacji o wymaganiach.

61 Pochodzenie Możliwość śledzenia pochodzenia jest ogólną cechą specyfikacji wymagań Trzy typy informacji o pochodzeniu, które warto gromadzić Informacje o uczestnikach, którzy zaproponowali dane wymagania, wraz z ich uzasadnieniem Informacje o zależnościach wymagań wiążą wzajemnie zależne wymagania Informacje o uzależnieniu projektu wiążą wymagania z modułami projektu, które implementują te wymagania

62 Macierz zależności: Uzależnione, Relacja
Id wymagań 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 U R

63 Narzędzia CASE w zarządzaniu w.
Przechowywania wymagań Wymagania należy gromadzić w zabezpieczonej i administrowanej składnicy danych, która jest dostępna dla wszystkich biorących udział w procesie inżynierii wymagań Zarządzania zmianami Proces zarządzania zmianami jest znacznie prostszy, gdy aktywnie korzysta się ze wspomagania narzędzi Zarządzania zależnościami Wspomaganie narzędzi przy śledzeniu zależności umożliwia wykrywanie powiązanych wymagań

64 Zarządzanie zmianami wymagań
Zarządzanie zmianami wymagań należy zastosować do wszystkich postulowanych zmian wymagań. Trzy podstawowe kroki: Analiza problemu i specyfikacja zmiany proces rozpoczyna się od rozpoznania problemu z wymaganiem lub od propozycji zmiany Analiza zmiany i ocena kosztów korzystając z informacji o uzależnieniu i ogólnej wiedzy o wymaganiach systemowych ocenia się wpływ proponowanej zmiany Implementacja zmiany modyfikuje się dokumentacje wymagań oraz, jeśli zachodzi taka potrzeba, również projekt i implementację systemu

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

66 Plan Inżynieria wymagań Powtórka o wymaganiach Studium wykonalności
Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami Podsumowanie

67 Podsumowanie 1/4 Proces inżynierii wymagań:
studium wykonalności określanie, analizowanie, sprawdzanie, specyfikowanie wymagań zatwierdzanie wymagań zarządzanie wymaganiami Analizowanie wymagań to proces iteracyjny: rozpoznanie dziedziny zbieranie wymagań klasyfikację, strukturalizację nadawanie priorytetów sprawdzanie i zatwierdzanie

68 Podsumowanie 2/4 Różni użytkownicy systemu mogą stawiać różne wymagania. Wszystkie złożone systemy należy więc analizować z kilku punktów widzenia odpowiadają źródłom lub przeznaczeniom danych, różnym reprezentacjom systemu albo bytom spoza systemu, które korzystają z jego usług Pomagają uporządkować strukturę: scenariusze  zdarzenia przypadki użycia  wymagania

69 Podsumowanie 3/4 Reprezentacje:
punkty widzenia i usługi przedstawia się w formularzach scenariusze i przypadki użycia przedstawia się także na diagramach diagram scenariuszy (struktura) diagram przebiegu (czas) wszystko to można zapisać (narysować) w UML Jedną z technik wykrywania scenariuszy, przypadków, a zatem i wymagań jest etnografia

70 Podsumowanie 4/4 Wymaganiami i ich zmianami trzeba zarządzać
powiązania wymagań, według pochodzenia i zależności między nimi Czynniki społeczne i organizacyjne mają silny wpływ na wymagania systemowe i od nich głównie zależy, czy system będzie faktycznie używany, czy nie.

71 Dziękuję