Co je to softwarová specifikace a proč ji nepodcenit

Softwarová specifikace je jeden z nejdůležitějších dokumentů při vývoji softwaru. Přesto je to pojem, který si firmy často vykládají různě — někdy zjednodušeně jako „seznam požadavků“, jindy jako „zadání od klienta“. Jenže skutečnost je mnohem širší a hlubší. Dobře zpracovaná softwarová specifikace dokáže ochránit obě strany spolupráce a výrazně snížit riziko, že projekt narazí na časové skluz, rozpočet nebo nedorozumění.

V tomto článku podrobně vysvětlíme co to softwarová specifikace je a co naopak není, co obsahuje, proč je důležitá a komu pomáhá a jak s ní pracujeme v TRITON IT.

Co je to softwarová specifikace?

Softwarová specifikace je podrobný dokument, který popisuje, co má být vytvořeno, jak to má fungovat, za jakých podmínek bude výsledek považován za hotový a jaká rizika je potřeba zohlednit. Není to jen „seznam přání“ nebo zadání sepsané na papír. Je to formální dohoda mezi klientem a dodavatelem, ve které jsou stanovené konkrétní požadavky a očekávání — oboustranně odsouhlasené.

Tvorba specifikace bývá předmětem samostatného nacenění, protože teprve na jejím základě je možné spolehlivě stanovit cenu projektu - za předpokladu, že má být určena dopředu a je konečná. V případě volby agilních metodik vývoje se totiž celková cena může vyvíjet v závislosti na jednotlivých vývojových etapách. Proto specifikace často obsahuje podrobný popis díla a jeho architektury formou textu nebo například UML diagramy.

Co je to UML?

UML (Unified Modeling Language) je standardizovaný jazyk pro vizuální modelování softwarových systémů. Slouží k zachycení struktury, chování a architektury systému pomocí diagramů, které usnadňují návrh, analýzu a komunikaci mezi vývojáři. UML pomáhá převést myšlenky do srozumitelných modelů.

Co je to PlantUML?

PlantUML je popisný jazyk, který umožňuje textově a standardizovaně definovat UML diagramy. Zatímco UML samo o sobě představuje pouze grafickou notaci, PlantUML poskytuje způsob, jak tyto diagramy vytvářet pomocí jednoduchého kódu. To umožňuje snadnou integraci do verzovacích systémů, automatizaci dokumentace a také generování diagramů pomocí AI, například velkými jazykovými modely (LLM). Díky tomu mohou softwaroví architekti efektivněji navrhovat architekturu systémů s podporou umělé inteligence.

Cílem specifikace je odstranit nejednoznačnost. V momentě, kdy se začne vyvíjet bez přesného zadání, nastupuje domněnka, interpretace a prostor pro omyly. Dobrá specifikace nastavuje pravidla hry — pro vývoj, testování i předání.

Co všechno softwarová specifikace obsahuje?

Softwarová specifikace je přesný a detailní návod, jak má výsledek vypadat. Představte si ji jako podrobný stavební plán pro dům – když chcete dům, nestačí říct „chci dům se třemi pokoji a koupelnou“. Architekt vám musí dát plán, kde je přesně zakresleno, co kde bude, jaké materiály se použijí, kde bude světlo, elektřina, kde jsou dveře, jak silné jsou zdi atd. Stejné je to se softwarem.

1. Popis díla

Tady se jednoduše popíše, co se bude vytvářet. Jestli se jedná o webovou aplikaci, interní firemní systém, mobilní aplikaci nebo třeba evidenční nástroj. Cílem je, aby obě strany měly stejnou představu o tom, co je výsledkem projektu.

Příklad: „Webová aplikace pro rezervaci ubytování s přehledem volných termínů, správou účtů uživatelů a administračním rozhraním pro správce.“

2. Funkční požadavky

Funkční požadavky jsou seznam konkrétních funkcí, které má software umět. Co uživatel bude moci dělat – např. přihlásit se, vyhledat položku, upravit profil, stáhnout fakturu. A důležitá věc – součástí specifikace jsou i věci, které aplikace umět nebude, i když se mohou zdát samozřejmé.

Příklad:

• Uživatel se může přihlásit pomocí e-mailu a hesla.
  
• Aplikace neumožní registraci pomocí Facebooku nebo Google účtu.
  
• Administrátor může mazat uživatelské účty.

3. Nefunkční požadavky

To nejsou požadavky na funkce, ale spíše podmínky a omezení, za kterých má systém fungovat. Patří sem např. jak rychle má systém reagovat, na jakém zařízení má běžet, jaká se předpokládá zátěž systému, jaké technologie se použijí, nebo jaká data má zvládnout.

Příklad:

• Systém bude optimalizovaný pro mobilní telefony.
  
• Bude provozován na serveru klienta s operačním systémem Linux.
  
• Musí být kompatibilní s prohlížeči Chrome a Firefox.
  
