Team Se@Msi: Meranie v softvérovom inžinierstve. - FIIT STU ...

64 Eseje
zákazník od začiatku detailne vie, čo vlastne chce. Preto je intenzívny styk
tvorcov systému so zákazníkom veľmi dôležitý [Reifer00].
Analytik musí preniknúť do problémovej oblasti, ktorej sa vyvíjaný
softvérový systém týka. Jeho hlavnou úlohou je získať požiadavky od
zákazníka. Analytik by mal získať jasnú predstavu definície požiadavky.
Zapísať si nielen ako znie požiadavka, ale aj kto ju vyslovil a čo ho k tomu
viedlo. Zákazník by mal vysvetliť, prečo je to tak.
Analytik by mal identifikovať, čo vlastne zákazník chce, aké sú jeho
očakávania týkajúce sa výkonnosti systému a aké sú rozhrania s inými
systémami. Získané požiadavky musí analytik zapísať a overiť. Mal by
špecifikovať funkcie, ktoré má systém poskytovať a nie ako navrhnúť
daný systém. Musí však vedieť poradiť, čo je a čo nie je technicky možné
zrealizovať (najmä v súvislosti s ohraničeniami konkrétneho projektu).
Niekedy musí zjednotiť rôzne pohľady na výsledný systém. Zákazník
a používateľ často nie sú totožní. Zákazník sa snaží o maximálnu
efektivitu vynaložených prostriedkov, zatiaľ čo používateľ vyžaduje
maximálne pohodlie počas práce so systémom. Rozličné skupiny
používateľov môžu mať rôzne predstavy o systéme.
Podceňovať špecifikáciu požiadaviek sa nevypláca
Niektoré vývojárske tímy podceňujú špecifikáciu požiadaviek [Berry].
Charakteristický výrok, ktorý počuť z úst analytika, je takýto: „Ľudia,
začnite implementovať, ja idem vypátrať, čo zákazník chce!” Manažéri
niektorých tímov síce uznávajú, že špecifikácia požiadaviek je veľmi
dôležitá, no napriek tomu tvrdia: „Nemáme čas na dôkladnú
špecifikáciu, musíme implementovať, aby sme stihli termín
odovzdania.“
Nuž a napokon extrémny názor manažérov tímov, ktoré sa naplno
vrhnú do vývoja systému bez stanovenia špecifikácie požiadaviek: „Nikdy
sme nenapísali dokument špecifikácie a napriek tomu sme stále
úspešní.“ Boehm prirovnáva tieto tímy k cestovateľom, ktorí sa vybrali na
dlhú cestu bez mapy.
Vytvárať prototyp sa určite oplatí
Pri prvom kontakte potenciálneho používateľa s prototypom systému
dochádza často k dramatickej zmene požiadaviek, najmä tých, ktoré sa
týkajú používateľského rozhrania systému. Dochádza k tzv. IKIWISI
efektu (angl. I’ll Know It When I See It).
Používatelia pred dodaním prototypu často nevedia povedať, čo
vlastne chcú, no teraz to pomenujú vcelku presne. Takisto dokážu určiť,
čo vlastne ani nechcú a nepotrebujú. Na základe týchto reakcií a
pripomienok sa upresňuje špecifikácia požiadaviek na systém. Pomocou
prototypovania si obe zúčastnené strany – analytik a zákazník vyjasňujú
nielen požiadavky, ale aj ich interpretáciu. Pri prototypovaní platí