Press "Enter" to skip to content

Metoda MoSCoW a její potenciál pro dotazníkové výzkumné účely v kontextu návrhu UX (v kombinaci s ISO/IEC 25010)

Published 11/04/2025 by Oxford

Anotace: Tato rešerše se zaměřuje na analýzu využitelnosti metody MoSCoW jako nástroje pro strukturování dotazníkového výzkumu v oblasti UX, konkrétně v kontextu návrhu podpůrného prostředí pro kyberbezpečnostní testery mobilních aplikací. Zvláštní pozornost je věnována možnostem kombinace MoSCoW s normou ISO/IEC 25010 za účelem systematického hodnocení a prioritizace požadavků z hlediska softwarové kvality. Výběr pěti odborných zdrojů zahrnuje jak teoretická východiska, tak empirická ověření a praktické aplikace metody. Výsledky ukazují, že MoSCoW nabízí přehlednou a srozumitelnou strukturu, která je vhodná pro transformaci potřeb a očekávání uživatelů do výzkumných položek, přičemž její účinnost lze zvýšit právě kombinací s rámcem ISO. Rešerše rovněž upozorňuje na limity metody, jako je subjektivita a potřeba precizního výkladu kategorií, které je nutné při návrhu výzkumného nástroje vhodně ošetřit.

Abstract: This literature review examines the potential of the MoSCoW prioritisation method as a framework for structuring survey research in the context of UX design, with a particular focus on supporting cybersecurity testers of mobile applications. The study further explores the possibility of combining MoSCoW with the ISO/IEC 25010 quality model to enhance the prioritisation of software requirements based on quality attributes. Drawing on five diverse sources, the review presents a balanced perspective incorporating both theoretical and empirical insights. The findings suggest that MoSCoW offers a clear and accessible structure for translating user needs into survey items, and that its value can be further amplified through integration with ISO/IEC 25010. The review also highlights the method’s limitations, including its inherent subjectivity and the need for clearly defined category criteria, which should be addressed when designing a survey tool.

Tato rešerše si klade za cíl ověřit vhodnost použití metody MoSCoW – případně v kombinaci s normou ISO/IEC 25010 – jako nástroje pro strukturování dotazníkového výzkumu (ať už kvalitativního, kvantitativního nebo smíšeného). Ten bude realizován v rámci bakalářské práce (obor Design informačních služeb, KISK, FF MU) zaměřené na návrh podpůrného prostředí pro kyberbezpečnostní testery mobilních aplikací. Hlavní přínos rešerše spočívá v orientační analýze možností, výhod a omezení MoSCoW metody v praxi, nikoli v budování samostatného teoretického rámce. Hlavní výzkumnou otázkou je:

Je metoda MoSCoW – případně v kombinaci s normou ISO/IEC 25010 – vhodná pro návrh strukturovaného dotazníkového výzkumu zaměřeného na UX v kontextu podpůrného prostředí pro kyberbezpečnostní testování mobilních aplikací?

Kontext bakalářské práce je specifický: zaměřuje se na UX orchestraci pracovního postupu v oblasti kyberbezpečnostního testování mobilních aplikací – tedy na navrhování takového systému podpory, který nezasahuje do samotných testovacích nástrojů (např. MobSF, ZAP), ale vytváří nad nimi srozumitelné a efektivní prostředí pro testera, včetně podpory tvorby PoC. V tomto prostředí může být prioritizace požadavků a funkcí klíčová, a proto je potřeba pečlivě zvolit, jaký výzkumný nástroj bude pro takový účel relevantní a srozumitelný pro zúčastněné strany.

Výběr rešeršních zdrojů

