©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 1

Proces inżynierii
wymagań



Służy do określania,
analizowania i
zatwierdzania wymagań
stawianych systemowi.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 2

Cele



Rozumieć podstawowe czynności inżynierii

wymagań i związki między nimi.



Znać kilka metod określania i analizowania

wymagań.



Rozumieć znaczenie zatwierdzania

wymagań oraz to, jak w tym procesie używa

się przeglądów wymagań.



Rozumieć, dlaczego zarządzanie

wymaganiami jest niezbędne oraz to, jak

wspomaga ono inne czynności inżynierii

wymagań.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 3

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 4

Zawartość



Studium wykonalności



Określanie i analizowanie
wymagań



Zatwierdzanie wymagań



Zarządzanie wymaganiami

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 5



Obejmuje wszystkie czynności niezbędne

do opracowania i aktualizacji

dokumentacji wymagań systemowych.



Istnieją cztery ogólne czynności wysokiego

poziomu w procesie inżynierii wymagań:

• studium wykonalności
• określenie i analizowanie wymagań
• specyfikowanie i dokumentowanie

wymagań

• zatwierdzanie wymagań

Proces inżynierii
wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 6

Studium

wykonalności

Określanie

i analizowanie

wymagań

Specyfikowanie

wymagań

Zatwierdzanie

wymagań

Raport

o wykonalności

Model

systemu

Wymagania użytkownika

i wymagania systemowe

Dokumentacja

wymagań

Proces inżynierii
wymagań c.d.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 7



Wynikiem tego studium powinien być raport, który

zaleca albo nie zaleca kontynuacji procesu inżynierii

wymagań i tworzenia systemu.



Studium wykonalności to krótkie, skumulowane

opracowanie, w którym staramy się odpowiedzieć

na kilka pytań:

• Czy system przyczyni się do realizacji ogólnych

celów przedsiębiorstwa?

• Czy system może być zaimplementowany z

użyciem dostępnych technologii, w ramach

ustalonego budżetu i ograniczeń czasowych?

• Czy system może być zintegrowany z

istniejącymi systemami, które już zainstalowano?

Studium wykonalności

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 8



Obejmuje określenie i zebranie informacji oraz pisanie

raportu



Kilka przykładów pytań:

• Jak firma poradziłaby sobie, jeśli system nie byłby

zaimplementowany?

• Jakie problemy występują w obecnie przyjętych

procesach i jak nowy system ma pomóc w ich

eliminacji?

• Jaki byłby bezpośredni wkład systemu w osiąganie

celów gospodarczych?

• Czy można przekazywać informacje do i z innych

systemów przedsiębiorstwa?

• Czy system wymaga technologii, których wcześniej

w firmie nie stosowano?

• Co system musi wspomagać, a czego nie musi?

Przeprowadzanie studium
wykonalności

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 9

Określanie i analizowanie
wymagań



Po wstępnych studiach wykonalności następna fazą

inżynierii wymagań jest określanie i analizowanie

wymagań.



W trakcie tej czynności techniczni budowniczowie

oprogramowania pracują z klientem i użytkownikami

systemu nad badaniem dziedziny zastosowania i

usług, które system ma oferować, pożądanej

efektywności, ograniczeniach sprzętowych itd.



W określaniu i analizowaniu wymagań mogą wziąć

udział osoby z różnych stanowisk w firmie. Pojęcie

uczestnik odnosi się do każdego, kto powinien mieć

pewien pośredni lub bezpośredni wpływ na

wymagania systemowe.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 10

Problemy analizy
wymagań



Uczestnicy często nie wiedzą, czego tak naprawdę
oczekują od systemu komputerowego.



Uczestnicy systemu w naturalny sposób wyrażają
wymagania za pomocą własnych pojęć.



Różni uczestnicy mogą stawiać różne wymagania.



Czynniki polityczne mogą mieć wpływ na system



Środowisko ekonomiczne i gospodarcze, w którym
prowadzi się analizę, jest dynamiczne.
Nieuchronnie zmienia się w trakcie procesu
analizy.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 11

