PSI 7 Reikalavimu Inzinerija 20150309 v01

PROGRAMŲ SISTEMŲ
INŽINERIJA
1 paskaita: Reikalavimų inžinerija
Skaidrės ruoštos remianti prof. A.Čaplinsko ir

J.Somerville medžiaga
Doc. dr. Diana Kalibatienė

diana.kalibatiene@vgtu.lt
2
Dėstymo planas
• Reikalavimų inžinerija
• 3 dalis. Reikalavimai
• Kas vadinama reikalavimu? Reikalavimų apibrėžtis. Reikalavimų
rūšys. Kam reikia formuluoti reikalavimus. Gerai suformuluoto
reikalavimo savybės: abstraktumas, išsamumas, tikslumas,
vienareikšmiškumas, patikrinamumas, įgyvendinamumas,
integruotumas, galimybė lokalizuoti, galimybė trasuoti,
unikalumas, glaustumas, suprantamumas.
• Funkciniai ir nefunkciniai reikalavimai. Dalykinio pobūdžio ir
pagalbinis funkcionalumas. Kaip nustatyti, kokių funkcinių
reikalavimų reikia? Funkcinių reikalavimų specifikavimas.
Programų sistemos korektiškumas.
• Interfeiso reikalavimai: užduočių formulavimo kalba, sąveikos
reikalavimai, naudojimo paprastumo reikalavimai, patogumo
vartotojui reikalavimai, ergonominiai reikalavimai.
3
Dėstymo planas
• Reikalavimų inžinerija
• 3 dalis. Reikalavimai
• Veikimo reikalavimai: tikslumas, patikimumas, gyvybingumas,
robastiškumas, našumas.
• Iš ekonominių ribojimų išplaukiantys reikalavimai: diegimo,
aptarnavimo, priežiūros ir tiražuojamumo reikalavimai.
• Iš politinių ribojimų išplaukiantys reikalavimai. Apsaugos
reikalavimai. Iš teisinių ribojimų išplaukiantys reikalavimai.
• ISO 9126 standartas ir jo panaudojimas.
• Anotuoti reikalavimai.
• Reikalavimų specifikacija. Gerai parašytos reikalavimų
specifikacijos savybės.
4
Reikalavimai
Kas vadinama reikalavimu?
• PS reikalavimu vadinama sandoriu su užsakovu,
specifikacija, standartu arba kokiu nors kitu juridinę
galią turinčiu dokumentu numatyta tos sistemos
savybė.
• Reikalavimai gali būti labai skirtingo abstrakcijos lygmens – nuo
labai bendrų sistemos ar jos teikiamų paslaugų ribojimų iki detalios
matematinės tos sistemų savybių specifikacijos.
• To išvengti yra neįmanoma dėl dvigubos reikalavimų paskirties:
• viena vertus, jie naudojami skelbiant konkursą sistemai sukurti ir todėl
turi būti pakankamai bendro pobūdžio, kad konkurse galėtų dalyvauti
kuo daugiau pretendentų;
• Kita vertus, jie yra pagrindinė sandorio tarp užsakovo ir vykdytojo dalis
ir todėl turi būti suformuluoti kuo tiksliau ir išsamiau;
• Taigi turime mažiausiai du reikalavimų abstrakcijos lygmenis.
5
Reikalavimai
• Reikalavimų abstraktumas (Davis)
• “Jei organizacija nori sudaryti sandorį dideliam
projektui programinei įrangai sukurti, ji turi nusakyti
savo poreikius pakankamai abstrakčiai,
nenusakydama savo problemų sprendimo būdo.
Reikalavimai turi būti suformuluoti taip, kad dėl
sandorio galėtų varžytis keli pretendentai, galbūt
pasiūlydami skirtingus būdus, kaip galima
patenkinti tos organizacijos poreikius. Pasirašęs
sandorį, konkursą laimėjęs vykdytojas privalo taip
detalizuoti reikalavimus, kad užsakovas suprastu, ką
gi darys kuriama programinė įranga ir, ją sukūrus,
patikrinti, ar ji iš tiesų tą daro. Abu šie dokumentai
yra vadinami sistemos reikalavimų specifikacija”.
6
Reikalavimai
• Kokią išeigą generuos sistema?
• Kokia tvarka bus pateikti rezultatai: didėjančia ar
mažėjančia? Eilutėje vienas skaičius?
• Ar programa rašys rezultatus į pradinių duomenų
failą, ar kurs specialų rezultatų failą? Kaip tas
failas vadinsis?
• Reikalavimų specifikacija turi duoti atsakymus į
visus tuos klausimus ir dar į daugelį kitų.
7
Reikalavimai
Reikalavimų nustatymas
• Procesas, kuriuo nustatoma, kokias
paslaugas privalo teikti sistema ir kokius
ribojimus ta sistema turi tenkinti teikdama
tas paslaugas.
8
Reikalavimai
Reikalavimų rūšys
• Vartotojo reikalavimai (operaciniai poreikiai): Turi taip
aprašyti reikalavimus, kad jie būtų suprantami žmonėms, tik
paviršutiniškai susipažinusiems su tuo, kas yra kompiuteriai
ir programų sistemos.
• Šie reikalavimai skirti būsimiems sistemos vartotojams bei jos
užsakovams.
• Sistemos reikalavimai: Tam tikru specialiu būdu
struktūrizuotas detalus sistemos teikiamų paslaugų ir jos
tenkinamų ribojimų aprašas.
• Rašomi kaip sudėtinė užsakovo ir vykdytojo sandorio dalis.
• Projektiniai reikalavimai: Abstraktus programų sistemos
įgyvendinimo būdo aprašas, naudojamas kaip išeities
ribojimai detaliai projektuojant sistemą.
• Šie reikalavimai skirti vykdytojams. Susieja sistemos
reikalavimus su jos realizacija.
9
Reikalavimai
Kas skaito reikalavimus
• Užsakovo vadovybė
Vartotojo • Sistemos vartotojai
reikalavimai • Dalykinės srities specialistai
• Sistemos architektas
• Sistemos vartotojai
Sistemos • Dalykinės srities specialistai
reikalavimai • Sistemos architektas
• PS inžinieriai
• Sistemos eksploatavimo
Projektiniai tarnybos
reikalavimai • Sistemos architektas
• PS inžinieriai
10
Reikalavimai
Vartotojo (operaciniai poreikiai) ir sistemos reikalavimai:
11
Reikalavimai
Vartotojo (operaciniai poreikiai) ir sistemos reikalavimai:
• Vartojo ir sistemos reikalavimai yra

skirtingo detalumo lygmens, nes juos
skaito skirtingi skaitytojai ir jie naudojami
skirtingiems tikslams.
• Vartotojų reikalavimų skaitytojams nesvarbu
kaip sistema bus įgyvendinta.
• Sistemos reikalavimų skaitytojams svarbu tiksliai
žinoti ką sistema turi daryti, nes jie turi juos
įgyvendinti.
12
Reikalavimai
Reikalavimų formulavimas
• Procesas, kuriuo operaciniai poreikiai yra
pertvarkomi į tikslų ir išsamų aprašą, ką sistema
darys ir kaip ji veiks.
• Daug svarbių programų sistemų kūrimo projektų
žlugo tik todėl, kad blogai buvo tvarkomasi su
reikalavimais. Jei pradedama dirbti iki galo
nesuformulavus reikalavimų arba jei jie yra nuolat
kaitaliojami, gali žlugti net ir geriausiai valdomas
projektas.
13
Reikalavimai
Reikalavimų specifikacija
• Tai dokumentas, aprašantis ką turi daryti sistema
ir kokius kitus reikalavimus ji turi tenkinti.
• Mintis, kad jūs ką nors galite sukurti tik tuomet,
kuomet jūs žinote, ką norite sukurti, yra akivaizdi.
• Įsivaizduokite, kad jūs įeinate į statybos bendrovę ir sakote “Aš
noriu, kad man pastatytumėt gyvenamą pastatą“, nepateikdami
daugiau jokios informacijos. Jokia save gerbianti bendrovė
niekuomet nesiims tokio darbo. Deja, programuotojai dažnai
elgiasi kitaip.
14
Operacinių poreikių ir reikalavimų