Zdroje byly vybírány na základě následujících kritérií:

  • Relevance k tématu prioritizace požadavků v softwarovém vývoji a řízení projektového rozsahu.
  • Důvěryhodnost, přičemž byl preferován výběr recenzovaných odborných publikací, univerzitního výzkumu a oficiálních metodických materiálů.
  • Šíře pohledů, která zahrnuje jak základní popis metody MoSCoW, tak její praktické využití, modifikace a empirické ověření.
  • Dostupnost, všechny zdroje jsou veřejně přístupné online, což zajišťuje transparentnost a možnost ověření čtenářem.
  • Aktuálnost, časové rozpětí zdrojů sahá od roku 2011 do roku 2024, přičemž starší zdroje obsahují metodická východiska a novější přinášejí empirické ověření.
    • Časové rozpětí použitých zdrojů sahá od roku 2011 do roku 2024. Nejstarším zařazeným materiálem je esej Eduarda Mirandy Time Boxing Planning: Buffered MoSCoW Rules (2011), který přináší originální návrh modifikace MoSCoW metody s ohledem na plánování v pevném časovém rámci (time boxing). I přes svůj věk zůstává tento text relevantní, neboť reflektuje přetrvávající problémy s přetěžováním „must have“ kategorií a nabízí praktické řešení, které je dodnes citováno a metodicky využitelné. Navíc jeho autor vychází z dlouhodobého výzkumu v oblasti agilního plánování a softwarového inženýrství, čímž dodává textu nadčasový charakter.
    • Novější zdroje z let 2020–2024 pak zajišťují aktuální empirické zázemí a reflektují současné diskuse o použitelnosti MoSCoW metody v reálných projektech. Tato kombinace umožňuje propojit historický vývoj a koncepční stabilitu metody s její současnou aplikací a kritickou reflexí.

Vzhledem k tomu, že rešerše plní podpůrnou roli v rámci širšího výzkumného návrhu, nebyl kladen důraz na značný počet zdrojů ani jejich úplné pokrytí. Záměrně byl zvolen omezený, ale reprezentativní výběr, který poskytuje přehled napříč různými přístupy k metodě MoSCoW – od oficiální metodiky přes praktické modelování až po empirickou evaluaci.

Zpracování zdroje č. 1: WIKIPEDIA. MoSCoW method [1]

Metoda MoSCoW je přístup k prioritizaci požadavků, který se využívá v oblastech softwarového vývoje, projektového řízení a business analýzy. Jejím cílem je dosáhnout společného porozumění mezi všemi zúčastněnými stranami ohledně důležitosti jednotlivých požadavků. Akronym MoSCoW vychází z počátečních písmen čtyř kategorií priorit: „Must have“ označuje nezbytné požadavky, které jsou pro úspěch dodávky klíčové; „Should have“ zahrnuje důležité, ale časově méně kritické prvky; „Could have“ představuje požadavky, které jsou vítané, pokud zbývá dostatek času nebo zdrojů; a „Won’t have“ se vztahuje na požadavky, které nebudou v aktuální fázi řešeny. Písmena „o“ v názvu slouží pouze k usnadnění výslovnosti a nemají vlastní význam.

Metodu vyvinul Dai Clegg v roce 1994 pro potřeby rapid application development (RAD). Uplatnění dosáhla například od roku 2002 v rámci metodiky DSDM (Dynamic Systems Development Method). V současnosti je „běžně“ využívána v agilním prostředí, zejména v rámci přístupů jako jsou Scrum, RAD nebo právě DSDM, a nachází uplatnění také při vývoji nových produktů.

V praxi se MoSCoW metoda často uplatňuje v kombinaci s technikou timeboxingu – tedy s pevným časovým rámcem pro dokončení určité části práce. V takových případech je prioritou dodání všech „Must have“ požadavků, zatímco méně důležité prvky lze případně vyřadit. Velkou výhodou této metody je její srozumitelnost pro zadavatele a uživatele. Kategorizace pomocí běžného jazyka (např. „musí být“, „mohlo by být“) je často vnímána jako přístupnější než tradiční označení pomocí abstraktních priorit typu „vysoká“, „střední“, „nízká“. V kontextu agilního vývoje metoda pomáhá například při definování tzv. minimálně životaschopného produktu (MVP), kdy jsou jako klíčové vybrány pouze požadavky spadající do kategorie „Must have“.

