Wiegers, Karl E.: Požadavky na software

Část I – Podstata a význam požadavků na software

• Při vývoji software je komunikace potřeba přinejmenším stejně jako programování, ale my přesto běžně dáváme přednost programování.
• Většinu lidí by nenapadlo postavit nový dům za šest milionů, aniž by své potřeby a požadavky důkladně probrali s projektantem a všechny podrobnosti postupně upřesnili. Jasně chápou, že jakékoliv dodatečné úpravy s sebou nesou náklady – nelíbí se jim to, ale rozumí tomu. Naproti tomu u vývoje SW se podobné problémy lehkovážně přehlíží.
• Špatná analýza požadavků může představovat 40-60 % chyb SW projektů.
• Požadavek lze definovat jako
  • podmínku nebo funkci, kterou uživatel potřebuje pro řešení problému nebo dosažení nějakého cíle;
  • podmínku nebo funkci, kterou musí systém nebo jeho část splňovat, aby vyhověl smlouvě, standardu, specifikaci nebo jinému dokumentu, jenž se na něj formálně vztahuje;
  • dokumentovanou podobu některého z předchozích dvou bodů;
  • vnější chování systému (z pohledu uživatele, účastníka projektu);
  • vnitřní parametr (z pohledu vývojáře);
  • vlastnost, již systém musí mít, aby měl hodnotu pro některého z účastníků;
  • popis toho, co všechno by se mělo implementovat, tj. popis žádaného chování systému a jeho vlastností, přičemž mohou představovat nějaká omezení procesu vývoje systému.
• Požadavky můžeme rozčlenit do tří skupin: 1) Podnikatelské požadavky (cíle na nejvyšší úrovni organizace/zadavatele – PROČ má systém vzniknout); 2) Uživatelské požadavky (cíle uživatelů, případy užití, scénáře, tabulky – CO systém budě dělat pro splnění podnikatelských požadavků) a 3) Funkční požadavky (funkcionalita pro plnění uživatelských cílů, features, chování – JAK systém bude plnit uživatelské požadavky).
• Podnikatelská pravidla nepatří mezi SW požadavky, existují mimo ně, avšak často z nich plynou omezení či kvalitativní parametry konkrétních funkcionalit. Jsou to firemní předpisy, státní nařízení, průmyslové standardy, systémy účetnictví, výpočetní algoritmy atd.
• Funkce (features) jsou logicky související funkční požadavky, představující nějaký nástroj pro uživatele a umožňující splnění některého z podnikatelských požadavků.
• Kvalitativní parametry upřesňují přívlastky obsažené v podnikatelských, resp. uživatelských požadavcích do konkrétních hodnot, metrik.
• Nejtěžší samostatnou fází stavby SW systému je rozhodnout, co přesně má vzniknout. Žádná z ostatních částí konceptuální práce není tak složitá, jako vybudování podrobných technických požadavků včetně všech rozhraní k lidem, strojům a dalším systémům. Žádná z ostatních částí práce systém tak nezmrzačí, když ji uděláte špatně. Žádná z ostatních částí se tak těžko neopravuje později.
• Postupné upřesňování kódu je dražší než postupné upřesňování představ.
• Problém s tichým nárůstem požadavků je z části vinou častých změn uživatelských požadavků a z části je na vině způsob, kterým na tyto požadavky reagují vývojáři.
• Nejednoznačnost zadání způsobuje rozdíly v očekávání jednotlivých účastníků projektu. Znamená několikerý možný výklad či prostor pro domýšlení si při vývoji. Předcházet tomu lze několika způsoby – požádat pár lidí s různými perspektivami o formální posouzení požadavků, napsat si testovací scénáře nebo prototypováním. Při čtení požadavku by každý čtenář měl dojít k jedinému logickému výkladu, proto popisujte požadavky jednoduchým, stručným a přímočarým jazykem odpovídajícím uživatelské doméně.
• Každý požadavek by měl pocházet od zdroje, který má právo klást nové požadavky. Dohledejte každý požadavek až k zákazníkovi, například k případu užití, podnikatelskému pravidlu. Je dobré ke každému požadavku zapsat autora, na kterého bude možné se obracet.
• Když se požadavek nedá ověřit, jeho správná implementace se stává předmětem názoru a nikoliv objektivní analýzy.
• Vlastnosti dobře popsaných požadavků: úplnost, správnost, proveditelnost, nepostradatelnost, priorita, jednoznačnost, ověřitelnost.
• Chyba v analýze znamená předělávání výsledného systému, což je mnohem dražší než čas zprvu strávený nad definicí požadavků. Známá pravda, přesto v praxi je zanedbávání tohoto faktu běžné a projekty se takto protahují/prodražují.
• Zákazník je jednotlivec nebo organizace, kterým produkt přináší nějaký přímý či nepřímý užitek: účastníci, kteří si vyžádali, zaplatili, vybrali, specifikovali, používají/dostávají výstup z vytvářeného SW produktu. Dobrý systém je výsledkem dobrého návrhu založeného na dobře formulovaných požadavcích.
• U všech aplikací na zakázku by měly podnikatelské požadavky pocházet od lidí, kteří mají na starosti peníze, a uživatelské požadavky od lidí, kteří budou systém skutečně používat. Přičemž mezi podnikatelskými a uživatelskými požadavky by měl být soulad.
• Směrná verze dokumentu představuje v daném čase závaznou podobu požadavků. Akceptace by se neměla ze strany zákazníka brát na lehkou váhu, na druhou stranu by dodavatel neměl zákazníkův podpis používat jako automatickou odpověď, dojde-li k potřebě změn. Podpis = souhlas, že požadavky jsou nejlepší současnou představou o budoucím systému, a že případné změny budou probíhat podle domluveného postupu a zároveň mohou vyžadovat nová jednání o ceně, zdrojích či termínech celého projektu.
• Nezbytné dovednosti analytika: 1) Umění naslouchat, 2) umění ptát se a vést rozhovor, 3) kritické a abstraktní myšlení, 4) moderátorské schopnosti, 5) pozorovací schopnosti, 6) vyjadřovací schopnosti, 7) organizační schopnosti (z množství nesourodých kousků vykřesat něco smysluplného/hodnotného), 8) modelovací schopnosti, 9) sociální inteligence, 10) nápaditost.
• Co posuzovat u analytika? – Praktické zkušenosti, znalost technik a nástrojů, znalost vývoje SW a projektového řízení, znalosti aplikačních domén, osobnost.