Proces określania i
analizowania wymagań

Początek

procesu

Rozpoznanie

dziedziny

Zbieranie

wymagań

Klasyfikacja

Usuwanie

sprzeczności

Nadawanie

priorytetów

Sprawdzenie

wymagań

Specyfikacja

wymagań

Dokumentacja

wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 12

Czynności procesu



Rozpoznanie dziedziny



Zbieranie wymagań



Klasyfikacja



Usuwanie sprzeczności



Nadawanie priorytetów



Sprawdzanie wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 13

Modelowanie systemu



Określanie i analizowanie wymagań jest

procesem iteracyjnym z ustawicznym

przekazywaniem informacji zwrotnej

między czynnościami.



Cykl procesu rozpoczyna się od

rozpoznania dziedziny, a kończy na

sprawdzeniu wymagań.



Stopień zrozumienia dziedziny przez

analityków rośnie z każdym cyklem.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 14

Określanie oparte na
punktach widzenia



Średnie i wielkie systemy maja
zwykle kilku różnych
użytkowników.



Wielu uczestników w jakiś sposób
interesuje się wymaganiami
systemowymi.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 15

System bankomatowy -
przykład



Służy do automatycznego dokonywania
operacji bankomatowych.



W uproszczonej wersji służy wielu
zwykłym klientom i oferuje bardziej
skomplikowane usługi wybranym
klientom.



Usługi obejmują: wypłatę, wpłatę,
przekazywanie informacji.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 16

Uczestnicy systemu
bankomatowego



Obecni klienci banku



Przedstawiciele innych banków



Dyrektorzy oddziałów banków



Pracownicy obsługi klienta w oddziałach



Administratorzy baz danych



Osoby odpowiedzialne za bezpieczeństwo w
banku



Dział marketingu banku



Inżynierowie pielęgnacji sprzętu i
oprogramowania

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 17

Różne punkty widzenia



Źródło lub przeznaczenie danych

• Osoba mająca taki punkt widzenia użytkuje lub

produkuje dane. W tym wypadku analiza polega na

rozpoznawaniu wszystkich takich punktów

widzenia, danych, które są produkowane lub

użytkowane, oraz przeprowadzanym przetwarzaniu.



Zrąb reprezentacji

• Osoba mająca taki punkt widzenia jest związana z

konkretnym typem modelu systemu.



Odbiorca usług

• W tym wypadku punkty widzenia są zewnętrzne

wobec systemu; osoby mające ten punkt widzenia

korzystają z usług systemu.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 18

Model zewnętrznych
punktów widzenia



Reprezentanci tych punktów widzenia współpracują z

systemem przez otrzymywanie usług od systemu oraz

przekazywanie do systemu danych i sygnałów

sterujących.



Punkty widzenia są zewnętrzne wobec systemu,

stanowią zatem naturalny sposób strukturalizacji

procesu określania wymagań.



Dość łatwo jest stwierdzić, czy coś jest punktem

widzenia, czy nie. Reprezentanci punktów widzenia

muszą bowiem w pewien sposób oddziaływać na system.



Punkty widzenia i usługi stanowią dobry sposób

strukturalizacji wymagań niefunkcjonalnych. Każda

usługa może być powiązana z wymaganiami

niefunkcjonalnymi.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 20

Etapy metody VORD

Identyfikacja

punktów widzenia

Strukturalizacja

punktów widzenia

Dokumentacja

punktów widzenia

Przyporządkowywanie

punktów widzenia

do systemu

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 21

Etapy metody VORD
c.d.



Identyfikacja punktów widzenia

• Znajdowanie punktów widzenia, których reprezentanci

korzystają z usług systemu, oraz na wyszukiwaniu
szczególnych usług oferowanych reprezentantom
konkretnych punktów widzenia.



Strukturalizacja punktów widzenia

• Polega na grupowaniu podobnych punktów widzenia w

hierarchie.



