Your SlideShare is downloading. ×
0
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
PI_7_paskaita
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

PI_7_paskaita

1,276

Published on

Published in: Business, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,276
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Program ų inžinerija Reikalavimų inžinerija Reikalavimų specifikavimas. Reikalavimų specifikacijos dokumento šablonas Volere Autorius: Rolandas Kri štapaitis
  • 2. Turinys <ul><li>Reikalavimų specifikavimas </li></ul><ul><li>Reikalavimų specifikacijos dokumento šablono Volere apžvalga </li></ul>
  • 3. Reikalavimų specifikavimas
  • 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. 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. 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. 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. 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. 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. 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. 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. Reikalavimų specifikacijos dokumento šablono Volere apžvalga
  • 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. 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. 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. 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. 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. 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. Volere Projekto varovai
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Volere Projekto apribojimai
  • 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. 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. 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. 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. 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. 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. Volere Funkciniai reikalavimai
  • 41. Funkcinio reikalavimo pateikimo forma (1)
  • 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. 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. 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. 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. 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. 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. 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. Funkcinio reikalavimo pavyzdys
  • 50. Volere Nefunkciniai reikalavimai
  • 51. Nefunkcinio reikalavimo pateikimo forma
  • 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. 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. 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. 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. 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. Nefunkcinio reikalavimo pavyzdys
  • 58. Volere Projekto išeiga
  • 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. 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. 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>

×