Izdelava stopnje zahtev procesa razvoja programske opreme je Specifikacije programskih zahtev (SRS) (imenovan tudi a dokument z zahtevami ). To poročilo postavlja temelje za dejavnosti inženiringa programske opreme in se konstruira, ko so izluščene in analizirane celotne zahteve. SRS je formalno poročilo, ki deluje kot predstavitev programske opreme, ki strankam omogoča pregled, ali le-ta (SRS) ustreza njihovim zahtevam. Vsebuje tudi uporabniške zahteve za sistem in podrobne specifikacije sistemskih zahtev.

SRS je specifikacija za določen programski izdelek, program ali nabor aplikacij, ki izvajajo določene funkcije v določenem okolju. Služi več ciljem, odvisno od tega, kdo ga piše. Prvič, SRS bi lahko napisal odjemalec sistema. Drugič, SRS bi lahko napisal razvijalec sistema. Obe metodi ustvarjata povsem različne situacije in določata povsem različne namene dokumenta. Prvi primer, SRS, se uporablja za opredelitev potreb in pričakovanj uporabnikov. Drugi primer, SRS, je napisan za različne namene in služi kot pogodbeni dokument med stranko in razvijalcem.

Značilnosti dobrega SRS

Sledijo značilnosti dobrega dokumenta SRS:

1. Pravilnost: Uporabniški pregled se uporablja za zagotavljanje točnosti zahtev, navedenih v SRS. SRS naj bi bil popoln, če pokriva vse potrebe, ki se od sistema resnično pričakujejo.

2. Popolnost: SRS je popoln, če in samo če vključuje naslednje elemente:

(1). Vse bistvene zahteve, ne glede na to, ali se nanašajo na funkcionalnost, zmogljivost, oblikovanje, omejitve, atribute ali zunanje vmesnike.

kako pretvoriti iz int v niz v javi

(2). Opredelitev njihovih odzivov programske opreme na vse izvedljive razrede vhodnih podatkov v vseh razpoložljivih kategorijah situacij.

Opomba: bistveno je, da podate odgovore na veljavne in neveljavne vrednosti.

(3). Celotne oznake in sklicevanja na vse slike, tabele in diagrame v SRS ter definicije vseh pojmov in merskih enot.

3. Doslednost: SRS je dosleden, če in samo če ni nobene podmnožice posameznih zahtev, opisanih v njegovem konfliktu. Obstajajo tri vrste možnih konfliktov v SRS:

(1). Navedene značilnosti predmetov iz resničnega sveta so lahko v nasprotju. na primer

(a) Oblika izhodnega poročila je lahko v eni zahtevi opisana kot tabelarična, v drugi pa kot besedilna.

(b) En pogoj lahko navaja, da morajo biti vse luči zelene, drugi pa navaja, da morajo biti vse luči modre.

(2). Med navedenima dejanjema lahko pride do razumnega ali časovnega konflikta. na primer

(a) Ena zahteva lahko določa, da bo program dodal dva vhoda, druga pa lahko določa, da ju bo program pomnožil.

(b) En pogoj lahko navaja, da mora 'A' vedno slediti 'B', medtem ko drugi zahteva, da se 'A in B' pojavljata hkrati.

(3). Dve ali več zahtev lahko definirata isti realni objekt, vendar za ta objekt uporabljajo različne izraze. Na primer, zahtevo programa za uporabniški vnos lahko imenujemo 'poziv' v eni zahtevi in ​​'namig' v drugi. Uporaba standardne terminologije in opisov spodbuja doslednost.

4. Nedvoumnost: SRS je nedvoumen, kadar ima vsaka fiksna zahteva samo eno razlago. To pomeni, da je vsak element edinstveno interpretiran. Če se uporablja metoda z več definicijami, mora poročilo o zahtevah določiti posledice v SRS, tako da je jasno in preprosto razumljivo.

5. Razvrstitev po pomembnosti in stabilnosti: SRS je razvrščen po pomembnosti in stabilnosti, če ima vsaka zahteva v njem identifikator, ki označuje pomembnost ali stabilnost te posebne zahteve.

