Napište správně podmínky zadání. Struktura technických specifikací. Podmínky nákupu paliv a maziv

Otázka „Je vůbec nutné vypracovat technickou specifikaci (TOR)? může vzniknout pouze u těch, kteří si vývoj webových stránek nikdy v životě neobjednali, neboť jeho potřeba vzniká již po první komunikaci mezi zákazníkem a zhotovitelem.

Technická specifikace je dokument, který podrobně a úplně popisuje budoucí projekt. Čím je detailnější, tím přesněji bude nápad realizován a tím méně konfliktů a kontroverzních situací bude vznikat při realizaci projektu, protože naprosto cokoliv se dá dělat různými způsoby. Může se na něj odkazovat, pokud něco není dokončeno nebo provedeno nesprávně nebo jsou udělány jiné chyby. Zákazník před zahájením prací obvykle popíše budoucí projekt v abstraktní formě nebo vyplní brief a zhotovitel všechny tyto požadavky a přání formalizuje a případně navrhne úpravy. Zákazník se zároveň musí ujistit, že všechna jeho „přání“ jsou zaznamenána ve specifikacích.

Pokud je s webovým studiem nebo freelancerem uzavřena dohoda o vývoji webu, technický úkol obvykle přichází jako její příloha. A v kontroverzních situacích se řídí tím, co je tam napsáno.

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

Předpokládejme, že v rámci projektu potřebujete vypracovat technické specifikace pro vývoj webu pro copywriting studio Pero. Jaké body by měl obsahovat?

Obecné informace (popis)

Zde jsou následující:

Informace o společnosti. Obecné informace o studiu, co dělá. Nebylo by od věci uvést seznam poskytovaných služeb. Zde můžete přidat adresu budoucí webové stránky a kontaktní údaje.

Fáze a načasování projektu. Velmi důležitý bod: plán pro všechny fáze práce je zpravidla vypracován na samém konci. Tato část poskytuje pochopení toho, co a kdy se bude dělat. Například (s daty):

• Přípravná fáze;
• Vývoj konceptu webových stránek;
• Design;
• Tvorba designového rozvržení;
• Vývoj designu stránek;
• Rozložení;
• Programování;
• Obsah náplně;
• SEO optimalizace;
• Testování;
• Zahájení.

Některé fáze, například propagace SEO, nemusí existovat. Záleží na cílech a záměrech zákazníka a kompetencích zhotovitele.

Účel a cíle

Zde je formulováno, jaké funkce bude stránka plnit a pro koho je určena.

Účel webu. Jakých cílů by mělo být vytvořením webu dosaženo? Proč je to potřeba, jaké problémy řeší?

• Reklama a získávání nových klientů;
• Zákaznická a partnerská podpora;
• Ukázka dokončené práce;
• Seznámení se seznamem služeb;
• Vytváření a udržování image společnosti.

Možná by měly být některé body popsány podrobněji. Pokud je například úkolem webu také informovat návštěvníky, pak je lepší vysvětlit, o co přesně jde.

cílové publikum. Kdo bude web používat, pro koho je vytvořen?

• Webmasteři, blogeři;
• Majitelé internetových obchodů;
• Majitelé informačních portálů;
• Reklamní studia;
• Zástupci firem a společností prezentujících se v online prostoru.

Požadavky

Rozsáhlá a nesmírně důležitá sekce, která zohledňuje co nejvíce konstrukčních a vývojových aspektů, protože za funkčnost neuvedenou v technických specifikacích si zákazník bude muset připlatit.

Typ. Do jaké kategorie webový zdroj patří?

• Vstupní stránka;
• Webové stránky vizitek;
• Firemní webové stránky;
• Informační portál;
• Internetový obchod.

Požadavky na registraci. Mohou být následujícího typu:

• Web by měl být minimalistický a zároveň odrážet typ činnosti společnosti.
• Primární barvy: zelená a bílá, podle knihy značek nebo podle uvážení designéra.
• V návrhu nemůžete použít animaci, vyskakovací okna, prvky Flash ani designové excesy.
• Nelze použít patkové fonty (lze použít standardní: Verdana, Arial, Tahoma atd.). Velikost písma by měla zajistit maximální čitelnost (12-16 bodů).

Pokud jde o požadavky na design, lze použít různé přístupy. Pokud zákazník sám přesně ví, co chce dostávat, pak svá přání podrobně popíše, uvede příklady stránek, které se mu líbí a uvede další specifika. Občas se ale stane, že on sám přesně neví, jak to má všechno vypadat, v tomto případě většinou vycházejí z úkolů, které musí návrh vyřešit. Dodavatel vypracuje koncepty, nabídne řešení, obhájí svůj nápad a upraví jej na základě připomínek zákazníka. Druhá možnost je dražší a vyžaduje od zhotovitele větší kvalifikaci.

Jazykové požadavky. Mluvčí v jakém jazyce budou mít ke zdroji přístup? Jaké jazykové verze by stránky měly být?

• Ruština;
• Angličtina;
• Esperanto.

Požadavky na kompatibilitu. Z jakých zařízení a z jakých prohlížečů se stránky otevřou správně? V poslední době je trend k adaptivnímu rozložení, kdy se stránka správně zobrazí na jakémkoli zařízení s jakýmkoli poměrem stran a rozlišením obrazovky. Zde můžete uvést prohlížeče, se kterými by měl být zdroj rozhodně kompatibilní. Obvykle se stránky zobrazují stejně ve všech moderních prohlížečích, problémy jsou pouze se staršími verzemi Internet exploreru.

Požadavky na CMS. Možnosti správy webu určují, které bloky lze upravovat a konfigurovat prostřednictvím ovládacího panelu, aniž by bylo nutné zasahovat do kódu nebo přímo upravovat databázi, ale pomocí pohodlného vizuálního rozhraní. Může být formulován například takto:

• Schopnost měnit obsah na stránkách webu;
• Schopnost spravovat stránky (přidávání, přejmenování, mazání atd.);
• Schopnost upravovat strukturu webu a položky nabídky;
• Funkce automatického zpracování grafiky (vytváření náhledů, transformace na danou velikost atd.);
• Schopnost psát jedinečné meta tagy;

Stejně jako v jiných podsekcích je potřeba popsat všechny požadavky a přání.

Často má zákazník již zkušenosti s prací s některým z oblíbených CMS, pak je vhodné hledat dodavatele pro konkrétní motor. Také při výběru CMS je lepší nespokojit se s řešeními napsanými vlastními silami, protože v budoucnu to bude záviset na interpretovi. Samostatně napsané motory podle mého názoru mají opodstatnění pouze ve velmi velkých projektech, kde je vyžadována specifická funkčnost nebo optimalizace velkých zátěží.

Struktura a navigace. Jaké sekce, podsekce a jednotlivé stránky bude projekt obsahovat?

• Domovská stránka
• Služby

• Copywriting
• Přepisování
• SEO copywriting
• Korektura
• Transkripce
• Správa obsahu
• Obsahový marketing

• Portfolio
• O nás
• Kontakty

Uveďte stručný popis každé stránky a uveďte definice. Co například znamená stránka „Kontaktujte nás“? Má obsahovat adresu, telefon a email v textové podobě? Nebo by tam měl být formulář pro zpětnou vazbu? Nebo možná potřebujete vložit kód Yandex Maps? Nebo má kontaktní stránka obsahovat vše výše uvedené plus odkazy na zástupce na sociálních sítích?

Obsah je vhodné připravit nebo alespoň nastínit před zahájením práce se zhotovitelem. To podpoří efektivnější komunikaci.

Další požadavky. Vše, co není zahrnuto v jiných částech sekce.

Popis sekcí webu

V tomto bodě jsou detaily. Obvykle je popsán obsah všech unikátních stránek: jaké prvky tam budou, jak s nimi bude uživatel pracovat.

Domovská stránka. Formulace problému může být následující.

