Lai izveidotu labu VID, šeit jūs redzēsiet dažus punktus, kurus var izmantot un kas jāņem vērā, veidojot labas programmatūras prasību specifikācijas (VID) struktūru. Tie ir minēti zemāk satura rādītājā un ir labi izskaidroti tālāk.

Satura rādītājs

• Ievads
• Vispārīgs apraksts
• Funkcionālās prasības
• Interfeisa prasības
• Veiktspējas prasības
• Dizaina ierobežojumi
• Nefunkcionālie atribūti
• Provizoriskais grafiks un budžets
• Pielikumi
• VID dokumenta lietojumi
• Bieži uzdotie jautājumi par VID formātu
• Secinājums

Programmatūras prasību specifikācijas (SRS) formāts kā norāda nosaukums, tā ir pilnīga programmatūras specifikācija un apraksts, kas jāizpilda veiksmīgai programmatūras sistēmas izstrādei. Šīs prasības var būt gan funkcionālas, gan nefunkcionālas atkarībā no prasības veida. Mijiedarbība starp dažādiem klientiem un darbuzņēmējiem tiek veikta, jo ir nepieciešams pilnībā izprast klientu vajadzības. Atkarībā no pēc mijiedarbības iegūtās informācijas tiek izstrādāts VID, kas apraksta programmatūras prasības, kas var ietvert izmaiņas un modifikācijas, kas jāveic, lai paaugstinātu produkta kvalitāti un apmierinātu klienta pieprasījumu.

Ievads

• Šī dokumenta mērķis – Sākumā tiek izskaidrots un aprakstīts galvenais mērķis, kāpēc šis dokuments ir nepieciešams un kāds ir dokumenta mērķis.
• Šī dokumenta darbības joma - Šajā dokumentā ir aprakstīts un izskaidrots dokumenta vispārējais darbs un galvenais mērķis un kāda vērtība tas sniegs klientam. Tas ietver arī izstrādes izmaksu un nepieciešamā laika aprakstu.
• Pārskats – Šeit ir izskaidrots produkta apraksts. Tas ir vienkārši produkta kopsavilkums vai vispārējs pārskats.

Vispārīgs apraksts

Šeit ir vispārīgas produkta funkcijas, kas ietver lietotāja mērķi, lietotāja īpašību, īpašības, priekšrocības, par to, kāpēc tiek pieminēta tā nozīme. Tas arī apraksta lietotāju kopienas funkcijas.

java isempty

Funkcionālās prasības

Šeit ir pilnībā izskaidrots programmatūras sistēmas iespējamais rezultāts, kas ietver programmas darbības radītos efektus. Visas funkcionālās prasības, kas var ietvert aprēķinus, datu apstrādi utt., ir sakārtotas ranžētā secībā. Funkcionālās prasības nosaka sagaidāmo sistēmas uzvedību — kādi izvadi jārada no dotajiem ievadiem. Tie apraksta attiecības starp sistēmas ievadi un izvadi. Katrai funkcionālajai prasībai detalizēti jāapraksta visi ievadītie dati un to avots, mērvienības un derīgo ievades diapazons.

Interfeisa prasības

Šeit ir pilnībā aprakstītas un izskaidrotas programmatūras saskarnes, kas nozīmē, kā programmatūras programma sazinās savā starpā vai lietotājiem jebkuras valodas, koda vai ziņojuma veidā. Piemēri var būt koplietojamā atmiņa, datu straumes utt.

Veiktspējas prasības

Šeit ir izskaidrots, kā programmatūras sistēma veic vēlamās funkcijas noteiktos apstākļos. Tajā ir arī izskaidrots nepieciešamais laiks, nepieciešamā atmiņa, maksimālais kļūdu līmenis utt. SRS veiktspējas prasību daļā ir norādīti programmatūras sistēmas veiktspējas ierobežojumi. Visām prasībām, kas attiecas uz sistēmas darbības parametriem, jābūt skaidri norādītām. Ir divu veidu veiktspējas prasības: statiskas un dinamiskas. Statiskās prasības ir tās, kas neierobežo sistēmas izpildes raksturlielumus. Dinamiskās prasības nosaka ierobežojumus sistēmas izpildei.

