Jak specifikace softwarových požadavků a makety šetří firmám čas a peníze

Věděli jste, že 70% IT projektů překročí rozpočet nebo zcela selže kvůli chybám ve fázi plánování? Podle Standish Group (2023) je hlavním důvodem nedostatek jasných obchodních požadavků a vizuální reprezentace produktu. A právě zde přicházejí na pomoc specifikace softwarových požadavků (SRS) a makety – dva nástroje, které… softwarové poradenství firma používá k proměně chaosu vývoje a testování produktů v zvládnutelný proces.

Dobrá specifikace požadavků na software není jen formalita, ale základ úspěchu jakéhokoli vývojového projektu. Dobře připravená specifikace požadavků na software (SRS) podrobně popisuje, co by měl softwarový systém dělat, jak bude interagovat s uživateli a systémy a jaké standardy kvality bude splňovat.

Například startup z Kalifornie přišel o 100 000 USD kvůli banální chybě: tým začal psát kód bez schváleného SRS. V důsledku toho zákazník obdržel produkt, který nesplňoval jeho očekávání, a jeho přepracování trvalo tři měsíce.

Makety zase vizualizují nápady ještě před zahájením programování. Umožňují koordinovat design, logické rozhraní a uživatelské scénáře, což je obzvláště důležité při vývoji IT. Bez nich může být role softwaru v obchodních procesech zkreslená a oprava chyb v pozdějších fázích bude stát 10 až 100krát více (IBM, 2021). Vývoj softwarových požadavků je nezbytný.

Pojďme se podívat na to, jak SRS a mockupy šetří čas, rozpočet a nervy všem účastníkům vývojového procesu. Dozvíte se:

• Jak napsat osnovu SRS, abyste se vyhnuli konfliktům s dodavateli.
• Proč jsou funkční a nefunkční požadavky klíčové a stejně důležité.
• Nástroje, které špičkové společnosti používají k vytvoření efektivního dokumentu SRS.
  

Jste připraveni proměnit váš další IT projekt v úspěšný příběh? Začněme se základy.

Softwarové poradenství

Softwarové poradenství hraje klíčovou roli v pomoci firmám zefektivnit jejich vývojové procesy a efektivně dosáhnout jejich cílů. softwarová poradenská firma nabízí odborné poradenství, jak vytvářet robustní softwarové architektury, implementovat osvědčené postupy a vyhýbat se nákladným chybám. Jednou z klíčových oblastí zaměření softwarového poradenství je vývoj specifikací softwarových požadavků (SRS) a maket. Tyto nástroje zajišťují, že proces vývoje softwaru zůstává strukturovaný a efektivní, což pomáhá firmám šetřit čas a snižovat pravděpodobnost nákladných chyb během vývoje.

Například podle Standish Group (2023) selže nebo překročí rozpočet 70% IT projektů kvůli nejasným požadavkům. SRS není jen byrokratický dokument; funguje jako podrobný plán pro vývoj softwaru, který zahrnuje funkční i nefunkční požadavky. Spoluprácí se softwarovou poradenskou firmou nebo konzultační společností SRS se firmy mohou vyhnout běžným nástrahám, jako je nedostatečné plánování nebo špatně definované cíle, což v konečném důsledku pomáhá chránit rozpočet a časový harmonogram projektu.

Dalším cenným nástrojem jsou makety, které vizuálně znázorňují nápady před fází programování. Pomáhají zajistit soulad mezi designem, uživatelskou zkušeností a funkčními požadavky. Tyto vizuály umožňují zúčastněným stranám ověřit, zda produkt splňuje očekávání, a snižují tak riziko nákladných redesignů později.

Softwarové poradenství v konečném důsledku poskytuje firmám jasnější pochopení jejich softwarových potřeb, pomáhá jim orientovat se v komplexních IT projektech a připravit se na úspěch. SRS poradenství tento proces dále vylepšuje zajištěním přesných a dobře zdokumentovaných softwarových požadavků, minimalizací rizik a sladěním vývojových snah s obchodními cíli.

Vývoj SaaS

