Proces inynierii wymaga l Suy do okrelania analizowania

Proces inżynierii wymagań l Służy do określania, analizowania i zatwierdzania wymagań stawianych systemowi. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 1

Cele l l Rozumieć podstawowe czynności inżynierii wymagań i związki między nimi. Znać kilka metod określania i analizowania wymagań. Rozumieć znaczenie zatwierdzania wymagań oraz to, jak w tym procesie używa się przeglądów wymagań. Rozumieć, dlaczego zarządzanie wymaganiami jest niezbędne oraz to, jak wspomaga ono inne czynności inżynierii wymagań. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 2

©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 3

Zawartość l l Studium wykonalności Określanie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 4

Proces inżynierii wymagań l l Obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych. Istnieją cztery ogólne czynności wysokiego poziomu w procesie inżynierii wymagań: • studium wykonalności • określenie i analizowanie wymagań • specyfikowanie i dokumentowanie wymagań • zatwierdzanie wymagań ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 5

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ń ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 6

Studium wykonalności l l Wynikiem tego studium powinien być raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu. Studium wykonalności to krótkie, skumulowane opracowanie, w którym staramy się odpowiedzieć na kilka pytań: • 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? ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 7

Przeprowadzanie studium wykonalności l l Obejmuje określenie i zebranie informacji oraz pisanie raportu Kilka przykładów pytań: • 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? ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 8

Określanie i analizowanie wymagań l l l Po wstępnych studiach wykonalności następna fazą inżynierii wymagań jest określanie i analizowanie wymagań. W trakcie tej czynności techniczni budowniczowie 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. Pojęcie uczestnik odnosi się do każdego, kto powinien mieć pewien pośredni lub bezpośredni wpływ na wymagania systemowe. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 9

Problemy analizy wymagań l l l Uczestnicy często nie wiedzą, czego tak naprawdę oczekują od systemu komputerowego. Uczestnicy systemu w naturalny sposób wyrażają wymagania za pomocą własnych pojęć. Różni uczestnicy mogą stawiać różne wymagania. Czynniki polityczne mogą mieć wpływ na system Środowisko ekonomiczne i gospodarcze, w którym prowadzi się analizę, jest dynamiczne. Nieuchronnie zmienia się w trakcie procesu analizy. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 10

Proces określania i analizowania wymagań Specyfikacja wymagań Sprawdzenie wymagań Początek procesu Nadawanie priorytetów Rozpoznanie dziedziny Dokumentacja wymagań Usuwanie sprzeczności Zbieranie wymagań Klasyfikacja ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 11

Czynności procesu l l l Rozpoznanie dziedziny Zbieranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 12

Modelowanie systemu l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 13

Określanie oparte na punktach widzenia l l Średnie i wielkie systemy maja zwykle kilku różnych użytkowników. Wielu uczestników w jakiś sposób interesuje się wymaganiami systemowymi. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 14

System bankomatowy - przykład l l l Służy do automatycznego dokonywania operacji bankomatowych. W uproszczonej wersji służy wielu zwykłym klientom i oferuje bardziej skomplikowane usługi wybranym klientom. Usługi obejmują: wypłatę, wpłatę, przekazywanie informacji. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 15

Uczestnicy systemu bankomatowego l l l l 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 ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 16

Różne punkty widzenia l l l Źródło lub przeznaczenie danych • Osoba mająca taki punkt widzenia użytkuje lub produkuje dane. W tym wypadku 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 17

Model zewnętrznych punktów widzenia l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 18

Etapy metody VORD Identyfikacja punktów widzenia ©Ian Sommerville 2000 Strukturalizacja punktów widzenia Dokumentacja punktów widzenia Inżynieria oprogramowania, Rozdział 6 Przyporządkowywanie punktów widzenia do systemu Slide 20

Etapy metody VORD c. d. l l Identyfikacja punktów widzenia • Znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu, oraz na wyszukiwaniu szczególnych usług oferowanych reprezentantom konkretnych punktów widzenia. Strukturalizacja punktów widzenia • Polega na grupowaniu 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 21

Szablony formularzy i punktów widzenia Szablon do usług Szablon do punktów widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariuszy 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 ©Ian Sommerville 2000 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 korzystają z usługi Wymagania Odnośnik do zbioru wymagań niefunkcjo- niefunkcjonalnych ograniczanalne: jących usługę Dostawca: Odnośnik do listy obiektów systemu, które oferują tę usługę Inżynieria oprogramowania, Rozdział 6 Slide 22

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

