Správa požadavků

Získávání, analýza a modelování požadavků, katalog požadavků, funkční a nefunkční požadavky.

Předmět Softwarové inženýrství 1.

Literatura:           Arlow, J., Neustat, I.: UML 2 a unifikovaný proces vývoje aplikací. Computer Press, Praha 2007.

Požadavek lze definovat jako “specifikaci toho, co by mělo být implementováno”. V podstatě rozlišujeme dva typy požadavků:

·         Funkční požadavky jež určují, jaké chování bude systém nabízet

·         Nefunkční požadavky, které specifikují vlastnosti nebo omezující podmínky daného systému

Požadavky jsou základem všech systému. (nebo by alespoň měli být). Jsou v podstatě vyjádřením toho, co by měl system dělat. Požadavky by měly být jediným vyjádřením, co by měl system dělat, nikoli toho, jak by to měl dělat. To je nesmírně důležitý rozdíl. Můžeme určit, co by měl system dělat a jaké chování by měl poskytovat, aniž bychom cokoli říkali o způsobu, jak bude dané funkce dosaženo.

Teoreticky je rozdělení toho, “co”, od toho, “jak” velmi lákavé. V praxi se ovšem setkáváme s problémem, že množina požadavků (označovaná jako specifikace systémových požadavků) nebo jen specifikace požadavků se bude snažit o smíchání obou aspektů. Z části je příčinou fakt, že je snažší porozumět popisu implementace než abstraktnímu vyjádření problému. Zčásti je příčinou skutečnost, že mohou existovat implementační omezení, která předurčují aspect “jak” vznikajícího systému.

Získávání

Kdykoliv při zachycení požadavků na softwarový projekt pracujete s lidmi, snažíme se jejich prostřednictvím získat co nejpřesnější obraz nebo mapu jejich pracovního modelu.

Nutno projít tři procesy:

1.      Vyřazením, kdy je informace odfiltrována

2.      Deformací, kdy je informace upravena souvisejícími mechanismy tvorby a halucinace

3.      Zobecněním, kdy dochází k tvorbě pravidel, víry zásad týkajících se pravdy a klamu.

Tyto selektivní rysy jsou mechanizmem utvářejícím přirozené jazyky. Je důležité o nich vědět – především tehdy, snažímeli se o co nejpodrobnější zachycení požadavků a o jejich co nejdůkladnější  analýzu. Můžeme totiž potřebovat jejich aktivní označení a vybídnutí k obnvení informace.

Prostředí, v němž je hovor veden může mít rovněž velký vliv na kvalitu získaných informací. Nejlepšími pomůckami pro zachycení informací během rozhovoru jsou pero a papír.

funkční a nefunkční požadavky

Požadavky se vyplatí rozdělit na funkční a nefunkční. Existuje mnoha dalších metod jejich kategorizace.

Funkčním požadavkem je formulace toho, co by měl systém dělat – popisuje požadovanou funkci systému. Pokud například shromažďujete požadavky objevit i takovéto:

1.      Bankomat bude ověřovat validitu vložené platební karty

2.      Bankomat bude ověřovat validitu zákazníkem zadaného kódu PIN

3.      Bankomat vydá na každou kartu maximálně 1000 Kč za 24 hodin

Nefunkční požadavek je omezující podmínka uvalená na daný system. Zůstaneme-li ještě na chvíli u bankomatu, mohly by se v seznamu nefunkčních požadavků objevit I následující:

1.      Řídící system bankomatu bude napsán v jazuce C++

2.      Řídící systém bankomatu bude s bankou komunikovat zabezpečeným kanálem

3.      Řídící systém bankomatu ověří validitu platební karty maximálně do tří sekund

Z uvedeného sesznamu vyplívá, že nefunkční požadavky specifikují, nebo spíše omezují způsob, jimž bude system implementován.

Uspořádání požadavků na základě typu je užitečné, zejména pracujete-li s mnoha požadavky (máte-li jich například více než 100). Obzvláště užitečné je v případě, používate-li nástroj pro řízení požadavků. Umožňuje totiž získání užitečných informací pomocí dotazů koncipovaných pro model požadavků.

Funkční požadavky

·         Zákazníci

·         Produkty

·         Objednávky

·         Prodejní kanály

·         Platby

Nefunkční požadavky

·         Výkon

·         Kapacita

·         Dostupnost

·         Shoda se standardy

Vaše hiearchie typů požadavků může jít v podstatě do libovolné hloubky. V praxi si obvykle vystačíme se dvěmi až třemi úrovněmi, ledaže byste pracovali na velice složitém systému.