Reikalavimai programinei Ä¯rangai

Programų sistemų inžinerija 

Reikalavimai programinei įrangai 

Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 1 

Tikslai 

• Supažindinti su vartotojo ir sistemos reikalavimų 

sąvoka 

• Aprašyti funkcinius ir nefunkcinius reikalavimus 

• Išsiaiškinti, kaip programinės įrangos 

reikalavimai gali būti aprašomi reikalavimų 

specifikacijos dokumentuose 

Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 2

Nagrinėjamos temos 

• Funkciniai ir nefunkciniai reikalavimai 

• Vartotojo reikalavimai 

• Sistemos reikalavimai 

• Sąsajos specifikavimas 

• PĮ reikalavimų specifikacija 


Reikalavimų inžinerija 

• Tai procesas, kurio metu nustatoma, kokias 

paslaugas turės atlikti kuriama programinė 

įranga bei su kokiais apribojimais sistemai 

susidursime kūrimo metu 

• Patys reikalavimai - tai sistemos paslaugų ir 

apribojimų aprašymai, kurie sugeneruojami 

reikalavimų inžinerijos proceso metu 


Kas yra reikalavimas? 

• Tai gali būti nuo labai abstrakčių teiginių iki 

detalizuotų matematinių funkcijų. 

• Tai neišvengiama, nes reikalavimai gali atlikti 

dvigubą funkciją 

– gali būti kaip pagrindas pasiūlymui ( konkursui) – 

todėl turi būti atviras interpretacijai 

– gali būti pagrindas ir pačiai užsakymo sutarčiai – 

taigi tai turi būti aprašyta gana smulkiai 

– abu tokie teiginiai gali būti pavadinti reikalavimais 


• Vartotojo reikalavimai 

Reikalavimų tipai 

– Paprasta (ne technine) kalba surašyti vartotojo 

pageidavimai būsimai sistemai, gali būti pridedamos 

laisvos formos diagramos, parašyta taip, kad 

suprastų bet kuris sistemos vartotojas 

• Sistemos reikalavimai 

– Struktūrizuotas dokumentas, išdėstantis detalius 

sistemos funkcijų, paslaugų ir operacijų aprašymus. 

Nusako, kas turi būti padaryta ir gali būti naudojamas 

kaip kontrakto dalis 


Apibrėžimai ir specifikacijos 

Vartotojo reikalavimų apibrėžimas 

Programinė įranga turi leisti atvaizduoti ir apdoroti išorinius failus, 

sukurtus 1. kitomis programomis 

Sistemos reikalavimų specifikacija 

1.1 

1.1 Vartotojai turi turėti galimybę apibrėžti išorinių failų tipą. 

1.2 Kiekvienas išorinis failo tipas turi turėti susijusias priemones, kurias 

galima būtų panaudotos failui apdoroti. 

1.3 1.2 Kiekvienas išorinių failų tipas gali būti pristatytas kaip specifinė 

ikona. 

1.4 1.2Vartotojas turi turėti galimybę apibrėžti ikonų atvaizdavimą 

kiekvienam išorinio failo tipui 

1.2 

1.2 

1.2 


Reikalavimų skaitytojai 

Vartotojo 

reikalavimai 

Kliento vadybininkai 

Sistemos galutiniai vartotojai 

Kliento inžinieriai 

Kūrėjų vadybininkai 

Sistemos architektai 

Sistemos 

reikalavimai 

Galutiniai sistemos vartotojai 

Kliento inžinieriai 


Programinės įrangos tobulintojai(vystytojai) 

Programinės įrangos 

projektavimo 

specifikacijos 

Galimi kliento inžinieriai 


Programinės įrangos tobulintojai(vystytojai) 


Funkciniai ir nefunkciniai reikalavimai 

• Funkciniai reikalavimai 

– Sistemos atleikamų paslaugų aprašymas, sistemos reakcijos į 

tam tikrus įvedimo ar išvedimo duomenis aprašymas, sistemos 

elgesys tam tikroje situacijoje... 

• Nefunkciniai reikalavimai 

– Apribojimai sistemos atliekamoms paslaugoms ar funkcijoms, 

