Výroba fázy požiadaviek procesu vývoja softvéru je Špecifikácie softvérových požiadaviek (SRS) (nazývaný aj a dokument s požiadavkami ). Táto správa predstavuje základ pre aktivity softvérového inžinierstva a vytvára sa vtedy, keď sa získajú a analyzujú všetky požiadavky. SRS je formálna správa, ktorá funguje ako reprezentácia softvéru, ktorá umožňuje zákazníkom posúdiť, či je (SRS) v súlade s ich požiadavkami. Obsahuje tiež požiadavky používateľov na systém, ako aj podrobné špecifikácie systémových požiadaviek.

SRS je špecifikácia špecifického softvérového produktu, programu alebo súboru aplikácií, ktoré vykonávajú konkrétne funkcie v špecifickom prostredí. Slúži viacerým cieľom v závislosti od toho, kto ju píše. Po prvé, SRS by mohol napísať klient systému. Po druhé, SRS by mohol napísať vývojár systému. Tieto dve metódy vytvárajú úplne odlišné situácie a stanovujú úplne odlišné účely dokumentu. Prvý prípad, SRS, sa používa na definovanie potrieb a očakávaní používateľov. Druhý prípad, SRS, je napísaný na rôzne účely a slúži ako zmluvný dokument medzi zákazníkom a vývojárom.

Charakteristika dobrého SRS

Nasledujú vlastnosti dobrého dokumentu SRS:

1. Správnosť: Používateľská recenzia sa používa na zabezpečenie presnosti požiadaviek uvedených v SRS. SRS je vraj dokonalé, ak pokrýva všetky potreby, ktoré sa od systému skutočne očakávajú.

2. Úplnosť: SRS je úplná vtedy a len vtedy, ak obsahuje tieto prvky:

(1). Všetky základné požiadavky, či už sa týkajú funkčnosti, výkonu, dizajnu, obmedzení, atribútov alebo externých rozhraní.

anonymná funkcia java

(2). Definícia ich reakcií softvéru na všetky realizovateľné triedy vstupných údajov vo všetkých dostupných kategóriách situácií.

Poznámka: Je nevyhnutné špecifikovať odpovede na platné aj neplatné hodnoty.

(3). Úplné označenia a odkazy na všetky obrázky, tabuľky a diagramy v SRS a definície všetkých termínov a merných jednotiek.

3. Konzistencia: SRS je konzistentný vtedy a len vtedy, ak v jeho konflikte nie je opísaná žiadna podskupina individuálnych požiadaviek. V SRS existujú tri typy možných konfliktov:

(1). Špecifikované charakteristiky objektov reálneho sveta môžu byť v konflikte. Napríklad,

a) Formát výstupnej správy môže byť v jednej požiadavke opísaný ako tabuľkový, ale v inej ako textový.

(b) Jedna podmienka môže uvádzať, že všetky svetlá budú zelené, zatiaľ čo iná uvádza, že všetky svetlá budú modré.

(2). Medzi týmito dvoma špecifikovanými činnosťami môže byť primeraný alebo dočasný konflikt. Napríklad,

(a) Jedna požiadavka môže určiť, že program pridá dva vstupy, a iná môže určiť, že program ich znásobí.

b) Jedna podmienka môže uvádzať, že „A“ musí vždy nasledovať za „B“, zatiaľ čo iná vyžaduje, aby sa „A a B“ vyskytovali súčasne.

(3). Dve alebo viaceré požiadavky môžu definovať ten istý objekt reálneho sveta, ale pre tento objekt používajú rôzne výrazy. Napríklad požiadavka programu na užívateľský vstup sa môže nazývať „výzva“ v jednej požiadavke a „narážka“ v inej. Používanie štandardnej terminológie a popisov podporuje konzistentnosť.

4. Jednoznačnosť: SRS je jednoznačná, keď každá pevná požiadavka má iba jeden výklad. To naznačuje, že každý prvok je jedinečne interpretovaný. V prípade, že sa používa metóda s viacerými definíciami, v správe o požiadavkách by sa mali určiť dôsledky v SRS, aby bola jasná a ľahko pochopiteľná.

5. Poradie dôležitosti a stability: SRS sa hodnotí podľa dôležitosti a stability, ak má každá požiadavka v ňom identifikátor, ktorý označuje význam alebo stabilitu danej konkrétnej požiadavky.

Zvyčajne nie sú všetky požiadavky rovnako dôležité. Niektoré predpoklady môžu byť nevyhnutné, najmä pre životne dôležité aplikácie, zatiaľ čo iné môžu byť žiaduce. Každý prvok by mal byť identifikovaný, aby boli tieto rozdiely jasné a jednoznačné. Ďalším spôsobom, ako zoradiť požiadavky, je rozlišovať triedy položiek ako nevyhnutné, podmienené a voliteľné.