Hlavní část hlavní stránky by měla být vytvořena ve formě vstupní stránky. Následující prvky by na něm měly být umístěny shora dolů:

• Záhlaví - logo, název společnosti;
• Navigační menu;
• Informace o akcích a slevách;
• tlačítko objednat;
• Reklamní texty;
• Blok s pěti nejlepšími pracemi a odkazem na sekci portfolia;

Pro začátek musíme připomenout, že referenční podmínky (TOR) jsou oficiálním dokumentem, který je nedílnou součástí Smlouvy o vývoji webových stránek.

Technická specifikace obsahuje technické zdůvodnění vývoje a požadavky na projektované místo (design, navigace, způsoby prezentace informací); určuje načasování, náklady, objem a pořadí implementace každé fáze vývoje.

Referenčními podmínkami je původní dokument návrhu webových stránek, schválený bilaterálně zákazníkem a dodavatelem. Technická specifikace je hlavním dokumentem, na jehož základě se provádí vývoj a posuzuje se kvalita hotového výrobku.

Na základě technických specifikací jsou akceptovány nebo zamítnuty nároky objednatele na kvalitu díla zhotovitele, je zaplaceno hotové dílo a je vystaven převodní a přejímací certifikát.

bikeriderlondon / Shutterstock.com

Zadávací podmínky vypracovává zhotovitel na základě vypracovaného zadání, analýzy výsledků předběžných studií, výpočtů a návrhového modelování budoucího staveniště. Technická specifikace musí zohledňovat všechny požadavky, aspekty a detaily budoucí lokality.

Tento dokument poskytuje kompletní sadu požadavků na implementaci webu.

Zákazník a zhotovitel souhlasí

Podpisem Zákazníka a Zhotovitele v 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 (TOR), který obsahuje seznam požadavků na prováděné práce.
2. Zákazník souhlasí se všemi ustanoveními těchto Podmínek.
3. Po schválení TOR pozbývají platnosti všechny předchozí dohody a platná jsou pouze ustanovení těchto TOR.
4. Zákazník nemá právo požadovat od zhotovitele v rámci aktuální smlouvy provedení díla nebo poskytnutí služeb, které nejsou výslovně popsány v tomto vyúčtování.
5. Zhotovitel provádí pouze práce uvedené v těchto ZP.
6. Vše, co přesahuje rámec těchto Podmínek, hradí Zákazník dodatečně na základě dodatků k těmto Podmínkám schválených stranami.
7. Zhotovitel zahájí provádění prací dle technické specifikace, po: písemném odsouhlasení technické specifikace, obdržení všech potřebných informací uvedených v technických specifikacích, obdržení potřebných materiálů od objednatele a doplnění platebních míst.
8. Objednatel se zavazuje převzít dílo po dokončení do 3-5 pracovních dnů, uhradit dílo na této specifikaci díla v termínu tam uvedeném, bude-li dílo dokončeno v plném rozsahu a v souladu s výkazem práce.
9. Zákazník nemá právo požadovat, aby zhotovitel dodržoval jakékoli formáty a normy, pokud to není uvedeno v těchto podmínkách.
10. Veškeré práce na tvorbě webu jsou prováděny na vlastním hostingu Zhotovitele. Po dokončení všech prací je přenesen na skutečný server k testování.
11. Po dokončení díla poskytuje zhotovitel konzultace administrativy do 5 pracovních dnů, maximálně však půl hodiny denně. Dodatečný čas se hradí zvlášť, dle aktuálního tarifu zhotovitele.
12. Veškeré nejasnosti uvedené v této TOR po jejím 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.
13. Ustanovení tohoto dokumentu jsou pro vývojáře závazná po jeho schválení předepsaným způsobem.
14. Technická specifikace je prostředkem k ověření provedené práce.

Související článek: 10 užitečných tipů při tvorbě webu

Kompatibilita s prohlížečem

Musíte zvážit funkčnost různých prohlížečů, které vaši návštěvníci pravděpodobně používají. Chcete-li zajistit identické zobrazení webu, musíte zajistit kompatibilitu s nejoblíbenějšími prohlížeči:

• Internet Explorer (verze 8 a vyšší);
• Mozilla Firefox (verze 3 a vyšší);
• Google Chrome (verze 4 a vyšší);
• Opera (verze 10 a vyšší).

Požadavky na vzhled webových stránek

Text musí být čitelný. podle statistik, minimální rozlišení obrazovky uživatelských monitorů je 1024 x 768 pixelů. V tomto rozlišení by měl veškerý text na webu vypadat jasně a jasně viditelný bez použití vodorovného posuvníku. Při rozlišení nižším než 1024x768 se zobrazí vodorovný posuvník.

Stránky by také měly mít limit maximální velikosti, aby vypadaly dobře na monitorech s vysokým rozlišením. Proto maximální šířka webu bude 1280x1024.

Požadavky na změnu obsahu webu

Pro vzdálenou správu (přidávání, úpravy a mazání textových a grafických informací) lze využít bezplatný systém pro správu obsahu webových stránek (CMS), např. WordPress. Můžete ale použít i UMI.CMS (pro uživatele je pohodlnější web upravovat, ale pro vývojáře náročnější). Pokud si tedy Zákazník přeje používat UMI.CMS, náklady na implementaci se sjednávají samostatně, po schválení návrhu. Bude to přibližně o 50 % dražší než náklady na programování.

Pomocí CMS můžete snadno přidávat nové sekce a podsekce, ale kromě správy obsahu databáze nebude možné měnit vzhled webu.

souhrn

Čím podrobněji popíšete úkoly, před kterými stojí vývojář webu, tím snazší bude dokončení projektu. Dokonce k tomu, abych napsal, jak se obrázek otevře ve vyskakovacím okně, v jakém rámu bude a zda se otevře s nějakým dodatečným efektem. Protože zákazníci velmi často i při tvorbě webu usilují o úpravy textu, obrázků a podobně, což vlastně patří do úplně jiné fáze, která se nazývá „Plnění webu“ nebo „Aktualizace webu“.

Technický úkol (TK, podmínky zadání) - zdrojový dokument pro vývoj a testování internetového obchodu.

Pojem technické specifikace

Technické specifikace - originální projektový dokument technický předmět (produkt). Technická specifikace stanoví hlavní účel vyvíjeného objektu, jeho technické vlastnosti, ukazatele kvality 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 jako speciální požadavky.

Zadání se také používá při vytváření kreativního objektu (videoklip, článek, grafický obrázek).

Dá se říci, že technická specifikace je dokument, který popisuje CO zákazník potřebuje, na rozdíl od navazující projektové dokumentace, ve které je kladen důraz na zodpovězení otázky JAK toho dosáhnout.

Technická specifikace je právní dokument - žádost je součástí smlouvy mezi objednatelem a zhotovitelem projekční práce a je jejím základem: určuje postup a podmínky prací včetně účelu, cílů, zásad, očekávaných výsledků a termínů. .

Veškeré změny, doplňky a upřesnění znění technických specifikací musí být odsouhlaseny se zákazníkem a jím schváleny. To je také nezbytné, protože pokud se v procesu řešení konstrukčního problému objeví nepřesnosti nebo chyby ve výchozích datech, je nutné určit míru zavinění každé ze stran zúčastněných na vývoji a rozložení ztrát vzniklých v souvislosti s tím.

Místo technických specifikací ve struktuře návrhu

Design je proces (vývoj projektu), který má určité struktura, tedy posloupnost a skladba etap a fází, soubor postupů a použitých technických prostředků, interakce účastníků procesu.

Design je v souladu s občanským zákoníkem jedním z druhů smluvních prací, jejichž výsledkem jsou výrobky ( projekt), tedy soubor projektové dokumentace jiného výrobku ( designový objekt). Projekt je určen k vytvoření objektu, jeho provozu, opravě a likvidaci, jakož i k ověření či reprodukci mezilehlých a konečných řešení, na jejichž základě byl tento objekt vyvinut.
Slovo "projekt" v oblasti činnosti "projektový management" používá se ve významu „program“, „akční plán“, „balíček práce“.