dažniausiai laiko apribojimai, programavimo proceso 

apribojimai, standartai ir pan. 

• Srities reikalavimai 

– Reikalavimai, ateinantys iš konkrečios nagrinėjamos srities ir 

atspindintys tik tai sričiai būdingas problemas ar 

charakteristikas 


Funkciniai reikalavimai 

• Nusako sistemos funkcionalumą ar sistemos 

paslaugas 

• Priklauso nuo kuriamos PĮ tipo, būsimų vartotojų 

ar srities, kur sistema bus naudojama 

• Funkciniai vartotojo reikalavimai gali būti aukšto 

lygio teiginiai, apie tai, ką sistema turi daryti, bet 

funkciniai sistemos reikalavimai turi detaliai 

aprašyti sistemos paslaugas. 


Bibliotekos sistema LIBSYS 

• Sistema, kuria naudojantis galima prieiti prie tam 

tikro skaičiaus straipsnius talpinančių duomenų 

bazių kitose bibliotekose 

• Vartotojai gali atlikti straipsnių paiešką, išsaugoti 

rastus straipsnius bei spausdinti juos 

asmeniniam naudojimui 


Funkcinių reikalavimų pavyzdžiai 

• Vartotojas privalo turėti galimybę paiešką atlikti 

tiek visoje duomenų bazėje, tiek pasirinktame jos 

poaibyje 

• Sistema turi aprūpinti vartotojus tinkamomis 

straipsnių peržiūros priemonėmis (viewers), kad 

jie galėtų skaityti dokumentus tiesiai iš straipsnių 

saugyklos/duomenų bazės 

• Kiekvienam užsakymui turi būti priskirtas 

unikalus užsakymo numeris (ORDER_ID), kurį 

vartotojas galėtų išsaugoti savo užsakymų 

istorijoje 


Reikalavimų netikslumai 

• Jei reikalavimai suformuluoti netiksliai, 

neišvengiamai turėsime problemų 

• Netiksliai apibrėžtus reikalavimus programuotojai 

ir vartotojai supras skirtingai 

• Pvz, ką reiškia “atitinkama straipsnių peržiūros 

priemonė” 

– Vartotojo pozicija – kiekvienam dokumento tipui 

pritaikyta atitnkama peržiūros programa (.pdf, .doc) 

– Programuotojo pozicija – tekstinis peržiūros režimas( 

nes taip greičiau ir lengviau) 


Reikalavimų pilnumas ir 

suderinamumas 

• Reikalavimai turi būti ir pilni, ir suderinti. 

• Pilni 

– Jie turi pilnai aprašyti visas reikalingas sistemos 

funkcijas 

• Suderinti 

– Neturėtų būti vienas kitam prieštaraujančių sistemos 

reikalavimų reikalavimų 

• Praktikoje yra sunku pateikti ir pilną, ir suderintą 

reikalavimų dokumentą. 


Nefunkciniai reikalavimai 

• Šie reikalavimai apibrėžia sistemos savybes 

(pvz. patikimumą, atsakymo į užklausą laiką, 

reikalavimus atminčiai) ir apribojimus (pvz. 

įvedimo/ išvedimo įrenginio galimybes) 

• Proceso reikalavimai gali būti specifikuoti 

reikalaujant naudoti specialią CASE sistemą, 

programavimo kalbą ar projektavimo metodą. 

• Nefunkciniai reikalavimai gali būti svarbesni už 

funkcinius reikalavimus. Jei jie nėra tenkinami, 

sistema gali būti bevertė 


Nefunkcinių reikalavimų klasifikacija 

• Produkto reikalavimai 

– Reikalavimai, kurie apibrėžia, kad pateiktas 

produktas privalo elgtis specifiniu būdu, pvz. 

vykdymo greitis ir patikimumas ir pan. 

• Organizaciniai reikalavimai 

– Reikalavimai, kurie yra organizacinės politikos ir 

procedūrų padariniai, pvz. panaudoti procesų 

standartai, įdiegimo reikalavimai ir pan. 

• Išoriniai reikalavimai 

