Výroba fáze požadavků procesu vývoje softwaru je Specifikace softwarových požadavků (SRS) (také nazývaný a dokument požadavků ). Tato zpráva pokládá základ pro činnosti softwarového inženýrství a vzniká, když jsou získány a analyzovány veškeré požadavky. SRS je formální zpráva, která funguje jako reprezentace softwaru, která umožňuje zákazníkům zkontrolovat, zda je (SRS) v souladu s jejich požadavky. Obsahuje také uživatelské požadavky na systém a podrobné specifikace požadavků na systém.

SRS je specifikace pro konkrétní softwarový produkt, program nebo sadu aplikací, které provádějí konkrétní funkce ve specifickém prostředí. Slouží několika cílům v závislosti na tom, kdo to píše. Za prvé, SRS může být napsán klientem systému. Za druhé, SRS by mohl být napsán vývojářem systému. Tyto dvě metody vytvářejí zcela odlišné situace a stanovují zcela odlišné účely dokumentu. První případ, SRS, se používá k definování potřeb a očekávání uživatelů. Druhý případ, SRS, je napsán pro různé účely a slouží jako smluvní dokument mezi zákazníkem a vývojářem.

Charakteristika dobrého SRS

Níže jsou uvedeny vlastnosti dobrého dokumentu SRS:

1. Správnost: Uživatelská recenze se používá k zajištění přesnosti požadavků uvedených v SRS. SRS je prý perfektní, pokud pokrývá všechny potřeby, které se od systému skutečně očekávají.

2. Úplnost: SRS je kompletní tehdy a pouze tehdy, pokud obsahuje následující prvky:

(1). Všechny základní požadavky, ať už se týkají funkčnosti, výkonu, designu, omezení, atributů nebo externích rozhraní.

powershell větší nebo rovno

(2). Definice jejich reakcí softwaru na všechny realizovatelné třídy vstupních dat ve všech dostupných kategoriích situací.

Poznámka: Je nezbytné specifikovat odpovědi na platné i neplatné hodnoty.

(3). Úplné štítky a odkazy na všechny obrázky, tabulky a diagramy v SRS a definice všech termínů a měrných jednotek.

3. Konzistence: SRS je konzistentní tehdy a pouze tehdy, když v jeho konfliktu není popsána žádná podmnožina individuálních požadavků. V SRS existují tři typy možných konfliktů:

(1). Zadané charakteristiky objektů reálného světa mohou být v rozporu. Například,

(a) Formát výstupní zprávy může být v jednom požadavku popsán jako tabulkový, v jiném jako textový.

(b) Jedna podmínka může uvádět, že všechna světla musí být zelená, zatímco jiná uvádí, že všechna světla musí být modrá.

(2). Mezi dvěma specifikovanými akcemi může být rozumný nebo dočasný konflikt. Například,

(a) Jeden požadavek může určit, že program přidá dva vstupy, a jiný může určit, že je program vynásobí.

sql ddl příkazy

(b) Jedna podmínka může uvádět, že „A“ musí vždy následovat po „B“, zatímco jiná vyžaduje, aby se „A a B“ vyskytovaly současně.

(3). Dva nebo více požadavků může definovat stejný objekt reálného světa, ale pro tento objekt používají různé termíny. Například požadavek programu na vstup uživatele může být v jednom požadavku nazýván „výzva“ a v jiném „narážka“. Použití standardní terminologie a popisů podporuje konzistenci.

4. Jednoznačnost: SRS je jednoznačný, když každý pevný požadavek má pouze jeden výklad. To naznačuje, že každý prvek je interpretován jedinečně. V případě, že se používá metoda s více definicemi, měla by zpráva o požadavcích určit důsledky v SRS, aby byla jasná a snadno srozumitelná.

5. Hodnocení důležitosti a stability: SRS je hodnocen podle důležitosti a stability, pokud má každý požadavek v něm identifikátor, který označuje buď významnost nebo stabilitu tohoto konkrétního požadavku.