Mezi hlavní výhody této metody patří její jednoduchost, přehlednost a schopnost pomoci řídit očekávání ohledně dodávky. Lze ji aplikovat na různé typy požadavků – od funkcí přes uživatelské příběhy až po celkové produktové epiky. Kritika se však objevuje v několika oblastech. Především metoda neposkytuje nástroj pro další rozlišení požadavků uvnitř jedné priority – například pokud má projekt více „Must have“ prvků, není zřejmé, jak mezi nimi rozhodovat. Rovněž chybí jasná metodika, jak určovat, do které kategorie požadavek spadá, což může vést ke zpochybnění důvodů jednotlivých rozhodnutí. Otázky vyvolává i kategorie „Won’t have“, která může být nejednoznačná – není vždy zřejmé, zda se jedná o požadavky úplně vyřazené, nebo jen odložené na pozdější fázi vývoje. Dále byla kritizována možnost politického nátlaku na upřednostňování viditelných funkcí před nezbytnými, avšak technickými úpravami, jako je např. refaktoring.

Zdrojem nebyla přímo uvedena souvislost s normou ISO/IEC 25010, která definuje charakteristiky kvality softwaru. Lze však předpokládat, že metoda MoSCoW může být využita při stanovování priorit v rámci těchto charakteristik – například při rozhodování, zda dát přednost použitelnosti, bezpečnosti nebo přenositelnosti. Díky tomu může být potenciálně aplikovatelná i při návrhu dotazníků nebo rozhodovacích rámců, které sledují plánování a hodnocení softwarových vlastností dle tohoto standardu. Je ale důležité upozornit, že tato souvislost je odvozena interpretačně a není výslovně uvedena ve zkoumaném zdroji.

Tento zdroj poskytuje velmi přehledný úvod do problematiky metody MoSCoW – včetně jejího historického pozadí, způsobu použití a přínosů v agilním prostředí. Obsahuje také přehled výhod a nevýhod metody, což je cenné pro kritickou reflexi její vhodnosti. Dále uvádí i odkazy na alternativní metody prioritizace, například Kano model, což může být užitečné pro následné srovnání metod.

Zpracování zdroje č. 2: AGILE BUSINESS CONSORTIUM. MoSCoW Prioritisation [2]

V rámci metodiky DSDM představuje metoda MoSCoW klíčový nástroj pro řízení rozsahu projektů. Jejím hlavním účelem je umožnit efektivní prioritizaci požadavků v prostředí, kde jsou čas, rozpočet i úroveň kvality fixní, a jedinou proměnnou jsou právě funkce a požadavky. MoSCoW pomáhá týmům a zadavatelům udržet projekt v mantinelech tím, že umožňuje flexibilně reagovat na změny a přitom zachovat důvěru v úspěšné dodání. Metoda se nejčastěji používá pro prioritizaci požadavků definovaných pomocí user stories, ale lze ji aplikovat také na úlohy, testovací kritéria, případy užití a další prvky vývoje. Její přínos spočívá mimo jiné v překonání nedostatků jiných metod – například klasifikace na „vysoká, střední, nízká“ priorita postrádá jasná pravidla, zatímco číslované pořadí může vést ke zbytečným sporům o jemné rozdíly mezi jednotlivými body.

MoSCoW dělí požadavky do čtyř kategorií. Do skupiny Must Have spadají požadavky, bez nichž nemá projekt smysl realizovat – například z právního, bezpečnostního nebo funkčního hlediska. Tato skupina tvoří tzv. Minimum Usable SubseT, tedy minimální sadu funkcí, které musí být dodány. Should Have zahrnuje důležité, ale časově méně kritické prvky, jejichž absence sice může způsobit nepohodlí nebo nutnost workaroundu, ale neohrozí celkový úspěch řešení. Could Have označuje žádoucí, ale nejméně důležité požadavky, které lze snadno vyškrtnout v případě nedostatku času nebo kapacity – právě tyto požadavky tvoří hlavní zdroj flexibility. Won’t Have this time představuje požadavky, které jsou oficiálně mimo rozsah dané fáze projektu. Slouží jako nástroj řízení očekávání a pomáhají zamezit neformálnímu vracení požadavků zpět do vývoje bez souhlasu všech stran.