– Reikalavimai, atsirandantys iš išorinių sistemos 

faktorių, pvz sistemos suderinamumo reikalavimai, 

teisiniai reikalavimai ir pan. 


Nefunkcinių reikalavimų tipai 

Nefunkciniai 

reikalavimai 

Produkto 

reikalavimai 

Organizaciniai 

reikalavimai 

Išoriniai 

reikalavimai 

Efektyvumo 

reikalavimai 

Patikimumo 

reikalavimai 

Pernešamumo 

reikalavimai 

Darbingumo 

reikalavimai 

Etiniai 

reikalavimai 

Panaudojamumo 

reikalavimai 

Pristymo 

reikalavimai 

Kūrimo 

reikalavimai 

Standartai 

Teisiniai 

reikalavimai 

Reikalavimai 

veikimo greičiui 

Apimties 

reikalavimai 

Privatumo 

reikalavimai 

Saugumo 

reikalavimai 


Nefunkcinių reikalavimų pavyzdžiai 

• Produkto reikalavimai 

– 4.C.8 visus būtinus ryšius tarp APSE ir vartotojo bus įmanoma 

išreikšti standartiniu Ada simbolių rinkiniu. 

• Organizaciniai reikalavimai 

– 9.3.2 Sistemos kūrimo procesas bei rezultate gauti dokumentai turi 

tenkinti standarto XYZCo-SP-STAN-95 reikalavimus. 

• Išoriniai reikalavimai 

– 7.6.5 Sistema neturi atskleisti sistemos operatoriams jokios 

asmeninės informacijos apie vartotojus, išskyrus jų vardą ir 

kreipimosi numerį. 


Tikslai ir reikalavimai 

• Nefunkcinius reikalavimus sunku tiksliai suformuluoti, o 

netiksliai suformuluotus reikalavimus sunku patikrinti 

• Tikslas 

– Bendras vartotojo pageidavimas, pvz. lengvai įsisavinama 

programa 

• Nefunkcinio reikalavimo tikrinimas 

– Būtina suformuluoti aiškų matavimą, leisiantį patikrinti, ar 

reikalavimas įvykdytas 

• Tokie tikslai yra labai naudingi sistemos kūrėjams, nes 

galima suprasti, ko iš sistemos tikisi galutiniai vartotojai 


• Sistemos tikslas 

Pavyzdžiai 

– Sistema turi būti lengvai įsisavinama patyrusių 

vartotojų ir turi būti suprojektuota taip, kad dirbdami 

vartotojai padarytų kaip galima mažiau klaidų 

• Nefunkcinio reikalavimo patikrinimas 

– Patyrę vartotojai privalo gebėti naudotis visomis 

sistemos funkcijomis po max. dviejų valandų 

mokymų. Išklausius mokymus, vidutinis tokių 

vartotojų leistinas klaidų sakičius per dieną neturi 

viršyti dviejų klaidų 


Reikalavimų matavimai 

Greitis 

Dydis 

Naudojimo lengvumas 

Patikimumas 

Operacijos atlikimo greitis sekundėmis, ekrano 

persipiešimo greitis, per kiek laiko sureaguojama į 

vartotojo veiksmą 

Baitai 

RAM mikroshemų skaičius 

Mokymų laikas 

Kiek laiko dirba nenulūždama, lūžimų dažnis, 

išsaugotų po lūžimo duomenų kiekis ar atsatymo 

greitis 

Patvarumas 

Pernešamumas 

Per kiek laiko persikrauna po lūžimo, kiek procentų 

veiksmų iššaukia lūžimą, tikimybė prarasti duomenis 

Koks kiekis programos kodo tinka pakartotiniam 

naudojimui, keliose sistemose galima panaudoti kodą 


Reikalavimų sąveika 

• Konfliktai tarp skirtingų nefunkcinių reikalavimų 

sudėtingose sistemose pasitaiko dažnai 

• Lėktuvo valdymo programa 

– Siekiant sumažinti svorį, atskirų mikroschemų 

skaičius sistemoje turi būti minimalus. 

– Siekiant sumažinti energijos vartojimą, turi būti 