Informacja o usługach przypisanych do punktów widzenia WŁAŚCICIEL KONTA 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 ©Ian Sommerville 2000 OBCY KLIENT Lista usług Wypłata gotówki Pytania o saldo Inżynieria oprogramowania, Rozdział 6 KASA BANKU Lista usług Diagnostyka Dodanie gotówki Dodanie papieru Wysłanie komunikatu Slide 24

Dane wejściowe i dane sterujące związane z punktami widzenia WŁAŚCICIEL KONTA Dane sterujące Dane wejściowe Rozpocznij transakcje Informacje z karty ©Ian Sommerville 2000 Anuluj transakcje PIN Zakończ transakcje Żądana kwota Wybór usługi Komunikat Inżynieria oprogramowania, Rozdział 6 Slide 25

Hierarchia punktów widzenia Wszystkie PW Usługi Personel banku Klient Pytanie o saldo Wypłata gotówki Kasa Menedżer Usługi Zamówienie czeków Wysyłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków ©Ian Sommerville 2000 Właściciel konta Klient obcy Inżynieria oprogramowania, Rozdział 6 Slide 26 Inżynier

Opis punktu widzenia klienta i opis usługi wypłaty gotówki Odnośnik: Klient Atrybuty: Numer konta PIN Zdarzenia: Usługi: Zacznij transakcję Wybór usługi Anuluj transakcję Zakończ transakcję Wypłata gotówki Pytanie o saldo Podrzędne PW: Właściciel konta ©Ian Sommerville 2000 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 Inżynieria oprogramowania, Rozdział 6 Slide 27

Scenariusze l l l 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 przeglądowego opisu wymagań. Są opisami przykładowych sesji interakcyjnych. Każdy scenariusz obejmuje jedną lub najwyżej kilka możliwych interakcji. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 28

Cechy scenariusza l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 29

Scenariusze zdarzeń l l Scenariusze zdarzeń są używane w VORD 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ć. Aby zapoznać się z przykładem scenariusza zdarzenia rozważmy schemat, na którym przedstawiono scenariusz zdarzenia „Zacznij transakcję”. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 30

Konsekwencje dotyczące diagramów scenariuszy zdarzeń l l l Dane odbierane i przekazywane do reprezentantów punktów widzenia są przedstawione w postaci elips. Informacja sterująca wchodzi w każdy prostokąt od góry, a opuszcza z dołu. . Dane opuszczają prostokąty z prawej strony. Jeśli te dane nie są otoczone elipsą, oznacza to, że są 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 jest przedstawiana w cieniowanym prostokącie. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 31

Opis wyjątków l l Część metody nie zawiera opisu wyjątków W tym przykładzie: • Przekroczenie limitu czasu. Klient może nie wprowadzić PIN przed upływem wyznaczonego czasu. Karta jest zwracana. • Karta nieważna. Nie rozpoznano karty. Karta jest zwracana. • Karta ukradziona. Rozpoznano kartę jako skradzioną. Karta jest zatrzymywana. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 32

Przypadki użycia l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 33

Przypadek użycia Wypożyczanie Obsługa wypożyczania ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 34

Przypadki użycia biblioteki Czytelnik Obsługa wypożyczania Zarządzanie użytkownikami Personel biblioteki Dostawa ©Ian Sommerville 2000 Obsługa katalogu c Inżynieria oprogramowania, Rozdział 6 Slide 35

Diagramy przebiegu l l l Zdefiniowane w UML diagramy przebiegu mogą służyć do dodawania szczegółowej informacji do przypadku użycia. Na takich diagramach przedstawia się aktorów biorących udział w interakcji, obiektyw systemie, z którymi komunikują się aktorzy, oraz operacje powiązane z tymi obiektami. Rysunek zawiera przykład takiego diagramuinterakcję obejmującą nabywanie i katalogowanie książek w bibliotece. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 36

Diagram przebiegu zarządzania katalogiem Składnik: Składnik biblioteki Książki: Katalogujący: Personel biblioteki Nowy Sprzedawca książek : Nabądź Kataloguj składnik Usuń składnik z katalogu ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 37