Účastníci projekční práce jsou rozděleni na spotřebitele ( zákazníky tyto práce) a dodavatelé ( účinkujících tyto práce, dodavatelé). Specializovaný umělec se nazývá designér nebo vývojář. Dodavatelem, stejně jako spotřebitelem produktu, může být organizace (právnická osoba) nebo konkrétní osoba (fyzická osoba).

Návrhovým předmětem může být hmotné zařízení, nebo výkon práce, nebo poskytování služby, například budova nebo průmyslový areál, technické zařízení (přístroj, stroj, přístroj), řídicí systém, informační systém , regulační dokumentace (například norma) atd.

Fáze návrhu jsou upraveny normami. Toto je následující sekvence:

• Technické specifikace (podle GOST 2.103-68 se nevztahuje na vývojové fáze),
• Technický návrh,
• Předběžný návrh,
• technický projekt,
• Etapy pracovního projektu.

Řešení jakéhokoli problému začíná jeho pochopením a ujasněním výchozích dat. Tyto (technické) požadavky, které jsou vystaveny zákazníkem, jsou formulovány v jazyce nespecializovaného spotřebitele a nejsou vždy technicky jasné a komplexní. Přeložit požadavky do jazyka předmětu, formulovat problém co nejúplněji a nejkompetentněji, zdůvodnit nutnost jeho řešení, to je hlavní cíl technické specifikace, povinná etapa práce. Zhotovitel ji provádí v úzkém kontaktu se zákazníkem. Ve skutečnosti to znamená, že práce dodavatele na projektu již začala.
Ve strojírenství se této fázi někdy říká vnější design.

Technické specifikace jsou zpravidla sestavovány na základě analýzy výsledků předběžných studií, výpočtů a modelování.

Soukromé technické úkoly

V procesu navrhování komplexního objektu (systému), vyžadujícího účast několika vývojářů, vznikají soukromé technické specifikace pro subsystémy.

Vývojář systému v souladu s obdrženými technickými požadavky vygeneruje technické specifikace a ve fázi technického návrhu provede rozklad objektu a připraví konkrétní technické specifikace pro subsystémy. Po dokončení všech fází technického návrhu jej vývojář zkoordinuje a schválí se zákazníkem systému a společně si ujasní výchozí technické specifikace.

Po schválení technického návrhu vývojář systému rozešle soukromé technické specifikace mezi spoluvykonavatele, na jejichž základě mohou být vypracovány soukromé technické specifikace pro subsystémy nižších úrovní. Pokud subsystémy druhé úrovně chybí, pak se technický návrh subsystémů často nerealizuje, protože byl prakticky dokončen na úrovni systému.

Po dokončení fáze distribuce technických specifikací začnou vývojáři systému a jeho subsystémů provádět fázi předběžného návrhu. Vývoj struktury v této fázi probíhá za úzké spolupráce všech vývojářů. Při této práci se jednotlivé části na sebe navážou a dohodnou se hlavní parametry navrženého objektu. Kvalita návrhu závisí na šíři vize developera o problému, tedy na jeho obzorech a schopnosti zohlednit všechny souvislosti uvažovaného objektu a na přítomnosti znalostí, které pokrývají související oblasti. V procesu předběžného návrhu a koordinace jednotlivých řešení s obecným je možné upravit technické specifikace.

Po dokončení předběžného návrhu, koordinaci a odsouhlasení výsledných technických řešení se zákazníkem přechází do fáze technického návrhu. Zde se provádějí všechny hlavní stavební práce na objektu a jeho částech. Je možné objasnit technická řešení s návratem k předchozím etapám. Technický návrh probíhá v úzké spolupráci všech vývojářů.

Potřeba technických specifikací

Prvotní úkol zadává zákazník. Hlavními důvody, které jej nutí obrátit se na vývojáře, jsou nedostatek relevantních speciálních znalostí zákazníka nebo omezené zdroje (nedostatek času na vyřešení problému, požadovaný počet lidí, vybavení).

Úkol může být jasně definován, například když všechny práce provádí jedna osoba, nebo je zadává renomovaný odborník, nebo jej nelze zpochybnit (nařízení vlády). Častěji je však formulován obecně v jazyce nespecializovaného spotřebitele, daleko od jazyka vývojáře a termínů předmětné oblasti. Nejisté požadavky způsobují nejistotu mezi všemi účastníky práce, protože umožňují různé výklady požadavků a neumožňují objektivní posouzení kvality vyvíjeného produktu. Vývojář také musí pochopit, že zákazník nemusí znát (nebo částečně znát) speciální požadavky, což nezbavuje developera odpovědnosti a povinnosti dodržovat požadavky dozorových orgánů, bez ohledu na jejich přítomnost v úkolu. Za stanovení rozvojových cílů a užitečnost jeho výsledku je tedy odpovědný nejen zákazník, ale i vývojář (performer).

Vypracování technických specifikací je složitý a odpovědný úkol: mnoho údajů ještě není známo, ale to, jak je úkol nastaven, může usnadnit nebo ztížit následný návrh (obrazně řečeno „jak loď nazvete, tak bude plout“). .

Odborníci se domnívají, že kompetentní technická specifikace je více než 50 % úspěchu při řešení problému a čas strávený přípravou technických specifikací je jednou z nejlepších investic, které může společnost během období návrhu provést. Ne nadarmo je příprava technických specifikací svěřena předním specialistům – hlavním konstruktérům, vedoucím projektů a prací atp.

Řekl akademik A. N. Krylov. V jedné továrně byl instalován nový stroj, ale nemohli ho uvést do provozu. Pak se obrátili o pomoc na univerzitního profesora. Když dorazil do továrny, dlouho obcházel auto, pečlivě něco hledal a něco poslouchal. Pak vzal kladivo a udeřil do jejího těla. A auto začalo fungovat. Profesor za jeho pomoc požádal vedení továrny o 100 rublů (to bylo na počátku 20. století). Ale vedení továrny se domnívalo, že to bylo příliš mnoho na to, aby zaplatili za jeden úder kladivem. Na což profesor odpověděl, že samotný úder stojí jeden rubl, ale kam ho zasáhnout stojí 99 rublů. Bylo zjištěno, že pokud jsou náklady na opravu konstrukční chyby provedené ve fázi technického návrhu brány jako 1, pak náklady na její opravu vzrostou přibližně 10, 100 a 1000krát, pokud byla chyba učiněna ve fázích předběžného návrhu. design, technický návrh a technické specifikace!

Jako komunikační nástroj v komunikačním spojení zákazník-provozovatel vám technické specifikace umožňují:

• Oběma stranám:
  • představte si (představte si) hotový výrobek,
  • provést bodovou kontrolu hotového výrobku (přejímací zkouška - provedení testy),
  • snížit počet chyb spojených s měnícími se požadavky v důsledku jejich neúplnosti nebo chyby (ve všech fázích a fázích tvorby, s výjimkou testy).
• Zákazníkovi:
  • uvědomit si, co přesně potřebuje,
    • včetně spoléhání se na současné technické možnosti a naše zdroje,
  • požadovat po zhotoviteli dodržení všech podmínek uvedených v technických specifikacích.
• Umělec:
  • pochopit podstatu úkolu, ukázat zákazníkovi „technický vzhled“ budoucího produktu, softwarového produktu nebo automatizovaného systému,
  • plánovat realizaci projektu a pracovat podle plánu,
  • odmítnout provést práce neuvedené v technických specifikacích.

Regulované technické specifikace

Přes svůj význam je obsah technických specifikací málo regulován regulačními dokumenty (GOST, OST).

