020 ANALIZA WYMAGAŃ Prof. dr hab. Marek Wisła
Wymagania Wymaganie (ang. requirement) - pojęcie wymagania jest różnie interpretowane przez różne organizacje zajmujące się produkcją oprogramowania. Może oznaczać zarówno bardzo zgrubny, abstrakcyjny opis funkcji jakie powinien realizować system informatyczny lub ograniczeń jakim może podlegać, jak również może być matematyczną formułą, bardzo precyzyjnie określającą jego funkcjonalność Wymagania w wielu przypadkach mogą spełniać różne, wydawałoby się przeciwstawne, funkcje: mogą stanowić podstawę dla ofert na realizację systemu - powinny być otwarte, tak aby nie narzucać formy realizacji systemu mogą (a właściwie powinny) stanowić podstawę kontraktu na realizację systemu - powinny zatem być: dokładne, kompletne, spójne, realizowalne i weryfikowalne
Inżynieria wymagań Inżynieria wymagań - proces identyfikacji wymagań jakich spełnienia oczekują użytkownicy systemu oraz ograniczeń nakładanych na jego realizację i użytkowanie.
Proces (uproszczony) inżynierii wymagań
Analiza realizowalności Analiza realizowalności zebranie zasadniczych (podstawowych) wymagań klienta i określenie czy te wymagania mogą zostać spełnione w założonym budżecie i przy wykorzystaniu wymaganych lub dostępnych rozwiązań technologicznych. Zwykle za ten etap klient nie jest obciążany kosztami. Jednak w przypadku dużych, złożonych projektów analiza realizowalności może być płatna.
Analiza wymagań Analiza wymagań analiza aktualnego środowiska pracy użytkowników systemu, określenie celów systemu i jego ograniczeń. Analiza wymagań jest zwykle wykonywana w środowisku klienta na podstawie bezpośrednich rozmów z decydentami i użytkownikami systemu. Analiza wymagań powinna być przeprowadzana kilkukrotnie w celu usunięcia zauważonych nieścisłości i ostatecznego uzgodnienia listy wymagań. Na podstawie przeprowadzonej analizy powstaje dokument definicja wymagań, który w formie przejrzystej i zrozumiałej przez przyszłych użytkowników systemu przedstawia zebrane wymagania i ograniczenia. Ten dokument powinien zostać zaakceptowany przez klienta.
Specyfikacja wymagań systemowych Specyfikacja Wymagań Systemowych (SWS, ang, System Requirements Specification - SRS) to dokument, w którym są uszczegółowiane wymagania dotyczące przyszłego systemu. Specyfikacja wymagań powinna stanowić podstawę kontraktu (wycena, termin realizacji) pomiędzy klientem i wykonawcą, jak również stanowi punkt startowy dla dokumentów określających architekturę systemu oraz jego implementację. Więcej o dokumentach SWS w dalszej części wykładu.
Przykład definicji i specyfikacji Definicja wymagania Oprogramowanie powinno w łatwy, intuicyjny sposób umożliwiać dostęp do zewnętrznych plików tworzonych przez inne programy. Specyfikacja wymagań 1.1 Użytkownik ma mieć możliwość definiowania typów plików zewnętrznych 1.2 Każdy zdefiniowany przez użytkownika typ pliku zewnętrznego musi mieć związane z nim oprogramowanie, które może zostać użyte do edycji plików tego typu. 1.3 Każdy plik zewnętrzny będzie reprezentowany w systemie przez ikonę. 1.4 Użytkownik ma mieć możliwość tworzenia i przypisywania ikon do typów plików zewnętrznych. 1.5 W wyniku kliknięcia myszą na ikonie reprezentującej plik zewnętrzny oprogramowanie związane z typem tego pliku ma zostać użyte do prezentacji zawartości tego pliku.
POZYSKIWANIE WYMAGAŃ
Pozyskiwanie wymagań Celem fazy pozyskiwania wymagań jest zebranie wymagań klienta wobec tworzonego systemu. Zbieranie wymagań to proces w którym klient łącznie z przedstawicielami producenta systemu konstruuje zbiór wymagań wobec systemu zgodnie z postawionymi celami i przyjętym zakresem. Zebrane wymagania dokumentowane są w Specyfikacji Wymagań Systemowych SWS (ang. SRS System Requirements Specification).
Inżynieria wymagań Inżynieria wymagań (ang. Requirements engineering) to całość działań związanych z pozyskiwaniem, reprezentowaniem, analizą i zarządzaniem wymaganiami. Etap zbierania wymagań jest traktowany jako jeden z najtrudniejszych w całym procesie produkcji oprogramowania. Osiągnięcie całkowicie poprawnej i pełnej specyfikacji wymagań jest niezwykle trudne ze względu na ciągłą ewolucję każdego systemu informatycznego.
Trzy metody pozyskiwania wymagań 1. Wywiady 2. Studia istniejących systemów 3. Prototypowanie
1. Wywiady Mają być przygotowane w postaci listy pytań i podzielone na odrębne zagadnienia. Mają umożliwić użytkownikowi zrozumienie konsekwencji wyborów i ich wpływ na ostateczną postać systemu Mają doprowadzić do szerokiej zgody i akceptacji projektu.
2. Studia istniejących systemów Są rozpatrywane w sytuacji gdy nowe oprogramowanie zastępuje stare. Mają ustalić wszystkie dobre i złe strony starego oprogramowania. Mają ustalić wymagania wobec nowego systemu, które zwykle związane są z usunięciem złych stron starego systemu, zachowaniem dobrych strony starego systemu, dodaniem nowych możliwości nieobecnych w starym systemie.
3. Prototypowanie Zbudowanie prototypu systemu działającego w mniejszej skali z uproszczonymi interfejsami. Na podstawie prototypu zebranie listy wymagań zwykle dotyczących: rozwinięcia funkcjonalności, poprawienia efektywności (np. szybszej pracy systemu), zmian w interfejsie (np. poprawy ergonomii). Budowa prototypu jest najbardziej kosztownym sposobem zbierania/uściślania wymagań.
Rodzaje wymagań Trzy podstawowe rodzaje wymagań: Wymagania funkcjonalne opisują one funkcje (czynności, operacje), które mają być wykonywane przez system, dotyczą rezultatów oczekiwanych przez użytkownika podczas kontaktu z systemem. Wymagania niefunkcjonalne opisują ograniczenia (sprzętowe, prawne), przy zachowaniu których system ma realizować swoje funkcje. Wymagania przejściowe opisują ograniczenia o określonym czasie występowania, np. związane z migracją ze starego systemu do nowego.
Ważność fazy pozyskiwania wymagań Zbieranie wymagań jest fazą w której niezbędna jest najbardziej staranna weryfikacja i walidacja. Rozwijanie aplikacji w oparciu o niepoprawne wymagania może w skrajnym przypadku doprowadzić do wytworzenia nieodpowiedniego lub niepotrzebnego oprogramowania! Koszt naprawy błędów w specyfikacji wymagań rośnie zgodnie z zasadą 1:10, tzn. naprawa błędu specyfikacji wymagań kosztuje: 10 razy więcej na etapie projektowania, 100 razy więcej na etapie kodowania, 1000 razy więcej na etapie użytkowania i konserwacji niż na etapie specyfikacji.
Kto? Ustalenie interesariuszy projektu Zarządzający (cele biznesowe) Kontroler finansowy (koszty) Kierownik IT (szczególne wymagania funkcjonalne, niezawodność, dostępność, testowalność) Użytkownicy końcowi (wymagania funkcjonalne) Kierownik marketingu (cechy marketingowe) Kierownik ochrony (bezpieczeństwo) Dobrą praktyką jest ograniczanie liczby interesariuszy biorących udział w bezpośrednim opracowywaniu listy (definicji) wymagań (np. do kierowników działów, brygadzistów itp.). Jednak nie zwalnia to z obowiązku przeprowadzenia wywiadu na bezpośrednich stanowiskach pracy użytkowników.
Kto? Ustalenie interesariuszy Każda osoba zainteresowana może występować w kilku rolach (np. administrator może też być użytkownikiem końcowym). Z każdą rolą jest związany określony punkt widzenia. Każde urządzenie lub system współpracujący z projektowanym systemem również może mieć swoje wymagania i w tym sensie również jest udziałowcem projektu. Punkty widzenia różnych interesariuszy są różne. Wszystkie punkty widzenia interesariuszy są ważne, chociaż nie wszystkie w tym samym stopniu. Wszystkie punkty widzenia powinny zostać wzięte pod uwagę. Wszystkie punkty widzenia powinny zostać przeanalizowane. Pojawiające się konflikty powinny zostać rozstrzygnięte.
Kto? Ustalenie klienta Klientem jest osoba lub organizacja, która ma ostateczny wpływ na kształt projektu. Z klientem uzgadniamy specyfikację wymagań i podpisujemy kontrakt. Klient powinien należeć do interesariuszy projektu. W przeciwnym przypadku nie jest on zainteresowany wprowadzeniem systemu, a wtedy szanse zrealizowania projektu są minimalne. W organizacji klienta musi być wyznaczona osoba (kierownik projektu) odpowiedzialna za realizację projektu i reprezentująca klienta. Osoba ta musi mieć odpowiednią władzę nad innymi interesariuszami, aby zapewnić ich współpracę w fazie formułowania wymagań. W przypadku klienta szerokiego (produktu przeznaczonego dla masowego odbiorcy) trzeba znaleźć osobę lub grupę osób reprezentujących interesariuszy (najczęściej użytkowników końcowych) i od nich pozyskiwać wymagania.
Zrozumienie
Każdy słyszy to, co chce usłyszeć
Co? Cztery etapy pozyskiwania wymagań 1. Uświadomienie sobie przez interesariuszy ich potrzeb. 2. Sformułowanie potrzeb. 3. Transformowanie potrzeb na wymagania względem systemu. 4. Zdobycie uzupełniających informacji potrzebnych do zrozumienia wymagań.
1. Uświadamianie potrzeb Interesariusz może nie czuć potrzeby wprowadzenia systemu, a jedynie kierować się odgórnymi nakazami czy trendami (fatalna sytuacja!). Interesariusz może być na tyle przyzwyczajony do dotychczasowego sposobu pracy, że nie potrafi zrozumieć zmian, które nastąpią po wprowadzeniu nowego systemu. Interesariusz prawie na pewno nie uświadamia sobie wszystkich swoich potrzeb. W przypadku, gdy Interesariusz jest urządzeniem lub systemem, jego wymagania może reprezentować osoba eksperta lub mogą być one zapisane w dokumentacji, do której trzeba dotrzeć.
2. Formułowanie potrzeb Interesariusz może mieć kłopoty z formułowaniem jasnych wypowiedzi. Interesariusz może być niechętny do formułowania pewnych potrzeb, gdyż może uznać je za słabość swoją lub swojej organizacji i wstydzić się tej słabości. Interesariusz może uznać pewne swoje potrzeby za oczywiste i nie zdawać sobie sprawy z tego, że ktoś inny może ich nie znać (fatalnie!).
3. Zamiana potrzeb na wymagania Nie każdą potrzebę jest w stanie zaspokoić system informatyczny. Niektórych potrzeb nie da się zaspokoić bez zmiany organizacji. Wymagania mogą być funkcjonalne, niefunkcjonalne i przejściowe. Istnieje konieczność klasyfikacji wymagań. Wymagania powinny określać, co system ma robić, a nie w jaki sposób ma to robić. Różne potrzeby mogą prowadzić do sprzecznych wymagań. Istnieje konieczność określenia priorytetów ważności wymagań.
4. Uzyskanie informacji potrzebnych do zrozumienia wymagań Informacje mogą być przechowywane w głowach pewnych osób, które mogą nie być zainteresowane w dzieleniu się nimi (bierny opór). Informacje mogą być zapisane w trudno dostępnej dokumentacji. Informacje mogą być niekompletne. Informacje mogą być sprzeczne. Informacje mogą być mylące.
Trudność fazy pozyskiwania wymagań (1) Klient z reguły nie wie dokładnie w jaki sposób osiągnąć założone cele. Cele klienta mogą być osiągnięte na wiele sposobów. Duże systemy są wykorzystywane przez wielu użytkowników. Ich cele są często sprzeczne. Różni użytkownicy mogą posługiwać się inną terminologią mówiąc o tych samych problemach.
Trudność fazy pozyskiwania wymagań (2) Zleceniodawcy, sponsorzy i użytkownicy to często inne osoby. Głos zleceniodawców może być w tej fazie decydujący, chociaż nie zawsze potrafią oni właściwie przewidzieć potrzeby przyszłych użytkowników. W większości organizacji związanych z produkcją i eksploatacją oprogramowania jakość procesów inżynierii wymagań jest bardzo niska. Znaczenie tej fazy jest umniejszane, bardzo szybko przechodzi się do faz związanych bezpośrednio z produkcją (projektowanie, implementacja)
Zagrożenia w procesie pozyskiwania wymagań Wymagania muszą być zbierane w procesie iteracyjnym aż do uzyskania pewności, że pozyskana lista wymagań jest kompletna i poprawnie sformułowana. W wielu sytuacjach proces ten jest przerywany (np. z powodu kosztów, upływających terminów) w wyniku czego specyfikacja wymagań nie jest wystarczająco precyzyjna.
Zagrożenia w procesie pozyskiwania wymagań Przyczyny uzyskania specyfikacji wymagań nie w pełni kompletnej: Brak przeznaczenia wystarczających zasobów na realizację tego procesu. Pozyskane wymagania wydają się pozornie prawdziwe, lecz nie przeprowadzono dostatecznej ich analizy oraz ich kompletności i poprawności. Wykonano jedynie jedną iterację, a zespół zbierający wymagania nie jest wystarczający świadomy tego, że ponowny kontakt z klientem może wnieść nowe informacje co do ostatecznej postaci systemu.