Vývoj SaaS (software as a Service) je proces vytváření cloudových softwarových aplikací, ke kterým se přistupuje online, nikoli na lokální počítače. Platformy SaaS poskytují firmám škálovatelná řešení založená na předplatném, ke kterým lze přistupovat z jakéhokoli zařízení s připojením k internetu. Mezi klíčové výhody vývoje SaaS patří nižší počáteční náklady, automatické aktualizace a snadná integrace s jinými systémy. Vývoj SaaS zaměřuje se na uživatelsky přívětivá rozhraní, zabezpečení a zajištění vysoké dostupnosti a škálovatelnosti s cílem uspokojit rostoucí uživatelské základny.

Dokument SRS: Role v inženýrství softwarových produktů

Dokument se specifikací softwarových požadavků: Základ úspěšného projektu

Dokument SRS (Software Requirements Specification) je formalizovaná dohoda mezi zákazníkem a vývojovým týmem, která podrobně popisuje, co by měl softwarový projekt dělat, jak bude fungovat a za jakých podmínek. Není to jen seznam přání, ale projektová „bible“, která eliminuje nedorozumění a snižuje rizika. Podle standardu IEEE 830 obsahuje dobrá specifikace softwarových požadavků SRS jasné cíle, funkční požadavky, výkonnostní kritéria a systémová omezení, které tvoří základ pro úspěšný vývoj softwarových požadavků.:

1. Cíle a rozsah – proč je produkt vytvářen.
2. Funkční požadavky – co by měl systém dělat (např. „uživatel může nahrávat soubory“).
3. Nefunkční požadavky – jak to systém dělá (výkon, bezpečnost, kompatibilita).
4. Rozhraní – interakce s externími systémy a uživateli.
5. Omezení – technická nebo obchodní pravidla.

Příklad: Specifikace požadavků na prototyp softwaru pro mobilní banku obsahuje sekci „Bezpečnostní požadavky“, která specifikuje dvoufaktorové ověřování a šifrování dat.

Funkční požadavky a nefunkční požadavky: srovnávací analýza

V softwarovém inženýrství se požadavky dělí na dva typy:

Funkční požadavky definují základní logiku produktu. Například v aplikaci pro elektronické obchodování může funkční požadavek znít: „Nákupní košík musí uchovávat položky po dobu 24 hodin.“

Nefunkční požadavky však často slouží jako „záchrana“. 

Případová studie: Fintech startup zahrnutý do Dokument SRS požadavek „systém musí zpracovat 5 000 transakcí za sekundu“. Při zvýšení zátěže tento požadavek zabránil selhání systému a ztrátám zákazníků.

Cena za ignorování nefunkčních požadavků

Jejich zanedbávání je častou chybou. V roce 2022 společnost HealthCareSoft spustila softwarovou aplikaci pro kliniky bez požadavků na zálohování.

Výsledek: Havárie serveru smazala 10 000 záznamů o pacientech. Obnova trvala 1 milion $2 a šest měsíců.

Závěr: Dokument SRS není byrokracie; je to investice do předvídatelnosti. Transformuje abstraktní myšlenky do jasných pokynů pro vývojový tým a zároveň chrání rozpočet před překvapeními.

Psaní dokumentu SRS: Kroky a nástroje

Podrobný návod k vytvoření SRS

Psaní SRS se může zpočátku zdát složité. Pojďme si to rozebrat, co musí dokument SRS obsahovat, a níže uvádíme čtyři fáze, jak chaotické nápady přeměnit na strukturovanou dokumentaci:

1. Shromažďování požadavků
   • Provádějte rozhovory s klienty, průzkum trhu a analýzu uživatelských scénářů.
   • Zachyťte jak funkční („co systém dělá“), tak nefunkční („jak to dělá“) požadavky.
   • Příklad: U online bankovního produktu zahrnují požadavky zabezpečení, rychlost zpracování požadavků a integraci platebního systému.
2. Analýza a stanovování priorit
   • Zajistěte, aby si požadavky navzájem neprotiřečily ani aby si neprotiřečily obchodním cílům.
   • Použijte metodu MoSCoW: Musel mít, Měl mít, Mohl mít, Nebude mít.
3. Dokumentace
   • Požadavky na formátování pomocí šablony SRS (např. standard IEEE 830).
   • Zahrňte sekce: Úvod, Funkční a nefunkční požadavky, Rozhraní, Omezení.
4. Schválení
   • Slaďte dokument s klientem a vývojovým týmem.
   • Příklad: Dokument SRS musí být před zahájením kódování schválen zúčastněnými stranami.

Automatizační nástroje pro vývoj SRS