specifikavimo svarba
15
Reikalavimai
Reikalavimų formulavimas
• Pradedant programavimo darbus, neturint nei
sistemos, nei projektinių reikalavimų, tikimasi
sutaupyti laiko ir pinigų. Nors projekto pradžioje
(netgi iki atiduodant sistemą užsakovui) dažnai
atrodo, kad tai pavyko pasiekti, iš tiesų tai yra tik
iliuzija. Ilgesniame laiko periode toks darbo stilius
niekuomet nepasiteisina.
• Viskas, ką pavyksta sutaupyti tokiu būdu, yra
prarandama dėl žemos sistemos kokybės ir sunkumų ką
nors joje pakeisti.
16
Reikalavimai
• Gerai suformuluotas reikalavimas turi būti (1):
• Abstraktus: Reikalavimas vadinamas abstrakčiu,
jei jis suformuluotas vadovaujantis juodosios dėžės
principu, t.y. specifikuoja operacinę (stebimą iš
išorės) sistemos savybę ir nieko nekalba apie tai,
kaip tą savybę realizuoti sistemoje.
• Išsamus: Reikalavimas vadinamas išsamiu, jei jis
turi prasmę ne tik tuomet, kai yra nagrinėjamas
kartu su kitais reikalavimais, bet ir tuomet, kai jis
nagrinėjamas atskirai.
17
Reikalavimai
• Tikslus: Reikalavimas vadinamas tiksliu, jei visi
jame vartojami terminai turi griežtai apibrėžtas
reikšmes.
• Tai reiškia, kad negalima vartoti žodelių maždaug, beveik,
apytiksliai ir pan. Negalima taip pat vartoti griežtai
neapibrėžtų terminų “turi būti patogus”, “naudoti nedaug
atminties”, “veikti greitai” ir pan.
• Suformuluoti tikslius reikalavimus yra nelengva:
• Formalios specifikacijos yra tikslios, bet jas sudėtinga parašyti ir
sunku skaityti.
• Natūraliąja kalba paprasta rašyti ir tokia kalba parašytus
reikalavimus lengva skaityti, bet jie dažniausiai yra netikslūs.
18
Reikalavimai
• Vienareikšmis: Reikalavimas vadinamas
vienareikšmiu, jei jo negalima interpretuoti
(suprasti) keliais skirtingais būdais.
• Tai nereiškia, kad reikalavimą galima įgyvendinti tik
vienu būdu.
• Patarimai
• Venk natūraliosios kalbos daugiaprasmiškumo
• Reikalavimą: “Kontrolinę sumą reikia imti iš paskutinio įrašo
“ galima interpretuoti trim skirtingais būdais:
• iš failo gale esančio įrašo;
• iš vėliausiai įrašyto įrašo;
• iš paskutinio apdoroto įrašo.
19
Reikalavimai
• Verifikuojamas: Reikalavimas vadinamas verifikuojamu
(patikrinamu), jei yra žinomas ir prieinamas baigtinis ir
kainos bei kitais požiūriais priimtinas procesas (testavimas,
stebėjimas, analizė ar kt.), kurį taikant galima nustatyti, ar
reikalavimas tikrai yra įgyvendintas.
• Netikslūs reikalavimai yra neverifikuojami.
• Įgyvendinamas: Reikalavimas vadinamas įgyvendinamu,
jei yra žinomas ir prieinamas toks ekonominiu, juridiniu bei
kitais požiūriais priimtinas technologinis procesas, kurio
inovaciniai slenksčiai gali būti pašalinti per priimtiną
laikotarpį ir už priimtiną kainą ir kurį taikant galima sukurti
sistemą, turinčią tuo reikalavimu specifikuojamą savybę.
20
Reikalavimai
• Integruojamas: Reikalavimas vadinamas
integruojamu, jei, sujungus jį su kitais
reikalavimais, yra gaunamas tarpusavyje suderintų
reikalavimų rinkinys.
• Lokalizuojamas: Reikalavimas vadinamas
lokalizuojamu, jei jį galima susieti su vienu ar
keliais konkrečiais kuriamos sistemos
komponentais, įgyvendinančiais tą reikalavimą.
• Ne visi reikalavimai yra lokalizuojami. Sistemos aplinkos
reikalavimai, projektavimo standartai ir kai kurie kiti
reikalavimai galioja visiems sistemos komponentams ir
negali būti lokalizuoti nei viename iš jų.
21
Reikalavimai
• Trasuojamas: Reikalavimas vadinamas
trasuojamu, jei jis yra vienareikšmiškai įvardinamas
(pvz., turi unikalų numerį) ir turi nuorodą į savo
šaltinį.
• Egzistuoja daug reikalavimų identifikavimo būdų. Vienas iš
efektyviausi yra vartoti raidžių ir skaitmenų kombinaciją.
Raidinė identifikatoriaus dalis nurodo reikalavimo rūšį (tam
pakanka fiksuoto raidžių skaičiaus), o skaitmeninė – tos rūšies
reikalavimo numerį.
• Trasavimas reikalingas reikalavimų valdymui. Padarius kokius
nors reikalavimų pakeitimus, trasuojamumas įgalina nustatyti,
kokie aukštesniųjų ir žemesniųjų lygmenų reikalavimai yra
susiję su keičiamu reikalavimu ir patikrinti, ar jų taip pat
nereikia keisti.
22
Reikalavimai
• Unikalus: Reikalavimas vadinamas unikaliu, jei
jame nėra kartojama kituose reikalavimuose
pateikta informacija.
• Glaustas: Reikalavimas vadinamas glaustu, jei
jame nėra pagrindimo, apibrėžčių ar kitų nebūtinų
dalykų.
• Suprantamas: Reikalavimas vadinamas
suprantamu, jei jis parašytas nevartojant tik
specialistams suprantamų terminų ir yra aiškiai
pasakyta, kokią funkcinę ar nefunkcinę savybę
privalo turėti sistema.
23
Reikalavimai
Funkciniai ir nefunkciniai reikalavimai
• Funkciniai reikalavimai: Reikalavimai, nusakantys,
kokias paslaugas privalo teikti sistema, kokia turi būti
jos reakcija į konkrečius stimulus ir kaip ji turi elgtis
konkrečiose situacijose.
• Nefunkciniai reikalavimai: Ribojimai potencialiai
galimų projektinių sprendimų aibei.
• Nefunkciniai reikalavimai apima ribojimus sistemos paslaugų
teikimo būdui (pvz., maksimali trukmė), jos įgyvendinamoms
funkcijoms (pvz., patikimumas), standartus, kurių privalu laikytis ir
pan.
• Projekto vykdymo reikalavimai taip pat yra nefunkciniai
reikalavimai.
24
Reikalavimai
Funkciniai reikalavimai
• Aprašo sistemos funkcionalumą bei jos
teikiamas paslaugas.
• Paslaugų pobūdis priklauso nuo
• kuriamos programinės įrangos pobūdžio;
• tos įrangos vartotojų pobūdžio.
25
Reikalavimai
• Vartotojo lygmens funkciniai reikalavimai gali
gana bendrai aprašyti, ką turi daryti sistema, bet
sistemos lygmens funkciniai reikalavimai visas
sistemos funkcijas (jos teikiamas paslaugas)
privalo specifikuoti labai detaliai.
• Pavyzdžiai
• Vartotojui turi būti leista egzamino rezultatus peržiūrėti
ekrane.
• Studentui turi būti sudaryta galimybė laikyti egzaminą per
internetą.
• Sistema privalo įvertinti studentų atsakymus.
26
Reikalavimai
• Vartotojo lygmens funkciniai reikalavimai:
• Kokias įeigas (komandas, duomenis) sistema turi
gebėti apdoroti.
• Kokius rezultatus sistema turi generuoti.
• Kokius duomenis sistema privalo įsiminti ir
padaryti prieinamus kitoms sistemoms.
• Kokius skaičiavimus sistema privalo atlikti.
27
Reikalavimai
• Funkciniai reikalavimai aprašo:
• pagrindinį (probleminį) sistemos funkcionalumą;
• t.y. funkcionalumą, kurio reikia patenkinti vartotojų
operacinius poreikius, nusakytus užduotimis
koncepciniame verslo modelyje.
• pagalbinį funkcionalumą;
• t.y. funkcionalumą, kurio reikia sistemai aptarnauti,
prižiūrėti, administruoti arba darbui su ja palengvinti.
28
Reikalavimai
• Funkciniai reikalavimai turi aprašyti visas sistemos
įgyvendinamas funkcijas.
• Viena vertus, funkcijos turi tenkinti poreikių
specifikacijoje aprašytus operacinius vartotojų poreikius.
• Kita vertus, funkciniai reikalavimai yra išvedami iš verslo
koncepciniame modelyje specifikuotų užduočių (tiksliau,
tų užduočių, kurias nuspręsta kompiuterizuoti).
• Koncepciniame verslo modelyje specifikuotų užduočių aibė nėra
išsami, nes ji neapima sistemos administravimo, aptarnavimo bei
priežiūros užduočių.
• Tos užduotys turėtų būti išvedamos iš sistemos naudojimo
scenarijaus.
29
Reikalavimai
Iš kur gaunami funkciniai reikalavimai
Operaciniai
poreikiai
Funkciniai
Užduotys reikalavimai
Sistemos naudojimo
scenarijus
30
Reikalavimai
• Funkcinis reikalavimas aprašo
• funkcijos įeigą (pradinius duomenis);
• funkcijos išeigą (rezultatą);
• principinį algoritmą (jei to reikia).
• Pradiniai duomenys ir rezultatai turi būti aprašyti
detalumu, pakankamu parašyti programą.
• Algoritmas reikalingas tam, kad būtų galima suprasti,
ką funkcija daro. Tačiau tai nereiškia, kad funkciją
reikia realizuoti naudojant būtent tokį algoritmą.
31
Reikalavimai
Įvesties ir išvesties duomenys
turi būti specifikuoti detaliai.
Programų sistema
Įeiga
DB Išeiga
Sistemos viduje esantys duomenys specifikuojami

