Programinės įrangos kūrimo proceso reikalavimų etapo gamyba yra Programinės įrangos reikalavimų specifikacijos (SRS) (taip pat vadinamas a reikalavimų dokumentas ). Ši ataskaita sudaro pagrindą programinės įrangos inžinerijos veiklai ir kuriama, kai nustatomi ir analizuojami visi reikalavimai. SRS yra oficiali ataskaita, kuri veikia kaip programinės įrangos atvaizdas, leidžiantis klientams peržiūrėti, ar ji (SRS) atitinka jų reikalavimus. Be to, ji apima vartotojo reikalavimus sistemai ir išsamias sistemos reikalavimų specifikacijas.
SRS yra konkretaus programinės įrangos produkto, programos ar taikomųjų programų rinkinio, atliekančio tam tikras funkcijas konkrečioje aplinkoje, specifikacija. Jis tarnauja keliems tikslams, priklausomai nuo to, kas jį rašo. Pirma, SRS gali parašyti sistemos klientas. Antra, SRS galėtų parašyti sistemos kūrėjas. Abu metodai sukuria visiškai skirtingas situacijas ir nustato skirtingus dokumento tikslus. Pirmasis atvejis, SRS, naudojamas vartotojų poreikiams ir lūkesčiams apibrėžti. Antrasis atvejis, SRS, yra parašytas įvairiems tikslams ir tarnauja kaip sutarties dokumentas tarp užsakovo ir kūrėjo.
Geros SRS savybės
Toliau pateikiamos gero SRS dokumento savybės:
1. Teisingumas: Vartotojo apžvalga naudojama siekiant užtikrinti SRS nurodytų reikalavimų tikslumą. Teigiama, kad SRS yra tobula, jei ji patenkina visus poreikius, kurių iš tikrųjų tikimasi iš sistemos.
2. Išsamumas: SRS yra baigtas tada ir tik tada, kai jame yra šie elementai:
(1). Visi esminiai reikalavimai, susiję su funkcionalumu, veikimu, dizainu, apribojimais, atributais ar išorinėmis sąsajomis.
mašinraščio data ir laikas
(2). Programinės įrangos atsakymų į visas realizuojamas įvesties duomenų klases visose galimose situacijose.
Pastaba: būtina nurodyti atsakymus į galiojančias ir netinkamas reikšmes.
(3). Išsamios etiketės ir nuorodos į visus paveikslėlius, lenteles ir diagramas SRS bei visų terminų ir matavimo vienetų apibrėžimus.
3. Nuoseklumas: SRS yra nuoseklus tada ir tik tada, kai nėra jo konflikte aprašytų individualių reikalavimų pogrupio. SRS galimi trys konfliktų tipai:
(1). Nurodytos realaus pasaulio objektų charakteristikos gali prieštarauti. Pavyzdžiui,
a) Išvesties ataskaitos formatas viename reikalavime gali būti apibūdintas kaip lentelės, o kitame kaip tekstinis.
b) Viena sąlyga gali nurodyti, kad visos lemputės turi būti žalios, o kitos – kad visos lemputės turi būti mėlynos.
(2). Tarp dviejų nurodytų veiksmų gali kilti pagrįstas arba laikinas konfliktas. Pavyzdžiui,
a) Vienas reikalavimas gali lemti, kad programa pridės dvi įvestis, o kitas gali nustatyti, kad programa juos padaugins.
(b) Viena sąlyga gali nurodyti, kad „A“ visada turi būti po „B“, o kita sąlyga reikalauja, kad „A“ ir „B“ vyktų kartu.
(3). Du ar daugiau reikalavimų gali apibrėžti tą patį realaus pasaulio objektą, bet tam objektui naudoti skirtingus terminus. Pavyzdžiui, programos vartotojo įvesties užklausa viename reikalavime gali būti vadinama raginimu, o kitame – užuomina. Standartinės terminijos ir aprašymų naudojimas skatina nuoseklumą.
4. Vienareikšmiškumas: SRS yra vienareikšmis, kai kiekvienas fiksuotas reikalavimas turi tik vieną aiškinimą. Tai rodo, kad kiekvienas elementas yra savaip interpretuojamas. Jei naudojamas metodas su keliais apibrėžimais, reikalavimų ataskaitoje turėtų būti nurodytos SRS pasekmės, kad ji būtų aiški ir lengvai suprantama.
tkinter rėmas
5. Reitingas pagal svarbą ir stabilumą: SRS reitinguojama pagal svarbą ir stabilumą, jei kiekvienas jame esantis reikalavimas turi identifikatorių, nurodantį to konkretaus reikalavimo svarbą arba stabilumą.
Paprastai visi reikalavimai nėra vienodai svarbūs. Kai kurios būtinos sąlygos gali būti būtinos, ypač svarbioms gyvybei svarbioms programoms, o kitos gali būti pageidautinos. Kiekvienas elementas turėtų būti identifikuotas, kad šie skirtumai būtų aiškūs ir aiškūs. Kitas būdas reitinguoti reikalavimus yra atskirti elementų klases kaip esminius, sąlyginius ir pasirenkamus.
6. Keičiamumas: SRS turėtų būti kiek įmanoma modifikuojamas ir turi turėti galimybę greitai gauti tam tikrus sistemos pakeitimus. Modifikacijos turi būti puikiai indeksuotos ir su kryžminėmis nuorodomis.
7. Patikrinimas: SRS yra teisingas, kai nurodytus reikalavimus galima patikrinti naudojant ekonomišką sistemą ir patikrinti, ar galutinė programinė įranga atitinka tuos reikalavimus. Reikalavimai tikrinami remiantis apžvalgomis.
8. Atsekamumas: SRS galima atsekti, jei kiekvieno iš reikalavimų kilmė yra aiški ir jei tai palengvina kiekvienos sąlygos nuorodas būsimuose kūrimo ar tobulinimo dokumentuose.
Yra du atsekamumo tipai:
1. Atgalinis atsekamumas: Tai priklauso nuo kiekvieno reikalavimo, aiškiai nurodant jo šaltinį ankstesniuose dokumentuose.
2. Išankstinis atsekamumas: Tai priklauso nuo to, ar kiekvienas SRS elementas turi unikalų pavadinimą arba nuorodos numerį.
Išankstinis SRS atsekamumas yra ypač svarbus, kai programinės įrangos produktas pradeda eksploatavimo ir priežiūros etapą. Kadangi kodas ir projekto dokumentas yra modifikuojami, būtina turėti galimybę nustatyti visą reikalavimų, kuriems gali būti taikomi tie pakeitimai, rinkinį.
9. Dizaino nepriklausomumas: Turėtų būti galimybė pasirinkti iš kelių galutinės sistemos dizaino alternatyvų. Tiksliau sakant, SRS neturėtų būti jokių įgyvendinimo detalių.
dekoduoti base64 javascript
10. Bandomumas: SRS turėtų būti parašytas tokiu būdu, kad iš ataskaitos būtų paprasta sugeneruoti bandomuosius atvejus ir bandymų planus.
11. Klientui suprantama: Galutinis vartotojas gali būti savo srities ekspertas, bet gali būti neapmokytas informatikos srityje. Todėl reikėtų kiek įmanoma vengti formalių užrašų ir simbolių tikslo. Kalba turi būti paprasta ir aiški.
12. Tinkamas abstrakcijos lygis: Jei SRS yra parašytas reikalavimų etapui, detalės turi būti aiškiai paaiškintos. Tuo tarpu galimybių studijai atlikti galima naudoti mažiau analizės. Vadinasi, abstrakcijos lygis keičiasi pagal SRS tikslą.
Gero SRS dokumento savybės
Pagrindinės gero SRS dokumento savybės yra šios:
Glaustai: SRS ataskaita turi būti glausta ir kartu nedviprasmiška, nuosekli ir išsami. Daugiakalbiai ir nesusiję aprašymai sumažina skaitomumą ir padidina klaidų galimybes.
Struktūrinis: Jis turėtų būti gerai struktūrizuotas. Geros struktūros dokumentą lengva suprasti ir keisti. Praktiškai SRS dokumentas keletą kartų peržiūrimas, kad atitiktų vartotojo reikalavimus. Dažnai vartotojų poreikiai kinta per tam tikrą laikotarpį. Todėl, kad SRS dokumento pakeitimus būtų lengva atlikti, labai svarbu, kad ataskaita būtų gerai struktūrizuota.
Juodosios dėžutės vaizdas: Ji turėtų tik apibrėžti, ką sistema turėtų daryti, ir nenurodinėti, kaip tai padaryti. Tai reiškia, kad SRS dokumente turėtų būti apibrėžta išorinė sistemos elgsena, o ne aptarti diegimo klausimai. SRS ataskaitoje į kuriamą sistemą turėtų būti žiūrima kaip į juodąją dėžę ir turi būti apibrėžta išoriškai matoma sistemos elgsena. Dėl šios priežasties SRS ataskaita taip pat žinoma kaip sistemos juodosios dėžės specifikacija.
Koncepcinis vientisumas: Jis turėtų parodyti sąvokų vientisumą, kad skaitytojas galėtų jį tik suprasti. Reakcija į nepageidaujamus įvykius: ji turėtų apibūdinti priimtinus reakciją į nepageidaujamus įvykius. Tai vadinama sistemos atsaku į išskirtines sąlygas.
Patikrinama: Visi sistemos reikalavimai, kaip nurodyta SRS dokumente, turi būti teisingi. Tai reiškia, kad turėtų būti įmanoma nuspręsti, ar įgyvendinant buvo įvykdyti reikalavimai, ar ne.