Wstęp. Inżynieria wymagań. Plan wykładu. Wstęp. Wstęp. Wstęp. Schemat procesu pozyskiwania wymagań

Transkrypt

1 Wstęp Inżynieria wymagań Schemat procesu pozyskiwania wymagań identyfikacja źródeł wymagań Organizacja i Zarządzanie Projektem Informatycznym pozyskiwanie pozyskiwanie pozyskiwanie Jarosław Francik marzec - kwiecień 2002 konsolidacja analiza zbiorcza Plan wykładu Wstęp: Specyfikacja Wymagań Systemowych Zakres systemu i zakres wymagań Odpowiedzialność Specyfikacja wymagań Literatura: Inżynieria oprogramowania w projekcie informatycznym pod red. J. Górskiego Wstęp Specyfikacja wymagań: uzasadnienie potrzeby koszt błędnej specyfikacji (zasada 1:10) klienci i użytkownicy na ogół nie wiedzą, czego chcą! Zagrożenia dla procesu zbierania wymagań koszty brak umiejętności, pośpiech często zmieniające się informacje od klientów niewłaściwa polityka kierownictwa Wstęp Wstęp to, co klient zamówił to, co opisywał projekt to, co wykonali programiści Klucze do sukcesu: kontakt z udziałowcami ciągła analiza systemu w czasie trwania projektu dobra procedura kontroli zmian Specyfikacja Wymagań Systemowych - SWS System Requirements Specification - SRS po uruchomieniu to, za co klient zapłacił i wdrożeniu... to, czego klient potrzebował 1

2 Zakres systemu i zakres wymagań Klient strategia biznesowa, potrzeby, problemy, możliwości, ograniczenia Odpowiedzialność Wykonawca technologia, personel, doświadczenia, zarządzanie, ograniczenia pozyskiwanie wymagań analiza i specyfikacja wymagania realizowalność ryzyko proces rozwoju Zakres systemu i zakres wymagań Planowanie strategiczne identyfikacja wymaganych cech systemu określenie celów biznesowych ustalenie priorytetów poszczególnych cech i celów określenie harmonogramu i budżetu zdefiniowanie zakresu systemu Klient? Niezależny konsultant? Dostawca? WSPÓŁDZIAŁANIE Odpowiedzialność Wymagania udziałowców systemu Potrzeba odcięcia osób nie będących udziałowcami Zakres systemu i zakres wymagań System ma służyć potrzebom organizacji, a nie tylko wymaganiom końcowych użytkowników (priorytety!) Wykluczenie niektórych podmiotów nie będących faktycznymi udziałowcami projektu Zidentyfikuj wszystkich udziałowców systemu Przeanalizuj ich punkty widzenia Wydobądź wymagania 2

3 Przykładowi udziałowcy: użytkownicy końcowi (wymagania funkcjonalne) wyższe kierownictwo (cele biznesowe) kierownik pielęgnacji kierownik marketingu kierownik finansowy osoby odpowiedzialne za bezpieczeństwo Brak rozgraniczenia potrzeb od wymagań potrzeby: sformułowane mało konkretnie i ogólnikowo wymagania: nie rozpoznane, nie wyartykułowane nic nie wnoszące wymagania: komputeryzacja, informatyzacja, rachunkowość zarządcza, prognoza wyniku, opłacalność inwestycji Błędne sformułowanie wymagań wymaganie ma specyfikować co system ma robić, a nie czym system ma być klient ma formułować wymagania a nie projektować system! Klient nie wie, w jaki sposób osiągnąć założone cele! Punkty widzenia osoba a udziałowiec punkty widzenia udziałowców są różne punkty widzenia mogą być sprzeczne wszystkie punkty widzenia są znaczące wszystkie punkty widzenia należy wziąć pod uwagę Wymagania nieuświadomione Wymagania uznane za oczywiste Wymagania uznane za niemożliwe Nie sądziłem, że to ma znaczenie Nie sądziłem, że się to da zrobić Uzgodnienie celów systemu Problemy (podsumowanie): sprzeczne punkty widzenia sprzeczne wymagania (np. projektant kontra specjalista ds. pielęgnacji) pominięte punkty widzenia (np. kierownik kontra sekretarka) Problemy (podsumowanie): sprzeczne punkty widzenia sprzeczne wymagania (np. projektant kontra specjalista ds. pielęgnacji) pominięte punkty widzenia (np. kierownik kontra sekretarka) niewłaściwie wyspecyfikowane wymagania niewyspecyfikowane wymagania 3

4 Wskazówki techniczne: nie ustawać w zadawaniu pytań (jak porucznik Columbo) pytania nie tylko Co, ale też: dlaczego załóżmy, że... a co, jeżeli... wywiady studiowanie istniejących systemów studiowanie podręczników użytkowania analiza środowiska docelowego Grupowanie wymagań: Wymagania funkcjonalne określają to, co system ma robić: rezultaty oczekiwane przez użytkownika (tryby pracy, funkcje, postać interfejsu) Wymagania niefunkcjonalne formułowane w odniesieniu do całości systemu: dostępność, niezawodność, odtwarzalność, pielęgnowalność rozszerzalność, kompatybilność, przenośność Inne: cele biznesowe, ograniczenia techniczne, polityczne itp. Wydobywanie wymagań to najtrudniejsze zadanie całego cyklu życia projektu Polega na przepływie informacji od ludzi lub dokumentów do analityków systemu W znacznym zakresie jest to zagadnienie pozatechniczne, psychologiczne, wymagające harmonii i dobrych stosunków międzyludzkich wymaga całościowej analizy systemu Klienci i użytkownicy powinni sami oceniać swoje wymagania i rozumieć ich konsekwencje to proces iteracyjny funkcje i możliwości bezpieczeństwo 4

5 czynniki ludzkie (interfejs użytkownika) estetyka system pomocy dokumentacja materiały szkoleniowe testowalność, rozszerzalność, adaptowalność, przenośność, kompatybilność, konfigurowalność, pielęgnowalność, instalowalność, możliwość lokazlizacji liczba / częstotliwość występowania błędów odtwarzalność (po wystąpieniu błędu) dokładność dostępność MTBF średni czas pomiędzy awariami FURBS + Wymagania projektowe założenia dotyczące projektowania Wymagania implementacyjne standardy, języki, środowisko, ograniczenia Wymagania interfejsu ograniczenia i założenia interfejsu (np. font nie mniejszy niż...) Wymagania fizyczne kolor, rozmiar itp. szybkość efektywność czas odpowiedzi użycie zasobów Konsolidacja: łączenie wymagań o nakładającej się treści odnoszenie wymagań do zakresu projektu usuwanie niespójności (sprzeczności) usuwanie wymagań wyspecyfikowanych więcej niż raz identyfikacja wymagań brakujących (luk) 5

6 Specyfikacja wymagań Definicja wymagania Specyfikacja wymagania Specyfikacja Wymagań Systemowych - SWS System Requirements Specification SRS wg Rational Unified Process (RUP) Specyfikacja wymagań Atrybuty wymagań: Jednoznaczność (unamiguity) Kompletność (completeness) Poprawność (corectness) Spójność (consistency) Weryfikowalność (verifiability) Mierzalność (measurablity) Modyfikowalność (modifiability) Śladowość (traceability) Podsumowanie PROBLEMY: Brak wsparcia analityków systemowych Niedostateczna współpraca z klientem, brak końcowej walidacji specyfikacji Brak kwalifikacji (źle sformułowany dokument) Niewłaściwa polityka kierownictwa Konieczność wprowadzania i śledzenia zmian 6