nenurodant jų vaizdavimo detalių. Tą padarys projektuotojai.
32
Reikalavimai
PS savybės funkcinių reikalavimų atžvilgiu
• Korektiškumas: Programų sistema
vadinama korektiška, jei ji tenkina
operacinius vartotojų poreikius ir funkcinės
savybės atitinka reikalavimų specifikacija
numatytus reikalavimus.
• Jei programų sistema netenkina jos funkcinių
reikalavimų, ji daro ne tai, ko iš jos tikimasi ir
tampa nekorektiška.
33
Reikalavimai
Nefunkciniai reikalavimai
• Nefunkciniai reikalavimai aprašo sistemos
savybes ir jos ribojimus.
• Dažnai nefunkciniai reikalavimai yra netgi
svarbesni už funkcinius.
• Nefunkcinius reikalavimus labai sunku
suformuluoti tiksliai, o jeigu jie yra netikslūs, tai
tampa neverifikuojami ir praranda savo prasmę.
• Jei nefunkciniai reikalavimai netenkinami,
sistema yra niekam nereikalinga!
35
Reikalavimai
• Bendra problema, kuri dažniausiai atsiranda,
formuluojant nefunkcinius reikalavimus yra ta,
kad vartotojas arba užsakovas dažniausiai
pagrindinį dėmesį skiria bendriems
uždaviniams, kaip paprasta naudotis (ease of
use), sistemos gebėjimas greitai atsigauti po
trykių arba greitas atsakas į vartotojo
užklausas.
• Tai sukelia problemų PS inžinieriams, kadangi
lieka vietos interpretacijai.
36
Reikalavimai
• Bendra problema, formuluojant nefunkcinius
reikalavimus
• Pavyzdžiui, tipinė vadybininko nefunkcinio reikalavimo
formuluotė:
• Sistema turi būti lengvai naudojama medicinos personalo ir
turi būti organizuota taip, kad vartotojų klaidų kiekis būtų
minimizuotas.
• Nefunkcinis reikalavimas perrašomas taip, kad būtų
verifikuojamas:
• Medicinos personalas turi gebėti naudotis visomis sistemos
funkcijomis po to, kai išklausė keturių valandų mokymus
kaip naudotis sistema. Po šitų mokymų pažengusio
vartotojo daromų klaidų vidurkis neturi viršyti dviejų klaidų
per darbo su sistema valandą.
37
Reikalavimai
• Nefunkciniai reikalavimai aprašo:
• interfeiso ribojimus;
• veikimo ribojimus;
• ekonominius ribojimus;
• politinius ribojimus;
• teisinius ribojimus.
38
Reikalavimai
Interfeiso ribojimai
• Interfeiso ribojimai riboja sistemos ir jos aplinkos
sąveikos būdus.
• Programų sistemos aplinką sudaro:
• vartotojai;
• kitos dalykinės programų sistemos;
• operacinė sistema;
• duomenų bazės;
• kompiuterių tinklas;
• programavimo kalbos;
• dokumentai.
39
Reikalavimai
• Sistemos interfeisai
Tinklas
TCP/IP ,
GUS, Duomenų
Vartotojai OSI
bazės
Windows SQL
Sistema
ANSI/ISO LATEX,
PDF, PS,
Programavimo Dokumentų
POSIX RTF
kalbos mainai
Operacinė sistema
40
Reikalavimai
Interfeiso reikalavimai
• Funkciniai reikalavimai gali aprašyti kiekvienam
sistemos aplinkos elementui reikalingas paslaugas
ir funkcijas, bet ne sąveikos su jais būdus
(komandų sintaksę, dialogines formas, funkcinius
klavišus, pelės naudojimą ir pan.).
• Interfeiso reikalavimai nieko nekalba apie tai, ką sistema daro. Jie
aprašo, kaip tomis galimybėmis galima pasinaudoti.
• Pažeidus interfeiso reikalavimus, sistema išlieka korektiška, bet ji
praranda sąveikos su tam tikrais savo aplinkos elementais
(vartotojais, OS, DB ir t.t.) galimybes.
• Nors sistema ir vykdo visas numatytas funkcijas, tačiau jomis
nebegalima pasinaudoti.
41
Reikalavimai
• Interfeiso reikalavimai atsako į klausimus
• Kaip turi atrodyti vartotojo interfeisai?
• Kaip programų sistemos interfeisai turi susieti tą sistemą su jos
aplinkos elementais?
• Interfeiso ribojimai
• vartotojų interfeisų reikalavimai;
• sąveikos su operacine sistema reikalavimai;
• sąveikos su duomenų bazėmis reikalavimai;
• sąveikos su kompiuterių tinklais reikalavimai;
• sąveikos su programavimo aplinkomis reikalavimai;
• dokumentų mainų reikalavimai;
• sąveikos su kitomis dalykinėmis programų sistemomis reikalavimai.
42
Reikalavimai
• Vartotojo interfeiso reikalavimai
• užduočių formulavimo kalbos (UFK)
reikalavimai;
• naudojimo paprastumo (easy-to-use)
reikalavimai;
• patogumo vartotojui (user-friendless)
reikalavimai;
• ergonominiai reikalavimai.
43
Reikalavimai
• Vartotojo interfeisas: UFK
• Kalbos semantinė galia
• UFK konceptų abstrakcijos lygmuo
• Nelabai kvalifikuoto specialisto požiūris: “Tai per daug bendra,
kad būtų galima suprasti, ką gi konkrečiai padarys sistema
pateikus tokią užduotį.”
• Kvalifikuoto specialisto požiūris: “Tai per daug konkretu.
Formuluodamas tokias užduotis, aš susipainioju detalėse.“
• Dauguma žmonių masto tam tikro abstrakcijos lygmens
terminais ir nervinasi, jei jie yra verčiami mąstyti kito lygmens
terminais.
• Viskas priklauso nuo konkretaus vartotojo: viskas turi
būti kuo paprasčiau, bet ne per daug supaprastinta!
44
Reikalavimai
• Kalbos procedūriškumas
• algoritmo samprata, kuria grindžiama UFK
• esti procedūrinės (pvz., Pascal), deklaratyviosios
(pvz., Prolog), funkcinės (pvz., Lisp), objektinės
(pvz., SmallTalk) ir hibridinės (pvz., C++)
programavimo kalbos;
• UFK irgi gali būti grindžiama bet kuria iš šių
paradigmų.
45
Reikalavimai
• procedūrinėse kalbose algoritmai yra aprašomi
naudojant Tiuringo mašinų formalizmą
• tai reiškia, kad užduotis yra aprašoma kaip (nebūtinai tiesinė)
seka komandų, keičiančių tam tikro kintamųjų rinkinio
(atminties) reikšmes;
• procedūrinėse kalbose išreikštiniu būdu (nors galbūt aykšto
abstrakcijos lygmens komandomis) specifikuojamas užduoties
vykdymo algoritmas.
46
Reikalavimai
• deklaratyviosiose kalbose algoritmai yra aprašomi
naudojant Markovo natūrinių algoritmų formalizmą
• tai reiškia, kad užduotis yra aprašoma kaip rinkinys faktų ir
loginių taisyklių, nusakančių kaip iš turimų faktų gauti norimus
rezultatus;
• deklaratyviosiose kalbose aprašoma, ką užduotis turi padaryti,
bet nėra nurodoma, kokiu būdu gauti rezultatus.
47
Reikalavimai
• funkcinėse kalbose algoritmai yra aprašomi
naudojant rekursyviųjų funkcijų formalizmą
• tai reiškia, kad užduotis yra aprašoma kaip tam tikra
funkcijų (atvaizdžių) kompozicija;
• funkcinėse kalbose aprašoma kaip, vienų funkcijų
rezultatams taikant kitas funkcijas, iš pradinių
duomenų gauti norimus rezultatus.
48
Reikalavimai
• objektinėse kalbose algoritmai yra aprašomi naudojant
vadinamąjį aktorių formalizmą
• tai reiškia, kad užduotis yra aprašoma pranešimų (reikalavimų atlikti
operacijas) seka;
• objektinėse kalbose aprašoma, kaip pakeisti pradines tam tikram
rinkiniui priklausančių objektų būsenas į norimas (tai ir yra užduoties
rezultatas).
• Kokio tipo UFK geriau pasirinkti, priklauso ir nuo programų
sistemos probleminės srities, ir nuo to, per kokią sąvokų sistemą
vartotojai suvokia tą probleminę sritį
• t.y. nuo to, kaip jų nuomone turėtų būti aprašinėjami algoritmai.
49
Reikalavimai
• Kalbos dalykinė orientacija
• kalbos dalykinė orientacija priklauso nuo metaforos,
kuria grindžiama kalba
• žmonės naujus dalykus perpranta naudodamiesi savo
turimomis žiniomis ir patirtimi;
• bent jau pradžioje, naujas sąvokas stengiamasi išreikšti per
jau žinomas sąvokas.
50
Reikalavimai
• vartotojai, bent jau pradžioje, taip pat bando
programų sistemą suvokti per tai, ką jie jau žino apie
dalykinę sritį, t.y. jie bando mąstyti dalykinės srities
metaforos terminais.
• Metaforizavimo principas: Naujas pažinimo struktūras
žmonės kuria metaforizuodami esamas (jau
išstudijuotas) pažinimo struktūras.
51
Reikalavimai
• Pavyzdys
• Įstaigos vadovas įsisavindamas naują duomenų apdorojimo
sistemą bando ją “matyti” per įstaigą aprašančių sąvokų
prizmę.
• Tai apima įstaigos tikslus, naudojamą biuro įrangą, darbuotojų
vaidmenis, jų vykdomas užduotis ir darbo metu kylančių
problemų sprendimo būdus.
• Sistemos projektuotojai privalo perprasti įstaigos sąvokų
sistemą ir projektuoti užduočių formulavimo kalbą taip, kad
įstaigos vadovas (o taip pat ir kiti darbuotojai) galėtų
formuluoti užduotis jiems įprastais terminais (o ne
programuotojų žargonu).
52
Reikalavimai
• Kad metafora būtų naudinga, ji turi būti išreikštiniu
būdu susieta su tuo, ką norima metaforizuoti t.y. su
problemine sritimi.
• Svarbi tokios sąsajos (tiksliau, atvaizdžio) savybė yra
jos kongruentiškumas: probleminės srities esybės ir
ryšiai turi būti tiesiogiai atvaizduojami į interfeiso
esybes (piktogramas, komandų pavadinimus, objektų
pavadinimus ir t.t.) ir ryšius taro jų.
• t.y. gerą metaforą galima sukonstruoti tik vadovaujabtis
konceptualizacijos principu.
53
Reikalavimai
• Jei visa programa ir atskiri jos elementas yra lengvai susiejami su
atitinkamais vartotojo aplinkos procesais bei objektais, tai,
vaizdžiai tariant, vartotojas pasijunta kaip žuvis vandenyje ir gali
laisvai “plaukioti” po sistemą. Visų pirma tai liečia vartotojo
interfeisą ir su juo siejamą užduočių formulavimo kalbą.
• Viena iš labiausiai paplitusių metaforų yra darbo stalo metafora.
Ja grindžiamas daugumos biuro sistemų interfeisas.
• Pagrindinis programos langas imituoja darbo stalo paviršių, kuriame
yra išdėstyti įvairūs dokumentai ir darbo priemonės (žirklės, trintukas ir
kt.).
• Dokumentus galima pasižiūrėti atitinkamuose “languose", kas imituoja
dokumento paėmimą skaitymui ar redagavimui.
• Dokumentai yra sudėlioti į “aplankus", juos galima keisti, naikinti ir k.t.
54
Reikalavimai
• Kalbos selektyvinė geba
• Duomenų filtravimas – tai procesas, naudojant kurį iš
įvesties ar išvesties duomenų srauto yra išrenkamas
(nufiltruojant kitus) nurodytas sąlygas tenkinantis
duomenų poaibis.
• Pavyzdys
• INCLUDE IN ATASKAITA DARBUOTOJUS WHERE
ATLYGINIMAS>=50000
• Filtrai aprašomi naudojant kvalifikavimo išraiškas
• Kvalifikavimo išraišką sudaro loginėmis operacijomis (IR,
ARBA, NE ir t.t.) sujungti predikatai (t.y. sąlygos).
55
Reikalavimai
• Kalbos selektyvinė geba
• Kalbos selektyvinė geba priklauso nuo to, kokios
kvalifikavimo išraiškos yra leidžiamos užduočių
formulavimo kalboje.
• Selektyvinė geba nusako kokiu tikslumu galima filtruoti
įvesties ir išvesties duomenis. Kitaip tariant, ji lemia kokiu
tikslumu vartotojas gali aprašyti užduoties pradinius duomenis
(imamus iš įvesties srauto arba iš DB) ir užduoties rezultatus
(pvz., ką ir kokia tvarka spausdinti norimoje gauti
ataskaitoje).
56
Reikalavimai
• Kalbos raiškos galia (išsamumas)
• UFK yra išsami jei jos raiškos priemonėmis galima
specifikuoti visus užduoties aspektus.
• Kartais UFK turi priemones tik skaičiuojamiesiems užduoties
aspektams aprašyti, nes kiti aspektai (pvz., duomenų rašymas
į bazes ar ataskaitų generavimas) yra aprašomi kitomis
kalbomis.
• Kartais, kuriant UFK, nepavyksta tiksliai specifikuoti visų
galimų užduočių aibę. Taigi, neįmanoma ir tiksliai numatyti,
kokių priemonių prireiks užduotims specifikuoti. Tokiais
atvejais kalboje numatoma išplėsties taško konstrukcija ir
leidžiama prie užduoties aprašymo jungti plėtinius parašytus
skriptų programavimo kalbose (Perl, JavaScript ir kt.)
57
Reikalavimai
• Sintaksė
• UFK gali būti suprojektuota kaip
• tekstinė kalba (pvz., sakiniai, primenantys lietuvių kalbos
sakinius);
• meniu kalba;
• formų kalba;
• grafinė kalba;
• piktogramų kalba;
• hiperteksto kalba
• ir t.t.
58
Reikalavimai
• Užduoties pateikties protokolas (UPP)
• Užduoties aprašas yra pateikiamas sistemai pagal taisykles,
numatytas atitinkamu protokolu. Formuluojant interfeiso
ribojimus turi būti suformuluoti ir užduočių pateikties
protokolo reikalavimai.
• UPP aprašo, kokiais pranešimais, pateikdamas užduotį,
vartotojas keičiasi su sistema, kokia eilės tvarka pranešimai
yra pateikiami ir kaip, pasinaudojant atitinkama technine
įranga (klaviatūra, pele ar pan.), pranešimai yra
formuluojami ir perduodami.
59
Reikalavimai
• Vartotojo interfeisas
• Naudojimo paprastumo (easy-to-use) reikalavimai
• Vidinė darna: komandų formato standartas, klavišų naudojimo
nepriklausomybė nuo konteksto, pranešimuose vartojamų
terminų darna, manipuliavimo ekranu operacijų standartas ir t.t..
• Išorinė darna: atitikimas išoriniams standartams (pvz., GUI
standartams).
• Akivaizdumas: interfeisas suprojektuotas metaforos terminais.
• Informatyvumas: informuoja apie padarytų klaidų pobūdį,
aiškina kaip elgtis ir pan.
• Prasmingumas: visi sistemos pranešimai yra glausti,
informatyvūs ir formuluojami metaforos terminais.
60
Reikalavimai
• Vartotojo interfeisas
• Patogumo vartotojui (user-friendliness)
reikalavimai
• Informavimo priemonių tinkamumas (helpfulness): ką
reikia įtraukti į informavimo (help) failus ir kaip tie failai
turi būti organizuoti.
• Patrauklumas: spalvos ir kiti dizaino ypatumą.
• Individualizavimas: kaip vartotojas gali individualizuoti
(prisitaikyti savo pomėgiams) interfeisą.
• Ergonominiai reikalavimai
• kaip atsižvelgti į potencialių vartotojų psichofiziologines
charakteristikas (pvz., aklus vartotojus).
61
Reikalavimai
Veikimo ribojimai
• Veikimo ribojimai apima:
• tikslumo reikalavimus;
• patikimumo reikalavimus;
• gyvybingumo reikalavimus;
• robastiškumo reikalavimus;
• našumo reikalavimus.
62
Reikalavimai
Veikimo ribojimai
• Pažeidus veikimo reikalavimus, sistema išlieka
korektiška. Nėra pažeidžiama ir jos sąveika su
aplinka. Tačiau yra prarandama jos operacinė
kokybė
• pvz., ji veikia lėčiau, yra mažiau patikima ar labiau
pažeidžiama.
63
Reikalavimai
Veikimo ribojimai
• Tikslumas
• Nepakanka vien tik pasakyti, kad programų
sistema turi mokėti paskaičiuoti, tarkime,
įmonės mėnesines išlaidas gamybai.
• Kokiu tikslumu tai reikia paskaičiuoti?
• Ką turi daryti sistema tuo atveju, kai jai
nepakanka duomenų?
• Kokie turi būti kiti kokybiniai tos funkcijos
parametrai?
64
Reikalavimai
Veikimo ribojimai
• Tikslumas
• Duomenų vaizdavimo tikslumas
• Programų sistemos geba skirti panašius objektus vieną nuo kito.
• pvz.,. du asmenis ar du skaičius
• jei duomenų vaizdavimo tikslumas yra nepakankamas, sistema gali
neskirti Jono Matusos (sistemoje vaizduojamas kaip J. Matusa) ir
Jurgio Matusos (sistemoje taip pat vaizduojamas kaip J. Matusa);
• keturis ženklus po kablelio turintys skaičiai yra mažiau tikslūs kaip
tie, kurie turi šešis ženklus po kablelio;
• tačiau teisingai paskaičiuotas keturis ženklus po kablelio turintis
skaičius gali būti tikslesnis už neteisingai paskaičiuotą šešis ženklus
po kablelio turintį skaičių.
65
Reikalavimai
Veikimo ribojimai
• Tikslumas
• Skaičiavimų tikslumas
• Nusako, kokio dydžio skaičiavimų paklaidos yra
leistinos sistemoje.
• paklaidos gali atsirasti ne tik atliekant skaičiavimus įprasta
prasme, bet ir transformuojant bet kokį skaitmeninį objektą.
• pvz., paveikslėlio transformavimas iš .gif formato į .jpg
formatą.
• Kitaip tariant, nusako rezultatų tikslumą.
• paklaida – tai skirtumas tarp paskaičiuotos reikšmės ir tos,
kuri turėtų būti gauta teoriškai.
66
Reikalavimai
Veikimo ribojimai
• Tikslumas
• Į sistemą vedami duomenys turi tenkinti verslo
taisykles.
• Verslo taisyklės reglamentuoja duomenų tikslumą ir
išsamumą.
• Aišku, kad, pažeidus organizacijos verslo taisyklių
reikalavimus, duomenys praranda savo vertę (kokybę).
• Tai reiškia, kad, kuriant sistemą, reikia išreikštiniu
būdu suformuluoti verslo taisykles ir jas teisingai
taikyti.
67
Reikalavimai
Veikimo ribojimai
• Tikslumas
• Kokio tikslumo reikia, priklauso nuo sistemos
paskirties ir jos realizuojamų funkcijų pobūdžio.
• Jei didelio tikslumo nereikia, nėra jokios prasmės
reikalauti, kad, tarkime, skaičiavimo paklaidos
neviršytų 0.00001.
• Pasiekti tikslumą kainuoja, todėl reikia reikalauti tokio
tikslumo, kokio iš tiesų reikia, bet ne didesnio.
68
Reikalavimai
Veikimo ribojimai
• Patikimumas
• Programų sistemos trykių neigiamo poveikio
vartotojų verslo tikslams dydis.
• Tai normalaus veikimo trykių dažnio ir rimtumo
matas.
• Matų pavyzdžiai:
• vidutinis laikas tarp dviejų trykių;
• tikimybė, kad sistema nebus galima pasinaudoti;
• vidutinis trykių dažnis;
• dėl trykių prarandamo laiko procentas.
69
Reikalavimai
Veikimo ribojimai
• Patikimumas
70
Reikalavimai
Veikimo ribojimai
• Gyvybingumas
• Programų sistemos geba apsaugoti jos kritines
funkcijas nuo trykių poveikio.
• Kokiu mastu sistema gebės vykdyti kritines
(gyvybines) funkcijas trykiams pažeidus kitas jos
dalis.
71
Reikalavimai
Veikimo ribojimai
• Robastiškumas
• Programų sistemos geba automatiškai atkurti savo
prarastą funkcionalumą, ypač, praradus jį dėl klaidingų
duomenų arba dėl kokių nors ypatingų situacijų
• Nusako, kokiu mastu sistema geba išvengti trykių pateikus jai
neteisingus duomenis arba ja neteisingai naudojantis.
• Tai sistemos “nenumušamumo” matas.
• Pavyzdžiui, operacinė sistema laikoma robastiška, jei ji geba
išlikti korektiška jai pritrūkus operatyviosios ar išorinės atminties
arba vykdant klaidų turinčią dalykinę programą arba tai
programai elgiantis nekorektiškai, pavyzdžiui, bandant
pasinaudoti kitai programai priskirta atmintimi.
72
Reikalavimai
Veikimo ribojimai
• Robastiškumas
• Matų pavyzdžiai:
• laikas, reikalingas sistemos funkcionalumui atkurti;
• trykius iššaukiančių įvykių procentas;
• tikimybė, kad trykio metu bus sugadinti duomenys.
73
Reikalavimai
Veikimo ribojimai
• Našumas
• Nusako kaip greitai sistema reaguoja į stimulus
ir kiek resursų ji sunaudoja tai darydama.
• Yra keli našumo aspektai
• reakcijos laikas (response time);
• pralaidumas (throughput);
• produktyvumas (efficiency);
• gaišties laikas (latency);
• masto keitimas (scalability).
74
Reikalavimai
Veikimo ribojimai
• Našumas
• Reakcijos laikas
• Reakcijos laiko į įvykius (behavioural response time)
reikalavimai apibūdina vartotojo sąveiką su sistema
• Apskritai, vartotojas tikisi, kad sistema atsakys jam per kelias
sekundes, nepriklausomai nuo to, ką kompiuteris tuo metu
daro.
• Atsakymas ne būtinai turi būti laukiamas rezultatas, bet
sistema turėtų bent jau parodyti, kad ji priėmė vartotojo
pateiktą užduotį.
• Labai svarbu, kad sistema iš karto vienaip ar kitaip atsakytų į
bet kokius vartotojo veiksmus.
75
Reikalavimai
Veikimo ribojimai
• Našumas
• Reakcijos laikas
• Rezultatų pateikties laiko (operational response time)
reikalavimai
• Jei programų sistema kompiuterizuoja kokias nors rankines
procedūras, kurioms atlikti reikėjo visos savaitės, o dabar
pakanka vienos valandos, tai be abejo jau yra didelis
pasiekimas.
• Formuluojant rezultatų pateikties laiko reikalavimus, visų
pirma reikia galvoti apie tai, kiek laiko galima skirti atitinkamai
verslo operacijai atlikti.
• Kaip greitai turi veikti sistema, kad būtų pasiekti
organizacijos verslo tikslai?
76
Reikalavimai
Veikimo ribojimai
• Našumas
• Gaišties laikas (latency)
• Kiek laiko prie nurodyto apkrovos (pvz., apdorojamų
duomenų apimčių) dydžio gali sugaišti sistema vienam
įvykiui apdoroti?
• Pralaidumas (throughput)
• Kiek įvykių per nurodytą laiko tarpą prie nurodyto
apkrovos (pvz., apdorojamų duomenų apimčių) dydžio
turi gebėti apdoroti sistema?
77
Reikalavimai
Veikimo ribojimai
• Našumas
• Produktyvumas
• Kiek resursų galima sunaudoti nurodytiems
pralaidumu ir produktyvumui užtikrinti?
• Masto keitimas (scalability)
• Kiek papildomų resursų galima sunaudoti nurodytiems
pralaidumu ir produktyvumui užtikrinti didinant
sistemos apkrovas?
78
Reikalavimai
Veikimo ribojimai
• Našumas
79
Reikalavimai
Veikimo ribojimai
• Našumas
80
Reikalavimai
Ekonominiai ribojimai
• Ekonominiai ribojimai formuluojami siekiant
sumažinti ilgalaikes išlaidas sistemai.
• Pažeidus ekonominius ribojimus, užsakovas
ir/arba vykdytojai be reikalo praranda tam tikras
pinigų sumas ir tai atsitinka todėl, kad tam tikros
sistemos savybės buvo nepakankamai gerai
apgalvotos.
• Sistema išlieka korektiška, jos sąveika su aplinka nėra
pažeidžiama ir ji nepraranda savo veikimo kokybės.
• Taigi, paprastai sistemos vartotojas tiesiogiai nepajunta
jokių ekonominių ribojimų pažeidimo pasekmių.
81
Reikalavimai
• Lėšos gali būti prarastos dėl to, kad su
sistema sunku dirbti ją diegiant,
aptarnaujant ar prižiūrint, arba dėl to, kad
jos komponentų negalima tiražuoti t.y.
pakartotinai panaudoti kituose projektuose.
• Taigi, iš ekonominių ribojimų išplaukia;
• diegiamumo reikalavimai;
• aptarnaujamumo reikalavimai;
• prižiūrimumo reikalavimai;
• tiražuojamumo reikalavimai.
82
Reikalavimai
• Diegiamumo reikalavimai
• Instaliuojamumas
• ruošinio patikimumas, instaliavimo trukmė,
instaliavimo procedūros, parametrizavimas,
konfigūravimo galimybės, resursų poreikis
(instaliavimui).
• Įsisavinamumas
• Matas: tikimybė, kad per laiką [t1,t2] atitinkamą
išsilavinimą turintis asmuo sugebės išmokti dirbti su
sistema ar ją administruoti.
• Pastangos duomenų bazėms sukurti
83
Reikalavimai
• Išmokstamumas
• Išmokstamumas priklauso nuo:
• suprantamumo;
• sudėtingumo.
• Suprantamumas, savo ruožtu, priklauso nuo:
• koncepcinės skaidros,
• virtualumo.
84
Reikalavimai
• Išmokstamumas
• Programų sistema yra koncepciškai skaidri, jei ji
• turi darnų, akivaizdų, informatyvų ir prasmingą
vartotojo interfeisą;
• yra komunikatyvi,
• t.y. tiek jos įvesties, tiek ir išvesties duomenys yra glausti,
prasmingi ir pateikiami vartotojui lengvai suprantama forma.
85
Reikalavimai
• Išmokstamumas
• Programų sistema vadinama virtualia, jei ji
nuo vartotojo slepia kompiuterinę platformą.
• Tai reiškia, kad sistema galima pasinaudoti
neturint jokių (arba tik minimalias) žinių apie
techninės įrangos, sisteminės PĮ ar
kompiuterių tinklo ypatumus.
86
Reikalavimai
• Išmokstamumas
• Programų sistemos sudėtingumas priklauso nuo jos
realizuojamų funkcijų skaičiaus, tų funkcijų
semantinės galios ir jų tarpusavio sąryšių.
• Pastangos duomenų bazėms sukurti
• siekiant palengvinti pradinį DB kūrimą, sistemoje
reikia numatyti specialiai tam skirtas funkcijas
(duomenims skaitmenizuoti, naujoms DB kurti,
liktinėms DB transformuoti į naują formatą ir t.t.).
87
Reikalavimai
• Aptarnaujamumo reikalavimai
• Vartotojų (įskaitant sistemą administruojantį
personalą) pastangos, kurių prireikia naudojant
sistemą savo užduotims vykdyti.
• galimybė pritaikyti sistemą prie vartotojo įgūdžių
lygmens, sistemos veiksmų siejimas su užduočių
vykdymo kontekstu, specialus dažnai vykdomų
operacijų palaikymas, “karštieji” klavišai ir t.t.
88
Reikalavimai
• Prižiūrimumo reikalavimai
• Nuo jų priklauso sistemos darnos palaikymo ir
jos perdarymų išlaidos.
• Prižiūrimumas priklauso nuo:
• Taisomumo: Kiek pastangų reikia klaidoms pašalinti?
• Keičiamumo: Kiek pastangų reikia sistemai pritaikyti
prie jos reikalavimų pokyčių?
• Plečiamumo: Kiek pastangų reikia sistemos
komponentams pakeisti ir jos funkcionalumui išplėsti?
89
Reikalavimai
• Prižiūrimumo reikalavimai
• Prižiūrimumas priklauso nuo:
• Perkeliamumo: Kiek pastangų reikia sistemai į
kitą platformą perkelti?
• Komponuojamumo: Kiek pastangų reikia
sistemos sąveikai su kitomis sistemomis
organizuoti?
• Testuojamumo: Kiek pastangų reikia testams
sistemos savybėms patikrinti suprojektuoti ir
sukurti?
90
Reikalavimai
• Tiražuojamumo reikalavimai
• kurie komponentai turi būti tiražuojami?
• kokius reikalavimus turi tenkinti
tiražuojami komponentai?
• t.y. kokie komponentų tiražavimo metodai
planuojami naudoti.
91
Reikalavimai
• Portability: How easy is it to adapt the software to run
on different platforms
92
Reikalavimai
Politiniai ribojimai
• Politiniai ribojimai išplaukia iš organizacijos verslo
politikos ypatumų. Tai, visų pirma, verslo
paslapčių apsaugos klausimai. Sistemai pažeidus
verslo ribojimus, yra pažeidžiama organizacijos
verslo politika.
• Apsaugos (security) reikalavimai
• Apibrėžia, kokiu mastu sistema turi būti apsaugota nuo
galimybių ja pasinaudoti neteisėtai.
• Teisėtu PS naudojimu vadinamas sistemos naudojimas pagal jos
paskirtį, atliekamas tam oficialius įgaliojimus turinčio asmens ar
proceso (įskaitant kitas programų sistemas).
93
Reikalavimai
• Apsaugos reikalavimai:
• grėsmės, nuo kurių turi būti apsaugota sistema;
• vartotojų ir procesų registravimo procedūros;
• vartotojų ir procesų skirstymo į klases ir teisių
priskyrimo toms klasėms taisyklės;
• vartotojų ir procesų autorizavimo taisyklės;
• duomenų ir sistemos funkcijų klasifikavimo pagal
slaptumo kategorijas taisyklės ir tų klasių apsaugos
lygmenys.
94
Reikalavimai
• Apsaugos reikalavimai
95
Reikalavimai
96
Reikalavimai
97
Reikalavimai
98
Reikalavimai
Teisiniai ribojimai
• Teisiniai ribojimai reglamentuoja kas leidžiama ir
kas neleidžiama daryti kuriamoje PS, atsižvelgiant
į galiojančius teisės aktus (asmens duomenų
apsauga, statistinių duomenų apdorojimas ir
pateiktis, garbinga konkurencija, teisinis
konkrečios dalykinės srities reguliavimas ir kt.).
• Iš teisinių ribojimų išplaukiantys reikalavimai
specifikuoja tas PS savybes, kurios garantuoja, kad
naudojantis sistema nebus pažeisti kokie nors įstatymai,
standartai, vyriausybės nutarimai ir pan.
• Formuluojami tik tokie reikalavimai, kurie vienaip ar kitaip suvaržo
sistemą kuriančių projektuotojų ar programuotojų veikimo laisvę.
99
Reikalavimai
Nefunkciniai ribojimai
• Reikalavimai
turi būti
formuluojami
taip, kad juos
galima būtų
patikrinti.
100
ISO 9126 (Quint)