Dizaina ierobežojumi

Šeit ierobežojumi, kas vienkārši nozīmē ierobežojumu vai ierobežojumu, ir norādīti un izskaidroti projektēšanas komandai. Piemēri var ietvert noteikta algoritma izmantošanu, aparatūras un programmatūras ierobežojumus utt. Klienta vidē ir vairāki faktori, kas var ierobežot dizainera izvēli, izraisot dizaina ierobežojumus, piemēram, standarti, kuriem jāievēro resursu ierobežojumi, ekspluatācija. vides, uzticamības un drošības prasības un politikas, kas var ietekmēt sistēmas dizainu. VID būtu jāidentificē un jāprecizē visi šādi ierobežojumi.

Nefunkcionālie atribūti

Šeit ir izskaidroti nefunkcionālie atribūti, kas nepieciešami programmatūras sistēmai, lai nodrošinātu labāku veiktspēju. Piemēri var ietvert drošību, pārnesamību, uzticamību, atkārtotu izmantošanu, lietojumprogrammu saderību, datu integritāti, mērogojamību utt.

lasīt no csv java

Provizoriskais grafiks un budžets

Šajā gadījumā ir izskaidrota projekta plāna sākotnējā versija un budžets, kas ietver kopējo nepieciešamo laiku un kopējās izmaksas, kas nepieciešamas projekta izstrādei.

Pielikumi

Tajā ir sniegta un izskaidrota papildu informācija, piemēram, atsauces, no kurienes informācija tiek vākta, dažu specifisku terminu definīcijas, akronīmi, saīsinājumi utt.

VID dokumenta lietojumi

• Izstrādes komanda to pieprasa, lai izstrādātu produktu atbilstoši vajadzībām.
• Testēšanas plānus ģenerē testēšanas grupa, pamatojoties uz ārējās uzvedības aprakstu.
• Apkopes un atbalsta personālam tas ir nepieciešams, lai saprastu, kas programmatūras produktam ir jādara.
• Projekta vadītājs uz to balsta savus plānus un grafiku, pūļu un resursu aplēses.
• klienti paļaujas uz to, lai uzzinātu, kādu produktu viņi var sagaidīt.
• Kā līgums starp izstrādātāju un klientu.
• dokumentācijas nolūkā.
  

Bieži uzdotie jautājumi par VID formātu

1. Kāpēc ir svarīgi definēt VID dokumenta darbības jomu?

Tvēruma noteikšana VID dokumentā palīdz klientam izprast programmatūras mērķus un vērtību. Tajā ir arī informācija par to, cik izmaksās izveide un cik ilgi tas prasīs, lai būtu skaidras projekta robežas.

2. Kas ir funkcionālās prasības VID dokumentā, un kāpēc tās ir svarīgas?

Funkcionālās prasības apraksta, kā programmatūras sistēmai ir jādarbojas, tostarp kā tai jāreaģē uz ievadi un jāveido izvadi. Tie palīdz jums noskaidrot, kas programmatūrai ir jādara, un sniedz jums vietu, kur sākt to veidot un testēt.

jlist

Secinājums

Programmatūras izstrādei ir nepieciešama labi strukturēta programmatūras prasību specifikācija (SRS). Tas palīdz ieinteresētajām personām sazināties, nodrošina ceļvedi izstrādes komandām, palīdz testētājiem izveidot efektīvus testēšanas plānus, sniedz norādījumus apkopes un atbalsta darbiniekiem, informē projektu vadības lēmumus un nosaka klientu vēlmes. VID dokuments palīdz nodrošināt programmatūras atbilstību funkcionālajām un nefunkcionālajām prasībām, kā rezultātā tiek iegūts kvalitatīvs produkts laikā un budžeta ietvaros.