6. Modifikovateľnosť: SRS by malo byť čo najpravdepodobnejšie modifikovateľné a malo by byť schopné do určitej miery rýchlo získať zmeny v systéme. Úpravy by mali byť dokonale indexované a krížové.

7. Overiteľnosť: SRS je správny, keď je možné špecifikované požiadavky overiť pomocou nákladovo efektívneho systému, aby sa skontrolovalo, či konečný softvér spĺňa tieto požiadavky. Požiadavky sa overujú pomocou recenzií.

8. Sledovateľnosť: SRS je vysledovateľná, ak je jasný pôvod každej požiadavky a ak uľahčuje odkazovanie na každú podmienku v dokumentácii budúceho vývoja alebo vylepšenia.

Existujú dva typy sledovateľnosti:

linuxové skratky

1. Spätná sledovateľnosť: Závisí to od každej požiadavky, ktorá explicitne odkazuje na svoj zdroj v predchádzajúcich dokumentoch.

2. Dopredná sledovateľnosť: Závisí to od toho, či má každý prvok v SRS jedinečný názov alebo referenčné číslo.

pothineni baran

Dopredná sledovateľnosť SRS je obzvlášť dôležitá, keď softvérový produkt vstupuje do fázy prevádzky a údržby. Keďže sa kódový a konštrukčný dokument mení, je potrebné vedieť zistiť úplný súbor požiadaviek, ktorých sa tieto úpravy môžu týkať.

9. Nezávislosť dizajnu: Pre konečný systém by mala existovať možnosť výberu z viacerých alternatív dizajnu. Konkrétnejšie, SRS by nemala obsahovať žiadne podrobnosti o implementácii.

10. Testovateľnosť: SRS by mal byť napísaný takou metódou, aby bolo možné zo správy jednoducho generovať testovacie prípady a testovacie plány.

11. Zrozumiteľné pre zákazníka: Koncový používateľ môže byť odborníkom vo svojej explicitnej oblasti, ale nemusí byť vyškolený v počítačovej vede. Preto by sa malo v maximálnej možnej miere vyhnúť účelu formálnych zápisov a symbolov. Jazyk by mal byť jednoduchý a jasný.

12. Správna úroveň abstrakcie: Ak je SRS napísaná pre fázu požiadaviek, podrobnosti by sa mali explicitne vysvetliť. Zatiaľ čo pre štúdiu uskutočniteľnosti je možné použiť menej analýz. Úroveň abstrakcie sa teda mení podľa cieľa SRS.

Vlastnosti dobrého dokumentu SRS

Základné vlastnosti dobrého dokumentu SRS sú nasledovné:

Stručný: Správa SRS by mala byť stručná a zároveň jednoznačná, konzistentná a úplná. Podrobné a irelevantné popisy znižujú čitateľnosť a tiež zvyšujú možnosti chýb.

Štruktúrované: Mal by byť dobre štruktúrovaný. Dobre štruktúrovaný dokument je jednoduchý na pochopenie a úpravu. V praxi prechádza dokument SRS niekoľkými revíziami, aby sa vyrovnali s požiadavkami používateľov. Požiadavky používateľov sa často vyvíjajú v priebehu času. Preto, aby boli úpravy dokumentu SRS jednoduché, je nevyhnutné, aby bola správa dobre štruktúrovaná.

Pohľad na čiernu skrinku: Mala by len definovať, čo má systém robiť, a zdržať sa uvádzania, ako to má robiť. To znamená, že dokument SRS by mal definovať vonkajšie správanie systému a nie diskutovať o otázkach implementácie. Správa SRS by mala vnímať systém, ktorý sa má vyvinúť, ako čiernu skrinku a mala by definovať externe viditeľné správanie systému. Z tohto dôvodu je správa SRS známa aj ako špecifikácia systému v čiernej skrinke.

Koncepčná integrita: Mala by vykazovať koncepčnú integritu, aby jej čitateľ mohol iba porozumieť. Reakcia na nežiaduce udalosti: Mala by charakterizovať prijateľné reakcie na nežiaduce udalosti. Tieto sa nazývajú odozva systému na výnimočné podmienky.

Overiteľné: Všetky požiadavky systému, ako sú zdokumentované v dokumente SRS, by mali byť správne. To znamená, že by malo byť možné rozhodnúť, či boli alebo neboli pri implementácii splnené požiadavky.