• Quint – tai plačiai naudojamas PĮ kokybės
standarto ISO 9126 plėtinys
• Quint = QUality in InformatioN Technology;
• Quint skiria 6 PĮ kokybės atributų klases ir 32 atributus;
• Quint apibrėžia kokybės matavimo matus;
• dėl visų šių priežasčių Quint yra labai svarbus
formuluojant PS reikalavimus.
• Svarba: Quint pateikia sąvokų sistemą, vartojant
kurią PS užsakovai, vartotojai ir tą sistemą
kuriantys PS inžinieriai gali diskutuoti apie PS
kokybę ir susitarti apie konkrečių kokybės
atributų prioritetus.
101
Reikalavimai
ISO 9126 (Quint)
• Quint ir užduočių modeliavimo panaudojimas
specifikuojant nefunkcinius PS reikalavimus:
1. konkrečiai PS ne visi 32 kokybės atributai yra vienodai
svarbūs: nustatyk jų prioritetus!
2. formuluok reikalavimus taip, kad būtų galima
pamatuoti jų įgyvendinimo laipsnį
• ne: “Sistema turi būti patogi vartotojui”
• bet: “Nei vienai užduočiai formuluoti vartotojas neturi gaišti
daugiau kaip 2 minutes”.
3. Siek reikalavimus su konkrečiomis užduotimis
• Pavyzdys: “PS turi patikrinti PIN kodą per 1 sekundę”.
102
Reikalavimai
• ISO 9126 (Quint) kokybės atributai
Funkcionalumas Panaudojamumas
Prižiūrimumas
Tinkamumas Suprantamumas Analizuojamumas
Tikslumas Išmokstamumas Keičiamumas
Interoperabilumas Operabilumas Stabilumas
Darnumas Būsenos vizualizavimas Testuojamumas
Apsauga Individualizuojamumas Valdomumas
Trasuojamumas Patrauklumas Tiražuojamumas
Aiškumas
Patikimumas Informatyvumas
Patogumas vartotojui Perkeliamumas
Išbaigtumas
Atsparumas trykiams Našumas Adaptuojamumas
Atkuriamumas Instaliuojamumas
Prieinamumas Našumas pagal laiką Atitikimas standartams
Pažeidžiamumas Našumas pagal resursus Pakeičiamumas
103
Reikalavimai
• ISO 9126 approach
• Funkcionalumas (functionality): kokiu mastu
sistemos funkcijos tenkina užsakovo (vartotojų)
poreikius ir ar tos funkcijos turi pageidaujamas
savybes.
Tinkamumas Darnumas
Tikslumas Apsaugotumas
Interoperabilumas Trasuojamumas
104
Reikalavimai
• ISO 9126: funkcionalumas
• Tinkamumas (suitability)
• Sistemos funkcijų tinkamumas vartotojų poreikiams
tenkinti ir jų išsamumas.
• Reikalavimų įgyvendinimui matuoti skirtų matų
pavyzdžiai:
• probleminės srities užduočių padengimo sistemos funkcijomis
procentas;
• pakeistų funkcinių reikalavimų procentas (per pasirinktą
laikotarpį);
• prašymų tobulinti sistemą skaičius (per pasirinktą laikotarpį);
• vartotojų nusiskundimų skaičius (per pasirinktą laikotarpį).
105
Reikalavimai
• Tikslumas (accuracy)
• Apibūdina, kokiu tikslumu sistema atlieka
skaičiavimus bei kitus perdirbimus.
• Reikalavimų įgyvendinimui matuoti skirtų
matų pavyzdžiai:
• netiksliai paskaičiuotų (per pasirinktą laikotarpį)
užduočių procentas;
• reikalaujamo ir sistemoje įgyvendinto reikšminių
ženklų po kablelio santykis;
• leistinas apvalinimo paklaidas darančių funkcijų
procentas.
106
Reikalavimai
• Sąveikos (interoperability)
• Apibūdina sistemos gebėjimą kooperuotis su kitomis
sistemomis.
pavyzdžiai:
• pastangos, reikalingos sistemos sąveikai su nauja sistema
realizuoti;
• duomenų formatų, kuriais sėkmingai keičiamasi su kitomis
sistemomis, procentas;
• grafinių ir valdančiųjų ženklų, kuriais sėkmingai keičiamasi su
kitomis sistemomis, procentas;
• teisingai realizuotų sąveikos interfeisų procentas;
• sistemoje realizuotų sąveikos standartų procentas.
107
Reikalavimai
• Darna, atitikimas (compliance)
• Apibūdina, kokiu mastu sistema yra suderinta su galiojančiais teisės
aktais ir dalykinėje srityje galiojančiais standartais bei susitarimais.
• Reikalavimų įgyvendinimui matuoti skirtų matų pavyzdžiai:
• standartizuotų duomenų vaizdavimo formatų procentas (lyginant su tuo,
kas turėjo būti pagal reikalavimus);
• standartizuotų media formatų procentas (lyginant su tuo, kas turėjo būti
pagal reikalavimus);
• standartizuotų grafinių ir valdančiųjų ženklų procentas (lyginant su tuo,
kas turėjo būti pagal reikalavimus);
• standartizuotų interfeisų procentas (lyginant su tuo, kas turėjo būti
pagal reikalavimus);
• nurodytus standartus atitinkančių funkcijų procentas (lyginant su tuo,
kas turėjo būti pagal reikalavimus).
108
Reikalavimai
• Apsauga (security)
• Apibūdina sistemos gebėjimą apsisaugoti nuo
tyčinio ar netyčinio neteisėto jos funkcionalumo ar
joje saugomų duomenų panaudojimo.
• tikimybė, kad, turint nurodytas resursų (pinigų, laiko, aparatūros)
apimtis, galima apeiti sistemos apsaugos priemones;
• kiek laiko patyrę hakeriai, turėdami fizinę prieigą prie sistemos,
nepajėgia į ją įsilaužti;
• koks procentas (lyginant su tuo, ką reikėjo padaryti pagal
reikalavimus) duomenų yra koduojamas;
• prie kokio procento konfidencialių duomenų per pasirinktąjį periodą
buvo neteisėtai prieita;
• kiek kartų per pasirinktąjį periodą buvo sugadinti duomenys.
109
Reikalavimai
• Trasuojamumas (traceability)
• Apibūdina pastangas, kurių reikia tam, kad
pasirinktuose programos taškuose būtų galima
patikrinti tarpinių skaičiavimų rezultatų
teisingumą.
matų pavyzdžiai:
• kiek laiko (procentais) gaišta sistema trasavimui;
• kiek laiko (procentais nuo viso užduočiai atlikti
reikalingo laiko) reikia žmogui trasavimui atlikti.
110
Reikalavimai
• ISO 9126: patikimumas
• Patikimumas (reliability): PS gebėjimas,
tinkamai eksploatuojant tą sistemą,
specifikacijoje nurodytą laiko tarpą išlikti
korektiška ir produktyvia.
Išbaigtumas Prieinamumas
Atsparumas trykiams Pažeidžiamumas
Atkuriamumas
111
Reikalavimai
• Išbaigtumas (maturity)
• Programoje esančių klaidų sukeliamų trykių dažnis.
Reikalavimų įgyvendinimui matuoti skirtų matų
pavyzdžiai:
• vidutinis laikas tarp dviejų trykių;
• trumpiausias laiko tarpas tarp dviejų trykių, įvykusių per
nurodytą laiko periodą;
• esamų klaidų (pagal vertinimus) ir baigto produkto apimties
(pvz., operatoriais) santykis;
• per pasirinktą laiko tarpą ištaisytų klaidų ir, pagal vertinimus,
sistemą baigus joje likusių klaidų santykis;
• atliktų testų ir sistemos apimties santykis;
• atliktų testų ir reikiamų atlikti testų santykis.
112
Reikalavimai
• Atsparumas trykiams (fault tolerance)
• Apibūdina, kokiu mastu sistema geba išlikti
korektiška ir produktyvi, po trykių ar
įsilaužimų.
pavyzdžiai:
• dėl trykių ar įsilaužimų prarastas laikas (per pasirinktą laiko periodą);
• laikas, per kurį galima nutraukti sistemos darbą, pastebėjus trykį ar
įsilaužimą;
• įsilaužimo per pasirinktąjį laiko periodą tikimybė;
• korektiškumo ar produktyvumo praradimų skaičiaus ir pastebėtų
trykių skaičiaus santykis;
• Sistemos pranešimų apie klaidas ir faktiškai įvykusių klaidų per
pasirinktąjį laiko periodą skaičius.
113
Reikalavimai
• Atkuriamumas (recoverability)
• Apibūdina pastangas, reikalingas atkurti po trykio
prarastą sistemos funkcionalumą ir/arba duomenis.
pavyzdžiai:
• vidutinis laikas, reikalingas sistemos funkcionalumui atkurti;
• automatiškai atkurto funkcionalumo ir prarasto funkcionalumo
atvejų santykis;
• maksimalus laikas, kurio prireikė prarastam funkcionalumui
atkurti;
• laikas, kurio prireikė dirbtinai įvestai klaidai pašalinti.
114
Reikalavimai
• Prieinamumas (availability)
• Laikas, per kurį galima pasinaudoti sistema, jei jos
prireikia.
pavyzdžiai:
• laikas, kurį per pasirinktąjį laiko periodą sistema yra
funkcionali ir produktyvi;
• laiko trukmės, kuomet sistema galima naudotis, ir laiko
trukmės, kuomet sistema reikėtų pasinaudoti, santykis;
• procentas laiko, kuriuo per sistemos stebėjimo periodą galima
pasinaudoti sistema.
115
Reikalavimai
• Pažeidžiamumas (degradability)
• Pastangos, reikalingos atkurti esmines
sistemos funkcijas, jai praradus savo
funkcionalumą.
matų pavyzdžiai:
• kiek laiko prireikė atkurti esmines sistemos
funkcijas, dirbtinai “numušus” jos funkcionalumą.
116
Reikalavimai
• ISO 9126:
• Perkeliamumas (portability): galimybė kelti
programų sistemą iš vienos platformos į kitą.
Atitikimas
Adaptuojamumas standartams
Instaliuojamumas Pakeičiamumas
117
Reikalavimai
• ISO 9126: perkeliamumas
• Adaptuojamumas (adaptability)
• Apibūdina galimybę perkelti sistemą į kitą
platformą, nedarant tos sistemos pakeitimų.
matų pavyzdžiai:
• pastangos, reikalingos pritaikyti sistemą kitai
platformai;
• platformų, į kurias galima kelti sistemą, nedarant
joje pakeitimų, skaičiaus santykis su platformų, į
kurias planuojama kelti sistemą, skaičiumi;
118
Reikalavimai
• Adaptuojamumas (tęsinys)
pavyzdžiai:
• operacinių sistemų, į kurias galima kelti sistemą, nedarant joje
pakeitimų, skaičiaus santykis su operacinių sistemų, į kurias
planuojama kelti sistemą, skaičiumi;
• DBVS, į kurias galima kelti sistemos duomenis, nedarant
sistemoje pakeitimų, skaičiaus santykis su DBVS, į kurias
planuojama kelti sistemos duomenis, skaičiumi;
• Sistemos naudojimo dokumentacijos, kurios nereikia keisti
perkėlus sistemą į kitą platformą, apimties (puslapiais)
santykis su visa sistemos naudojimo dokumentacijos apimtimi.
119
Reikalavimai
• Instaliuojamumas (installability)
• Apibūdina sistemai instaliuoti reikalingas
pastangas.
pavyzdžiai:
• žmogaus darbo valandos, reikalingos sistemai
instaliuoti;
• kiek sistemos parametrų (nuo bendro skaičiaus)
reikia keisti instaliavimo metu;
• kokią sistemos kodo dalį reikia keisti instaliavimo
metu;
• keliuose failuose (nuo bendro skaičiaus) reikia daryti
pakeitimus instaliavimo metu.
120
Reikalavimai
• Atitikimas standartams (conformance)
• Apibūdina sistemos atitikimą perkeliamumo
standartams ir susitarimams.
matų pavyzdžiai:
• sistemoje panaudotų perkeliamumo standartų bei
susitarimų skaičiaus santykis su visų perkeliamumo
standartų bei susitarimų skaičiumi.
121
Reikalavimai
• Pakeičiamumas (replaceability)
• Apibūdina pastangas, reikalingas pakeisti
sistema anksčiau naudotą kitą sistemą.
matų pavyzdžiai:
• keičiamų sistemos funkcijų procentas;
• keičiamos kodo dalies procentas.
122
Reikalavimai
• ISO 9126: panaudojamumas
• Panaudojamumas: pastangos, kurių reikia
vartotojams pasinaudoti sistema.
Suprantamumas Patrauklumas
Išmokstamumas Aiškumas
Operabilumas Informatyvumas
Būsenos vizualizavimas Patogumas vartotojui
Individualizuojamumas
123
Reikalavimai
• Suprantamumas (understandability)
• Pastangos, kurių vartotojui reikia sistemos
koncepcijai ir jos panaudojimo būdui perprasti.
pavyzdžiai:
• suprantamumo įvertis (rated understandability): vartotojų
duotas sistemos informacinio aprūpinimo (naudojimo
instrukcijos, help failai, užduočių formulavimo kalba ir jos
pateiktis vartotojo interfeise ir kt.) suprantamumo vertinimas;
• skaitomumo įvertis (readability score): produkto (dokumentai,
pranešimai, piktogramos ir kt.) skaitomumo vertinimas,
panaudojant Dale-Chall formulę;
• Ši formulė skaitomumą vertina pagal sakinių ilgį ir skaitytojui
nežinomų žodžių skaičių.
124
Reikalavimai
• Suprantamumas (tęsinys)
• koncepcinis aiškumas (concept clearness): kokį procentą sistemos
funkcijų galima paaiškinti per vartotojui įprastus sąvokas bei
terminus;
• kokio procento sistemos funkcijų veikimui aiškinti sistemoje yra
pateikta demonstracinė PĮ ;
• panaudojimo aiškumas (usage clearness): kokio procento sistemos
funkcijų panaudojimas sistemoje yra kaip nors (modeliais, demo,
aprašymais ar pan.) paaiškintas;
• kokiam procentui sistemos funkcijų yra pateikti jų pradinių duomenų
ir rezultatų aprašai;
• kokiam procentui funkcijų parametrų aiškiai nurodyta, ar jie yra
pastovūs, ar pakeičiami vykdant tas funkcijas.
125
Reikalavimai
• Išmokstamumas (learnability)
• Pastangos, kurių vartotojui reikia išmokti naudotis sistema
(užduočių formulavimas ir pateiktis, įvesties duomenys, rezultatų
interpretavimas ir pan.)
• vidutinis mokymosi laikas;
• vartotojo vadovų naudingumas: vidutinis pavyzdžių, paveikslėlių bei
kitos iliustracinės medžiagos vienetų skaičius vienai komandai;
• vartotojo vadovų prieinamumas: mokomosios medžiagos vienetų
skaičius vienai PS funkcijai;
• savarankiškam skaitymui skirtos įvadinės medžiagos vienetų skaičiaus
ir sistemos funkcijų santykis;
• esamos ir reikiamos mokomosios medžiagos apimčių santykis;
• esamų ir reikiamų help aprašų santykis;
126
Reikalavimai
• Išmokstamumas (tęsinys)
matų pavyzdžiai:
• procentas vartotojų nusiskundimų, pateiktų dėl to,
kad jie padarė klaidas dėl to, jog neteisingai suprato
tai, kas parašyta vartotojo vadovuose ar kitoje
sistemos dokumentacijoje;
• vidutinis laikas, sugaištas išmokti naudotis sistema
vienai verslo užduočiai vykdyti.
127
Reikalavimai
• Eksploatuojamumas (operability)
• Kiek vartotojo pastangų reikia dirbant su sistema.
pavyzdžiai:
• ekspertinis Eksploatuojamumas vertinimas;
• sistemos Eksploatuojamumo palyginimas su etaloniniu (dirbant
su kokia nors žinoma sistema);
• vartotojų duotas Eksploatuojamumo vertinimas;
• sumarinis laikas, reikalingas pradžioje parengti sistemą
naudojimui (instaliavimas, pritaikymas organizacijai ir pan.);
• kiek rankinių operacijų reikia atlikti instaliuojant sistemą;
128
Reikalavimai
• Eksploatuojamumas (tęsinys)
matų pavyzdžiai:
• sistemos instaliavimą palaikančių funkcijų ir visų
sistemai instaliuoti reikalingų operacijų santykis;
• taškų, kuriuose galima pertraukti sistemos
instaliavimo procesą, o po to jį vėl atnaujinti,
skaičius;
129
Reikalavimai
• kiek ir kokų kompiuterinių resursų (įskaitant TĮ ir PĮ) reikia sistemai
instaliuoti;
• per kelis žingsnius patikrinama, ar sistema instaliuota teisingai;
• koks yra sistemos komandų, turinčių nutylimus parametrus, ir visų
sistemos komandų santykis;
• kokį procentą sudaro komandos, turinčios standartizuotą
(suvienodintą) formatą;
• kokį procentą sudaro standartizuoti terminai (vartojami komandose,
pranešimuose ir t.t.);
• kokį procentą sudaro sistemos pranešimai, kuriuose aiškiai nurodyta
pranešimo priežastis ir vartotojui pasakytą, ką jis turi padaryti, gavęs
tą pranešimą;
130
Reikalavimai
pavyzdžiai:
• koks yra procentas sistemos funkcijų, naudojant kurias,
vartotojas gali pasirinkti jo patirtį atitinkantį darbo režimą;
• koks procentas ekraninių komandų yra suvienodintas;
• kokį procentą sudaro standartizuoti ekraniniai duomenų
įvesties/išvesties laukai;
• kiek veiksmų reikia atlikti, pradedant darbą su sistemas;
131
Reikalavimai
pavyzdžiai:
• užduočiai pakartoti reikalingų veiksmų ir pirmam tos užduoties
vykdymui reikalingų veiksmų (to paties seanso metu) santykis;
• vidutinis laikas tarp dviejų operatoriaus daromų klaidų;
• kiek laiko reikėtų gaišti dirbant su sistema, jei viskas būtų
maksimaliai patogu ir supaprastinta;
• kiek laiko reikia sugaišti darbui su sistema užbaigti;
• sistemos pateikiamų nurodymų santykis su skaičiumi
nurodymų, kuriuos ji turėtų pateikti (pagal reikalavimų
specifikaciją);
132
Reikalavimai
pavyzdžiai:
• kokį procentą sudaro komandos/duomenys, kurių galima
suklydus atsisakyti (cancel);
• kokį procentą (lyginant su reikalavimų specifikacija) sudaro
realizuoti dėmesio akcentai (spalvos, garsas, blykstelėjimai ir
kt.);
• minimalus, maksimalus ir vidutinis sistemos reakcijos į
vartotojo veiksmus laikas (response time for user);
• minimalus, maksimalus ir vidutinis laikas, per kurį pasikeičia
ekrane koks nors laukas, to paprašius (display time).
133
Reikalavimai
• Būsenos vizualizavimas (explicitness)
• Vertina sistemos gebėjimą informuoti apie tai, kas su ja vyksta
(atliekamų veiksmų progreso indikacija ir pan.).
• sistemos gebėjimo palaikyti kontaktą ekspertinis vertinimas;
• vidutinė laiko, kuriame vartotojas paliekamas nežinioje, trukmė
(insecure time);
• į kokį procentą iš visų galimų veiksmų sistema reaguoja tuoj pat
pranešdama apie savo būseną (status report ratio);
• po tam tikro sistemos naudojimo laiko vartotojų pranešama laiko,
kuriame jie paliekami nežinioje, trukmė (insecure time in practice);
• realizuotų progreso indikacijos ir specifikacija reikalautų realizuoti
progreso indikacijos atvejų santykis (status or progress report
availability ratio).
134
Reikalavimai
• Individualizuojamumas (customisability)
• Galimybės prisitaikyti sistemą savo individualiems
poreikiams.
pavyzdžiai:
• kokį procentą sistemos funkcionalumo galima
konfigūruoti (configurability ratio);
• vidutinis sistemos rekonfigūravimo laikas
(configurability effort).
135
Reikalavimai
• Patrauklumas (attractivity)
• Vertina, kokiu mastu sistemos teikiamos
paslaugos, jos elgsena bei jos naudojami
informacijos vizualizavimo bei pateikties būdai
tenkina išreikštiniu būdu nesuformuluotus
vartotojo pageidavimus, tai kam teikiama
pirmenybė bei nuostatas.
pavyzdžiai:
• vartotojų duodamas sistemos patrauklumo vertinimas.
136
Reikalavimai
• Aiškumas (clarity)
• Vertina, kokiu mastu vartotojui akivaizdu, ką
moka daryti sistema;
• koks procentas sistemos galimybių paaiškėja vartotojui
(neskaitant dokumentacijos, help failų ar kitos
medžiagos) paaiškėja vartotojui padirbėjus su ja tam
tikrą (pasirinktą vertinimui) laiką;
• kokį procentą sistemos galimybių naudoja vidutinis (ne
pradedantysis) vartotojas.
137
Reikalavimai
• Informatyvumas (helpfulness)
• Vertina, kokiu mastu vartotojams yra prieinama
informacinė medžiaga.
pavyzdžiai:
• vartotojui prieinamos (ekrane, įskaitant pranešimus)
informacinės medžiagos apimties (ženklais) ir ekrano
dydžio (ženklais) santykis (ratio of expounding text);
• vartotojui prieinamos (įskaitant pranešimus)
informacinės medžiagos apimties (žodžiais) ir visos
sistemos kodo apimties (kodo eilutėmis) santykis
(normalised ratio of expounding text).
138
Reikalavimai
• Patogumas vartotojui (user-
friendliness)
• Vertina vartotojo pasitenkinimą sistema. Reikalavimų
įgyvendinimui matuoti skirtų matų pavyzdžiai:
• koks procentas vartotojų praėjus tam tikram laikui
po sistemos diegimo mano, kad sistema palengvino
jų darbą (rated user-friendliness);
• ekspertinis patogumo vartotojui vertinimas;
• palyginimas su pasirinkta etalonine sistema (daro
ekspertai).
139
Reikalavimai
• ISO 9126: našumas
• Našumas (efficiency): programų sistemos
veikimo greičio ir, prie nurodytų sąlygų, jos
naudojamų resursų santykis.
Našumas pagal laiką Našumas pagal resursus

