View
65
Download
0
Category
Preview:
DESCRIPTION
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ń - PowerPoint PPT Presentation
Citation preview
©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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 2
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ń
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 3
Zawartość Studium wykonalności Określenie i analizowanie wymagań Zatwierdzanie wymagań Zarządzanie wymaganiami
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 4
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 5
Proces inżynierii wymagań
Studiumwykonalności
Określaniei analizowanie
wymagań
Zatwierdzaniewymagań
Specyfikowaniewymagań
Raporto wykonalności
Modelsystemu
Wymagania użytkownikai wymagania systemowe
Dokumentacjawymagań
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 6
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 7
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?
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 8
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 9
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 10
Proces analizy wymagań
Rozpoznaniedziedziny
Zbieraniewymagań
Klasyfikacja
Usuwaniesprzeczności
Nadawaniepriorytetów
Sprawdzaniewymagań
Specyfikacjawymagań
Dokumentacjawymagań
Początekprocesu
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 11
Czynności procesu Rozpoznanie dziedziny Zebranie wymagań Klasyfikacja Usuwanie sprzeczności Nadawanie priorytetów Sprawdzanie wymagań
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 12
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ń
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 13
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ń
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 14
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 15
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 16
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 17
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 18
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 19
Metoda VORD
Identyfikacjapunktów widzenia
Strukturalizacjapunktów widzenia
Dokumentacjapunktów widzenia
Przyporządkowaniepunktów widzenia
do systemu
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 20
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 21
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ę
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 22
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 23
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 24
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 25
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 26
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 27
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 28
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 29
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 30
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 31
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 32
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 33
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 34
Przypadek użycia - wypożyczenie
Obsługa wypożyczania
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 35
Przypadki użycia biblioteki
Czytelnik Obsługa wypożyczania
Dostawa
Zarządzanie użytkownikami
Obsługa katalogu
Personelbiblioteki
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 36
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ń
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 37
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 38
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 39
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 40
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 41
Etnografia i prototypowanie
Analizaetnograficzna
NaradySzczegółowa
etnografia
Ocenaprototypu
Ogólne tworzeniesystemu
Prototypowaniesystemu
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 42
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 43
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 44
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ć?
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 45
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 46
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 47
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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 48
Automatyczne sprawdzanie niesprzeczności
Wymagania wjęzyku formalnym
Kompilator
Baza danychwymagań
Raporty o sprzecznychwymaganiach
Generatorraportów
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 49
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 50
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 51
Ewolucja wymagań
Czas
Wstępnezrozumienie
problemu
Wstępnewymagania
Zmienionezrozumienie
problemu
Zmienionewymagania
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 52
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 53
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 54
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 55
Ś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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 56
Macierz zależności
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 57
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 58
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 59
Zarządzanie zmianami wymagań
Analiza problemui specyfikacja
zmiany
Analiza zmianyi ocena kosztów
Implementacjazmiany
Rozpoznanyproblem
Skorygowanewymaganie
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 60
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 61
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
Recommended