Předtím jsme probrali 4 hlavní činnosti inženýrství požadavků.

Inženýrství požadavků je proces shromažďování a definování toho, jaké služby by měl systém poskytovat.

Zaměřuje se na posouzení, zda je systém pro podnik užitečný (studie proveditelnosti), zjištění požadavků (elicitation a analýza), převedení těchto požadavků do určitého standardního formátu (specifikace) a kontrolu, zda požadavky definují systém, který zákazník chce (validace).

V praxi není inženýrství požadavků sekvenční proces, je to iterativní proces, ve kterém se činnosti prolínají.

Například nejprve iterujete na uživatelské požadavky; elicitaci, specifikaci a validaci a stejné kroky opakujete pro systémové požadavky.

Na začátku procesu bude většina úsilí vynaložena na pochopení obchodní úrovně a uživatelských požadavků. Později v procesu bude více úsilí vynaloženo na elicitaci a pochopení detailních požadavků na systém.

Někteří lidé považují inženýrství požadavků za proces aplikace metody strukturované analýzy, například objektově orientované analýzy. To zahrnuje analýzu systému a vytvoření sady grafických modelů systému, jako jsou modely případů užití, které pak slouží jako specifikace systému.

Ačkoli strukturované metody hrají v procesu inženýrství požadavků určitou roli, je toho mnohem více, než co tyto metody pokrývají.

Objektově orientovanou analýzou a návrhem se budeme zabývat v další sérii výukových materiálů.

Požadavky na uživatele a systém

Typicky jsou požadavky prezentovány do dvou úrovní podrobnosti; uživatelské a systémové požadavky, přičemž uživatelé potřebují vysokoúrovňové vyjádření požadavků, zatímco vývojáři systému potřebují podrobnější specifikaci systému. Uživatelské a systémové požadavky tedy pouze odkazují na různou úroveň podrobnosti.

Různá úroveň podrobnosti je užitečná, protože sděluje informace o vyvíjeném systému pro různé typy čtenářů.

Takže koncoví uživatelé se nebudou zabývat detaily, potřebují obecný, abstrahovaný písemný požadavek.

Proti tomu lidé, kteří se podílejí na vývoji, potřebují, co přesně by měl systém dělat.

Pravděpodobně skončíte se spoustou problémů a nedorozumění, pokud jste neměli jasně oddělené různé úrovně detailů.

Požadavky uživatele

Popisuje služby, které by měl systém poskytovat, a omezení, za kterých musí fungovat. Neočekáváme, že uvidíme nějakou úroveň podrobnosti nebo co přesně bude systém dělat, Jedná se spíše o obecné požadavky.

Obvykle se píší v přirozeném jazyce a dodávají se pomocí diagramů.

Různé způsoby specifikace požadavků probereme později v tomto seriálu.

Požadavky na systém

Požadavky na systém znamenají podrobnější popis systémových služeb a provozních omezení, například jak se bude systém používat, a vývojových omezení, například programovacích jazyků.

Tuto úroveň podrobnosti potřebují ti, kteří se podílejí na vývoji systému, jako jsou inženýři, systémoví architekti, testeři atd.

Funkční &Nefunkční požadavky

Požadavky na software se dělí na funkční požadavky a nefunkční požadavky.

Funkční požadavky

Pokrývají hlavní funkce, které by měl systém poskytovat. Pokud jsou vyjádřeny jako uživatelské požadavky, jsou obvykle popsány abstraktním způsobem.

Konkrétnější funkční požadavky na systém však popisují funkce systému, jeho vstupy, zpracování; jak bude reagovat na určitý vstup a jaký je očekávaný výstup.

Nefunkční požadavky

Jsou to omezení funkcí poskytovaných systémem.

Omezení, jako kolik procesů systém zvládne (výkon), jaké jsou (bezpečnostní) problémy, o které se systém musí postarat, například SQL injections …

Míra selhání (spolehlivost), jaké jazyky a nástroje se budou používat (vývoj), jaká pravidla je třeba dodržovat, aby systém fungoval v rámci zákonů organizace (legislativní).

Nofunkční požadavky jsou často kritičtější než jednotlivé funkční požadavky. Uživatelé obvykle najdou způsob, jak obejít funkci systému, která ve skutečnosti nesplňuje jejich potřeby. Nesplnění nefunkčního požadavku však může znamenat nepoužitelnost celého systému.

Například pokud letadlo nebude znamenat splnění požadavků na spolehlivost, nebude bezpečné pro provoz, nebo pokud vestavěný řídicí systém nesplní požadavky na výkon, nebudou řídicí funkce fungovat správně.

Nefunkční požadavky by měly být měřitelné

Kdykoli je to možné, měli bychom nefunkční požadavky psát kvantitativně, aby je bylo možné testovat. Lze je měřit při testování systému, aby se ověřilo, zda systém splňuje své nefunkční požadavky.

V praxi je pro zákazníky systému často obtížné převést své cíle do měřitelných požadavků. Nechápou, co znamená nějaké číslo definující požadovanou rychlost nebo spolehlivost. Pro některé cíle, například udržovatelnost, neexistují žádné metriky, které by bylo možné použít.

Náklady na ověření měřitelných nefunkčních požadavků mohou být velmi vysoké a zákazníci si nemusí myslet, že tyto náklady jsou oprávněné.

Nefunkční a funkční požadavky jsou závislé

Nefunkční požadavky jsou často v rozporu, vzájemně se ovlivňují nebo dokonce generují další funkční nebo nefunkční požadavky.

Požadavek uživatele týkající se bezpečnosti, například omezení přístupu oprávněným uživatelům, může generovat jiné požadavky, které jsou funkční, například potřebu zahrnout do systému prostředky pro ověřování uživatelů.

Rozlišení funkčních a nefunkčních požadavků

V praxi je obtížné oddělit funkční a nefunkční požadavky. Rozlišení není jasné, jak naznačují jejich definice.

Oddělení funkčních a nefunkčních požadavků

Jsou-li nefunkční požadavky uvedeny odděleně od funkčních požadavků, může být vztah mezi nimi obtížně pochopitelný.

Měli bychom však výslovně zdůraznit požadavky, které jasně souvisejí s emergentními vlastnostmi systému, jako je výkonnost nebo spolehlivost.

Emergentní vlastnosti jsou spíše vlastnosti systému jako celku než vlastnosti, které lze odvodit z vlastností jednotlivých součástí systému.

.