Výhoda: získat znalosti o tom, co jsou technické specifikace a jak je sestavit. Obohaťte svou slovní zásobu o slova: koncepční model, datový tok, myšlenková karta, uživatelský tok. případy použití, drátové modely, ER-model, klient-server, API.
Pro koho: pro začínající vývojáře a ty, kteří chtějí být pochopeni (zákazníci, startupy a manažeři).
Čas na čtení: 7 minut.
Východisko – požadavky
Panuje mylná představa, že stačí říct: „Potřebujeme aplikaci do muzea/kočky/továrny“ a hned je jasné, co potřebujete.
Bohužel to není tak jednoduché. Představte si, že potřebujete postavit dům. Jdete za stavitelem a ten se pustí do práce. Neposkytli jste mu žádné výkresy ani pozemek, dokonce jste mu neřekli, jakou barvu má plot mít. Ale dali mi šest měsíců a značné množství peněz, abych všechno udělal.
Strašidelné, že? Rozpočet je již vyčerpán a termín vypršel.
Aby k tomu nedocházelo, jsou všechny požadavky na produkt pevně dané a zde začíná veškerý vývoj.
Pohodlný typ požadavků – technické specifikace
Pokuta. Budou požadavky. Nyní vám vývojáři určitě porozumí. Zde však nastává úskalí č. 1: lidstvo se ještě nenaučilo číst myšlenky. Proto je nutné informace v nějaké formě předávat a nejlepším způsobem k tomu je Zadání.
Říká se mu také technická specifikace, SRS, PRD – to vše jsou názvy dokumentu, ve kterém jsou ve správné podobě zaznamenány požadavky na výrobek.
Úskalí č. 2: paměť člověka není neomezená, vždy je lepší mít jedno místo, kde se zaznamenávají všechna vaše přání a požadavky (ne korespondence v telegramu nebo telefonátu). Technickou specifikací je proto tištěný textový dokument s připojenými schématy a infografikou, nikoli ručně psaný nebo fotografovaný. Nejlépe ve formátu .PDF nebo Google Docs.
Recept na kompetentní technické specifikace
Technická specifikace pro vývojáře je jakýmsi receptem na přípravu úspěšného produktu. Úspěšný produkt je takový, který se snadno udržuje, lze jej vyvíjet a měnit, nerozpadne se při změně vývojáře a přináší zisk v jakékoli podobě. Chcete, aby byl váš projekt kompletní? Skvělý. Napište na to dobrý recept. Klasické přísady (podle mezinárodního standardu IEEE-830) jsou:
- konceptuální model
- Funkční mapa
- Cesta uživatele
- Uživatelské rozhraní
- Softwarová rozhraní
- Nefunkční požadavky
Níže se budu podrobně zabývat každým bodem. Pro ty, kteří nechtějí podrobně rozumět, nechávám odkaz na mezinárodní normu se šablonou technické specifikace: odkaz na dokument.
konceptuální model
Tento odstavec obsahuje stručný popis produktu, který odráží účel projektu a jeho charakteristické rysy.
Například: „Seznamovací aplikace, kde můžete sledovat krátká videa na uživatelských profilech a chatovat.“ Také by neuškodilo říci pár slov o publiku produktu, aby projektový tým porozuměl jeho funkcím a dal vám užitečné rady. Řekněte nám o jeho stáří, charakteru a územním umístění, některých vlastnostech, které by se měly v projektu promítnout.
Například: “Jsou to mladí lidé, kteří cestují na dovolenou do zahraničí a mají zájem komunikovat za jazykovou bariérou, rádi fotí a natáčí.”
Stojí za to mluvit o typech uživatelů a jejich klíčových rozdílech.
Například: „Aplikace by měla mít pravidelné uživatele a moderátory, kteří dostávají stížnosti od uživatelů na obsah nebo profily. Moderátoři mohou po stížnosti zobrazit chat běžných uživatelů a zablokovat porušující účet ze služby.“
Nakonec nám řekněte o složkách vašeho produktu.
Například: admin panel používaný moderátory; mobilní aplikace, kterou uživatel používá k registraci, přidávání obsahu, účasti na chatu atd.
Nejlépe uděláte, když si uděláte tzv. datový tok neboli kontextový diagram, který bude odrážet, jak uživatelé interagují s produktem, jeho komponentami a mezi sebou navzájem.
Funkční mapa
Funkční mapa zobrazuje celkový koncept projektu s mírou detailů potřebnou k odhadu množství práce a stanovení priorit.V tradičním formátu taková mapa připomíná mapu webu. Nejpohodlnější je ale vystavit jej ve formě myšlenkové karty. Manažeři často na poradě kreslí slova a souvislosti mezi nimi na tabuli nebo papír, takže jde o myšlenkovou mapu. To lze pohodlně provést v bezplatných službách (coggle, draw.io a mindmeister) nebo jednoduše v Office Word.
Je velmi důležité promítnout všechny uživatelské funkce do funkční mapy. Pro první přiblížení se jedná o jednoduchou sadu funkcí produktu.
Například: „Aplikace by měla obsahovat registraci poštou, vytváření a vyplňování profilových údajů, možnost nahrávat a upravovat fotky a videa, seznam účtů ostatních uživatelů s různými typy filtrů, textový chat a kontaktování podpory.
Cesta uživatele
Takzvaný uživatelský tok nebo uživatelská cesta je sekvenční seznam akcí nebo obrazovek, kterými může uživatel procházet v procesu interakce s produktem. Popište, jak ve vaší vizi bude uživatel s produktem komunikovat. Velmi pohodlně to lze provést také pomocí myšlenkové mapy nebo jednoduše seznamu akcí.
Například: „Uživatel se přihlásí do aplikace, aby se setkal s vrstevníky. Vyplní svůj profil daty a nahraje fotky a videa. Poté uživatel přejde na zdroj a vyfiltruje jej podle určitých kritérií. Díky tomu obdrží seznam relevantních profilů, může si je prohlédnout a napsat dalšímu uživateli do chatu.
Cesta uživatele je obecný algoritmus pro práci s produktem. Existují také případy užití (případy užití) – to je podrobný popis uživatelského toku. V případě mobilní seznamovací aplikace vytvoříte cestu uživatele napříč obrazovkami a poté popíšete, co může uživatel na každé obrazovce dělat.
Například: Na registrační obrazovce může uživatel:
přejděte na autorizační obrazovku; zaregistrujte se přes sociální sítě (Facebook, Twitter); můžete zadat svůj e-mail a heslo, poté to zopakovat a potvrdit registraci v dopise zaslaném na váš e-mail.
Uživatelské rozhraní
Výrobek by měl nejen fungovat, ale také hezky vypadat. Odbočme trochu od tématu aplikací, abychom vás nenutili stahovat je k recenzi. Pojďme se podívat na pěkné stránky:
Popište obecně, jak chcete, aby váš produkt vypadal, jaké by měl mít barvy, jaké prvky použít, jakou chcete animaci atd. Pokud máte firemní identitu nebo knihu značek, skvělé, odkaz na ně.
Návrháři vám velmi poděkují, pokud určíte styl designu rozhraní, jako je plochý design nebo materiálový design.
Akrobacie by spočívala v přidání drátěných modelů – prototypů rozhraní produktu ve formě přibližných schémat.
Softwarová rozhraní
Tato sekce je pro specialisty. Pokud jste si jisti svými schopnostmi, tak pokračujte ve čtení Nejlepší technická specifikace popisuje i architekturu produktu, tedy z jakých softwarových komponent se skládá. V případě seznamovací aplikace klient-server je služba rozdělena na serverovou část, která ukládá a zpracovává data, provádí některé logické operace, a klientskou část, která data zobrazuje.
Server je rozložen na moduly: databáze, autentizace, chat atd. Klient se serverem komunikuje přes API (rozhraní přenosu dat), vyplatí se uvést jeho typ (REST, WEB, RPC atd.) a popsat způsoby, reakce a řešení chyb.
Data jsou v databázi obvykle ukládána ve formě speciálních struktur, nejčastěji tabulek (pro relační databáze) a json struktur (pro nerelační). Vývojáři vám velmi poděkují, pokud v technických specifikacích uvedete databázové entity (ER-modely) a popíšete uložená pole s uvedením jejich datových typů (string, int atd.), klíčů (primárních, cizích), požadavků ( povinné) ) a prázdnou hodnotu (s možností null).
Nefunkční požadavky
Toto jsou obecné požadavky na produkt. Lze je rozdělit na hardwarové požadavky, požadavky na bezpečnost a požadavky na výkon Hardwarové požadavky vyjadřují přání pro zařízení a operační prostředí, například u seznamovací aplikace je to Android 7.0+ a JDK 8+, iOS 11.0+ a Swift 4.2 .
V požadavcích na zabezpečení můžete určit, že přenos dat v chatu má být prováděn pomocí šifrování SHA-1 a že při registraci musí být složitost hesla minimálně 8 bitů Požadavky na výkon hovoří o připojení komponent a odolnosti proti chybám například stojí za to uvést, že časový limit netrvá déle než 1 sekundu pro přečtení chatové zprávy a že aplikace částečně ukládá mezipaměť a může po omezenou dobu pracovat offline.
Všechny úspěšné IT produkty byly kdysi jen nápady. A velmi často (téměř vždy) nápady patří lidem, kteří mají k vývoji softwaru a hardwaru daleko.
Chtějí něco zlepšit ve svém podnikání v oblasti činnosti, kterou důkladně znají. Nápady, myšlenky, sny jsou úžasné, ale je důležité, aby jim specialista správně porozuměl a převedl je do fungujícího zařízení nebo programu.
Technické specifikace pomohou správně uvést myšlenku do vývoje. Proč připravovat technické specifikace, kdo a jak to má dělat, je možné se obejít bez technických specifikací a jak minimalizovat náklady – o tom všem se dozvíte z tohoto článku.
Proč psát technickou specifikaci?
Technická specifikace pro vývoj zařízení nebo softwaru je dokument, který definuje požadavky na IT produkt, včetně jeho účelu, funkcí, chování, použitých komponent, technologií, vývojových nástrojů a také postupu při provádění práce. Výkaz práce slouží jako vodítko pro obchodní a technické týmy podílející se na tvorbě IT řešení.
Technické specifikace jsou stejně potřebné pro zákazníka i vývojáře. Specifikace je dílem specialistů z různých oborů a je využívána zadavatelem i zhotovitelem po celou dobu vývoje i po ukončení projektu.
Technická specifikace pro návrh zařízení nebo softwaru pro zápis umožňuje získat předběžný odhad nákladů na vývoj produktu
Náklady na složité zařízení nebo aplikaci nelze předem odhadnout. Je třeba vzít v úvahu mnoho bodů – mzdové náklady specialistů, náklady na komponenty a logistiku, práce související s certifikací atd. Dobře zpracovaný dokument umožňuje jak zhotoviteli, tak zákazníkovi vidět a zhodnotit jak celý proces vývoje, tak jeho jednotlivé fáze. Zákazník tak získá představu o předběžných nákladech každé fáze práce. Přesnější údaje budou uvedeny v odhadu projektu.
V technické specifikaci jsou uvedeny přibližné termíny realizace zakázky. Klient a outsourcingová společnost nebudou mít neshody ohledně načasování, pokud dokument uvádí časové úseky pro každou fázi projektu od samého začátku.
Termíny dokončení prací na návrhu elektroniky a vytvoření softwaru se mohou z různých důvodů zpozdit. Některé z nich – například čekací dobu na komponenty a dodací lhůty – lze předvídat již ve fázi psaní technických specifikací.
Pro zákazníka bude jednodušší zhodnotit hotové řešení – elektronické zařízení, software nebo hardwarově-softwarový systém – porovnáním s popisem v technických specifikacích. Proto musí být technická specifikace vypracována kvalifikovaně a co nejpodrobněji.
Dobře napsaná technická specifikace pro vývoj zařízení nebo softwaru může naznačovat kompetenci a zkušenosti specialistů. Promyšlený přístup vývojářů k přípravě projektu, jasné a komplexní informace v technických specifikacích hovoří o celkové úrovni služeb společnosti.
Spolupráce může být z toho či onoho důvodu přerušena nebo zmražena – kvůli finančním a právním potížím, geopolitické situaci, neshodám mezi stranami, vážným logistickým problémům atd.
S dobře zpracovanou technickou specifikací pro vývoj IT produktu je pro zákazníka snazší vrátit se ke spolupráci s outsourcingovou společností nebo najít nového dodavatele.
Technická specifikace popisuje samotný produkt, jeho účel a funkčnost, dále fáze vývoje, základní elektronické prvky a nástroje pro tvorbu softwaru. Zákazník i vývojář tak dokonale rozumí navrženému IT řešení, což slouží jako pojistka proti neshodám, nedorozuměním a neplánovaným změnám v konceptu produktu.
Práce na projektu jde rychleji a snadněji, když se vývojový tým spoléhá na technické specifikace. Není potřeba koordinovat každý krok, ztrácet čas.
Je to možné bez technických specifikací?
Psaní technických specifikací je náročný proces, který vyžaduje vysokou kvalifikaci a samozřejmě stojí peníze. Ve snaze snížit náklady na projekt se může zákazník rozhodnout napsat technické specifikace samostatně nebo odmítnout sepsání dokumentu úplně. Je možné se obejít bez technických specifikací – vysvětlit slovy, ukázat vzorek zařízení, desky nebo aplikace, požádat o zhotovení podle šablony?
Jakýkoli, i velmi malý standardní projekt vyžaduje přípravu specifikace – dokumentu, který bude zaznamenávat požadavky na vyvíjené řešení, pořadí prací, použité komponenty atd. Nepůjde o technickou specifikaci v klasické podobě, ale bez specifikace se vůbec neobejde.
Klient může poskytnout dokument, ve kterém jsou uvedeny jeho představy, přání a vize produktu v jakékoli podobě. Kompetence klienta v otázkách designu a programování bude velkým plusem, ale hlavní je jasně a jasně formulovat svá přání k produktu. Vývojářská společnost na základě takového vysvětlení vytvoří plnohodnotnou kvalitní technickou specifikaci, která bude sloužit jako vodítko při následném vývoji.
Jak napsat technickou specifikaci
Technická specifikace obsahuje mnoho předmětových dat a podrobný popis procesu vývoje. Čím složitější je úkol, tím více specialistů se bude podílet na psaní technických specifikací a tím více informací bude v hotovém dokumentu.
Kdo připravuje specifikaci?
Vývoj technických specifikací pro návrh zařízení nebo vytváření softwaru provádějí specialisté, kteří znají všechny nuance vývoje a jak bude projekt dokončen – fáze práce, termíny, komponenty a konečný produkt. Jsou to PM, vývojáři, testeři. Každý z nich přispívá svými vlastními informacemi do technické specifikace a vytváří celkový obraz projektu.
Psaní technických specifikací můžete svěřit specialistům z řad zaměstnanců vaší společnosti, kteří vědí, jaký produkt potřebují, a mohou v dokumentu podrobně uvést požadované funkce a vlastnosti zařízení nebo programu. Často ale taková úspora vede k dvojnásobné práci, ztrátě času a peněz.
Zadávací podmínky vytvořené developerskou společností zohlední nejen všechna přání klienta, ale také možnosti zhotovitele (odbornost ve vývoji, zkušenosti s komponentami, nástroji a používanými programovacími jazyky atd.). Všechny body technické specifikace budou odsouhlaseny stranami a schváleny zákazníkem tak, aby jako výsledek spolupráce klient obdržel produkt, který splňuje všechny požadavky.
Co by mělo být v technické specifikaci?
Technické specifikace jsou vypracovány pro konkrétní projekt a jsou zpravidla jedinečné. Přesto existují body, které jsou v té či oné podobě přítomny ve všech technických specifikacích pro vývoj softwaru, elektroniky a hardwarových a softwarových systémů.
Termíny, zkratky a definice
Termíny použité v textu jsou uvedeny na začátku dokumentu. Mohou to být jak IT pojmy – názvy prvků, prostředí a programovací jazyky, technické definice – tak i slova a označení z oblasti, pro kterou je IT řešení určeno. Čím pečlivěji je seznam odborných slov promyšlen, tím lépe si bude zhotovitel a zákazník rozumět.
Účel produktu
Tento blok popisuje účel IT řešení, cíle jeho tvorby a cílové publikum.
Primární cíle mohou zahrnovat zvýšení zákaznické základny, pozitivní image firmy, zvýšení produktivity práce, omezení manuálních operací atd.
Odstavec obsahuje také informace o úkolech projektu – to může být vývoj od začátku a na klíč, účast na samostatné fázi tvorby (například práce na softwaru pro hotový hardware) nebo vylepšení stávajícího produktu.
Cíle musí být konkrétní a srozumitelné, aby konečný produkt co nejlépe vyhovoval požadavkům a byl pro zákazníka užitečný.
Požadavky projektu
Základem specifikace, její nejvýznamnější a nejpodrobnější části, jsou požadavky na projekt. Blok požadavků zpravidla obsahuje následující podsekce:
Obecné požadavky určit posloupnost vývojového procesu.
Takto například vypadají obecné požadavky projektu v zadání pro vývoj softwarového systému pro řízení zařízení.
Vývoj ovladače pro ovládání zákaznických zařízení Ovladač musí být nainstalován na každém zařízení.
Vytvoření ovládacího panelu zařízení pomocí jednodeskového počítače se systémem Linux.
Vývoj aplikace pro dálkové ovládání.
Integrace ovládacího panelu a ovladače do jednoho řídicího systému.
Možná vylepšení a úpravy systému.
Funkční požadavky se týkají funkcí a chování IT řešení. Příklad:
Systém by měl zasílat upozornění na poruchu zařízení.
Systém musí monitorovat senzory.
Systém musí přenášet data přes rádiový kanál.
Systém musí mít alarm.
Systém musí ovládat všechny funkce zařízení.
Nefunkční požadavky definovat kritéria, jako je výkon, škálovatelnost, udržovatelnost, bezpečnost produktu a mnoho dalšího.
Požadavky na vývoj lze prezentovat v několika odstavcích, které podrobně popisují fáze práce a použité komponenty a nástroje.
Například v zadávacích podmínkách pro vývoj softwarového a hardwarového komplexu může být klauzule popisující požadavky na vývoj zařízení, komunikačních protokolů (MQTT, TCP atd.) a uživatelské aplikace pro ovládání přístroj.
Požadavky na organizaci a kvalitu práce určit, jak bude práce na projektu organizována, komunikace mezi zákazníkem a zhotovitelem, dále hlavní body týkající se kvality systému, zařízení nebo softwarového produktu – doba nepřetržitého provozu, chování systému v případě nouze atd. .
Bezpečnostní požadavky může obsahovat požadavky na ochranu kódu, řízení přístupu, práva atd.
Kromě hlavních bodů obsahuje technická specifikace jednotlivé bloky pro konkrétní projekt, například popis rolí pro řízení přístupu, požadavky na rozhraní, požadavky na velikost a vzhled zařízení.
Co je dobrá technická specifikace?
Jaká by měla být kvalitní technická specifikace pro vývoj zařízení a softwaru: jedna nebo padesát stránek napsaných v šablonových frázích nebo pomocí technického slangu, s obrázky nebo bez?
Technická specifikace musí být v první řadě napsána jednoduchým a srozumitelným jazykem, protože ji budou studovat nejen techničtí specialisté, ale také obchodní manažeři a tým zákazníka. Bez technických výrazů se samozřejmě neobejdete, ale neměli byste jimi přetěžovat text. Schémata, výkresy, tabulky nejsou vyžadovány, ale jsou velmi žádoucí. Grafické prvky předávají informace vizuální a srozumitelnou formou.
Velikost technických specifikací závisí na rozsahu a složitosti projektu. Čím větší projekt, tím více přípravných dokumentů. Zadání pro vývoj systému správy baterií, na kterém bude práce trvat déle než jeden rok, nemůže být jednostránkovým dokumentem. Ale i u rozsáhlých projektů se při psaní technických specifikací musíte snažit o rovnováhu stručnosti, přehlednosti a informačního obsahu.
Co může vyplynout z frivolního přístupu k vypracování a studiu specifikace? Minimálně dodatečné časové náklady, maximálně neshody mezi stranami a obdržení produktu, který nesplňuje požadavky zákazníka. Aby se takovým momentům vyhnul, musí zákazník věnovat čas i technické specifikaci – zúčastnit se projednávání specifikace a ponořit se do hotového dokumentu.
Psaní technických specifikací je lepší svěřit profesionálům – těm, kteří budou vyvíjet IT řešení. Můžete za nimi přijít s nápadem, i když netušíte, jak jej realizovat. Dobrá technická specifikace ušetří čas, peníze a nervy jak klientovi, tak developerovi.
Chyby při sestavování specifikací
Při sestavování technických specifikací je důležité vyvarovat se běžných chyb. Pojďme si některé z nich uvést.
Nedostatek slovníčku pojmů
Ve specifikaci od zákazníka: Virtuální asistent poskytuje hlasovou interakci, přehrávání Mx přehrávače, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna, poskytuje informace o EPL, MLB, NBA, NHL atd.
To by mělo být: Virtuální asistent zajišťuje hlasovou interakci, přehrávání hudby (Mx player, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna), poskytuje informace o sportovních událostech (EPL, MLB, NBA, NHL atd.).
Hudební služby: Mx přehrávač, Spotify, TuneIn, Audible, Pandora, Hungama, Ganna.
Zkratky sportovních svazů:
EPL – anglická Premier League
MLB – Major League Baseball
NBA – Národní basketbalová asociace
NHL – National Hockey League
Nejasná a nejasná formulace
Ve specifikaci od zákazníka: MIDI, představený v roce 1983, je standardem pro mnoho existujících produktů a aplikací. MIDI definuje nejen protokol pro výměnu hudebních dat, ale také hardwarové připojení sloužící k fyzické výměně dat. Přenos MIDI dat přes jiné připojení, jako je USB, se bude nazývat USB-MIDI.
To by mělo být: Formát MIDI (Music Instrument Digital Interface) umožňuje standardizaci hudebních zařízení od různých výrobců.
Protokol zajišťuje přenos dat v digitálním formátu mezi zařízeními, umožňuje přehrávání hudby a ovládání provozu pomocných zařízení (pyrotechnika, osvětlení atd.).
Popis přeplněný detaily
Ve specifikaci od zákazníka: Formát GS je soubor pokynů vytvořených společností Roland za účelem standardizace výkonu zařízení pro reprodukci zvuku. Podporuje všechny funkce uvedené v General MIDI System. Kromě toho vysoce kompatibilní formát GS poskytuje větší rozmanitost zvuků, umožňuje editaci zvuku a definuje řadu funkcí pro širokou škálu pokročilých funkcí, jako jsou efekty chorus a reverb.
Formát GS byl vytvořen s ohledem na budoucnost, takže je snadné přidávat další zvuky a podporovat nové hardwarové funkce, jakmile budou k dispozici. Může být upraven tak, aby fungoval se systémem General MIDI. Výsledkem je, že formát GS společnosti Roland dokáže věrně reprodukovat obecné MIDI skóre i hudební data GS (hudební data zaznamenaná ve formátu GS).
To by mělo být: Formát Roland GS je rozšířením General MIDI standardu pro sjednocení charakteristik audio zařízení.
Díky podpoře všech funkcí uvedených v General MIDI System je standard rozšířen o nové nástroje, efekty a funkce.
Zmatky ohledně funkčních a nefunkčních požadavků
Ve specifikaci od zákazníka: Systém musí udržovat teplotu vody v topné nádrži maximálně 50°C.
To by mělo být: Funkční požadavky: Systém musí udržovat teplotu vody nastavenou uživatelem. Nefunkční požadavky: Teplota vody v topném zařízení by neměla překročit 50°C.
Závěr
Vývoji IT řešení – elektronického zařízení, aplikace, vestavěného softwaru nebo IoT systému – předchází sepsání technické specifikace. Může to být stručná specifikace nebo velká seriózní technická specifikace – vše závisí na rozsahu a složitosti projektu. Technická specifikace dává představu o účelu a funkcích produktu, požadavcích na vývoj, postupu prací a postupu při převzetí hotového řešení.
Technická specifikace je výsledkem kolektivní práce projektového manažera, vývojářů, testerů a samozřejmě zákazníka. Psaní technických specifikací je složitý proces, který vyžaduje, aby vývojáři měli znalosti a odborné znalosti v oblasti vývoje softwarových a hardwarových řešení, rozuměli trhu s elektronickými součástkami, vyhodnocovali logistické trasy a také jasně prezentovali informace. Je lepší, když technické specifikace napíše vývojová společnost s přihlédnutím ke všem požadavkům zákazníka a jeho odbornosti. Vývoj produktu pak půjde rychleji a pohodlněji jak pro dodavatele, tak pro zákazníka.