Pro zjednodušení procesu SRS použijte:

• Jira – pro sledování požadavků a úkolů.
• Confluence – pro ukládání a společnou úpravu dokumentace SRS.
• Helix ALM – pro správu verzí a testování.

Tyto nástroje snižují rizika ztráty dat a urychlují správu požadavků.

Příklad neúspěšné implementace SRS

Berlínský startup vyvinul software pro správu skladu. Kvůli časové tísni tým vynechal detailní požadavky na externí rozhraní. Výsledkem bylo:

• Vývojáři postavili systém na základě předpokladů.
• Klient produkt odmítl, protože uživatelské rozhraní nesplňovalo potřeby zaměstnanců.
• $30 000 a dva měsíce byly vynaloženy na redesign.

Závěr: Šetření na SRS vedlo k neúspěchu projektu.

Proč jsou chyby SRS drahé

Podle výzkumu společnosti IBM se náklady na opravu chyb v průběhu času výrazně zvyšují:

• Oprava chyby ve fázi návrhu: $1.
• Během testovací fáze: $15.
• Po vydání: $100+.

Zdroj: IBM Systems Sciences Institute, 2023.

Závěr: SRS a dokument s požadavky na systém nejsou byrokracie – je to pojištění proti finančním ztrátám. Investice času do vytvoření SRS dokumentu chrání váš projekt před nákladnými překvapeními a urychluje proces vývoje softwaru.

Vývoj IT: Funkce dokumentace SRS

Vývoj IT je víc než jen psaní kódu; jde o vytvoření produktu, který funguje v neustále se vyvíjejícím digitálním prostředí. Na rozdíl od desktopových aplikací čelí webové projekty (SaaS, e-commerce, firemní portály) jedinečným výzvám:

• Škálovatelnost – systém musí zvládat růst provozu.
• Kompatibilita napříč prohlížeči – konzistentní zobrazení v Chrome, Safari a Firefoxu.
• Integrace – platební systémy, CRM, analytické nástroje.

Například dokument SRS pro platformu pro řízení projektů SaaS může obsahovat část s požadavky, která uvádí: „Systém musí bez prodlev podporovat 1 000 souběžných uživatelů.“

Funkce SRS pro SaaS a elektronické obchodování

1. SaaS řešení:
   • Zaměření na typy nefunkčních požadavků: zabezpečení dat (šifrování, přístup založený na rolích), dostupnost 99.9%.
   • Příklad: SRS pro cloudový textový editor může specifikovat:

„Automatické ukládání každé 2 minuty.“

1. Webové stránky elektronického obchodování:
   • Záhlaví: logo, vyhledávací lišta, ikona košíku.
   • Sekce produktů: filtruje podle ceny, kategorie a hodnocení.
   • Zápatí: kontaktní údaje, odkazy na sociální média.
     
   • Důraz na požadavky UI/UX: uživatelsky přívětivý nákupní košík, integrace PayPal/Stripe.
   • Případová studie: Rozvržení hlavní stránky e-shopu zahrnuje:

Tato struktura pomáhá sladit očekávání mezi vývojáři a klienty před zahájením vývoje.

Outsourcing vývoje softwaru: Příběh úspěchu

Nizozemský startup budoval SaaS platformu pro online vzdělávání. Kvůli nedostatku vlastních zdrojů se rozhodl pro outsourcing vývoje, ale nejdříve:

• Vytvořil jsem podrobnou SRS specifikující funkcionalitu (video webináře, kvízy) a bezpečnostní dodržování (GDPR).
• Zahrnuty požadavky na benchmarking z podobných projektů.
• Definovaná očekávání výkonu: podpora 5 000 souběžných uživatelů.

Výsledek:

• Dodavatel přesně odhadl časový harmonogram a rozpočet ($150K místo původních $200K).
• Finální produkt prošel bezpečnostním auditem na první pokus.
• Startup si zajistil investici ve výši $2M díky dobře definovanému sladění MVP a SRS.

Proč je SRS vaší tajnou zbraní ve vývoji IT?

• Pro klienty: Proměňuje abstraktní myšlenky v jasnou technickou specifikaci a chrání před nespolehlivými dodavateli.
• Pro vývojáře: Snižuje počet revizí a nedorozumění.

