Správné technické specifikace pro vývoj softwaru jsou tajemstvím úspěšného projektu. Vývoj technických specifikací. Co to je, proč je to potřeba, kde začít a jak by to mělo vypadat? Úkol pro vývoj technických specifikací

Co je to technická specifikace? Jak na to a k čemu to je? Příklady, vzorky, tipy a doporučení.

Zdálo by se, jak skvělé je, když vám někdo dokonale rozumí. Dal jsi pár frází a tady to je, přesně to, co sis představoval. Bohužel to tak nefunguje.

Problém vnímání informací je věčný. Efekt „rozbitého telefonu“ je běžný jev. Ale co když prostě nevíte, jak zadat úkol? Ano, i to se stává a je potřeba s tím nějak pracovat, ale jak? Abyste zajistili, že výsledky vámi nastavených úkolů splní vaše očekávání, napište technickou specifikaci.

Co je to technická specifikace

Technická specifikace (nebo TOR) je dokument, který obsahuje požadavky zákazníka na produkty nebo služby poskytované dodavatelem. Jednoduše řečeno: Chci mít sedm vzájemně kolmých čar a také nakreslit některé červeně a některé nakreslit bezbarvě (doporučuji zhlédnout video na toto téma na konci materiálu).

Oddělení designu

Tento dokument může zabírat buď jednu stránku A4, nebo celý svazek, vše závisí na úkolech a přáních, které jsou v něm obsaženy. Můžete například napsat technickou specifikaci pro malou vstupní stránku (jednostránkový web) nebo pro složitý software se strojovým učením a dalšími funkcemi.

Proč potřebujete technické specifikace?

• Přidělovat úkoly účinkujícím.
• Chcete-li podrobně popsat, co chcete na konci získat.
• Dohodnout se na pořadí prací.
• Zhodnotit a přijmout práci po realizaci.
• Do...(doplňte své možnosti do komentářů).

Ve skutečnosti existuje mnohem více účelů a výhod technické specifikace než ve výše uvedeném seznamu. Pro mě osobně je hlavním úkolem, který technické specifikace řeší, implementace toho, co potřebuji s minimálními odchylkami od očekávání (mých očekávání).

Díky technickým specifikacím se můžete vždy zeptat na čas realizace, peníze a dodržení deklarovaných vlastností finálního produktu nebo služby.

Ve skutečnosti se jedná o seriózní dokument, který sestavuje zákazník a zhotovitel. V rozsahu, v jakém jsou stanoveny sankce a povinnosti stran. Existuje celá řada GOST, čtěte více na Habré.

Vývoj technických specifikací

Pokud mluvíme o „dospělé“ hře, například o technickém úkolu pro vývoj mobilní aplikace nebo webu, pak se jedná o samostatnou práci, za kterou se platí hodně peněz. Přilákáte osobu, obvykle bývalého nebo současného technického ředitele, a požádáte ho, aby vám pomohl.

Mít vousy je volitelné

V závislosti na rozsahu projektu/úkolů tato osoba shromáždí všechna vaše „přání“, přeloží je do odborného jazyka, možná připraví skici (jak by to přibližně mělo vypadat) a předá vám hotový dokument. Dále předáte tento dokument účinkujícím (týmu ve vaší společnosti nebo externě), dohodnete se na penězích, termínech a pustíte se do práce.

Tip: CTO by měl být ve vašem týmu, jinak vám s největší pravděpodobností během implementace něco unikne. Na všechno prostě nemáte dostatek znalostí. Kdo se podílel na psaní technických specifikací, kontroluje je.

Z čeho se skládá technická specifikace?

Vše bude záviset na šabloně, kterou si vyberete (o něco dále dám nějaké odkazy na šablony/příklady), ale v technických specifikacích jsou zahrnuty základní bloky:

1. Popis projektu/úkolu. Stručně napíšeme, jaký je projekt nebo úkol, který je potřeba dokončit.
2. Účel a cíle. Jaké jsou cíle projektu?
3. Požadavky. Design, funkce, technologie, které jsou potřeba.
4. Popis práce. Co, kdy a jak se bude dělat.
5. Kontrolní a akceptační řízení. Jak bude dílo přijato, co lze považovat za dokončené.
6. Aplikace. Skici, skici, prototypy.

Cena díla je obvykle zahrnuta v samostatné příloze smlouvy, ale stane se tak, když si strany uvedou částky v technických specifikacích samy.

Omlouvám se za přerušení čtení. Připojte se k mému telegramovému kanálu. Čerstvé oznámení článků, vývoj digitálních produktů a hack pro růst, to vše je tam. Čekám na tebe! Pokračujme...

Příklady technických specifikací

Navzdory skutečnosti, že vývoj technických specifikací je složitý proces, je velmi zajímavý. Vaším úkolem je znovu vytvořit obrázek konečného výsledku a poté jej po částech popsat.

Příklad jednoho z mých zadání pro aktualizaci aplikace Smart TV. Úkoly pro složitější a složitější produkty byly sestaveny za pomoci kolegů z technického oddělení. Neváhejte požádat o pomoc své spoluhráče, zapojte je do procesu co nejčastěji. A nezapomeňte dát zpětnou vazbu! Není nic horšího, než dát do něčeho úsilí a čas, aniž byste znali výsledky. Řekněte nám, jak byly rady toho člověka užitečné ve vaší práci, jinak je to jednostranná hra.

Referenční podmínky pro rozvoj internetového obchodu

Zadání pro vývoj mobilní aplikace

Referenční podmínky pro web

Referenční podmínky pro služby/aktualizace

Pokud potřebujete další vzorky, stačí si to vygooglit.

Hlavním doporučením je to udělat. Potíž je v tom, že mateřská lenost přemůže každého a není snadné jí odolat. Seberte veškerou svou vůli a začněte psát technické specifikace, prostě pište a nepřestávejte. Nebojte se, že to nevyjde „dokonale“, řeknu vám tajemství, tohle se nikdy nestane. Stačí napsat, bude to pokaždé lepší a lepší.

Tak to má být

Moje první základy pro psaní technických specifikací se začaly objevovat před několika lety. Spolupracoval jsem s designéry a měl jsem za úkol vytvářet kreativy pro reklamní kampaně. Chtěl jsem to nesouvisle a změnilo se to na spoustu ztraceného času a vysvětlování. Postupem času se zadávání úkolů začalo měnit v jakési sémantické bloky a následně v něco jako technickou specifikaci.

Například pro úkol „Tlačítko To se mi líbí na webu“:

1. Popis: na našem webu musíte vytvořit tlačítko „To se mi líbí“.
2. Účel a cíle: zapojení uživatelů, vydávání/hodnocení materiálů na základě počtu lajků.
3. Požadavky: následující design (příklad: odkaz na něco podobného), funkčnost (obrázek může hodnotit a lajkovat každý uživatel, systém webu zohledňuje počet lajků a mění výstup materiálů), technologie (dostupné na ploše a mobilní verze webu).
4. Popis práce: nakreslete 3 možnosti rozložení tlačítek (připravený termín: 10/01/17), vyvinout systém pro distribuci materiálů na základě lajků (datum: 14/10/17), testování funkcí (datum: 16/10/17 ), vydání (datum: 17.10.17)
5. Převzetí práce: uživatel stiskne tlačítko líbí, systém započítá kliknutí, změní se dodávka materiálů.
6. Aplikace: skici, skici, příklady projektů, kde funguje podobná funkce.

Nechte si pro sebe ty části a části struktury, které jsou potřebné pro vaše úkoly. Například šestý blok „Aplikace“ může být popsán ve funkčních požadavcích. Základní rada: tak či onak popište úkol podle struktury technické specifikace. Tímto způsobem vám neuniknou důležité body a ušetříte se zbytečných otázek a zároveň usnadníte život svým kolegům.

Tady máš

Podívali jsme se na to, co je to technický úkol a jak ho provést. Nyní máte možnost jasně a jasně stanovit úkoly, sdělit své myšlenky ostatním lidem a ušetřit čas na další vysvětlování. Doufám, že teď už víte, co s tím vším dělat.

Glosář

Ostatní odborná terminologie je chápána v souladu s aktuálními normami a doporučeními mezinárodních orgánů odpovědných za normalizační problematiku na internetu.

Obecná ustanovení

Předmět vývoje

Předmětem vývoje jsou internetové stránky společnosti "...", sro s dynamickým redakčním systémem na bázi webového rozhraní.
Účel webu:
- poskytování informací o společnosti LLC „...“;
- poskytování informací o činnosti LLC „...“;
- atd.;
- atd.

Účel vytvoření webu: ... .

Účel dokumentu