Dokumentacja punktów widzenia

• Udoskonalanie opisu znalezionych punktów widzenia i

usług.



Przyporządkowywanie punktów widzenia do systemu

• Znajdowanie obiektów w projekcie obiektowym za pomocą

związanej z punktami widzenia informacji o usługach.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 22

Szablony formularzy i
punktów widzenia

Szablon do punktów widzenia

Odnośnik: Nazwa punktu
widzenia
Atrybuty: Atrybuty z
informacją o

punkcie widzenia
Zdarzenia: Odnośnik do zbioru
scenariu-

szy zdarzeń

opisujących, jak

system

reaguje na zdarzenia w
ramach tego punktu

widzenia
Usługi:

Odnośnik do

zbioru opisów

usługi

Podrzędne Nazwy podrzędnych

PW:

punktów

widzenia

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ć

opisane

za pomocą różnych

notacji
Punkty Lista nazw punktów
widzenia,
widzenia: których
reprezentanci korzy-

stają z usługi

Wymagania Odnośnik do zbioru
wymagań
niefunkcjo- niefunkcjonalnych
ogranicza-
nalne: jących usługę
Dostawca: Odnośnik do listy
obiektów

systemu, które oferują

tę usługę

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 23

Burza mózgów w
trakcie identyfikacji
punktów widzenia

Pytanie

o saldo

Menedżer

Odczyt

transakcji

Zasoby

maszyny

Interfejs

użytkownika

Właściciel

konta

Zdalna

diagnostyka

Karta

skradziona

Niezawodność

Informacje

o koncie

Koszt systemu

Baza danych

klientów

Wypłata

gotówki

Aktualizacja

konta

Zamówienie

wyciągu

Obcy klient

Dziennik

komunikatów

Przelew

środków

Zdalna

aktualizacja

oprogramowania

Zamówienie

czeków

Zwrot karty

Dziennik

transakcji

Drukarka

Rozmiar

oprogramowania

Zatrzymanie

karty

Nieuprawniony

użytkownik

Kasa

banku

Weryfikacja

karty

Przekazywanie

komunikatów

Zabezpieczenia

Pielęgnacja

oprogramowania

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 24

Informacja o usługach
przypisanych do punktów
widzenia

WŁAŚCICIEL
KONTA

OBCY
KLIENT

KASA
BANKU

Lista usług

Lista usług

Lista usług

Wypłata gotówki
Pytania o saldo
Zamówienie
czeków
Wysyłanie
komunikatu
Lista transakcji
Zamówienie
wyciągu
Przelew środków

Wypłata gotówki
Pytania o saldo

Diagnostyka
Dodanie gotówki
Dodanie papieru
Wysłanie
komunikatu

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 25

Dane wejściowe i dane
sterujące związane z
punktami widzenia

WŁAŚCICIEL
KONTA

Dane sterujące Dane
wejściowe

Rozpocznij transakcje Informacje z karty

Anuluj transakcje PIN

Zakończ transakcje Żądana kwota

Wybór usługi Komunikat

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 26

Hierarchia punktów
widzenia

Usługi

Usługi

Inżynier

Menedżer

Kasa

Klient

obcy

Właściciel

konta

Klient

Personel banku

Wszystkie PW

Pytanie o saldo
Wypłata
gotówki

Zamówienie czeków
Wysyłanie komunikatu
Lista transakcji
Zamówienie wyciągu
Przelew środków

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 27

Opis punktu widzenia
klienta i opis usługi
wypłaty 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 PW: Właściciel konta

Odnośnik: Wypłata gotówki
Uzasadnienie: Celem jest ulepszenie
obsługi
klienta i zmniejszenie
liczby
dokumentów
papierkowych
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

PW: Klient
Wymagania
niefunkcjonalne: Wypłacić gotówkę
najpóźniej
po 1 minucie od
potwierdzenia
kwoty
Dostawca: Wypełnić później

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 28



Ludzie zwykle wolą przykłady wzięte z życia niż
abstrakcyjne opisy



