Programmatūras izstrādes procesa prasību posma ražošana ir Programmatūras prasību specifikācijas (SRS) (saukts arī par a prasību dokuments ). Šis ziņojums veido pamatu programmatūras inženierijas darbībām un tiek veidots, kad tiek noskaidrotas un analizētas visas prasības. VID ir formāls pārskats, kas darbojas kā programmatūras attēlojums, kas ļauj klientiem pārbaudīt, vai tā (VID) atbilst viņu prasībām. Tas ietver arī lietotāja prasības sistēmai, kā arī detalizētas sistēmas prasību specifikācijas.
VID ir specifikācija konkrētam programmatūras produktam, programmai vai lietojumprogrammu kopai, kas veic noteiktas funkcijas noteiktā vidē. Tas kalpo vairākiem mērķiem atkarībā no tā, kurš to raksta. Pirmkārt, VID varētu rakstīt sistēmas klients. Otrkārt, VID varētu rakstīt sistēmas izstrādātājs. Abas metodes rada pilnīgi dažādas situācijas un nosaka dokumentam atšķirīgus mērķus. Pirmais gadījums, VID, tiek izmantots, lai definētu lietotāju vajadzības un cerības. Otrs gadījums, VID, ir rakstīts dažādiem mērķiem un kalpo kā līguma dokuments starp pasūtītāju un izstrādātāju.
Laba VID raksturojums
Tālāk ir norādītas laba VID dokumenta iezīmes:
1. Pareizība: Lietotāju apskats tiek izmantots, lai nodrošinātu VID noteikto prasību precizitāti. Tiek uzskatīts, ka VID ir ideāls, ja tas aptver visas vajadzības, kas patiešām tiek gaidītas no sistēmas.
2. Pabeigtība: VID ir pilnīgs tad un tikai tad, ja tajā ir iekļauti šādi elementi:
(1). Visas pamatprasības neatkarīgi no tā, vai tās attiecas uz funkcionalitāti, veiktspēju, dizainu, ierobežojumiem, atribūtiem vai ārējām saskarnēm.
Linux mainīt direktorija nosaukumu
(2). Programmatūras reakciju definīcija uz visām realizējamajām ievaddatu klasēm visās pieejamajās situāciju kategorijās.
Piezīme. Ir svarīgi norādīt atbildes gan uz derīgām, gan nederīgām vērtībām.
(3). Pilnas etiķetes un atsauces uz visiem attēliem, tabulām un diagrammām VID un visu terminu un mērvienību definīcijām.
3. Konsekvence: VID ir konsekvents tad un tikai tad, ja tā konfliktā nav aprakstīta atsevišķu prasību apakškopa. VID ir iespējami trīs konfliktu veidi:
(1). Norādītās reālās pasaules objektu īpašības var būt pretrunā. Piemēram,
a) Izvades ziņojuma formātu vienā prasībā var aprakstīt kā tabulas, bet citā kā tekstuālu.
b) Viens nosacījums var noteikt, ka visām gaismām jābūt zaļām, bet citā nosacījumā ir noteikts, ka visām gaismām jābūt zilām.
(2). Starp abām norādītajām darbībām var būt saprātīgs vai īslaicīgs konflikts. Piemēram,
(a) Viena prasība var noteikt, ka programma pievienos divus ievades datus, bet cita var noteikt, ka programma tās pavairos.
kas ir rom
(b) Viens nosacījums var norādīt, ka “A” vienmēr ir jāseko burtam “B”, bet otrs nosaka, ka “A” un “B” jāatbilst vienlaikus.
(3). Divas vai vairākas prasības var definēt vienu un to pašu reālās pasaules objektu, bet šim objektam var izmantot dažādus terminus. Piemēram, programmas pieprasījumu pēc lietotāja ievades var saukt par “uzvedni” vienā prasībā un par “norādu” citā. Standarta terminoloģijas un aprakstu izmantošana veicina konsekvenci.
4. Nepārprotamība: VID ir nepārprotams, ja katrai fiksētajai prasībai ir tikai viena interpretācija. Tas liek domāt, ka katrs elements ir unikāli interpretēts. Gadījumā, ja tiek izmantota metode ar vairākām definīcijām, prasību ziņojumā ir jānosaka ietekme uz VID, lai tas būtu skaidrs un vienkārši saprotams.
5. Reitings pēc svarīguma un stabilitātes: VID tiek ranžēts pēc svarīguma un stabilitātes, ja katrai tajā ietvertajai prasībai ir identifikators, kas norāda vai nu konkrētās prasības nozīmīgumu, vai stabilitāti.
Parasti visas prasības nav vienlīdz svarīgas. Daži priekšnosacījumi var būt būtiski, jo īpaši dzīvībai kritiskiem lietojumiem, savukārt citi var būt vēlami. Katrs elements ir jāidentificē, lai šīs atšķirības būtu skaidras un skaidras. Vēl viens veids, kā klasificēt prasības, ir nošķirt priekšmetu klases kā būtiskas, nosacītas un izvēles.
6. Modificējamība: VID ir jābūt pēc iespējas modificējamam un jāspēj ātri iegūt izmaiņas sistēmā zināmā mērā. Modifikācijām jābūt nevainojami indeksētām un savstarpējām atsaucēm.
7. Pārbaudāmība: VID ir pareizi, ja noteiktās prasības var pārbaudīt ar rentablu sistēmu, lai pārbaudītu, vai gala programmatūra atbilst šīm prasībām. Prasības tiek pārbaudītas ar atsauksmju palīdzību.
8. Izsekojamība: VID ir izsekojams, ja ir skaidra katras prasības izcelsme un ja tas atvieglo katra nosacījuma atsauci turpmākās izstrādes vai uzlabošanas dokumentācijā.
Ir divi izsekojamības veidi:
1. Atpakaļējā izsekojamība: Tas ir atkarīgs no katras prasības, kurā ir skaidri norādīts tās avots iepriekšējos dokumentos.
2. Tālāk izsekojamība: Tas ir atkarīgs no tā, vai katram VID elementam ir unikāls nosaukums vai atsauces numurs.
VID izsekojamība uz priekšu ir īpaši svarīga, kad programmatūras produkts nonāk ekspluatācijas un apkopes fāzē. Tā kā kods un projekta dokuments tiek mainīti, ir jāspēj pārliecināties par visu prasību kopumu, uz ko šīs izmaiņas var attiekties.
9. Dizaina neatkarība: Jābūt iespējai izvēlēties no vairākām galīgās sistēmas dizaina alternatīvām. Konkrētāk, VID nedrīkst būt nekādas ieviešanas detaļas.
10. Pārbaudāmība: VID jāraksta tādā veidā, lai no atskaites būtu vienkārši ģenerēt pārbaudes gadījumus un testēšanas plānus.
11. Klientam saprotams: Galalietotājs var būt eksperts savā konkrētajā jomā, bet var nebūt apmācīts datorzinātnēs. Tāpēc pēc iespējas vairāk jāizvairās no formālu apzīmējumu un simbolu nolūka. Valodai jābūt vienkāršai un skaidrai.
12. Pareizais abstrakcijas līmenis: Ja VID ir rakstīts prasību posmam, detaļas ir skaidri jāpaskaidro. Tā kā priekšizpētē var izmantot mazāk analīžu. Līdz ar to abstrakcijas līmenis mainās atbilstoši VID mērķim.
Laba VID dokumenta īpašības
Laba VID dokumenta būtiskās īpašības ir šādas:
Īsi: VID ziņojumam jābūt kodolīgam un tajā pašā laikā nepārprotamam, konsekventam un pilnīgam. Plaši un neatbilstoši apraksti samazina lasāmību un palielina kļūdu iespējas.
Strukturēts: Tam jābūt labi strukturētam. Labi strukturētu dokumentu ir viegli saprast un modificēt. Praksē VID dokuments tiek vairākkārt pārstrādāts, lai atbilstu lietotāju prasībām. Bieži vien lietotāju prasības mainās noteiktā laika periodā. Tāpēc, lai atvieglotu VID dokumenta grozījumus, ir svarīgi, lai ziņojums būtu labi strukturēts.
Melnās kastes skats: Tam vajadzētu tikai noteikt, kas sistēmai ir jādara, un atturēties no paziņojuma, kā tas jādara. Tas nozīmē, ka VID dokumentā ir jādefinē sistēmas ārējā uzvedība, nevis jāapspriež ieviešanas jautājumi. VID ziņojumā izstrādājamā sistēma jāskata kā melnā kaste un jādefinē sistēmas ārēji redzamā darbība. Šī iemesla dēļ VID ziņojums ir pazīstams arī kā sistēmas melnās kastes specifikācija.
java lambda
Konceptuālā integritāte: Tam vajadzētu parādīt konceptuālu integritāti, lai lasītājs to varētu tikai saprast. Reakcija uz nevēlamiem notikumiem: tai jāraksturo pieņemama reakcija uz nevēlamiem notikumiem. Tos sauc par sistēmas reakciju uz ārkārtas apstākļiem.
Pārbaudāms: Visām sistēmas prasībām, kas dokumentētas VID dokumentā, jābūt korektām. Tas nozīmē, ka jābūt iespējai izlemt, vai ieviešanā ir izpildītas prasības.