Tento dokument poskytuje kompletní sadu požadavků pro implementaci webových stránek LLC "".
Podpisem Objednatele a Zhotovitele na tomto dokumentu stvrzují svůj souhlas s následujícími skutečnostmi a podmínkami:
1. Zhotovitel zpracoval a vypracoval tento dokument s názvem Technické specifikace, který obsahuje seznam požadavků na prováděné práce.
2. Zákazník souhlasí se všemi ustanoveními této technické specifikace.
3. Zákazník nemá právo požadovat od zhotovitele v rámci této smlouvy provedení díla nebo poskytnutí služeb, které nejsou výslovně popsány v této technické specifikaci.
4. Zhotovitel se zavazuje provést práce v rozsahu uvedeném v této Technické specifikaci.
5. Objednatel nemá právo požadovat od zhotovitele dodržování jakýchkoli formátů a norem, pokud to není uvedeno v této technické specifikaci.
6. Veškeré nejasnosti uvedené v těchto podmínkách po jejich podpisu podléhají dvoustranné dohodě mezi stranami. Během schvalovacího procesu mohou být vypracovány další požadavky, které jsou formalizovány v dodatečné dohodě ke Smlouvě a podle toho posouzeny.

Požadavky na grafický design webu

Požadavky na design webových stránek

Při vývoji webu by se měly používat převážně světlé styly.
Hlavní části webu by měly být přístupné z první stránky.
První stránka by neměla obsahovat velké množství textových informací.

Design stránek by neměl obsahovat:
- blikající bannery;
- hodně slučovacího textu;
- atd.;
- atd.

Postup při schvalování koncepce návrhu

Designový koncept je chápán jako možnost návrhu hlavní stránky a grafického pláště interních stránek, demonstrující celkové vizuální (kompoziční, barevné, fontové, navigační) řešení hlavních stránek webu. Koncepce návrhu je prezentována jako soubor (několik souborů) v rastrovém formátu nebo ve výtisku podle dohody stran.
Pokud návrhový koncept předložený zhotovitelem uspokojí objednatele, musí jej schválit do pěti pracovních dnů od data předložení. Zároveň může zhotoviteli zaslat seznam soukromých vylepšení, která nemají vliv na celkovou strukturu stránek a jejich styl. Tato vylepšení se provádějí souběžně s vývojem softwarových modulů pro web. Změny koncepce designu po jejím přijetí jsou povoleny pouze po dodatečné dohodě stran.
Pokud předložený koncept nesplňuje požadavky zákazníka, zákazník poskytne odůvodněné odmítnutí přijmout koncept s uvedením podrobností, které sloužily jako překážka pro přijetí konceptu, a jasnější formulaci požadavků.
V tomto případě zhotovitel vypracuje druhou verzi konceptu návrhu. Zhotovitel přijímá závazek vypracovat druhou verzi projektového konceptu až po odsouhlasení a podepsání dodatečné dohody o prodloužení fáze zpracování projektového konceptu na dobu minimálně pěti pracovních dnů.
Další (třetí a následující) opce vyvíjí Dodavatel za úplatu na základě dodatečných dohod.

Funkční požadavky

Požadavky na webovou prezentaci

Požadavky na prezentaci hlavní stránky webu Hlavní stránka webu by měla obsahovat grafickou část, navigační menu webu a také obsahovou oblast, aby návštěvník webu z první stránky mohl získat úvodní informace o společnosti a seznámit se s nejnovějšími novinkami společnosti .
Obsah první stránky by měl být rozdělen do následujících sekcí:
- úvodní článek o společnosti s odkazem „více podrobností“ vedoucí do sekce „O společnosti“;
- novinky - obsahuje 3 nejnovější zprávy (oznámení) ve formátu: datum, název, shrnutí;
- stručné kontaktní údaje - telefonní číslo a e-mail společnosti;
- v horní části stránky se zobrazí odlehčená navigační lišta, která umožňuje přechod na položky hlavního menu webu (O společnosti, Novinky atd.);


- čítače a odkaz na stránku pro výměnu odkazů.

Rýže. 1. Příklad umístění prvků na hlavní stránku.

Grafický shell vnitřních stránek (společný pro všechny podsekce)
Grafický obal vnitřních stránek by měl být rozdělen do následujících částí:
- grafické záhlaví
- nabídka navigace na webu (navigační panel 2 umožňuje přechod k položkám hlavní nabídky webu);
- vyhledávací pole - určené k provádění fulltextového vyhledávání na webu;
- pole pro výběr jazyka - ruština\angličtina;
- odkaz „Domů“;
- navigační panel pro podsekce vybrané části webu;
- pole pro zobrazení obsahu vybrané stránky webu;
- v dolní části stránky - stručné kontaktní údaje - telefonní číslo a e-mail společnosti;
- Tlačítko „Pro tisk“ - poskytuje výstup oblasti obsahu ve formě vyříznuté pro tisk na listy A4;
- Tlačítko „Položit otázku“ – poskytuje přechod do formuláře „Položit otázku“.

Rýže. 2. Příklad umístění prvků vnitřních stránek webu.

Požadavky na strukturu webu
Všechny níže uvedené názvy částí webu jsou podmíněné a lze je upravit po dohodě se zákazníkem během procesu návrhu.
Počáteční struktura webu by měla vypadat takto:
- O společnosti

A. historie společnosti
b. Diplomy a certifikáty
C. Naši partneři
d. naši klienti
E. Naše souřadnice
F. ...

2. Novinky
3. atd.
4. ave.

Požadavky na redakční systém

Obecné požadavky na administrativní část
Chcete-li získat přístup do administrativní části webu, musíte zadat konkrétní adresu do řádku prohlížeče a projít autorizací.
Hlavní stránka administrativní části by měla obsahovat následující položky nabídky:
- Stránky webu (v souladu s první úrovní struktury webu):

O společnosti
- Novinky
- atd.;

Rýže. 3. Rozvržení formuláře hlavní stránky administrativní části webu.

Požadavky na správu sekcí webu
Pro správu částí webu by měly být poskytovány následující funkce:
- vytvoření podsekce úrovně 1;
- vytvoření podsekce úrovně 2 (a dále);
- úprava obsahu stránky;
- smazání sekce;
- přesunutí sekce nahoru v seznamu;
- přesunutí sekce dolů v seznamu;
- známka zobrazení (zobrazení) nebo nezobrazení (skrytí) stránky v klientské části webu;
- zobrazení seznamu podsekcí zvolené úrovně.

Správa obsahu webových stránek
Pro správu obsahu webu by měly být poskytnuty následující bloky:
1. pole prvku obsahu, může být jednoho z následujících typů:
- linka;
- datum;
- odkaz na soubor;
- víceřádkový text;
2. obsahový prvek – skládá se ze sady polí prvků obsahu;
3. seznam obsahových prvků – tvoří soubor obsahových prvků.

Rýže. 4. Pole prvků obsahu.

Pole Prvek textového obsahu je nutné upravit na samostatné stránce ve víceřádkovém textovém editoru (tento editor umožňuje vkládání obrázků do textu).

Rýže. 5. Víceřádkový textový editor v administrativní části.

Pro každý prvek obsahu musí být definována požadovaná sada polí. Například pro prvek „News“ je definována následující sada polí obsahu:

Rýže. 6. Příklad prezentace obsahového prvku „Novinky“ v administrativní části.

Seznam prvků obsahu by měl umožňovat:
. přejděte na úpravy polí položek seznamu;
. odstranit prvek seznamu;
. určit pořadí prvků výstupního seznamu v klientské části;
. zadejte atribut hide\show.

Rýže. 7. Příklad prezentace seznamu prvků obsahu v administrativní části a jejich zobrazení v klientské části.

Seznam prvků by měl zobrazovat všechna pole prvku kromě polí typu „Víceřádkový text“.

Spravovat nastavení webu
Nastavení webu by mělo zahrnovat:
- e-mail pro...;
- atd.;
- atd.

Doplňkové funkce administrativní části
Další funkce administrativní části by měly zahrnovat:
- …;

Požadavky na sdílení přístupu

Všechny publikované části webu musí být otevřené pro přístup pro čtení bez ověření uživatele.
Při pokusu o vstup do uzavřené sekce musí být neautentizovaný uživatel vyzván k zadání přihlašovacího jména a hesla.
Po ověření musí systém zkontrolovat oprávnění uživatele pro přístup k požadované sekci. Pokud je přístup odepřen, měl by uživatel obdržet zprávu, že nemá přístup k omezené části.

Požadavky na typy zajištění

Požadavky na informační podporu

Požadavky na ukládání dat
Všechna data webu musí být uložena ve strukturované podobě pod kontrolou relačního DBMS. Výjimkou jsou datové soubory určené k prohlížení a stahování (obrázky, videa, dokumenty atd.). Takové soubory jsou uloženy v souborovém systému a odkazy na ně jsou umístěny v databázi.
Obsah různých stránek, jejichž fungování je podporováno stejnou instalací systému, musí být uložen pod kontrolou jednoho DBMS.
Požadavky na programovací jazyk
K implementaci statických stránek a šablon je nutné použít jazyky HTML 4.0 a CSS. Zdrojový kód musí být vyvinut v souladu se standardy W3C (HTML 4.0).
Pro implementaci interaktivních prvků na straně klienta by měly být použity jazyky JavaScript a DHTML.
Pro implementaci dynamických stránek je nutné použít jazyk PHP.
Požadavky na uspořádání hypertextových odkazů
Všechny odkazy na webu musí být relativní (s výjimkou externích odkazů).

Požadavky na ilustrace
Všechny kresby a fotografie větší než 1 kb (s výjimkou prvků návrhu stránky) musí být provedeny s alternativním textem. Všechny kresby musí být ve formátu gif nebo jpg.
Požadavky na objem jedné stránky
Průměrná velikost jedné standardní načtené webové stránky by neměla přesáhnout 170 kb.
Velikost flashového spořiče obrazovky by neměla přesáhnout 300 Kb.

