Procesy Inżynierii Wymagań

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1

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ń

Studiumwykonalności

Określaniei analizowanie

wymagań

Zatwierdzaniewymagań

Specyfikowaniewymagań

Raporto wykonalności

Modelsystemu

Wymagania użytkownikai wymagania systemowe

Dokumentacjawymagań


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ń

Rozpoznaniedziedziny

Zbieraniewymagań

Klasyfikacja

Usuwaniesprzeczności

Nadawaniepriorytetów

Sprawdzaniewymagań

Specyfikacjawymagań

Dokumentacjawymagań

Początekprocesu


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

Identyfikacjapunktów widzenia

Strukturalizacjapunktów widzenia

Dokumentacjapunktów widzenia

Przyporządkowaniepunktó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 VORDSzablon 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

Pytanieo saldo

Odczyttransakcji

Zasobymaszyny

Zdalnadiagnostyka

Wypłatagotówki

Zdalnaaktualizacja

oprogramowania

Zamówienieczeków

Przelewśrodków

Zamówieniewyciągu Przekazywanie

komunikatów

Baza danychklientów

Menedżer

Właścicielkonta

Obcyklient

Pielęgnacjaoprogramowania

Kasabanku

Informacjeo koncie

Interfejsużytkownika

Koszt systemu

Kartaskradziona

NiezawodnośćAktualizacja

konta

Dziennikkomunikatów

Zwrotkarty

Rozmiaroprogramowania

Drukarka

Zabezpieczenia

Dzienniktransakcji

Nieuprawnionyużytkownik

Zatrzymaniekarty

Weryfikacjakarty


Informacje o usługach

Właściciel konta Obcy klient Kasa bankuLista 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 Dodanie papieru

Wysłanie komunikatu 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

Personel bankuKlient

Właścicielkonta

Klientobcy

Kasa InżynierMenedżer

UsługiPytanie o saldo

Wypłata gotówki

UsługiZamówienie czekówWysłanie komunikatuLista transakcjiZamówienie wyciąguPrzelew środków


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ę

Karta

PIN

Poprośo PIN

Przekroczenielimitu czasu

Zwróć kartę

Kartaskradziona

Zatrzymaj kartę

Karta nieważna

Zwróć kartę

Wsunięto kartę

Zły PIN

Wprowadźponownie PIN

Zły PIN

Zwróć kartę

Sprawdźużytkownika

NumerkontaPIN

Karta ważna

Wybierzusługę

Użytkownik OK

Numerkonta


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

Dostawa

Zarządzanie użytkownikami

Obsługa katalogu

Personelbiblioteki


Zarządzanie katalogiem

Sprzedawcaksiążek

Nabądź

Składnik:Składnik biblioteki

Książki:Katalog

Katalogujący:Personel biblioteki

Nowy

Katalogujskładnik

Usuń składnikz katalogu

Usuń


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

Analizaetnograficzna

NaradySzczegółowa

etnografia

Ocenaprototypu

Ogólne tworzeniesystemu

Prototypowaniesystemu


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 wjęzyku formalnym

Kompilator

Baza danychwymagań

Raporty o sprzecznychwymaganiach

Generatorraportów


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ń

Czas

Wstępnezrozumienie

problemu

Wstępnewymagania

Zmienionezrozumienie

problemu

Zmienionewymagania


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ń

• 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ń

Analiza problemui specyfikacja

zmiany

Analiza zmianyi ocena kosztów

Implementacjazmiany

Rozpoznanyproblem

Skorygowanewymaganie


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

Documents

Procesy Inżynierii Wymagań