Przykłady l l l Na rysunku 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 38

Etnografia l l 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 etnografii jest to, że pomaga odkrywać niejawne wymagania systemowe odzwierciedlające rzeczywiste, a nie formalne procesy, w których biorą udział ludzie. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 39

Skoncentrowana etnografia l l 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. Wadą etnografii jest to, że bada ona istniejące zachowania, które mogą mieć jakieś historyczne podłoże, które nie jest już odpowiednie. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 40

Etnografia i prototypowanie Analiza etnograficzna Narady Szczegółowa etnografia Ocena prototypu Ogólne tworzenie systemu ©Ian Sommerville 2000 Prototypowanie systemu Inżynieria oprogramowania, Rozdział 6 Slide 41

Cele etnografii l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 42

Zatwierdzanie wymagań l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 43

Sprawdzenie wymagań l l l 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ć. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 44

Modele zatwierdzania wymagań l Przeglądy wymagań • l Prototypowanie • l W tym podejściu do zatwierdzania przedstawia się użytkownikom i klientom wykonywalny model systemu. Generowanie testów • l Zespół recenzentów systematycznie analizuje wymagania. 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 45

Przeglądy wymagań l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 46

Sprawdzenie wymagań l l 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? ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 47

Zautomatyzowane sprawdzanie niesprzeczności wymagań Wymagania zapisane w języku formalnym Raport o błędach w wymaganiach Procesor wymagań Analizator wymagań Baza danych wymagań ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 48

Zarządzanie wymaganiami l l 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, a zmiany te mają zwrotny wpływ na wymagania. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 49

Wymagania stawiane wielkim systemom l l l 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 50

Ewolucja wymagań Wstępne zrozumienie problemu Zmienione wymagania Wstępne wymagania Czas ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 51

Wymagania stałe i zmienne l l 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. Takimi wymaganiami są na przykład wymagania, które wynikają z polityki zdrowotnej rządu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 52

Klasyfikacja wymagań zmiennych l l 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żą mów lub procesów gospodarczych wewnątrz firmy. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 53

Planowanie zarządzania wymaganiami l 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 » Jest to zbiór czynności szacowania wpływu i kosztu zmian. • Strategia śledzenia pochodzenia » Te strategie definiują zależności między wymaganiami i projektem systemu, które należy odnotowywać. • Użycie narzędzi CASE » Zarządzanie wymaganiami polega na przetwarzaniu ogromnych ilości informacji o wymaganiach. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 54

Pochodzenie l l 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 uzależnieniu wymagań wiążą w dokumentacji wymagań te wymagania, które od siebie zależą. Informacje o uzależnieniu projektu wiążą wymagania z modułami projektu, które implementują te wymagania. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 55

Macierz zależności Id wymagań 1. 1 1. 2 1. 3 U R 1. 2 1. 3 2. 1 2. 2 U R 2. 3 3. 1 R U R 2. 1 R U U 2. 2 2. 3 U R U 3. 1 R 3. 2 ©Ian Sommerville 2000 3. 2 R Inżynieria oprogramowania, Rozdział 6 Slide 56

Korzystanie z narzędzi CASE w zarządzaniu wymaganiami l l l 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ń. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 57

Zarządzanie zmianami wymagań l l 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 czasem od konkretnej 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 implementacje systemu. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 58

Zarządzanie zmianami wymagań Skorygowane wymagania Rozpoznany problem Analiza problemu i specyfikacja zmiany ©Ian Sommerville 2000 Analiza zmiany i ocena kosztów Implementacja zmiany Inżynieria oprogramowania, Rozdział 6 Slide 59

Główne tezy l l Proces inżynierii wymagań obejmuje studium wykonalności, określanie i analizowanie wymagań, specyfikowanie wymagań, zatwierdzanie wymagań oraz zarządzanie wymaganiami. Analizowanie wymagań to proces iteracyjny, który obejmuje rozpoznanie dziedziny, zbieranie wymagań, klasyfikację, strukturalizację, nadawanie priorytetów i zatwierdzanie. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 60

Główne tezy l l 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. Punkty widzenia odpowiadają źródłom lub przeznaczeniom danych, różnym reprezentacjom systemu albo bytom spoza systemu, które korzystają z jego usług. 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. ©Ian Sommerville 2000 Inżynieria oprogramowania, Rozdział 6 Slide 61