Požadavky na software

Požadavky na serverový software
Pro fungování webu je vyžadován následující software:
- Operační systém - Windows XP a Windows Server 2003;
- Webový server - Verze Apache ne nižší než 1.3.26;
- DBMS - MySQL verze ne nižší než 3.23;
Požadavky na software klienta
Stránky musí být plně funkčně viditelné pomocí následujících prohlížečů:
. MS IE 5.0 a vyšší;
. Opera 6.0 a vyšší;
. Mozilla Firefox 1.0;
. Mozilla 1.7.
Stránka musí být funkční (informace na ní umístěné musí být přístupné), když je v prohlížeči zakázána podpora Flash a JavaScript.

Technické požadavky

Aby webové stránky fungovaly, je vyžadována následující technická podpora s následujícími minimálními vlastnostmi:
- procesor - Intel Pentium III 1 Ghz;
- RAM - 512 Mb RAM;
- pevný disk - 20 Gb HDD.
- atd.;
- atd.

Požadavky na jazykovou podporu

Stránka musí být v ruštině a angličtině. Na jakékoli stránce webu by mělo být možné přepínat mezi ruštinou a angličtinou.

Požadavky na ergonomii a technickou estetiku

Stránky by měly být optimalizovány pro prohlížení v rozlišení 1024*768, 1280*1024 bez vodorovného posuvníku a bez prázdných (bílých) polí pro hlavní typy rozlišení.
Ovládací prvky by měly být seskupeny stejným způsobem – vodorovně nebo svisle – na všech stránkách.
Každá stránka by měla obsahovat logo společnosti a kontaktní informace.
Rozhraní zásuvných modulů musí být vytvořeno ve stejném stylu jako rozhraní systémového jádra a musí administrátorovi poskytovat možnost transparentně se pohybovat mezi systémovými moduly a používat stejné ovládací procedury a navigační prvky k provádění stejného typu operací.

Požadavky na přijetí a dodání projektu

Požadavky na vyplnění informací

Obecné požadavky na obsah informací
Zhotovitel v rámci prací na tomto projektu zajistí zaplnění částí staveniště materiálem dodaným objednatelem způsobem uvedeným v bodě 6.1.2.
Zhotovitel zajišťuje zpracování ilustrací tak, aby odpovídaly technickým požadavkům a HTML layoutu připravovaných materiálů. Skenování, psaní na stroji a úpravy-korektury textů, retuše, úpravy, překlady a další práce může zhotovitel provádět na základě dodatečné dohody (po prostudování podkladů, které má objednatel k dispozici).
Po zprovoznění systému probíhá informační obsah sekcí na základě smlouvy o podpoře webu.
Objem textu a počet vyobrazení v jiných typech oddílů jsou určeny datovou strukturou stanovenou v tomto TOR a jsou objasněny ve fázi schvalování koncepce návrhu.
Postup při poskytování informačního obsahu
Zákazník poskytuje materiály v elektronické podobě v zip archivu obsahujícím strom adresářů odpovídající struktuře webu.
Každý adresář obsahuje sadu dokumentů ve formátu MS Word - jeden dokument pro každý informační modul, jehož informační bloky jsou zveřejněny v příslušné sekci. Není dovoleno umísťovat text ve formě grafiky nebo jiných netextových prvků.
Obrázky mohou být umístěny buď v textu uvnitř souboru, nebo jako samostatný obrázek. V druhém případě však musí text obsahovat odkaz na obrázek ve formě cesty a názvu souboru obrázku.
U každého informačního modulu musí struktura dokumentu odpovídat šablonám poskytnutým zhotovitelem před zahájením etapy poskytování materiálů.
Materiály pro prvotní naplnění úseků musí být plně předloženy zhotoviteli ve lhůtách stanovených harmonogramem prací. Je povoleno přenášet materiály po částech, v několika souborech zip, které splňují výše uvedené požadavky.
Převod materiálů v objemu a formátu odpovídajícím tomuto TOR je zabezpečen podpisem Certifikátu o převodu informačního obsahu.
Jakékoli změny obsahu informací ze strany dodavatele po podpisu tohoto zákona jsou povoleny pouze na základě samostatné dohody za příplatek.
Informační materiály nedodané objednatelem ve lhůtách stanovených harmonogramem prací vyvěšuje zhotovitel dle záručního listu zhotovitele do 2 týdnů po předání a převzetí projektu. I tato část informačních materiálů podléhá výše uvedeným požadavkům na formát prezentace.

Personální požadavky

Pro obsluhu webového rozhraní dynamického redakčního systému by správce neměl vyžadovat speciální technické dovednosti, znalosti technologií či softwarových produktů, s výjimkou obecných dovedností v práci s osobním počítačem a standardním webovým prohlížečem (například MS IE 6.0 nebo vyšší).

Postup poskytování distribuce

Po dokončení vývoje musí dodavatel poskytnout zákazníkovi sadu pro distribuci systému sestávající z:
-archiv se zdrojovými kódy všech softwarových modulů a částí webu;
- výpis databáze projektu s aktuálními informacemi.
Distribuce je poskytována na CD jako souborový archiv.

Postup převodu webu na technické prostředky zákazníka

Po dokončení akceptace stránek v rámci záruční podpory provede zhotovitel jednorázový převod vyvinutého softwaru na hardware objednatele. Soulad softwarové a hardwarové platformy s požadavky tohoto dokumentu zajišťuje Zákazník.
Zákazník před převodem poskytuje vzdálený shellový přístup k webovému serveru a přístup k databázi webu.

A tak hlavní standardy, metodiky a soubory znalostí, které zmiňují TK nebo SRS (Software (nebo System) Requirements Specification):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK atd.

GOST 34

Podle GOST 34 musí technická specifikace obsahovat následující oddíly:

1. Obecné informace
2. Účel a cíle tvorby (vývoje) systému
3. Charakteristika objektů automatizace
4. Systémové požadavky
5. Skladba a obsah práce na vytvoření systému
6. Postup pro kontrolu a přejímku systému
7. Požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu
8. Požadavky na dokumentaci
9. Zdroje rozvoje

Při vývoji technických specifikací pro vládní projekty zákazníci zpravidla požadují shodu s tímto konkrétním standardem.

GOST 19

1. Úvod;
2. Důvody rozvoje;
3. Účel rozvoje;
4. Požadavky na program nebo softwarový produkt;
5. Požadavky na dokumentaci programu;
6. Technické a ekonomické ukazatele;
7. Etapy a fáze vývoje;
8. Postup pro kontrolu a přejímku;
9. Aplikace.

Přirozeně, GOST 34 (a 19) jsou již zastaralé a nerad je používám, ale se správnou interpretací norem můžete získat dobré technické specifikace, viz Závěr.

IEEE STD 830-1998

Popisuje obsah a kvalitativní charakteristiky dobře napsané specifikace požadavků na software (SRS) a poskytuje několik šablon SRS. Tento doporučený postup je určen ke stanovení požadavků na vyvíjený software, ale může být také použit jako pomoc při výběru proprietárních a komerčních softwarových produktů.

Podle normy musí zadání obsahovat následující oddíly:

1. Úvod

• 1. Účel
• 2. Rozsah
• 3. Definice, akronymy a zkratky
• 4. Odkazy
• 5. Stručný přehled

• 1. Interakce produktu (s jinými produkty a komponenty)
• 2. Vlastnosti produktu (stručný popis)
• 3. Uživatelské vlastnosti
• 4. Omezení
• 5. Předpoklady a závislosti

• 1. Požadavky na externí rozhraní
  • 1. Uživatelská rozhraní
  • 2. Hardwarová rozhraní
  • 3. Softwarová rozhraní
  • 4. Rozhraní
• 2. Funkční požadavky
• 3. Požadavky na výkon
• 4. Omezení návrhu (a odkazy na normy)
• 5. Nefunkční požadavky (spolehlivost, dostupnost, bezpečnost atd.)
• 6. Další požadavky

Ve skutečnosti je pro začátečníka docela obtížné pochopit, co by mělo být obsaženo v těchto částech podle výše uvedené struktury (jako v případě GOST), takže si musíte přečíst samotnou normu, která. ovšem v angličtině. Jazyk.

Pro ty, kteří dočetli až do konce, je tu bonus: příklad technických specifikací, které jsem napsal před mnoha lety (teď už dávno nepracuji jako analytik a další úspěšnější příklady jsou zakázány otevřela k veřejnému nahlédnutí NDA).

• Prezentace Yuri Buluy Klasifikace požadavků na software a její reprezentace ve standardech a metodikách.
• Analýza požadavků na automatizované informační systémy. Přednáška 11: Požadavky na dokumentaci.
• Pravidla pro vypracování specifikace požadavků na software (čtěte spolu s komentáři)
• Příklady technických specifikací a další dokumentace pro vývoj AS pro Ministerstvo hospodářského rozvoje
• Styl řízení GOST. Gapertonův článek o správné práci s technickými specifikacemi podle GOST
• Šablony dokumentů obchodního analytika z