Inżynierowie wymagań mogą skorzystać z
informacji zebranych w trakcie dyskusji do
formułowania rzeczywistych wymagań
systemowych.



Scenariusze są szczególnie użyteczne przy
uszczegóławianiu przeglądowego opisu
wymagań. Są opisami przykładowych sesji
interakcyjnych. Każdy scenariusz obejmuje jedną
lub najwyżej kilka możliwych interakcji.

Scenariusze

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 29



Opis stanu systemu na początku scenariusza.



Opis normalnego następstwa zdarzeń
scenariusza.



Opis tego, co może pójść źle, i jak to jest
obsługiwane.



Informacje o innych czynnościach, które można
wykonywać w tym samym czasie.



Opis stanu systemu po zakończeniu scenariusza.

Cechy scenariusza

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 30



Scenariusze zdarzeń są używane w VORD do

dokumentowania zachowania systemu, gdy zajdą

konkretne zdarzenia.



Każde odrębne zdarzenie w interakcji, takie jak

wsunięcie karty do bankomatu albo wybranie

usługi, może być udokumentowane za pomocą

oddzielnego scenariusza zdarzenia.



Obejmują opis przepływu danych, akcji systemu i

wyjątków, które mogą się pojawić.



Aby zapoznać się z przykładem scenariusza

zdarzenia rozważmy schemat, na którym

przedstawiono scenariusz zdarzenia „Zacznij

transakcję”.

Scenariusze zdarzeń

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 31

Konsekwencje dotyczące
diagramów scenariuszy
zdarzeń



Dane odbierane i przekazywane do reprezentantów

punktów widzenia są przedstawione w postaci elips.



Informacja sterująca wchodzi w każdy prostokąt od

góry, a opuszcza z dołu..



Dane opuszczają prostokąty z prawej strony. Jeśli te

dane nie są otoczone elipsą, oznacza to, że są

wewnętrzne dla systemu.



Wyjątki są pokazywane na dole prostokątów. Jeśli

tych wyjątków jest kilka, to oznacza się je

prostokątem.



Nazwa następnego zdarzenia oczekiwanego po

zakończeniu scenariusza jest przedstawiana w

cieniowanym prostokącie

.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 32

Opis wyjątków



Część metody nie zawiera opisu wyjątków



W tym przykładzie:

• Przekroczenie limitu czasu. Klient może nie

wprowadzić

PIN

przed

upływem

wyznaczonego czasu. Karta jest zwracana.

• Karta nieważna. Nie rozpoznano karty.

Karta jest zwracana.

• Karta ukradziona. Rozpoznano kartę jako

skradzioną. Karta jest zatrzymywana.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 33



Przypadek użycia jest metodą opartą na

scenariuszach, służącą do określania

wymagań.



Po raz pierwszy użyto jej w metodzie

Objectory (Jacobson i inni, 1993). Obecnie

stała się podstawowym elementem notacji

UML do opisywania obiektowych modeli

systemu.



W najprostszej postaci w przypadku użycia

definiuje się aktorów biorących udział w

interakcji i wskazuje typ tej interakcji.

Przypadki użycia

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 34

Obsługa wypożyczania

Przypadek użycia
Wypożyczanie

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 35

c

Czytelnik

Obsługa wypożyczania

Zarządzanie użytkownikami

Personel
biblioteki

Dostawa

Obsługa katalogu

Przypadki użycia
biblioteki

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 36

Diagramy przebiegu



Zdefiniowane w UML diagramy przebiegu

mogą służyć do dodawania szczegółowej

informacji do przypadku użycia.



Na takich diagramach przedstawia się

aktorów biorących udział w interakcji,

obiektyw systemie, z którymi komunikują

się aktorzy, oraz operacje powiązane z tymi

obiektami.



Rysunek zawiera przykład takiego

diagramu- interakcję obejmującą nabywanie

i katalogowanie książek w bibliotece.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 37

:

Książki:

Katalog

Sprzedawca książek