Část II – Vývoj požadavků

• Vývoj požadavků představuje jejich sbírání, analýzu, specifikaci a kontrolu. Směrná verze požadavků je výstupem.
• Vize a rozsah projektu musí být jasné ještě před tím, než se začne s podrobnou specifikací funkčních požadavků. Popisují, k čemu je navrhovaný SW a co by se z něj mohlo časem stát.
• Kontextový diagram. Slouží ke grafickému vyjádření hranic a rozsahu projektu (koncové prvky, hranice a spojení mezi vyvíjeným systémem a celým zbytkem vesmíru). Je na nejvyšší úrovni abstrakce – navrhovaný systém je vyjádřen jako blackbox, důležité jsou toky.
• Podnikatelské požadavky. Jsou rámcem, představují omezení – determinují šířku aplikace a hloubku implementace. Určují prioritu uživatelských požadavků (funkce navázané na prioritní podnikatelské cíle mají rovněž vyšší prioritu). Poté se soustředíme hlavně na funkce, které přinesou největší hodnotu co nejvíce lidem, budou vyžadovat nejmenší náklady a stihnou se nejdřív.
• Předpoklady a závislosti je také vhodné definovat ještě v rámci plánování projektu.
• Účastníci – jednotlivci, skupiny nebo organizace, které se projektu aktivně účastní, budou ovlivněni jeho výsledkem anebo mohou ovlivnit jeho výsledek.
• Hlas zákazníka. Měl by být při vývoji slyšet nejvíc, znamená to: 1) najít všechny třídy uživatelů (tj. také externí aplikace), 2) najít zdroje uživatelských požadavků, 3) vybrat zástupce jednotlivých tříd uživatelů a spolupracovat s nimi, 4) dohodnout se, kdo bude o požadavcích rozhodovat. Základem úspěchu je mít co nejtěsnější vazbu zákazník-vývoj a mít víc komunikačních kanálů, tedy klíčová je úloha analytika coby prostředníka/mediátora.
• Potřeba × Přání. Zákazník na začátku často sám neví, co ve skutečnosti chce. Může požadovat funkce, které ale nepotřebuje.
• Zákazník nemá vždy pravdu. Jeho slovo je ale důležité a mělo by být vždy bráno v potaz a respektováno.
• Sběr požadavků. Je patrně tou nejsložitější a přitom nejdůležitější částí vývoje SW. Analytik by měl umět myslet i mimo hranice, které běžně omezují představivost uživatelů příliš ponořených do problémové domény, a nespokojit se pouze se záznamem požadavků, ale už při sběru přicházet s dodatečnými nápady či alternativami (= přidaná hodnota analytika).
• Požadavkové workshopy. Důležitá je role moderátora, případně zapisovatele. Moderování = umění vést lidi ke společným cílům způsobem, který podporuje zapojení, účast a produktivitu všech zúčastněných. Doporučená pravidla:
  • Držet se stanoveného rozsahu projektu, držet si úroveň abstrakce, téma daného WS.
  • Některé informace si pouze poznamenat, ale nezacházet do detailu (pokud to nemá dopad např. do případů užití) a nechat na později (kvalitativní parametry, omezení, business rules, nápady na řešení, …).
  • Omezovat diskusi k jednotlivým bodům časovým limitem.
  • Držet tým co nejmenší a pečlivě vybírat účastníky, optimálně 5-6 aktivních účastníků.
  • Zapojovat všechny účastníky.