Často dostávám otázku: "Jak správně vyvinout technické specifikace pro automatizovaný systém?" Téma vývoje technických specifikací je neustále diskutováno na různých fórech. Tato otázka je tak široká, že na ni nelze ve zkratce odpovědět. Proto jsem se rozhodl napsat na toto téma dlouhý článek. V procesu práce na článku jsem si uvědomil, že nebude možné dát vše do jednoho článku, protože... Bude to mít asi 50 stran a rozhodl jsem se to rozdělit na 2 části:

• V první části" Vývoj technických specifikací. Co to je, proč je to potřeba, kde začít a jak by to mělo vypadat? Pokusím se podrobně zodpovědět otázky k tématu, zvážit strukturu a účel zadání a uvést některá doporučení k formulaci požadavků.
• Druhá část " Vývoj technických specifikací. Jak formulovat požadavky? bude výhradně věnována identifikaci a formulaci požadavků na informační systém.

Nejprve musíte zjistit, jaká otázka vlastně zajímá ty, kdo se ptají „Jak vyvinout technickou specifikaci? Faktem je, že přístup k vývoji technických specifikací bude do značné míry záviset na účelech, pro které se to dělá, a také na tom, kdo je bude používat. O jakých možnostech mluvím:

• Komerční organizace se rozhodla implementovat automatizovaný systém. Nemá vlastní IT službu a rozhodla se takto: Zájemce musí vypracovat technickou specifikaci a předložit ji k vývoji třetí straně;
• Komerční organizace se rozhodla implementovat automatizovaný systém. Má vlastní IT službu. Rozhodli jsme se udělat toto: vyvinout technickou specifikaci, poté ji odsouhlasit mezi IT službou a zainteresovanými stranami a implementovat ji vlastními silami;
• Vládní agentura se rozhodla zahájit IT projekt. Všechno je tu takové kalné, spousta formalit, provizí, škrtů atd. Tuto možnost v tomto článku nebudu zvažovat.
• IT společnost poskytuje služby pro vývoj a/nebo implementaci automatizovaných systémů. Toto je nejtěžší případ, protože musíte pracovat v různých podmínkách:

  Klient má své specialisty s vlastními názory, kteří kladou specifické požadavky na Technické specifikace;

  • Podmínky jsou vypracovány pro interní vývojáře (klientovi je to jedno);
  • Zadávací podmínky jsou vypracovány pro předání dodavateli (tj. skupině programátorů z řad zaměstnanců společnosti nebo jednotlivému specialistovi);
  • Mezi společností a klientem dochází k nedorozumění ohledně dosaženého výsledku a společnost si znovu a znovu klade otázku: „Jak by měly být vypracovány technické specifikace? Poslední případ se může zdát jako paradox, ale je to tak.
  • Jiné, méně obvyklé možnosti jsou také možné;

Myslím, že čtenář by nyní měl mít otázky:

• Proč nemohou být technické specifikace vždy vypracovány stejným způsobem?;
• Existují nějaké normy, metody, doporučení? Kde je mohu získat?
• Kdo by měl vypracovat zadání? Měl by mít tento člověk nějaké speciální znalosti?
• Jak pochopit, zda jsou podmínky zadání dobře napsané nebo ne?
• Na čí náklady by se to mělo rozvíjet a je to vůbec nutné?

Tento seznam může být nekonečný. Říkám to s důvěrou, protože se věnuji profesionálnímu vývoji softwaru již 15 let a otázka technických specifikací se objevuje v každém vývojovém týmu, se kterým pracuji. Důvody pro to jsou různé. Vzhledem k tomu, že jsem nastolil téma rozvoje zadání, jsem si dobře vědom toho, že jej nebudu moci prezentovat na 100 % všem, kteří se o toto téma zajímají. Ale pokusím se, jak se říká, „všechno utřídit“. Ti, kteří již znají mé články, vědí, že nepoužívám „copy-paste“ cizích prací, nepřetiskuji cizí knihy, necituji vícestránkové normy a další dokumenty, které si sami můžete najít na internetu, vydávat je za své vlastní geniální myšlenky. Stačí zadat do vyhledávače „Jak vypracovat technickou specifikaci“ a můžete si přečíst spoustu zajímavých, ale bohužel opakujících se věcí. Ti, kteří jsou rádi na fórech chytří (zkuste hledat!), zpravidla sami nikdy nevypracovali řádnou technickou specifikaci a neustále citují doporučení GOST k tomuto problému. A ti, kteří to myslí opravdu vážně, obvykle nemají čas sedět na fóru. Mimochodem, budeme také mluvit o normách GOST. Za léta své práce jsem viděl mnoho verzí technické dokumentace sestavené jak jednotlivými specialisty, tak významnými týmy a poradenskými společnostmi. Občas se také věnuji této činnosti: přiděluji si čas pro sebe a hledám informace na téma, které mě zajímá, z neobvyklých zdrojů (např. trocha inteligence). V důsledku toho jsem musel vidět dokumentaci o takových monstrech, jako je GazProm, Ruské dráhy a mnoho dalších zajímavých společností. Zásadu mlčenlivosti samozřejmě dodržuji, a to i přesto, že mi tyto dokumenty pocházejí z veřejně dostupných zdrojů nebo nezodpovědností poradců (rozhazování informací po internetu). Proto rovnou říkám: Nesdílím důvěrné informace, které patří jiným společnostem, bez ohledu na zdroje (profesní etika).

Co je to technická specifikace?

První věc, kterou nyní uděláme, je zjistit, jaký druh zvířete tato „Technická specifikace“ je.

Ano, skutečně existují GOST a normy, které se pokoušejí regulovat tuto část činnosti (vývoj softwaru). Kdysi byly všechny tyto GOST relevantní a aktivně používané. Nyní existují různé názory na relevanci těchto dokumentů. Někteří tvrdí, že GOST byly vyvinuty velmi prozíravými lidmi a jsou stále relevantní. Jiní říkají, že jsou beznadějně zastaralí. Možná si teď někdo myslel, že pravda je někde uprostřed. Odpověděl bych slovy Goetha: „Říkají, že mezi dvěma protichůdnými názory leží pravda. V žádném případě! Je mezi nimi problém." Takže mezi těmito názory není pravda. Protože GOST neodhalují praktické problémy moderního vývoje a ti, kdo je kritizují, nenabízejí alternativy (specifické a systémové).

Všimněte si, že GOST jasně neuvádí ani definici, pouze říká: „TK pro jadernou elektrárnu je hlavním dokumentem, který definuje požadavky a postup pro vytvoření (vývoj nebo modernizace - poté vytvoření) automatizovaného systému, v souladu s ve kterém se provádí vývoj jaderné elektrárny a její převzetí při uvedení do provozu“.

Pokud někoho zajímá, o čem mluvím GOST, zde jsou:

• GOST 2.114-95 Jednotný systém projektové dokumentace. Technické specifikace;
• GOST 19.201-78 Jednotný systém programové dokumentace. Technický úkol. Požadavky na obsah a design;
• GOST 34.602-89 Informační technologie. Soubor standardů pro automatizované systémy. Zadání pro vytvoření automatizovaného systému.

Mnohem lepší definice je uvedena na Wikipedii (i když o technických specifikacích obecně, a nejen pro software): “ Technický úkol- toto je originální projektový dokument technický objekt. Technický úkol stanoví hlavní účel vyvíjeného objektu, jeho technické a takticko-technické charakteristiky, kvalitativní ukazatele a technicko-ekonomické požadavky, pokyny pro dokončení nezbytných stupňů tvorby dokumentace (projekční, technologická, softwarová atd.) a její složení, jako i speciální požadavky. Úkol jako výchozí dokument pro vytvoření něčeho nového existuje ve všech oblastech činnosti, lišících se názvem, obsahem, pořadím provedení atd. (například projektový úkol ve výstavbě, bojový úkol, domácí úkol, zakázka na literární dílo atd.). d.)“

A tak, jak vyplývá z definice, hlavním účelem Technické specifikace je formulovat požadavky na vyvíjený objekt, v našem případě na automatizovaný systém.

Je to hlavní, ale jediná věc. Nastal čas přejít k hlavní věci: dát vše „na police“, jak bylo slíbeno.

Co potřebujete vědět o požadavcích? Je nutné jasně pochopit, že všechny požadavky musí být rozděleny podle typu a vlastností. Nyní se naučíme, jak to udělat. K oddělení požadavků podle typu nám pomůže GOST. Seznam typů požadavků, který je zde uveden, je dobrým příkladem toho, jaké typy požadavků je třeba vzít v úvahu. Například:

• Požadavky na funkčnost;
• Požadavky na bezpečnost a přístupová práva;
• Požadavky na kvalifikaci personálu;
• …. Atd. Dočtete se o nich ve zmíněném GOST (a níže se na ně také podívám trochu podrobněji).