Metoda MoSCoW se v rámci DSDM používá na třech úrovních – pro celý projekt, pro jednotlivé projektové Inkrementy a pro konkrétní Timeboxy. To umožňuje přizpůsobit prioritu požadavku podle kontextu. Například určitá funkce může být Must Have z pohledu celého projektu, ale pro první Inkrement stačí, aby byla plánována jako Should nebo Could Have. Tento přístup zajišťuje, že tým se může soustředit na to nejdůležitější v daný moment, aniž by se vzdával dlouhodobých cílů.

DSDM doporučuje konkrétní poměrové rozdělení úsilí mezi jednotlivé kategorie. Na Must Have požadavky by nemělo být vynaloženo více než 60 % celkové kapacity. Vyšší podíl zvyšuje riziko selhání, protože eliminuje prostor pro reakci na nečekané události. Přibližně 20 % úsilí by mělo být věnováno požadavkům typu Could Have, což vytváří přirozenou rezervu. Zbytek připadá na Should Have. Tento model podporuje realistické plánování a současně nastavuje transparentní očekávání zadavatele.

Součástí doporučení DSDM je také soubor otázek a kritérií, které pomáhají určit, do které kategorie by měl požadavek spadat. Zvažuje se například, co se stane, pokud požadavek nebude dodán, zda existuje workaround, kolik uživatelů je ovlivněno nebo zda se priorita může měnit v čase. Důležitá je také týmová shoda na těchto pravidlech ještě před začátkem práce. Tím se předchází konfliktům a zajišťuje jednotný přístup k rozhodování.

Metoda MoSCoW podle DSDM zároveň napomáhá řízení očekávání. Zákazníci i tým si mohou být jisti, že Must Have požadavky budou dodány, a díky existenci rezervy lze obvykle dodat i část Should nebo Could Have prvků. Současně však tento přístup chrání kvalitu výsledného řešení a brání scope creepu, tedy nekontrolovanému rozšiřování rozsahu projektu. DSDM také doporučuje sledovat metriky, které ukazují procento dodaných Should a Could Have požadavků – ty mohou sloužit buď jako potvrzení dobrého vývoje, nebo jako včasné varování.

Zajímavé je, že ačkoli tento zdroj nijak nezmiňuje normu ISO/IEC 25010, lze metodu MoSCoW chápat jako nástroj, který může pomoci při prioritizaci jednotlivých charakteristik softwarové kvality dle této normy – například funkčnosti, použitelnosti nebo bezpečnosti. Tato úvaha ale vychází z vlastní interpretace a není přímo obsažena ve zdroji.

Celkově se jedná o velmi důležitý a oficiální zdroj k pochopení metody MoSCoW, který nejen popisuje její principy, ale především poskytuje konkrétní doporučení pro praxi. Je výborně využitelný jak pro teoretické porozumění metodě, tak pro návrh její praktické aplikace – například při tvorbě dotazníků, plánování vývoje nebo návrhu uživatelského rozhraní.

Zpracování zdroje č. 3: MIRANDA, Eduardo. MoSCoW Rules: A Quantitative Exposé [3]

Cílem článku Eduarda Mirandy je analyzovat spolehlivost metody MoSCoW pomocí modelovacích nástrojů a simulací a a ověřit, jak dobře dokáže tato metoda zajistit dodání požadavků z jednotlivých prioritních kategorií. Autor k tomu využívá Monte Carlo simulace, které modelují různé úrovně nejistoty v odhadech pracnosti a zohledňují i korelace mezi požadavky. Výsledkem je důkladná analýza pravděpodobností dodání funkcí v kategoriích Must Have, Should Have a Could Have za různých scénářů, včetně situací, kdy jsou odhady systematicky podhodnocené nebo kdy mezi požadavky existuje vnitřní závislost.

