Požadavky na software – typy požadavků, formy popisu, úrovně detailu a jejich vztah k procesu vývoje.

Požadavky na software – typy požadavků, formy popisu, úrovně detailu a jejich vztah k procesu vývoje.

Požadavek = schopnost nebo vlastnost, kterou by měl výsledný produkt mít

Požadavkem není to, co uživatel nepotřebuje

Typy požadavků:

Funkční požadavky

Popisují funkce nebo služby, které jsou od systému očekávány

Mimofunkční požadavky

Neméně důležité, např. požadavky na spolehlivost systému, rychlost odezvy, dané vnějšími faktory – legislativa…

Business požadavky

Cena, vize, rozsah projektu, smluvní záležitosti…

Způsoby formulace požadavku

Slovně, formou pár vět

Uživatelská příručka

Úrovně detailu:

Na začátku jsou požadavky spíše obecné, časem s postupem projektu se zpřesňují

Konečný výsledek analýzy požadavků

Zahrnuje případy užití zahrnující všechny případy interakce uživatele se software

Pouze externí chování z pohledu uživatele

Technický dokument, oficiální vyjádření o tom, co se od produktu očekává

Jednoznačnost, srozumitelnost, modifikovatelnost, snadné úpravy, formálnost – specifikuje CO udělat NE JAK to dělat

 Co je to požadavek? 

požadavek = schopnost nebo vlastnost, kterou má sw mít, aby jej uživatel mohl použít k vyřešení problému nebo dosažení cíle, který vedl k zadání, nebo aby splnil podmínky stanovené smlouvou, standardem nebo jinou specifikací. 

vlastnosti požadavku: úplný, bezesporný 

požadavkem není to, co uživatel nepotřebuje 

Typy požadavků 

Funkční požadavky = funkce 

popisují funkce nebo služby, které jsou od systému očekávány 

příklady: požadavky na univerzitní knihovní systém 

Mimofunkční požadavky = vlastnosti

netýkají se funkcí systému, ale vlastností jako je spolehlivost, čas odpovědi, obsazené místo na disku nebo v paměti, aj. 

často kritičtější než jednotlivé funkční požadavky (např. pokud je řídící systém letadla nespolehlivý, je nepoužitelný) 

někdy dané vnějšími faktory, tj. legislativní požadavky (př. zákon na ochranu osobních údajů apod.) 

př. veškerá komunikace mezi uživatelem a systémem by měla být vyjádřitelná ve znakové sadě ISO 8859-2 

Business požadavky 

Smluvní záležitosti 

Právní a další 

Např. různé právní systémy dvou zemí a cloud 

Způsob formulace požadavku

uživatelská specifikace 

vysokoúrovňový popis funkčních a mimofunkčních požadavků zákazníka 

musí být srozumitelné pro uživatele, kteří nemají technické znalosti 

podrobnější specifikace uživatelských požadavků pro vývojáře 

slouží jako výchozí bod pro design systému  

grafické vyjádření 

popis ve formě prototypu a uživatelské příručky 

Úrovně detailu v rámci procesu vývoje 

Zahájení projektu: strategické, klíčové, obrysy 

Úroveň detailu a agilní metodiky

Cíl: zachytit věci v danou chvíli nejpodstatnější (viz Manifest), detaily se dohodnou až bude potřeba

S každou iterací zpřesnění

Dokument specifikace požadavků (DSP) 

konečný výsledek analýzy požadavků 

zahrnuje případy užití popisující všechny interakce uživatele se SW -- funkční požadavky 

technický dokument, oficiální vyjádření o tom, co se od vyvíjeného systému očekává (dohoda mezi zákazníkem a dodavatelem, co má zadaný sw dělat a jak to má vypadat) 

základ pro pozdější ověření správnosti - důraz na jednoznačnost, ověřitelnost, reálnost, srozumitelnost, úplnost, přesnost a správnost, modifikovatelnost, konzistenci 

měl by specifikovat pouze externí chování systému, tj. snaha vyloučit design z DSP 

strukturován tak, aby v něm bylo snadné provádět změny (modifikovatelnost) 

měl by specifikovat omezení implementace – mimofunkční požadavky 

měl by charakterizovat přijatelné odpovědi na nežádoucí události 

Jednodušeji: 

Jednoznačnost, úplnost, srozumitelnost, modifikovatelnost, přesnost, ověřitelnost, reálnost, specifikace pouze chování - NE jak to udělat 
