Postupy pro sběr požadavků.

Z Na státnice zvesela!

[editovat] Metody shromažďování požadavků

Způsoby získávání

• interview
  • 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ů)
• analýza existujícího systému
  • inspirujme se tím, jak funguje stávající systém
• dotazníky
  • vhodnými otázkamy 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 specifikované funkce nebo entity
    • 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í)
    • pokud vznikají postranní efekty, pak jejich popis
• pseudokódy
  • v přirozeném jazyce tež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

formuláře vs. pseudokód

• formuláře – celková specifikace systému
• pseudokód – řídící sekvence, rozhraní

[editovat] Kontrola požadavků

• musíme zjistit, zda jsou požadavky úplné, konzistentní a zda odpovídají tomu, co zadavatel chce
• vstupem je úplný DSP
• metody:
  • 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

[editovat] 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
  • sledovatelnost
    • 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)