panaudotos mažesnės galios mikroschemos. 

– Tačiau naudojant mažesnio galingumo 

mikroschemas, jų gali prireikti daugiau... Kuris 

reikalavimas yra svarbesnis? 


Srities reikalavimai 

• Gauti iš sistemos taikymo srities bei nusako tą 

konkrečią sritį atspindinčias charakteristikas. 

• Tai gali būti nauji funkciniai reikalavimai, 

egzistuojančių reikalavimų apribojimai arba 

apibrėžti specifiniai skaičiavimai. 

• Jei srities reikalavimai netenkinami, sistema 

nedirbs. 


Bibliotekos sistemos srities reikalavimai 

• Visos duomenų bazės turi būti prieinamos 

naudojantis standartine vartotojo sąsaja, 

aprašyta Z39.50 standarte. 

• Dėl autorinių teisių apribojimų kai kurie 

dokumentai turi būti sunaikinami iš karto po jų 

peržiūros. Priklausomai nuo vartotojo teisių, šitie 

dokumentai arba bus spausdinami bibliotekoje ir 

po to atiduodami vartotojui, arba nukreipiami į 

vartotojo nurodytą tinklo spausdintuvą. 


Srities reikalavimų problemos 

• Suprantamumas (Understandability) 

– Reikalavimai yra išreikšti srities taikymo kalba. 

– Tokių reikalavimų nesupranta programinę įrangą 

kuriantys projektuotojai 

• Neabejotinumas (Implicitness) 

– Srities specialistai situacijoje gaudosi taip gerai, kad 

jie nė negalvoja apie tikslių srities reikalavimų 

sudarymą. 


Vartotojo reikalavimai 

• Turi aprašyti funkcinius ir nefunkcinius 

reikalavimus taip, kad juos suprastų detalių 

techninių žinių neturintys sistemos vartotojai. 

• Vartotojo reikalavimai yra apibrėžiami naudojant 

natūralią kalbą, lenteles ir diagramas. 


Natūralios kalbos naudojimo problemos 

• Aiškumo trūkumas 

– Jei norime, kad būtų lengva skaityti, tai nebus 

aiškumo, jei norime aiškumo, tada teks pridėti 

papildomų detalių ir skaityti lengva jau nebus... 

• Reikalavimų painiava 

– Aiškiai neatskiriami funkciniai ir nefunkciniai 

reikalavimai 

• Reikalavimų apjungimas 

– Keli skirtingi reikalavimai gali būti pateikti kaip vienas 


LIBSYS vartotojo reikalavimas 

4..5 LIBSYS turi pateikti visų vartotjo atliktų mokėjimo 

operacijų sąrašą. Sistemos administratoriai gali suderinti 

sistemą taip, kad vartotojas gautų nuolaidas teikiamoms 

paslaugoms. 


LIBSYS vartotojo reikalavimo problema 

• Reikalavimas apima tiek koncepcinę, tiek detalią 

informaciją: 

– Aprašo dalį finansų apskaitos sistemos, kuri bus prijungta prie 

LIBSYS; 

– Tuo pačiu pateikia tokios sistemos detales – bus galima gauti 

nuolaidas 


Patarimai reikalavimų rašymui 

• Susirasti šabloną ir jį naudoti visų reikalavimų 

užrašymui (Volere). 

• Naudoti kalbą tinkamu būdu, pvz. žodis “turi” 

privalomiems reikalavimams, “ turėtų” 

pageidaujamiems reikalavimams. 

• Naudoti teksto paryškinimą reikalavimų esminių 

dalių identifikavimui. 

• Vengti kompiuterinio žargono. 


Sistemos reikalavimai 

• Tai daug detalesnis sistemos funkcioanlumo bei 

apribojimų aprašymas, negu vartotojų 

reikalavimai 

• Tarnauja kaip pagrindas kuriant sistemą. 

• Gali būti įtraukiami į sistemos kontraktą. 

• Sistemos reikalavimai gali būti išreiškiami ar 

papildomi sistemos modeliais 


Reikalavimai ir projektavimas 