Składnik:
Składnik
bibliotek
i

Katalogujący:
Personel biblioteki

Nowy

Usuń

Kataloguj
składnik

Usuń składnik
z katalogu

Nabądź

Diagram przebiegu
zarządzania katalogiem

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 38

Przykłady



Na rysunku pokazano dwa obiekty klas

Składnik biblioteki i Katalog, które biorą udział

w przypadku użycia Zarządzanie katalogiem.



Akcje są wykonywane w kolejności z góry na

dół, a etykietki na strzałkach między aktorami i

obiektami są nazwami operacji.



Po zakupie książki, wykonuje się zatem

operację Nowy na katalogu Nabądź i na

Składniku. Gdy książka jest już dostępna, na

Składniku wykonuje się operację Kataloguj

składnik.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 39

Etnografia



To metoda obserwacji, która może służyć do

rozpoznawania wymagań społecznych i

organizacyjnych.



Analityk pogrąża się w środowisku pracy, w którym

system będzie używany.



Obserwuje codzienną pracę i odnotowuje podstawowe

zadania wykonywane przez pracowników.



Zaleta etnografii jest to, że pomaga odkrywać

niejawne wymagania systemowe odzwierciedlające

rzeczywiste, a nie formalne procesy, w których biorą

udział ludzie.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 40

Skoncentrowana
etnografia



Rozwinięta w projekcie badającym proces

kontroli lotów.



Łączy etnografię z prototypowaniem.



Prototypowanie pomaga w pokierowaniu

etnografią przez identyfikowanie problemów i

pytań, które potem mogą być rozważone przez

etnografa.



Wadą etnografii jest to, że bada ona istniejące

zachowania, które mogą mieć jakieś

historyczne podłoże, które nie jest już

odpowiednie.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 41

Etnografia i
prototypowanie

Analiza

etnograficzna

Analiza

etnograficzna

Prototypowanie

systemu

Prototypowanie

systemu

Ogólne tworzenie

systemu

Ogólne tworzenie

systemu

Narady

Narady

Szczegółowa

etnografia

Szczegółowa

etnografia

Ocena

prototypu

Ocena

prototypu

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 42



Opis wymagań wynikających z
rzeczywistego sposobu pracy
osób, a nie ze sposobu zalecanego
formalne definicje procesów.



Opis wymagań, które wynikają z
kooperacji i świadomości
czynności innych osób.

Cele etnografii

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 43

Zatwierdzanie wymagań



Zatwierdzanie wymagań polega na
wykazaniu, że wymagania naprawdę
definiują system, którego chce użytkownik.



Ponieważ błędy w dokumentacji wymagań
mogą przyczynić się do poważnych
kosztów powtarzania prac po
sukcesywnym wykrywaniu tych błędów w
trakcie tworzenia lub nawet po
rozpoczęciu korzystania z systemu.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 44

Sprawdzenie wymagań



Sprawdzenie ważności.

Użytkownik może być

przekonany, że system powinien spełniać pewne funkcje.



Sprawdzenie niesprzeczności.

Wymagania zapisane

w dokumentacji nie powinny być sprzeczne.



Sprawdzenie kompletności.

Dokumentacja

wymagań powinna zawierać wymagania, w których

zdefiniowano wszystkie funkcje i ograniczenia

zamierzone przez użytkownika systemu.



Sprawdzenie realności.

Znając obecną wiedze

techniczną, należy sprawdzić, czy wymagania mogą być

naprawę zaimplementowane.



Możliwość weryfikacji.

Aby uniknąć późniejszych

sporów między klientem a zleceniobiorcą, wymagania

systemowe zawsze powinny być napisane tak, aby

można było je weryfikować.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 45



Przeglądy wymagań

• Zespół recenzentów systematycznie analizuje

wymagania.



Prototypowanie

• W tym podejściu do zatwierdzania przedstawia się

użytkownikom i klientom wykonywalny model
systemu.



Generowanie testów

• Idealnie byłoby, aby wymagania dało się testować.