Myslím, že je vám jasné, že klíčovým faktorem úspěšné technické specifikace jsou přesně dobře formulované požadavky na funkčnost. Většina prací a metod, o kterých jsem hovořil, je věnována těmto požadavkům. Požadavky na funkčnost tvoří 90 % složitosti práce na vývoji zadání. Vše ostatní je často „kamufláž“, která tyto požadavky pokrývá. Pokud jsou požadavky formulovány špatně, tak bez ohledu na to, jakou krásnou kamufláž na ně dáte, úspěšný projekt nevyjde. Ano, formálně budou splněny všechny požadavky (podle GOST J), technická specifikace byla vyvinuta, schválena a podepsána a byly na ni přijaty peníze. a co? A pak začíná ta nejzajímavější část: co dělat? Pokud se jedná o projekt na státní zakázku, pak nejsou žádné problémy - rozpočet je takový, že se nikomu nevejde do kapsy a během procesu implementace (pokud existuje) se vše vyjasní. Přesně tak se utrácí většina projektových rozpočtů na státní zakázky (načmárali „TZ“, přišli o desítky milionů, ale projekt neudělali. Všechny formality byly dodrženy, viníci nebyli, nové auto je blízko dům. Krása!). Ale mluvíme o komerčních organizacích, kde se počítají peníze a je potřeba jiný výsledek. Proto pojďme pochopit hlavní věc, jak se rozvíjet užitečné a funkční technické specifikace.

Řekl jsem o typech požadavků, ale co vlastnosti? Pokud se typy požadavků mohou lišit (v závislosti na cílech projektu), pak s vlastnostmi je vše jednodušší, existují 3 z nich:

1. Požadavek musí být srozumitelný;
2. Požadavek musí být charakteristický;
3. Požadavek musí být účastníci testu;

Navíc poslední vlastnost je nemožná bez dvou předchozích, tzn. je jakýmsi „lakmusovým papírkem“. Pokud výsledek požadavku nelze otestovat, znamená to, že je buď nejasný, nebo není konkrétní. Přemýšlejte o tom. Právě ve zvládnutí těchto tří vlastností požadavků spočívá mistrovství a profesionalita. Je to vlastně velmi jednoduché. Když na to přijdeš.

Tím končí příběh o tom, co je technická specifikace, a přecházíme k hlavní věci: jak formulovat požadavky. Ale není to tak rychlé. Je tu ještě jeden nesmírně důležitý bod:

• V jakém jazyce (z hlediska obtížnosti porozumění) by měla být technická specifikace napsána?
• Měl by popisovat specifikace různých funkcí, algoritmů, datových typů a dalších technických věcí?
• Co je technický design, který je mimochodem také zmíněn v GOST, a jak souvisí s Technickými specifikacemi?

V odpovědích na tyto otázky se skrývá velmi zákeřná věc. Proto často dochází ke sporům o dostatečnosti či nedokonalosti potřebných podrobností požadavků, o srozumitelnosti dokumentu ze strany objednatele a zhotovitelů, o nadbytečnosti, formátu prezentace atd. Kde je hranice mezi zadáním a technickým projektem?

Technický úkol- jedná se o dokument založený na požadavcích formulovaný v jazyce, který je Zákazníkovi srozumitelný (běžný, známý). V tomto případě může a měla by být použita oborová terminologie, která je pro zákazníka srozumitelná. Neměly by existovat žádné vazby na specifika technické realizace. Tito. ve fázi technické specifikace je v zásadě jedno, na jaké platformě budou tyto požadavky implementovány. I když existují výjimky. Pokud se bavíme o implementaci systému založeného na již existujícím softwarovém produktu, pak k takovému propojení může dojít, ale pouze na úrovni obrazovkových formulářů, formulářů reportů apod. Vyjasnění a formulace požadavků, stejně jako vývoj by měl být proveden mandát Obchodní analytik. A rozhodně ne programátor (pokud tyto role nespojí, tak se to stává). Tito. tato osoba musí se Zákazníkem hovořit v jazyce jeho podnikání.

Technický projekt- jedná se o dokument, který je určen k technické realizaci požadavků formulovaných v Zadání. Tento dokument popisuje datové struktury, spouštěče a uložené procedury, algoritmy a další věci, které budou vyžadovány technické specialisty. Zákazník se v tom nemusí vůbec vrtat (ani takové termíny mu nemusí být jasné). Technický projekt ano Systémový architekt(kombinovat tuto roli s programátorem je zcela normální). Nebo spíše skupina specialistů JSC vedená architektem. Čím větší je projekt, tím více lidí pracuje na zadání.

Co máme v praxi? Je legrační sledovat, když je řediteli předložena ke schválení technická specifikace, která je plná odborné terminologie, popisů datových typů a jejich hodnot, struktury databáze atd. On se samozřejmě snaží pochopit, protože potřebuje schválit , snaží se najít známá slova mezi řádky a neztratit obchodní požadavky řetězce. Je to známá situace? A jak to skončí? Takové technické specifikace jsou zpravidla schváleny, následně implementovány a v 80 % případů pak vůbec neodpovídají skutečnosti provedené práce, protože rozhodli se změnit, předělat spoustu věcí, špatně pochopili, mysleli špatně atd. a tak dále. A pak začíná série o odevzdání práce. "Ale tady to není to, co potřebujeme," ale "toto pro nás nebude fungovat", "to je příliš složité", "toto je nepohodlné" atd. Zní povědomě?!! To je mi povědomé, musel jsem narazit včas.

Co tedy máme v praxi? Ale v praxi máme rozmazanou hranici mezi zadáním a technickým projektem. Pohybuje se mezi TK a TP v různých projevech. A to je špatně. To se děje proto, že kultura rozvoje zeslábla. Částečně je to způsobeno kompetencemi specialistů, částečně snahou snižovat rozpočty a termíny (koneckonců, dokumentace zabere spoustu času - to je fakt). Je zde ještě jeden důležitý faktor ovlivňující využití Technického návrhu jako samostatného dokumentu: rychlý vývoj nástrojů rychlého vývoje a také vývojových metodik. Ale to je samostatný příběh; níže o něm řeknu pár slov.

Další malý, ale důležitý bod. Někdy se referenčním podmínkám říká malý kousek požadavků, jednoduchý a srozumitelný. Například zlepšit vyhledávání objektu podle nějakých podmínek, přidat sloupec do sestavy atd. Tento přístup je celkem oprávněný, proč si komplikovat život. Nepoužívá se však u velkých projektů, ale u menších vylepšení. Řekl bych, že se to blíží údržbě softwarových produktů. V tomto případě může zadání také popisovat konkrétní technické řešení pro realizaci požadavku. Například „Proveďte takovou a takovou změnu v takovém a takovém algoritmu“, což označuje konkrétní postup a konkrétní změnu pro programátora. To je případ, kdy je hranice mezi zadáním a technickými projekty zcela smazána, protože není ekonomická proveditelnost nafouknout papírování tam, kde to není potřeba, ale vznikne užitečný dokument. A je to správné.

Je vůbec potřeba technická specifikace? A co technický projekt?

Přehřívám se? Je to možné bez něj Technické specifikace? Představte si, že je to možné (nebo spíše je to možné) a tento přístup má mnoho následovníků a jejich počet roste. Zpravidla poté, co si mladí specialisté přečtou knihy o Scrumu, Agile a dalších technologiích rychlého rozvoje. Ve skutečnosti jsou to úžasné technologie a fungují, ale doslova neříkají „není třeba dělat technické úkoly“. Říká se „minimum papírování“, zejména zbytečného, ​​blíže k zákazníkovi, více specifik a rychlejší výsledky. Ale záznam požadavků nikdo nezrušil a je to tam jasně řečeno. Právě tam jsou požadavky stanoveny na základě tří pozoruhodných vlastností, které jsem zmínil výše. Jde jen o to, že mysl některých lidí je strukturována tak, že pokud lze něco zjednodušit, zjednodušme to až do úplné absence. Jak řekl Einstein" Udělejte to co nejjednodušší, ale ne jednodušší." . To jsou zlatá slova, která se hodí ke všemu. Tak Technický úkol nutné, jinak se nedočkáte úspěšného projektu. Další otázkou je, jak to poskládat a co tam zařadit. Ve světle metod rychlého vývoje se musíte soustředit pouze na požadavky a všechny „kamufláže“ lze odhodit. V zásadě s tím souhlasím.

A co technický projekt? Tento dokument je velmi užitečný a neztratil svou relevanci. Navíc se bez něj často prostě neobejdete. Zejména pokud jde o outsourcing vývojových prací, tzn. na principu outsourcingu. Pokud to neuděláte, riskujete, že se hodně dozvíte o tom, jak by měl systém, který máte na mysli, vypadat. Měl by se s tím zákazník seznámit? Pokud chce, proč ne, ale není potřeba na tomto dokumentu trvat a schvalovat, jen to bude brzdit a překážet v práci. Navrhnout systém do nejmenších detailů je téměř nemožné. V tomto případě budete muset průběžně provádět změny v technickém návrhu, což zabere spoustu času. A pokud je organizace silně byrokratická, pak tam necháte všechny nervy. Omezení tohoto druhu designu je přesně to, o čem jsou moderní metodologie rychlého vývoje, které jsem zmínil výše. Mimochodem, všechny jsou založeny na klasickém XP (extreme programming) - přístupu starém již asi 20 let. Vytvořte tedy kvalitní Technickou specifikaci, která je pro zákazníka srozumitelná, a použijte Technický návrh jako interní dokument pro vztah mezi architektem systému a programátory.