Klíčové ponaučení: Outsourcing vývoje funguje pouze tehdy, pokud máte podrobnou strategii zabezpečení (SRS). Bez ní riskujete, že získáte produkt, který nesplňuje vaše obchodní potřeby.

Nefunkční požadavky: klíčový prvek SRS

Představte si, že vaše aplikace funguje perfektně na lokálním serveru, ale spadne, když je online 100 uživatelů. Nebo je týden po spuštění napadena hackery. Nejedná se o hypotetické hororové příběhy, ale o reálné důsledky ignorování nefunkčních požadavků (NFR). I když je funkčnost bezchybná, bez „skrytého frameworku“ je váš produkt odsouzen k zániku.

Co jsou nefunkční požadavky (NFR)?

NFR definují, jak by systém měl fungovat, spíše než co dělá. Mezi klíčové kategorie patří:

• Výkon – doba odezvy, vytížení serveru.
• Zabezpečení – ochrana dat, ověřování.
• Škálovatelnost – možnost růstu bez nutnosti přepisování kódu.
• Použitelnost – uživatelsky přívětivý design rozhraní.

Příklad: V systému online bankovnictví se funkční požadavky vztahují na převody peněz a platby, zatímco nefunkční požadavky zajišťují šifrování dat a odolnost proti útokům DDoS.

Případová studie: Jak se plýtvalo ignorováním NFR $2M

V roce 2021 spustil startup z oblasti vzdělávacích technologií online platformu pro kurzy. Jejich systém pro správu vzdělávacích potřeb (SRS) pokrýval detailní funkční požadavky (video přednášky, kvízy), ale ignoroval požadavky na výkon.

Výsledek:

• S 500 souběžnými uživateli byly servery přetížené.
• Videa se načítala do vyrovnávací paměti po dobu 10–15 sekund, což způsobovalo hromadný odchod uživatelů.
• Optimalizace havarijní infrastruktury stála $2M a trvala 4 měsíce.

Závěr: NFR nejsou volitelné – jsou základem stability

Jak definovat nefunkční požadavky v SRS?

1. Buďte konkrétní, ne abstraktní
   • ❌ Špatné: „Systém musí být rychlý.“
   • ✅ Dobré: „Doba načítání stránky musí být ≤ 2 sekundy s 1 000 souběžnými uživateli.“
2. Používejte standardy
   • Pro bezpečnost: GDPR, ISO 27001.
   • Pro výkon: SLA (příklad doba provozuschopnosti 99,91 TP8T).

Proč je to pro outsourcing důležité?

Při outsourcingu vývoje softwaru, definování NFR v SRS:

• Pomáhá dodavateli vybrat správné technologie (např. cloudová řešení pro škálovatelnost).
• Zabraňuje sporům během akceptačních zkoušek („Nespecifikovali jste požadavky na zatížení!“).
• Šetří rozpočet – oprava architektonických chyb později stojí 10–20krát více. 

Sečteno a podtrženo: Funkční požadavky odpovídají na otázky „Co?“, nefunkční požadavky na otázky „Jak?“ a „Jak dobře?“. Ignorování NFR je jako stavět dům bez základů. Ujistěte se, že vaše SRS pokrývá obojí, abyste předešli selhání produktu v nejdůležitějších chvílích.

Outsourcing vývoje softwaru: Role SRS

Představte si, že outsourcujete svůj projekt externímu týmu, jen abyste si o měsíc později uvědomili, že staví něco úplně jiného, než jste očekávali. Zní to povědomě? Stává se to při outsourcingu bez podrobného systému zabezpečení (SRS).

Proč je SRS vaším „štítem“ v outsourcingových smlouvách?

SRS není jen seznam přání – je to právně významný dokument, který:

1. Zajišťuje fixaci požadavků – zajišťuje, aby obě strany měly stejné cíle.
2. Snižuje riziko manipulace – dodavatel nebude moci „standardně“ zavést zbytečné funkce.
3. Slouží jako základ pro testování – přijetí probíhá podle jasných kritérií.

Například pokud SRS uvádí: „software musí zpracovat 100 objednávek za minutu“, ale dodavatel dodá systém, který zpracovává pouze 50 objednávek – jedná se o přímé porušení smlouvy.

Případová studie: Jak SRS zachránila $50k a reputaci společnosti

Startup z Barcelony si nechal outsourcovat vývoj softwaru pro mobilní aplikaci pro fitness tracker. Místo abstraktní technické specifikace poskytli:

• Podrobná specifikace požadavků na software (SRS) s příklady rozhraní.
• Požadavky na výkon: Synchronizace dat s Apple Health za ≤ 3 sekundy.
• Nefunkční požadavky: 24hodinový autonomní provoz.

Výsledek:

• Dodavatel nemohl nafouknout rozpočet skrytými revizemi.
• Konečné náklady projektu byly o $50K nižší než průměr trhu.
• Aplikace získala v App Storu 4,8 hvězdiček díky promyšlenému uživatelskému rozhraní.

5 rizik outsourcingu bez SRS

Pokud se rozhodnete vynechat psaní SRS, abyste ušetřili čas, čeká vás toto:

1. Posouvání termínů – Bez jasných požadavků se odhady času a rozpočtu stávají pouhou záležitostí.
2. Konflikty během přijetí – „Udělali jsme, co jste chtěli!“ vs. „Tohle jsme nechtěli!“
3. Technický dluh – Dodavatelé mohou používat levná řešení, která budou vyžadovat nákladné přepracování.
4. Ztráta znalostí – Pokud tým odejde, nový tým nebude rozumět tomu, jak produkt vyvíjet.
5. Právní rizika – Spory nelze vyřešit bez odvolání se na SRS.

Jak se chránit?

Pokud outsourcujete vývoj softwaru, postupujte třemi kroky:

1. Investujte do vytvoření SRS – Trvá to 2–3 týdny, ale ušetří vám to měsíce práce.
2. Ujistěte se, že váš dodavatel rozumí všem požadavkům a souhlasí s nimi.
3. Používejte SRS jako kontrolní seznam u každého milníku projektu.

Pamatujte: SRS není byrokracie; je to váš klíčový kontrolní nástroj. Nenechte svůj projekt proměnit v černou díru v rozpočtu!

SRS a wireframy – Vaše pojistka pro IT projekty

Představte si, že každý projekt bude spuštěn včas, v rámci rozpočtu a splní očekávání. To není utopie – je to realita pro ty, kteří investují do specifikací softwarových požadavků (SRS) a wireframů. Tyto nástroje fungují jako pojistka: neodstraní všechna rizika, ale minimalizují jejich finanční dopad.

Podle IBM každých $1 investovaných do plánování ušetří $15 na opravách chyb po vydání. SRS proměňuje abstraktní myšlenky v jasné instrukce, zatímco wireframy vizualizují koncepty ještě před napsáním jediného řádku kódu. Společně:

• Snižte potřebu revizí o 60–70%.
• Urychlete schvalování dodavatelů.
• Umožněte přesnější predikce návratnosti investic.

Co se stane, když vynecháte SRS? Nejasné požadavky, nekonečné revize, promeškané termíny – a nakonec překročení rozpočtu o 40–200%.

Závěr

Dobře strukturovaný Specifikace softwarových požadavků Dokument (SRS) zajišťuje, že software splňuje obchodní potřeby, a to popisem toho, co by měl software dělat, a podrobným popisem požadavků nezbytných pro vývoj. SRS poskytuje komplexní sadu případů užití softwaru, které přesně popisují funkční a technické požadavky, včetně omezení, za kterých musí software fungovat. Napsání dokumentu SRS pomáhá projektovým manažerům v procesu vývoje softwaru efektivně řídit požadavky a snižuje nesrovnalosti mezi dokumentem a konečnou implementací softwaru. 

Stávající SRS může sloužit jako reference pro nové projekty, zatímco vzorový nástin SRS může pomoci standardizovat proces správy požadavků. Firmy, které chtějí outsourcovat vývoj softwaru, mohou těžit z dokončení SRS před zapojením externích týmů, což zajistí přehlednost a sníží nákladné revize. Ať už vyvíjíte cloudový systém pro správu dokumentů nebo jiné komplexní řešení, formulace silného dokumentu SRS zefektivňuje procesy systému a vývoje softwaru, což v konečném důsledku šetří čas a peníze.

Nedělejte z vývoje loterii. Nechte profesionály z Camel Expert vytvořit váš SRS – pomůžeme vám formalizovat vaše nápady, připravit wireframy a vybrat správného dodavatele. Výsledek? Ušetříte až 401 TP8T z vašeho rozpočtu a spustíte svůj produkt rychleji než konkurence.

