Slovníček pro business analytiky : CARA’S SOUPS → abychom požadavky nevařili z vody

14. 1. 2022clock Analýza - 4 minuty čtení

Dnešní heslo se netýká vaření polévek, týká se atributů požadavků (Requirements). V těch je někdy pěkný guláš.

Atributy požadavků

Při specifikaci požadavků (funkčních i nefunkčních) obvykle začínáme s vlastním textem požadavku, ke kterému přidáme jako atribut jednoznačné ID, což je základ pro další práci s požadavky, umožňuje odkázat se na požadavek a je předpokladem trasovatelnosti požadavků. Dále přidáme atribut priorita, který umožňuje odlišit důležité od méně důležitého (nice to have) a naplánovat postup realizace změn. Základní tip pro analytiky je tedy:

  • Text požadavku
  • ID
  • Priorita

      • Abychom nemuseli vařit z vody a vymýšlet si další atributy požadavků, průvodce business analytika BABOK ® nám dává recept a doporučuje v průběhu životního cyklu požadavků od jejich identifikace až po provedení požadované změny evidovat i další atributy požadavků, které pomáhají zvládnout vše efektivně a s přehledem:

      • Complexity – složitost realizace požadavku.
      • Absolute Reference – unikátní ID.
      • Risk – míra nejistoty výskytu nečekaných událostí, které mají vliv na požadavek.
      • Author –kdo zaznamenal požadavek, na koho se obrátit pro vyjasnění požadavku
      • Source– kdo vznesl požadavek.
      • Stability – máme požadavek specifikovaný tak, že se (alespoň po nějakou dobu) nezmění?
      • Ownership– kdo potřebuje požadavek (které oddělení)
      • Urgency– jak moc to spěchá
      • Priority– relativní důležitost oproti jiným požadavkům. Zohledňuje nejen Urgency , ale i Risk, Complexity atd. A musí to jako celek smysluplně fungovat s ostatními požadavky (MVP).
      • State– stav požadavku (například draft, specifikován, proběhlo review, schválen, zamítnut, implementován …)

        Pokud si zapamatujete, že Cara (což je ženské jméno) umí dobře vařit polévky, pomůže vám to dát dohromady atributy požadavků podle jejich prvních písmen: CARA’S SOUPS
        Požadavků se týkají ještě dva další důležité pohledy, které v polévkovém akronymu nenajdete, ale musíte s nimi při specifikaci požadavků pracovat. Je to za prvé pohled na úroveň abstrakce požadavků a za druhé seskupení požadavků do vhodných skupin.

        Úroveň abstrakce požadavků

        Požadavky často bývají na různých úrovních abstrakce. Například RAM (Requirements Abstraction Model) používá klasifikaci do 4 úrovní:

      • Product Level: požadavky spojené se strategií produktu nebo strategií organizace.
      • Feature Level: vlastnosti produktu, bez detailů funkčních požadavků.
      • Function Level: úroveň akcí prováděných uživatelem při plnění business cíle.
      • Component Level: podrobný návrh jak bude požadavek vyřešen , není to povinná úroveň ale požadavky (respektive omezení) s v praxi objevují i na této úrovní.

        Cílem je pokrýt Product level pomocí Feature level a požadavky z Feature level zase pokrýt požadavky z Function level. A to jen takovými, které jsou opravdu potřeba. Není uměním napsat tam všechno, takže už nelze nic přidat. Uměním je napsat to tak, že nelze nic ubrat.

          Obdobnou problematiku popisuje A.Cockburn (spoluautor Agilního manifestu) v knize Writing Effective Use Cases, kde definuje různé úrovně cílů use case. Use case může pro někoho vypadat jako zastaralý koncept, ale stále se používá, protože je praktický a není to nic jiného než forma zápisu funkčního požadavku. Úrovně cílů jsou znázorněny od mořského dna přes úroveň hladiny moře až do oblak.

          Naše úsilí by se mělo zaměřovat na hladinu moře, tedy na uživatelské cíle. Užitečnost jednotlivých úrovní se bude měnit v průběhu postupu projektu. Nepřipomíná vám to známou agilní hierarchii Epic – Feature – User Story – Task? Cílem user story je ale především sloužit jako podklad pro plánování práce a jako podklad pro komunikaci o požadavcích, nikoli jako detailní specifikace požadavku.

            Polévka, kterou vaříme, tedy bude asi slaná (mořská), bude v ní i nějaká ryba ale neměly by v ní být mušle, pokud to opravdu není nutné.

            Skupiny požadavků

            Požadavků bývá hodně, zejména těch funkčních. Aby se s nimi dalo dobře a přehledně pracovat, je nutné je vhodně seskupit. Seskupeny mohou být například podle:

            • Skupin uživatelů
            • Business procesů, které požadavky podporují
            • Modulů a komponent

                • Osobně dávám předost seskupení podle procesů ale nevhodnější způsob může být závislý na konkrétním projektu. Seskupování požadavků bývá obvykle provedeno manuálně analytikem. Objevují se ale i pokusy tento proces zautomatizovat a vytvářet clustery automaticky podle sémantické podobnosti jednotlivých požadavků.

                  Strukturování a seskupování požadavků do clusterů relevantních pro projekt je také doporučeným postupem (base practice) který popisuje rámec pro posuzování vyspělosti procesů vývoje softwaru SPICE (Software Process Improvement and Capability dEtermination) jako součást procesu SWE.1 Software Requirements Analysis. Aplikací tohoto rámce například pro Automotive je ASPICE.

                    Tím jsme se zase vrátili k jídlu a polévku jsme si okořenili a dochutili pomocí SPICE.

                      Dobrou chuť!

                      Sdílet:

                      Autor článku

                      Tomáš Vahalík

                      Tomáš Vahalík