Zajímavý detail o technickém návrhu: některé vývojové nástroje navržené na principu předmětově orientovaného designu (jako 1C a podobně) předpokládají, že návrh (myšleno proces dokumentace) je vyžadován pouze ve skutečně složitých oblastech, kde je vyžadována interakce mezi celými subsystémy. V nejjednodušším případě, například vytvoření adresáře nebo dokumentu, stačí pouze správně formulované obchodní požadavky. Svědčí o tom i obchodní strategie této platformy z hlediska školení specialistů. Pokud se podíváte na zkušební kartu specialisty (tak se tomu říká, nikoli „programátor“), uvidíte, že existují pouze obchodní požadavky a jak je implementovat v programovém jazyce, je úkolem specialisty. Tito. tu část problému, kterou má technický projekt vyřešit, musí specialista vyřešit „v hlavě“ (hovoříme o úkolech střední složitosti), tady a teď, po určitých vývojových a konstrukčních standardech, které jsou opět tvořeny společnost 1C pro svou platformu. Tedy ze dvou specialistů, jejichž pracovní výsledky vypadají identicky, může jeden zkoušku složit, druhý nikoli, protože očividně porušil vývojové standardy. To znamená, že se samozřejmě předpokládá, že specialisté musí mít takovou kvalifikaci, aby mohli navrhovat typické úkoly samostatně, bez zapojení systémových architektů. A tento přístup funguje.

Pokračujme ve studiu otázky: "Jaké požadavky by měly být zahrnuty do podmínek zadání?"

Formulace požadavků na informační systém. Struktura zadání

Aby bylo jasno: budeme hovořit konkrétně o formulaci požadavků na informační systém, tzn. za předpokladu, že práce na vývoji obchodních požadavků, formalizaci obchodních procesů a veškeré předchozí konzultační práce již byly dokončeny. V této fázi je samozřejmě možné provést určitá upřesnění, ale pouze upřesnění. Samotný projekt automatizace neřeší obchodní problémy – pamatujte si to. Toto je axiom. Někteří manažeři se to z nějakého důvodu snaží vyvrátit a věří, že pokud si program koupí, přijde řád v chaotickém byznysu. Ale axiom je axiom, protože nevyžaduje důkaz.

Jako každá činnost, formulování požadavků může (a mělo by) být rozděleno do etap. Vše má svůj čas. To je těžká intelektuální práce. A pokud s ním zacházíte s nedostatečnou pozorností, výsledek bude vhodný. Podle odborných odhadů mohou náklady na vytvoření zadání činit 30–50 %. Jsem stejného názoru. I když 50 je možná moc. Technická specifikace ostatně není posledním dokumentem, který je třeba vypracovat. Nesmí chybět ani technické provedení. Tato variace je způsobena různými automatizačními platformami, přístupy a technologiemi, které používají projektové týmy během vývoje. Například, pokud mluvíme o vývoji v klasickém jazyce, jako je C++, pak je nepostradatelný detailní technický návrh. Pokud mluvíme o implementaci systému na platformě 1C, pak je situace s designem poněkud odlišná, jak jsme viděli výše (i když při vývoji systému od nuly je navržen podle klasického schématu).

Ačkoli prohlášení o požadavcích je hlavní částí Technické specifikace a v některých případech se stává jedinou částí technických specifikací, měli byste věnovat pozornost skutečnosti, že se jedná o důležitý dokument, a měl by být podle toho vypracován. kde začít? Nejprve musíte začít s obsahem. Napište obsah a poté jej začněte rozšiřovat. Osobně dělám toto: nejprve načrtnu obsah, popíšu cíle, všechny úvodní informace a pak se pustím do hlavní části – formulace požadavků. Proč ne naopak? Nevím, je to pro mě pohodlnější. Zaprvé jde o mnohem menší část času (v porovnání s požadavky) a zadruhé, zatímco popisujete všechny úvodní informace, naladíte se na to hlavní. No kdo to má rád. Postupem času si vytvoříte vlastní šablonu technické specifikace. Pro začátek doporučuji vzít jako obsah přesně ten, který je popsán v GOST. Je ideální pro obsah! Poté vezmeme a začneme popisovat každou sekci, přičemž nezapomeneme na doporučení následujících tří vlastností: srozumitelnost, specifičnost a testovatelnost. Proč na tom tolik trvám? Více o tom v další části. A nyní navrhuji projít ty body technických specifikací, které jsou doporučeny v GOST.

1. obecná informace;
2. účel a cíle tvorby (vývoje) systému;
3. charakteristiky objektů automatizace;
4. Požadavky na systém;
5. skladba a obsah práce na vytvoření systému;
6. postup pro kontrolu a akceptaci systému;
7. požadavky na skladbu a obsah prací na přípravě objektu automatizace pro uvedení systému do provozu;
8. požadavky na dokumentaci;
9. vývojové zdroje.

Celkem 9 sekcí, z nichž každá je rozdělena také na podsekce. Pojďme se na ně podívat popořadě. Pro usnadnění uvedu vše ve formě tabulky u každé položky.

Oddíl 1. obecné informace.

Sekce 2. účel a cíle tvorby (vývoje) systému.

Obecně platí, že schopnost identifikovat cíle, formulovat je a sestavit strom cílů je zcela samostatné téma. Pamatujte na hlavní věc: pokud víte jak, pište, pokud si nejste jisti, nepište vůbec. Co se stane, když si neformulujete cíle? Budete pracovat podle požadavků, to se často praktikuje.

Sekce 3. Charakteristika objektů automatizace.

Část 4. Systémové požadavky

GOST dešifruje seznam těchto požadavků:

• požadavky na strukturu a fungování systému;
• požadavky na počet a kvalifikaci personálu systému a způsob jeho provozu;
• ukazatele destinace;
• požadavky na spolehlivost;
• bezpečnostní požadavky;
• požadavky na ergonomii a technickou estetiku;
• požadavky na přenositelnost mobilních reproduktorů;
• požadavky na provoz, údržbu, opravy a skladování součástí systému;
• požadavky na ochranu informací před neoprávněným přístupem;
• požadavky na bezpečnost informací v případě nehod;
• požadavky na ochranu před vnějšími vlivy;
• požadavky na čistotu patentu;
• požadavky na standardizaci a unifikaci;

I přesto, že hlavní bude jistě sekce se specifickými požadavky (funkční), může mít i tato sekce velký význam (a ve většině případů tomu tak je). Co může být důležité a užitečné:

• Kvalifikační požadavky. Je možné, že vyvíjený systém bude vyžadovat rekvalifikaci specialistů. Mohou to být jak uživatelé budoucího systému, tak IT specialisté, kteří budou potřeba k jeho podpoře. Nedostatečná pozornost této problematice se často vyvine v problémy. Pokud je kvalifikace stávajícího personálu zjevně nedostatečná, je lepší specifikovat požadavky na organizaci školení, program školení, načasování atd.
• Požadavky na ochranu informací před neoprávněným přístupem. Zde nejsou žádné komentáře. To jsou přesně požadavky na vymezení přístupu k datům. Pokud jsou takové požadavky plánovány, pak je třeba je napsat samostatně, co nejpodrobněji, podle stejných pravidel jako funkční požadavky (srozumitelnost, specifičnost, testovatelnost). Proto lze tyto požadavky zařadit do části s funkčními požadavky
• Požadavky na standardizaci. Pokud existují nějaké konstrukční normy, které jsou použitelné pro projekt, mohou být zahrnuty do požadavků. Tyto požadavky jsou zpravidla iniciovány IT službou zákazníka. Například společnost 1C má požadavky na návrh programového kódu, design rozhraní atd.;
• Požadavky na strukturu a fungování systému. Zde mohou být popsány požadavky na integraci systémů mezi sebou a je uveden popis obecné architektury. Častěji jsou integrační požadavky obecně rozděleny do samostatné části nebo dokonce samostatné technické specifikace, protože tyto požadavky mohou být poměrně složité.

Všechny ostatní požadavky jsou méně důležité a není třeba je popisovat. Podle mého názoru pouze zatěžují dokumentaci a mají malý praktický přínos. A popsat ergonomické požadavky ve formě obecných požadavků je velmi obtížné, je lepší je přenést na funkční. Může být například formulován požadavek „Získat informaci o ceně produktu stisknutím jediného tlačítka“. To se podle mého názoru stále více blíží konkrétním funkčním požadavkům, i když se to týká ergonomie Požadavky na funkce (úkoly) prováděné systémem To je hlavní a klíčový bod, který rozhodne o úspěchu. I když je vše ostatní provedeno perfektně a tato sekce je „3“, pak bude výsledek projektu v nejlepším případě „3“, nebo dokonce projekt zcela selže. Právě tomu se budeme podrobněji věnovat v druhém článku, který bude zařazen do 5. čísla zpravodaje. Právě v tomto bodě platí „pravidlo tří vlastností požadavků“, o kterém jsem hovořil. Požadavky na typy zajištění

GOST identifikuje následující typy:

• Matematický
• Informační
• Lingvistické
• Software
• Technický
• Metrologické
• Organizační
• Metodický
• a další…

Na první pohled se tyto požadavky mohou zdát nedůležité. Ve většině projektů je to pravda. Ale ne vždy. Kdy popsat tyto požadavky:

• Nebylo učiněno žádné rozhodnutí o tom, který jazyk (nebo platforma) bude vyvíjen;
• Systém vyžaduje vícejazyčné rozhraní (například ruština/angličtina)
• Aby systém fungoval, musí být vytvořena samostatná jednotka nebo musí být přijati noví zaměstnanci;
• Aby systém fungoval, musí zákazník projít změnami pracovních metod a tyto změny musí být specifikovány a naplánovány;
• Očekává se integrace s jakýmkoli zařízením a jsou na něj kladeny požadavky (například certifikace, kompatibilita atd.)
• Jiné situace jsou možné, vše závisí na konkrétních cílech projektu.

Sekce 5. Složení a obsah práce na vytvoření systému

Oddíl 6. Postup pro kontrolu a převzetí systému

Obecné požadavky na přejímku díla po etapách (seznam zúčastněných podniků a organizací, místo a načasování), postup koordinace a schvalování přejímací dokumentace, důrazně doporučuji převzít odpovědnost za postup odevzdání práce a kontrolu systému. To je přesně důvod, proč jsou potřeba testovatelné požadavky, ale ani přítomnost testovatelných požadavků nemusí při dodání systému stačit, pokud není jasně stanoven postup pro přijetí a převod díla. Například běžná past: systém je postaven a je plně funkční, ale Zákazník z nějakého důvodu není připraven v něm pracovat. Tyto důvody mohou být jakékoli: žádný čas, cíle se nezměnily, někdo skončil atd. A říká: „Protože v novém systému ještě nepracujeme, nemůžeme si být jisti, že funguje.“ Naučte se tedy správně identifikovat fáze práce a jak kontrolovat výsledky těchto fází. Tyto způsoby navíc musí být zákazníkovi jasné od samého počátku. Pokud jsou fixní na úrovni Technických specifikací, pak se na ně můžete v případě potřeby vždy obrátit a dokončit práci s převodem.

Oddíl 7. Požadavky na skladbu a obsah prací na přípravu objektu automatizace pro uvedení systému do provozu

Mohou existovat jiná pravidla pro zadávání informací přijatá společností (nebo plánovaná). Například informace o smlouvě se dříve zadávaly jako textový řetězec v libovolné podobě, nyní je však vyžadováno samostatné číslo, samostatné datum atd. Takových podmínek může být spousta. Některé z nich mohou být personálem vnímány s odporem, proto je lepší všechny takové případy evidovat na úrovni požadavků na pořadí zadávání dat Změny, které je potřeba provést v objektu automatizace

Vytvoření podmínek pro fungování objektu automatizace, za kterých je zaručena shoda vytvořeného systému s požadavky obsaženými v technických specifikacích Případné změny. Společnost například nemá lokální síť, zastaralou flotilu počítačů, na kterých systém nebude fungovat.

Možná byly některé potřebné informace zpracovány na papíře a nyní je třeba je zadat do systému. Pokud to neuděláte, některý modul nebude fungovat atd.

Možná bylo něco zjednodušeno, ale nyní je třeba vzít v úvahu podrobněji, takže někdo musí sbírat informace podle určitých pravidel.

Tento seznam může být dlouhý, podívejte se na konkrétní případ vašeho projektu Vytvoření oddělení a služeb nezbytných pro fungování systému;

Načasování a postup pro personální obsazení a školení O tom jsme již hovořili dříve. Možná je systém vyvíjen pro novou strukturu nebo typ činnosti, která dříve neexistovala. Pokud není k dispozici vhodný personál, a dokonce ani vyškolený, systém nebude fungovat, bez ohledu na to, jak kompetentně je postaven.

Oddíl 8. Požadavky na dokumentaci

Zvažte, jak budou prezentovány uživatelské příručky.

Zákazník možná přijal podnikové standardy, což znamená, že se na ně musíme odvolávat.

Ignorování požadavků na dokumentaci velmi často vede k nejneočekávanějším důsledkům na projekty. Například vše je hotovo a vše funguje. Uživatelé také vědí, jak pracovat. O dokumentaci nebyla vůbec žádná shoda ani rozhovor. A najednou se vás při předávání díla jeden z top manažerů Zákazníka, který se na projektu ani neúčastnil, ale podílí se na převzetí díla, ptá: „Kde jsou uživatelské manuály? A začne vás přesvědčovat, že nebylo třeba se dohodnout na dostupnosti uživatelských příruček, to se prý „samozřejmě“ předpokládá. A je to, nechce vám vzít práci. Na čí náklady vypracujete pokyny? Tomuto háku už propadlo mnoho týmů.

Sekce 9. Zdroje vývoje

Proto je lepší jednoduše odkázat na zprávu o průzkumu a požadavky klíčových osob.

A tak jsme zvážili všechny části, které lze zahrnout do podmínek zadání. „Můžu“ a ne „Musím“ právě proto, že k dosažení výsledku musí být vytvořen jakýkoli dokument. Pokud je vám tedy zřejmé, že konkrétní sekce vás k výsledku nepřiblíží, pak ji nepotřebujete a nemusíte s ní ztrácet čas.

Žádná kompetentní technická specifikace se však neobejde bez toho hlavního: funkčních požadavků. Rád bych poznamenal, že v praxi se takové technické specifikace vyskytují a jak! Existují lidé, kteří budou schopni oddělit vody ve všech částech, popsat obecné požadavky obecně a dokument se ukáže jako velmi závažný a je v něm spousta chytrých slov a dokonce se může líbit i zákazníkovi to (tedy on to schválí). Ale nemusí to podle něj fungovat, tzn. Má malé praktické využití. Ve většině případů se takové dokumenty rodí, když potřebujete získat hodně peněz konkrétně za podmínky zadání, ale je třeba to udělat rychle a bez ponoření do detailů. A hlavně pokud se ví, že věc dál nepůjde, nebo to budou dělat úplně jiní lidé. Obecně jen k hospodaření s rozpočtem, zejména státním.

Ve druhém článku se budeme hovořit pouze o části 4 „Systémové požadavky“ a konkrétně požadavky formulujeme z důvodu srozumitelnosti, specifičnosti a testovatelnosti.

Proč požadavky musí být jasné, konkrétní a testovatelné.

Protože praxe ukazuje: zprvu se většina technických specifikací, které vyvíjejí specialisté, buď ukáže, že není poptávaná (neodpovídají skutečnosti), nebo se stane problémem pro toho, kdo je musí implementovat, protože Zákazník začíná manipulovat s vágními termíny a požadavky. Uvedu pár příkladů, s jakými frázemi se setkali, k čemu to vedlo, a poté se pokusím dát doporučení, jak se takovým problémům vyhnout.

Od autora: Jak psát referenční podmínky (TOR) pro vývoj webových stránek? Téma je to poměrně obsáhlé a je těžké ho 100% rozebrat v rámci jedné poznámky (pokud je to vůbec možné). Pokusím se ale dostatečně podrobně nastínit obecná ustanovení o tom, na co je třeba přihlížet a na co si dát pozor při sestavování zadání pro web.

Takže technické specifikace pro vývoj webových stránek

Technické specifikace jsou připraveny pro vývojáře. Na zadávací podmínky je třeba odkázat při sepisování smlouvy mezi zákazníkem a zhotovitelem. Musí být stanovena odpovědnost za nesplnění nebo nesprávné plnění bodů a termínů na obou stranách. Ale to nejdůležitější (podle mě), pro co jsou technické specifikace vytvořeny, je pro urychlení procesu vývoje projektu.

Pojďme analyzovat tento příklad:

Předpokládejme, že potřebujete kalendář někde na straně vašeho webu. Vypadalo to jako maličkost. Čím podrobněji ale jeho funkčnost popíšete, tím rychleji se dočkáte výsledku.

Dovolte mi to zde trochu vysvětlit. Existuje kalendář, který jednoduše zobrazuje čísla podle dne v týdnu aktuálního měsíce. A je tu možnost listovat mezi měsíci. K dispozici je kalendář s možností listování měsíci a roky.

JavaScript. Rychlý start

Řekněme, že chcete druhou možnost (s možností procházet měsíce a roky) se zvýrazněným aktuálním datem. V podmínkách, které jste uvedli: „je potřeba kalendář v postranním panelu.“ Poskytnou vám první možnost (prostě zobrazuje čísla podle dne v týdnu aktuálního měsíce).

Co máme. Dodavatel splnil specifikaci, ale vy jste chtěli něco úplně jiného. Vše se zdá být v souladu, nikdo za to nemůže, nedochází ke konfliktu, ale to nejdůležitější je ztraceno čas a peníze.

Toto je příklad pouze banálního kalendáře.

Co když musíte předělat něco vážnějšího, na jehož zpracování je potřeba více než půl dne, jako v případě kalendáře? Dodavatel je s vámi zaneprázdněn, když může dokončit váš projekt a začít nový.

Proto, než více informací Popíšete funkčnost každého modulu, tím rychleji se dočkáte výsledku. To by mělo zajímat obě strany.

Z jakých bodů se obvykle technická specifikace skládá?

