Technická specifikace: Projekťáci, mluvíte vývojářsky?

Stačí malé nedorozumění mezi klientem a vývojářem. Jeden „drobný“ požadavek navíc a práce na aplikaci se o měsíc protáhne. A prodraží, samozřejmě.
Proto jsme se zamysleli: Dá se tomu předejít?

Dá!

Stačí, aby mezi klientem a vývojářem byl tlumočník. Někdo, kdo mluví jazykem obou kmenů. Pochopí byznys klienta, poslechne si jeho požadavky a přeloží je do technicky přesné řeči vývojářů. 

Takový tlumočník je každý projektový manažer, který řídí vývoj aplikace nebo systému. Proto jsme si vzali do parády naše projekťáky a vysvětlili jsme jim, jak nám předávat klientské požadavky tak, aby jim rozuměl každý vývojář.

Naučili jsme je, co jsou entity i jaký je rozdíl mezi vazbou 1:N a N:N.
Díky tomu dokážou jasně a přesně popsat, co klient potřebuje, a tak předejdou nedorozumění a prodražení aplikace.

A přesně to teď naučíme i vás.

Kdo by si měl přečíst dnešní článek?

Dnešní článek je tu pro všechny, kdo řeší vývoj aplikace nebo webu:

• Projektoví manažeři.
• Obchodníci.
• Vedoucí technických týmů, kteří chtějí svému týmu usnadnit práci.
• Ale i klienti: firmy, které mají nebo plánují svou appku nebo systém.

Po přečtení dokážete technicky popsat klientské požadavky na aplikaci. Podíváte se na ni analytickýma očima a převedete potřeby klienta do řeči vývojářů, aby nedošlo k nedorozumění. 

Nebojte, vyškrtali jsme všechny složité pojmy, UML, ERD, diagramy nebo modely. Začneme pěkně zlehka a bezbolestně. 

Technická specifikace = datová + funkční (a teď to začne být zajímavé)

Zjednodušili jsme celou věc na dva základní pohledy: 

• datovou specifikaci (s jakými daty budeme pracovat)
• funkční specifikaci (co se s daty má dít)

Abychom ale uspokojili i UML puritány: O čem to mluvíme? Mluvíme o základech diagramu tříd (ERD, chcete-li) a diagramu užití (UseCase).

Ale zpátky do lidštiny.

Datová specifikace

Entity

Základní otázkou vývojářů bývá: „S jakými daty se pracuje?“. 
A tady přichází na scénu pojem ENTITA. 
Entita je datová reprezentace reálného objektu. Může být fyzická (uživatel) i abstraktní (objednávka). 
Když dokážeme pojmenovat více věcí jedním slovem, pak je možné, že jde o jednu entitu. Pokud se nám tedy do systému přihlašuje Pepa, Franta a Lojza, pak půjde o entitu Uživatel.
Dejme tomu, že chystáme nový e-shop. Náš projekťák s klientem pravděpodobně dojde k entitám Objednávka, Platba, Produkt, Kategorie produktu, Uživatel apod.

Atributy

Už víme, že v systému má figurovat například entita Uživatel. Vývojáře ale navíc zajímá, jaká data má o uživateli uchovávat. Tomu říkáme atributy. Pro každého uživatele chceme uchovávat například Jméno, Příjmení, E-mail, Heslo a Datum registrace.

Vazby 

Dobře, ale co když objednávka v e-shopu obsahuje produkty? Jsou to atributy? Nejsou. Je to vazba mezi entitami. A právě vazby jsou klíčové při odhadu pracnosti projektu (a tedy ceny). 

V tomto bodě se často setkáváme s požadavkem na změnu. Tváří se jako drobnost, ale může zabrat i několik dní. Proto je potřeba vazby dobře vydefinovat už na začátku.

Rozlišujeme základní tři typy vazeb 1:1, 1:N a N:M. 

1. Vazba 1:1 říká, že jedna entita typu A se může kamarádit jen s jednou entitou typu B. Například každé auto má jen jeden motor a každý motor může být jen v jednom autě.
2. Při vazbě 1:N se jedna entita typu A kamarádí s více entitami typu B, ale entita B může patřit pouze do jedné entity A. Například Výrobce (A) vyrábí více produktů, ale každý Produkt (B) má pouze jednoho výrobce.
3. Vazbě N:M se v angličtině říká many-to-many, tedy „více na více“. Každá entita A se může kamarádit s více entitami B a naopak. Například každá kategorie obsahuje více článků a každý článek může být ve více kategoriích.

Proč toto musíte znát?

Jeden příklad vydá za pět hodin vysvětlování:
Nedávno jsme implementovali systém pro řízení poboček kavárenské sítě. Měli jsme tedy entity Pobočka a Manažer. 
Základní zadání znělo: Každou pobočku řídí jeden manažer. Manažer může řídit více Poboček. Tedy typická vazba 1:N. Bohužel těsně po vydání aplikace přišel nový požadavek: manažeři se chtějí navzájem zastupovat a kontrolovat, tedy systém musí umět funkci „Každá pobočka má více manažerů“. 
Šlo tedy o změnu z vazby 1:N na N:M. Vypadá jednoduše, ale přidala nám pořádný kus práce a vývoj zbytečně prodražila.

Proto si zapamatujte:

Popisek: 3 typy vazeb mezi entitami 

Funkční specifikace

Než se pustíme do nové aplikace, potřebujeme vědět, jaké funkce má aplikace umět a dělat. Zajímá nás tedy, KDO může CO dělat a jaká to má OMEZENÍ. 

Už jsme si vysvětlili datový model (entity, atributy, vazby). Kromě něj potřebujeme znát také tzv. Persony. Tedy uživatele, kteří vystupují v různých rolích. U e-shopu to bude zákazník, operátor, správce kampaně a majitel. Tito odlišní lidé mají odlišná práva a operace.

Zní to složitě? Není. Stačí nám k tomu obyčejný odrážkový seznam. 
Dejme tomu, že připravujeme jednoduchý e-shop. Řekli jsme, že budeme mít entity Produkt, Objednávka, Zákazník. Funkční specifikace pak bude vypadat například takto:

• Produkt
  • Přidat / editovat / smazat – Správce
  • Vložit do objednávky (=koupit) – Zákazník (registrovaný)
• Objednávka
  • Vytvořit / odeslat – Zákazník
  • Změnit stav, stornovat – Správce
    • Pozn: při změně stavu se zašle e-mail zákazníkovi

Tak jednoduché to je. 
Teď, když znáte základy technické specifikace, jste připravení tlumočit požadavky klientů vývojářům. A že takový tlumočník je k nezaplacení. Předchází nejasnostem a nedorozuměním, která prodražují vývoj.

Když už jste u nás: Četli jste rozhovor s agilním koučem Liborem Beňkem? Dozvíte se v něm, proč se agilní přístup vyplatí všem firmám, nejen těm vývojovým.