1) Začni “WHAT” (čo), nie “HOW” (ako)

Požiadavky majú popísať čo má systém robiť, nie ako to bude naprogramované.

Cieľ prototypu je overiť smer, nie hádať technické detaily.

2) 1–2 týždne: Discovery, ktoré ušetrí mesiace

Získaj požiadavky od stakeholderov (užívatelia, biznis, support…) cez:

• krátke interview,

• 1 workshop (brainstorm),

• prípadne pozorovanie procesu (ako ľudia reálne fungujú).

Výstup: jasné use-cases / flowy + zoznam požiadaviek.

3) Prioritizácia: MoSCoW alebo sa utopíš

Bez tvrdého rezu sa prototyp nikdy “nedokončí”. Použi MoSCoW:

• Must have (bez toho appka nedáva zmysel),

• Should have (dôležité, ale pre MVP sa dá vynechať),

• Could have (voliteľné),

• Want to have (neskôr).

Pravidlo: MVP = Must + minimum zo Should. Všetko ostatné je “later”.

4) Validácia požiadaviek: skontroluj kvalitu, kým je lacná

Požiadavky si musíš prejsť a otestovať, či sú:

• kompletné, konzistentné, presné, overiteľné a realistické.

  A hlavne: či definujú to, čo zákazník naozaj chce/potrebuje (nie čo si myslí, že chce).

Tvrdý fakt: oprava chyby v požiadavkách po dodaní môže stáť až 100× viac než oprava implementačnej chyby.

5) Prototypovanie: rýchlo ukáž, rýchlo oprav

Prototyp je počiatočná verzia systému na demonštráciu konceptov a vyskúšanie dizajnových možností.

Používa sa na:

• získanie a spresnenie požiadaviek (elicitation),

• kontrolu konzistencie a validáciu,

• exploráciu UI/UX.

Dôležité: prototypy často majú slabú “vnútornú štruktúru”, nemajú byť základ finálneho systému.

6) 3–8 týždňov: Iterácie (agile mindset), nie “waterfall”

V praxi to ide tak, že špecifikácia, dizajn, implementácia a testovanie sa prelínajú a rozhodnutia sa robia priebežne.

Pre prototyp to znamená: týždenné cykly → ukážka → feedback → úprava.

7) Architektúra: rozhodni drahé veci čo najskôr

Architektúra je súbor významných dizajnových rozhodnutí, ktorých význam sa meria cenou zmeny.

Architektúra odpovedá na “najdrahšie otázky”.

Minimum, čo si musíš ujasniť už pri prototype:

• ako systém rozdelíš na moduly,

• aký štýl/štruktúru zvolíš,

• distribúcia (čo beží kde),

• ako to budeš dokumentovať a hodnotiť.

8) Nezabudni na non-functional požiadavky už od začiatku

Non-functional požiadavky (výkon, bezpečnosť, spoľahlivosť, použiteľnosť…) sú často to, čo rozhodne o úspechu.

A často ovplyvnia celú architektúru, nie len detaily komponentov.

Čo dostaneš na konci 0–3 mesiacov (ideálny stav)

• Prioritizovaný scope (MoSCoW) + jasné use-cases

• Klikateľný prototyp na validáciu a rozhodovanie

• Základný architektúrny prehľad (kľúčové rozhodnutia)

• Dohodnuté kritériá kvality a “čo je hotové” (aby sa to nezvrhlo)