• Reikalavimai turi nurodyti, ką sistema turi daryti, o 

projektavimo dokumentas nusakyti, kaip tai turi būti 

daroma. 

• Praktikoje reikalavimai ir projektavimas yra neatskiriami: 

– Sistemos architektūra gali būti suprojektuota tam, kad 

patikslintų reikalavimus. 

– Sistema gali dirbti su kitomis sistemomis, kurios generuoja 

projekto reikalavimus. 

– Specialaus dizaino parinkimas gali būti srities reikalavimas. 


Problemos dėl specifikacijų, parašytų 

natūralia kalba 

• Dviprasmiškumas 

– Reikalavimų skaitytojai ir autoriai tą patį žodį turi 

interpretuoti taip pat. Natūrali kalba yra 

nevienareikšmė, todėl tą pasiekti yra labai sunku. 

• Per didelis lankstumas 

– Tas pats dalykas specifikacijoje gali būti pasakytas 

keliais skirtingais būdais. 

• Struktūrizavimo trūkumas 

– Natūrali kalba netinka sistemos reikalavimų 

struktūrizavimui. 


Struktūrizuotos kalbos specifikacijos 

• Reikalavimų analitiko “žodžio laisvė” yra iš 

anksto apribota tam tikru šablonu 

• Visi reikalavimai užrašomi tuo pačiu stiliumi 

• Naudojami tie patys terminai (terminų žodynas) 

• Tai panaikina kai kurias problemas, atsiradusias 

dėl nevienareikšmiškumo, ir suteikia 

specifikacijai vienodą stilių 


Formomis paremtos specifikacijos 

• Funkcijos ar objekto apibrėžimas 

• Įvedimo duomenų aprašymas, iš kur jie ateina 

• Rezultatų aprašymas ir kur jie nueina 

• Kitų reikalingų objektų atpažinimas 

• Pradinės ir galutinės sąlygos (jei reikia) 

• Pašaliniai efektai (jei yra) 


Formomis paremtos specifikacijos pvz. 

Insulin Pump/Control Software/SRS/3.3.2 

Function Compute insulin dose: Safe sugar level 

Description Computes the dose of insulin to be delivered when the current measured sugar level is in 

the safe zone between 3 and 7 units. 

Inputs Current sugar reading (r2), the previous two readings (r0 and r1) 

Source Current sugar reading from sensor. Other readings from memory. 

Outputs CompDose Š the dose in insulin to be delivered 

Destination 

Main control loop 

Action: CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of 

increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is 

computed by dividing the difference between the current sugar level and the previous level by 4 and 

rounding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that can 

be delivered. 

Requires 

Pre-condition 

Post-condition 

Side-effects None 

Two previous readings so that the rate of change of sugar level can be computed. 

The insulin reservoir contains at least the maximum allowed single dose of insulin.. 

r0 is replaced by r1 then r1 is replaced by r2 


Lentelės formos specifikacija 

• Papildo natūralią kalbą 

• Naudinga tada, kai yra daug alternatyvių variantų 


Lentelės formos specifikacija 

Condition 

Action 

Sugar level falling (r2 < r1) CompDose = 0 

Sugar level stable (r2 = r1) CompDose = 0 

Sugar level increasing and rate of 