Običajno vse zahteve niso enako pomembne. Nekateri predpogoji so lahko bistveni, zlasti za življenjsko kritične aplikacije, drugi pa so lahko zaželeni. Vsak element je treba identificirati, da bodo te razlike jasne in eksplicitne. Drug način za razvrščanje zahtev je razlikovanje razredov elementov kot bistvenih, pogojnih in neobveznih.

6. Možnost spreminjanja: SRS bi moral biti čim bolj spremenljiv in bi moral biti sposoben do neke mere hitro pridobiti spremembe v sistemu. Spremembe morajo biti popolnoma indeksirane in navzkrižno povezane.

7. Preverljivost: SRS je pravilen, če je mogoče navedene zahteve preveriti s stroškovno učinkovitim sistemom, da se preveri, ali končna programska oprema izpolnjuje te zahteve. Zahteve se preverjajo s pomočjo pregledov.

8. Sledljivost: SRS je sledljiv, če je izvor vsake zahteve jasen in če olajša sklicevanje na vsak pogoj v prihodnji razvojni ali izboljšavi dokumentaciji.

Obstajata dve vrsti sledljivosti:

zbirka podatkov

1. Sledljivost nazaj: To je odvisno od vsake zahteve, ki se izrecno sklicuje na svoj vir v prejšnjih dokumentih.

2. Naprej sledljivost: To je odvisno od tega, ali ima vsak element v SRS edinstveno ime ali referenčno številko.

Naprejšnja sledljivost SRS je še posebej pomembna, ko programski izdelek vstopi v fazo delovanja in vzdrževanja. Ker se koda in projektni dokument spreminjata, je treba biti sposoben ugotoviti celoten niz zahtev, ki jih te spremembe lahko zadevajo.

9. Neodvisnost oblikovanja: Za končni sistem bi morala obstajati možnost izbire med več alternativami oblikovanja. Natančneje, SRS ne bi smel vsebovati nobenih podrobnosti o izvajanju.

10. Preizkušljivost: SRS mora biti napisan tako, da je iz poročila enostavno ustvariti testne primere in testne načrte.

11. Razumljivo s strani stranke: Končni uporabnik je lahko strokovnjak na svojem eksplicitnem področju, vendar morda ni usposobljen za računalništvo. Zato se je treba čim bolj izogibati namenu formalnih zapisov in simbolov. Jezik naj bo preprost in jasen.

js večvrstični niz

12. Prava raven abstrakcije: Če je SRS napisan za stopnjo zahtev, je treba podrobnosti izrecno pojasniti. Medtem ko je za študijo izvedljivosti mogoče uporabiti manj analiz. Zato se raven abstrakcije spreminja glede na cilj SRS.

Lastnosti dobrega dokumenta SRS

Bistvene lastnosti dobrega dokumenta SRS so naslednje:

Jedrnato: Poročilo SRS mora biti jedrnato in hkrati nedvoumno, dosledno in popolno. Natančni in nepomembni opisi zmanjšujejo berljivost in povečujejo možnosti napak.

Strukturirano: Biti mora dobro strukturiran. Dobro strukturiran dokument je preprost za razumevanje in spreminjanje. V praksi je dokument SRS podvržen več revizijam, da bi bil kos zahtevam uporabnikov. Zahteve uporabnikov se pogosto spreminjajo v določenem časovnem obdobju. Zato je za lažje spreminjanje dokumenta SRS nujno, da je poročilo dobro strukturirano.

Pogled črne skrinjice: Opredeliti mora le, kaj mora sistem narediti, in se vzdržati navajanja, kako to storiti. To pomeni, da mora dokument SRS definirati zunanje obnašanje sistema in ne obravnavati vprašanj implementacije. Poročilo SRS mora sistem, ki ga je treba razviti, obravnavati kot črno skrinjico in mora definirati navzven vidno obnašanje sistema. Zaradi tega je poročilo SRS znano tudi kot specifikacija črne skrinjice sistema.

Konceptualna celovitost: Izkazovati mora konceptualno celovitost, tako da jo lahko bralec zgolj razume. Odziv na neželene dogodke: Označiti mora sprejemljive odzive na neželene dogodke. To se imenuje odziv sistema na izjemne razmere.

Preverljivo: Vse zahteve sistema, kot so dokumentirane v dokumentu SRS, morajo biti pravilne. To pomeni, da bi moralo biti mogoče odločiti, ali so bile zahteve pri izvajanju izpolnjene ali ne.