1

Inżynieria oprogramowania

wykład 9

Zasady analizowania wymagań

2/23

Analiza wymagań - wstęp



stanowi pomost między inżynierią systemów
(analiza, modelowanie, zarządzanie wymaganiami
stawianymi systemowi) a projektowaniem
oprogramowania



podmioty biorące udział w analizie wymagań:



klienci → powinni precyzyjnie określać swoje
oczekiwania wobec programu



twórcy (analitycy)→ przyjmują uwagi klienta, analizują
je, rozwiązują problemy, negocjują

3/23

Wyniki analizy wymagań



określenie roli oprogramowania (bycie produktem -
przetwarzanie danych lub dostarczanie produktu –
kontrola, sterowanie, tworzenie)



określenie funkcjonalności programu



określenie danych przetwarzanych przez program



określenie wyników działania programu



wspomaganie jakości produktu



budowa modeli: danych, architektury, interfejsów

4/23

Czynności analizy wymagań



rozpoznanie problemu → poznanie aspektu problemu z

punktu widzenia klienta – użytkownika, poprzedza je

zapoznanie się ze specyfikacją systemu i planem

przedsięwzięcia,



ocenianie problemu, szukanie rozwiązania →

określenie kontekstu problemu, ustalenie rodzaju

przepływu danych, funkcji systemu, zachowania w

konkretnym przypadku, sposobu komunikowania się, co

może wspomóc uzyskanie rozwiązania



modelowanie → podstawa projektowania

oprogramowania i specyfikowania, tworzenie modelu

systemu ułatwiającego analizę sterowania, przepływu i

przetwarzania danych, zachowania programu



specyfikowanie, zastępowane czasem prototypowaniem



przegląd

5/23

Ustalanie wymagań dla
oprogramowania – wiedza ogólna



dla kogo przeznaczone ma być nowe
rozwiązanie



kto będzie go używał



korzyści wynikające z wprowadzenia nowego
rozwiązania



czy problem zgłaszany przez klienta można
rozwiązać inaczej

6/23

Ustalanie wymagań dla oprogramowania
– lepsze poznanie istoty problemu



określenie pojęcia: dobry wynik działania programu



w jakich sytuacjach / problemach może mieć
zastosowanie nowego rozwiązania



środowisko działania nowego produktu



czy znane są wymagania związane z efektywnością
produktu (efektywność – skuteczność, sprawność,
wydajność: efektywność czasowa, zużycie zasobów, itp..)



czy znane są ograniczenia w sposobie funkcjonowania
produktu (dane wejściowe i wyjściowe, środowisko pracy
oraz sprzęt, specyficzne wymagania użytkowników)

7/23

Ustalanie wymagań dla oprogramowania
– efekty spotkania z klientem



czy klient jest osobą kompetentną do udzielania
informacji na poruszane tematy, a odpowiedzi
są wiążące



czy są inne osoby potrafiące udzielić
dodatkowych informacji



czy są inne pytania które powinny zostać
dodatkowo postawione

8/23

Techniki ułatwiające
specyfikowanie aplikacji - FAST



FAST – facilitated application specification
techniques



techniki FAST nastawione są na ścisłą
współpracę twórców i klientów (a często bywa
odwrotnie, obie strony traktują się jak
przeciwnicy)



zespoły złożone z twórców i klientów zajmują
się identyfikacją problemów i wspólnie szukają
rozwiązań, tworzą specyfikację wymagań

9/23

Główne cechy spotkań wg FAST



spotkania na neutralnym gruncie



ustalone wcześniej reguły spotkań



swobodny styl wymiany poglądów



dyskusja na wszystkie istotne tematy



cel spotkania: identyfikowanie problemów,
szukanie rozwiązań, negocjacja dalszych
możliwości, specyfikacja wymagań

10/23

Jakość rozwijania funkcji QFD



QFD – quality function deployment



jest to technika z kategorii zarządzania jakością,
wspomagająca tłumaczenie potrzeb klienta na
techniczne wymagania dla oprogramowania



celem jest jak najlepsze zrozumienie wymagań
klienta



technika ta została opracowana w Japonii,
pierwsze zastosowanie: Mitsubishi Heavy
Industries (lata 70. XX. wieku)

11/23

Wymagania w technice QFD*



wymagania normalne → wyrażone przez klienta
podczas spotkań z analitykami, spełnienie ich oznacza
satysfakcję klienta (funkcje produktu, interfejsy,
efektywność)



wymagania oczekiwane → takie o których klient nie
wspomniał, gdyż uważał je za oczywiste (łatwość obsługi i
instalacji, poprawność działania), niespełnienie ich oznacza
niezadowolenie klienta



wymagania ekscytujące → ponad oczekiwania klienta,
spełnienie ich oznacza duże zadowolenie klienta, np.
dodatkowe możliwości konfiguracyjne (dostosowywanie
interfejsu, itp.)

* R. Zultner: „Quality Function Deployment for Software: Satysfying customers”,
American Programmer, 1992

12/23

Przypadki użycia



zbiór scenariuszy, zbiór ciągów zdarzeń wykonywanych

przez system, opisy sposobów użycia systemu



sporządzane w celu ułatwienia zdefiniowania wymagań

stawianych oprogramowaniu



pierwszymi krokami są identyfikacja osób i sprzętu

korzystającego z systemu



stanowią opis działania osoby w interakcji z systemem



może zawierać ograniczenia czasowe lub inne ograniczenia



przypadki użycia mogą być różnie oceniane przez

użytkowników, można obliczyć średni priorytet każdego

przypadku użycia stosując go w modelu przyrostowym

proc. wytw. do określania funkcji systemu

przygotowywanych w 1. kolejności



realizacja: np. diagram przypadków użycia (UML)

