Program ų sistem ų inžinerija Reikalavimai programinei įrangai
Transcript of Program ų sistem ų inžinerija Reikalavimai programinei įrangai
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 1
Programų sistemų inžinerija
Reikalavimai programinei įrangai
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 2
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ė 3
Nagrinėjamos temos
• Funkciniai ir nefunkciniai reikalavimai
• Vartotojo reikalavimai
• Sistemos reikalavimai
• Sąsajos specifikavimas
• PĮ reikalavimų specifikacija
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 4
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 5
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 6
Reikalavimų tipai• Vartotojo reikalavimai
– 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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 7
Apibrėžimai ir specifikacijos
1.
Programinė įranga turi leisti atvaizduoti ir apdoroti išorinius failus, sukurtus kitomis programomis
1.2
1.2
1.2
1.2
1.21.2
Vartotojo reikalavimų apibrėžimas
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 Kiekvienas išorinių failų tipas gali būti pristatytas kaip specifinė ikona.1.4 Vartotojas turi turėti galimybę apibrėžti ikonų atvaizdavimą kiekvienam išorinio failo tipui
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 8
Reikalavimų skaitytojai
Programinės įrangos projektavimo specifikacijos
Vartotojo reikalavimai
Kliento vadybininkai
Sistemos galutiniai vartotojai
Kliento inžinieriai
Kūrėjų vadybininkai
Sistemos architektai
Sistemos reikalavimai
Galutiniai sistemos vartotojai
Kliento inžinieriai
Sistemos architektai
Programinės įrangos tobulintojai(vystytojai)
Galimi kliento inžinieriai
Sistemos architektai
Programinės įrangos tobulintojai(vystytojai)
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 9
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 10
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 11
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 12
Funkcinių reikalavimų pavyzdžiai• Vartotojas privalo turėti galimybę paiešką atlikti
tiek visoje duomenų bazėje, tiek pasirinktame jospoaibyje
• Sistema turi aprūpinti vartotojus tinkamomisstraipsnių peržiūros priemonėmis (viewers), kadjie galėtų skaityti dokumentus tiesiai iš straipsniųsaugyklos/duomenų bazės
• Kiekvienam užsakymui turi būti priskirtasunikalus užsakymo numeris (ORDER_ID), kurįvartotojas galėtų išsaugoti savo užsakymųistorijoje
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 13
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)
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 14
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ą.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 15
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ė
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 16
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 17
Nefunkcinių reikalavimų tipai
Reikalavimai veikimo greičiui
Apimties reikalavimai
Panaudojamumo reikalavimai
Efektyvumo reikalavimai
Patikimumo reikalavimai
Pernešamumo reikalavimai
Darbingumo reikalavimai
Etiniai reikalavimai
Teisiniai reikalavimai
Kūrimo reikalavimai
StandartaiPristymo reikalavimai
Saugumo reikalavimai
Privatumo reikalavimai
Produkto reikalavimai
Organizaciniai reikalavimai
Išoriniai reikalavimai
Nefunkciniai reikalavimai
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 18
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į.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 19
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 20
Pavyzdžiai
• Sistemos tikslas
– Sistema turi būti lengvai įsisavinama patyrusiųvartotojų ir turi būti suprojektuota taip, kad dirbdamivartotojai padarytų kaip galima mažiau klaidų
• Nefunkcinio reikalavimo patikrinimas
– Patyrę vartotojai privalo gebėti naudotis visomissistemos funkcijomis po max. dviejų valandųmokymų. Išklausius mokymus, vidutinis tokiųvartotojų leistinas klaidų sakičius per dieną neturiviršyti dviejų klaidų
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 21
Reikalavimų matavimai
Operacijos atlikimo greitis sekundėmis, ekrano persipiešimo greitis, per kiek laiko sureaguojama į vartotojo veiksmą
BaitaiRAM mikroshemų skaičius
Mokymų laikas
Kiek laiko dirba nenulūždama, lūžimų dažnis, išsaugotų po lūžimo duomenų kiekis ar atsatymo greitis
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ą
Greitis
Dydis
Naudojimo lengvumas
Patikimumas
Patvarumas
Pernešamumas
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 22
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ūtipanaudotos mažesnės galios mikroschemos.
– Tačiau naudojant mažesnio galingumomikroschemas, jų gali prireikti daugiau... Kuris reikalavimas yra svarbesnis?
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 23
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 arbaapibrėžti specifiniai skaičiavimai.
• Jei srities reikalavimai netenkinami, sistemanedirbs.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 24
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ą.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 25
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ą.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 26
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 27
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 28
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 29
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 30
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 31
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 32
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 33
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 34
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ų
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 35
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)
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 36
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 inthe 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 ofincrease is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose iscomputed by dividing the difference between the current sugar level and the previous level by 4 androunding the result. If the result, is rounded to zero then CompDose is set to the minimum dose that canbe delivered.
Requires Two previous readings so that the rate of change of sugar level can be computed.
Pre-condition The insulin reservoir contains at least the maximum allowed single dose of insulin..
Post-condition r0 is replaced by r1 then r1 is replaced by r2
Side-effects None
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 37
Lentelės formos specifikacija
• Papildo natūralią kalbą
• Naudinga tada, kai yra daug alternatyvių variantų
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 38
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 ofincrease decreasing ((r2-r1)<(r1-r0))
CompDose = 0
Sugar level increasing and rate ofincrease stable or increasing. ((r2-r1) �(r1-r0))
CompDose = round ((r2-r1)/4)If rounded result = 0 thenCompDose = MinimumDose
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 39
Grafinis modelis
• Naudingas tada, kai reikia parodyti būsenos pasikeitimus ar veiksmų sekas
• Bus daugiau ☺
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 40
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 41
Sekos diagrama pinigų išėmimui iš automato
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 42
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 43
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 44
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 45
Reikalavimų specifikacijos dokumento naudotojai
Sistemos klientai
Nustato reikalavimus ir skaito juos tam, kad patikrintų, ar jie atitinka jų poreikius. Jie nustato reikalavimų pakeitimus.
VadybininkaiNaudoja 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ų.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 46
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 47
IEEE reikalavimų standartas
• Nusako bendrą reikalavimų specifikacijos struktūrą:
– Įvadas.
– Bendras aprašymas.
– Specifiniai reikalavimai.
– Priedai.
– Indeksų lentelės.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 48
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
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 49
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.
Pagal ©Ian Sommerville 2006 Software Engineering, 8th edition. Skaidrė 50
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