140
Reikalavimai
• Našumas pagal laiką (time behaviour)
• Apima sistemos reakcijos laiką, skaičiavimų trukmę ir jos
pralaidumą (gebėjimą per tam tikrą laiką apdoroti tam tikrą
įvykių skaičių).
• paketinio apdorojimo trukmė (batch turnaround time);
• maksimali paketinio apdorojimo apimtis (batch capacity)
• kokią didžiausią nuosekliai apdorojamų duomenų struktūrų (pvz. sąskaitų
faktūrų) seką geba apdoroti sistema;
• vidutinis ir maksimalus nurodyto tipo užduoties su nurodytomis
duomenų apimtimis vykdymo laikas (processing time);
• kiek nurodyto tipo užduočių su nurodytomis duomenų apimtimis gali
apdoroti sistema per nurodytą laiko tarpą(processing capacity);
141
Reikalavimai
• Našumas pagal laiką (tęsinys)
matų pavyzdžiai:
• vidutinis nurodyto tipo vidinės sistemos užduoties su
nurodytomis duomenų apimtimis vykdymo laikas (average
internal transaction time);
• maksimalus nurodyto tipo vidinės sistemos užduoties su
nurodytomis duomenų apimtimis vykdymo laikas (maximum
internal transaction time);
• visas skaičiavimų laikas, įskaitant užduoties formulavimą,
pradinių duomenų pateiktį ir rezultatų pateiktį (turnaround
time);
142
Reikalavimai
pavyzdžiai:
• laikas nuo užduoties formulavimo pabaigos iki rezultatų
pateikties pradžios (response time);
• laikas nuo programos vykdymo pradžios iki jos vykdymo
pabaigos (CPU elapsed time);
• kiek laiko procesoriaus darbo laiko sunaudoja programa nuo
jos vykdymo pradžios iki vykdymo pabaigos (CPU execution
time);
• kiek laiko sugaišta programa mainams tarp išorinės ir
operatyviosios atminčių (I/O processing time);
• laikas, kurį sistema sugaišta laukimui (pvz., spausdintuvo,
diskų ar pan.) (waiting time);
143
Reikalavimai
pavyzdžiai:
• laikas, gaištamas duomenims perduoti kompiuterių tinklu
(network processing time);
• laikas, kurį užduoties vykdymo metu skaičiavimams sunaudoja
kliento kompiuteris (terminal processing time);
• kiek nurodyto tipo įvykių (pvz., kreipinių iš skirtingų klientų)
geba apdoroti sistema per nurodytą laiką (throughput);
• kiek transakcijų geba apdoroti sistema per nurodytą laiką
(number of processed transactions).
144
Reikalavimai
• Našumas pagal resursus (resource
behaviour)
• Kiek resursų ir kiek laiko naudoja sistema
vykdydama savo funkcijas.
• kiek ženklų galima perduoti per nurodytą interfeisą, vykdant nurodytą
užduotį, per nurodytą laiką (communication occupancy);
• kiek operatyviosios atminties reikia sistemai nurodytoms duomenų
apimtims apdoroti (internal memory occupancy);
• kiek išorinės atminties reikia sistemai nurodytoms duomenų apimtims
apdoroti (external memory occupancy);
• kiek procesoriaus darbo laiko naudoja sistema (processor
occupancy);
145
Reikalavimai
• Našumas pagal resursus (tęsinys)
matų pavyzdžiai:
• kiek realiosios atminties užima programų sistema
(real memory occupancy);
• kiek virtualiosios atminties užima programų
sistema(virtual memory occupancy);
• (working set size);
146
Reikalavimai
pavyzdžiai:
• kiek atminties sistema naudoja savo failams talpinti (file
occupancy);
• kokias duomenų apimtis perdavinėja sistema kompiuterių
tinklu (network occupancy);
• kiek laiko per atitinkamą laiko vienetą sistema naudojasi
procesoriumi (CPU utilisation);
• kiek atminties per atitinkamą laiko vienetą naudoja sistema
(main memory utilisation);
įvesties/išvesties kanalais (I/O channel utilisation);
147
Reikalavimai
pavyzdžiai:
• kiek laiko per atitinkamą laiko vienetą sistema dirba su failais
(file utilisation);
kompiuterių tinklais (network utilisation);
įvesties/išvesties įrenginiais (I/O device utilisation);
kliento kompiuteriu (terminal utilisation).
148
Reikalavimai
• ISO 9126: prižiūrimumas
• Prižiūrimumas (maintainability): pastangos,
reikalingos sistemai perdaryti.
Analizuojamumas Testuojamumas
Keičiamumas Valdomumas
Stabilumas Tiražuojamumas
149
Reikalavimai
• Analizuojamumas (analysability)
• Pastangos, kurių reikia sistemos defektų ar
trykių priežastims nustatyti bei išsiaiškinti, kurią
sistemos dalį reikia keisti.
pavyzdžiai:
• trykių, kurių priežastys buvo nustatytos teisingai, ir
visų programoje esančių klaidų iššauktų trykių
santykis (fault position recognition ratio);
• vidutinis laikas, sugaištas sistemos trykį iššaukusioms
klaidoms rasti (mean failure analysis time).
150
Reikalavimai
• Keičiamumas (changeability)
• Pastangos, kurių reikia sistemai klaidai pašalinti ar
padaryti pakeitimus, pritaikant sistemą jos aplinkos
pokyčiams.
pavyzdžiai:
• vidutinio pakeitimui padaryti reikalingo laiko ir pakeitimo
apimties santykis (modification effort per unit volume);
• vidutinis laikas, reikalingas kokiam nors sistemos defektui
pašalinti (correction effort per defect);
• vidutinis laikas, reikalingas programoje esančiai klaidai ištaisyti
(mean fault correction time);
• kiek vidutiniškai laiko praeina nuo trykio įvykimo ir momento,
kada vartotojas vėl gali naudotis sistema (mean failure
treatment time);
151
Reikalavimai
• Keičiamumas (tęsinys)
pavyzdžiai:
• kiek programuotojo darbo valandų (vidutiniškai) reikia
programoje esančiai klaidai pašalinti (mean fault correction
work time);
• kiek laiko vidutiniškai yra gaištama (įskaitant išsiaiškinimo
laiką) vienai programos pataisymų kodo eilutei parašyti (mean
revise work time per changed line of source code);
• priežiūros inžinieriams skirtos dokumentacijos (puslapiais) ir
sistemos pradinio kodo apimties (kodo eilutėmis) santykis
(fulfilment degree of maintenance document).
152
Reikalavimai
• Stabilumas (stability)
• Pakeitimų iššaukiamų netikėtų efektų rizika.
matų pavyzdžiai:
• vidutinio pakeitimą darant padarytų klaidų ir
pakeitimo apimties santykis.
153
Reikalavimai
• Testuojamumas (testability)
• Pastangos, kurių reikia sistemos korektiškumui
(pradžioje ar padarius pakeitimus) patikrinti.
pavyzdžiai:
• pastangos, kurių reikia nurodytos kodo apimties korektiškumui
(naudojant nurodytą testų skaičių) patikrinti (test effort per
unit volume);
• kiek vidutiniškai laiko turi sugaišti vartotojas patikrinti, ar
teisingai buvo pataisyta klaida (mean user’s work time to
verify the fault correction);
• kiek vidutiniškai laiko turi sugaišti programuotojas patikrinti, ar
teisingai buvo pataisyta klaida (mean work time to test the
fault correction).
154
Reikalavimai
• Valdomumas (manageability)
• Pastangos, kurių reikia padaryti sistemą
veikiančia ar jos veikimui atkurti.
matų pavyzdžiai:
• žmogaus darbo valandomis matuojamų pastangų
(įskaitant priežiūros darbus), reikalingų padaryti
sistemą veikiančia ar jos veikimui atkurti, santykis
su valandomis, kuriomis vartotojas gali naudotis
sistema (control effort ratio);
• matuojama per pasirinktą laiko intervalą.
155
Reikalavimai
• Tiražuojamumas (reusability)
• Vertina, kokiu mastu sistemą ar jos dalis
galima pakartotinai pasinaudoti kituose
projektuose.
matų pavyzdžiai:
• pakartotinai panaudojamų sistemos dalių ir visų jos
dalių santykis (ratio reusable parts);
• pakartotinai panaudotų sistemos dalių ir visų jos
dalių santykis (ratio reused parts).
156
Reikalavimai
• Anotuoti reikalavimai
• Reikalavimai anotuojami, norint pateikti
sistemą kuriančiai organizacijai tam tikras
rekomendacijas.
• Reikalavimo statusas:
• E – esminis (privalomas) reikalavimas;
• D – pageidavimas (desirable requirement);
• O – papildomas (optional) reikalavimas.
157
Reikalavimai
• Reikalavimo statusas
• Esminiais vadinami tie reikalavimai, kurių neįgyvendinus
negali būti patenkinti operaciniai vartotojų poreikiai.
• Neįgyvendinus tokių reikalavimų, užsakovui sistema tampa bevertė ir
jis tokios sistemos nepriims.
• Pageidavimais vadinami reikalavimai, kuriuos įgyvendinus
vartotojo darbas palengvėja ar supaprastėja, tačiau be
kurių iš principo galima ir apseiti.
• Užsakovas gali priimti sistemą ir neįgyvendinus kai kurių
pageidavimų. Ji bus tinkama tik galbūt mažiau patogi.
• Papildomais vadinami reikalavimai, reikalingi papildomiems
vartotojų operaciniams reikalavimams tenkinti.
• Paprastai tokie reikalavimai yra įgyvendinami už papildomą mokestį.
158
Reikalavimai
• Reikalavimo statusas
• Vykdytojai gali sugaišti labai daug laiko kokiam nors
reikalavimui įgyvendinti ir tik po to sužinoti, kad
vartotojui daug svarbiau laiku gauti sistemą
netenkinančią šio reikalavimo, negu dviem
mėnesiais vėliau gauti sistemą, kuri tą reikalavimą
jau tenkina.
• Nurodžius reikalavimų statusus, tokių situacijų
galima išvengti.
159
Reikalavimai
• Reikalavimų galiojimo laikas:
• S – pastovus (stable) reikalavimas, t.y. niekad
nekeičiamas reikalavimas;
• U – sąlyginai pastovus (unstable) reikalavimas, t.y. toks
reikalavimas, kurio keitimo tikėtinumas nelygus nuliui;
• T – laikinas (temporal) reikalavimas, t.y. tik laikinai (pvz.,
kol galutinai bus pereita nuo anksčiau naudotos sistemos
prie naujos sistemos) reikalingas reikalavimas.
• Reikalavimo galiojimo laikas padeda įvertinti, kokios tą
reikalavimą realizuojančio kodo savybės (galimybė
lengvai keisti, našumas ar kt.) yra svarbesnės.
160
Reikalavimai
• Kritiškumo laipsnis:
• S – sunkios pasekmės;
• A – apysunkės pasekmės;
• L – lengvos pasekmės.
• Reikalavimo kritiškumo laipsnį nusako jo pažeidimo
pasekmės. Jos gali būti sunkios, apysunkės arba
lengvos. Pasekmių sunkumo laipsnis nustatomas pagal
materialinės arba kitokios galimos žalos dydį.
• Pavyzdžiui, sistemos trykis yra kritinis lėktuvą valdančiai
sistemai ir mažai kritinis darbo užmokesčio skaičiavimo sistemai.
Kita vertus, rezultatų tikslumas yra kritinis darbo užmokesčio
skaičiavimo sistemai ir mažiau kritinės lėktuvą valdančiai
sistemai.
161
Reikalavimai
RNr. Statusas Galiojimo laikas Kritiškumo
(E, D, O) (S, U, T) laipsnis (S, A, L)
Reikalavimo tekstas
•Reikalavimo statusas: E – esminis (privalomas)