13/23

Zasady analizowania
oprogramowania



identyfikacja dziedziny problemu



określenie funkcjonalności oprogramowania



określenie zachowania programu w zależności
od czynników zewnętrznych



określenie struktury warstwowej/hierarchicznej
systemu zawierające modele informacji, funkcji
i zachowań systemu



kierunek analizy: od cech najistotniejszych do
szczegółów

14/23

Reguły analizowania wymagań *



zrozumienie problemu (zapobieganie sytuacji: świetny
program ale rozwiązuje nie to co potrzeba”)



zastosowanie prototypów - ułatwia ocenę przez
użytkownika



zapamiętanie źródła i uzasadnienia każdego wymagania



ocena wymagań z różnych punktów widzenia,
zapobiega powstaniu sprzeczności i przeoczeń



uporządkowanie wymagań wg ważności



eliminacja niejasności, realizowana poprzez
wykonywanie formalnych przeglądów technicznych

* A. Davis: „201 principles of software development”, McGraw-Hill 1995

15/23

Dziedzina informacyjna



jest podstawową czynnością analizy wymagań



obejmuje:



model danych - obiekty danych oraz zdarzenia związane z ich
przetwarzaniem, należy zidentyfikować istniejące między nimi
zależności



przepływ informacji – określenie zmian dotyczących danych i
zdarzeń przemieszczającymi się między różnymi częściami
systemu



strukturę informacji – organizacja elementów danych i
zdarzeń (np. struktura drzewiasta, tablica itp.), związki między
elementami struktury, zapis informacji w strukturach

16/23

Modelowanie



tworzenie modeli ułatwia zrozumienie funkcjonowanie
projektowanego obiektu



model oprogramowania musi przedstawiać przetwarzane
informacje, funkcjonalności związane z przetwarzaniem
danych i zachowanie systemu podczas przetwarzania
danych



modelowanie obejmuje



model funkcji → pobieranie, przetwarzanie i udostępnianie
danych, tworzone od prostych modeli kontekstowych do bardziej
szczegółowych



model zachowań → opis reakcji na zdarzenia, opis możliwych
stanów i zdarzeń mogących prowadzić do zmian stanów

17/23

Dzielenie



zalecane do lepszej obsługi dużych
skomplikowanych problemów



pierwszym krokiem jest utworzenie
hierarchicznej prezentacji funkcji lub dziedziny
informacyjnej



w kolejnych krokach wykonywany jest podział
najwyższego elementu:



przemieszczając się w dół hierarchii (zwiększanie
szczegółowości), lub



przemieszczając się w bok (pozostając na jednym
poziomie) i dekomponując problem

18/23

Prototypowanie



wykonanie prototypu może pomóc w określeniu wymagań



prototyp można rozwijać i zmieniać



udoskonalony prototyp może stać się finalną wersją
oprogramowania



prototyp podlega ocenie przez klienta ale także przez
twórców programu



typy prototypów



zamknięte → jednokrotnego użycia, wykorzystywany do
ogólnego przedstawienia wymagań, potem niepotrzebny, nowa
wersja tworzona innymi środkami



otwarte → wielokrotnego użycia, stosowany również na etapach
projektowania i implementacji, wstępna wersja produktu finalnego

19/23

Wybór prototypu (1)



prototyp zaleca się do złożonych aplikacji,
używających niebanalnych algorytmów i
zaawansowanych metod przetwarzania danych,
cechujących się intensywną komunikacją z
użytkownikiem



jeżeli przygotowanie prototypu wymaga
napisania dużej ilości kodu, to prototypowanie
nie jest zalecane



czasem wykonywany jest najpierw podział na
mniejsze moduły i wykonywane są ich
prototypy

20/23

Wybór prototypu (2) *

* S. Andriole: „Rapid application prototyping”, QED 1992

nie

nie

tak

tak
tak
tak

tak

tak

tak/nie

tak
nie
nie

tak

tak

tak/nie

nie

tak
tak

Czy ustalono rodzaj i zastosowanie
systemu?
Czy problem można modelować?
Czy klient jest pewny podstawowych
wymagań stawianych systemowi?
Czy wymagania są znane i stabilne?
Czy wymagania są niejasne?
Czy w wymaganiach występują
sprzeczności?

Konieczna

dodatkowa

analiza

Prototyp

wielokrotnego

użycia

Prototyp

jednokrotnego

użycia

Pytanie

21/23

Specyfikowanie wymagań –
zasady *



oddzielenie spojrzenia abstrakcyjnego na funkcje

systemu od szczegółów implementacji



określenie modelu oczekiwanego zachowania systemu

(dane i reakcje na zdarzenia)



kontekst działania programu, sposób komunikacji z

innymi elementami systemu



środowisko aplikacji



przygotowanie modelu opisującego działanie widziane

oczami użytkownika



specyfikacja odporna na przeoczenia i łatwa do

uzupełniania



możliwość łatwej zmiany specyfikacji

* R. Balzer, N. Goodman: „Principles of good specification and their implications for
specification languages”, Addison-Wesley 1986

22/23

Przegląd specyfikacji



specyfikacja jest podstawą późniejszych prac, dlatego
musi być wykonana z należytą starannością



klienci i twórcy powinni dokonać przeglądu specyfikacji



należy sprawdzić kompletność i spójność specyfikacji,
dokładność opisu funkcji i zachowań, dziedziny
informacyjnej



po wykonaniu przeglądu następuje akceptacja
specyfikacji



możliwe są dalsze zmiany w specyfikacji, jednak mogą
one prowadzić do zmiany kosztów i harmonogramu
realizacji przedsięwzięcia

25

Dziękuję za uwagę

źródło: „Praktyczne podejście do inżynierii oprogramowania”, R.S. Pressman