• GOST 19.201-78. Jednotný systém programové dokumentace. Technický úkol. Požadavky na obsah a design (obsah technických specifikací je stručně nastíněn);
• GOST 34.602-89. Informační technologie. Soubor standardů pro automatizované systémy. Technické specifikace pro vytvoření automatizovaného systému (složení a obsah technických specifikací jsou popsány dostatečně podrobně);
• GOST 25123-82. Počítačové stroje a systémy pro zpracování dat. Technický úkol. Pořadí konstrukce, prezentace a návrhu (je uvedeno pořadí konstrukce technické specifikace).

Z hlediska provádění výzkumných prací je technická specifikace upravena následujícími dokumenty:

• OST 95 18-2001. Postup při provádění výzkumných a vývojových prací. Základní ustanovení.
• Příloha č. 3 Pravidel pro přijímání VaV, schválená nařízením Rosprom dne 16. září 2004 č. 95. Zadání pro výzkumnou práci (v příloze je vzor zadání pro vývoj v rámci Řádu obrany státu)

Části technických specifikací podle GOST 34.602-89 (příklad)

Podle GOST 34.602-89 musí technická specifikace obsahovat následující oddíly (uvedené ve zkrácené formě):

1. Obecná informace
   1. úplný název systému a jeho symbol;
      Příklad:
      Celý název systému: Automatizovaný systém „Management“
      Symbol: ACS
   2. kód předmětu nebo kód (číslo) smlouvy;
      Příklad:
      Smlouva č. XXX ze dne DD.MM.RRRR
   3. název podniků (sdružení) vývojáře a zákazníka (uživatele) systému a jejich podrobnosti;
      Příklad:
      ZÁKAZNÍK Jméno zákazníka: MIR LLC Sídlo zákazníka: 142345, Moskva, st. Tverskaya, dům 15 Poštovní adresa zákazníka: 142345, Moskva, st. Tverskaya, dům 15 Skutečná adresa zákazníka: 142345, Moskva, st. Tverskaya, budova 15 Telefon: +7 903 456 67 67 Fax: +7 903 453 34 54 E-mailová adresa: [e-mail chráněný] OGRN: 4554545445454 INN: 4343434345 KPP: 453345443 BANKA: ZAO BankStroy, Moskva BIC: 444454554 RS: 564456456456454453404230KS: 004204230KS:004
      DODAVATEL Jméno zhotovitele: LLC "DYATEL" Sídlo objednatele: 142345, Moskva, st. Lenina, dům 34 Poštovní adresa zákazníka: 142345, Moskva, st. Lenina, dům 34 Skutečná adresa zákazníka: 142345, Moskva, st. Lenina, budova 34 Telefon: +7 495 345 63 63 Fax: +7 495 433 34 54 E-mailová adresa: [e-mail chráněný] OGRN: 4554545445454 INN: 4343434345 KPP: 453345443 BANKA: ZAO BankStroy, Moskva BIC: 444454554 RS: 564456456456454453404230KS: 004204230KS:004
   4. seznam dokumentů, na základě kterých je systém vytvořen, kým a kdy byly tyto dokumenty schváleny;
   5. plánovaná data zahájení a ukončení prací na vytvoření systému;
   6. informace o zdrojích a postupu financování díla;
   7. postup při evidenci a prezentaci výsledků práce na vytváření systému (jeho částí), na výrobě a úpravě jednotlivých prostředků (hardware, software, informace) a softwarových a hardwarových (softwarových a metodických) komplexů systému zákazníkovi. Systém.
2. Účel a cíle tvorby systému
3. Charakteristika objektu automatizace
   1. stručné informace o objektu automatizace nebo odkazy na dokumenty obsahující takové informace;
   2. informace o provozních podmínkách automatizačního zařízení a charakteristikách prostředí.
4. Požadavky na systém
   1. Požadavky na systém jako celek;
   2. Požadavky na funkce (úkoly) prováděné systémem;
   3. Požadavky na typy zajištění.
5. Skladba a obsah práce na vytvoření systému
   1. seznam dokumentů v souladu s GOST 34.201 předložený na konci příslušných etap a fází práce;
   2. druh a postup prověřování technické dokumentace (stupeň, stupeň, kontrolovaný objem dokumentace, odborná organizace);
   3. program práce zaměřený na zajištění požadované úrovně spolehlivosti vyvíjeného systému (v případě potřeby);
   4. seznam prací na metrologické podpoře ve všech fázích tvorby systému s uvedením jejich termínů a provádějících organizací (v případě potřeby).
6. Postup pro kontrolu a přejímku systému
   1. typy, složení, rozsah a zkušební metody systému a jeho součástí (typy zkoušek podle aktuálních norem platných pro vyvíjený systém);
   2. obecné požadavky na přejímku díla po etapách (seznam zúčastněných podniků a organizací, umístění a načasování), postup koordinace a schvalování přejímací dokumentace;
   3. stav přejímací komise (státní, meziresortní, resortní).
7. Požadavky na skladbu a obsah prací na přípravu objektu automatizace pro zprovoznění systému
   1. uvedení informací vstupujících do systému (v souladu s požadavky na informační a jazykovou podporu) do podoby vhodné pro zpracování pomocí počítače;
   2. změny, které je třeba provést v objektu automatizace;
   3. 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;
   4. vytvoření oddělení a služeb nezbytných pro fungování systému;
   5. načasování a postup pro personální obsazení a školení.
8. Požadavky na dokumentaci
   1. seznam sad a typů dokumentů, které mají být vyvinuty, které splňují požadavky GOST 34.201 a vědecká a technická dokumentace zákaznického průmyslu, odsouhlasená vývojářem a zákazníkem systému; seznam dokumentů vydaných na počítačových médiích; požadavky na dokumentaci mikrofilmování;
   2. požadavky na dokumentaci součástí pro meziodvětvové použití v souladu s požadavky ESKD a ESPD;
   3. při absenci státních norem definujících požadavky na dokumentaci prvků systému dodatečně zahrnout požadavky na skladbu a obsah takových dokumentů.
9. Zdroje vývoje: dokumenty a informační materiály (studie proveditelnosti, zprávy o provedených výzkumných pracích, informační materiály o domácích a zahraničních analogových systémech atd.), na jejichž základě byly vypracovány technické specifikace a které by měly být použity při tvorbě systému .

Druh a složení požadavků technických specifikací

Obvykle si zákazník stanoví cíl (jak jej chápe) a omezení zdrojů (čas, peníze). Úkolem performera je především přeložit požadavky do jazyka oboru, co nejúplněji a nejkompetentněji formulovat problém a zdůvodnit potřebu jeho řešení. V důsledku toho bude technická specifikace obsahovat následující informace:

• Cíle ve funkční podobě. Výrobek je pouze materiálním nosičem určitých funkcí, jehož realizace vám umožní dosáhnout stanovených cílů (uspokojit potřeby). Stejnou funkci však mohou vykonávat různá zařízení. Funkční spíše než věcné naznačení cíle tedy rozšiřuje okruh možných řešení, která je nezbytná pro nalezení optimálního řešení. Funkce je také jasnějším pojmem pro popis podstaty účelu zařízení. Vyjasnění cílů a přiřazení odpovídajících funkcí je nejdůležitější částí práce na vypracování technických specifikací;
• Výkon funkcí realizujících dané potřeby je vždy vázán na uspokojení určitých požadavků (viz seznam standardních požadavků na technická zařízení), které zatraktivňují výrobky, zohledňují a upřesňují vlastnosti výroby a provozu atd. Pro pohodlí, požadavky jsou rozděleny do tří skupin typů:
  • podmínky jsou charakterizovány specifickými datovými hodnotami (formálně mohou být reprezentovány ve formě rovnosti). Například hmotnost produktu by měla být 10 kg, měla by být použita ocel 40X a místem provozu by měla být tundra. Důležitou součástí podmínek je posouzení dostupných zdrojů;
  • omezení určují přípustnou datovou oblast (formálně mohou být reprezentovány ve formě jednostranných nebo oboustranných nerovností). Například hmotnost výrobku by neměla přesáhnout 10 kg, měla by být použita uhlíková ocel;
  • indikátory kvality (které jsou převedeny na optimalizační kritéria) specifikují pouze seznam charakteristik a směr hledání preferované hodnoty (maximální nebo minimální hodnota, například hmotnost produktu by měla být minimální a snadnost údržby by měla být maximální ). Konkrétní hodnota indikátoru se stává známou až na konci etapy nebo celého cyklu projekční práce a slouží jako měřítko preference v procesu hledání optimální varianty (základ pro výběr konečné varianty).

