Faza proizvodnje zahtjeva procesa razvoja softvera je Specifikacije softverskih zahtjeva (SRS) (također se naziva a dokument zahtjeva ). Ovo izvješće postavlja temelje za aktivnosti softverskog inženjeringa i izrađuje se kada se izvuku i analiziraju cjelokupni zahtjevi. SRS je formalno izvješće, koje djeluje kao prikaz softvera koji omogućuje klijentima da pregledaju je li (SRS) u skladu s njihovim zahtjevima. Također, sadrži zahtjeve korisnika za sustav kao i detaljne specifikacije zahtjeva sustava.
SRS je specifikacija za određeni softverski proizvod, program ili skup aplikacija koje obavljaju određene funkcije u određenom okruženju. Ima nekoliko ciljeva, ovisno o tome tko ga piše. Prvo, SRS bi mogao napisati klijent sustava. Drugo, SRS bi mogao napisati programer sustava. Ove dvije metode stvaraju potpuno različite situacije i uspostavljaju posve različite svrhe dokumenta. Prvi slučaj, SRS, koristi se za definiranje potreba i očekivanja korisnika. Drugi slučaj, SRS, napisan je za različite svrhe i služi kao ugovorni dokument između korisnika i razvojnog programera.
Karakteristike dobrog SRS-a
Slijede karakteristike dobrog SRS dokumenta:
1. Ispravnost: Pregled korisnika koristi se za osiguranje točnosti zahtjeva navedenih u SRS-u. Za SRS se kaže da je savršen ako pokriva sve potrebe koje se od sustava uistinu očekuju.
2. Potpunost: SRS je potpun ako, i samo ako, uključuje sljedeće elemente:
(1). Svi bitni zahtjevi, bilo da se odnose na funkcionalnost, izvedbu, dizajn, ograničenja, atribute ili vanjska sučelja.
vraćanje niza java
(2). Definicija njihovih odgovora softvera na sve ostvarive klase ulaznih podataka u svim dostupnim kategorijama situacija.
Napomena: bitno je navesti odgovore i na važeće i na nevažeće vrijednosti.
(3). Potpune oznake i reference na sve slike, tablice i dijagrame u SRS-u i definicije svih pojmova i mjernih jedinica.
3. Dosljednost: SRS je dosljedan ako, i samo ako, nijedan podskup pojedinačnih zahtjeva nije opisan u njegovom sukobu. Postoje tri vrste mogućih sukoba u SRS-u:
(1). Navedene karakteristike objekata iz stvarnog svijeta mogu biti u sukobu. Na primjer,
(a) Format izlaznog izvješća može se u jednom zahtjevu opisati kao tablični, ali u drugom kao tekstualni.
(b) Jedan uvjet može navesti da sva svjetla budu zelena, dok drugi nalaže da sva svjetla budu plava.
(2). Može postojati razuman ili vremenski sukob između dvije navedene radnje. Na primjer,
(a) Jedan zahtjev može odrediti da će program dodati dva ulaza, a drugi može odrediti da će ih program umnožiti.
(b) Jedan uvjet može navesti da 'A' mora uvijek slijediti 'B', dok drugi zahtijeva da se 'A i B' pojavljuju zajedno.
(3). Dva ili više zahtjeva mogu definirati isti objekt iz stvarnog svijeta, ali koristiti različite pojmove za taj objekt. Na primjer, zahtjev programa za korisničkim unosom može se nazvati 'upit' u jednom zahtjevu i 'napomena' u drugom. Korištenje standardne terminologije i opisa promiče dosljednost.
4. Jednoznačnost: SRS je nedvosmislen kada svaki fiksni zahtjev ima samo jedno tumačenje. To sugerira da je svaki element jedinstveno interpretiran. U slučaju da se koristi metoda s više definicija, izvješće o zahtjevima treba odrediti implikacije u SRS-u tako da bude jasno i jednostavno za razumijevanje.
5. Rangiranje po važnosti i stabilnosti: SRS je rangiran prema važnosti i stabilnosti ako svaki zahtjev u njemu ima identifikator koji ukazuje na značaj ili stabilnost tog određenog zahtjeva.
Tipično, svi zahtjevi nisu jednako važni. Neki preduvjeti mogu biti bitni, posebno za aplikacije kritične za život, dok drugi mogu biti poželjni. Svaki element treba identificirati kako bi te razlike bile jasne i eksplicitne. Drugi način rangiranja zahtjeva je razlikovanje klasa stavki kao bitnih, uvjetnih i izbornih.
6. Mogućnost izmjene: SRS bi trebao biti što je moguće modifikabilniji i trebao bi biti sposoban za brzo dobivanje promjena u sustavu do neke mjere. Izmjene bi trebale biti savršeno indeksirane i međusobno povezane.
ms word alatna traka za brzi pristup
7. Provjerljivost: SRS je ispravan kada se navedeni zahtjevi mogu provjeriti s isplativim sustavom kako bi se provjerilo ispunjava li konačni softver te zahtjeve. Zahtjevi se provjeravaju uz pomoć recenzija.
8. Sljedivost: SRS je sljediv ako je podrijetlo svakog od zahtjeva jasno i ako olakšava referenciranje svakog uvjeta u budućoj dokumentaciji razvoja ili poboljšanja.
Postoje dvije vrste sljedivosti:
1. Sljedivost unatrag: To ovisi o svakom zahtjevu koji izričito navodi svoj izvor u ranijim dokumentima.
2. Sljedivost prema naprijed: To ovisi o tome da svaki element u SRS-u ima jedinstveni naziv ili referentni broj.
Sljedivost SRS-a unaprijed je posebno ključna kada softverski proizvod ulazi u fazu rada i održavanja. Kako se kôd i projektni dokument mijenjaju, potrebno je moći utvrditi kompletan skup zahtjeva na koje te izmjene mogu utjecati.
9. Nezavisnost dizajna: Trebala bi postojati opcija odabira između više alternativa dizajna za konačni sustav. Točnije, SRS ne bi trebao sadržavati nikakve pojedinosti o provedbi.
10. Ispitljivost: SRS bi trebao biti napisan na takav način da je jednostavno generirati slučajeve testiranja i planove testiranja iz izvješća.
js postavljeno
11. Razumljivo kupcu: Krajnji korisnik može biti stručnjak u svojoj eksplicitnoj domeni, ali možda nije obučen u računalnim znanostima. Stoga bi se svrha formalnih oznaka i simbola trebala izbjegavati što je više moguće. Jezik treba biti jednostavan i jasan.
12. Prava razina apstrakcije: Ako je SRS napisan za fazu zahtjeva, detalje treba eksplicitno objasniti. Dok se za studiju izvodljivosti može koristiti manje analiza. Stoga se razina apstrakcije mijenja prema cilju SRS-a.
Svojstva dobrog SRS dokumenta
Osnovna svojstva dobrog SRS dokumenta su sljedeća:
Sažet: Izvješće SRS treba biti sažeto, au isto vrijeme nedvosmisleno, dosljedno i potpuno. Opširni i nerelevantni opisi smanjuju čitljivost i također povećavaju mogućnosti pogreške.
Strukturirano: Trebao bi biti dobro strukturiran. Dobro strukturiran dokument lako je razumjeti i mijenjati. U praksi, SRS dokument prolazi kroz nekoliko revizija kako bi zadovoljio zahtjeve korisnika. Često se korisnički zahtjevi razvijaju tijekom određenog vremenskog razdoblja. Stoga je važno da izvješće bude dobro strukturirano, kako bi se izmjene SRS dokumenta učinile jednostavnima.
Prikaz crne kutije: Treba samo definirati što bi sustav trebao učiniti i suzdržati se od navođenja kako to učiniti. To znači da SRS dokument treba definirati vanjsko ponašanje sustava, a ne raspravljati o pitanjima implementacije. SRS izvješće treba promatrati sustav koji se razvija kao crnu kutiju i treba definirati izvana vidljivo ponašanje sustava. Zbog toga je SRS izvješće poznato i kao specifikacija crne kutije sustava.
Konceptualni integritet: Treba pokazati konceptualni integritet tako da ga čitatelj može samo razumjeti. Odgovor na neželjene događaje: Treba karakterizirati prihvatljive odgovore na neželjene događaje. To se naziva odgovor sustava na iznimne uvjete.
Provjerljivo: Svi zahtjevi sustava, kako je dokumentirano u SRS dokumentu, trebaju biti ispravni. To znači da bi trebalo biti moguće odlučiti jesu li zahtjevi ispunjeni ili ne u implementaciji.