• Třídění získaných informací. Možná kategorizace získaných informací (str. 118-122):
  • Předpoklady
  • Podnikatelské požadavky
  • Případy užití a scénáře (co uživatel potřebuje prostřednictvím systému udělat)
  • Podnikatelská pravidla
  • Funkční požadavky (jak se systém zachová za určitých podmínek –> systémové požadavky?)
  • Ne-funkční požadavky (požadavky na vnější rozhraní, uložení dat atd.)
  • Definice dat (popisy formátů, přípustných/výchozích hodnot –> shrnout do tzv. datového slovníku)
  • Kvalitativní parametry (včetně metrik, aby nezůstalo pouze u subjektivního pojetí)
  • Omezení (včetně důvodů, aby byl jasný původ omezení a nebylo zpochybňováno)
  • Návrhy řešení
  • Požadavky mimo vývoj SW (např. potřeba přeškolení uživatelů apod.)
• CO a JAK. Často se říká, že požadavky se týkají toho, co má systém dělat, a návrh se zabývá tím, jak toho dosáhnout. To je ale příliš jednoduchá definice. Požadavky by se opravdu měly soustředit na zmíněné co, ale mezi analýzou a návrhem je šedá zóna, nikoliv jasná čára. Hypotetické jak občas pomůže vyjasnit a upřesnit, co vlastně uživatelé chtějí. Modely a obrazovky vznikající během vývoje požadavků chápeme jako prototypy, které mají usnadnit komunikaci, nikoliv jako předpisy pro vývojáře!
• Techniky hledání chybějících požadavků. Ne vždy se podaří objevit všechny požadavky předem, pozor na tzv. analytickou paralýzu (příliš mnoho času stráveného nad kontrolou úplnosti požadavků).
  • Příliš obecné požadavky konkretizovat, rozvést, zbavit se nepřesných výrazů.
  • U každého případu užití najít alespoň jednoho aktéra (zastoupení uživatelských tříd).
  • Všechny systémové požadavky, události a odpovědi, business rules atd. namapovat na funkční požadavky (pro ujištění, že máme podchyceny všechny potřebné funkce).
  • Pohlídat si hraniční případy, typicky u podmínek a logických kombinací (co se stane, když je podmínka splněna, když není splněna, zachytit všechny případy, které mohou nastat). Výborným nástrojem jsou rozhodovací stromy nebo rozhodovací tabulky.
  • Požadavky zapisovat v různých podobách – textově i graficky, snáze tak objevíme chybějící místo, bod, spojení, … = chybějící požadavek.
  • Spojit si akce systému (případy užití) s datovými entitami v podobě jednoduché matice CRUD/L (Create-Read-Update-Delete-List), viz str. 124.
• Způsob záznamu požadavků 1 – Případy užití. Jejich prostřednictvím se snažíme zjistit, čeho uživatelé potřebují dosáhnout (což nemusí být shodné s tím, co si uživatelé myslí, že by systém měl dělat). Cílem případů užití je popsat všechny úkoly, které uživatel potřebuje pomocí systému vykonat. Výsledná skupina případů užití by tak měla být uceleným popisem veškeré požadované funkcionality. Případů užití bývá mnohem víc než podnikatelských požadavků a funkcí, ale mnohem méně než funkčních požadavků. Složitost business logiky neovlivníme, ale způsob jejího zápisu ano!
  • Scénář případu užití = jeden konkrétní průchod případem užití, jedno konkrétní použití systému.
  • Detail případu užití. Zahrnuje (str. 136): ID, stručný název, stručný textový popis, vstupní a výstupní podmínky (hranice případu, kroky musí být uvnitř), scénáře – hlavní, alternativní, výjimkové.
  • Principiální případ užití. Je formulován tak, aby neomezoval možné implementace požadavku („Zadejte, o jaký záznam máte zájem“ namísto „Zadejte číselný kód záznamu“). Díky své implementační nezávislosti se tyto případy užití dají i lépe recyklovat.
