Procesy Inżynierii Wymagań Procesy służące do zidentyfikowania, przeanalizowania i zatwierdzenia wymagań systemowych

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ń Określanie i analizowanie wymagań Studium wykonalności Specyfikowanie wymagań Zatwierdzanie wymagań Raport o wykonalności Model systemu 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ń Specyfikacja wymagań Sprawdzanie wymagań Dokumentacja wymagań Rozpoznanie dziedziny Nadawanie priorytetów Początek procesu 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

Typy punktów widzenia Źródło lub przeznaczenie danych Punkt widzenia odpowiedzialny za produkowanie lub użytkowanie danych. Analiza polega na rozpoznaniu wszystkich takich punktów widzenia i sprawdzeniu czy założenia dotyczące danych są poprawne Zrąb reprezentacji Osoba związana z konkretnym typem modelu systemu. Odpowiednie dla systemów czasu rzeczywistego. Odbiorca usług Punkty widzenia są zewnętrzne wobec systemu.

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

Analiza oparta na metodach Szeroko stosowane podejście do analizy wymagań. Zależnie od zastosowanej metody uzyskamy inny stopień zrozumienia systemu Metody koncentrują się na różnych celach. Niektóre są przeznaczone do wydobywania wymagań, inne są bliskie projektowaniu Jako przykład przedstawię opartą na punktach widzenia metodę VORD

Metoda VORD Identyfikacja punktów widzenia Strukturalizacja Dokumentacja punktów widzenia Przyporządkowanie punktów widzenia do systemu

Model procesu VORD Identyfikacja punktów widzenia Znajdowanie punktów widzenia, których reprezentanci korzystają z usług systemu i usług dla tych reprezentantów Strukturalizacja punktów widzenia Grupowanie podobnych punktów widzenia w hierarchię. Wspólne usługi są umieszczone wyżej Dokumentowanie punktów widzenia Udoskonalanie opisów punktów widzenia i usług Przyporządkowywanie punktów widzenia Przekształcanie punktów widzenia w projekt obiektowy

Szablony formularzy VORD Szablon do punktu widzenia Odnośnik: Nazwa punktu widzenia Atrybuty: Atrybuty z informacją o punkcie widzenia Zdarzenia: Odnośnik do zbioru scenariuszy opisujących, jak system reaguje na zdarzenia w ramach tego punktu widzenia Usługi: Odnośnik do zbioru opisów usług Podrzędne: Nazwy podrzędnych punktów 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ć zapisane za pomocą różnych notacji Punkty widzenia: Lista nazw punktów widzenia, których reprezentacji korzystają z usługi Wymagania niefunkcjonalne: Odnośnik do zbioru wymagań niefunkcjonalnych ograniczających usługę Dostawca: Lista obiektów systemu oferujących tę usługę

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

Informacje o usługach Właściciel konta Obcy klient Kasa banku Lista usług Wypłata gotówki Diagnostyka Pytanie o saldo Dodanie gotówki Zamówienie czeków 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ę Informacje z karty Anuluj transakcję 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

Scenariusze zdarzeń Scenariusze zdarzeń mogą być używane do opisu jak system odpowiada na jakieś konkretne zdarzenie np. „początek transakcji” VORD zawiera graficzne konwencje do przedstawiania scenariuszy zdarzeń. Dane odbierane i przekazywane Informacja sterująca Obsługa wyjątków Następne zdarzenia

Scenariusz zdarzenia – zacznij transakcję Wsunięto kartę Karta ważna Karta Poproś o PIN Użytkownik OK PIN Numer konta PIN Sprawdź użytkownika Numer konta Przekroczenie limitu czasu Wybierz usługę Zły PIN Zwróć kartę Wprowadź ponownie PIN Karta nieważna Zwróć kartę Zły PIN Zwróć kartę Karta skradziona 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 Obsługa wypożyczania Czytelnik Zarządzanie użytkownikami Personel biblioteki Dostawa Obsługa katalogu

Zarządzanie katalogiem Składnik: Składnik biblioteki Książki: Katalog Katalogujący: Personel biblioteki Sprzedawca książek Nabądź Nowy Kataloguj składnik Usuń Usuń składnik z katalogu

Czynniki organizacyjne i społeczne Systemy komputerowe istnieją w otoczeniu organizacyjnym i społecznym. To może wpływać lub wręcz zdominować wymagania systemowe Czynniki organizacyjne i społeczne oddziałują nie na jeden, ale na wszystkie punkty widzenia Analityk powinien wyczuwać takie czynniki, ale na razie nie istnieje systematyczna metoda ich opisu

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 Ocena prototypu Ogólne tworzenie systemu Prototypowanie systemu

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 Generator raportów Kompilator 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 Zmienione zrozumienie zrozumienie problemu 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

Narzędzia CASE Przechowywanie wymagań Zarządzanie zmianami 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