Stejně jako proces návrhu je řízena i práce s požadavky. Tyto postupy jsou dobře zavedené např. v správa softwarových požadavků.

Pro specifikaci cílů a požadavků, které jsou vágně nebo kvalitativně specifikovány, se používá metoda dekompozice.

Při vytváření systému požadavků je nutná analýza následujících zdrojů:

• Dostupnost zdrojů, které má zákazník a vývojář k dispozici: finanční, výrobní, lidské, časové. Všechny zdroje jsou vzájemně propojeny, například navýšením financování projektu lze zkrátit dobu vývoje. Důsledkem míry přístupnosti je zavedení omezení metod a přesnosti řešení konstrukčního problému, což následně ovlivňuje typ zvoleného modelu. Při časovém limitu tak provádějí vyhodnocovací výpočty zjednodušenými metodami nebo využívají hotový software, standardní metody, standardní vybavení, standardní a nakupované díly a sestavy atd. Zároveň je model, způsob a přesnost modelu řešení musí zajistit shodu s požadavky technických specifikací, i když jsou vysoké.
• Zohlednění požadavků dozorových a povolovacích orgánů při projektování např. technologických celků (výrob). V souladu se zákony Ruské federace vyžaduje jakákoliv výroba získání regionální provozní licence. Mnoho výrobních zařízení je navíc licencováno dozorovými orgány a podléhá jejich kontrole. Nejčastěji kontrolujícími jsou regionální orgány Rostechnadzor, Rosstandart, Ministerstvo pro místní rozvoj Ruska (dříve Gosstroy), Rospotrebnadzor, Rosprirodnadzor, Státní požární služba, Ministerstvo vnitra Ruska, Rostrud.
• Životní prostředí navrženého systému. Specifikuje požadavky charakterizující vzájemné ovlivňování navržené soustavy a okolních živých a neživých objektů a vnějšího prostředí. Základní pokyny k němu jsou uvedeny v technických požadavcích za podmínek spotřeby budoucích výrobků. Tyto stavy lze charakterizovat zcela obecně a vyžadují upřesnění.

Vypracování seznamu požadavků na technické specifikace

Práce na technických specifikacích zahrnují řadu fází. A nejistota, která je této práci vlastní, způsobuje, že je několikrát, iterativně procházejí, od obecnější formulace problému k jeho detailnímu rozpracování (návrh je iterativní povahy a to, co se na začátku nebere v úvahu, lze vzít v úvahu účet v následujících fázích).

Nejprve si povíme příběh o tom, jak si Edison stanovil technický úkol.

Před zahájením vývoje elektrického osvětlení pro domácnost provedl Edison výzkum, za jakých podmínek by konkurovalo cenou, jasem a pohodlím plynovému osvětlení (houkačce). Podrobně studoval plynárenství, vypracoval plán centrální elektrárny a schéma elektrického vedení do domů a továren. Poté spočítal náklady na měď a další materiály, které by byly potřeba k výrobě lamp a elektřiny pomocí parou poháněného dynama. Analýza dat určila nejen rozměry lampy, ale také její konkurenceschopnou cenu, rovných 40 centů. A teprve když se Edison přesvědčil, že dokáže vyřešit problém elektrického osvětlení, začal pracovat na žárovce s uhlíkovým vláknem umístěným ve skleněné kouli, ze které byl odčerpáván vzduch. Při hledání materiálu nití testoval asi 6000 druhů rostlinných vláken.

Analýza zadání zákazníka

Prvotní úkol vystaví zákazník a je sepsán ve formuláři technické požadavky. Převést tyto požadavky do jazyka předmětné oblasti, co nejúplněji a nejkompetentněji formulovat problém, zdůvodnit nutnost jeho řešení, pochopit a ujasnit si výchozí data je první fází práce. Zhotovitel ji provádí v úzkém kontaktu se zákazníkem.

Měli byste identifikovat a pokusit se vyhnout následujícím problémům:

• úkoly, které neodpovídají společenským potřebám – kriminální, nemorální, nelidské. Jejich rozhodnutí je věcí svědomí developera;
• technické pseudoúkoly s chybně položenými cíli. Jedná se o úkoly, které již řešení mají, nebo nemají pro své řešení objektivní předpoklady (úlohy předčasné, ale to je potřeba zdůvodnit, aby odmítnutí řešení nebylo důsledkem psychické setrvačnosti nebo jiných subjektivních důvodů);
• chimérické problémy. Jde o úkoly s chybně stanoveným cílem, jejichž dosažení odporuje fyzikálním zákonům (např. vytvoření zařízení s účinností vyšší než 100 %, okamžité zařízení apod.), nebo abstraktně předkládané úkoly, které zásadně mají žádné řešení (jako třeba kámen mudrců).

Při sestavování technických specifikací je důležité přistupovat k výchozím požadavkům kriticky a bez předsudků. K tomu potřebujete:

• ujistit se, zda uvedené potřeby jsou pro zákazníka skutečně cenné, zda jsou výchozí údaje pravdivé, jaké nepříznivé či škodlivé důsledky mohou nastat v procesu realizace této potřeby;
• zjistit podstatu potřeby, najít zdroj jejího výskytu;
• zjistit, co brání použití předchozího produktu k uspokojení nových potřeb.

Hlavním důvodem potřeby nového vývoje je dostupnost rozpory mezi touhou a možností uspokojení potřeby. Pokud neexistuje žádný rozpor, pak lze potřebu uspokojit bez vytváření nových produktů. Pokud se zdá, že neexistuje žádný rozpor, ale stávající řešení nevyhovuje, znamená to, že rozpor skutečně existuje a měli byste jej pečlivě hledat.

Rozpor lze rozložit, tedy představit ve formě elementárních problémů.

Ve většině případů je znám prototyp: prototyp nebo originální produkt, který přestal uspokojovat zákazníka. Přítomnost prototypu zjednodušuje rozhodování, ale jeho absence nevytváří psychologickou setrvačnost v podobě předem stanovených cest řešení, které ne vždy vedou k nejlepšímu výsledku.

• nebo zapomenout na jeho existenci a od počáteční potřeby nabídnout možné možnosti s následným výběrem toho nejlepšího;
• nebo zlepšit prototyp pomocí IFR;
• nebo lokalizovat potřebu. Obvykle je neuspokojivý výkon spojen s nedokonalostí pouze některých subsystémů. Za tímto účelem je prototyp rozložen podle jeho funkčních charakteristik a rozpor je prezentován ve formě elementárních problémů. Korelací elementárních problémů s určitými subsystémy prototypu jsou identifikovány „nedokonalé“ subsystémy. Od řešení obecného a složitého problému se tedy přechází k jednoduššímu konkrétnímu problému. Stupeň zlepšení vlastností se však může ukázat jako nízký a mohou nastat problémy při propojování vylepšených subsystémů s předchozími.

Specifikace cílů návrhu

Po vyjasnění a zdůvodnění rozvojových cílů jsou přiřazeny odpovídající funkce. Aby předsudky a psychologická setrvačnost nezužovaly oblast hledání a zákazník svou formulací problému nepředurčoval směr hledání řešení, je vhodné funkci formulovat obecně a neutrálně. Funkci „knock down“ (například desky) je tedy lepší nahradit pojmem „connect“, který umožňuje uniknout z přirozené asociace – srážení hřebíky a nabízí širší škálu možných řešení.