Proč platit za chyby, když jim můžete předejít? Začněte plánováním – je to jediná fáze, ve které se vaše investice zaručeně vyplatí.

Dodatek: Kontrolní seznam pro sebeověření SRS

Kontrolní seznam 1: Úplnost požadavků

✅ Všechny funkční požadavky jsou jasně popsány (např. „Uživatelé se mohou registrovat přes Google“).
✅ Jsou specifikovány nefunkční požadavky: bezpečnost, výkon, škálovatelnost.
✅ Je zahrnuta sekce „Požadavky na externí rozhraní“ (UI/UX, kompatibilita napříč prohlížeči).
✅ Omezení jsou zdokumentována (např. kompatibilita s Windows 10+).
✅ Jsou uvedeny uživatelské scénáře (případy užití) pro klíčové funkce.
✅ Zohledňují se všechny obchodní cíle klienta.

Kontrolní seznam 2: Dobrá struktura dokumentu SRS

✅ Používá se šablona SRS (např. IEEE 830 nebo ISO/IEC/IEEE 29148).
✅ Dokument obsahuje:

• Úvod (účel, soubor případů použití softwaru a role).
• Funkční a nefunkční požadavky.
• Rozhraní (API, integrace hardwaru/softwaru).
• Omezení a závislosti.
  Jsou zahrnuty příklady specifikací SRS pro podobné projekty.
  Požadavky jsou číslovány jedinečnými ID (např. FTR-001, NFR-005).

Kontrolní seznam 3: Kontrola konzistence

✅ Žádné protichůdné požadavky (např. „Systém musí fungovat offline“ vs. „Vyžaduje neustálé připojení k internetu“).
✅ Požadavky na výkon jsou v souladu s technickými omezeními (např. „10 000 požadavků/s“ na sdíleném hostingu je nereálných).
✅ Specifikace systémových požadavků jsou synchronizovány s SRS (např. kapacita serveru odpovídá pracovní zátěži).

Kontrolní seznam 4: Příprava na outsourcing

✅ SRS obsahuje kritéria přijetí (např. „Podporuje 5 000 souběžných uživatelů“).
✅ Jsou specifikovány bezpečnostní standardy (GDPR, ISO 27001 pro software).
✅ Jsou uvedeny požadavky na dokumentaci (např. uživatelská příručka v angličtině).
✅ Všechny pojmy v glosáři jsou jasně definovány (např. „autonomní provoz“ = 24 hodin bez nabíjení).

Kontrolní seznam 5: Ověření požadavků

✅ Byly provedeny rozhovory s projektovými manažery a zainteresovanými stranami.
✅ Požadavky jsou testovány pomocí scénářů případů užití (např. „Registrace → Platba → Doručení“).
✅ Zohledňují se specifikace webového vývoje: SEO, mobilní adaptace, caching.
✅ Používají se nástroje pro správu požadavků (Jira, Helix ALM).

Kontrolní seznam 6: Posouzení kvality SRS

✅ Silný SRS splňuje tato kritéria:

• Úplnost: Žádné chybějící funkce.
• Jasnost: Žádné nejednoznačné interpretace.
• Testovatelnost: Každý požadavek lze ověřit.
  Jsou zde uvedeny odkazy na podpůrnou dokumentaci (technické specifikace, dokumentace API).
  Dokument je schválen všemi stranami (vývojáři, klientem, testery).
  

Kontrolní seznam 7: Příprava na rozvoj

✅ Jasné požadavky na software jsou v souladu s vývojovým procesem.
✅ Jsou vybrány vhodné metodologie pro softwarové inženýrství (Agile, Waterfall).
✅ Je udržován aktivní dokument s možností provádění změn (např. Confluence + Jira).

Jak používat kontrolní seznamy:

1. Zkontrolujte každý bod oproti formulaci vašeho dokumentu SRS.
2. Pokud je odpověď „ne“, před pokračováním upravte SRS.
3. V případě vývoje softwaru poskytněte kontrolní seznam dodavateli jako součást smlouvy.
   

Příklad:

Pro projekt vývoje webových stránek pro elektronické obchodování zkontrolujte:

• Je integrace PayPalu zmíněna v SRS (funkční požadavek)?
• Je specifikována doba načítání stránky ≤ 2 sekundy (nefunkční požadavek)?