navigation
hledat
Rozdíly
Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
|
statnice:oi_si_okruh1_pozadavky_reseni [2011/05/11 11:53] mephisto007 |
statnice:oi_si_okruh1_pozadavky_reseni [2025/01/03 18:23] (aktuální) |
||
|---|---|---|---|
| Řádek 14: | Řádek 14: | ||
| ==== Definice požadavků ==== | ==== Definice požadavků ==== | ||
| - | |||
| - | |||
| * Požadavek lze definovat jako “specifikaci toho, co by mělo být implementováno”. | * Požadavek lze definovat jako “specifikaci toho, co by mělo být implementováno”. | ||
| * Rozlišují se dva typy požadavků: | * Rozlišují se dva typy požadavků: | ||
| Řádek 21: | Řádek 19: | ||
| * Nefunkční požadavky, které určují vlastnosti nebo omezující podmínky, kladené na daný systém. | * Nefunkční požadavky, které určují vlastnosti nebo omezující podmínky, kladené na daný systém. | ||
| * Požadavky jsou základem systému, neboť jsou vyjádřením toho, CO by měl systém dělat, nikoli však způsobu, JAK toho docílit. | * Požadavky jsou základem systému, neboť jsou vyjádřením toho, CO by měl systém dělat, nikoli však způsobu, JAK toho docílit. | ||
| - | * Požadavky je vhodné uspořádat do taxonomie. Nejjedndnoušší rozdělení požadavků je na funkční a nefunkční. Lze je však dále jemněji uspořádávat do kategorií, které závisí na typu vyvíjeného softwaru. K těmto účelům je velmi užitečné použít nástroj pro správu požadavků. | + | * Požadavky je vhodné uspořádat do taxonomie (FURPS - functionality, usability, reliability, performance, supportability). Nejjednodušší rozdělení požadavků je na funkční a nefunkční. Lze je však dále jemněji uspořádávat do kategorií, které závisí na typu vyvíjeného softwaru. K těmto účelům je velmi užitečné použít nástroj pro správu požadavků. |
| + | * Na základě požadavků dochází k vypracování Use Case pro systémy, kde to má smysl (interakce s uživateli) a analýzy. | ||
| + | |||
| + | === Chyby při sběru požadavků === | ||
| + | * špatně vyhodnocené požadavky | ||
| + | * nepřesné požadavky | ||
| + | * neúplné požadavky | ||
| + | * navzájem si odporující požadavky | ||
| + | * nevyřčené, ale přesto očekávané požadavky | ||
| + | * přehnané požadavky | ||
| + | * obtížně verifikovatelné (nekvantitativní) požadavky – např. systém bude potřebovat málo paměti | ||
| + | * nedostatečné zapojení zákazníka a uživatelů do procesu získávání požadavků | ||
| + | * chybějící priorita | ||
| + | * vytváření něčeho, co nikdo nechtěl | ||
| + | * specifikace není v systému pro správu verzí | ||
| + | * nedefinovaný proces změnových řízení | ||
| === Funkční požadavky === | === Funkční požadavky === | ||
| Řádek 30: | Řádek 43: | ||
| * Funkčními požadavky mohou být výpočty, manipulace s daty a jejich zpracování či jiné specifické operace, které by systém měl být schopen splnit. | * Funkčními požadavky mohou být výpočty, manipulace s daty a jejich zpracování či jiné specifické operace, které by systém měl být schopen splnit. | ||
| * Formulace funkčního požadavku má typicky následující podobu: | * Formulace funkčního požadavku má typicky následující podobu: | ||
| - | * <ID> <název systému> bude dělat <popis funkce> | + | * <ID> <název systému> musí/může/nesmí <popis funkce> |
| * Plán implementace funkčních požadavků je upřesněn ve fázi návrhu systému. | * Plán implementace funkčních požadavků je upřesněn ve fázi návrhu systému. | ||
| - | + | ||
| === Nefunkční požadavky === | === Nefunkční požadavky === | ||
| Řádek 39: | Řádek 52: | ||
| * Kladou specifická omezení a vlastnosti na systém jako celek, jeho návrh a vývoj. | * Kladou specifická omezení a vlastnosti na systém jako celek, jeho návrh a vývoj. | ||
| * Formulace nefunkčního požadavku má typicky následující podobu: | * Formulace nefunkčního požadavku má typicky následující podobu: | ||
| - | * <ID> <název systému> bude <popis vlastnosti / omezení> | + | * <ID> <název systému> musí/může/nesmí <popis vlastnosti / omezení> |
| * Plán implementace nefunkčních požadavků je upřesněn v architektuře systému. | * Plán implementace nefunkčních požadavků je upřesněn v architektuře systému. | ||
| + | * Definuje, za jakých okolností bude systém pracovat. | ||
| == Některé kategorie nefunkčních požadavků == | == Některé kategorie nefunkčních požadavků == | ||
| Řádek 50: | Řádek 64: | ||
| * Bezpečnost - vyjadřuje stupeň ochrany vůči nebezpečí, škodám, ztrátě a kriminálním aktivitám. | * Bezpečnost - vyjadřuje stupeň ochrany vůči nebezpečí, škodám, ztrátě a kriminálním aktivitám. | ||
| * Shoda se standardy | * Shoda se standardy | ||
| + | * integrace s jinými systémy | ||
| + | * formát vstupních a výstupních dat | ||
| + | * běhové prostředí (OS, verze Javy, verze DB) | ||
| + | * použité technologie | ||
| + | * komunikace s jinými systémy | ||
| === Specifikace systémových požadavků === | === Specifikace systémových požadavků === | ||
| Řádek 81: | Řádek 100: | ||
| * Požadavky na databáze | * Požadavky na databáze | ||
| * Omezení návrhu | * Omezení návrhu | ||
| + | |||
| + | ==== Use Case ==== | ||
| + | Případy užití sestávají z Use case text a Use case diagrams. UCT je v podstatě scénář uživatelské akce. | ||
| + | |||
| + | **Pojmy k UCD:** | ||
| + | * vazby include a extend | ||
| + | * actors a jejich hierarchie | ||
| + | * hranice systému | ||
| + | |||
| + | **Struktura UCT:** | ||
| + | * pritorita | ||
| + | * preconditions a postconditions | ||
| + | * tok hlavního scénáře a rozvětvení (klíčová slova if, for, else) | ||
| + | * alternativní scénáře | ||
| ===== Zdroje informací ===== | ===== Zdroje informací ===== | ||