Jedním z hlavních zjištění je, že běžně doporučované rozdělení rozpočtu v poměru 60 % na Must Have, 20 % na Should Have a 20 % na Could Have vykazuje vysokou míru spolehlivosti při dodání kritických požadavků. I v případě, že jsou vývojové odhady podhodnocené až o 100 %, je pravděpodobnost úplného dodání všech Must Have požadavků stále velmi vysoká – přesahuje 98 %. Pokud však podhodnocení stoupne na 200 %, šance dramaticky klesá, v některých scénářích až na 1 %. Pokusy zvýšit podíl Must Have požadavků na 70 či 80 % sice na první pohled vypadají jako snaha posílit hodnotu dodávky, ale ve skutečnosti vedou k výraznému snížení pravděpodobnosti, že se dané cíle podaří naplnit.

Aby MoSCoW metoda fungovala správně, je třeba dodržet určité podmínky. Každá z prioritních kategorií by měla obsahovat minimálně pět požadavků a žádný z nich by neměl dominovat – tedy nesmí spotřebovat více než čtvrtinu rozpočtu přiděleného dané kategorii. Dominantní požadavky zvyšují riziko, protože jejich odhadovaná pracnost se obtížně vyrovnává s ostatními prvky. Dále je nutné počítat s vlivem korelace – pokud mají požadavky společné závislosti, například používají stejnou technologii nebo na nich pracuje jeden tým, pak chyby v odhadech u jednoho prvku pravděpodobně ovlivní i ostatní. To znamená, že pozitivní i negativní výkyvy se kumulují, což ovlivňuje celkovou spolehlivost metody. Korelace tedy může být buď velkou výhodou, nebo zásadním rizikem.

Simulace pracují se dvěma typy scénářů – scénářem s nízkou důvěrou, kde se počítá s vysokou variabilitou odhadů, a typickým scénářem, kde jsou odhady realističtější, ale stále zohledňují běžné lidské tendence k optimismu, Parkinsonův zákon a další faktory zkreslující plánování. Výsledky ukazují, že v typickém scénáři jsou pravděpodobnosti dodání vyšší než v případě scénáře s nízkou důvěrou, ale i zde selhávají Should Have a Could Have požadavky při výrazném podhodnocení. V žádném ze scénářů nebylo dosaženo úplného dodání funkcí z kategorie Could Have, pokud byl rozpočet napjatý nebo odhady nepřesné.

Pro praxi je tento článek důležitým potvrzením, že MoSCoW není pouze intuitivní metodou, ale má i měřitelný dopad na plánování, řízení rizik a sestavování realistických závazků. Autoři ukazují, že správně nastavené rozložení priorit a dodržení pravidel vede ke zvýšení důvěry v dodávky ze strany vývojářů i zadavatelů. Současně dávají podněty pro formulaci smluvních vztahů, například skrze bonusové systémy za dodání Should a Could Have prvků, nebo penalizace za jejich nedodání. Pro projektové plánování je také důležité vědět, že většina běžných plánovacích metod nepočítá s nejistotou – zatímco MoSCoW, obzvlášť ve spojení s Monte Carlo simulací, umožňuje s nejistotou aktivně pracovat.

Článek lze velmi dobře využít jako argumentační základ pro návrh realistického prioritizačního modelu například v kyberbezpečnostních aplikacích, kde selhání funkčnosti kvůli špatně odhadnutým Must Have požadavkům může vést k fatálním důsledkům. Dále je relevantní pro návrh dotazníků nebo metrik, které mají sloužit ke zhodnocení plánovacích procesů v reálných systémech. Významně také podporuje důraz na transparentní plánování a rozdělení očekávání mezi základní a rozšiřující funkcionalitu.

Zdrojem je rovněž uvedeno několik důležitých referencí, na které lze při rešerši dále navázat. Patří mezi ně oficiální materiály Agile Business Consortium, publikace Mikea Cohna věnované agilnímu plánování, doporučení k psaní user stories podle modelu INVEST a několik zásadních odborných článků z oblasti modelování rizik a odhadování nákladů. Tyto zdroje mohou být cenné zejména při hlubší analýze vztahu mezi prioritizací, plánováním a smluvními zárukami.

Zpracování zdroje č. 4: VIJAYAKUMAR, Suchetha, PRASAD, Krishna a HOLLA, Raviraja M. Assessing the Effectiveness of MoSCoW Prioritization in Software Development: A Holistic Analysis across Methodologies. EAI Endorsed Transactions on Internet of Things [4]