Obvykle nejsou všechny požadavky stejně důležité. Některé předpoklady mohou být zásadní, zejména pro životně důležité aplikace, zatímco jiné mohou být žádoucí. Každý prvek by měl být identifikován, aby byly tyto rozdíly jasné a jednoznačné. Dalším způsobem, jak seřadit požadavky, je rozlišit třídy položek na základní, podmíněné a volitelné.

6. Modifikovatelnost: SRS by měl být co možná nejpravděpodobnější a měl by být schopen do určité míry rychle získat změny v systému. Úpravy by měly být dokonale indexovány a odkazovány.

7. Ověřitelnost: SRS je správné, když lze specifikované požadavky ověřit pomocí nákladově efektivního systému pro kontrolu, zda finální software tyto požadavky splňuje. Požadavky se ověřují pomocí recenzí.

8. Sledovatelnost: SRS je vysledovatelný, pokud je jasný původ každého z požadavků a pokud usnadňuje odkazování na každý stav v dokumentaci budoucího vývoje nebo vylepšení.

Existují dva typy sledovatelnosti:

1. Zpětná sledovatelnost: To závisí na každém požadavku výslovně odkazujícím na svůj zdroj v dřívějších dokumentech.

2. Dopředná sledovatelnost: To závisí na tom, zda má každý prvek v SRS jedinečný název nebo referenční číslo.

Dopředná sledovatelnost SRS je zvláště důležitá, když softwarový produkt vstupuje do fáze provozu a údržby. Vzhledem k tomu, že se kód a návrhový dokument mění, je nutné být schopen zjistit úplný soubor požadavků, kterých se tyto úpravy mohou týkat.

9. Nezávislost designu: Pro konečný systém by měla existovat možnost výběru z více alternativ návrhu. Konkrétněji by SRS neměl obsahovat žádné podrobnosti o implementaci.

10. Testovatelnost: SRS by měl být napsán takovým způsobem, aby bylo snadné ze zprávy generovat testovací případy a testovací plány.

11. Srozumitelné pro zákazníka: Koncový uživatel může být odborníkem ve své explicitní oblasti, ale nemusí být vyškolen v počítačové vědě. Účelu formálních zápisů a symbolů by se proto mělo v co největší míře vyhnout. Jazyk by měl být jednoduchý a jasný.

12. Správná úroveň abstrakce: Pokud je SRS napsán pro fázi požadavků, měly by být podrobnosti výslovně vysvětleny. Zatímco pro studii proveditelnosti lze použít méně analýz. Úroveň abstrakce se tedy mění podle cíle SRS.

bajtů na řetězec python

Vlastnosti dobrého dokumentu SRS

Základní vlastnosti dobrého dokumentu SRS jsou následující:

Stručný: Zpráva SRS by měla být stručná a zároveň jednoznačná, konzistentní a úplná. Upovídané a irelevantní popisy snižují čitelnost a také zvyšují možnost chyb.

Strukturováno: Mělo by být dobře strukturované. Dobře strukturovaný dokument je snadno pochopitelný a upravitelný. V praxi prochází dokument SRS několika revizemi, aby se vyrovnal s požadavky uživatelů. Často se požadavky uživatelů v průběhu času vyvíjejí. Proto, aby byly úpravy dokumentu SRS snadné, je důležité, aby byla zpráva dobře strukturovaná.

Pohled na černou skříňku: Mělo by pouze definovat, co by měl systém dělat, a zdržet se uvádět, jak to má dělat. To znamená, že dokument SRS by měl definovat vnější chování systému a ne diskutovat o otázkách implementace. Zpráva SRS by měla na systém, který má být vyvinut, nahlížena jako na černou skříňku a měla by definovat chování systému viditelné zvenčí. Z tohoto důvodu je zpráva SRS také známá jako specifikace černé skříňky systému.

Koncepční integrita: Měla by vykazovat koncepční integritu, aby ji čtenář mohl pouze pochopit. Reakce na nežádoucí události: Měla by charakterizovat přijatelné reakce na nežádoucí události. Tyto se nazývají reakce systému na výjimečné podmínky.

Ověřitelný: Všechny požadavky systému, jak jsou dokumentovány v dokumentu SRS, by měly být správné. To znamená, že by mělo být možné rozhodnout, zda byly požadavky při implementaci splněny či nikoli.