Představme si, že jste vlastníkem firmy nebo firmy. Vaše společnost se zabývá výrobou jakéhokoli produktu a jeho prodejem. Máte kupce. Spolupracujete s prodejci (obchody a internetové obchody), servisními centry a spotřebiteli produktů. Nebo děláte zdroj pro takovou společnost a potřebujete napsat technickou specifikaci.

Bez ohledu na to, jakou roli hrajete, první věc, kterou musíte udělat před sestavením technických specifikací pro vytvoření designu webových stránek, je prostudovat strukturu organizace, co dělá, nomenklaturu, vlastnosti a obecně vše, co souvisí s produktem. a společnost. Co se stane se zdrojem, závisí na tom, jak hluboce zákazník chápe podstatu toho, co se v podniku děje. Úkol je zde tedy vzájemný: zákazník musí o podniku vyprávět co nejpodrobněji a dodavatel musí důkladně porozumět podstatě toho, co se děje.

I když sami píšete technické specifikace pro společnost, která bude váš projekt realizovat, je dobré si to všechno spočítat na kus papíru.

Pojďme bod po bodu.

Popis

Zde můžete napsat pár větami o společnosti a o tom, co dělá. Udělejte něco jako úvod.

pro koho – cílové publikum:

potenciální kupce

prodejci produktů (obchody, internetové obchody)

servisní střediska

partneři (firmy)

spotřebitelé produktů (ti, kteří již zakoupili)

Proč potřebujete web:

Pro zlepšení image firmy

Pro zvýšení prodeje

Pro pohodlí zákazníka

Firemní

Webové stránky – vizitka

Internetový obchod

Jazykové verze:

Angličtina

Stránka musí vyřešit nějaké problémy. Podle toho se dále posouváme k cílům a záměrům.

Záměry a cíle

V této části technických specifikací procházíme celou cílovou skupinu a popisujeme okruh úkolů, které by pro ně měla stránka řešit.

Potenciální kupci produktu.

Cílová: přilákat více kupujících a přesvědčit je k prvnímu nákupu, pomoci jim s výběrem.

Je třeba vyřešit problémy:

Poskytujte vysoce kvalitní, komplexní informace o produktech, doplňkových službách, zárukách, servisu a metodách výběru.

Poskytování informací o showroomech

Poskytování informací o maloobchodní síti

Poskytněte příležitost položit otázku tím, že zorganizujete online konzultaci potenciálních kupujících se specialisty společnosti o otázkách výběru a nákupu produktů.

Procházíme tak celou cílovou skupinu. Popisujeme také cíle a záměry pro prodejce produktů (obchody, internetové obchody), servisní střediska, partnery (firmy) a spotřebitele produktů. Tedy to, co by měl web dělat konkrétně pro každý z nich.

Nyní uvádíme seznam modulů.

Funkčnost webu

Chcete-li uvést funkce, musíte se rozhodnout, co potřebuje:

Je nutná registrace?

Potřebuji uzavřenou sekci (pouze pro registrované uživatele)

Je nutný formulář zpětné vazby?

Atd. a tak dále.

JavaScript. Rychlý start

Naučte se základy JavaScriptu s praktickým příkladem, jak vytvořit webovou aplikaci.

Poté, co jsme si to vše popsali, se dostáváme k tomu nejdůležitějšímu a nejzajímavějšímu. Samozřejmě, že všechna výše provedená práce je velmi důležitá, ale teď je to ještě žhavější.

Popis funkčnosti

V tuto chvíli víme, pro koho je web určen, jaké cíle a cíle by měl splňovat a jaké má další funkce.

Nastal čas, kdy je potřeba všechny nasbírané informace přenést do systému a krásně je uspořádat. Chcete-li si tento úkol usnadnit a nevynalézat znovu kolo, můžete se podívat na zdroje na podobná témata. Něco si od nich vezměte, podívejte se a vyzkoušejte jejich funkčnost a co se vám zdálo nevyhovující, zkuste to na svém projektu vylepšit. V zásadě se můžete podívat na stránky s podobnými tématy (a pokud nemáte zkušenosti, pak dokonce musíte) na samém začátku vytváření technických specifikací.

Doporučuji začít s položkami menu. Musí zobrazovat hlavní stránky a zajistit, aby si každý návštěvník rychle našel informace pro sebe. A návštěvníci jsou naše cílová skupina. Nabídka bude obsahovat mnoho položek, bude tedy ve formě rozevíracího seznamu.

Nejprve nám musíte říci o společnosti. Mohou zde být stránky o společnosti, historii společnosti, kontakty, recenze.

Samozřejmostí by měla být položka nabídky „produkty“ s podpoložkami „katalog produktů“, „vydání“, „recenze produktu“.

Obecně doufám, že je jasné, jak to popsat. Dovolte mi představit konečnou verzi možného menu:

O společnosti

historie společnosti

kontakty

produkty

Produktový katalog

recenze produktů

servisní oddělení

záruční servis

pozáruční servis

spotřebiteli

nákup a doručení

použití

o službě

obchody a internetové obchody

fotografie produktů

FAQ

servisní střediska

Jak se stát servisním střediskem

FAQ

partnery

pozvání ke spolupráci

FAQ

Zdá se, že jsme vyřešili menu. Nyní je potřeba popsat, co bude na jednotlivých stránkách a jak to celé funguje. Plus poskytnout přibližné rozložení. Dá se nakreslit na kus papíru tužkou, naskenovat a přiložit k technické specifikaci. Jediná věc, kterou řeknu, je, že neomezujte fantazii designéra, načrtněte ji v nejobecnější podobě.

Tato část se mění v závislosti na tom, jak chcete, aby vaše stránka vypadala. Možná nepotřebujete tolik bannerů nahoře, možná budete muset uvést kontakty (adresa, telefon, fax) nahoře, třeba ve formě ikon „mapa webu“, „domů“, „kontakty“. Možná nepotřebujete novinky na levé straně, ale na levé straně zobrazíte „propagace a vydání“.

Hlavní je nyní popsat logiku práce.

Operační logika

Popíšu na základě obrázku výše.

Záhlaví zůstává na každé stránce stejné. Informační kanál je viditelný pouze na hlavní stránce. Na vedlejších stránkách vlevo zobrazujeme podpoložky nabídky položky, ve které se právě nacházíme (pokud jsme například na stránce „zákaznický servis“, zobrazujeme odkazy na „záruční servis“, „pozáruční servis “). Kliknutím na tyto odkazy se tedy dostanete na odpovídající stránky. Zde pod podpoložkami vlevo zobrazujeme údaje pro kontaktování online konzultantů (Skype, ICQ). Blok akcí a vydání zůstává na každé stránce. Zápatí se zobrazuje stejně na každé stránce.

Zhruba tak je popsána obecná logika práce.

Nyní, v našich podmínkách pro vývoj webových stránek, podrobně popisujeme každý určený blok webu. Například „Zprávy“.

„Zprávy“ 10 nejnovějších zpráv. Každá zpráva by měla obsahovat název zprávy, datum vydání, stručný začátek zprávy (4-5 řádků) a odkaz „přečíst celé“. Když kliknete na odkaz „přečíst celé“, budete přesměrováni na stránku novinek. Zprávy, na které jste narazili, se zobrazují místo hlavního obsahu. Obsahuje také název zprávy a datum vydání. Vlevo je také zobrazen zdroj novinek. Zprávy z minulých měsíců a let jsou archivovány. To znamená, že pod zprávami za aktuální měsíc zobrazujeme „archiv za (takový a takový měsíc nebo rok)“. Když kliknete na odkaz „archivovat za (takový a takový měsíc nebo rok)“, rozbalí se seznam novinek za příslušný měsíc/rok.

Takto popisujeme činnost každého bloku. Nezapomeňme na událost v kalendáři. A hlavně je potřeba popsat práci produktového katalogu. Zde vám dávám úkol: zkuste se zamyslet a popsat, jak bude katalog fungovat. Zašlete své možnosti e-mailem. Nejlepší zveřejníme.

Co jiného by tam mělo být? Bylo by hezké uvést kompatibilitu.

Kompatibilita

V tomto odstavci našich podmínek pro tvorbu webových stránek uvádíme, na kterých operačních systémech a v jakých prohlížečích by měly webové stránky vypadat stejně dobře. V jaké verzi, v jakém jazyce by měl být napsán. Jaký CMS se používá. Stojí za to na to upozornit, pokud skutečně víte, o čem mluvíte.

Pokud tyto otázky neznáte, jednoduše označte prohlížeče, ve kterých by se měl web správně zobrazovat. Ve zbytku se spolehněte na svědomí interpreta.

Závěr

V tomto článku jsem se nesnažil ukázat, že takto se sestavují technické specifikace a nijak jinak. Udělejte to a nebudou žádné problémy. Sestavte kvalitativní podmínky pro vývoj webových stránek- to je spíš otázka Zkušenosti. Ne každý bude schopen vytvořit kompetentní technickou specifikaci v prvních několika letech.

V tomto článku jsem chtěl ukázat příklad a principy, na kterých je postavena vzorová technická specifikace pro vývoj designu a logiky webu, a také hlavní body, které stojí za pozornost. Jak dalece jsem uspěl, doufám, že zjistím z vašich komentářů.

A nezapomeňte na úkol!