Studie autorů Vijayakumar, Prasad a Holla z roku 2024 se zaměřuje na praktické zhodnocení účinnosti metody MoSCoW v prostředí softwarového vývoje. Cílem bylo posoudit, jak tato populární metoda prioritizace skutečně funguje v reálných podmínkách, a to z pohledu samotných vývojářů. Autoři zvolili kombinaci kvantitativního a kvalitativního výzkumu (tzv. mixed-method přístup), což umožnilo propojit statistická data s hlubšími narativními vhledy ze zkušeností respondentů. Výsledky tak reflektují nejen měřitelnou efektivitu MoSCoW, ale i subjektivní vnímání její praktičnosti, srozumitelnosti a přínosu.

Studie identifikovala několik klíčových silných stránek MoSCoW. Metoda je podle respondentů snadno pochopitelná, rychle aplikovatelná a poskytuje užitečný rámec pro řízení rozsahu projektu. Pomáhá týmu zaměřit se na nejdůležitější funkce a zároveň vytváří prostor pro lepší plánování zdrojů a časových rezerv. Právě její jednoduchost je důvodem, proč se v praxi těší oblibě.

Na druhé straně však výzkum poukázal i na zásadní slabiny. MoSCoW podle výsledků trpí vysokou mírou subjektivity – různí lidé často odlišně interpretují, co přesně spadá do jednotlivých kategorií, což může vést k nekonzistentním rozhodnutím. Chybí pevná formální kritéria, která by přiřazení požadavků do kategorií objektivizovala. Studie dále ukazuje, že ve skupinové praxi často rozhoduje úzký okruh lidí, což snižuje participaci širšího spektra stakeholderů. Jako problematické se rovněž ukázalo pevné čtyřstupňové členění požadavků, které není dobře přizpůsobené dynamickým projektům, kde se potřeby rychle mění. Autoři zároveň upozorňují, že dosavadní vědecké práce poskytují jen velmi málo empirických dat k této metodě – jejich výzkum tak do značné míry tuto mezeru pomáhá zaplnit.

Experimentální část byla postavena na simulaci reálného prioritizačního úkolu, který byl zadán 172 studentům s relevantním odborným zázemím. Respondenti měli za úkol aplikovat metodu MoSCoW na požadavky systému pro online objednávání jídla. Výsledky kvantitativní části ukázaly, že většina účastníků dokončila úkol a vyjádřila střední míru spokojenosti. Zároveň však téměř tři čtvrtiny označily metodu jako matoucí. Rozdílné vnímání náročnosti se odrazilo i v průměrném čase na jednotlivá rozhodnutí, který se výrazně lišil mezi účastníky.

Kvalitativní analýza otevřených odpovědí potvrdila tyto závěry. Respondenti nejčastěji zmiňovali zmatenost ohledně zařazení požadavků, časovou náročnost a problém s tím, že mnoho požadavků by podle nich zasluhovalo označení „Must Have“, což ale odporuje principům metody. Sentimentální analýza, provedená dvěma nezávislými nástroji (VADER a TextBlob), navíc odhalila výraznou převahu negativně zabarvených odpovědí.

Pro účely bakalářského projektu lze tuto studii považovat za velmi cenný empirický zdroj. Ukazuje, že MoSCoW má své limity, které je nutné zohlednit při aplikaci v reálných systémech nebo při návrhu dotazníkových nástrojů. Autoři dochází k závěru, že samotná metoda nestačí, a je vhodné ji rozšířit o doplňující kritéria, jasnější pokyny a širší zapojení stakeholderů. Tyto poznatky lze využít například při kombinaci MoSCoW s normami jako je ISO/IEC 25010, které pomáhají formálně vymezit požadavky na kvalitu softwaru. Studie je rovněž inspirací pro vytvoření samostatné kapitoly rešerše zaměřené na omezení, kritiku a možnosti empirického ověření této metody v praxi.

Zpracování zdroje č. 5: MIRANDA, Eduardo. Time Boxing Planning: Buffered MoSCoW Rules [5]