Zautomatyzowane sprawdzanie sprzeczności

• Jeśli wymagania wyrażono w modelu systemu za

pomocą strukturalnej lub formalnej notacji, to
narzędzia CASE mogą sprawdzić niesprzeczność
systemu.

Modele zatwierdzania
wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 46

Przeglądy wymagań



Przegląd wymagań jest ręcznym procesem, w
którym wielu czytelników, zarówno ze strony
klienta, jak i zleceniobiorcy, sprawdza
dokumentację wymagań w poszukiwaniu
anomalii i pominięć.



Można też zorganizować go w większej skali z
wieloma uczestnikami sprawdzającymi różne
części dokumentacji.



Przeglądy wymagań mogą być formalne albo
nieformalne. Przeglądy nieformalne polegają na
tym, że zleceniobiorcy rozmawiają o
wymaganiach z największą liczbą uczestników,
jak to jest możliwe.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 47

Sprawdzenie wymagań



Możliwość weryfikacji. Czy wymaganie
wyrażono tak, aby można je praktycznie
sprawdzić?



Zrozumiałość. Czy klienci i użytkownicy
systemu właściwie zrozumieli wymaganie?



Pochodzenie. Czy jawnie zaznaczono źródło, z
którego pochodzi wymaganie?



Giętkość. Czy wymaganie może być zmienione
bez znaczącego wpływu na inne wymagania
systemowe?

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 48

Wymagania zapisane

w języku formalnym

Baza danych wymagań

Raport o błędach

w wymaganiach

Procesor wymagań

Analizator wymagań

Zautomatyzowane
sprawdzanie
niesprzeczności
wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 49



Wymagania stawiane wielkim systemom
oprogramowania zawsze się zmieniają.
Jedną z przyczyn takiej sytuacji jest to, że
systemy te są zwykle budowane po to, aby
rozwiązać problemy „złośliwe”.



W trakcie procesu tworzenia
oprogramowania stopień zrozumienia
problemu stale się zmienia, a zmiany te
mają zwrotny wpływ na wymagania.

Zarządzanie
wymaganiami

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 50



Z wielkich systemów korzysta zwykle bardzo

urozmaicona społeczność użytkowników. Różni

użytkownicy stawiają różne wymagania i przypisuje

im inne priorytety i może to prowadzić do zmiany

wymagań.



Ludzie, którzy płacą za system, i jego użytkownicy to

zwykle różni klienci. Klienci systemu formułują

wymagania wynikające z ograniczeń organizacyjnych

i budżetowych. Te wymagania mogą być w konflikcie

z wymaganiami użytkowników.



Otoczenie technologiczne i gospodarcze systemu

zmienia się. Te zmiany muszą być odzwierciedlone w

samym systemie.

Wymagania stawiane
wielkim systemom

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 51

Ewolucja wymagań

Wstępne
zrozumienie
problemu

Zmienione
rozumienie
problemu

Wstępne
wymagania

Zmienione
wymagania

Czas

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 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. W

szpitalu zawsze będą wymagania dotyczące

pacjentów, lekarzy, pielęgniarek, terapii, itp.



Wymagania zmienne to wymagania, które

prawdopodobnie ulegną zmianie w trakcie tworzenia

systemu albo po przekazaniu go do użytkowania.

Takimi wymaganiami są na przykład wymagania,

które wynikają z polityki zdrowotnej rządu.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 53

Klasyfikacja wymagań
zmiennych



Wymagania zmieniające się

• Zmieniają się na skutek zmian środowiska,

w którym działa firma.



Wymagania pojawiające się

• Pojawiają się w trakcie procesu tworzenia

w miarę coraz lepszego rozumienia

systemu przez klienta.



Wymagania wynikowe

• Wynikają z wdrożenia systemu

komputerowego.



Wymagania zgodności

• Zależą mów lub procesów gospodarczych

wewnątrz firmy.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 54



W trakcie tej fazy zarządzania wymaganiami należy podjąć

