Softwarové požadavky - sada požadavků / prohlášení týkajících se atributů, vlastností nebo kvalit softwarového systému , který má být implementován. V procesu zpracování (analýzy a syntézy) vznikají úkoly pro vývoj/modernizaci softwaru (SW).
Požadavky mohou být vyjádřeny formou textových prohlášení a grafických modelů.
V klasickém technickém přístupu se ve fázi návrhu softwaru používá soubor požadavků. Požadavky se také používají v procesu ověřování softwaru, protože testy vycházejí z požadavků.
Fázi vývoje požadavků může předcházet studie proveditelnosti nebo fáze analýzy koncepčního návrhu. Fáze vývoje požadavků lze rozdělit na identifikaci požadavků (shromažďování, pochopení, zvažování a zjišťování potřeb zainteresovaných stran), analýzu (kontrola integrity a úplnosti), specifikaci (požadavky na dokumentaci - syntéza textových a grafických modelů) a validaci.
Charakteristiky požadavků na kvalitu jsou různými zdroji definovány odlišně. Následující charakteristiky jsou však obecně uznávány :
| Charakteristický | Vysvětlení |
|---|---|
| Jedinečnost | Požadavek popisuje jednu jedinou věc. |
| úplnost | Požadavek je plně definován na jednom místě a jsou k dispozici všechny potřebné informace. |
| Subsekvence | Požadavek není v rozporu s ostatními požadavky a je plně v souladu s externí dokumentací. |
| Atomicita | Požadavek je „atomový“. To znamená, že jej nelze bez ztráty úplnosti rozložit na řadu podrobnějších požadavků. |
| Sledovatelnost | Požadavek plně nebo částečně splňuje obchodní potřeby, jak je uvedeno zúčastněnými stranami a zdokumentováno. |
| Relevantnost | Požadavek se časem nestal zastaralým. |
| Proveditelnost | Požadavek lze realizovat v rámci projektu. |
| jednoznačnost | Požadavek je stručně definován bez použití technického žargonu, akronymů nebo jiného skrytého jazyka. Vyjadřuje objektivní fakta, nikoli subjektivní názory. Je možný jeden a pouze jeden výklad. Definice neobsahuje fuzzy fráze. Použití negativních tvrzení a složených tvrzení je zakázáno. |
| povinný | Požadavek představuje charakteristiku definovanou zainteresovanou stranou, jejíž absence povede k podřadnosti řešení, kterou nelze ignorovat. Nepovinný požadavek je rozpor v samotném pojetí požadavku. |
| Ověřitelnost | Proveditelnost požadavku může být stanovena jednou ze čtyř možných metod: inspekce, demonstrace, test nebo analýza. |
Všechny nároky musí být ověřitelné. Nejběžnější ověřovací technikou jsou testy. Pokud ověření pomocí zkoušek není možné, měla by být použita jiná metoda ověření (analýza, demonstrace, kontrola nebo přezkoumání návrhu).
Některé požadavky jsou ze své podstaty neověřitelné. Zahrnují požadavky, které říkají, že systém nikdy nebo vždy nesmí zobrazovat konkrétní vlastnost. Správné testování těchto požadavků by vyžadovalo nekonečný testovací cyklus. Tyto požadavky by měly být předefinovány, aby byly ověřitelné. Jak je uvedeno výše, všechny požadavky musí být ověřitelné.
Nefunkční požadavky, které nejsou programově ověřitelné, by měly být stále zachovány jako dokumentace záměru klienta. Takové požadavky na produkt lze převést na požadavky na proces. Například nefunkční požadavek, aby software neobsahoval „tajné pasáže“, lze uspokojit jeho nahrazením požadavkem na použití párového programování. Složité požadavky na bezpečnost leteckého softwaru lze splnit dodržením vývojového procesu DO-178B .
Při vypracovávání požadavků často vznikají problémy s nejednoznačností, neúplností a nejednotností jednotlivých požadavků. Odstranění těchto problémů ve fázi vývoje požadavků stojí o několik řádů méně než řešení stejných problémů v pozdějších fázích vývoje. K vyřešení a odstranění těchto problémů existuje proces vývoje požadavků.
Při vývoji požadavků existuje technický kompromis mezi požadavky, které jsou příliš vágní, a požadavky, které jsou tak podrobné, že:
Požadavky se obvykle používají jako prostředek komunikace mezi různými zúčastněnými stranami. To znamená, že požadavky by měly být jednoduché a srozumitelné pro běžné uživatele i vývojáře.
Softwarová specifikace je často označována jako technická specifikace .
Nejčastěji v ruské praxi je za vytvoření specifikace softwaru zodpovědný systémový analytik , někdy obchodní analytik .
Pro grafické modely požadavků byly použity historické diagramy nebo metodologie grafického modelování: ER (IDEF1FX), IDEF0 , IDEF3 , DFD , UML , OCL , SysML , ARIS ( eEPC , VAD ).
Obecně se požadavky v průběhu času mění. Jakmile jsou požadavky definovány a schváleny, měly by změny podléhat kontrole změn. U mnoha projektů se požadavky mění před dokončením systému. Částečně je to způsobeno složitostí softwaru a tím, že uživatelé nevědí, co skutečně potřebují. Tato vlastnost požadavků dala vzniknout procesu řízení požadavků .
| Vývoj softwaru | |
|---|---|
| Proces | |
Koncepty na vysoké úrovni | |
| Pokyny |
|
Vývojové metodiky | |
| Modelky |
|
| Pozoruhodné postavy |
|