reikalavimas; D – pageidavimas (requirement); O – papildomas
reikalavimas.
•Reikalavimų galiojimo laikas: S – pastovus (stable)
reikalavimas; U – sąlyginai pastovus (unstable) reikalavimas; T
– laikinas (temporal) reikalavimas.
•Kritiškumo laipsnis: S – sunkios pasekmės; A – apysunkės
pasekmės; L – lengvos pasekmės.
162
Reikalavimai
• Reikalavimų specifikacija
• Reikalavimų specifikacija – tai oficialus, juridinę
galią turintis dokumentas, nustatantis kokį
produktą privalo sukurti vykdytojas.
• Dokumentas gali apimti ir vartotojo reikalavimus
(t.y. operacinius poreikius), ir sistemos
reikalavimus.
• Šis dokumentas NĖRA projektinis dokumentas.
Jame aprašoma KĄ sistema turi daryti, bet ne tai,
KAIP tai turi būti realizuota.
163
Reikalavimai
• Kam yra naudojama reikalavimų
specifikacija.
Reikalavimų specifikacija
užsakovas projekto vadovas projektuotojas testuotojas
konkursui baigtai projektui sistemai testams

organizuoti sistemai vertinti planuoti projektuoti specifikuoti
164
Reikalavimai
• Gerai parašytos reikalavimų specifikacijos
savybės
• Visų pirma reikalavimų specifikacija yra gerai
parašyta, jeigu ji tenkina projektuotojų
poreikius.
• Tai reiškia, kad dokumento savybes lemia tikslai,
kuriems jis yra naudojamas.
• Vienų savybių reikia tam, kad dokumentą būtų patogu
skaityti, kitų tam, kad būtų nesunku patikrinti, ar
projektuotojai tikrai įgyvendino visus reikalavimus, dar
kitų tam, kad dokumentą būtų nesunku keisti.
165
Reikalavimai
savybės
• Nėra kokio nors visuotinai pripažinto reikalavimų
specifikacijos formato standarto, tačiau yra įprasta
numeruoti visus reikalavimus:
3.5.1 Adding nodes to a design
3.5.1.1 The editor shall provide a facility for users to add nodes
of a specified type to their design.
3.5.1.2 The sequence of actions to add a node should be as follows:
1. The user should select the type of node to be added.
2. The user should move the cursor to the approximate node position
in the diagram and indicate that the node symbol should be
added at that point.
3. The user should then drag the node symbol to its final position.
Rationale: The user is the best person to decide where to position a
166
Reikalavimai
savybės
• Konceptualumas (appropriateness):
reikalavimų specifikacija yra konceptuali, jei visi
joje pateikti reikalavimai yra abstraktūs, t.y. joje
nėra liečiami sistemos projektavimo ar
įgyvendinimo klausimai.
• Nekonceptuali specifikacija per daug suvaržytų
projektuotojus ir programuotojus, trukdytų jiems
parinkti geriausią sistemos įgyvendinimo būdą.
• Kita vertus, dažnai yra labai sunku išvengti kai kurių
projektavimo ar realizavimo ribojimų.
167
Reikalavimai
savybės
• Koncepcinė skaidra: apima specifikacijos
paprastumą, aiškumą ir suprantamumą. Ši
savybė siejasi su specifikacijos konceptualumu.
• Jei reikalavimai saugomi duomenų bazėje ir tvarkomi
programiškai, koncepcinė skaidra dažniausiai yra
paaukojama siekiant padidinti reikalavimų apdorojimo
našumą.
168
Reikalavimai
savybės
• Konkretumas (constructability): specifikacija
yra konkreti, jei gali būti patikrintas visų joje
suformuluotų reikalavimų įgyvendinimo laipsnis.
• Tai labai svarbi specifikacijos savybė, nes šis
dokumentas yra užsakovo ir vykdytojo sandorio dalis
ir jos pagrindu yra sprendžiama ar sandoris buvo
įvykdytas.
169
Reikalavimai
savybės
• Geras struktūrizavimas: joje griežtai
išlaikytas turinių atskyrimo principas.
• Tikslumas: visi joje suformuluoti reikalavimai
yra tikslūs.
• Tai labai svarbi specifikacijos savybė, nes šis
dokumentas yra užsakovo ir vykdytojo sandorio dalis
ir jos pagrindu yra sprendžiama ar sandoris buvo
įvykdytas.
170
Reikalavimai
savybės
• Išsamumas: specifikacijoje aprašytas visas
reikalingas sistemos funkcionalumas ir visi
joje pateikti reikalavimai yra išsamūs.
• Tai reiškia, kad specifikacijoje yra viskas, kas joje
turėtų būti.
• Patikrinti, ar specifikacija tikrai yra išsami, yra labai
sunku.
• Nagrinėjant tai, kas yra aprašyta, labai sunku pastebėti,
ko gi ten trūksta.
• Geriausias būdas išsamumui patikrinti yra sukurti
sistemos prototipą.
171
Reikalavimai
savybės
• Išsamumas
• Išsamioje specifikacijoje turi būti aprašyta,
kaip sistema reaguoja į kiekvieną iš galimų
įvesties tipų kiekvienoje galimoje situacijoje.
• Reikia nagrinėti ne tik kaip reaguoja sistema į
leistinas (teisingas) įvestis, bet ir kaip ji reaguoja į
klaidingas įvestis.
172
Reikalavimai
• Gerai parašytos reikalavimų specifikacijos savybės
• Išsamumas (tęsinys)
• Išsamioje specifikacijoje turi būti visos
reikalaujamos to dokumento dalys, visi
puslapiai, visi paveikslėliai ir visos lentelės turi
būti sunumeruoti, paveikslėliai ir lentelės turi
turėti pavadinimus, turi būti pateiktos
tvarkingos nuorodos į visus naudojamus
išorinius informacijos šaltinius.
• Tai formalus dokumento išsamumas, kurį galima vadinti ir
dokumento tvarkingumu.
• Kokias dalis turi turėti dokumentas, nustato vidiniai
organizacijos (arba projekto) standartai.
173
Reikalavimai
• Išsamumas (tęsinys)
• Kartais analizės metu visų reikalavimų specifikuoti
nepavyksta, kai kurių reikalavimų specifikavimą tenka
atidėti vėlesniam laikui. Tokie reikalavimai pažymimi
žyme AVL.
• Išsamioje specifikacijoje kiekvienam AVL žyme pažymėtam
reikalavimui turi būti nurodyta:
• kodėl reikalavimo formulavimas yra atidėtas;
• kas turi būti atlikta, kad reikalavimą būtų galima
suformuluoti;
• iki kada reikalavimas turi būti suformuluotas;
• kas atsakingas už tai, kad reikalavimas būtų suformuluotas
nurodytu laiku.
174
Reikalavimai
• Vienareikšmiškumas: joje neturi būti jokių
dviprasmybių.
• Tai labai svarbi specifikacijos savybė, nes šis dokumentas yra
užsakovo ir vykdytojo sandorio dalis ir jos pagrindu yra
sprendžiama ar sandoris buvo įvykdytas.
• Trasuojamumas: reikalavimai yra
lokalizuojami ir reikalavimų ir projektinę
specifikacijas galima tarpusavyje susieti
kryžminėmis nuorodomis.
• Jei visi reikalavimai yra sunumeruoti, į juos galima daryti
nuorodas.
175
Reikalavimai
savybės
• Darna: visi joje suformuluoti reikalavimai yra
integruojami, jokių prieštaravimų dokumente nėra.
• Nedarna gali atsirasti dėl įvairių priežasčių, pavyzdžiui,
dėl:
• terminų konflikto: skirtingose dokumento vietose tas pats daiktas
yra vadinamas skirtingai;
• savybių konflikto: skirtinguose reikalavimuose yra reikalaujama,
kad sistema turėtų kokias nors nesuderinamas savybes;
• naudojimo režimų konflikto: pavyzdžiui, vienoje vietoje
reikalaujama, kad su sistema būtų dirbama dialogo režimu, kitoje,
kad ji būtų sistema, veikianti paketinio duomenų apdorojimo
režimu.
176
Reikalavimai
savybės
• Keičiamumas: dokumentas turi būti
lengvai keičiamas.
• Specifikaciją lengva keisti, jei ji parašyta griežtai
prisilaikant turinių atskyrimo principo ir visi
reikalavimai turi unikalius numerius.
• Naudojimo patogumas: mažai kas skaito
visą dokumentą, kiekvienam reikia tik to,
kas jam svarbu. Todėl dokumentas turi būti
parašytas taip, kad juo būtų galima
naudotis kaip žinynu.
177
Reikalavimai
• Reikalavimų specifikacija pateikiama varžovams
besivaržantiems konkurse dėl projekto.
• Tinkamai organizuotas konkursas padeda užsakovui pasirinkti
vykdytoją, kuris reikalavimus įgyvendins pigiausiai.
• Kad konkurse galėtų dalyvauti kuo daugiau
pretendentų, reikalavimai turi būti suformuluoti kuo
bendriau.
• Kita vertus, reikalavimai turi būti pakankamai konkretūs, kad
konkurse negalėtų dalyvauti pretendentai, siūlantys sukurti ne
tai, ko iš tiesų reikia užsakovui.
• Idealiu atveju, reikalavimai turėtų būti suformuluoti taip, kad visi
galimi pasiūlymai būtų suskirstyti į dvi dalis: tuos, kurie tenkina
vartotojų poreikius, ir tuos, kurie tų poreikių netenkina.
178
Reikalavimai
• “Reikalavimai yra didelis dalykas. Aš juos
rašau visą gyvenimą. Ten aš sudedu viską apie
tai, ką turėtų daryti programų sistema: kokias
verslo taisykles ji turi tenkinti, ką turi daryti
vartotojo interfeisas, paspaudus tą ar kitą
klavišą, kokias užduotis vartotojas norės
vykdyti ir taip toliau, ir taip toliau. Čia tikrai
yra apie ką pagalvoti.”
• Kevin Brennan
179
Reikalavimai
• “Kartais ko nors pritrūksta. Kartais nieko netrūksta,
bet vykdytojai klaidingai supranta mano mintį. Aš
susidūriau su daugybe situacijų, kurios yra visiškai
akivaizdžios verslo žmonėms, bet praranda savo
akivaizdumą arba dėl jų perpasakojimo kitais
terminais, arba dėl to, kad nors ir nesunku įsivaizduoti
tokias situacijas realizuojančias juodąsias dėžes, labai
sunku realizuoti pačias tokias juodąsias dėžes. Ir visa
tai vyksta nepaisant to, kad mes visi dirbame kartu jau
daugiau kaip metai, sėdimi tame pačiame pastate ir
daugelis iš mūsų jau ištisus dešimtmečius dirba tokį
darbą.”
• Kevin Brennan
180
Reikalavimai
• “Rasti ir pataisyti klaidą sistemoje testavimo
metu, o juo labiau po to, kai ji pradėta
eksploatuoti, kainuoja dešimt kartų daugiau,
negu ją rasti ir pataisyti reikalavimuose ar
projektinėje sistemos specifikacijoje. Blogai
valdomame projekte klaidoms surasti ir
pataisyti jūs galite sugaišti daugiau laiko, negu
jo buvo sugaišta sistemai sukurti.”
• Kevin Brennan
181
Reikalavimai
• Technologinis reikalavimų inžinerijos
procesas
Poreikių
analizė
Aiškinimasis
ir analizė
Specifikavimas
Vertinimas
Dokumentavimas
Prototipai
182
Reikalavimų pavyzdžiai
Greitosios pagalbos dispečerinės PS
183
184
185
186
187
Klausimai?
188
Klausimai
1. Kas vadinama reikalavimu? (1)
2. Kas vadinama reikalavimų formulavimu? (1)
3. Kokias reikalavimų rūšis jūs žinote? Jas trumpai apibūdinkite. (1)
4. Kas ir kokiais tikslais skaito reikalavimus? (2)
5. Dėl kokių priežasčių verta formuluoti reikalavimus? (2)
6. Kokios yra gerai suformuluoto reikalavimo savybės? (1)
7. Koks reikalavimas vadinamas abstrakčiu? (1)
8. Koks reikalavimas vadinamas išsamiu? (1)
9. Koks reikalavimas vadinamas tiksliu? (1)
10. Koks reikalavimas vadinamas vienareikšmiu? (1)
189
Klausimai
11. Koks reikalavimas vadinamas verifikuojamu? (1)
12. Koks reikalavimas vadinamas įgyvendinamu? (1)
13. Koks reikalavimas vadinamas integruojamu? (1)
14. Koks reikalavimas vadinamas lokalizuojamu? (1)
15. Koks reikalavimas vadinamas trasuojamu? (1)
16. Koks reikalavimas vadinamas unikaliu? (1)
17. Koks reikalavimas vadinamas glaustu? (1)
18. Koks reikalavimas vadinamas suprantamu? (1)
19. Paaiškinkite funkcinių ir nefunkcinių reikalavimų skirtumus. (2)
20. Paaiškinkite sistemos pagrindinio funkcionalumo ir jos pagalbinio
funkcionalumo skirtumus. (2)
190
Klausimai
21. Kaip nustatyti, kokius funkcinius reikalavimus turi tenkinti sistema? (3)
22. Kokią informaciją reikia pateikti, aprašant funkcinį reikalavimą? (2)
23. Kokia programų sistema vadinama korektiška? Kada ji praranda savo korektiškumą? (1)
24. Kokias ribojimų grupes apima nefunkciniai reikalavimai? Apibūdinkite jas trumpai. (3)
25. Kokius programų sistemos aspektus riboja interfeiso ribojimai? Kas įvyksta juos pažeidus?
(2)
26. Kokias reikalavimų grupes apima interfeiso reikalavimai? (1)
27. Kokias reikalavimų grupes apima vartotojo interfeiso reikalavimai? (1)
28. Kas tai yra užduočių formulavimo kalbos semantinė galia? Kokiais reikalavimais ji
nusakoma? (2)
29. Nuo ko priklauso užduočių formulavimo kalbos procedūriškumo laipsnis? Kokiais
reikalavimais jis nusakoma? (4)
30. Kas tai yra užduočių formulavimo kalbos dalykinė orientacija? Kas vadinama
metafora? (4)
191
Klausimai
31. Kas tai yra užduočių formulavimo kalbos selektyvinė geba? Kokiais
reikalavimais ji nusakoma? (2)
32. Kas tai yra užduočių formulavimo kalbos raiškos geba (išsamumas)? (2)
33. Ką apibūdina užduočių formulavimo kalbos sintaksiniai reikalavimai? (2)
34. Kas tai yra užduoties pateikties protokolas? (2)
35. Apibūdinkite programų sistemos naudojimo paprastumo reikalavimus. (3)
36. Apibūdinkite programų sistemos patogumo vartotojui reikalavimus. (2)
37. Apibūdinkite programų sistemos ergonominius reikalavimus. (1)
38. Kokius programų sistemos aspektus riboja veikimo ribojimai? Kas atsitinka juos
pažeidus? (2)
39. Kokias reikalavimų grupes apima veikimo ribojimai? (1)
40. Apibūdinkite, kas tai yra programų sistemos tikslumo reikalavimai. (2)
192
Klausimai
41. Apibūdinkite, kas tai yra programų sistemos patikimumo reikalavimai. (2)
42. Apibūdinkite, kas tai yra programų sistemos gyvybingumo reikalavimai. (1)
43. Apibūdinkite, kas tai yra programų sistemos robastiškumo reikalavimai. (1)
44. Apibūdinkite, kas tai yra programų sistemos našumo reikalavimai. (4)
45. Kokius programų sistemos aspektus riboja ekonominiai ribojimai? Kas atsitinka
juos pažeidus? (2)
46. Kokios reikalavimų grupės išplaukia iš ekonominių ribojimų? (1)
47. Apibūdinkite, kas tai yra programų sistemos diegimo reikalavimai. (4)
48. Apibūdinkite, kas tai yra programų sistemos aptarnaujamumo reikalavimai. (2)
49. Apibūdinkite, kas tai yra programų sistemos prižiūrimumo reikalavimai. (3)
50. Apibūdinkite, kas tai yra programų sistemos tiražuojamumo reikalavimai. (1)
193
Klausimai
51. Kokius programų sistemos aspektus riboja politiniai ribojimai? Kas atsitinka
juos pažeidus? (2)
52. Apibūdinkite, kas tai yra programų sistemos apsaugos reikalavimai? (3)
53. Kokius programų sistemos aspektus riboja teisiniai ribojimai? (1)
54. Ką reglamentuoja ISO 9126 standartas? Kaip jis susijęs su reikalavimų
formulavimu ir jų įgyvendinimo vertinimu?(4)
55. Kokie reikalavimai vadinami anotuotais? (2)
56. Kas tai yra reikalavimų specifikacija? Kokios yra gerai parašytos reikalavimų
specifikacijos savybės? Apibūdinkite jas trumpai. (5)

PSI 7 Reikalavimu Inzinerija 20150309 v01

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PSI 7 Reikalavimu Inzinerija 20150309 v01

Uploaded by

Copyright:

Available Formats

PROGRAMŲ SISTEMŲ

Skaidrės ruoštos remianti prof. A.Čaplinsko ir

Doc. dr. Diana Kalibatienė

• Vartojo ir sistemos reikalavimai yra

Operacinių poreikių ir reikalavimų

Sistemos viduje esantys duomenys specifikuojami

ISO 9126 (Quint)

Atsparumas trykiams Pažeidžiamumas

Našumas pagal laiką Našumas pagal resursus

•Reikalavimo statusas: E – esminis (privalomas)

užsakovas projekto vadovas projektuotojas testuotojas

konkursui baigtai projektui sistemai testams

You might also like