Jak má taková specifikace vypadat? Na co si ní dát pozor a co od ní očekávat? To jsou otázky, které by si měl položit nejen analytik či programátor, ale také zadavatel úpravy/investor.
V minulém článku Specifikace webových aplikací – proč se namáhat? jsme probírali, proč má smysl psát specifikace webových aplikací podrobně a nespoléhat se jen na dobré slovo domluvené s programátorem a také, co se pak s takovou specifikací děje. Specifikaci připravuje nejčastěji analytik či programátor dle zadání od klienta. Je tedy jasné, že specifikace musí analytik i programátor perfektně ovládat – prostě vědět jak na ně. Rozumět jim však musí i klient, protože pokud nerozumí a při zadávání dojde k nepochopení, tak se potom problémy často řeší až s křížkem po funuse. Je to asi jako by klient při stavbě domu nerozuměl půdorysu dodanému stavařem a pak byl překvapen, co tady dělá ta místnost.
Cíle specifikace
Specifikace či jakákoliv jiná forma popisu úpravy se používá na několika místech v průběhu realizace úpravy:
- Ověření správnosti zadání klientem
Klient či zadavatel úpravy si může “černé na bílém” zkontrolovat, zda byl jeho požadavek pochopen a plán odpovídá jeho představám. - Zadání pro programátora
Na základně specifikace programátor provádí jednotlivé změny v aplikaci jen na základě toho, co má napsáno. - Pokyny pro testování
Tester porovnává naprogramovanou funkčnost se specifikací a hledá odchylky. - Návod
Klient dle specifikace ví, které tlačítko dělá co, kdy úpravy najde a jak s nimi může pracovat. - Dokumentace
Pokud vezmeme specifikace všech úprav, které na eshopu jsou, tak máme kompletní dokumentaci eshopu a je jasné co a jak funguje.
Máme tady celkem 5 cílů a jednu specifikaci. Ideální by bylo, kdyby pro každý účel byla vytvořena jedna specifikace a jeden popis – programátor by měl technické zadání, tester testovací scénář atp. Toto je je však problém udělat u drobných úprav, protože pak by místo například dvou hodin programování úprava zabrala po všem tom psaní a specifikování 6 hodin. Je tedy třeba vždy hledat nějakou zlatou střední cestu s ohledem na efektivitu – čím víc psaní, tím lepší zadání, ale znamená to více práce.
U nás v netdevelu to řešíme nejčastěji jednou univerzální specifikací. Mezi hlavní výhody patří rychlost přípravy a také konzistentnost – nikdy se nestane, že v pokynech pro testera jě něco jiného, než pro programátora. Nevýhodou může být, že různí lidé (především klienti) mají i zbytečné informace, tomu ale předcházíme tím, že technické detaily dáváme do speciální sekce specifikace.
Struktura specifikace
1) Anotace
Nejjednodušeji lze říci, že anotace je krátký popis úpravy z obchodního pohledu. Pro klienta jde o nejdůležitější část, protože by měla reprodukovat jeho potřeby tak, aby byly srozumitelné všem. Cílem je, aby všichni zúčastnění pochopili, k čemu daná úprava bude a k čemu má sloužit bez zbytečných detailů a popisů. Často stačí pár slov např. “Cílem úpravy je zdůraznit možnost nákupu příslušenství” – zda tam budou tlačítka nebo nový box na detailu zboží je už popsáno dále ve specifikaci. Anotace slouží i k tomu, aby se programátor mohl s úpravou ztotožnit, aby věděl, že to, co dělá, má smysl a pochopil význam a souvislosti.
2) Administrace a zákaznické prostředí
Jde o hlavní část specifikace, kde je do detailu popsáno, jak se daná úprava bude na eshopu projevovat. Je rozdělena do dvou sekcí – administrace a zákaznické prostředí. Rozdělení je z praktického důvodu, aby se vše nepletlo dohromady. Nejprve je popsáno, jak se daná úprava projevuje v administrační části eshopu. Je to prakticky zároveň i návod pro klienta, jak si pak danou úpravu nastavit a používat. Pak je teprve vysvětleno, jak se úprava projevuje v zákaznickém prostředí a co zákazník uvidí a kdy.
Spousta prvků se prolíná napříč administrací i zákaznickým rozhraním, takže občas na sebe jednotlivé části odkazují či je někdy jedna část vynechána (pokud například žádné nastavování není k dispozici).
3) Napojení na IS
Zde je rozepsáno, jak se tato úprava projeví v napojení na informační systém (Pohoda, Money, SAP atp.), pokud je eshop na takový propojen (což bývá velmi často). V předchozí části je zmíněno, co se přenáší z IS, ale zde je popsáno do detailu, jak. Tato část bývá především technická a ve specifikaci i pro klienta je proto, že napojení často závisí na třetí straně (implementatátorovi IS), který potřebuje tyto detaily vědět.
4) Akceptační kritéria
Akceptační kritéria představují shrnutí celé úpravy ve stručných bodech. Jde o kontrolu pro programátora, zda na nic nezapomněl, a slouží hlavně pro zdůraznění, co jsou hlavní prvky úpravy. Jde spíše o doplňkový prvek celé specifikace, ale umožňují ukázat, co jsou hlavní funkce v úpravě. Často se nepředstavují přímo klientovi, ale požívají se pouze interně – ne vždy je schopen klient akceptovat, že v kritériích není “úplně vše”. Jsou ale dobrým nástrojem, jak si i v dlouhém zadání udělat jasno a vypíchnout, co je základ úpravy a co jsou jen vylepšení.
Pro ilustraci zde přikládám příklad stručné specifikace úpravy Stránkování v administraci:
Z článku by si každý zadavatel úprav měl odnést, že i když je specifikace dlouhá, tak ji stojí ze to číst (a to zejména před schválením). Že to není jen text pro programátora, ale že s ním bude pracovat několik různých lidí, z nichž každý hledá něco jiného. Navíc by měl vědět, co má ve specifikaci hledat – nejdůležitější je anotace, kde je popsáno, co je cílem úpravy a k čemu to celé vlastně je. Věřím, že se vám bude dále se specifikacemi pracovat snadněji.
