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/22 15:55] pajamrazek |
statnice:oi_si_okruh1_pozadavky_reseni [2025/01/03 18:23] (aktuální) |
||
|---|---|---|---|
| Řádek 19: | Řá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. 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ů. | + | * 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. | * 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. | ||
| Řádek 43: | Řá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 52: | Řá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. | * Definuje, za jakých okolností bude systém pracovat. | ||
| Řádek 100: | Řá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í ===== | ||
