©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

Zawartość



Studium wykonalności



Określanie i analizowanie wymagań



Zatwierdzanie wymagań



Zarządzanie wymaganiami

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 4

Proces inżynierii
wymagań



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ń

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 5

Proces inżynierii
wymagań

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ń

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 6

Studium wykonalności



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?

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 7

Przeprowadzanie studium
wykonalności



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?

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 8

Określanie i analizowanie
wymagań



Po wstępnych studiach wykonalności następną 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 9

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 10

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 11

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 12

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 13

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 14

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
specjalistyczne usługi dla wybranych
klientów.



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

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 15

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 16

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 17

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 19

Metoda 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 20

Metoda VORD (Viewpoint-
Oriented Requirements
Definition)



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 21

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 22

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 23

Informacja o usługach
przypisanych do punktów
widzenia

WŁAŚCICIEL
KONTA

OBCY
KLIEN
T

KASA
BANK
U

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 24

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 25

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 26

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 27

Scenariusze



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.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 28

Cechy scenariusza



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.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 29

Scenariusze zdarzeń



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ę”.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 30

Scenariusz zdarzenia
„Zacznij transakcję”

l

r

l

r

I

PIN

PIN

PIN

Wsunięto kartę

Numer konta
PIN

Karta nieważna

Num
er

kont
a

Kart
a

Poproś
o PIN

Sprawdź
użytkowni
ka

Użytkownik OK

Wybierz
usługę

Zły

Wprowadź
ponownie PIN

Zły

Zwróć
kartę

Przekrocze
nie
limitu
czasu

Zwróć kartę

Zwróć kartę

Karta
nieważna

Karta
skradziona

Zatrzymaj
kartę

©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 i opuszcza każdy

prostokąt od góry.



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

Przypadki użycia



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.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 34

Przypadek użycia
Wypożyczanie

Obsługa wypożyczania

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 35

Przypadki użycia
biblioteki

ding service

r administra

talog servic

Czytelnik

Obsługa wypożyczania

Zarządzanie użytkownikami

Personel
biblioteki

Dostawa

Obsługa katalogu

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 36

Diagram przebiegu
zarządzania katalogiem

:

:

Książki:
Katalog

:

:

Sprzedawca książek

Składnik:
Składnik biblioteki

Katalogujący:
Personel biblioteki

Nowy

Usuń

Kataloguj
składnik

Usuń składnik
z katalogu

Nabądź

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 37

Czynniki społeczne i
organizacyjne



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 katalagowanie książek w bibliotece.

©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

Wykorzystanie etnografii
do badania prac



Rzeczywista praktyka pracy biurowej jest znacznie
bogatsza, bardziej złożona i dynamiczna niż
przewidywana przez proste modele w systemach
automatyzacji biura.



Różnica między zakładem, a rzeczywistym trybem
pracy jest najważniejsza przyczyną nikłego wpływu
tych systemów biurowych na wydajność pracy.



Innymi studiami etnograficznymi nad
rozpoznawaniem wymagań systemowych były
prace nad systemem kontroli lotów i rozmaite
działania projektowe.

©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

Cele etnografii



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.

©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.



Sprawdzenie realności. 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

Metody zatwierdzania
wymagań



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.

©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

Zautomatyzowane
sprawdzanie
niesprzeczności wymagań

Wymagania zapisane

w języku formalnym

Baza danych wymagań

Raport o błędach

w wymaganiach

Procesor wymagań

Analizator wymagań

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 49

Zarządzanie wymaganiami



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.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 50

Nowe wymagania



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.

©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 zmienione 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 zmienne

•

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

Planowanie zarządzania
wymaganiami



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.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 55

Pochodzenie



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



Trzy typy informacji o pochodzeniu

•

Informacje o pochodzeniu wiążą wymagania z
uczestnikami, którzy je zaproponowali, i z
uzasadnieniami tych wymagań.

•

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.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 56

Macierz zależności

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 57

Korzystanie



Przechowywania wymagań

•

Wymagania należy gromadzić w zabezpieczonej i
administrowanej składnicy danych, która jcst
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ń.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 58

Zarządzanie zmianami
wymagań



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.

©Ian Sommerville 2000

Inżynieria oprogramowania, Rozdział 6

Slide 59

Zarządzanie zmianami
wymagań

Rozpoznany
problem

Implementacja

zmiany

Analiza zmiany

i ocena kosztów

Analiza problemu

i specyfikacja

zmiany

Skorygowa
ne

wymagani
a

©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 maja silny
wpływ na wymagania systemowe i od nich
głównie zależy, czy system będzie faktycznie
używany, czy nie.