Eduardo Miranda ve svém článku Time Boxing Planning: Buffered MoSCoW Rules z roku 2011 navrhuje modifikaci klasické MoSCoW metody s cílem zlepšit její použitelnost v prostředí plánování s pevně daným časovým rámcem, tedy takzvaném time boxingu. Klíčovým motivem této úpravy je snaha vytvořit plán, který je realističtější a spolehlivější, zejména pokud jde o garanci dodání prioritních požadavků, aniž by docházelo k přehnaným slibům či přetížení vývojového týmu.

Zatímco klasická MoSCoW metoda řadí požadavky podle jejich důležitosti z pohledu zákazníka, Miranda redefinuje jednotlivé kategorie na základě pravděpodobnosti jejich dodání v rámci stanoveného časového limitu. Must Have funkce jsou takové, které by měly být dodány téměř jistě, pokud nenastane vážná událost; Should Have jsou funkce s rozumnou šancí na realizaci, pokud předchozí fáze nespotřebuje všechny zdroje; Could Have mají šanci pouze v případě, že vše probíhá nadstandardně hladce; a Won’t Have pak představují položky, na které v daném časovém rámci nezbývá kapacita. Přesná čísla jako 90 %, 45 % nebo 20 % se v článku objevují pouze jako ilustrativní analogie pro vyjádření relativní spolehlivosti jednotlivých kategorií – jejich skutečné použití by vyžadovalo komplexní analýzu, například formou Monte Carlo simulace.

Metoda samotná staví na dvoubodových odhadech pracnosti jednotlivých požadavků: běžném (normálním) odhadu a takzvaném bezpečném odhadu, který reflektuje pesimistický scénář. Nejprve se sestaví realistický plán, ve kterém se do kategorie Must Have zařazují jen ty požadavky, které lze stihnout i při uplatnění bezpečných odhadů. Rozdíl mezi bezpečnými a běžnými odhady pak tvoří tzv. buffer – rezervu, která se využije pro případné dodání Should Have požadavků. Zbylý prostor je určen pro Could Have, u nichž je úspěšná realizace zcela podmíněna tím, že předchozí fáze proběhne s výraznou rezervou. Tímto způsobem je možné sestavit plán dodávky, který je konzervativní, ale o to lépe predikovatelný a srozumitelný i pro zákazníka.

Miranda tuto logiku propojuje s obchodním a smluvním rámcem. Upozorňuje, že pokud zákazník ví, že určitá část funkcionality je zajištěna téměř s jistotou, může se podle toho lépe rozhodovat a plánovat své aktivity. Současně to umožňuje uzavírat smlouvy, které rozlišují mezi základním závazkem a „bonusovými“ dodávkami – například pomocí cenové struktury, kde Must Have funkcionalita je garantovaná, zatímco Should nebo Could Have přinášejí dodatečné odměny nebo slevy v případě jejich nedodání. Stejný princip lze použít i pro motivaci týmu, kde plnění základního plánu odpovídá standardní odměně a další vrstvy přinášejí uznání za mimořádný výkon.

Přestože článek nezmiňuje žádné konkrétní standardy jako ISO/IEC 25010, je jeho metodika s těmito rámci nepřímo kompatibilní. Umožňuje totiž prioritizovat softwarové požadavky nejen podle obchodní důležitosti, ale i podle typu kvality – například bezpečnostní či robustní funkce lze zařadit do Must Have, zatímco přenositelnost nebo uživatelské rozhraní může spadat do volitelnějších kategorií.

Celkově Miranda přináší metodicky jednoduchý, ale koncepčně silný nástroj pro plánování projektů, který bere vážně nejistoty spojené s odhady pracnosti. Nabízí přístup, který zajišťuje důvěryhodnost vývoje a umožňuje projektovým manažerům transparentně komunikovat, co lze dodat jistě, co s rezervou a co pouze v případě příznivého průběhu. Pro systémy s vyšší mírou rizika nebo nejistoty, jako jsou například nástroje v oblasti kyberbezpečnosti, představuje tato metoda velmi praktické řešení, které propojuje agilní plánování s realistickým řízením očekávání.

