Proces Inżynierii Wymagań michał możdżonek 02.2008
Literatura 1. Sommerville I. (2003): Inżynieria oprogramowania, WNT, Warszawa 2. Leffingwell D., Widrig D. (2003): Zarządzanie wymaganiami, WNT, Warszawa 3. Pressman R. S. (2004): Praktyczne podejście do inżynierii oprogramowania, WNT, Warszawa
Proces Inżynierii Wymagań Procesy służące do zidentyfikowania, przeanalizowania i zatwierdzenia wymagań systemowy Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 3
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ń
Zawartość Studium wykonalności Określenie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami
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
Proces inżynierii wymagań Studium wykonalności Określanie i analizowanie wymagań Specyfikowanie wymagań Raport o wykonalności Model systemu Zatwierdzanie wymagań Wymagania użytkownika i wymagania systemowe Dokumentacja wymagań
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?
Przeprowadzenie studium wykonalności Okreś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?
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
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
Proces analizy wymagań Początek procesu Rozpoznanie dziedziny Sprawdzanie wymagań Specyfikacja wymagań Nadawanie priorytetów Dokumentacja wymagań Zbieranie wymagań Usuwanie sprzeczności Klasyfikacja
Czynności procesu Rozpoznanie dziedziny Zebranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań
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ń
Określanie oparte na punktach widzenia Uczestnicy 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ń
System obsługi bankomatu Przykł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
Punkty widzenia dla bankomatu Klienci 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
Zewnętrzne punkty widzenia Naturalny 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
Identyfikacja punktów widzenia Pytanie o saldo Zasoby maszyny Interfejs użytkownika Właściciel konta Zdalna diagnostyka Odczyt transakcji Informacje o koncie Menedżer Koszt systemu Karta skradziona Zamówienie wyciągu Niezawodność Baza danych klientów Dziennik komunikatów Obcy klient Zwrot karty Aktualizacja konta Wypłata gotówki Rozmiar oprogramowania Drukarka Pielęgnacja oprogramowania Zdalna aktualizacja oprogramowania Przelew środków Dziennik transakcji Kasa banku Zabezpieczenia Przekazywanie komunikatów Zamówienie czeków Nieuprawniony użytkownik Zatrzymanie karty Weryfikacja karty
Informacje o usługach Właściciel konta Obcy klient Kasa banku Lista usług Lista usług Lista usług Wypłata gotówki Wypłata gotówki Diagnostyka Pytanie o saldo Pytanie o saldo Dodanie gotówki Zamówienie czeków Wysłanie komunikatu Dodanie papieru Wysłanie komunikatu Lista transakcji Zamówienie wyciągu Przelew środków
Dane wejściowe i sterujące WŁAŚCICIEL KONTA Dane sterujące Dane wejściowe Rozpocznij transakcję Anuluj transakcję Informacje z karty PIN Zakończ transakcję Żądana kwota Wybór usługi Komunikat
Hierarchia punktów widzenia Wszystkie 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
Wzory: klient/wypłata 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: 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
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
Opis scenariusza Stan systemu przed rozpoczęciem scenariusza Normalny 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
Scenariusz zdarzenia zacznij transakcję Wsunięto kartę Karta PIN Poproś o PIN Przekroczenie limitu czasu Zwróć kartę Karta nieważna Numer konta PIN Sprawdź użytkownika Zły PIN Karta ważna Wprowadź ponownie PIN Numer konta Użytkownik OK Wybierz usługę Zwróć kartę Zły PIN Karta skradziona Zwróć kartę Zatrzymaj kartę
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
Opis wyjątków Większość metod nie posiada udogodnień do opisu wyjątków W 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
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
Przypadek użycia - wypożyczenie Obsługa wypożyczania
Przypadki użycia biblioteki Czytelnik Obsługa wypożyczania Zarządzanie użytkownikami Personel biblioteki Dostawa Obsługa katalogu
Zarządzanie katalogiem Sprzedawca książek Składnik: Składnik biblioteki Książki: Katalog Katalogujący: Personel biblioteki Nabądź Nowy Kataloguj składnik Usuń Usuń składnik z katalogu
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
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
Szczegółowa etnografia Powstał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
Etnografia i prototypowanie Analiza etnograficzna Narady Szczegółowa etnografia Ogólne tworzenie systemu Prototypowanie systemu Ocena prototypu
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
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
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ć?
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
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
Lista sprawdzeń dla wymagania Weryfikowalność. 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.
Automatyczne sprawdzanie niesprzeczności Wymagania w języku formalnym Raporty o sprzecznych wymaganiach Kompilator Generator raportów Baza danych wymagań
Zarządzanie wymaganiami Zarzą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
Zmiany wymagań Ważność wymagań zależy od punktu widzenia Klienci 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
Ewolucja wymagań Wstępne zrozumienie problemu Zmienione zrozumienie problemu Wstępne wymagania Zmienione wymagania Czas
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 Wymagania zmienne to wymagania,,które prawdopodobnie ulegną zmianie w trakcie tworzenia systemu albo po przekazaniu go do użytkownika
Klasyfikacja wymagań zmiennych Wymagania ś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
Planowanie zarządzania wymaganiami Podczas 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
Ś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
Macierz zależności Req. 1.1 1.2 1.3 2.1 2.2 2.3 3.1 3.2 id 1.1 U R 1.2 U R U 1.3 R R 2.1 R U U 2.2 U 2.3 R U 3.1 R 3.2 R
Narzędzia CASE Przechowywanie wymagań Wymagania 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
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
Zarządzanie zmianami wymagań Rozpoznany problem Skorygowane wymaganie Analiza problemu i specyfikacja zmiany Analiza zmiany i ocena kosztów Implementacja zmiany
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
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