V procesu hledání nejúplnější a nejpřesnější formulace se buduje řetězec funkcí (strom cílů) – od původně navrženého až po nakonec přijaté. Tomu pomůže odpověď na otázku „Proč je to potřeba? (a další otázky metody testovacích otázek). Ve většině případů je cílem uvedeným v požadavcích potřeba vykonávat (postupně nebo současně) několik funkcí. Pro každou z nich je vytvořen řetězec funkcí.

Spolu s potřebou nějaké akce může existovat také potřeba neprovést akci nebo provést akci s negativním účinkem.

Zpracování shromážděných informací

1. Zobecnění a abstrakce.
Jednotlivé fragmenty jsou propojeny a shrnuty tak, aby byla pokud možno získána úplná, jasná a stručná představa o vyvíjeném objektu s přihlédnutím k možným změnám. Duplicitní informace jsou odstraněny, včetně těch, které se opakují v jiných formulacích nebo jsou zvláštním případem.

Abstrakce má formulovat požadavky tak, aby se zabránilo předurčování způsobů řešení problému (nevytvářely psychologické bariéry). Pro získání „silných“ řešení se doporučuje posílit systém požadavků a prohloubit rozpory formulací IFR.

2. Zkontrolujte nekonzistenci.
Pokud existuje několik funkcí, některé z nich mohou být ve svém účinku protichůdné (např. voda by měla být horká (na spařování), ale nepálit si ruce). K vyřešení rozporů je efektivní použití heuristických metod. Odstranění rozporů je přitom možné jak ve fázi sepisování technických specifikací (změna znění funkcí, rozložení jejich působení v čase či prostoru atd.), tak i v navazujících fázích návrhu.

Podmínky a omezení by měly být také zkontrolovány z hlediska nekonzistence. Omezení tedy mohou určit prázdnou množinu. Tyto rozpory nejsou vždy zřejmé: informace o horní a dolní hranici mohou být obdrženy v různých časech nebo umístěny na různých místech ve výkazu práce a mohou být prezentovány v implicitní formě.

3. Rozdělení požadavků na podmínky, omezení a ukazatele kvality.
Prezentace požadavků ve formě ukazatelů umožňuje získat řešení s vysokým výkonem, ale tento problém je obtížnější vyřešit. Ukazatele jsou ty, které charakterizují nejdůležitější vlastnosti (aby bylo možné získat nejlepší hodnoty). Pro zadané podmínky je nutné vyhodnotit velikost rozptylu a nutnost udávat limitní hodnoty, tedy prezentovat je formou omezení.

4. Parametrizace.
Přesnost úsudku a správnost výběru závisí na míře specifičnosti výchozích požadavků, ať už jsou prezentovány ve formalizované nebo neformální podobě. Aby byly závěry jednoznačné, musí být všechny požadavky převedeny do formalizované podoby, to znamená, že musí být uvedeny parametry, které je charakterizují, a ty, které lze měřit, kontrolovat a vypočítat. To také umožní identifikovat duplicitní požadavky (ty, které se vyznačují stejnými parametry) a zobecnit je (zavést zobecněné parametry za účelem snížení jejich celkového počtu, specifické charakteristiky).

Při řešení optimálního konstrukčního problému se doporučuje redukovat ukazatele kvality na formalizovanou formu založenou na kritériích, tj. přiřadit jim číselnou míru. Hlavní metodou pro specifikaci formulací je sestavení stromu cílů (stromy AND nebo OR): počáteční indikátor se rozloží, aby se identifikovaly elementární koncepty, které jsou jednoznačně charakterizovány sadami parametrů.

Věda „Kvalimetrie“ se zabývá problémy hodnocení kvality prostřednictvím kvantitativních ukazatelů.

5. Zkrácení seznamu požadavků.
Velké množství informací, i když je schopno podat nejúplnější obrázek o řešeném problému, je obtížnější udržet v hlavě a komplikuje řešení problému. Pro redukci informací na rozumný objem (podle schopností každého konkrétního vývojáře, dodržení jeho finančních, organizačních, technických a časových zdrojů) lze využít jejich řazení či rozdělení do skupin povinných, žádoucích a nepodstatných. Mezi povinné patří ti, jejichž nespokojenost výrazně ovlivňuje výběr možností rozhodování. Jedná se o funkční parametry, podmínky pro vztah systémů a jejich částí a další. Žádoucí požadavky umožňují rozlišovat mezi možnostmi na základě kvality.

Stojí za to vzít v úvahu slova Lee Iacocca: „...problém je v tom, že jste studoval na Harvardu, kde vám v hlavě vrtali, že nemůžete podniknout žádné kroky, dokud neshromáždíte všechna fakta. Máte 95 % informací a abyste nasbírali chybějících 5 %, budete potřebovat dalších šest měsíců. Během této doby budou všechna fakta zastaralá, protože trh se vyvíjí mnohem rychleji. Nejdůležitější v životě je dělat vše včas. ...hlavním úkolem je posbírat všechna důležitá fakta a pohledy, které máte k dispozici. Ale v určitém okamžiku musíte začít jednat rozhodně. Jednak proto, že i to nejsprávnější rozhodnutí se ukáže jako špatné, pokud je učiněno příliš pozdě. Za druhé proto, že ve většině případů neexistuje úplná jistota. Nikdy nebudete schopni shromáždit 100 % informací. Bohužel život nepočká, až vyhodnotíte všechny možné přepočty a ztráty. Někdy se prostě musíte posunout vpřed náhodně a opravit chyby za pochodu.“

6. Sestavení požadavků do jednoho dokumentu a jeho schválení zákazníkem.

Literatura

• Khoroshev A.N.Úvod do managementu návrhu strojních systémů: Studijní příručka. - Belgorod, 1999. - 372 s. - ISBN 5-217-00016-3 Elektronická verze 2011

Zadání - písemný příkaz protistrany k provedení stanovených úkonů nebo provedení požadované práce (služby). Samostatně se takový dokument obvykle nepoužívá.

A přesto je v některých případech takový úkol jediným písemným potvrzením vzniku práv a povinností.

Pravidla platná pro taková zadání

Jsou (pravidla) vyvěšeny na veřejně přístupném místě a každá osoba, která přijme jejich podmínky, je považována za stranu, která uzavřela veřejnou smlouvu o poskytování služeb a různých dalších možnostech transakcí.

Dokladem o tom, že klient souhlasí s podmínkami dodavatele, mohou být různé dokumenty. Může se jednat o pokladní doklady, platební příkazy s uvedením platby objednatelem za služby zhotovitele, jakož i další písemné dokumenty včetně technických specifikací.

V zadání musí být zároveň jasně vyznačeno umístění základních pravidel pro výrobu díla nebo v něm mohou být stanovena v plném rozsahu.

Legislativa umožňuje uzavírání technických specifikací na dálku. Tato možnost by měla být podrobně specifikována v pravidlech pro provádění prací (poskytování služeb). Korespondence může být vedena prostřednictvím různých komunikačních prostředků (e-mail, fax atd.).

V každém případě musí strany jasně chápat a být si vědomy důsledků uzavření obchodu a vzniku určitých práv a povinností pro ně. Za účelem potvrzení uzavření smlouvy (dohody) stranami je povoleno použití elektronických digitálních podpisů a faksimilií (pokud je to výslovně uvedeno v podmínkách transakce).

Jiné formy použití takového dokumentu

V běžném obchodním styku je technická specifikace nedílnou přílohou hlavní smlouvy a bez ní je neplatná. Na internetu jsou různé příklady technických specifikací.

Jejich rozmanitost často hraje krutý vtip, protože není jasné, kterou možnost si vybrat. Pokusíme se zvážit závazné podmínky, které musí být splněny při sestavování tohoto dokumentu nebo analýze vzorové technické specifikace, staženo z internetu:

Dokument je vyhotoven písemně a podepsán stranami nebo jejich oprávněnými zástupci. Pokud je stranou právnická osoba, musí dokument nést pečeť organizace. Je třeba věnovat pozornost řádným pověřením osoby podepisující zadání. Zastupitelé mají obvykle plné moci. Právnické osoby sepisují plné moci v jednoduché písemné formě, fyzické osoby - v notářské formě. Vzhledem k tomu, že plnou moc může osoba, která ji vystavila, kdykoli odvolat, měli byste si před podpisem dokumentu ověřit její platnost.