Závěr rešeršní části

Tato rešerše si kladla za cíl orientačně posoudit vhodnost metody MoSCoW – případně v kombinaci s rámcem ISO/IEC 25010 – pro strukturování výzkumného nástroje v rámci bakalářské práce zaměřené na návrh podpůrného pracovního prostředí pro kyberbezpečnostní testování mobilních aplikací. Rešerše zahrnovala jak teoretická východiska, tak empirické studie, a nabídla ucelený obraz silných i slabých stránek MoSCoW metody.

V průběhu rešerše však došlo k zásadní změně metodologické perspektivy. Původní hypotéza, že by MoSCoW mohla být využita jako přímá odpovědní škála v dotazníku, se ukázala jako problematická. Většina analyzovaných zdrojů ukazuje, že MoSCoW je primárně určena pro plánování a rozhodování v rámci projektového nebo návrhového procesu – nikoliv pro přímé použití respondenty ve výzkumných nástrojích. Nabízí hodnotu tam, kde dochází ke kategorizaci požadavků z pohledu dostupných zdrojů, nikoliv při exploraci uživatelských zkušeností.

Z toho důvodu se MoSCoW v této práci uplatní nikoli jako formát odpovědí, ale jako interpretační rámec – tedy jako nástroj designéra pro následné třídění zjištěných potřeb a očekávání podle míry jejich naléhavosti. V kombinaci s rámcem ISO/IEC 25010, který definuje charakteristiky softwarové kvality, lze tímto způsobem konvertovat volné nebo škálované uživatelské odpovědi do návrhově relevantní prioritizace.

Tato kombinace přináší dvě výhody:

  1. přehlednou strukturu pro rozhodování na straně návrhového týmu,
  2. zachování přirozeného, pro respondenty srozumitelného výzkumného jazyka.

Z pohledu UX výzkumu tedy MoSCoW neslouží jako nástroj výpovědi, ale jako nástroj designové interpretace a plánování.

Explicitní zodpovězení výzkumné otázky

Je metoda MoSCoW – případně v kombinaci s normou ISO/IEC 25010 – vhodná pro návrh strukturovaného dotazníkového výzkumu zaměřeného na UX v kontextu podpůrného prostředí pro kyberbezpečnostní testování mobilních aplikací?

Na základě provedené rešerše lze odpovědět následovně:

  1. Kombinace MoSCoW a ISO/IEC 25010 se tedy jeví jako silný nástroj návrhového myšlení, který umožňuje spojit uživatelské poznatky s kvalitou softwaru. Tento rámec poskytuje designérovi jasnou oporu při rozhodování o tom, co je nutné realizovat, co je žádoucí a co může být odloženo – na základě skutečných uživatelských potřeb, nikoli odhadu.
  2. Metoda MoSCoW je vhodná jako nástroj pro interpretaci a strukturaci výstupů z výzkumu, nikoli jako přímá forma odpovědí v dotazníku. Její silnou stránkou je schopnost kategorizovat požadavky podle jejich relativní důležitosti s ohledem na omezené zdroje – což je klíčové v návrhové fázi, ne ve fázi zjišťování.
  3. Pro samotný výzkumný nástroj (dotazník) je vhodnější použít běžnější formy dotazování – např. škálování důležitosti, výběr preferovaných charakteristik, otevřené otázky apod. Tyto vstupy lze následně analyzovat optikou ISO/IEC 25010 a prioritizovat pomocí MoSCoW z pohledu návrhového týmu.

Seznam použitých zdrojů

  • [4] VIJAYAKUMAR, Suchetha, PRASAD, Krishna a HOLLA, Raviraja M. Assessing the Effectiveness of MoSCoW Prioritization in Software Development: A Holistic Analysis across Methodologies. EAI Endorsed Transactions on Internet of Things [online]. 2024, 10. [cit. 2025-04-21]. DOI: 10.4108/eetiot.6515. Dostupné z: https://publications.eai.eu/index.php/IoT/article/view/6515​

Published in Kyberbezpečnost