reikalavimai programinei įrangai
DESCRIPTION
Reikalavimai programinei įrangai . Sistemos aprašymai ir specifikacijos. Įžanga. (Tikslai. temos, kas yra reikalavimas, abstrakcija, tipai, apibrėžimai ir specifikacijos, reikalavimų skaitytojai). Tikslai. Supažindinti su vartotojo ir sistemos reikalavimų sąvoka - PowerPoint PPT PresentationTRANSCRIPT
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1
Reikalavimai programinei įrangai
Sistemos aprašymai ir specifikacijos
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 2
Įžanga (Tikslai. temos, kas yra reikalavimas, abstrakcija,
tipai, apibrėžimai ir specifikacijos, reikalavimų skaitytojai)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 3
Tikslai• Supažindinti su vartotojo ir sistemos reikalavimų
sąvoka• Aprašyti funkcinius ir nefunkcinius reikalavimus• Paaiškinti du metodus sistemos reikalavimų
aprašymui• Paaiškinti kaip programinės įrangos reikalavimai
gali būti organizuoti reikalavimų dokumentuose
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 4
Aptariamos temos• Funkciniai ir nefunkciniai reikalavimai• Vartotojo reikalavimai• Sistemos reikalavimai• Programinės įrangos reikalavimų dokumentas
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 5
Reikalavimų inžinerija• Tai procesas paslaugų, kurių vartotojas
reikalauja iš sistemos ir apribojimų, pagal kuriuos sistema dirba ir yra kuriama, nustatymui
• Patys reikalavimai tai sistemos paslaugų ir apribojimų aprašymai, kurie sugeneruojami reikalavimų inžinerijos proceso metu
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 6
Kas tai yra reikalavimas? Tai gali būti nuo labai abstrakčių teiginių iki
detalizuotų matematinių funkcijų. Tai neišvengiama, nes reikalavimai gali atlikti
dvigubą funkciją• tai gali būti kaip pagrindas pasiūlymui ( konkursui) – todėl turi
būti atviras interpretacijai• tai 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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 7
Reikalavimų abstrakcija (Davis)“Jei kompanija nori sudaryti sutartį dideliam programinės įrangos projektui, ji turi pateikti savo poreikius pakankamai abstrakčiu būdu, kad sprendimas nebūtų iš anksto apibrėžtas.Poreikiai turėtų būti nurodyti dar prieš sutarties sudarymą. Reikalavimai turi būti parašyti taip, kad keli rangovai galėtų vykdyti sutartį, duoti pasiūlymus, kad galėtų siūlyti skirtingais būdai išpildyti užsakovo poreikius. Kai kontrakto laimėtojas jau nustatytas, rangovas turi tiksliai ir smulkiai aprašyti sistemą tam, kad klientai suprastų ką programinė įranga darys. Abu šie dokumentai vadinami reikalavimų dokumentais.”
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 8
Reikalavimų tipai Vartotojo reikalavimai
• Natūralios kalbos teiginiai plius paslaugų, kurias teikia sistema ir vykdymo apribojimai. Tai parašyta užsakovams.
Sistemos reikalavimai• Struktūrizuotas dokumentas išdėstantis detalius sistemos
paslaugų aprašymus. Parašytas kaip kontraktas tarp kliento ir rangovo.
Programinės įrangos specifikacija• Tai detalus programinės įrangos aprašymas, kuris tarnauja
kaip pagrindas projektavimui ir realizacijai. Tai parašyta projektuotojams.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 9
Apibrėžimai ir specifikacijosReikalavimų apibrėžimas ( Labai bendras reikalvimų aprašymas)•Programinė įranga turi leisti atvaizduoti ir apdoroti išorinius failus,• sukurtus kitomis priemonėmis.Reikalavimų specifikacija ( Detalesnis reikalavimų aprašymas)•Vartotojai turi turėti galimybę apibrėžti išorinių failų tipą.•Kiekvienas išorinis failo tipas turi turėti susijusias priemones, kurias •galima būtų panaudotos failui apdoroti.•Kiekvienas išorinių failų tipas gali būti pristatytas kaip specifinė ikona •vartotojo displėjuje.•Vartotojas turi turėti galimybę apibrėžti ikonų atvaizdavimą kiekvienam išorinio• failo tipui•Kai vartotojas pasirenka ikoną, atvaizduojančią išorinį failą, šio •pasirinkimo pasekoje failas apdorojamas įrankiais susietais su išorinį •failą vaizduojančia ikona.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 10
Reikalavimų skaitytojai
Programinės įrangos projektavimo specifikacijos
Vartotojo reikalavimai
Kliento vadybininkaiSistemos galutiniai vartotojai
Kliento inžinieriaiKūrėjų vadybininkaiSistemos architektai
Sistemos reikalavimai
Sistemos galutiniai vartotojaiKliento inžinieriai
Sistemos architektaiPrograminės įrangos tobulintojai(vystytojai)
Galimi kliento inžinieriaiSistemos architektai
Programinės įrangos tobulintojai(vystytojai)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 11
Aptariamos temos• Funkciniai ir nefunkciniai reikalavimai (funkcinių
reikalavimų pavyzdžiai, netikslumai, suderinamumas, nefunkcinių reikalavimų klasifikavimas, pavyzdžiai, tikslas ir reikalavimai, reikalavimų matavimai, sąveika, srities reikalavimai, problemos)
• Vartotojo reikalavimai• Sistemos reikalavimai• Programinės įrangos reikalavimų dokumentas
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 12
Funkciniai ir nefunkciniai reikalavimai
Funkciniai reikalavimai• Sistemos paslaugų aprašymai dar turėtų paaiškinti, kaip
sistema turėtų reaguoti į ypatingus duomenų įvedimus ir kaip sistema elgsis ypatingose situacijose.
Nefunkciniai reikalavimai• Sistemos paslaugų arba funkcijų apribojimai, tokie kaip laiko
apribojimai, kūrimo proceso apribojimai, standartai, ir pan.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 13
Funkciniai reikalavimai• Aprašo funkcionalumą arba sistemos paslaugas• Priklauso nuo programinės įrangos tipo, laukiamų
vartotojų ir sistemos tipo, kur programinė įranga yra 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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 14
Funkcinių reikalavimų pavyzdžiai• Vartotojas turi turėti galimybę ieškoti arba visus
pradinius duomenų bazės rinkinius, arba išsirinkti poaibį iš jų.
• Sistema turi aprūpinti vartotojus tinkamomis peržiūros priemonėmis, kad jie galėtų skaityti iš saugyklos.
• Kiekvienam užsakymui turi būti paskirtas unikalus identifikatorius, kuriuos vartotojas galėtų kopijuoti į pastovų saugojimo lauką.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 15
Reikalavimų netikslumai Problemos atsiranda, kai reikalavimai nėra tiksliai
nusakyti. Nevienareikšmiai reikalavimai gali būti skirtingai
interpretuojami kūrėjo ir vartotojo. Apibrėžkime terminą “tinkamomis peržiūros
priemonėmis”• Vartotojo ketinimai – speciali peržiūros priemonė kiekvienam
skirtingam dokumento tipui.• Projektuotojo interpretacija – aprūpinti teksto peržiūros
priemonėmis, kurios parodo dokumento sudedamąsias dalis.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 16
Reikalavimų pilnumas ir suderinamumas
Praktiškai, reikalavimai turi būti ir pilni, ir suderinti.
Pilni• Juose turi būti visi aprašymai apie visas reikalaujamas
galimybes Suderinti
• Neturėtų būti konfliktų ir prieštaravimų sistemos galimybių aprašymuose
Praktikoje yra svarbu pateikti pilną ir suderintą reikalavimų dokumentą.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 17
Nefunkciniai reikalavimai• Apibrėžti sistemos sistemos savybes ir
apribojimus kaip pvz. patikimumą, atsakymo laiką ir reikalavimus atminčiai. Apribojimai yra įvedimo/ išvedimo įrenginio galimybės ir pan.
• Reikalavimai procesui gali būti specifikuoti naudojant specialią CASE sistemą, programavimo kalbą ar projektavimo metodą.
• Nefunkciniai reikalavimai gali būti labiau svarbūs nei funkciniai reikalavimai. Jei jie nėra išpildomi, sistema yra nenaudinga.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 18
Nefunkcinių reikalavimų klasifikavimas
Reikalavimai produktui• 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 kaip pvz. panaudoti procesų standartai, įdiegimo reikalavimai ir pan.
Išoriniai reikalavimai• Reikalavimai, atsirandantys iš faktorių, kurie yra išoriniai
sistemai ir jos kūrimo procesui kaip sistemos suderinamumo reikalavimai, teisiniai reikalavimai ir pan.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 19
Nefunkcinių reikalavimų tipaiNefunkciniai reikalavimai
Produkto reikalavimai
Efektyvumo reikalavimai
Organizaciniai reikalavimai
Išoriniai reikalavimai
Patikimumo reikalavimai
Mobilumo reikalavimai
Naudojimo reikalavimai
Našumo reikalavimai
Erdvės reikalavimai
Pristatymo reikalavimai
Įdiegimo reikalavimai
Prisiderinamumo reikalavimai
Etikos reikalavimai
Standartų reikalavimai
Teisiniai reikalavimai
Saugos reikalavimai
Privatumo reikalavimai
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 20
Nefunkcinių reikalavimų pavyzdžiai Produkto reikalavimas
• 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 ir persiunčiamieji dokumentai atitiks procesą
ir persiunčiamuosius dokumentus apibrėžtus XYZCo-SP-STAN-95 standartu. Išoriniai reikalavimai
• 7.6.5 Sistema neturi atskleisti sistemos operatoriams jokios asmeninės informacijos apie vartotojus, išskyrus jų vardą ir kreipimosi numerį.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 21
Tikslai ir reikalavimai Nefunkcinius reikalavimus gali būti labai sudėtinga
nustatyti tiksliai ir netikslius reikalavimus gali būti labai sunku patikrinti.
Tikslas• Pagrindiniai vartotojo ketinimai tokie kaip vartojimo
lengvumas. Patikrinami nefunkciniai reikalavimai.
• Teiginiai naudojantys tam tikrus matavimus, kurie gali būti objektyviai išbandyti.
Tikslai, naudingi kūrėjams, nes jie perduoda sistemos vartotojų ketinimus.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 22
Pavyzdžiai Sistemos tikslas
• Sistema turi būti lengvai naudojama patyrusių operatorių ir turi būti organizuota taip, kad vartotojo klaidos būtų minimizuotos.
Patikrinami nefunkciniai reikalavimai• Patyrę operatoriai turėtų sugebėti naudoti visas sistemos
funkcijas po dviejų apmokymo valandų. Po tokio apmokymo vidutinis patyrusių vartotojų padarytų klaidų skaičius neturi viršyti dviejų per dieną.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 23
Reikalavimų matavimai
Processed transactions/secondUser/Event response timeScreen refresh timeK BytesNumber of RAM chipsTraining timeNumber of help framesMean time to failureProbability of unavailability
Rate of failure occurrenceAvailabilityTime to restart after failurePercentage of events causing failureProbability of data corruption on failurePercentage of target dependent statementsNumber of target systems
SavybėSavybėss MatavimMatavimaiai
Greitis
Dydis
Naudojimo lengvumas
Patikimumas
Patvarumas
Pernešamumas
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 24
Reikalavimų sąveika Konfliktai tarp skirtingų nefunkcinių reikalavimų
yra bendri sudėtingose sistemose. Kosminio laivo sistema
• Minimizuojant apimtį, atskirų mikroschemų skaičius sistemoje turi minimizuotas.
• Minimizuojant galios suvartojimą, turi būti panaudotos mažesnės galios mikroschemos.
• Tačiau naudojant mažesnio galingumo mikroschemas, jų gali būti panaudota daugiau. Kuris reikalavimas yra labiausiai kritiškas?
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 25
Srities reikalavimai Gauti iš taikymo srities ir nusako sistemos
charakteristikas ir sritį atspindinčius bruožus. Tai gali būti nauji funkciniai reikalavimai,
egzistuojančių reikalavimų apribojimai arba apibrėžti specifiniai skaičiavimai.
Jei srities reikalavimai nepatenkinami, sistema nedirbs.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 26
Bibliotekinės sistemos srities reikalavimai
Turi būti standartinė sąsaja su vartotoju visoms duomenų bazėms, paremta Z39.50 standartu.
Dėl autorinių teisių apribojimų kai kurie dokumentai turi būti iš karto sunaikinti. Priklausomai nuo vartotojo reikalavimų šitie dokumentai bus atspausdinti vietoje, po to persiunčiant vartotojui arba nukreipti į tinklo spausdintuvą.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 27
Srities reikalavimų problemos Suprantamumas (Understandability)
• Reikalavimai yra išreikšti taikymo srities kalboje.• Tai dažnai nesupranta programinės įrangos projektuotojai
projektuojant sistemą. Neabejotinumas (Implicitness)
• Srities specialistai situacijoje gaudosi taip gerai, kad jie nė negalvoja apie tikslių srities reikalavimų sudarymą.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 28
Aptariamos temos Funkciniai ir nefunkciniai reikalavimai Vartotojo reikalavimai (problemos dėl natūralios
kalbos, patarimai reikalavimų rašymui) Sistemos reikalavimai Programinės įrangos reikalavimų dokumentas
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 29
Vartotojo reikalavimai Turi aprašyti funkcinius ir nefunkcinius
reikalavimus taip, kad jie būtų suprantami sistemos vartotojų, kurie neturi detalių techninių žinių.
Vartotojo reikalavimai yra apibrėžti, naudojant natūralią kalbą, lenteles ir diagramas.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 30
Problemos su natūralia kalba Aiškumo trūkumas
• Sunku pasiekti tikslumą, nedarant taip, kad dokumentą būtų sunku skaityti.
Reikalavimų painiava (confusion)• Funkciniai ir nefunkciniai reikalavimai turi tendenciją
susimaišyti. Reikalavimų susijungimas (amalgamation)
• Keletas skirtingų reikalavimų gali būti išreikšti kartu.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 31
Patarimai reikalavimų rašymui Pasiūlyti standartinį formatą ir naudoti jį visiems
reikalavimams. Naudoti kalbą tinkamu būdu. Naudoti “turi”
priverstiniams reikalavimams, “ turėtų” pageidaujamiems reikalavimams.
Naudoti teksto paryškinimą tam, kad pabrėžti esmines reikalavimų dalis.
Vengti kompiuterinių žargonų naudojimo.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 32
Aptariamos temos Funkciniai ir nefunkciniai reikalavimai Vartotojo reikalavimai Sistemos reikalavimai (reikalavimai ir projektas,
problemos, alternatyvos natūralios kalbos specifikacijoms, forma pagrįstas specifikavimas, PDL naudojimas, trūkumai, sąsajos specifikavimas)
Programinės įrangos reikalavimų dokumentas
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 33
Sistemos reikalavimai Tai vartotojų reikalavimų detalesnės
specifikacijos. Tarnauja kaip bazė, kuriant sistemą. Gali būti naudojama kaip dalis sistemos
kontrakto. Sistemos reikalavimai gali būti išreikšti,
naudojant sistemos modelius, modeliavimą.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 34
Reikalavimai ir projektas Iš principo reikalavimai turi skelbti ką sistema
turi daryti, o projektas turi apibūdinti, kaip tai padaryti.
Praktiškai, reikalavimai ir projektas yra neatskiriami.
• Sistemos architektūra gali būti suprojektuota tam, kad struktūrizuotu reikalavimus.
• Sistema gali dirbti su kitomis sistemomis, kurios generuoja projekto reikalavimus.
• Specialaus projektavimo naudojimas gali būti srities reikalavimas.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 35
Problemos dėl specifikacijų natūralia kalba
Dviprasmiškumas• Reikalavimų skaitytojai ir autoriai tą patį žodį turi interpretuoti
taip pat. Natūrali kalba yra nevienareikšmė, taigi tai pasiekti yra labai sunku.
Per didelis lankstumas• Tas pats dalykas gali būti pasakytas specifikacijoje daugeliu
skirtingų būdų. Moduliarizacijos trūkumas
• Natūrali kalba netinka struktūrizuoti sistemos reikalavimus.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 36
Alternatyvos natūralios kalbos specifikacijoms
Įvardinimas Aprašymas
Struktūrizuota natūrali kalba Šis priėjimas priklauso nuo apibrėžtų standartinių formų ar šablonų tam, kad išreikšti specifikacijos reikalavimus.
Projekto aprašymo kalba Šis metodas naudoja kalbą, panašią į programavimo kalbą, bet su abstraktesnėmis savybėmis tam, kad aprašant sistemos operacinį modelį, išskirtų reikalavimus.
Grafiniai pažymėjimai Grafinė kalba, papildyta teksto anotacijomis yra naudojama sistemos funkcinių reikalavimų apibrėžimui. Ankstyvasis tokios grafinės kalbos pavyzdys yra SADT. Dar anksčiau buvo naudojamas naudojimo atvejo aprašymai. Aptarsime tai kituose skyriuose.
Matematinės specifikacijosTai yra pažymėjimai, paremti matematinėmis sąvokomis, tokiomis kaip baigtiniai automatai ar aibės. Šios vienareikšmės specifikacijos sumažina ginčus tarp klientų ir vykdytojų dėl sistemos funkcionavimo. Kaip bebūtų dauguma klientų nesupranta formalios specifikacijos ir atsisako priimti tai kaip sistemos kontraktą. Formalią specifikaciją
aptarsime 9 skyriuje.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 37
Struktūrizuotos kalbos specifikacijos
Natūralios kalbos ribota forma gali būti naudojama reikalavimų išreiškimui
Tai panaikina kai kurias problemas, atsiradusias dėl dvireikšmiškumo ir lankstumo ir tai uždeda specifikacijoms vienodumo laipsnį.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 38
Formomis pagrįstose specifikacijose nurodoma
Funkcijos ar objekto apibrėžimas Įvesčių aprašymas ir iš kur jos yra Rezultatų aprašymas ir kur jie eina Kitų reikalingų objektų atpažinimas Pradinės ir galutinės sąlygos ( jei tinka) Pašaliniai efektai(jei yra)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 39
Forma pagrįstas mazgo specifikavimas
ECLIPSE/Workstation/Tools/DE/FS/3.5.1
Function Add node
Description Adds a node to an existing design. The user selects the type of node, and its position.When added to the design, the node becomes the current selection. The user chooses the node position bymoving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of theoperation.
Requires Design graph rooted at input design identifier.
Pre-condition The design is open and displayed on the user's screen.
Post-condition The design is unchanged apart from the addition of a node of the specified typeat the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 40
Forma pagrįstas mazgo specifikavimas
Funkcija – Prideda mazgą Aprašymas – Prideda mazgą prie egzistuojančio projekto. Vartotojas pasirenka mazgo
tipą ir jo poziciją. Kada prideda prie projekto, mazgas tampa einamu pasirinkimu. Vartotojas, judindamas kursorių po sritį, kur yra pridėtas mazgas, parenka mazgo poziciją.
Įvestis – Mazgo tipas, mazgo pozicija, projekto identifikatorius. Šaltinis – mazgo tipas ir mazgo pozicija yra įvedami vartotojo, Projekto identifikatorius
iš duomenų bazės. Išvestis – Projekto identifikatorius. Paskirtis – Projektavimo duomenų bazė. Pabaigus veiksmą projektas yra įrašomas į
duomenų bazę. Reikalaujama– Projekto grafo susieto su identifikatoriumi. Pradinės sąlygos – Projektas yra atidarytas ir rodomas vartotojo ekrane. Galinės sąlygos – Projektas yra nepakeistas išskyrus pridėtą duotoje pozicijoje
nurodyto tipo mazgą. Šalutiniai efektai - nėra.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 41
PDL pagrįstas reikalavimų apibrėžimas
Reikalavimai gali būti apibrėžti, operatyviai naudojant kalbą, tokią kaip programavimo kalbą, bet su lankstesnėmis išraiškomis.
Daugiausiai vyrauja dviejose situacijose:• Kur operacija yra specifikuota, kaip veiksmų seka ir svarbi
tvarka;• Kai aparatūrinės ir programinės įrangos sąsajos turi būti
nustatytos. Trūkumai yra:
• PDL negali būti pakankamai išraiškinga, kad apibrėžtų srities sąvokas;
• Specifikacija bus suprasta greičiau kaip projektas, o ne kaip specifikacija.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 42
Dalis ATM specifikacijosclass ATM {
//declarations herepublic static void main (String args[]) throws InvalidCard {
try { thisCard.read () ; // may throw InvalidCard exception pin = KeyPad.readPin () ; attempts = 1 ; while( !thisCard.pin.equals (pin) & attempts <
4 ) { pin = KeyPad.readPin () ; attempts = attempts + 1 ;
} if (!thisCard.pin.equals (pin)
} throw newInvalisCard(“Bad PIN”);
thisBalance = thisCard.getBalance();do { Screen.prompt ( “Please select a service” ); servise = Screen.touchKey();
switch (service) {case Services.withdrawalWithReceipt:
receiptRequired = true;
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 43
PDL trūkumai PDL negali būti pakankamai išraiškingas, kad
suprantamu būdu išreikštų sistemos funkcines galimybes
Pažymėjimai suprantami tik žmonėms, žinantiems programavimo kalbą
reikalavimai gali būti greičiau priimti kaip projekto specifikacija negu kaip modelis, padedantis suprasti sistemą
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 44
Sąsajos specifikavimas Dauguma sistemų turi dirbti su kitomis
sistemomis ir bendravimo interfeisai turi būti nurodyti, kaip dalis reikalavimų
Galima apibrėžti tris sąsajų tipus• Procedūriniai interfeisai• Struktūros duomenų, kuriais vyksta apsikeitimas• Duomenų atvaizdavimas
Formalūs aprašymai - tai efektyvi technika, specifikuojant sąsają
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 45
Sąsajos aprašymas PDL
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
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 46
Aptariamos temos Funkciniai ir nefunkciniai reikalavimai Vartotojo reikalavimai Sistemos reikalavimai Programinės įrangos reikalavimų dokumentas
(reikalavimų dokumento vartotojai, reikalavimai dokumentui, reikalavimų dokumento struktūra)
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 47
Reikalavimų dokumentas Reikalavimų dokumentas yra oficialus
pareiškimas, ko reikalaujama iš sistemos kūrėjų. Turi būti įtraukta reikalavimų apibrėžimas ir
specifikacija. Tai ne projekto dokumentas. Kaip galima labiau
jis turi nustatyti KĄ sistema turi padaryti, negu tai, KAIP ji turi tai padaryti.
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ų.
Reikalavimų dokumento vartotojai
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 49
Reikalavimai dokumentui Turi nustatyti išorinį sistemos elgesį. Turi nustatyti realizavimo apribojimus. Turi būti lengvai keičiamas. Turi būti kaip vadovas programinės įrangos
palaikymui. Vertinti sistemos gyvavimo ciklą, tai yra nuspėti
pakeitimus. Charakterizuoti atsakymus į netikėtus įvykius.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 50
IEEE standartas reikalavimams Įvadas Bendras aprašymas Konkretūs reikalavimai Priedai Indeksas Tai yra bendra struktūra, kuri turi būti priderinta
konkrečioms sistemoms
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 51
Reikalavimų dokumento struktūra
Įvadas Sąrašas techninių terminų Vartotojo reikalavimų apibrėžimas Sistemos architektūra Sistemos reikalavimų specifikacija Sistemos modeliai Sistemos vystymas Priedai Indeksai
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 52
Esminiai akcentai 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.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 53
Esminiai akcentai Vartotojo reikalavimai turi būti parašyti natūralia
kalba, lentelėmis ir diagramomis. Sistemos reikalavimai skirti funkcijoms, kurias
sistema turi vykdyti. Sistemos reikalavimai gali būti parašyti
struktūrizuota natūralia kalba, PDL ar formalia kalba.
Programinės įrangos reikalavimų dokumentas yra sistemos reikalavimų suderinti teiginiai.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 54
Esminių aspektų raktiniai žodžiai (Ką apibrėžia reikalavimai, ką apibrėžia
funkciniai ir nefunkciniai reikalavimai, vartotojo ir sistemos reikalavimai, aprašymai, kas yra reikalavimų dokumentas)