Postupy pro sběr požadavků.

Problematická a ošemetná to záležitost: 

Uživatelé nerozumí tomu, co chtějí, nebo uživatelé nemají jasnou představu o svých požadavcích 

Uživatelé neschválí seznam sepsaných požadavku jako finální 

Uživatelé trvají na nových požadavcích i po zafixovaní nákladů a časového harmonogramu 

Komunikace s uživateli je pomalá 

Uživatelé se často nepodílejí na kontrolách, nebo jsou neschopní to udělat 

Uživatelé jsou technicky nevzdělaní 

Uživatelé nerozumí procesu vývoje 

Uživatelé neví o současné technologii 

Je potřeba předem počítat s různou úrovní počítačové gramotnosti. To může vést k situaci, kdy uživatelé průběžně mění své požadavky, i když systém nebo vývoj produktu byl zahájen. 

Způsoby sběru požadavků 

Hlášení problémů

Konkurenční systémy

předem připravený rozhovor, který vede moderátor (klade otázky, dává slovo) 

nedoporučuje se více než 2 hodiny 

předem si připravit scénář, které okruhy se budou probírat, v jakém pořadí, scénář se snažit nenásilně dodržovat 

pozorování, práce s uživateli 

pozorování prací u zákazníka (účast analytiků) 

vhodnými otázkami zjistíme od uživatelů, co potřebují 

prototypování – tvorba prototypů, podle kterých si zákazník ujasní své požadavky 

stačí na papír nebo skutečné programové prototypy 

studium hlášení problémů 

Způsoby vyjádření 

přirozený jazyk 

výhodou je srozumitelnost pro uživatele 

nevýhodou – spoléhá se na to, že autoři používají stejná slova pro stejný koncept (stejná věc se dá říci mnoha různými způsoby). Obtížná modularizace - kterých všech dalších požadavků se změna dotkne. 

formuláře 

pro vyjádření požadavku se nadefinuje jeden nebo více typů formulářů 

měl by obsahovat: 

popis vstupů, odkud se berou 

popis výstupů, kam putují 

jaké další entity specifikovaná funkce nebo entita používá 

případné pre/post conditions (co platí při vstupu do funkce a co při výstupu z ní) 

v přirozeném jazyce těžko vyjádřitelné vnořené podmínky nebo smyčky 

jazyk s abstraktními konstrukcemi, které právě potřebujeme 

vnoření konstrukcí je vyjádřeno odsazením 

vyhýbáme se syntaktickým konstrukcím cílového programovacího jazyka (popisujeme požadovaný záměr, nikoli jak to bude v cílovém jazyce) 

na druhou stranu musí umožňovat téměř automatickou konverzi do kódu 

Kontrola požadavků 

musíme zjistit, zda jsou požadavky úplné, konzistentní a zda odpovídají tomu, co zadavatel chce 

vstupem je úplný Dokument specifikace požadavků 

přezkoumání (reviews) – požadavky jsou systematicky kontrolovány týmem, manuální proces 

prototypování – zákazníkovi předvedeme spustitelný model systému 

generování testovacích případů – vytvoříme testy požadavků, pokud je obtížné vytvořit test, bude požadavek obtížně implementovatelný 

automatická analýza konzistence – pokud byly požadavky specifikovány jako model ve formální nebo strukturované notaci 

Management požadavků 

požadavky na systém se stále mění 

měl by začít plánováním, ve kterém se rozhodne: 

způsob identifikace požadavků – každý požadavek by měl mít jednoznačné ID 

proces změny požadavků – definujeme proces, abychom se ke změnám požadavků chovali konzistentním způsobem 

zdroj požadavku – kdo požadavek navrhnul, důvod; abychom se mohli zdroje zeptat na podrobnosti 

vztahy mezi požadavky – kolika požadavků se změna dotkne 

nástroje – co se použije pro uchování informací o požadavcích (malé projekty – obvyklé prostředky(textové nástroje, EXCEL, databáze, aj), velké projekty – CASE nástroje)

Postupy pro sběr požadavků.

Uživatel často neví, co chce

Požadavky upřesňuje postupně, takže se v počáteční fázi musíme snažit co nejlépe zjistit co přesně se od nás očekává

Sběr požadavků většinou zajišťuje analytik, který funguje jako styčný bod mezi zákazníkem a týmem vývojářů

Interview – rozhovor se zákazníkem

Pozorování zákazníka – sledování chování zákazníka za účelem zjištění co nejvíce informací o procesu

Prototypování – na základě prototypů se ukáže zákazníkovi, jak by výsledný produkt mohl vypadat

Způsoby vyjádření požadavků

přirozený jazyk

formuláře

Měli bychom začít tím, že rozhodneme, jak budeme požadavky identifikovat, jak je budemem případně měnit, jak vysledujeme, kdo požadavek navrhnul, na čem požadavek závisí apod. K tomu slouží nástroje – v nejjednodušším případě nám postačí Excel, jinak je lepší použít nějaký CASE systém.