decyzje dotyczące następujących zagadnień:

• Oznakowanie wymagań

» Każde wymaganie musi być unikatowo oznakowane

tak, aby można było robić do niego odnośniki z

innych wymagań i używać tego wymagania przy

ocenianiu pochodzenia.

• Proces zarządzania zmianami

» Jest to zbiór czynności szacowania wpływu i kosztu

zmian.

• Strategia śledzenia pochodzenia

» Te strategie definiują zależności między

wymaganiami i projektem systemu, które należy

odnotowywać.

• Użycie narzędzi CASE

» Zarządzanie wymaganiami polega na przetwarzaniu

ogromnych ilości informacji o wymaganiach.

Planowanie zarządzania
wymaganiami

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 55



Możliwość śledzenia pochodzenia jest
ogólną cechą specyfikacji wymagań



Trzy typy informacji o pochodzeniu, które
warto gromadzić

• Informacje o uczestnikach, którzy zaproponowali dane

wymagania, wraz z ich uzasadnieniem..

• Informacje o uzależnieniu wymagań wiążą w

dokumentacji wymagań te wymagania, które od siebie
zależą.

• Informacje o uzależnieniu projektu wiążą wymagania z

modułami projektu, które implementują te wymagania.

Pochodzenie

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 56

Macierz zależności

Id

wymagań

1.1

1.2

1.3

2.1

2.2

2.3

3.1

3.2

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

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 57



Przechowywania wymagań

• Wymagania należy gromadzić w zabezpieczonej i

administrowanej składnicy danych, która jest

dostępna dla wszystkich biorących udział w

procesie inżynierii wymagań.



Zarządzania zmianami

• Proces zarządzania zmianami jest znacznie

prostszy, gdy aktywnie korzysta się ze

wspomagania narzędzi.



Zarządzania zależnościami

• Wspomaganie narzędzi przy śledzeniu zależności

umożliwia wykrywanie powiązanych wymagań.

Korzystanie z narzędzi
CASE w zarządzaniu
wymaganiami

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 58



Zarządzanie zmianami wymagań należy

zastosować do wszystkich postulowanych

zmian wymagań.



Trzy podstawowe kroki:

• Analiza problemu i specyfikacja zmiany.

Proces rozpoczyna się od rozpoznania

problemu z wymaganiem lub czasem od

konkretnej propozycji zmiany.

• Analiza zmiany i ocena kosztów.

Korzystając z informacji o uzależnieniu i

ogólnej wiedzy o wymaganiach systemowych,

ocenia się wpływ proponowanej zmiany.

• Implementacja zmiany. Modyfikuje się

dokumentacje wymagań oraz, jeśli zachodzi

taka potrzeba, również projekt i

implementacje systemu.

Zarządzanie zmianami
wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 59

Rozpoznany
problem

Implementacja

zmiany

Analiza zmiany

i ocena kosztów

Analiza problemu

i specyfikacja

zmiany

Skorygowan
e
wymagania

Zarządzanie zmianami
wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 60

Główne tezy



Proces inżynierii wymagań obejmuje
studium wykonalności, określanie i
analizowanie wymagań, specyfikowanie
wymagań, zatwierdzanie wymagań oraz
zarządzanie wymaganiami.



Analizowanie wymagań to proces
iteracyjny, który obejmuje rozpoznanie
dziedziny, zbieranie wymagań,
klasyfikację, strukturalizację, nadawanie
priorytetów i zatwierdzanie.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 61

Główne tezy



Różni użytkownicy systemu mogą stawiać

różne wymagania. Wszystkie złożone

systemy należy więc analizować z kilku

punktów widzenia. Punkty widzenia

odpowiadają źródłom lub przeznaczeniom

danych, różnym reprezentacjom systemu

albo bytom spoza systemu, które

korzystają z jego usług.



Czynniki społeczne i organizacyjne mają

silny wpływ na wymagania systemowe i

od nich głównie zależy, czy system będzie

faktycznie używany, czy nie.