• Způsob záznamu požadavků 2 – Podnikatelská pravidla. Podnikatelské pravidlo = věta, která definuje nebo omezuje nějakou stránku podnikání. Často jsou to důvody funkčních požadavků. Podnikatelská pravidla se mohou týkat více aplikací firmy, a tak by bylo vhodnější je spravovat na úrovni celé firmy. Vždy je ale třeba je najít, zdokumentovat (katalog podnikatelských pravidel) a provázat s příslušnými funkčními požadavky na nově vyvíjený SW. Typy podnikatelských pravidel:
  • Fakta (invarianty – neměnné pravdy),
  • Omezení,
  • Aktivátory (složitější podmínky typu if/else, které spouští nějakou akci),
  • Výpočty (vzorce či algoritmy),
  • Implikace (odvozené znalosti – pravidla, která z platnosti nějakých podmínek vyvozují nová fakta, rovněž typu if/else, jenže nespouští akci, ale pouze vyvozují/popisují nějaký fakt).
• Způsob záznamu požadavků 3 – Dokumentace požadavků. Cílem vývoje požadavků je, aby se zákazníci a vývojáři průkazně shodli na podobě systému, který se má implementovat. Nejpraktičtějším nástrojem pro dokumentaci požadavků jsou grafické modely (seznamy, tabulky, schémata, obrázky, rozhodovací tabulky/stromy, mapy dialogů, diagramy atd.) ve spojení se strukturovaným přirozeným jazykem. Ani ta nejlepší specifikace ovšem nikdy nenahradí osobní komunikaci v průběhu celého projektu.
  • Specifikace požadavků ~ Funkční specifikace ~ Produktová specifikace ~ Požadavková dokumentace ~ Systémová specifikace. Popisuje funkce, které systém musí poskytovat, a omezení, do nichž se musí vejít, měla by v potřebném detailu popisovat chování systému v různých podmínkách. Je základem pro veškeré další plánování, návrh a implementaci, pak i pro testování a psaní uživatelské dokumentace. Každá organizace zabývající se vývojem SW by měla mít alespoň jednu standardní šablonu pro specifikaci svých projektů (str. 160).
    • Patří návrhy obrazovek do specifikace, pomáhají upřesnit požadavky/funkčnost, nebo se jedná už o návrh řešení? – Kompromis: použít pouze náčrtky rozhraní, netrvat na implementaci detailů.
  • Datový slovník. Sdílená databáze s definicemi významů, datových typů, délek, formátů, povolených rozsahů, výčtů povolených hodnot datových typů sytému.
  • Analytické modely jako doplněk specifikace v přirozeném jazyce, nikoliv jeho náhrada!
  • Je třeba rozlišovat, kdy se jedná o model ryze analytický (tj. koncept), nebo o model návrhu (podle kterého se má implementovat)!
• Analytická paralýza. Požadavky nelze vylepšovat donekonečna. Cílem je napsat požadavky, které budou dostatečně dobré na to, aby vývojáři mohli postupovat s přijatelnou mírou rizika.
• Prototypování. IKIWISI – I’ll know it when I see it; chování systému se těžko představuje jen na základě textových požadavků nebo analytických modelů, uživatelé rádi zkouší prototypy (protože je to legrace) a neradi čtou specifikaci (protože to legrace není). Pokud fráze IKIWISI zazní od zákazníka/uživatelů, je třeba se zamyslet, čím jim popis požadavků usnadnit – nabízí se tvorba prototypu. Pokud ovšem účastníci absolutně netuší, co by se mělo implementovat, projekt je stejně odepsaný.

Část III – Správa požadavků

• Správa požadavků představuje především změnu požadavků. Směrná verze požadavků je vstupem, výstupem je její aktualizace.
• TBD

Část IV – Řízení požadavků

• Zlepšování SW procesů s cílem snížit náklady na vývoj a údržbu SW.
• TBD