• Musí zvládnout 500 současně připojených uživatelů.
  

4. Postupy vedoucí k cíli

Zde se popisuje jakým způsobem bude vývoj probíhat. Jaké kroky budou následovat po sobě, jaké milníky jsou nastavené, jak často se budou posílat reporty, kdy se bude co testovat, kdy se co předává.

Příklad:

• První fáze: návrh uživatelského rozhraní.
  
• Druhá fáze: vývoj základních funkcí.
  
• Třetí fáze: testování a ladění.
  
• Čtvrtá fáze: akceptace a nasazení do provozu.
  

5. Struktura systému

V části o struktuře systému se ukazuje, z jakých částí (modulů) se celý systém skládá a kdo v něm vystupuje (aktéři). Modul je třeba „objednávkový formulář“, „katalog produktů“, „admin rozhraní“. Aktéři jsou různí typičtí uživatelé – třeba běžný návštěvník, registrovaný uživatel, administrátor…

 Příklad:

• Modul: Rezervační formulář
  
• Modul: Přehled rezervací
  
• Aktéři:
  
  • Uživatel (provádí rezervaci)
    
  • Správce (spravuje kapacity, potvrzuje objednávky)
    

6. Nastíněná architektura

Nejde o hluboký technický návrh (ten přijde později), ale náčrt, jak bude systém uvnitř fungovat – jak spolu budou jednotlivé části komunikovat, kde bude uložená databáze, jestli bude systém rozdělen na frontend a backend, jaká bude logika mezi nimi.

Klient tím získá představu o složitosti řešení a o tom, jestli odpovídá jeho potřebám a možnostem.

7. Způsob akceptace

Jedna z nejdůležitějších částí! Tady se přesně popíše, jak bude probíhat předání díla. Co vše se musí odzkoušet, jak bude vypadat kontrolní seznam, podle kterého se ověří, že dílo je dokončené. Když je seznam odškrtnutý, není prostor pro dohady, zda je vše připraveno k předání a dílo se přijímá bez výhrad.

Příklad:

• Funguje přihlášení a odhlášení uživatele
  
• Uživatel může vytvořit novou rezervaci
  
• E-mailové potvrzení přijde do 5 minut

8. Vyjmenovaná rizika

V této části se zhodnocuje, co by mohlo způsobit komplikace – např. závislost na třetích stranách, pomalé rozhodování ze strany klienta, integrace na cizí systémy apod. Tato část je důležitá pro všechny, protože i dobře naplánovaný projekt může narazit na překážky, které je správné si předem pojmenovat.

Příklad:

• Integrace s poštovní službou třetí strany může selhat, pokud změní API.
  
• Pozdní dodání podkladů od klienta může způsobit posun termínu dodání.

Co není softwarová specifikace?

Softwarová specifikace není jen zadání od klienta. Pokud klient pošle e-mail, že chce „rezervační systém pro správu kapacit“, není to specifikace. Stejně tak to není ani seznam funkcí sepsaný v Excelu nebo myšlenková mapa či wireframe, i když tyto věci mohou být součástí specifikace.

Skutečná specifikace je kompletní dokument, který popisuje nejen funkce, ale i jejich mantinely, prostředí, testovací scénáře a podmínky převzetí. A hlavně — musí být podepsaná nebo alespoň odsouhlasená oběma stranami. Jinak nemá váhu.

K čemu je to dobré?

Pro klienta přináší specifikace zásadní výhody:

• Přesně ví, co si kupuje.
  Žádné nejasnosti, co bude a nebude dodáno.
  
• Dává rovné podmínky ve výběrovém řízení.
  Pokud se klient rozhodne oslovit více firem, může specifikaci vzít a dát ji k nacenění. Všichni pak soutěží o totéž – a ne o svou interpretaci.
  
• Brání nafukování ceny během vývoje.
  Pokud něco není ve specifikaci, může to být rozumně vyčísleno jako vícenáklad. Co je ovšem jednou zaneseno ve specifikaci, musí dodavatel vyvinout a dodat.
  
• Zajišťuje hladké předání.
  Díky akceptačním podmínkám je jasně dané, co se má otestovat a za jakých podmínek bude dílo převzato bez výhrad.

Jak to děláme u nás v TRITON IT

U větších zakázek nebo při výběrových řízeních vytváříme softwarovou specifikaci jako placenou službu. Klient ji pak může vzít a dát ji komukoliv jinému – ať si řešení nacení více firem. Pokud výběrové řízení vyhrajeme my, cenu za specifikaci odečítáme z celkové ceny. V praxi je tak specifikace pro klienta zdarma.

Zároveň nelpíme na tom, že specifikaci musíme dělat my. Pokud si ji klient připraví sám nebo s jiným dodavatelem, je to naprosto v pořádku — ale vždy ji chceme vidět. Bez ní do vývoje nejdeme.