Reikalavimai programinei įrangai

1. Reikalavimai programinei įrangai • Sistemos aprašymai ir specifikacijos

2. 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

3. Aptariamos temos • Funkciniai ir nefunkciniai reikalavimai • Vartotojo reikalavimai • Sistemos reikalavimai • Sistemos modeliavimas • Programinės įrangos reikalavimų dokumentas

4. 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

5. 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

6. 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.”

7. 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.

8. Apibrėžimai ir specifikacijos • Reikalavimų 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.

9. Kliento vadybininkai Sistemos galutiniai vartotojai Kliento inžinieriai Kūrėjų vadybininkai Sistemos architektai Vartotojo reikalavimai Sistemos galutiniai vartotojai Kliento inžinieriai Sistemos architektai Programinės įrangos tobulintojai(vystytojai) Galimi kliento inžinieriai Sistemos architektai Programinės įrangos tobulintojai(vystytojai) Sistemos reikalavimai Programinės įrangos projektavimo specifikacijos Reikalavimų skaitytojai

10. Aptariamos temos • Funkciniai ir nefunkciniai reikalavimai • Vartotojo reikalavimai • Sistemos reikalavimai • Sistemos modeliavimas • Programinės įrangos reikalavimų dokumentas

11. 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.

12. 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.

13. 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ą.

14. 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.

15. 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ą.

16. 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.

17. 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.

18. Našumo reikalavimai Nefunkciniai reikalavimai Produkto reikalavimai Efektyvumo reikalavimai Organizaciniai reikalavimai Išoriniai reikalavimai Patikimumo reikalavimai Mobilumo reikalavimai Naudojimo reikalavimai Privatumo reikalavimai Erdvės reikalavimai Pristatymo reikalavimai Įdiegimo reikalavimai Prisiderinamumo reikalavimai Etikos reikalavimai Standartų reikalavimai Teisiniai reikalavimai Saugos reikalavimai Nefunkcinių reikalavimų tipai

19. 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į.

20. 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.

21. 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ą.

22. Reikalavimų matavimai Savybės Matavimai Processed transactions/second Greitis User/Event response time Screen refresh time K Bytes Dydis Number of RAM chips Training time Naudojimo lengvumas Number of help frames Mean time to failure Probability of unavailability Patikimumas Rate of failure occurrence Availability Time to restart after failure Patvarumas Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Pernešamumas Number of target systems

23. 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?

24. 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.

25. 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ą.

26. 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ą.

27. Aptariamos temos • Funkciniai ir nefunkciniai reikalavimai • Vartotojo reikalavimai • Sistemos reikalavimai • Sistemos modeliavimas • Programinės įrangos reikalavimų dokumentas

28. 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.

29. 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.

30. 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.

31. Aptariamos temos • Funkciniai ir nefunkciniai reikalavimai • Vartotojo reikalavimai • Sistemos reikalavimai • Sistemos modeliavimas • Programinės įrangos reikalavimų dokumentas

32. 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ą.

33. 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.

34. 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.

35. Į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. Tai 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. Matematinės specifikacijos Alternatyvos natūralios kalbos specifikacijoms

36. 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į.

37. 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)

38. Forma pagrįstas mazgo specifikavimas

39. 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.

40. 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.

41. Dalis ATM specifikacijos class ATM { //declarations here public static void main (String args[]) throwsInvalidCard { 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;

42. 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ą

43. 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 pažymėjimai - tai efektyvi technika, specifikuojant sąsają

44. Sąsajos aprašymas PDL

45. Aptariamos temos • Funkciniai ir nefunkciniai reikalavimai • Vartotojo reikalavimai • Sistemos reikalavimai • Sistemos modeliavimas • Programinės įrangos reikalavimų dokumentas

46. Sistemų modeliavimas • Sistemų modeliavimas padeda analitikui suprasti sistemos veikimą ir sistemos modeliai naudojami bendravimui su užsakovu. • Skirtingi modeliai atvaizduoja sistemą skirtingais požiūriais: • Išorinis požiūris rodo sistemos kontekstą arba aplinką; • Elgsenos požiūris atspindi sistemos veikimą; • Struktūrinis požiūris atspindi sistemos arba duomenų architektūrą.

47. Vieninga atvaizdavimo kalba • Sukurta iš plačiai naudojamų objektiškai orientuotų analizės ir projektavimo metodų. • Tapo efektyviu objektiškai orientuoto atvaizdavimo standartu. • Žymėjimai: • Objektinės klasės - stačiakampiai su vardu viršuje, atributais viduje ir operacijomis apačioje; • Ryšiai tarp klasių yra linijos su rodyklėmis; • Paveldimumas nurodytas hierarchijoje “viršun“ .

48. Objekto elgesio atvaizdavimas • Elgsenos modelis parodo sąveiką tarp objektų nusakant tam tikrą sistemos elgesį, kuris yra apibrėžtas vartojimo atvejais. • Sekos diagramos (arba bendradarbiavimo diagramos) UML’e yra naudojamos sąveikai tarp objektų atvaizduoti.

49. Elektroniniai leidiniai

50. CASE priemonės • Suderinta įrankių seka, skirta palaikyti susijusiems programinės įrangos procesų veiksmams, tokiems kaip analizė, projektavimas ar testavimas. • Analizės ir projektavimo priemonės palaiko sistemos modeliavimą reikalavimų ruošimo ir sistemos projektavimo metu. • Šios priemonės gali palaikyti specifiniu projektavimo metodus arba gali numatyti kelių skirtingų tipų sistemos modelių kūrimą.