Treść książki
Przejdź do opcji czytnikaPrzejdź do nawigacjiPrzejdź do informacjiPrzejdź do stopki
3.Cyklżyciaoprogramowania
3.4.analizawymagań
Jesttofaza,wktórejanalityk(lubgrupa)musiprzekształcićpomysłwwy-
maganiawobecsystemu.Opierającsięnawcześniejszychfazachorazideach
pomysłodawcy,musimystworzyćmodellubdokumentopisujący,jakprodukt
będziewyglądałidziałałpopowstaniu.Zazwyczajmówimyowymaganiach
funkcjonalnych,czylizestawiefunkcjidanegoproduktu.Czasamisątorów-
nieżcharakterystykiniefunkcjonalne,takiejakużyteczność(usability)czy
wydajność(efciency).
Wfazieanalizywymagańjestnadawanybiegprocesomlubczynnościom
ciągłymwprocesie.Zaczynamymówićoinżynieriiwymagańjakoopozyski-
waniuwymagańizarządzaniunimi.Określasięteż,przynajmniejwstępnie,
mechanizmwprowadzaniazmian,nazywanypowszechnieprocesemzarzą-
dzaniazmianą.
defnicjezzakresuanalizywymagań
Wymaganietowarunekorazumiejętnośćpotrzebnaużytkownikowidorozwią-
zaniaproblemulubosiągnięciacelu.
Procesinżynieriiwymagańobejmujezidentyfikowanie,przeanalizowanie
izatwierdzeniewymagańwobecsystemu.
Zarządzaniewymaganiamitoproceszarządzaniazbieraniemizmianami
wwymaganiachpodczastworzeniasystemu.
Grupanarzędzimożliwychdoużyciapodczasdefiniowaniawymagańjest
bardzoograniczona.Służąonedopozyskaniawymagańprzezwspółpracę
zezleceniodawcą,np.możemyprzeprowadzićwywiadzklientemlubpo-
prosićowypełnieniekwestionariusza.Alemożemyteżzorganizowaćburzę
mózgów,podczasktórejzbierzemywszystkiewymagania(równieżdotych-
czasukryte).
Notacjawymagańmożebyćbardzosformalizowanaiopartananor-
mach,takichjakIEEE1233czyIEEE830.Wymaganiamogąbyćrównież
przypadkamiużycialubteżhistoryjkamiużytkownika(userstories).Taki
zapiszorientowanynaużytkownikaopisujezapomocąprzykładówlub
scenariuszy,wjakisposóbproduktbędzieużywanyprzezjegodocelowych
odbiorców.
Błędypopełnianewtejważnejfazieprowadządowytworzeniaproduk-
tu,któryniespełniaoczekiwańklienta.Musimypamiętać,żeprzekształ-
ceniepotrzebwproduktmusiangażowaćobiestrony–klientaiwytwórcę.
24