Zadání podrobně specifikuje technické požadavky na prováděné práce (služby). Pokyny zhotovitele jsou pro objednatele závazné, pokud neporušují podmínky hlavní smlouvy a jejich realizace nepovede k nepříznivým následkům.

V dokumentu je uvedeno datum jeho přípravy a termíny dokončení díla. Mohou být uvedeny fáze práce a také termíny pro přijetí výsledků. V případě potřeby jsou v dokumentu uvedeny osoby odpovědné za jeho provedení. Tento úkol může také obsahovat podrobnosti o stranách.

V případě potřeby lze k technickým specifikacím připojit různé dokumenty, originály i kopie. Dokumentace skutečného stavu je vyhotovena v počtu kopií, který se rovná počtu kopií technických specifikací. Každá strana transakce má právo na původní technickou specifikaci se všemi přílohami k ní.

Níže je uvedena jedna z technických specifikací. Další ukázky technických specifikací naleznete na našich webových stránkách v části „Vzorky dokumentů“. Přečtěte si právní dokumentaci k tomuto tématu v části „Otázky a odpovědi“ na webu. Řádná registrace nově vznikajících práv a povinností je klíčem k jejich implementaci všemi stranami zúčastněnými na transakci.

Zadání práce

Pamatujete na Murphyho zákony? Pokud můžete být nepochopeni, budete jistě nepochopeni. To platí nejen v komunikaci mezi lidmi, ale i při tvorbě webových stránek. Klient chtěl druhý Facebook, ale dostal fórum pro mladé chovatele psů. Vývojář neuhodl, co zákazník chce – ztrácel čas.

V této příručce vám řeknu, co a proč musíte napsat do podmínek zadání. Zároveň vám ukážu, jak nepsat, aby se tvorba technických specifikací neproměnila v ztracený čas.

Článek bude užitečný:

• Pro všechny, kteří se podílejí na tvorbě webových stránek: vývojáře, designéry, designéry rozložení.
• Projektoví manažeři.
• Vedoucí digitálních studií.
• Podnikatelé, kteří si plánují objednat vývoj webových stránek.

Aby byl materiál užitečný, shromáždil jsem komentáře od několika vývojářů, designérů, projektových manažerů a majitelů digitálních studií. Ty nejcennější jsem doplnil na konec článku. Pojďme to zjistit.

Co je to technická specifikace a proč je potřeba?

Technická specifikace je dokument, který stanoví požadavky na lokalitu. Čím jsou tyto požadavky jasnější a podrobnější, tím lépe všichni účastníci procesu chápou, jak by to mělo být. To znamená, že se zvyšuje šance, že všichni budou s výsledkem spokojeni.

Hlavním cílem technické specifikace je zajistit, aby si objednatel a zhotovitel správně rozuměli.

Technická specifikace má mnoho výhod. Pro každou stranu je to jiné.

Výhody pro klienta:

• Uvědomte si, za co platí peníze a jaký bude web. Můžete okamžitě vidět strukturu, pochopit, co bude fungovat a jak. Zjistěte, zda vám vše vyhovuje. Pokud ne, není problém to před zahájením vývoje změnit.
• Viz kompetence interpreta. Pokud jsou zadávací podmínky jasné a přesné, důvěra ve vývojáře se zvyšuje. Pokud je napsáno kaše, možná byste měli utéct a neohlížet se.
• Pojistit proti nepoctivosti interpreta. Když je stránka připravena, lze ji zkontrolovat podle technických specifikací. Existují nějaké nesrovnalosti? Developer je povinen je opravit. Pokud spolupracujete oficiálně a uzavřeli jste dohodu, můžete ji dokonce vynutit soudní cestou.
• Zjednodušte výměnu účinkujících. Pokud se klient a vývojář pohádali a utekli, může vytvoření webu zabrat spoustu času. Když bude podrobná technická specifikace, může se to přenést na nový tým – zapojí se do práce mnohonásobně rychleji.
• Zjistěte náklady na vývoj složitého produktu. Je nemožné okamžitě odhadnout přesné načasování a náklady na vývoj komplexní webové služby. Nejprve musíte pochopit, jak bude služba fungovat a jaké funkce bude mít. K tomu je třeba připravit technické specifikace.

Výhody pro interpreta:

• Pochopte, co zákazník chce. Klientovi jsou položeny desítky dotazů, ukázky příkladů a nabídnuta řešení. Poté se vše sepíše do jediného dokumentu a odsouhlasí. Pokud je vše v pořádku - hurá, pochopili jste správně.
• Pojistěte se proti náhlým přáním klienta. Občas narazíte na zákazníky, kteří chtějí v polovině úkol změnit. Pokud jste souhlasili a podepsali podmínky zadání, tak se toho nebojíte. Pokud se něco stane, i soud bude na vaší straně.
• Ukažte svou kompetenci. Dobře připravená technická specifikace ukáže klientovi odbornost vývojářů. Pokud společnost pochybuje, zda vám má svěřit vývoj webových stránek, pochybnosti budou s největší pravděpodobností rozptýleny.
• Vydělat peníze. Některá studia a vývojáři nabízejí přípravu technických specifikací jako samostatnou službu.

• Usnadnit a urychlit proces vývoje. Dobrá technická specifikace udává strukturu webu, potřebné funkce a prvky na každé stránce. Když už máte všechny požadavky před očima, zbývá už jen navrhnout a napsat kód.

Nyní pojďme zjistit, jak vytvořit dobrou technickou specifikaci, která plní všechny tyto funkce.

Mandát sestavuje výkonný umělec

Obecně platí, že každý může sestavit technické specifikace. „Potřebujeme webovou vizitku pro zubní kliniku“ – to je již technický úkol. Bude ale plnit své funkce? Stěží.

Dobrou technickou specifikaci vždy připraví vykonavatel: projektový manažer nebo vývojář. Je zřejmé, že webový vývojář rozumí tvorbě webových stránek více než majitel kavárny nebo zubní kliniky. Proto bude muset projekt popsat.

To neznamená, že klient zmizí a objeví se úplně na konci a napíše: „Zbs, schvaluji.“ Měl by se také zúčastnit procesu:

Zákazník si samozřejmě může načrtnout vlastní verzi technických specifikací. Snad to urychlí proces tvorby finálních technických specifikací. Nebo možná výsledkem budou odpadky, které budou tajně vyhozeny do koše.

Pište jasně a přesně

Tato rada vyplývá z hlavního cíle zadání – „Ujistit se, že si klient a zhotovitel správně rozumí.“

Zadávací podmínky by neměly obsahovat kvalitní přívlastky: krásný, spolehlivý, moderní. Nelze je jasně pochopit. Každý má své vlastní představy o kráse a modernosti.

Dívej se. Někdo si myslel, že tento design je krásný a dovolil, aby byl použit na svých webových stránkách:

Totéž se děje s vágními formulacemi, které samy o sobě nic neznamenají:

• Zákazníkovi se stránky musí líbit. Co když má špatnou náladu?
• Stránka by měla být pohodlná. Co to znamená? Pohodlné k čemu?
• Místo musí odolat velkému zatížení. 10 tisíc návštěvníků? Nebo 10 milionů?
• Vysoce kvalitní odborný obsah. No, rozumíte tomu.

Zkontrolujte, zda v textu nejsou nejasnosti. Pokud existuje, přepište jej. Vaše formulace by měla být jasná a přesná:

• Stránka se musí načítat rychle → Každá stránka na webu musí mít v Google PageSpeed ​​​​Insights více než 80 bodů.
• Velké zatížení → 50 tisíc návštěvníků současně.
• Na hlavní stránce se zobrazí seznam článků → Na hlavní stránce se zobrazí seznam posledních 6 publikovaných článků.
• Minimalistické uživatelsky přívětivé rozhraní předplatného → pole „Nechte svůj e-mail“ a tlačítko „Přihlásit se“ → *nakreslená skica*.

