Successfully reported this slideshow.
Program ų inžinerija Reikalavimų inžinerija Reikalavimų specifikavimas. Reikalavimų specifikacijos dokumento šablonas Vole...
Turinys <ul><li>Reikalavimų specifikavimas </li></ul><ul><li>Reikalavimų specifikacijos dokumento šablono Volere apžvalga ...
Reikalavimų specifikavimas
Reikalavimų specifikavimas <ul><li>Reikalavimų specifikavimas – tai dokumento, kuriame pateikiami surinkti ir išanalizuoti...
Reikalavimų specifikacijos dokumentų tipai <ul><li>Sudėtingoms sistemoms dažniausiai yra paruošiami trijų tipų reikalavimų...
Sistemos aprašymo dokumentas (1) <ul><li>Sistemos aprašymo dokumentas dar vadinamas vartotojo reikalavimų dokumentu arba t...
Sistemos aprašymo dokumentas (2) <ul><li>Šis dokumentas skirtas sistemos užsakovams, vartotojams, analitikams, todėl jame ...
Sistemos reikalavimų specifikacijos dokumentas <ul><li>Sistemos reikalavimų specifikacijos dokumentas yra reikalingas toki...
PĮ reikalavimų specifikacijos dokumentas (1) <ul><li>PĮ reikalavimų specifikacijos dokumentas yra sutarties tarp sistemos ...
PĮ reikalavimų specifikacijos dokumentas (2) <ul><li>Pagal PĮ reikalavimų specifikacijos dokumentą, galima įvertinti proje...
Reikalavimų užrašymo būdai <ul><li>Dažniausiai reikalavimai PĮ yra užrašomi natūralia kalba, tačiau reikalavimų specifikac...
Reikalavimų specifikacijos dokumento šablono Volere apžvalga
Volere šablono kilmė <ul><li>Volere šablonas buvo sukurtas remiantis ilgamete darbo, konsultacijų ir tyrimų reikalavimų in...
Volere šablono struktūra (1) <ul><li>Projekto varovai </li></ul><ul><ul><li>Sistemos paskirtis </li></ul></ul><ul><ul><li>...
Volere šablono struktūra (2) <ul><li>Projekto apribojimai </li></ul><ul><ul><li>Įpareigojantys apribojimai </li></ul></ul>...
Volere šablono struktūra (3) <ul><li>Funkciniai reikalavimai </li></ul><ul><ul><li>Veiklos sfera </li></ul></ul><ul><ul><l...
Volere šablono struktūra (4) <ul><li>Nefunkciniai reikalavimai </li></ul><ul><ul><li>Reikalavimai sistemos išvaizdai </li>...
Volere šablono struktūra (5) <ul><li>Projekto išeiga </li></ul><ul><ul><li>Atviri klausimai (problemos) </li></ul></ul><ul...
Volere Projekto varovai
Vartotojo problema arba projekto kūrimo pagrindimas (1) <ul><li>Pateikiamas trumpas vartotojo atliekamos veiklos aprašymas...
Vartotojo problema arba projekto kūrimo pagrindimas (2) <ul><li>Vartotojo problemos charakteristika gali būti visiškai tru...
Vartotojo problema arba projekto kūrimo pagrindimas (3) <ul><li>Galimas atvejis, kad problemos nėra, tačiau yra poreikis (...
Projekto tikslai (1) <ul><li>Aprašoma, ko norima iš kuriamos sistemos, ką ji turi atlikti, kaip ji įtakos vartotojo atliek...
Projekto tikslai (2) <ul><li>Jei tikslas yra aiškus, tuomet jis turi atspindėti tam tikrą naudą ar sistemos teikiamus priv...
Projekto tikslai (2) <ul><li>Jei tikslas yra aiškus, tuomet jis turi atspindėti tam tikrą naudą ar sistemos teikiamus priv...
Užsakovai (1) <ul><li>Užsakovas – tai asmuo, kuris apmoka sistemos kūrimo darbus ir taps šios sistemos savininku </li></ul...
Užsakovai (2) <ul><li>Užsakovas priima galutinį produktą (sistemą), todėl turi būti juo patenkintas </li></ul><ul><li>Jei ...
Pirkėjai (1) <ul><li>Pirkėjas – tai sistemą perkantis asmuo </li></ul><ul><li>Jei sistema skirta savoms reikmėms, tai pirk...
Pirkėjai (2) <ul><li>Šiuo atveju reikia pateikti tokią pirkėjo charakteristiką, kad reikalavimų analitikas galėtų reikalav...
Kiti suinteresuoti asmenys <ul><li>Pateikiama informacija apie kitus sistemos kūrimą įtakojančius asmenis:  </li></ul><ul>...
Vartotojai (1) <ul><li>Tai asmenų, kurie betarpiškai naudosis sistema, sąrašas </li></ul><ul><li>Kiekvienai vartotojų kate...
Vartotojai (2) <ul><li>Kiekvienai vartotojų grupei rekomenduojama suteikti prioritetą </li></ul><ul><li>Prioritetai gali b...
Volere Projekto apribojimai
Apribojimai sprendimui (1) <ul><li>Pateikiami išankstiniai apribojimai sistemos kūrimo eigai ar jos charakteristikoms bei ...
Apribojimai sprendimui (2) <ul><li>Tokių apribojimų pavyzdžiai:  </li></ul><ul><ul><li>sistema turi būti kuriama Windows 2...
Sistemos kūrimo terminai <ul><li>Numatomi visi laiko apribojimai arba galimi terminų  keitimo (tikslinimo) faktoriai </li>...
Sistemos kūrimo biudžetas <ul><li>Numatomi sistemos kūrimo finansiniai ištekliai kiekine išraiška </li></ul><ul><li>Reikal...
Terminų žodynas (1) <ul><li>Pateikiamas terminų, kurie bus naudojami specifikuojant reikalavimus, žodynas </li></ul><ul><l...
Terminų žodynas (2) <ul><li>Šio punkto paskirtis – sudaryti dalykinės srities sąvokų žodyną, dėl ko gali būti sutaupyta da...
Volere Funkciniai reikalavimai
Funkcinio reikalavimo pateikimo forma (1)
Funkcinio reikalavimo pateikimo forma (2) <ul><li>Reikalavimas turi būti stebimas per visą sistemos kūrimo laiką, todėl lo...
Funkcinio reikalavimo pateikimo forma (3) <ul><li>Aprašymas  skirtas reikalavimo formuluotei pateikti. Tai tekstinis reika...
Funkcinio reikalavimo pateikimo forma (4) <ul><li>Užsakovo patenkinimas ir nepatenkinimas:  patenkinimo rangas atspindi, k...
Funkcinio reikalavimo pateikimo forma (5) <ul><li>Priklausomybės : tai kiti reikalavimai, turintys įtaką nagrinėjamam reik...
Funkcinio reikalavimo pateikimo forma (6) <ul><li>Konfliktai : tai reikalavimai, kurie prieštarauja nagrinėjamam reikalavi...
Funkcinio reikalavimo pateikimo forma (7) <ul><li>Papildoma medžiaga : ne viską reikia pateikti reikalavimo specifikacijoj...
Funkcinio reikalavimo pateikimo forma (8) <ul><li>Istorija : čia užregistruojama, kada reikalavimas pirmą kartą buvo sufor...
Funkcinio reikalavimo pavyzdys
Volere Nefunkciniai reikalavimai
Nefunkcinio reikalavimo pateikimo forma
Reikalavimai sistemos išvaizdai <ul><li>Tai bendri reikalavimai vartotojo sąsajai: </li></ul><ul><ul><li>lengvai įsisavina...
Reikalavimai panaudojamumui <ul><li>Tai reikalavimai, keliami naudojimosi sistema paprastumui: </li></ul><ul><ul><li>galim...
Reikalavimai veikimo charakteristikoms <ul><li>Tai reikalavimai sistemos veikimo našumui: </li></ul><ul><ul><li>užduočių v...
Reikalavimai sistemos priežiūrai <ul><li>Tai reikalavimai, keliami sistemos priežiūrai ir palaikymui po to, kai ji bus ati...
Reikalavimai saugumui <ul><li>Tai vieni iš sudėtingiausių reikalavimų, kurie yra susiję su didele rizika, jei jų nepaisoma...
Nefunkcinio reikalavimo pavyzdys
Volere Projekto išeiga
Egzistuojantys sprendimai <ul><li>Punkto paskirtis – įvertinti jau esamų sistemų panaudojimo galimybę vartotojo uždaviniam...
Vartotojo dokumentacija ir apmokymai <ul><li>Šiame skyriuje pateikiamas vartotojui reikalingos dokumentacijos sąrašas </li...
Perspektyviniai reikalavimai <ul><li>Pateikiami specifikacijoje nepaminėti funkciniai ir nefunkciniai reikalavimai, kurie ...
Upcoming SlideShare
Loading in …5
×

PI_7_paskaita

1,748 views

Published on

Published in: Business, Technology
  • Be the first to comment

PI_7_paskaita

  1. 1. Program ų inžinerija Reikalavimų inžinerija Reikalavimų specifikavimas. Reikalavimų specifikacijos dokumento šablonas Volere Autorius: Rolandas Kri štapaitis
  2. 2. Turinys <ul><li>Reikalavimų specifikavimas </li></ul><ul><li>Reikalavimų specifikacijos dokumento šablono Volere apžvalga </li></ul>
  3. 3. Reikalavimų specifikavimas
  4. 4. Reikalavimų specifikavimas <ul><li>Reikalavimų specifikavimas – tai dokumento, kuriame pateikiami surinkti ir išanalizuoti reikalavimai PĮ, parengimas taip, kad jį būtų galima sistemingai peržiūrėti, vertinti ir patvirtinti </li></ul>
  5. 5. Reikalavimų specifikacijos dokumentų tipai <ul><li>Sudėtingoms sistemoms dažniausiai yra paruošiami trijų tipų reikalavimų specifikacijos dokumentai: </li></ul><ul><ul><li>sistemos aprašymas </li></ul></ul><ul><ul><li>sistemos reikalavimų specifikacija </li></ul></ul><ul><ul><li>PĮ reikalavimų specifikacija </li></ul></ul><ul><li>Nedidelių sistemų atveju dažniausiai yra parengiamas tik trečiasis iš aukščiau paminėtų dokumentų </li></ul>
  6. 6. Sistemos aprašymo dokumentas (1) <ul><li>Sistemos aprašymo dokumentas dar vadinamas vartotojo reikalavimų dokumentu arba technine užduotimi </li></ul><ul><li>Jame pateikiami aukščiausio lygio sistemos reikalavimai, suformuluoti iš dalykinės srities pusės </li></ul>
  7. 7. Sistemos aprašymo dokumentas (2) <ul><li>Šis dokumentas skirtas sistemos užsakovams, vartotojams, analitikams, todėl jame dažnai bus sutinkami jų dalykinėje srityje vartojami terminai </li></ul><ul><li>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 </li></ul>
  8. 8. Sistemos reikalavimų specifikacijos dokumentas <ul><li>Sistemos reikalavimų specifikacijos dokumentas yra reikalingas tokio tipo sistemoms, kaip mobilūs telefonai, buitinė technika ir pan. </li></ul><ul><li>Jose PĮ sudaro tik nedidelę dalį, o reikalavimai jai išplaukia iš reikalavimų visai sistemai </li></ul><ul><li>Programų inžinerija nenagrinėja sistemos reikalavimų specifikacijos dokumento sudarymo, nes jos tyrimo objektas yra PĮ kūrimas </li></ul>
  9. 9. PĮ reikalavimų specifikacijos dokumentas (1) <ul><li>PĮ reikalavimų specifikacijos dokumentas yra sutarties tarp sistemos užsakovo ir sistemos kūrėjo pagrindas, nes jame yra aprašoma, ką sukurta sistema turės daryti ir ko ne </li></ul><ul><li>PĮ reikalavimų specifikacijos dokumentas leidžia atlikti griežtą joje pateiktų reikalavimų įvertinimą, prieš pradedant PĮ projektavimo etapą </li></ul>
  10. 10. PĮ reikalavimų specifikacijos dokumentas (2) <ul><li>Pagal PĮ reikalavimų specifikacijos dokumentą, galima įvertinti projekto sąnaudas, rizikas ir sudaryti detalų jos įgyvendinimo planą </li></ul><ul><li>PĮ reikalavimų specifikacijos dokumento pagalba, sistema yra įdiegiama vartotojų darbo vietose, atliekami joje aptiktų klaidų pataisymai bei PĮ papildymai naujomis f-jomis </li></ul>
  11. 11. Reikalavimų užrašymo būdai <ul><li>Dažniausiai reikalavimai PĮ yra užrašomi natūralia kalba, tačiau reikalavimų specifikacijos dokumente ji gali būti papildyta formaliais arba pusiau formaliais paaiškinimais </li></ul><ul><li>Grafinės notacijos naudojimas leidžia kai kuriuos reikalavimus užrašyti tiksliau, negu naudojant tik natūralią kalbą </li></ul><ul><li>Grafinė notacija turi būti parenkama atsižvelgiant į specifikacijos kūrėjų ir skaitytojų žinias bei patirtį </li></ul>
  12. 12. Reikalavimų specifikacijos dokumento šablono Volere apžvalga
  13. 13. Volere šablono kilmė <ul><li>Volere šablonas buvo sukurtas remiantis ilgamete darbo, konsultacijų ir tyrimų reikalavimų inžinerijos srityje patirtimi </li></ul><ul><li>Volere šablono autoriai yra James ir Suzanne Robertson </li></ul><ul><li>Detali informacija apie Volere pateikiama internete adresu: http://www.systemsguild.com </li></ul>
  14. 14. Volere šablono struktūra (1) <ul><li>Projekto varovai </li></ul><ul><ul><li>Sistemos paskirtis </li></ul></ul><ul><ul><li>Užsakovai, pirkėjai ir kiti sistema suinteresuoti asmenys </li></ul></ul><ul><ul><li>Vartotojai </li></ul></ul>
  15. 15. Volere šablono struktūra (2) <ul><li>Projekto apribojimai </li></ul><ul><ul><li>Įpareigojantys apribojimai </li></ul></ul><ul><ul><li>Terminų žodynas </li></ul></ul><ul><ul><li>Svarbūs faktai ir prielaidos </li></ul></ul>
  16. 16. Volere šablono struktūra (3) <ul><li>Funkciniai reikalavimai </li></ul><ul><ul><li>Veiklos sfera </li></ul></ul><ul><ul><li>Produkto veikimo sfera </li></ul></ul><ul><ul><li>Funkciniai reikalavimai ir reikalavimai duomenims </li></ul></ul>
  17. 17. Volere šablono struktūra (4) <ul><li>Nefunkciniai reikalavimai </li></ul><ul><ul><li>Reikalavimai sistemos išvaizdai </li></ul></ul><ul><ul><li>Reikalavimai panaudojamumui </li></ul></ul><ul><ul><li>Reikalavimai veikimo charakteristikoms </li></ul></ul><ul><ul><li>Reikalavimai vykdymo sąlygoms </li></ul></ul><ul><ul><li>Reikalavimai sistemos priežiūrai </li></ul></ul><ul><ul><li>Reikalavimai saugumui </li></ul></ul><ul><ul><li>Kultūriniai-politiniai reikalavimai </li></ul></ul><ul><ul><li>Teisiniai reikalavimai </li></ul></ul>
  18. 18. Volere šablono struktūra (5) <ul><li>Projekto išeiga </li></ul><ul><ul><li>Atviri klausimai (problemos) </li></ul></ul><ul><ul><li>Egzistuojantys sprendimai </li></ul></ul><ul><ul><li>Naujos problemos </li></ul></ul><ul><ul><li>Uždaviniai </li></ul></ul><ul><ul><li>Pritaikymas </li></ul></ul><ul><ul><li>Rizikos </li></ul></ul><ul><ul><li>Sąnaudos </li></ul></ul><ul><ul><li>Vartotojo dokumentacija ir apmokymai </li></ul></ul><ul><ul><li>Perspektyviniai reikalavimai </li></ul></ul><ul><ul><li>Idėjos sprendimams </li></ul></ul>
  19. 19. Volere Projekto varovai
  20. 20. Vartotojo problema arba projekto kūrimo pagrindimas (1) <ul><li>Pateikiamas trumpas vartotojo atliekamos veiklos aprašymas ir apibūdinama situacija, kuri sąlygojo kuriamos PĮ užsakymą (vartotojo problema) </li></ul><ul><li>Keliais sakiniais aprašoma, kokias f-jas kuriama PĮ turi leisti atlikti savo vartotojams </li></ul><ul><li>Įvertinama, ar vartotojo problema yra pakankamai rimta, kodėl ir kaip ją reikėtų išspręsti </li></ul>
  21. 21. Vartotojo problema arba projekto kūrimo pagrindimas (2) <ul><li>Vartotojo problemos charakteristika gali būti visiškai trumpa, pavyzdžiui: “Klientai nepatenkinti, kad užsakymas įvykdomas per 10 dienų” </li></ul><ul><li>Dažnai pateikiamas žymiai platesnis tam tikros veiklos aprašas, atskleidžiant pagrindines problemas </li></ul>
  22. 22. Vartotojo problema arba projekto kūrimo pagrindimas (3) <ul><li>Galimas atvejis, kad problemos nėra, tačiau yra poreikis (galimybė) plėsti tam tikrą veiklą - tuomet tokia galimybė turi būti aprašyta </li></ul>
  23. 23. Projekto tikslai (1) <ul><li>Aprašoma, ko norima iš kuriamos sistemos, ką ji turi atlikti, kaip ji įtakos vartotojo atliekamos veiklos tikslų sėkmingą pasiekimą </li></ul><ul><li>Čia nereikėtų daug prirašyti. Pakanka kuriamos sistemos trumpo tikslų (paskirties) paaiškinimo </li></ul><ul><li>Tikslų apraše neturėtų būti specifinių reikalavimų, kuriuos tikslai būtent ir padengia </li></ul>
  24. 24. Projekto tikslai (2) <ul><li>Jei tikslas yra aiškus, tuomet jis turi atspindėti tam tikrą naudą ar sistemos teikiamus privalumus </li></ul><ul><li>Įvardinami trys pagrindiniai privalumai (naudos atvejai): </li></ul><ul><ul><li>rinkos vertė </li></ul></ul><ul><ul><li>operacijų kainos sumažinimas </li></ul></ul><ul><ul><li>paslaugų kiekio ir kokybės padidinimas klientui </li></ul></ul>
  25. 25. Projekto tikslai (2) <ul><li>Jei tikslas yra aiškus, tuomet jis turi atspindėti tam tikrą naudą ar sistemos teikiamus privalumus </li></ul><ul><li>Įvardinami trys pagrindiniai privalumai (naudos atvejai): </li></ul><ul><ul><li>rinkos vertė </li></ul></ul><ul><ul><li>operacijų kainos sumažinimas </li></ul></ul><ul><ul><li>paslaugų kiekio ir kokybės padidinimas klientui </li></ul></ul>
  26. 26. Užsakovai (1) <ul><li>Užsakovas – tai asmuo, kuris apmoka sistemos kūrimo darbus ir taps šios sistemos savininku </li></ul><ul><li>Dažnai tai asmuo, esantis sistemos galutinio vartotojo padalinio vadovu. Šiame punkte nurodomi šio asmens duomenys </li></ul><ul><li>Kartais užsakovu gali būti keli asmenys </li></ul>
  27. 27. Užsakovai (2) <ul><li>Užsakovas priima galutinį produktą (sistemą), todėl turi būti juo patenkintas </li></ul><ul><li>Jei sistema kuriama savoms reikmėms, tai užsakovas ir pirkėjas gali būti tas pats asmuo </li></ul><ul><li>Jei sistema kuriama rinkai (išorės vartotojams), tuomet užsakovu gali būti marketingo skyrius, kurį atstovauja šio skyriaus darbuotojas </li></ul>
  28. 28. Pirkėjai (1) <ul><li>Pirkėjas – tai sistemą perkantis asmuo </li></ul><ul><li>Jei sistema skirta savoms reikmėms, tai pirkėjas yra asmuo, kuris priima galutinį sprendimą, ar sistema reikalinga. Tai gali būti padalinio, kuriame diegiama sistema, vadovas, arba visos organizacijos vadovas </li></ul><ul><li>Jei sistema skirta rinkai, tai pirkėjas yra sistemą įsigyjančią organizaciją atstovaujantis asmuo </li></ul>
  29. 29. Pirkėjai (2) <ul><li>Šiuo atveju reikia pateikti tokią pirkėjo charakteristiką, kad reikalavimų analitikas galėtų reikalavimus pateikti įvertindamas pirkėjo pageidavimus </li></ul><ul><li>Jei pirkėją atstovauja sistemą platinančios organizacijos marketingo skyrius, tuomet jie turi pateikti kuo tikslesnę numatomų faktinių pirkėjų charakteristiką </li></ul><ul><li>Sistema turi būti kuriama patenkinant pirkėjo tikslus ir užsakovo apribojimus (reikalavimus) </li></ul>
  30. 30. Kiti suinteresuoti asmenys <ul><li>Pateikiama informacija apie kitus sistemos kūrimą įtakojančius asmenis: </li></ul><ul><ul><li>vadovybė arba projekto rėmėjai </li></ul></ul><ul><ul><li>veiklos srities ekspertai </li></ul></ul><ul><ul><li>techniniai specialistai </li></ul></ul><ul><ul><li>projektuotojai </li></ul></ul><ul><ul><li>marketingo specialistai </li></ul></ul><ul><ul><li>projekto vadovai </li></ul></ul><ul><ul><li>testuotojai ir kokybę tikrinantys asmenys </li></ul></ul><ul><ul><li>teisininkai </li></ul></ul>
  31. 31. Vartotojai (1) <ul><li>Tai asmenų, kurie betarpiškai naudosis sistema, sąrašas </li></ul><ul><li>Kiekvienai vartotojų kategorijai reikia nurodyti tokią informaciją: </li></ul><ul><ul><li>Vartotojo kategorija </li></ul></ul><ul><ul><li>Vartotojo sprendžiami uždaviniai (atliekamos funkcijos) </li></ul></ul><ul><ul><li>Patirtis dalykinėje srityje (naujokas, eilinis darbuotojas, srities specialistas) </li></ul></ul><ul><ul><li>Patirtis informacinėse technologijose (naujokas, patyręs, informatikas) </li></ul></ul><ul><ul><li>Papildomos vartotojo charakteristikos, turinčios įtaką reikalavimams bei sistemos savybėms </li></ul></ul>
  32. 32. Vartotojai (2) <ul><li>Kiekvienai vartotojų grupei rekomenduojama suteikti prioritetą </li></ul><ul><li>Prioritetai gali būti: </li></ul><ul><ul><li>Svarbiausi vartotojai – jų nuomonė ir pageidavimai svarbiausi </li></ul></ul><ul><ul><li>Antraeiliai vartotojai – jei kyla konfliktas su pirmąja grupe, tai jų nuomonė turi didesnę įtaką </li></ul></ul><ul><ul><li>Nesvarbūs (atsitiktiniai) vartotojai </li></ul></ul>
  33. 33. Volere Projekto apribojimai
  34. 34. Apribojimai sprendimui (1) <ul><li>Pateikiami išankstiniai apribojimai sistemos kūrimo eigai ar jos charakteristikoms bei jų atsiradimo priežastys </li></ul><ul><li>Jie turi griežto reikalavimo pobūdį, todėl juos reikia tiksliai aprašyti, nepamirštant numatyti, kaip galima “išmatuoti” (testuoti) jų laikymąsi sukurtoje sistemoje </li></ul><ul><li>Šiuos apribojimus dažniausiai pateikia užsakovas, pirkėjas arba vartotojas dėl įvairiausių priežasčių </li></ul><ul><li>Neįvertinus šių apribojimų, sistema gali būti nepriimta </li></ul>
  35. 35. Apribojimai sprendimui (2) <ul><li>Tokių apribojimų pavyzdžiai: </li></ul><ul><ul><li>sistema turi būti kuriama Windows 2000 operacinės sistemos pagrindu </li></ul></ul><ul><ul><li>sistema turi būti pritaikyta delniniam kompiuteriui </li></ul></ul>
  36. 36. Sistemos kūrimo terminai <ul><li>Numatomi visi laiko apribojimai arba galimi terminų keitimo (tikslinimo) faktoriai </li></ul><ul><li>Būtina numatyti konkrečias datas ir argumentus, kodėl tokie terminai fiksuojami </li></ul><ul><li>Gali būti numatomos ir atskirų sistemos dalių užbaigimo ar parengimo testavimui datos </li></ul><ul><li>Tikslinga įvertinti terminų nesilaikymo pasekmes (“Kas bus, jei…”) </li></ul>
  37. 37. Sistemos kūrimo biudžetas <ul><li>Numatomi sistemos kūrimo finansiniai ištekliai kiekine išraiška </li></ul><ul><li>Reikalavimai negali viršyti biudžeto, todėl dalies reikalavimų gali tekti atsisakyti </li></ul><ul><li>Įvertinus numatomą skirti biudžetą, galima identifikuoti, ar sistema tikrai reikalinga (ar jos tikrai pageidaujama) </li></ul>
  38. 38. Terminų žodynas (1) <ul><li>Pateikiamas terminų, kurie bus naudojami specifikuojant reikalavimus, žodynas </li></ul><ul><li>Žodyne sukaupiamos dalykinėje srityje naudojamos standartinės sąvokos </li></ul><ul><li>Kiekvienai sąvokai pateikiamas glaustas paaiškinimas </li></ul>
  39. 39. Terminų žodynas (2) <ul><li>Šio punkto paskirtis – sudaryti dalykinės srities sąvokų žodyną, dėl ko gali būti sutaupyta daug laiko įvairiems paaiškinimams </li></ul><ul><li>Žodynas naudojamas bei papildomas sistemos projektavimo metu </li></ul>
  40. 40. Volere Funkciniai reikalavimai
  41. 41. Funkcinio reikalavimo pateikimo forma (1)
  42. 42. Funkcinio reikalavimo pateikimo forma (2) <ul><li>Reikalavimas turi būti stebimas per visą sistemos kūrimo laiką, todėl logiška, kad numeravimas turi būti unikalus </li></ul><ul><li>Reikalavimų tipai gali būti funkciniai ir nefunkciniai </li></ul><ul><li>Įvykių numeriai gali būti pritaikyti panaudojimo atvejams numeruoti, tačiau gali būti ir nesutapimų. Reikalavimas susiejamas su panaudojimo atvejais, nurodant jų numerius </li></ul>
  43. 43. Funkcinio reikalavimo pateikimo forma (3) <ul><li>Aprašymas skirtas reikalavimo formuluotei pateikti. Tai tekstinis reikalavimo apibrėžimas, kuriame turi atsispindėti užsakovo arba vartotojo pageidavimai. Geriausia apsiriboti vienu sakiniu </li></ul><ul><li>Šaltinis – tai asmuo, kuris iškėlė reikalavimą </li></ul>
  44. 44. Funkcinio reikalavimo pateikimo forma (4) <ul><li>Užsakovo patenkinimas ir nepatenkinimas: patenkinimo rangas atspindi, kiek bus patenkintas užsakovas, jei reikalavimas bus sėkmingai įvertintas </li></ul><ul><ul><li>rangui galima naudoti skalę nuo 1 iki 5 </li></ul></ul><ul><ul><li>1 reiškia, kad užsakovas nelabai kreips dėmesį, jei reikalavimas bus įgyvendintas, o 5 reiškia maksimalų vartotojo patenkinimą realizuojant reikalavimą </li></ul></ul><ul><ul><li>analogiškai vertinamas ir nepasitenkinimo rangas </li></ul></ul>
  45. 45. Funkcinio reikalavimo pateikimo forma (5) <ul><li>Priklausomybės : tai kiti reikalavimai, turintys įtaką nagrinėjamam reikalavimui: </li></ul><ul><ul><li>jei vienas reikalavimas keičiasi, tai turi keistis ir kitas </li></ul></ul><ul><ul><li>arba vieno reikalavimo duomenys betarpiškai siejasi su kito reikalavimo duomenimis </li></ul></ul><ul><ul><li>gali būti, kad vienas reikalavimas negali egzistuoti be kito reikalavimo įvertinimo </li></ul></ul>
  46. 46. Funkcinio reikalavimo pateikimo forma (6) <ul><li>Konfliktai : tai reikalavimai, kurie prieštarauja nagrinėjamam reikalavimui </li></ul><ul><ul><li>pavyzdžiui, galimas reikalavimas, kad “sistema suskaičiuotų trumpiausią kelią iki paskirties vietos”, o kitas reikalavimas gali nurodyti “surasti greičiausią kelią iki paskirties vietos” </li></ul></ul><ul><ul><li>šie reikalavimai gali prieštarauti vienas kitam, kadangi trumpiausias kelias ne visada yra greičiausias kelias </li></ul></ul>
  47. 47. Funkcinio reikalavimo pateikimo forma (7) <ul><li>Papildoma medžiaga : ne viską reikia pateikti reikalavimo specifikacijoje </li></ul><ul><ul><li>jei yra kokia nors papildomai reikalavimą aprašanti medžiaga, tuomet gali būti panaudota nuoroda į šią medžiagą </li></ul></ul><ul><ul><li>tačiau čia reikia pateikti tik betarpiškai su reikalavimu susijusias nuorodas </li></ul></ul>
  48. 48. Funkcinio reikalavimo pateikimo forma (8) <ul><li>Istorija : čia užregistruojama, kada reikalavimas pirmą kartą buvo suformuluotas, kada pakeistas pašalintas ar patikrintas (kokybės aspektu). Galima registruoti ir už reikalavimą atsakingus asmenis </li></ul>
  49. 49. Funkcinio reikalavimo pavyzdys
  50. 50. Volere Nefunkciniai reikalavimai
  51. 51. Nefunkcinio reikalavimo pateikimo forma
  52. 52. Reikalavimai sistemos išvaizdai <ul><li>Tai bendri reikalavimai vartotojo sąsajai: </li></ul><ul><ul><li>lengvai įsisavinama sąsaja </li></ul></ul><ul><ul><li>atitinkantis kitus vartotojo naudojamus produktus (pavyzdžiui, Word tipinės sąsajos imitavimas) </li></ul></ul><ul><ul><li>spalvota ir patraukli vaikams sąsaja </li></ul></ul><ul><ul><li>neįkyri sąsaja (pavyzdžiui, nereikalaujanti pastoviai ką nors kelis kartus patvirtinti) </li></ul></ul><ul><ul><li>novatoriška ir meniška išvaizda </li></ul></ul><ul><ul><li>profesionali (imituojanti realią aplinką) išvaizda </li></ul></ul><ul><ul><li>įdomi išvaizda (reklamos tikslais) </li></ul></ul><ul><ul><li>... </li></ul></ul>
  53. 53. Reikalavimai panaudojamumui <ul><li>Tai reikalavimai, keliami naudojimosi sistema paprastumui: </li></ul><ul><ul><li>galimybė dirbti vartotojams su negalia </li></ul></ul><ul><ul><li>paprastas naudotis inžinieriams-mechanikams (įprasti žymėjimai ar pan.) </li></ul></ul><ul><ul><li>paprastas panaudojamas bet kokio asmens be apsimokymo (90% sėkmingas pasinaudojimas pirmu bandymu) </li></ul></ul><ul><ul><li>klaidos kaina (klaidos kainos sumažinimas) </li></ul></ul><ul><ul><li>... </li></ul></ul>
  54. 54. Reikalavimai veikimo charakteristikoms <ul><li>Tai reikalavimai sistemos veikimo našumui: </li></ul><ul><ul><li>užduočių vykdymo greitis </li></ul></ul><ul><ul><li>tikslumo koeficientas </li></ul></ul><ul><ul><li>talpumas (DB apimtis) </li></ul></ul>
  55. 55. Reikalavimai sistemos priežiūrai <ul><li>Tai reikalavimai, keliami sistemos priežiūrai ir palaikymui po to, kai ji bus atiduota naudotis vartotojui: </li></ul><ul><ul><li>Per kiek laiko bus galima sistemą papildyti naujomis galimybėmis, patobulinti jau esamas ar ištaisyti surastas klaidas </li></ul></ul><ul><ul><li>Kaip dažnai ir kaip vartotojams bus pateikiamos naujos sistemos versijos </li></ul></ul><ul><ul><li>Kokie keliami reikalavimai vartotojų aptarnavimui </li></ul></ul><ul><ul><li>... </li></ul></ul>
  56. 56. Reikalavimai saugumui <ul><li>Tai vieni iš sudėtingiausių reikalavimų, kurie yra susiję su didele rizika, jei jų nepaisoma </li></ul><ul><li>Egzistuoja trys saugumo aspektai: </li></ul><ul><ul><li>konfidencialumas – sistemoje esantys duomenys apsaugoti nuo neteisėto priėjimo </li></ul></ul><ul><ul><li>vientisumas ( integrity ) – sistemos duomenys vienareikšmiškai atitinka šaltinio perduotus (iš jo gautus) duomenis, kartu užtikrinant jų panaudojimo teisėtumą </li></ul></ul><ul><ul><li>pasiekiamumas – galimybė pasinaudoti duomenimis per fiksuotą laiką teisėtiems vartotojams </li></ul></ul>
  57. 57. Nefunkcinio reikalavimo pavyzdys
  58. 58. Volere Projekto išeiga
  59. 59. Egzistuojantys sprendimai <ul><li>Punkto paskirtis – įvertinti jau esamų sistemų panaudojimo galimybę vartotojo uždaviniams spręsti </li></ul><ul><li>Taip pat šiame skyriuje gali būti įvardinti jau sukurti komponentai, kuriuos būtų galima panaudoti kuriamoje sistemoje </li></ul><ul><li>Čia pateiktinos nuorodos į šių sistemų ir/arba komponentų platesnes apžvalgas ar kitą juos charakterizuojančią medžiagą </li></ul>
  60. 60. Vartotojo dokumentacija ir apmokymai <ul><li>Šiame skyriuje pateikiamas vartotojui reikalingos dokumentacijos sąrašas </li></ul><ul><li>Jo tikslas – įvertinti dokumentacijos poreikį ir numatyti atsakingus asmenis jai parengti </li></ul><ul><li>Klausimai, į kuriuos galima atsakyti šio skyriaus pagalba yra: </li></ul><ul><ul><li>Kokio lygio dokumentacija reikalinga? </li></ul></ul><ul><ul><li>Ar vartotojai dalyvaus rengiant dokumentaciją? </li></ul></ul><ul><ul><li>Kas bus atsakingas už savalaikį dokumentacijos rengimą ir atnaujinimą? </li></ul></ul><ul><ul><li>Kokia dokumentacijos pateikimo forma? </li></ul></ul><ul><ul><li>Numatomas vartotojų apmokymo grafikas (jei reikia) </li></ul></ul>
  61. 61. Perspektyviniai reikalavimai <ul><li>Pateikiami specifikacijoje nepaminėti funkciniai ir nefunkciniai reikalavimai, kurie gali būti realizuoti naujoje sistemos versijoje </li></ul><ul><li>Skyriaus tikslas - užregistruoti svarbius, bet nerealizuotus reikalavimus, kurie dar laukia savo eilės </li></ul>

×