4. Reikalavim迭 specifikavimas Reikalavim迭 specifikavimas tai dokumento, kuriame pateikiami surinkti ir i邸analizuoti reikalavimai P町, parengimas taip, kad j眺 b笛t迭 galima sistemingai per転i笛rti, vertinti ir patvirtinti
5. Reikalavim迭 specifikacijos dokument迭 tipai Sudtingoms sistemoms da転niausiai yra paruo邸iami trij迭 tip迭 reikalavim迭 specifikacijos dokumentai: sistemos apra邸ymas sistemos reikalavim迭 specifikacija P町 reikalavim迭 specifikacija Nedideli迭 sistem迭 atveju da転niausiai yra parengiamas tik treiasis i邸 auk邸iau pamint迭 dokument迭
6. Sistemos apra邸ymo dokumentas (1) Sistemos apra邸ymo dokumentas dar vadinamas vartotojo reikalavim迭 dokumentu arba technine u転duotimi Jame pateikiami auk邸iausio lygio sistemos reikalavimai, suformuluoti i邸 dalykins srities puss
7. Sistemos apra邸ymo dokumentas (2) is dokumentas skirtas sistemos u転sakovams, vartotojams, analitikams, todl jame da転nai bus sutinkami j迭 dalykinje srityje vartojami terminai Sistemos apra邸ymo dokumente da転niausiai yra i邸vardijami sistemai keliami tikslai, apribojimai, apra邸oma jos veikimo aplinka, pateikiami verslo proces迭, kuriuos realizuos sistema, modeliai
8. Sistemos reikalavim迭 specifikacijos dokumentas Sistemos reikalavim迭 specifikacijos dokumentas yra reikalingas tokio tipo sistemoms, kaip mobil笛s telefonai, buitin technika ir pan. Jose P町 sudaro tik nedidel dal眺, o reikalavimai jai i邸plaukia i邸 reikalavim迭 visai sistemai Program迭 in転inerija nenagrinja sistemos reikalavim迭 specifikacijos dokumento sudarymo, nes jos tyrimo objektas yra P町 k笛rimas
9. P町 reikalavim迭 specifikacijos dokumentas (1) P町 reikalavim迭 specifikacijos dokumentas yra sutarties tarp sistemos u転sakovo ir sistemos k笛rjo pagrindas, nes jame yra apra邸oma, k sukurta sistema turs daryti ir ko ne P町 reikalavim迭 specifikacijos dokumentas leid転ia atlikti grie転t joje pateikt迭 reikalavim迭 眺vertinim, prie邸 pradedant P町 projektavimo etap
10. P町 reikalavim迭 specifikacijos dokumentas (2) Pagal P町 reikalavim迭 specifikacijos dokument, galima 眺vertinti projekto snaudas, rizikas ir sudaryti detal迭 jos 眺gyvendinimo plan P町 reikalavim迭 specifikacijos dokumento pagalba, sistema yra 眺diegiama vartotoj迭 darbo vietose, atliekami joje aptikt迭 klaid迭 pataisymai bei P町 papildymai naujomis f-jomis
11. Reikalavim迭 u転ra邸ymo b笛dai Da転niausiai reikalavimai P町 yra u転ra邸omi nat笛ralia kalba, taiau reikalavim迭 specifikacijos dokumente ji gali b笛ti papildyta formaliais arba pusiau formaliais paai邸kinimais Grafins notacijos naudojimas leid転ia kai kuriuos reikalavimus u転ra邸yti tiksliau, negu naudojant tik nat笛rali kalb Grafin notacija turi b笛ti parenkama atsi転velgiant 眺 specifikacijos k笛rj迭 ir skaitytoj迭 転inias bei patirt眺
13. Volere 邸ablono kilm Volere 邸ablonas buvo sukurtas remiantis ilgamete darbo, konsultacij迭 ir tyrim迭 reikalavim迭 in転inerijos srityje patirtimi Volere 邸ablono autoriai yra James ir Suzanne Robertson Detali informacija apie Volere pateikiama internete adresu: http://www.systemsguild.com
14. Volere 邸ablono strukt笛ra (1) Projekto varovai Sistemos paskirtis U転sakovai, pirkjai ir kiti sistema suinteresuoti asmenys Vartotojai
15. Volere 邸ablono strukt笛ra (2) Projekto apribojimai 町pareigojantys apribojimai Termin迭 転odynas Svarb笛s faktai ir prielaidos
16. Volere 邸ablono strukt笛ra (3) Funkciniai reikalavimai Veiklos sfera Produkto veikimo sfera Funkciniai reikalavimai ir reikalavimai duomenims
17. Volere 邸ablono strukt笛ra (4) Nefunkciniai reikalavimai Reikalavimai sistemos i邸vaizdai Reikalavimai panaudojamumui Reikalavimai veikimo charakteristikoms Reikalavimai vykdymo slygoms Reikalavimai sistemos prie転i笛rai Reikalavimai saugumui Kult笛riniai-politiniai reikalavimai Teisiniai reikalavimai
18. Volere 邸ablono strukt笛ra (5) Projekto i邸eiga Atviri klausimai (problemos) Egzistuojantys sprendimai Naujos problemos U転daviniai Pritaikymas Rizikos Snaudos Vartotojo dokumentacija ir apmokymai Perspektyviniai reikalavimai Idjos sprendimams
20. Vartotojo problema arba projekto k笛rimo pagrindimas (1) Pateikiamas trumpas vartotojo atliekamos veiklos apra邸ymas ir apib笛dinama situacija, kuri slygojo kuriamos P町 u転sakym (vartotojo problema) Keliais sakiniais apra邸oma, kokias f-jas kuriama P町 turi leisti atlikti savo vartotojams 町vertinama, ar vartotojo problema yra pakankamai rimta, kodl ir kaip j reikt迭 i邸sprsti
21. Vartotojo problema arba projekto k笛rimo pagrindimas (2) Vartotojo problemos charakteristika gali b笛ti visi邸kai trumpa, pavyzd転iui: Klientai nepatenkinti, kad u転sakymas 眺vykdomas per 10 dien迭 Da転nai pateikiamas 転ymiai platesnis tam tikros veiklos apra邸as, atskleid転iant pagrindines problemas
22. Vartotojo problema arba projekto k笛rimo pagrindimas (3) Galimas atvejis, kad problemos nra, taiau yra poreikis (galimyb) plsti tam tikr veikl - tuomet tokia galimyb turi b笛ti apra邸yta
23. Projekto tikslai (1) Apra邸oma, ko norima i邸 kuriamos sistemos, k ji turi atlikti, kaip ji 眺takos vartotojo atliekamos veiklos tiksl迭 skming pasiekim ia nereikt迭 daug prira邸yti. Pakanka kuriamos sistemos trumpo tiksl迭 (paskirties) paai邸kinimo Tiksl迭 apra邸e neturt迭 b笛ti specifini迭 reikalavim迭, kuriuos tikslai b笛tent ir padengia
24. Projekto tikslai (2) Jei tikslas yra ai邸kus, tuomet jis turi atspindti tam tikr naud ar sistemos teikiamus privalumus 町vardinami trys pagrindiniai privalumai (naudos atvejai): rinkos vert operacij迭 kainos suma転inimas paslaug迭 kiekio ir kokybs padidinimas klientui
25. Projekto tikslai (2) Jei tikslas yra ai邸kus, tuomet jis turi atspindti tam tikr naud ar sistemos teikiamus privalumus 町vardinami trys pagrindiniai privalumai (naudos atvejai): rinkos vert operacij迭 kainos suma転inimas paslaug迭 kiekio ir kokybs padidinimas klientui
26. U転sakovai (1) U転sakovas tai asmuo, kuris apmoka sistemos k笛rimo darbus ir taps 邸ios sistemos savininku Da転nai tai asmuo, esantis sistemos galutinio vartotojo padalinio vadovu. iame punkte nurodomi 邸io asmens duomenys Kartais u転sakovu gali b笛ti keli asmenys
27. U転sakovai (2) U転sakovas priima galutin眺 produkt (sistem), todl turi b笛ti juo patenkintas Jei sistema kuriama savoms reikmms, tai u転sakovas ir pirkjas gali b笛ti tas pats asmuo Jei sistema kuriama rinkai (i邸ors vartotojams), tuomet u転sakovu gali b笛ti marketingo skyrius, kur眺 atstovauja 邸io skyriaus darbuotojas
28. Pirkjai (1) Pirkjas tai sistem perkantis asmuo Jei sistema skirta savoms reikmms, tai pirkjas yra asmuo, kuris priima galutin眺 sprendim, ar sistema reikalinga. Tai gali b笛ti padalinio, kuriame diegiama sistema, vadovas, arba visos organizacijos vadovas Jei sistema skirta rinkai, tai pirkjas yra sistem 眺sigyjani organizacij atstovaujantis asmuo
29. Pirkjai (2) iuo atveju reikia pateikti toki pirkjo charakteristik, kad reikalavim迭 analitikas galt迭 reikalavimus pateikti 眺vertindamas pirkjo pageidavimus Jei pirkj atstovauja sistem platinanios organizacijos marketingo skyrius, tuomet jie turi pateikti kuo tikslesn numatom迭 faktini迭 pirkj迭 charakteristik Sistema turi b笛ti kuriama patenkinant pirkjo tikslus ir u転sakovo apribojimus (reikalavimus)
30. Kiti suinteresuoti asmenys Pateikiama informacija apie kitus sistemos k笛rim 眺takojanius asmenis: vadovyb arba projekto rmjai veiklos srities ekspertai techniniai specialistai projektuotojai marketingo specialistai projekto vadovai testuotojai ir kokyb tikrinantys asmenys teisininkai
31. Vartotojai (1) Tai asmen迭, kurie betarpi邸kai naudosis sistema, sra邸as Kiekvienai vartotoj迭 kategorijai reikia nurodyti toki informacij: Vartotojo kategorija Vartotojo sprend転iami u転daviniai (atliekamos funkcijos) Patirtis dalykinje srityje (naujokas, eilinis darbuotojas, srities specialistas) Patirtis informacinse technologijose (naujokas, patyrs, informatikas) Papildomos vartotojo charakteristikos, turinios 眺tak reikalavimams bei sistemos savybms
32. Vartotojai (2) Kiekvienai vartotoj迭 grupei rekomenduojama suteikti prioritet Prioritetai gali b笛ti: Svarbiausi vartotojai j迭 nuomon ir pageidavimai svarbiausi Antraeiliai vartotojai jei kyla konfliktas su pirmja grupe, tai j迭 nuomon turi didesn 眺tak Nesvarb笛s (atsitiktiniai) vartotojai
34. Apribojimai sprendimui (1) Pateikiami i邸ankstiniai apribojimai sistemos k笛rimo eigai ar jos charakteristikoms bei j迭 atsiradimo prie転astys Jie turi grie転to reikalavimo pob笛d眺, todl juos reikia tiksliai apra邸yti, nepamir邸tant numatyti, kaip galima i邸matuoti (testuoti) j迭 laikymsi sukurtoje sistemoje iuos apribojimus da転niausiai pateikia u転sakovas, pirkjas arba vartotojas dl 眺vairiausi迭 prie転asi迭 Ne眺vertinus 邸i迭 apribojim迭, sistema gali b笛ti nepriimta
35. Apribojimai sprendimui (2) Toki迭 apribojim迭 pavyzd転iai: sistema turi b笛ti kuriama Windows 2000 operacins sistemos pagrindu sistema turi b笛ti pritaikyta delniniam kompiuteriui
36. Sistemos k笛rimo terminai Numatomi visi laiko apribojimai arba galimi termin迭 keitimo (tikslinimo) faktoriai B笛tina numatyti konkreias datas ir argumentus, kodl tokie terminai fiksuojami Gali b笛ti numatomos ir atskir迭 sistemos dali迭 u転baigimo ar parengimo testavimui datos Tikslinga 眺vertinti termin迭 nesilaikymo pasekmes (Kas bus, jei)
37. Sistemos k笛rimo biud転etas Numatomi sistemos k笛rimo finansiniai i邸tekliai kiekine i邸rai邸ka Reikalavimai negali vir邸yti biud転eto, todl dalies reikalavim迭 gali tekti atsisakyti 町vertinus numatom skirti biud転et, galima identifikuoti, ar sistema tikrai reikalinga (ar jos tikrai pageidaujama)
38. Termin迭 転odynas (1) Pateikiamas termin迭, kurie bus naudojami specifikuojant reikalavimus, 転odynas 貼odyne sukaupiamos dalykinje srityje naudojamos standartins svokos Kiekvienai svokai pateikiamas glaustas paai邸kinimas
39. Termin迭 転odynas (2) io punkto paskirtis sudaryti dalykins srities svok迭 転odyn, dl ko gali b笛ti sutaupyta daug laiko 眺vairiems paai邸kinimams 貼odynas naudojamas bei papildomas sistemos projektavimo metu
42. Funkcinio reikalavimo pateikimo forma (2) Reikalavimas turi b笛ti stebimas per vis sistemos k笛rimo laik, todl logi邸ka, kad numeravimas turi b笛ti unikalus Reikalavim迭 tipai gali b笛ti funkciniai ir nefunkciniai 町vyki迭 numeriai gali b笛ti pritaikyti panaudojimo atvejams numeruoti, taiau gali b笛ti ir nesutapim迭. Reikalavimas susiejamas su panaudojimo atvejais, nurodant j迭 numerius
43. Funkcinio reikalavimo pateikimo forma (3) Apra邸ymas skirtas reikalavimo formuluotei pateikti. Tai tekstinis reikalavimo apibr転imas, kuriame turi atsispindti u転sakovo arba vartotojo pageidavimai. Geriausia apsiriboti vienu sakiniu altinis tai asmuo, kuris i邸kl reikalavim
44. Funkcinio reikalavimo pateikimo forma (4) U転sakovo patenkinimas ir nepatenkinimas: patenkinimo rangas atspindi, kiek bus patenkintas u転sakovas, jei reikalavimas bus skmingai 眺vertintas rangui galima naudoti skal nuo 1 iki 5 1 rei邸kia, kad u転sakovas nelabai kreips dmes眺, jei reikalavimas bus 眺gyvendintas, o 5 rei邸kia maksimal迭 vartotojo patenkinim realizuojant reikalavim analogi邸kai vertinamas ir nepasitenkinimo rangas
45. Funkcinio reikalavimo pateikimo forma (5) Priklausomybs : tai kiti reikalavimai, turintys 眺tak nagrinjamam reikalavimui: jei vienas reikalavimas keiiasi, tai turi keistis ir kitas arba vieno reikalavimo duomenys betarpi邸kai siejasi su kito reikalavimo duomenimis gali b笛ti, kad vienas reikalavimas negali egzistuoti be kito reikalavimo 眺vertinimo
46. Funkcinio reikalavimo pateikimo forma (6) Konfliktai : tai reikalavimai, kurie prie邸tarauja nagrinjamam reikalavimui pavyzd転iui, galimas reikalavimas, kad sistema suskaiiuot迭 trumpiausi keli iki paskirties vietos, o kitas reikalavimas gali nurodyti surasti greiiausi keli iki paskirties vietos 邸ie reikalavimai gali prie邸tarauti vienas kitam, kadangi trumpiausias kelias ne visada yra greiiausias kelias
47. Funkcinio reikalavimo pateikimo forma (7) Papildoma med転iaga : ne visk reikia pateikti reikalavimo specifikacijoje jei yra kokia nors papildomai reikalavim apra邸anti med転iaga, tuomet gali b笛ti panaudota nuoroda 眺 邸i med転iag taiau ia reikia pateikti tik betarpi邸kai su reikalavimu susijusias nuorodas
48. Funkcinio reikalavimo pateikimo forma (8) Istorija : ia u転registruojama, kada reikalavimas pirm kart buvo suformuluotas, kada pakeistas pa邸alintas ar patikrintas (kokybs aspektu). Galima registruoti ir u転 reikalavim atsakingus asmenis
52. Reikalavimai sistemos i邸vaizdai Tai bendri reikalavimai vartotojo ssajai: lengvai 眺sisavinama ssaja atitinkantis kitus vartotojo naudojamus produktus (pavyzd転iui, Word tipins ssajos imitavimas) spalvota ir patraukli vaikams ssaja ne眺kyri ssaja (pavyzd転iui, nereikalaujanti pastoviai k nors kelis kartus patvirtinti) novatori邸ka ir meni邸ka i邸vaizda profesionali (imituojanti reali aplink) i邸vaizda 眺domi i邸vaizda (reklamos tikslais) ...
53. Reikalavimai panaudojamumui Tai reikalavimai, keliami naudojimosi sistema paprastumui: galimyb dirbti vartotojams su negalia paprastas naudotis in転inieriams-mechanikams (眺prasti 転ymjimai ar pan.) paprastas panaudojamas bet kokio asmens be apsimokymo (90% skmingas pasinaudojimas pirmu bandymu) klaidos kaina (klaidos kainos suma転inimas) ...
55. Reikalavimai sistemos prie転i笛rai Tai reikalavimai, keliami sistemos prie転i笛rai ir palaikymui po to, kai ji bus atiduota naudotis vartotojui: Per kiek laiko bus galima sistem papildyti naujomis galimybmis, patobulinti jau esamas ar i邸taisyti surastas klaidas Kaip da転nai ir kaip vartotojams bus pateikiamos naujos sistemos versijos Kokie keliami reikalavimai vartotoj迭 aptarnavimui ...
56. Reikalavimai saugumui Tai vieni i邸 sudtingiausi迭 reikalavim迭, kurie yra susij su didele rizika, jei j迭 nepaisoma Egzistuoja trys saugumo aspektai: konfidencialumas sistemoje esantys duomenys apsaugoti nuo neteisto prijimo vientisumas ( integrity ) sistemos duomenys vienareik邸mi邸kai atitinka 邸altinio perduotus (i邸 jo gautus) duomenis, kartu u転tikrinant j迭 panaudojimo teistum pasiekiamumas galimyb pasinaudoti duomenimis per fiksuot laik teistiems vartotojams
59. Egzistuojantys sprendimai Punkto paskirtis 眺vertinti jau esam迭 sistem迭 panaudojimo galimyb vartotojo u転daviniams sprsti Taip pat 邸iame skyriuje gali b笛ti 眺vardinti jau sukurti komponentai, kuriuos b笛t迭 galima panaudoti kuriamoje sistemoje ia pateiktinos nuorodos 眺 邸i迭 sistem迭 ir/arba komponent迭 platesnes ap転valgas ar kit juos charakterizuojani med転iag
60. Vartotojo dokumentacija ir apmokymai iame skyriuje pateikiamas vartotojui reikalingos dokumentacijos sra邸as Jo tikslas 眺vertinti dokumentacijos poreik眺 ir numatyti atsakingus asmenis jai parengti Klausimai, 眺 kuriuos galima atsakyti 邸io skyriaus pagalba yra: Kokio lygio dokumentacija reikalinga? Ar vartotojai dalyvaus rengiant dokumentacij? Kas bus atsakingas u転 savalaik眺 dokumentacijos rengim ir atnaujinim? Kokia dokumentacijos pateikimo forma? Numatomas vartotoj迭 apmokymo grafikas (jei reikia)
61. Perspektyviniai reikalavimai Pateikiami specifikacijoje nepaminti funkciniai ir nefunkciniai reikalavimai, kurie gali b笛ti realizuoti naujoje sistemos versijoje Skyriaus tikslas - u転registruoti svarbius, bet nerealizuotus reikalavimus, kurie dar laukia savo eils