Vyřešili jsme formulaci, pojďme na strukturu.

Uveďte prosím obecné informace

Všichni členové týmu musí správně rozumět tomu, co společnost dělá a kdo je její cílová skupina. Aby se nikdo nepletl, je lepší to napsat hned na začátek zadání.

Vyplatí se také uvést účel webu a ve zkratce popsat jeho funkčnost – abyste místo blogu neskončili u internetového obchodu.

Vysvětlete obtížné pojmy

Prvním pravidlem zadání je, že musí být srozumitelné každému, komu je určen. Pokud budete používat termíny, kterým váš klient, majitel dětského hračkářství, nemusí rozumět, určitě je vysvětlete. Jasným jazykem, nikoli kopírováním a vkládáním z Wikipedie.

Popište nástroje a požadavky na hosting

Představte si, že jste strávili 2 měsíce tvorbou skvělého webu. Každá fáze byla koordinována s klientem - byl potěšen. A teď je čas odevzdat práci. Ukážete panel administrátora a klient zakřičí: „Co je to? Modex?! Myslel jsem, že to uděláš na WordPressu!“

Chcete-li se těmto problémům vyhnout, popište použité nástroje, motory a knihovny. Zároveň uveďte své požadavky na hosting. Nikdy nevíte, uděláte to v PHP - a klient má server v .NET.

Vyjmenujte požadavky na provoz stránek

Stránka musí fungovat ve všech současných prohlížečích a na všech typech zařízení. Ano, to je zřejmé každému vývojáři a každému zákazníkovi. Ale je lepší napsat, abyste ochránili klienta před prací vykonanou ve zlé víře.

Napište sem požadavky na rychlost načítání stránek, odolnost proti zatížení, ochranu před útoky hackerů a podobné věci.

Určete strukturu webu

Než začnete kreslit návrh a rozložení, musíte se s klientem dohodnout na struktuře webu.

Promluvte si se zákazníkem a zjistěte, co potřebuje. Shromážděte vývojáře, SEO specialisty, marketéry, šéfredaktora – a rozhodněte, jaké stránky jsou na webu potřeba. Přemýšlejte o tom, jak budou vzájemně propojeny, ze kterého můžete přejít.

Strukturu můžete zobrazit seznamem, můžete nakreslit blokové schéma. Jak si přejete.

Toto je jedna z nejdůležitějších fází práce na webu. Struktura je základ. Pokud se to nepodaří, web bude křivý.

Vysvětlete, co bude na každé stránce

Klient musí pochopit, proč je každá stránka potřebná a jaké prvky na ní budou. Existují dva způsoby, jak to ukázat.

Prototyp- názornějším a jednoznačným způsobem. Zhotovitel nakreslí náčrtky každé stránky a připojí je k zadání. Klient vidí, jak bude vypadat rozhraní jeho budoucího webu a říká, co se mu líbí a co je potřeba změnit.

Výčet prvků- líná alternativa k prototypu. Stačí napsat, jaké bloky by na stránce měly být a co dělají.

Popište scénáře používání webu

Pokud vytváříte nějaké nestandardní rozhraní, nestačí pouze ukázat strukturu a miniatury stránek. Je důležité, aby celý realizační tým a klient pochopili, jak budou návštěvníci stránky používat. Skripty jsou na to skvělé. Schéma scénáře je velmi jednoduché:

• Akce uživatele.
• Odezva webu.
• Výsledek.

Samozřejmě, pokud vytváříte standardní vizitku nebo vstupní stránku, nemusíte psát skripty. Ale pokud jsou na webu nějaké interaktivní služby, je to velmi žádoucí.

Přečtěte si více o případech použití na Wikipedii.

Určete, kdo je za obsah zodpovědný

Někteří vývojáři vytvoří web s obsahem hned. Jiní umisťují ryby. Ještě jiní mohou psát texty, ale za příplatek. Domluvte se na tom na břehu a napište si do zadání, jaký obsah byste si měli připravit.

Vymyslet objektivní kritéria pro hodnocení kvality textů je poměrně obtížné. Je lepší nepsat nic jiného než „Vysoce kvalitní, zajímavý a prodejní obsah, který je užitečný pro cílové publikum“. Je to odpad, nikdo to nepotřebuje.

Je užitečné určit, že veškerý obsah musí být jedinečný. Další ochrana klienta před bezohlednými umělci.

Popište design (pokud můžete)

Stejně jako u textu je obtížné přijít s objektivními kritérii pro hodnocení designu. Pokud jste se s klientem dohodli na barevném provedení, napište ho. Pokud má značku, ve které jsou fonty specifikovány, uveďte je také.

O krásném a moderním designu není třeba psát. Nic to neznamená, nemá moc a obecně fuj.

Místo závěru: struktura zadání

Struktura technických specifikací se bude pro různé úkoly lišit. Je hloupé vytvářet stejné technické specifikace pro novou sociální síť a vstupní stránku pro velkoobchodní prodej mrkve. Ale obecně potřebujete tyto sekce:

• Informace o společnosti a cílové skupině, cílech a záměrech webu.
• Slovníček pojmů, které nemusí být klientovi jasné.
• Technické požadavky na uspořádání a provoz staveniště.
• Popis použitých technologií a seznam požadavků na hosting.
• Detailní struktura webu.
• Prototypy stránek nebo popisy prvků, které by na nich měly být.
• Scénáře pro použití nestandardního rozhraní (volitelné).
• Seznam obsahu, který vytváří vývojář.
• Požadavky na design (volitelné).

• Pravidla pro sestavování specifikace požadavků na software. SRS je dalším krokem ve vývoji technických specifikací. Potřebné pro velké a složité projekty.
• Standardy a šablony technických specifikací pro vývoj softwaru. Popisy různých GOST a metodik pro vytváření technických specifikací.

Toto je konec části, kterou jsem napsal. Ale je tu ještě jeden - připomínky specialistů, kteří pomohli vytvořit průvodce. Přečtěte si to, je to také zajímavé.

Komentáře vývojářů

Mluvil jsem s několika vývojáři, abych zjistil, jak vytvářejí technické specifikace. Předám jim mikrofon.

Klient potřebuje v první řadě technické specifikace – aby rozuměl tomu, jaký bude jeho web a za co budou utráceny peníze. Pokud se něco udělá špatně, může se obrátit na technické specifikace a požádat o přepracování.

Technickou specifikaci vypracuje projektový manažer po komunikaci s klientem a projednání úkolu s projektantem.

Velcí zákazníci často žádají velmi podrobné technické specifikace, které popisují každé tlačítko. Malé firmy naopak nemají rády pečlivé 100stránkové dokumenty. Je to dlouhé čtení a snadno se stane, že vám něco důležitého unikne. Častěji zpracováváme stručné technické specifikace v rozsahu 10–15 stran.

Uvádíme:

• Informace o společnosti a účelu stránek.
• Požadavky na design, barevné provedení.
• Použité technologie a CMS.
• Kdo vytváří obsah – my nebo klient.
• Struktura webu až na každou stránku.
• Popis každé stránky. Neděláme prototypy, ale specifikujeme, jaké prvky mají na stránce být a jak mají fungovat.

Poslední 2 části jsou nejdůležitější. Jsou to oni, kdo poskytuje pochopení toho, jak bude web vypadat a jak bude fungovat.

Velmi důležitý bod - nemůžete jen zadat podmínky vývojářům a doufat, že vše udělají dobře. Technická specifikace je seznam požadavků na web, nemůže nahradit komunikaci. Je důležité se ujistit, že každý člen týmu rozumí celkovému cíli a nedělá úkoly jen za běhu. Pokud je něco nejasné, je potřeba to vysvětlit, prodiskutovat a podrobně komentovat.