increase decreasing ((r2-r1)

Grafinis modelis 

• Naudingas tada, kai reikia parodyti būsenos 

pasikeitimus ar veiksmų sekas 

• Bus daugiau ☺ 


Sekos diagramos 

• Parodo įvykių sekas, kurios atsiras vartotojui 

dirbant su sistema 

• Skaitomos iš viršaus į apačią tam, kad nustatyti, 

kokia tvarka turi būti atliekami veiksmai. 

• Pinigų išėmimas iš bankomato: 

– Kortelės identifikavimas; 

– Užklausos pateikimas; 

– Operacijos užbaigimas. 


Sekos diagrama pinigų išėmimui iš 

automato 


Sąsajos specifikacija 

• Dauguma sistemų sąveikauja su kitomis 

sistemomis, todėl sąsaja turi būti specifikuojama 

kaip reikalavimų dalis. 

• Yra trys sąsajų tipai 

– Procedūrinė sąsaja; 

– Duomenų struktūros, kuriomis keičiasi programos; 

– Duomenų vaizdavimas. 

• Formalios specifikacijos labiausiai tinka sąsajos 

specifikavimui. 


Procedūrinės sąsajos pavyzdys 

interface PrintServer { 

// defines an abstract printer server 

// requires: interface Printer, interface PrintDoc 

// provides: initialize, print, displayPrintQueue, cancelPrintJob, switchPrinter 

void initialize ( Printer p ) ; 

void print ( Printer p, PrintDoc d ) ; 

void displayPrintQueue ( Printer p ) ; 

void cancelPrintJob (Printer p, PrintDoc d) ; 

void switchPrinter (Printer p1, Printer p2, PrintDoc d) ; 

} //PrintServer 


Reikalavimų specifikacijos dokumentas 

• Reikalavimų specifikacija yra oficialus 

dokumentas, ko reikalaujama iš sistemos kūrėjų. 

• Į ją turi būti įtraukiami ir vartotojo reikalavimai, ir 

sistemos specifikacija 

• Tai ne projektavimo dokumentas. Jis akcentuoja 

KĄ sistema turi padaryti, o ne KAIP ji turi 

padaryti. 


Reikalavimų specifikacijos dokumento 

naudotojai 

Sistemos 

klientai 

Nustato reikalavimus ir skaito juos tam, kad 

patikrintų, ar jie atitinka jų poreikius. Jie 

nustato reikalavimų pakeitimus. 

Vadybininkai 

Naudoja reikalavimų dokumentą tam, kad 

suplanuotų sistemos kainą ir suplanuotų 

sistemos kūrimo procesą. 

Sistemos 

projektuotojai 

Naudoja reikalavimus tam, kad suprastų , 

kaip projektuoti sistemą. 

Sistemos testo 

projektuotojai 

Naudoja reikalavimus tam, kad sukurtų 

sistemai atestavimo testą. 

Sistemų 

palaikymo 

inžinieriai 

Naudoja reikalavimus, kad padėtų suprasti 

sistemą ir santykius tarp jos dalių. 


Reikalavimų specifikacijos dokumentas 

• Turi nustatyti išorinį sistemos elgesį. 

• Turi nustatyti realizavimo apribojimus. 

• Turi būti lengvai keičiamas. 

• Turi būti atskaitos taškas programinės įrangos 

palaikymui. 

• Vertinti sistemos gyvavimo ciklą, tai yra nuspėti 

pakeitimus. 

• Charakterizuoti atsakymus į netikėtus įvykius 


IEEE reikalavimų standartas 

• Nusako bendrą reikalavimų specifikacijos 

struktūrą: 

– Įvadas. 

– Bendras aprašymas. 

– Specifiniai reikalavimai. 

– Priedai. 

– Indeksų lentelės. 


Reikalavimų specifikacijos dokumento 

struktūra 

• Priešistorė 

• Įvadas 

• Santrauka 

• Vartotojo reikalavimų apibrėžimas 

• Sistemos architektūra 

• Sistemos reikalavimų specifikacija 

• Sistemos modeliai 

• Sistemos palaikymas 

• Priedai 

• Indeksų lentelės 


Esminiai aspektai 

• Reikalavimai išdėsto, ką sistema turi daryti, ir 

apibrėžia jos vykdymo ir realizavimo apribojimus. 

• Funkciniai reikalavimai išdėsto paslaugas, kurias 

turi užtikrinti sistema. 

• Nefunkciniai reikalavimai apriboja kuriamą 

sistemą arba kūrimo procesą. 

• Vartotojo reikalavimai yra aukšto abstrakcijos 

lygio sakiniai, ką sistema turi daryti. 


Esminiai aspektai 

• Vartotojo reikalavimai turi būti parašyti natūralia 

kalba, lentelėmis ir diagramomis. 

• Sistemos reikalavimai skirti funkcijoms, kurias 

sistema turi vykdyti. 

• Yra specialūs šablonai ir standartai

Reikalavimai programinei Ä¯rangai

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?