Otázka „Je vôbec potrebné vypracovať technickú špecifikáciu (TOR)? môže vzniknúť len tomu, kto si vývoj webovej stránky v živote neobjednal, keďže jeho potreba vzniká už po prvej komunikácii medzi objednávateľom a zhotoviteľom.

Technická špecifikácia je dokument, ktorý podrobne a úplne popisuje budúci projekt. Čím je detailnejší, tým presnejšie sa nápad zrealizuje a pri realizácii projektu vznikne menej konfliktov a kontroverzných situácií, pretože úplne čokoľvek sa dá robiť rôznymi spôsobmi. Môže sa naň odkazovať, ak niečo nie je dokončené alebo vykonané nesprávne alebo sa vyskytli iné chyby. Pred začatím prác objednávateľ spravidla abstraktne popíše budúci projekt alebo vyplní brief a zhotoviteľ všetky tieto požiadavky a priania formalizuje a prípadne navrhne úpravy. Zákazník sa zároveň musí uistiť, že všetky jeho „priania“ sú zaznamenané v špecifikáciách.

Ak sa s webovým štúdiom alebo freelancerom uzatvorí dohoda o vývoji webovej stránky, technická úloha zvyčajne prichádza ako jej príloha. A v kontroverzných situáciách sa riadia tým, čo je tam napísané.

Z čoho pozostáva technická špecifikácia?

Predpokladajme, že v rámci projektu potrebujete vypracovať technické špecifikácie pre vývoj webovej stránky pre copywritingové štúdio Pero. Aké body by mala obsahovať?

Všeobecné informácie (popis)

Tu sú nasledujúce:

Informácie o spoločnosti. Všeobecné informácie o štúdiu, čo robí. Bolo by dobré uviesť zoznam poskytovaných služieb. Tu môžete pridať adresu budúcej webovej stránky a kontaktné informácie.

Etapy a načasovanie projektu. Veľmi dôležitý bod: spravidla sa na samom konci zostavuje harmonogram pre všetky fázy práce. Táto časť poskytuje pochopenie toho, čo sa bude robiť a kedy. Napríklad (s dátumami):

• Prípravná fáza;
• Vývoj koncepcie webovej stránky;
• Dizajn;
• Vytvorenie návrhu dizajnu;
• Vývoj dizajnu stránok;
• Rozloženie;
• Programovanie;
• Obsah náplne;
• SEO optimalizácia;
• Testovanie;
• Spustiť.

Niektoré fázy, napríklad propagácia SEO, nemusia existovať. Závisí od cieľov a zámerov objednávateľa a kompetencií zhotoviteľa.

Účel a ciele

Tu je formulované, aké funkcie bude stránka plniť a pre koho je určená.

Účel stránky. Aké ciele by sa mali dosiahnuť vytvorením webovej stránky? Prečo je to potrebné, aké problémy rieši?

• Reklama a prilákanie nových klientov;
• Zákaznícka a partnerská podpora;
• Ukážka dokončenej práce;
• Oboznámenie sa so zoznamom služieb;
• Vytváranie a udržiavanie imidžu spoločnosti.

Možno by bolo potrebné podrobnejšie opísať niektoré body. Ak je napríklad úlohou stránky informovať návštevníkov, potom je lepšie vysvetliť, o čo presne ide.

cieľové publikum. Kto bude stránku používať, pre koho je vytvorená?

• Webmasteri, blogeri;
• Majitelia internetových obchodov;
• Vlastníci informačných portálov;
• Reklamné štúdiá;
• Zástupcovia firiem a spoločností pôsobiacich v online priestore.

Požiadavky

Veľká a mimoriadne dôležitá sekcia, ktorá zohľadňuje čo najviac dizajnových a vývojových aspektov, pretože za funkčnosť neuvedenú v technických špecifikáciách si zákazník bude musieť priplatiť.

Typ. Do akej kategórie patrí webový zdroj?

• Vstupná stránka;
• Webová stránka vizitiek;
• Firemná webová stránka;
• Informačný portál;
• Internetový obchod.

Požiadavky na registráciu. Môžu byť nasledujúceho typu:

• Webová stránka by mala byť minimalistická a zároveň odrážať typ činnosti spoločnosti.
• Primárne farby: zelená a biela, podľa knihy značiek alebo podľa uváženia dizajnéra.
• V dizajne nemôžete použiť animáciu, kontextové okná, prvky Flash ani dizajnové excesy.
• Nemožno použiť pätkové písma (možno použiť štandardné: Verdana, Arial, Tahoma atď.). Veľkosť písma by mala zabezpečiť maximálnu čitateľnosť (12-16 bodov).

Pokiaľ ide o požiadavky na dizajn, možno použiť rôzne prístupy. Ak zákazník sám presne vie, čo chce dostať, potom svoje želania podrobne opíše, uvedie príklady stránok, ktoré sa mu páčia a uvedie ďalšie špecifiká. Niekedy sa ale stane, že ani on sám presne nevie, ako to má všetko vyzerať, v tomto prípade väčšinou vychádzajú z úloh, ktoré by mal návrh riešiť. Dodávateľ vypracuje koncepty, ponúkne riešenia, obháji svoj nápad a upraví ho na základe pripomienok zákazníka. Druhá možnosť je drahšia a vyžaduje si od dodávateľa väčšiu kvalifikáciu.

Jazykové požiadavky. Osoby hovoriace jazykom budú mať prístup k zdroju? Aké jazykové verzie stránky by mali byť?

• ruský;
• Angličtina;
• Esperanto.

Požiadavky na kompatibilitu. Z akých zariadení a akých prehliadačov sa stránka otvorí správne? V poslednej dobe je trend k adaptívnemu rozloženiu, kedy sa stránka správne zobrazí na akomkoľvek zariadení s ľubovoľným pomerom strán a rozlíšením obrazovky. Tu môžete uviesť zoznam prehliadačov, s ktorými by mal byť zdroj určite kompatibilný. Stránky sa zvyčajne zobrazujú rovnako vo všetkých moderných prehliadačoch, problémy sú len so staršími verziami Internet Explorera.

Požiadavky na CMS. Možnosti správy lokality určujú, ktoré bloky je možné upravovať a konfigurovať prostredníctvom ovládacieho panela bez zásahu do kódu alebo priamej úpravy databázy, ale s použitím pohodlného vizuálneho rozhrania. Môže byť formulovaný napríklad takto:

• Schopnosť meniť obsah stránok;
• Schopnosť spravovať stránky (pridávanie, premenovanie, mazanie atď.);
• Schopnosť upravovať štruktúru stránky a položky ponuky;
• Funkcie automatického spracovania grafiky (vytváranie náhľadov, transformácia na danú veľkosť atď.);
• Schopnosť písať jedinečné meta tagy;

Rovnako ako v iných podsekciách musíte opísať všetky požiadavky a želania.

Často už má zákazník skúsenosti s prácou s niektorým z populárnych CMS, vtedy je vhodné hľadať dodávateľov pre konkrétny motor. Taktiež pri výbere CMS je lepšie neuspokojiť sa s vlastnými riešeniami, pretože v budúcnosti to bude závisieť od interpreta. Vlastnoručne napísané motory majú podľa mňa opodstatnenie len vo veľmi veľkých projektoch, kde je potrebná špecifická funkcionalita alebo optimalizácia veľkých záťaží.

Štruktúra a navigácia. Aké sekcie, podsekcie a jednotlivé stránky bude projekt obsahovať?

• Domovská stránka
• Služby

• Copywriting
• Prepisovanie
• SEO copywriting
• Korektúry
• Prepis
• Obsahový management
• Obsahový marketing

• Portfólio
• O nás
• Kontakty

Uveďte stručný popis každej stránky a uveďte definície. Čo napríklad znamená stránka „Kontakt“? Má obsahovať adresu, telefón a email v textovej podobe? Alebo by tam mal byť formulár spätnej väzby? Alebo možno potrebujete vložiť kód máp Yandex? Alebo by sa všetko vyššie uvedené malo umiestniť na stránku kontaktov plus odkazy na zástupcov na sociálnych sieťach?

Obsah je vhodné pripraviť alebo aspoň načrtnúť ešte pred začatím prác so zhotoviteľom. To podporí efektívnejšiu komunikáciu.

Ďalšie požiadavky. Všetko, čo nie je zahrnuté v iných častiach sekcie.

Popis sekcií webovej stránky

V tomto bode sú detaily. Zvyčajne je popísaný obsah všetkých jedinečných stránok: aké prvky tam budú, ako s nimi bude používateľ interagovať.

Domovská stránka. Formulácia problému môže byť nasledovná.

Hlavná časť hlavnej stránky by mala byť vytvorená vo forme vstupnej stránky. Zhora nadol by na ňom mali byť umiestnené nasledujúce prvky:

• Hlavička - logo, názov spoločnosti;
• navigačné menu;
• Informácie o akciách a zľavách;
• tlačidlo objednať;
• Reklamné texty;
• Blok s piatimi najlepšími prácami a odkazom na sekciu portfólia;

Zadávacie podmienky sú dôležité pre zhotoviteľa aj objednávateľa. Zhotoviteľovi pomáha lepšie pochopiť, čo zákazník chce, poistiť sa proti náhlym „želaniam“ zo strany objednávateľa a urýchliť prácu na dokončení zákazky. Klientovi je možné presne povedať, čo chce, zjednodušiť kontrolu kvality a získať presné náklady na službu. O tom, ako správne zostaviť technické špecifikácie a čo s tým robiť, si povieme neskôr.

Čo je to technická špecifikácia

Technické špecifikácie sú dokument, ktorý odráža všetky požiadavky na budúci produkt. Popisuje všetky technické požiadavky. Technické špecifikácie sa zvyčajne zostavujú vo forme textového dokumentu, zriedkavo v iných formátoch.

TK používajú všetci vývojári webových stránok. Pomáha návrhárom rozloženia, programátorom a dizajnérom lepšie pochopiť požiadavky klienta a vytvoriť zdroj, ktorý spĺňa ich očakávania. Okrem toho sa technické špecifikácie používajú vo všetkých ostatných oblastiach, napríklad v:

• vývoj aplikácií;
• dizajn domu;
• písanie textov a iné.

Ak pracujete podľa technických špecifikácií, riziko sporov a zdĺhavých súdnych sporov je minimalizované.

Ako zostaviť technické špecifikácie: štruktúra technických špecifikácií pre webovú stránku

Predtým ako začneš:

• Rozhodnite sa, kto vypracuje technické špecifikácie
• Vysvetlite pojmy
• Vyhnite sa subjektívnym výrazom

Na prvý pohľad sa zdá, že technické požiadavky na stránku by mal vypracovať klient, pretože objednáva zdroj a kladie naň požiadavky. V skutočnosti by sa na procese mali zúčastniť obaja: klient vysloví požiadavky a interpret ich zapíše konkrétne, presne a jasne. Klient napríklad povie, že chce webovú stránku prispôsobenú všetkým používateľom a vývojár špecifikuje požiadavky na prispôsobivosť pre 4 dostupné veľkosti – PC, notebooky, tablety, smartfóny.

Objasnenie pojmov je veľmi dôležitý bod. Hneď na začiatku je vhodné vysvetliť všetky vysoko odborné pojmy – klienti nie vždy vedia, čo je to footer, CMS, alebo fish. Čím jednoduchšie a jasnejšie sú vysvetlenia, tým jasnejšie budú technické špecifikácie pre obe strany.

Subjektívne pojmy môžu spôsobiť zbytočné polemiky. Nepíšte „dizajn by mal byť krásny“ – každý vníma krásu inak. To isté platí pre kvalitatívne prídavné mená „pohodlný“, „ľahko použiteľný“, „veľký“. Použite konkrétne čísla a parametre: popíšte napríklad farebnú schému alebo usporiadanie prvkov.

Štruktúra technických špecifikácií môže byť ľubovoľná. Ako príklad ponúkame jednoduchú štruktúru zadávacích podmienok webovej stránky.

Popíšte stránku

Povedzte nám, aký typ stránky je potrebný, kto ju bude používať a prečo sa vytvára. Napíšte napríklad, že potrebujete internetový obchod, vstupnú stránku na predaj produktu alebo webovú stránku s vizitkami s 10 stranami. Ak neviete presný počet, uveďte približný počet strán.

Ak má projekt špecifickú cieľovú skupinu, opíšte ju. Pomôže vám to vytvoriť zdroj, ktorý osloví zákazníkov – napríklad použitím vhodného jazyka v článkoch alebo dizajnu, ktorý osloví mladých ľudí alebo staršie generácie.

Povedzte nám o štruktúre

Bez predstavy o štruktúre nie je možné vytvoriť normálnu webovú stránku. Popíšte, aké stránky budú na webe a ukážte úrovne ich vnorenia. Dá sa to urobiť rôznymi spôsobmi:

• Schéma
• Tabuľka
• Zoznam

Hlavná vec je, že na konci je jasné, ktoré stránky sa budú nachádzať v menu, kam povedú a ktorá nadradená stránka je pre každú sekciu. Odporúčame používať vývojové diagramy – sú jednoduchšie a zrozumiteľnejšie ako zoznamy a tabuľky a pomôžu vám zhodnotiť celú štruktúru webu za pár sekúnd.

Príklad jednoduchej štruktúry vo forme blokovej schémy

Popíšte, čo bude na každej strane

Povedzte nám, ako vidíte stránky webu. Odporúča sa to urobiť vo formáte prototypu, aby sa jasne preukázalo umiestnenie každého prvku. Požiadavky môžete opísať zoznamom, napríklad povedať, čo bude v hlavičke stránky, kde sa nachádza formulár spätnej väzby, čo bude v stĺpci na voľnej strane.

Ak sú všetky stránky webu približne podobné – napríklad plánujete vytvoriť web vizitky, vystačíte si s dvoma prototypmi: pre hlavnú stránku a ďalšie sekcie. Ak existuje niekoľko skupín podobných stránok - napríklad sekcie v katalógu internetového obchodu, blog s článkami a popisom doručovacích/montážnych/inštalačných služieb, je lepšie vytvoriť vlastný prototyp pre každú skupinu.

Príklad prototypu domovskej stránky webu: všetko je jednoduché, pohodlné, zrozumiteľné

Stanovte požiadavky na dizajn

Ak máte vypracované rozloženie, skvelé - jednoducho ho vložíte do technických špecifikácií. Ak nie, musíte opísať požiadavky na farebnú schému, použité obrázky a logá. Napríklad:

• Uveďte, ktoré firemné farby je možné použiť v dizajne a ktoré odtiene absolútne nie
• Poskytnite logo, ktoré sa musí nachádzať v hlavičke stránky
• Zadajte písma, ktoré chcete použiť pre stránky, ponuky, päty a obsah

Ak nie sú jasné požiadavky – to znamená, že klient sám nevie sformulovať svoju predstavu o lokalite, môžete mu ponúknuť niekoľko štandardných dispozičných riešení, z ktorých si môže vybrať alebo zostaviť dispozičné riešenie individuálne a následne sa na ňom dohodnúť. Toto sa musí urobiť pred schválením technických špecifikácií, inak môže rozdiel v chuti výrazne oneskoriť projekt.

Popíšte požiadavky na nástroje, kód, hosting, doménu

To je potrebné vopred vedieť, s ktorými nástrojmi môžete pracovať a s ktorými nie. Opíšte v samostatnom bloku:

• Na ktorej stránke by mala byť stránka - WordPress, Joomla, Modex atď.
• Aký programovací jazyk možno použiť - PHP, JavaScript, HTML, iné
• Na akom hostingu a v akej doménovej zóne má byť stránka umiestnená, aké doménové meno je možné použiť
• Akú softvérovú platformu možno použiť - .NET, OpenGL, DirectX
• A tak ďalej

Ak klient nerozumie ničomu o použitých výrazoch, vysvetlite rozdiel medzi WordPress a Modex, PHP z HTML, doména v zone.ru od domény v zone.com. Spoločne zostavte požiadavky tak, aby vyhovovali klientovi.

Zadajte požiadavky na prevádzku lokality

V predvolenom nastavení by stránka mala fungovať pre používateľov všetkých zariadení, v rôznych prehliadačoch, odolať útokom hackerov a nespadnúť, keď ju navštívi 1000 používateľov súčasne. Ale je lepšie to napísať ako samostatný blok. Uveďte prosím:

• Rýchlosť načítania webovej stránky, ktorá je pre vás prijateľná alebo štandardná hodnota je 1–5 sekúnd
• Kompatibilita medzi prehliadačmi – zadajte, v ktorých prehliadačoch sa má stránka otvárať
• Odozva – špecifikujte veľkosti obrazoviek, ktorým sa má dizajn prispôsobiť, a použité zariadenia
• Odolnosť voči zaťaženiu - koľko ľudí by malo byť na stránke súčasne, aby „neklesla“
• Odolnosť voči hackerským a dDos útokom: stránka musí odolať malým útokom

Zapíšte si scenáre prevádzky lokality

Popíšte, ako by mal používateľ interagovať s webom a aké akcie na zdroji by sa mali uskutočniť ako reakcia. To možno vykonať vo forme jednoduchého očíslovaného zoznamu alebo rozvetveného algoritmu, ak majú používatelia na výber medzi akciami. Ak existuje veľa interaktívnych služieb, napíšte scenár pre každú z nich.

Príklad najjednoduchšieho scenára pre webovú stránku

Zistite, kto tvorí obsah.

Niektorí vývojári píšu texty sami, niektorí si ich objednávajú od copywriterov, iní používajú ryby. Okamžite prosím objasnite, či je poskytovanie obsahu zahrnuté do vývojovej služby. Ak áno, môžete okamžite zadať ďalšie požiadavky, napríklad pre:

• - nie menej ako 95 % podľa Advego, Text.ru, Content.Watch
• Nevoľnosť (spamovanie) - nie viac ako 10 % podľa Advego alebo 65 % podľa Text.ru
• Body podľa Glavreda - minimálne 6,5 alebo 7 bodov

Samozrejme, rôzne služby nie sú všeliekom, ale minimalizujú riziko, že budú „vodnaté“ alebo prespamované. Okrem toho sa takto objavujú presné kritériá hodnotenia kvality textov.

Uveďte termíny

Na to sa často zabúda. Väčšina technických zadaní musí špecifikovať termíny, inak sa vývoj môže natiahnuť o niekoľko mesiacov, šesť mesiacov alebo rokov. Nepoužívajte nesprávne formulácie – napríklad „o mesiac“. Napíšte presný dátum: 1.12.2018 napr.

Lifehack: je lepšie vypracovať zadávacie podmienky ako prílohu k dohode o spolupráci. Týmto spôsobom stanovíte všetky požiadavky na vývoj webových stránok a v prípade sporov budete môcť spor vyhrať na súde.

Pamätajte: každá technická špecifikácia musí obsahovať niekoľko hlavných blokov:

• Ciele a zámery – o tom, prečo ste vo všeobecnosti vytvorili technické špecifikácie, čo chcete s produktom robiť
• Aký by mal byť produkt - všeobecný popis
• Technické požiadavky - plocha domu, objem textu, funkčnosť aplikácie atď.
• Termíny – sú dôležité, aby sa predišlo sporom.

Príklad vypracovania technických špecifikácií pre softvér

Potrebujeme vytvoriť softvér. Technické požiadavky sú uvedené nižšie.

Popis: program na vyhľadávanie článkov podľa kľúčového slova na všetkých dôveryhodných stránkach; adresy dôveryhodných stránok je potrebné zadať ručne.

Čo by mal softvér robiť:po zadaní kľúčového slova nájde články na stránkach, ktoré boli vopred zadané ako smerodajné zdroje, zobrazí zoznam zhôd v tomto formáte:

• Odkaz
• Názov článku
• Hlavný odsek

Ak existuje viac ako 10 zápasov, musíte to rozdeliť na strany - 10 na každej.

Technické požiadavky:programovací jazyk - akýkoľvek, na tom nezáleží. Hlavná vec je, že program môže byť následne upravený a uvoľnený ako online služba. V ideálnom prípade by služba mala vyhľadať za 10 sekúnd.

Termíny: do 15. septembra 2018.

Túto technickú špecifikáciu je samozrejme možné vylepšiť – uviedli sme ju ako príklad. Čo si myslíte, ako sa dajú zlepšiť podmienky, aby boli ešte jasnejšie, jednoduchšie a pohodlnejšie?

Čo si myslíte o tom, keď v meste alebo na webových stránkach (v reklamných blokoch) vidíte bannery s nadpismi: „Stránka za 500 UAH“, „Stránka za 1000 RUR“?

Ako vývojár som si dlho myslel - je to podvod! Počet takýchto reklám však naznačuje:

• Je to vôbec možné?
• Akú kvalitu bude mať stránka v tomto prípade?
• Bude možné ho neskôr spropagovať?
• Zaujme dôstojnú pozíciu?
• Bude to pohodlné a bude sa to dať upravovať?

Samozrejme, niekedy je prijateľná jednoduchá sada súborov HTML: ak je málo stránok, zriedka sa menia kvôli téme a vlastník stránky (alebo správca obsahu) pozná HTML. A ak nie? Čo ak napríklad potenciálny vlastník nevie nič o HTML a po prijatí stránky neurobí žiadne zmeny? Zvyčajne len málo ľudí urobí hneď nejaké zmeny, pretože všetko je relevantné. Ale po určitom čase, keď potrebujete pridať meta tagy a aktualizovať niektoré informácie, sa ukáže, že stránka je statická a neexistuje žiadny editor, pomocou ktorého by ste mohli meniť jej obsah.

Navyše len majiteľ stránky vie, čo predáva a na čo by sa mal klásť dôraz. Dizajnér môže nakresliť čokoľvek, programátori a dizajnéri rozloženia rozložia a vytvoria funkcie, ktoré chcete. Ako sa môžete uistiť, že ste čo najsprávnejšie pochopení a že sa vaše plány a nápady realizujú?

V našom blogu sme o tom už písali, s popisom jeho štruktúry a (zákazník, dizajnér, programátor, návrhár layoutu atď.). Tentokrát si popíšeme (s príkladmi), čo musí zákazník sprostredkovať dizajnérovi a programátorovi layoutu, aby sa očakávania zhodovali s realitou.

Navrhujem, aby ste zvážili príklad dobrej technickej špecifikácie. Kompilácia technických špecifikácií pre programátora trvala viac ako jeden deň, ale celý tento čas strávený kompilátorom je opodstatnený.

Takže vzorová technická špecifikácia pre vývoj malej webovej stránky s recenziami.

Referenčné podmienky pre vývoj webových stránok

Práca na vytváraní alebo redizajne webovej stránky spravidla začína u dizajnéra, pretože výstupom, ktorý dostanete, je obrázok. Je však ťažké nájsť človeka, ktorý bude rozumieť tomu, čo chcete a dokáže vám tento obrázok zdigitalizovať v hlave. Preto treba všetko demonštrovať.

Nehanbite sa a nehanbite sa uviesť príklady stránok, na ktorých sa vám páči tá či oná funkcia alebo dizajnové prvky, rozloženie, efekty. Ale! Neposkytujte len odkazy, ale pripojte snímky obrazovky. Môžete vypracovať technickú špecifikáciu a vlastník lokality (ktorú uvediete ako príklad) zmení usporiadanie, kým technická špecifikácia dostane dodávateľ. Potom budete musieť znova hľadať príklad a vysvetliť, čo ste tým mysleli.

Snímky obrazovky si uložte do počítača alebo do cloudovej služby, aby sa po mesiaci neodstránili (ako je to napríklad možné pri použití bezplatnej verzie služby Joxi). Všetko by malo byť uložené ešte aspoň mesiac po tom, ako sa stránka objaví s aktualizovaným rozložením/funkciou.

Neodporúčam dokončovať prácu s dizajnérom vo fáze tvorby layoutu webu. Počas procesu je tiež dôležité diskutovať, kresliť a popisovať správanie prvkov dizajnu. To pomôže dizajnérovi a vývojárovi rozloženia pochopiť vás rovnakým spôsobom, ako vám rozumel dizajnér. Je jasné, že takýto dialóg je často vyčerpávajúci, no nemali by ste prestať na polceste.

Verzia pre stolné počítače

všeobecné informácie

Šírka webu – 1140 px (príklad – vizaua.com).
Hlavička a päta sa tiahnu po celej šírke obrazovky a sú rovnaké pre všetky strany.
Rodina písiem: Cambria (preferované), Century, Georgia. Môžete určiť ďalšie populárne pätkové písma.
Veľkosti písma (pre Cambria):
Text pod logom v hlavičke – 15px
Odkazy v hlavičke – 14px
Text päty – 16 pixelov

Domovská stránka – home.png

Text nad vyhľadávacím panelom – 25 pixelov

Text pod vyhľadávacím panelom – 14px

Popis prvkov:

1, 2 – čísla so skutočným počtom obchodov a recenzií. Dá sa prepočítať raz za 24 hodín.
3 – kategórie. Usporiadame ich ručne v rovnakom poradí ako na rozložení.
4 – odkazy na obchody. Vedľa názvu obchodu zobrazujeme počet recenzií. Ak ešte nie sú žiadne recenzie, nič nezobrazujeme.
Pod každou kategóriou zobrazujeme 6 najobľúbenejších obchodov podľa počtu recenzií. Ak je v kategórii viac predajní, vedie na ňu odkaz “Viac N”, kde N je počet predajní. Ak neexistujú žiadne ďalšie obchody, odkaz „Zobraziť všetko“ vedie do kategórie.
5 – zoznam málo populárnych kategórií. Tu ich zobrazujeme.

Stránka s popisom obchodu a recenziami – shop-page.png

Nadpis H1 – 30px
Nadpis H2 – 22px

Popis prvkov:
1, 2, 3 – priestor pre reklamné bloky. Toto miesto musíte počas rozloženia označiť a zavrieť na indexovanie.
4 – obsah stránky. Dizajn sa mení tak, že všetky zmeny je možné vykonať globálne, bez úpravy každej stránky jednotlivo:
– pridané sivé pozadie do bloku obsahu;
– pridaný biely okraj k tabuľkám (v predvolenom nastavení to, zdá sa, nebolo nikde napísané);
— pridaný priestor pre reklamný blok nad recenziami.
5 – názov formulára. Musíte zaškrtnúť „Pridať recenziu“.
6 – najnovšie recenzie (celkový blok pre príspevky a kategórie). Toto je približné zobrazenie, prijateľný je hotový plugin s podobnou vizualizáciou.

Popis prvkov:
1,2 – priestor pre reklamné bloky.
3 – obsahová časť. Musíte odstrániť všetky popisy kategórií (uložte texty do samostatného súboru .doc a nahrajte tento súbor na server).
4 – odkaz na recenzie. Vo všetkých šablónach TOR meníme slovo „komentáre“ na „recenzie“.

Servisná stránka – page.png

chyba 404 – 404.png

404 – font 80px
Text pod ním má veľkosť 20 pixelov
Kurzíva – 15 pixelov

Vaša stránka nemá dobré hodnotenie v Yandex alebo Google,
a všetky snahy o jej propagáciu neprinášajú želaný efekt?

Odošlite žiadosť o bezplatnú SEO diagnostiku a zistite
čo je na vašom webe zlé.

Mobilné rozloženie

Teraz je lepšie urobiť z mobilného rozloženia hlavné a „tancovať“ z neho. Nie nadarmo je všetka pomoc a blog Google plné „Mobile first“ (mobil first alebo mobility). Hovoríme vám o tom od roku 2014 (články „“ a „“).

Preto sa v prvom rade zamyslite a popíšte, ako by mala vaša stránka vyzerať a fungovať na mobilných zariadeniach. Venujte zvláštnu pozornosť:

• Kontakty. Telefónne čísla by mali byť klikateľné – po kliknutí by sa mal otvoriť panel na zadávanie čísla s už vytočeným číslom a tlačidlom volania.
• Ponuka. Popíšte, ako sa má otvárať: vychádzať zboku, zhora atď.
• Na stránkach webu by nemalo byť žiadne horizontálne rolovanie (to je samozrejmé, ale aj tak som sa rozhodol vám to pripomenúť).

Nižšie sú uvedené rozloženia stránok na zobrazenie stránky na mobilných zariadeniach (adaptívne rozloženie).

Primárne požiadavky:
– ponuka burgerov – rozbalí sa nadol, keď sa dotknete ikony ponuky:

– znížte bočný panel pod hlavným obsahom:

Referenčné podmienky pre vývoj programu «______________» k dohode č.___ 1. Úvod 1.1. Názov programu 1.2. Účel a rozsah 2. Požiadavky na program 2.1. Funkčné požiadavky 2.2. Požiadavky na spoľahlivosť 2.2.1. Požiadavky na zabezpečenie spoľahlivej prevádzky programu 2.2.2. Doba zotavenia po zlyhaní 2.2.3. Poruchy spôsobené nesprávnymi činnosťami používateľov systému 3. Prevádzkové podmienky 3.1. Klimatické prevádzkové podmienky 3.2. Požiadavky na kvalifikáciu a počet personálu 3.3. Požiadavky na skladbu a parametre technických prostriedkov 3.4. Požiadavky na informácie a kompatibilitu softvéru 3.4.1. Požiadavky na informačné štruktúry a metódy riešenia 3.4.2. Požiadavky na zdrojové kódy a programovacie jazyky 3.4.3. Požiadavky na softvér používaný programom 3.4.4. Požiadavky na ochranu informácií a programov 3.5. Špeciálne požiadavky 4. Požiadavky na dokumentáciu programu 4.1. Predbežné zloženie programovej dokumentácie 5. Technické a ekonomické ukazovatele 5.1. Ekonomické prínosy rozvoja 6. Etapy a štádiá vývoja 6.1. Vývojové štádiá 6.2. Vývojové štádiá 6.3. Obsah práce po etapách 7. Postup kontroly a prijatia 7.1. Typy testov 7.2. Všeobecné požiadavky na prijatie práce 1. Úvod 1.1. Názov programu Názov programu: „ASU „______________“ 1.2. Účel a rozsah Program je určený na automatizáciu spracovania údajov klientov kaviarní/barov. Pracuje s nasledujúcimi údajmi: prípadné osobné údaje o klientovi; údaje o službách zákazníkom; informácie o systéme zliav; 2.1. Funkčné požiadavky Program musí poskytovať schopnosť vykonávať nasledujúce funkcie: možnosť zobraziť údaje klienta na požiadanie; schopnosť vypočítať zľavy; pridávanie/odstraňovanie klientov; zmena klientskych údajov; možnosť zmeny systému zliav; 2.2.1 Požiadavky na zabezpečenie spoľahlivej prevádzky programu Spoľahlivá (udržateľná) prevádzka programu musí byť zabezpečená zákazníkom implementáciou súboru organizačných a technických opatrení, ktorých zoznam je uvedený nižšie: organizovanie nepretržitého napájania technických zariadení; používanie licencovaného softvéru; pravidelné vykonávanie odporúčaní Ministerstva práce a sociálneho rozvoja Ruskej federácie, stanovených v uznesení z 23. júla 1998 o schválení medziodvetvových štandardných časových noriem pre prácu pri servise počítačov a kancelárskej techniky a údržbe softvéru“ ; pravidelné dodržiavanie požiadaviek GOST 51188-98. Ochrana dát. Testovací softvér na počítačové vírusy Zo strany vývojára: automatické vytváranie záložných kópií; systém automatickej aktualizácie programu; automatické obnovenie systému; Čas obnovy po zlyhaní spôsobenom výpadkom napájania hardvéru (iné vonkajšie faktory) alebo nefatálnym zlyhaním (nie pádom) operačného systému by nemal presiahnuť 30 minút za predpokladu, že prevádzkové podmienky hardvéru a softvéru sa dodržiavajú. Čas obnovy po zlyhaní spôsobenom poruchou hardvéru alebo fatálnym zlyhaním (haváriou) operačného systému by nemal presiahnuť čas potrebný na odstránenie porúch hardvéru a preinštalovanie softvéru. Zlyhania programu v dôsledku nesprávnych akcií používateľa pri interakcii s programom. 3.1. Požiadavky na kvalifikáciu a počet personálu Minimálny počet personálu potrebného na obsluhu programu musí byť minimálne 1 jednotka na plný úväzok – obsluha PC. Zoznam úloh vykonávaných operátorom PC by mal obsahovať: udržiavanie databázy klientov; úlohy inštalácie (inštalácie) a údržby funkčnosti systémového softvéru - operačného systému; úloha inštalácie programu; úlohou vytvárania záloh databázy. 3.2. Požiadavky na skladbu a parametre technických prostriedkov ^ procesor s frekvenciou hodín 2,0 Hz, nie menej; Kapacita RAM, 1 GB, nie menej; voľné miesto na disku najmenej 1 GB; LAN karta; 3.3.1. Požiadavky na informačné štruktúry a metódy riešenia Softvér je samostatná spustiteľná aplikácia. Formát databázy je kompatibilný s ADO. Používatelia pracujú s databázou cez systémové rozhranie. 3.3.3. Požiadavky na zdrojové kódy a programovacie jazyky Neexistujú žiadne ďalšie požiadavky. Systémový softvér používaný programom musí byť licencovaná lokalizovaná verzia operačného systému Windows XP. Neexistujú žiadne požiadavky na ochranu informácií a programov. 3.5. Špeciálne požiadavky Neexistujú žiadne špeciálne požiadavky. ^ 4.1. Predbežné zloženie programovej dokumentácie Zloženie programovej dokumentácie by malo obsahovať: technická úloha; testovací program a metódy; návod na obsluhu; 5.1. Ekonomické prínosy rozvoja Program je bezplatný produkt, nie sú vynaložené žiadne finančné prostriedky a výhodou je zrýchlenie automatizácie spracovania dát klientov kaviarní/barov 6.1. Vývojové štádiá Vývoj by sa mal uskutočniť v troch etapách: Vývoj technických špecifikácií; Detailný dizajn; Implementácia. Vo fáze vývoja technických špecifikácií musí byť dokončená fáza vývoja, koordinácie a schvaľovania tejto technickej špecifikácie. Vo fáze podrobného návrhu musia byť dokončené tieto fázy práce: vývoj programu; vývoj programovej dokumentácie; testovanie programu. Vo fáze implementácie musí byť ukončená vývojová fáza prípravy a prenosu programu. Vo fáze vývoja technických špecifikácií sa musia vykonať tieto práce: Formulácia problému; Stanovenie a objasnenie požiadaviek na technické prostriedky; Stanovenie požiadaviek programu; Stanovenie etáp, fáz a načasovanie vývoja programu a dokumentácie k nemu; Koordinácia a schvaľovanie technických špecifikácií. Vo fáze vývoja programu sa musí pracovať na programovaní (kódovaní) a ladení programu. Vo fáze vypracovávania programovej dokumentácie musí byť vypracovanie programových dokumentov realizované v súlade s požiadavkami na skladbu dokumentácie. Počas testovacej fázy programu sa musia vykonať tieto typy práce: Vývoj, koordinácia a schvaľovanie testovacích metód; Vykonávanie akceptačných testov; Oprava programu a programovej dokumentácie na základe výsledkov testov. Vo fáze prípravy a prenosu programu musia byť dokončené práce na príprave a prenose programu a programovej dokumentácie na prevádzku v zariadeniach Zákazníka. 7.1. Typy testov: testovanie procesu inštalácie; testovanie ergonómie ; testovanie schopnosti systému obnoviť normálnu prevádzku; testovanie systému v rôznych konfiguráciách; testovanie systému; 7.2. Požiadavky na prijatie práce Po prijatí je potrebné overiť nasledujúce podmienky: úplnosť a kvalita implementácie funkcií pri štandardných hraničných kritických hodnotách parametrov objektu automatizácie a v iných podmienkach fungovania údajov v technických špecifikáciách; splnenie každej požiadavky týkajúcej sa rozhrania systému; Práca personálu v interaktívnom režime; Prostriedky a metódy na obnovenie výkonu softvéru po zlyhaniach; Komplexnosť a kvalita prevádzkovej dokumentácie.

	Technické špecifikácie pre vypracovanie projektového projektu priestorov. Informácie		Zadanie pre vypracovanie projektovej dokumentácie pre výstavbu ZOO Poriadok V hraniciach pozemku st. Podlesnaya, diaľnica Kosmonavtov, st. Malkova, Dzeržinský okres Perm
	Referenčné podmienky pre vývoj štruktúry dokumentu webovej stránky Informačný systém, ktorý poskytuje užívateľom internetu prístup k jeho obsahu a funkcionalite v organizovanom…		Referenčné podmienky pre vývoj webovej stránky „Asociácia ruských airbrushingových umelcov“ Hlavný html kontajner, do ktorého sa vkladajú informačné bloky, musí byť plne editovateľný. Výhodne...
	Referenčné podmienky pre vytvorenie automatizovaného systému "Corporate Data Warehouse" GOST 34. 602-89 Technické špecifikácie na vytvorenie automatizovaného systému (príklad)		2. Referenčné podmienky pre vývoj softvéru Tento projekt kurzu popisuje proces vydávania potvrdenia o dôchodkovom poistení. Vyvinutý systém je navrhnutý tak, aby zjednodušil…
	Referenčné podmienky pre vývoj webovej stránky časopisu Táto technická špecifikácia predstavuje… Stránka je modelovaná s ohľadom na obmedzenia moderných redakčných systémov (otvorený WordPress, Joomla, LiveStreet a podobne...		Program na demonštráciu algoritmov prechodu grafom Táto technická špecifikácia upravuje vývoj vzdelávacieho softvérového produktu určeného na vizuálnu prezentáciu…
	Zadávacie podmienky zahŕňajú: názov vývoja, základ... Technický a detailný návrh: popis predmetnej oblasti (model objektu), správa objektu (udalosti, interakčný diagram),…		Návrh softvéru Fáza návrhu zahŕňa vývoj architektúry, vývoj údajov a vývoj procedurálneho softvéru

Technické požiadavky na systém

Technický vzhľad produktu

Teória riešenia invenčných problémov je sovietska metóda silného myslenia, ktorá sa rozšírila v Rusku aj po celom svete. Umožňuje vám hĺbkovo analyzovať problém a nájsť efektívne riešenie.
Práce na TRIZ začal Genrikh Saulovich Alshuller a jeho spoločníci v roku 1946.

Vývoj programu: príklad technických špecifikácií

V roku 1956 vyšla prvá publikácia o tom, že technika sa vyvíja podľa určitých zákonov. Ak chcete efektívne vynájsť, musíte tieto zákony identifikovať a efektívne ich uplatňovať.
Postupom času sa TRIZ vyvinul do veľkej sady nástrojov, ktoré pomáhajú riešiť množstvo naliehavých problémov:
- vytvárať nové prelomové produkty,
— zlepšiť spotrebiteľské vlastnosti existujúcich riešení,
- znížiť náklady,
- obchádzať patenty konkurentov.
Popredné svetové spoločnosti ako Samsung, Intel, Procter&Gambel, General Electric a ďalšie využívajú TRIZ vo svojich R&D centrách.

Podmienky

Aby sa predišlo kontroverzným problémom a nedorozumeniam, je dôležité používať rovnaký pojmový aparát. Na tento účel sme zostavili zoznam najčastejšie používaných výrazov a skratiek.

Pokiaľ ide o vývoj technickej dokumentácie pre softvér, najčastejšie uvažujeme o dokumente, ako je technická špecifikácia (TOR). Prečo sa to deje?

Účel technických špecifikácií

Po prvé, zadávacie podmienky sú spravidla hlavným dokumentom v rámci projektovej dokumentácie. Práve technické špecifikácie popisujú všetky základné požiadavky na vývoj softvéru, či už ide o vytvorenie jednoduchého programu alebo webovej stránky, alebo o vývoj rozsiahleho informačného systému alebo hardvérového a softvérového komplexu. Okrem toho v jazyku GOST je možné vypracovať technickú špecifikáciu v rámci predbežného návrhu (ide len o popis funkcií a štruktúry systému bez zohľadnenia technológií implementácie riešenia), ako aj v budúcnosti. „migrovať“ na technický projekt (podrobnejší popis zohľadňujúci vybrané technológie) .

Po druhé, technická špecifikácia môže byť buď povrchná (napríklad všeobecná koncepčná špecifikácia určená pre investorov projektu) alebo podrobnejšia (napríklad podrobná špecifikácia pre programátora). Pozrite si sekciu Projekty, sú tam príklady rôznych technických špecifikácií. Môžete si vybrať akúkoľvek úroveň detailu - pripravíme pre vás technické špecifikácie akejkoľvek zložitosti za prijateľné ceny.

Po tretie, v niektorých prípadoch je možné vystačiť len s prípravou jednej technickej špecifikácie na popis vyvíjaného systému. Samozrejme, v tomto prípade hrá kľúčovú úlohu kvalita vypracovaných technických špecifikácií, takže sa tu jednoznačne neoplatí šetriť a je lepšie zveriť vývoj takýchto technických špecifikácií odborníkom, ktorí majú v tejto veci rozsiahle skúsenosti. Lakomec platí dvakrát, no v prípade zlyhania vývoja softvéru pre nekvalitnú dokumentáciu zaplatí desaťnásobok a niekedy aj o niekoľko rádov vyššie.

Zloženie štandardnej technickej špecifikácie

Pozrime sa, čo zahŕňa typická technická špecifikácia.

Ukázalo sa, že špecifikácia softvéru bola povrchná?

Technická špecifikácia, bez ohľadu na zvolený GOST, teda vždy obsahuje nasledujúce základné informácie o vyvíjanom softvéri:

1) názov– celé a krátke názvy, symbol vyvíjaného softvéru;
2) vymenovanie– prečo, v akej oblasti a na aký účel sa softvér vyvíja;
3) základ pre rozvoj– dokumenty, na základe ktorých sa vykonáva vývoj softvéru;
4) funkcie– zoznam a popis funkcií vyvíjaného softvéru;
5) štruktúru– opis architektúry a komponentov vyvíjaného softvéru;
6) používateľské rozhranie– v modernom svete je to povinné;
7) spoľahlivosť, bezpečnosť, prevádzkové podmienky a tak ďalej. dôležité požiadavky;
8) dokumentáciu– aká dokumentácia, v akom objeme a v súlade s požiadavkami GOST sa tiež vypracuje;
9) etapy a etapy vývoja– čo sa vyvíja a v akom poradí;
10) kontrolný postup a prijatie– ako presne bude vyvinutý softvér dodaný Zákazníkovi.

Normy pre technické špecifikácie

Existuje niekoľko GOST, ktoré regulujú vývoj technických špecifikácií v našej oblasti: sú to GOST 34.602 (automatizované systémy) a GOST 19.201 (softvér). Dokumenty pripravené podľa týchto noriem sa výrazne líšia obsahom aj obsahom. Oba štandardy sú prezentované na našom firemnom portáli v sekcii Knižnica, môžete sa s nimi bližšie zoznámiť.

Náklady na vývoj technických špecifikácií

Vo všeobecnosti je vypracovanie technických špecifikácií pomerne zložitá a zodpovedná úloha, ale dobre napísaná technická špecifikácia je už polovicou úspechu vyvíjaného projektu. Preto v procese vývoja technických špecifikácií pre softvér musíte preukázať maximálnu starostlivosť a povedomie v technických a organizačných otázkach. Alebo si u nás môžete už teraz objednať vypracovanie technických špecifikácií na kľúč.

Mohlo by vás tiež zaujímať:

– vypracovanie testovacieho programu a metodiky;
– vytvorenie vysvetlivky k predbežnému a technickému návrhu;
– etapy tvorby dokumentácie.

Písanie technických špecifikácií je jednou z prvých fáz práce na projekte. Predchádza vývoju samotného systému. V technických špecifikáciách popisujeme predmetnú oblasť, existujúcu infraštruktúru Zákazníka, požiadavky na vytváranú funkcionalitu, ako aj nefunkčné požiadavky. Výsledný dokument je potrebný ako pre obchodného užívateľa, aby sa ubezpečil, že všetky jeho želania pre budúci systém budú zohľadnené, tak aj pre nás na odhad nákladov na vývoj systému.

Stojí za zmienku, že v každodennej analytickej práci sa snažíme vyhýbať pojmu „technické špecifikácie“. Tento výraz je príliš preplnený významami a často nie je jasné, čo sa za ním skrýva. Používame pojmy „Dokument o obchodných požiadavkách“ (BRD – Dokument o obchodných požiadavkách), „Funkčné požiadavky“ (FRD – Dokument o funkčných požiadavkách) a Technické a architektonické požiadavky (TAD – Dokument technickej architektúry). Aby sme však nekomplikovali popis, budeme tu používať termín „Technické špecifikácie“. Dokument, ktorý používame vo väčšine prípadov na interakciu so zákazníkmi, pozostáva zo 70 % obchodných požiadaviek, 20 % funkčných požiadaviek a iba 10 % technických a architektonických požiadaviek. Samozrejme, tento podiel sa mení v závislosti od špecifík a technickej náročnosti systému.

Hlavným faktorom úspechu pri vývoji technických špecifikácií je správne štruktúrovaná komunikácia so zákazníkom. Koniec koncov, úlohou analytikov je skutočne vykonať operáciu brain-dump a usporiadať výsledky na papier v štruktúrovanej forme. Zároveň je veľmi dôležité (1) hovoriť so zákazníkom v rovnakom jazyku, aby sa nemusel prehrýzť pojmami danej oblasti, ktoré sú odborníkovi zrejmé a (2) vedieť správne počúvať.

Nižšie uvádzame zásady, ktorými sa riadime pri písaní technických špecifikácií, a ilustrujeme ich výňatkami z technických špecifikácií, ktoré sme vyvinuli pre viaczložkový bannerový reklamný systém pre veľkú internetovú spoločnosť.

Štruktúra technických špecifikácií

Každá technická špecifikácia obsahuje niekoľko povinných častí. Definujú účel dokumentu, terminológiu a všeobecný kontext projektu. Prvá časť dokumentu zvyčajne vyzerá takto:

Class="fs-13">

Ak sú na začiatku dokumentu uvedené všeobecné, koncepčné informácie o vyvíjanom systéme, potom v druhej, hlavnej časti dokumentu sú uvedené obchodné požiadavky a funkčné požiadavky na systém, ktoré sú podstatné pre odhad nákladov na vývoj. podrobne.

V technickej špecifikácii bannerového systému v časti „Terminológia“ definujeme pojmy ako zobrazenia, kliknutia, CTR, dosah, frekvencia kontaktov, súbor rezervácie atď. a v časti „Všeobecný kontext“ popisujeme hlavný biznis procesy zákazníckej spoločnosti, súvisiace s umiestňovaním bannerovej reklamy, ako aj systémové prostredie, aktuálne roly manažérov spoločnosti a prístupové práva. Stojí za zmienku, že v tomto konkrétnom prípade systém nebol postavený od nuly. Predtým manažéri firmy používali bannerový reklamný systém, ktorý bol iný ako u nás. V opačnom prípade by bola analýza rolí a prístupových práv s najväčšou pravdepodobnosťou zaradená do samostatnej kapitoly.

class="fs-13">

7. Systém umiestňovania bannerov
8.

Interakcia s fakturáciou
9. Banner Engine
10. Technický popis komponentu Banner Engine

class="fs-13">

Najobsiahlejšia časť technických špecifikácií, ktoré popisujeme, je „Systém umiestňovania bannerov“; je venovaný jadru vyvíjaného systému a obsahuje všetky požiadavky priamo na systém správy reklamných plôch.

S prihliadnutím na špecifiká tohto projektu sme venovali samostatnú časť interakcii bannera s fakturačným systémom. Do samostatnej časti sme zaradili aj požiadavky na celkom samostatnú zložku zberu a zobrazovania štatistických informácií, ktorá je takmer hlavnou zložkou systému pre zákazníkov reklamných kampaní a manažérov reklamných agentúr.

V samostatnej časti technických špecifikácií sú popísané požiadavky na komponent Banner Engine, ktorý je zodpovedný za zobrazovanie bannerov, zaznamenávanie štatistík, ich spracovanie a uchovávanie vo forme vhodnej pre ďalšiu analýzu a reportovanie.

Ide o technicky najzložitejší a najviac zaťažovaný komponent bannerového systému. Do technických špecifikácií sme zaradili časť obsahujúcu niektoré technické a architektonické detaily súvisiace s prevádzkou Banner Engine. V prvom rade vám to umožňuje minimalizovať riziká pri odhadovaní nákladov na vývoj systému, pretože v závislosti od zvolenej architektúry sa náročnosť práce môže výrazne líšiť.

Každá technická špecifikácia sa líši veľkosťou, počtom ilustrácií a počtom verzií. Napríklad bannerový dokument je prezentovaný na 44 stranách a obsahuje 15 ilustrácií. Proces prípravy tohto dokumentu trval približne mesiac a zahŕňal približne 8 iterácií so zákazníkom.

class="fs-13">

Obchodné verzus funkčné požiadavky

V referenčných podmienkach sa zaznamenávajú obchodné požiadavky na systém aj funkčné požiadavky:

— Obchodné požiadavky sú popisom toho, ČO musí systém robiť v jazyku podnikového používateľa. Predovšetkým obchodné požiadavky musia byť zrozumiteľné pre manažéra, ktorý nemá technické vzdelanie a skúsenosti.

— Funkčné požiadavky sú opisom AKO sa v systéme vykonávajú určité činnosti. Vo fáze vývoja technických špecifikácií sú funkčné požiadavky zvyčajne stanovené len pre najzložitejšie bloky projektu.

Ponorenie sa do zložitých oblastí vám umožňuje znížiť riziká pri následnom hodnotení projektu. Typické funkčné požiadavky zahŕňajú blokové diagramy, stavové diagramy, vývojové diagramy a sú doplnené o zložitejšie rozloženia obrazovky.

Príklad obchodnej požiadavky:

„Pri reklamnej kampani je dôležité čo najpresnejšie sledovať limit zobrazení, aby sa predišlo finančným stratám spojeným so zobrazovaním bannerov nad zaplatený limit. Okrem toho vyvstáva úloha obmedziť zobrazovanie jedného bannera na jedného používateľa, napríklad nie viac ako N-krát za deň.“

„Aby sme tento problém vyriešili [ktoré – pozri vyššie] Má využívať externú službu, ktorú budú bannerové servery kontaktovať vždy, keď sa banner zobrazí. Keďže táto služba je bodom zlyhania, bannerové servery musia správne zvládnuť situáciu, keď je externá služba nedostupná alebo odpovedá s oneskorením.“

Zvyčajne zahŕňame

Referenčné podmienky obsahujú popis rolí a hlavných užívateľských scenárov vo vyvíjanom systéme.

Správne technické špecifikácie pre vývoj softvéru sú tajomstvom úspešného projektu

Úloha: Administrátor

Príklad funkčnej požiadavky:

„Po pridaní novej stránky do systému musí administrátor vytvoriť reklamné plochy s ňou spojené. Pri vytváraní reklamnej plochy je potrebné uviesť platformu, typ plochy, podporovaný formát banneru, veľkosť, frekvenciu zobrazení (pri statických miestach), ktorá sa po vytvorení reklamnej plochy stáva k dispozícii manažérom, ktorí zadávajú inzerciu.

Technická špecifikácia obsahuje požiadavky na integráciu vyvíjaného systému s ďalšími externými a internými systémami používanými zákazníkom.

V kontexte technických špecifikácií pre bannerový systém ide o integráciu so systémami správy webových stránok spoločnosti, fakturácie, autentifikácie a ukladania užívateľských dát.

„Systém bannerovej reklamy je napojený na tri externé moduly fungujúce v prostredí spoločnosti: systém správy webových stránok spoločnosti, fakturačný systém a systém na autentifikáciu a ukladanie používateľských údajov.“ Každé zobrazenie bannera je sprevádzané požiadavkou od redakčné systémy do bannerového systému. Tieto systémy tiež používajú spoločné identifikátory platformy a reklamného priestoru, ako aj konzistentné názvy parametrov zacielenia.“

V referenčných podmienkach zvyčajne uvádzame slovník, ktorý vysvetľuje význam špeciálnych pojmov použitých v dokumente. Je veľmi dôležité presne definovať význam pojmov, ktoré sa neskôr v dokumente použijú.

« Umiestnenie (jednotka umiestnenia, riadok mediálneho plánu) – Ide o subjekt, ktorý kombinuje banner, ktorý je potrebné zobraziť, reklamnú plochu, na ktorej bude banner zobrazený, a pravidlá zobrazovania. Pravidlá zobrazenia určujú obdobie umiestnenia, parametre zacielenia, limity umiestnenia, váhy atď. V skutočnosti všetky reklamné kampane pozostávajú z umiestnení.“

Kontaktná frekvencia– počet jedinečných používateľov, ktorí si prezreli reklamný banner určitý počet krát. Napríklad, frekvencia kontaktu 5– počet unikátnych užívateľov, z ktorých každý si pozrel tento reklamný banner aspoň 5x. Frekvencia kontaktov 1= Pokrytie.

Základné princípy

Pri písaní technických špecifikácií sa snažíme v maximálnej možnej miere využívať grafické podklady pre vizuálnu a výstižnú prezentáciu informácií. Jeden diagram môže často nahradiť niekoľko strán textu. V tejto súvislosti vidíme náš cieľ ako tzv. výkres technických špecifikácií, t.j. prezentácia všetkých viac či menej zložitých fragmentov systému v grafickej podobe a využitie textu ako komentára ku grafickým materiálom.

Obchodní manažéri väčšinou nemajú čas študovať viacstranové technické požiadavky. Prezeranie obrázkov poskytuje jasnú predstavu o hlavných charakteristikách vyvíjaného systému. Vďaka tomu sa zlepšuje komunikácia medzi biznis užívateľom a nami a zvyšuje sa kvalita samotných požiadaviek.

Nasledujúci diagram ilustrujúci štruktúru reklamných kampaní a vzťah medzi hlavnými pojmami v rámci reklamných kampaní nám ušetril niekoľko strán textu.

V prípade potreby používame v technických špecifikáciách prototypy vybraných systémových obrazoviek (funkčné wireframy), ktoré aj keď nie sú konečné, demonštrujú základný blok funkčnosti používateľského rozhrania.

Tento prototyp obrazovky na úpravu reklamnej kampane bol zahrnutý do zadávacích podmienok systému bannerovej reklamy.

Prototypy už vo fáze vývoja dávajú zákazníkovi predstavu o tom, ako presne bude rozhranie systému vyzerať.

Požiadavky musia byť napísané v jazyku „živého človeka“., zrozumiteľné pre firemného užívateľa, vr. senior manažér bez technických zručností; mali by obsahovať minimum odbornej terminológie. Čím rýchlejšie sa používateľ s obsahom technickej špecifikácie „vyrovná“, tým efektívnejšia bude naša komunikácia s ním.

Skúsenosti z predmetu

Skúsenosti s vývojom podobných systémov majú veľký význam pri tvorbe technických špecifikácií. Pomáha nám rýchlo pochopiť obchodné procesy a potreby zákazníka a robiť „analogicky“ mnohé veci, ktoré by sa nám predtým zdali ťažké. Nahromadené skúsenosti v oblasti manažérskych obchodných systémov, veľkých internetových projektov, finančných systémov, e-commerce systémov nám umožňujú aplikovať naše znalosti vo vzťahu ku každému následnému projektu, ktorým sa zaoberáme. Pred prijatím objednávky na vyššie uvedený bannerový reklamný systém sme už vyvíjali niekoľko bannerových systémov. Vedeli sme dobre, ako bannery fungujú, a poznali sme charakteristickú terminológiu tejto tematickej oblasti. Na základe skúseností s inými bannerovými systémami sme zákazníkovi ponúkli pomerne veľa zjednodušení a originálnych riešení nielen v oblasti techniky, ale aj obchodu.

Hľadajte prednášky

Technické špecifikácie zariadenia

Pri navrhovaní technického zariadenia má dôležité miesto vypracovanie technickej a technologickej dokumentácie: technické špecifikácie (TOR) a technické podmienky (TS).

Technická úloha— ide o hlavný podkladový dokument pre vývoj produktu, ktorý obsahuje technické a ekonomické požiadavky na produkt, ktoré určujú jeho spotrebiteľské vlastnosti a efektívnosť použitia, zoznam dokumentov vyžadujúcich spoločné zváženie, postup dodania a akceptácie výsledkov vývoja. Konštrukčná špecifikácia je vypracovaná na základe GOST 15.001-88 a vypracovaná v súlade so všeobecnými požiadavkami na textové dizajnové dokumenty v súlade s GOST 2.105-68.

Ako technickú špecifikáciu je tiež dovolené použiť akýkoľvek dokument (zmluva, protokol, náčrt, vzorka produktu a pod.) obsahujúci potrebné a dostatočné požiadavky na vývoj a uznaný zákazníkom a vývojárom.

Schválená technická špecifikácia je dokument, ktorý musia vývojári dodržiavať vo všetkých fázach tvorby systému a návrhu úloh. Zmeny vykonané v technických špecifikáciách musia byť zdokumentované v protokole, ktorý je súčasťou technických špecifikácií. Protokol musí byť schválený objednávateľom.

Pri vývoji technických špecifikácií by ste mali:

· stanoviť všeobecný cieľ vytvorenia technického systému;

· stanoviť všeobecné požiadavky na navrhnutý systém;

· určiť fázy tvorby systému a načasovanie ich implementácie;

· vykonať predbežnú kalkuláciu nákladov na vytvorenie systému.

Zadávacie podmienky musia obsahovať tieto oddiely:

1) názov a rozsah aplikácie;

2) kód produktu;

3) dôvody rozvoja;

4) účel a štúdia uskutočniteľnosti;

5) zdroje pre rozvoj;

6) fázy vývoja a spustenia výroby;

7) technické požiadavky.

V závislosti od účelu vyvíjaných meradiel, podmienok ich výroby a prevádzky je možné meniť štruktúru technických špecifikácií kombinovaním jednotlivých sekcií a zavádzaním nových.

V kapitole Základ pre rozvoj uveďte názov dokumentu (dokumentov), ​​ktorý zabezpečuje tento vývoj, organizáciu, ktorá tento dokument schválila a dátum jeho schválenia, názov a kód témy vývoja.

Základom vývoja je marketingový prieskum a vydanie nového štandardu.

V časti „Štúdia účelu a uskutočniteľnosti rozvoja“ uveďte:

1. Špecifickým funkčným účelom predmetu je zníženie toxicity automobilu.

Referenčné podmienky pre vývoj programu

Dostupnosť domácich a zahraničných analógov a možnosť alebo uskutočniteľnosť ich použitia na tento účel - na trhu sú zahraničné analógy, ale ich cena a domáce analógy.

3. Odhadovaná potreba týchto predmetov medzi spotrebiteľmi - tento predmet je nevyhnutný, aby spotrebiteľ spĺňal normy a chránil zdravie ľudí a životného prostredia.

V časti „Zdroje vývoja“ je uvedený zoznam výskumných a iných prác, ktorých výsledky sa pri tomto vývoji využívajú, ako aj zoznam vzoriek alebo makiet, na základe ktorých sa vývoj uskutočňuje. von.

V časti „Etapy vývoja“ sú uvedené potrebné etapy prác a približné termíny ich ukončenia, zloženie a približné termíny odovzdania projektovej technologickej dokumentácie na metrologické preskúmanie a organizácia, ktorá ho vykonáva.

Na základe štádií životného cyklu produktu vyvíjame štádiá vývoja a uvedenia do výroby.

Hlavné fázy vývoja: marketingový výskum; vývoj technických špecifikácií; — návrh zariadenia; súdny proces; predvýroba; uvedenie do výroby.

V prvej fáze návrhu sa uskutoční výber (alebo vývoj) schematického diagramu objektu. Na tento účel sa na základe referenčných údajov, odporúčaní a noriem vytvára množstvo variantov objektu - analógov, ktoré do tej či onej miery spĺňajú požiadavky technických špecifikácií. Ďalej, ak je to potrebné, sú finalizované schematické diagramy analógových objektov. Ak sa nenájdu varianty objektov - analógy, prejdite na postup syntézy variantov objektov, s ktorými sa v strojárskej praxi ešte nestretli. V tomto prípade, ako už bolo uvedené, sa v maximálnej možnej miere používajú štandardné prvky a komponenty.

Ďalšou etapou návrhu je návrh hlavných prvkov a konštrukcia matematických modelov fungovania zariadenia. Poslednou fázou návrhu je finálna dizajnová formalizácia prijatých rozhodnutí, vyhotovenie výkresov a textovej časti v súlade s požiadavkami ESKD.

Po úspešných skúškach je pre zákazníka projektu na základe požiadaviek technických špecifikácií a noriem vzťahujúcich sa na tento typ výrobku, s prihliadnutím na výsledky skúšok, vypracovaná technická špecifikácia zariadenia, ktorá obsahuje:

1.Technické požiadavky

2. Bezpečnostné požiadavky

3. Environmentálne požiadavky

4. Pravidlá prijímania

5. Metódy kontroly

6. Preprava a skladovanie

7. Návod na obsluhu

8. Záruka výrobcu

9. Likvidácia

Na základe vypracovaných dokumentov môžete začať so samotným návrhom zariadenia.

Čo je to technická špecifikácia? Ako na to a na čo slúži? Príklady, ukážky, tipy a odporúčania.

Zdalo by sa, aké je to skvelé, keď vám niekto dokonale rozumie. Dali ste pár fráz a tu je presne to, čo ste si predstavovali. Žiaľ, takto to nefunguje.

Problém vnímania informácií je večný. Efekt „rozbitého telefónu“ je bežný jav. Ale čo keď jednoducho neviete, ako zadať úlohu? Áno, aj to sa stáva a treba s tým nejako pracovať, ale ako? Aby ste zabezpečili, že výsledky úloh, ktoré si nastavíte, budú spĺňať vaše očakávania, napíšte si technickú špecifikáciu.

Čo je to technická špecifikácia

Technická špecifikácia (alebo TOR) je dokument, ktorý obsahuje požiadavky zákazníka na produkty alebo služby poskytované dodávateľom. Jednoducho povedané: chcem mať sedem navzájom kolmých čiar a tiež nakresliť niektoré červenou farbou a niektoré nakresliť bezfarebne (odporúčam pozrieť si video o tejto téme na konci materiálu).

Dizajnové oddelenie

Tento dokument môže zaberať buď jednu stranu A4 alebo celý zväzok, všetko závisí od úloh a želaní, ktoré sú v ňom zahrnuté. Môžete napríklad napísať technickú špecifikáciu pre malú vstupnú stránku (jednostránkový web) alebo pre zložitý softvér so strojovým učením a ďalšími funkciami.

Prečo potrebujete technické špecifikácie?

• Na prideľovanie úloh účinkujúcim.
• Aby ste podrobne opísali, čo chcete na konci získať.
• Dohodnúť sa na poradí prác.
• Po realizácii prácu zhodnotiť a prijať.
• Do...(do komentára pridajte svoje možnosti).

V skutočnosti existuje oveľa viac účelov a výhod technickej špecifikácie ako v zozname vyššie. Pre mňa osobne je hlavnou úlohou, ktorú riešia technické špecifikácie, implementácia toho, čo potrebujem s minimálnymi odchýlkami od očakávaní (mojich očakávaní).

Vďaka technickým špecifikáciám sa môžete vždy pýtať na čas realizácie, peniaze a súlad s deklarovanými vlastnosťami finálneho produktu alebo služby.

V skutočnosti ide o seriózny dokument, ktorý zostavuje zákazník a dodávateľ. V rozsahu, v akom sú stanovené sankcie a povinnosti strán. Existuje množstvo GOST, prečítajte si viac o Habré.

Vývoj technických špecifikácií

Ak hovoríme o „dospelej“ hre, napríklad o technickej úlohe na vývoj mobilnej aplikácie alebo webovej stránky, ide o samostatnú prácu, za ktorú sa platí veľa peňazí. Prilákate osobu, zvyčajne bývalého alebo súčasného technického riaditeľa, a požiadate ho, aby vám pomohol.

Mať bradu je voliteľné

V závislosti od rozsahu projektu/úloh táto osoba zhromaždí všetky vaše „želania“, preloží ich do odborného jazyka, prípadne pripraví náčrty (ako by to malo približne vyzerať) a dá vám hotový dokument. Ďalej tento dokument odovzdáte účinkujúcim (tím v rámci vašej spoločnosti alebo externe), dohodnete sa na peniazoch, termínoch a pustíte sa do práce.

Tip: CTO by mal byť vo vašom tíme, inak vám s najväčšou pravdepodobnosťou počas implementácie niečo unikne. Jednoducho nemáte dostatok vedomostí na všetko. Kto sa podieľal na písaní technických špecifikácií, kontroluje ich.

Z čoho pozostáva technická špecifikácia?

Všetko bude závisieť od šablóny, ktorú si vyberiete (o niečo ďalej uvediem odkazy na šablóny/príklady), ale v technických špecifikáciách sú zahrnuté základné bloky:

1. Popis projektu/úlohy. Stručne napíšeme, aký je projekt alebo úloha, ktorú je potrebné dokončiť.
2. Účel a ciele. Aké sú ciele projektu?
3. Požiadavky. Dizajn, funkcie, technológie, ktoré sú potrebné.
4. Popis práce. Čo, kedy a ako sa bude robiť.
5. Postup kontroly a prijatia. Ako bude dielo prijaté, čo možno považovať za dokončené.
6. Aplikácie. Skice, skice, prototypy.

Cena diela je zvyčajne zahrnutá v samostatnom dodatku k zmluve, stáva sa to však vtedy, keď si zmluvné strany uvedú sumy samy v technických špecifikáciách.

Prepáčte, že prerušujem čítanie. Pripojte sa k môjmu telegramovému kanálu. Čerstvé oznámenia článkov, vývoj digitálnych produktov a hack pre rast, to všetko je tam. Čakám na teba! Pokračujme...

Príklady technických špecifikácií

Napriek tomu, že vývoj technických špecifikácií je zložitý proces, je veľmi zaujímavý. Vašou úlohou je znovu vytvoriť obraz konečného výsledku a potom ho po častiach opísať.

Príklad jedného z mojich zadávacích podmienok pre aktualizáciu aplikácie Smart TV. Úlohy pre zložitejšie a komplexnejšie produkty boli zostavené s pomocou kolegov z technického oddelenia. Neváhajte požiadať o pomoc svojich spoluhráčov, zapojte ich do procesu čo najčastejšie. A nezabudnite poskytnúť spätnú väzbu! Nie je nič horšie, ako vložiť úsilie a čas do niečoho bez toho, aby ste poznali výsledky. Povedzte nám, ako bola rada danej osoby užitočná vo vašej práci, inak je to jednostranná hra.

Referenčné podmienky pre rozvoj internetového obchodu

Referenčné podmienky pre vývoj mobilnej aplikácie

Referenčné podmienky pre stránku

Referenčné podmienky pre služby/aktualizácie

Ak potrebujete ďalšie vzorky, stačí si ich vygoogliť.

Hlavným odporúčaním je urobiť to. Problém je v tom, že materská lenivosť prekoná každého a nie je ľahké jej odolať. Zhromaždite všetku svoju vôľu a začnite písať technické špecifikácie, jednoducho píšte a neprestávajte. Nebojte sa, že to nevyjde „dokonale“, poviem vám tajomstvo, toto sa nikdy nestane. Len píš, bude to zakaždým lepšie a lepšie.

Takto to má byť

Moje prvé základy na písanie technických špecifikácií sa začali objavovať pred niekoľkými rokmi. Pracoval som s dizajnérmi a mal som za úlohu vytvárať kreatívy pre reklamné kampane. Chcel som to nesúrodo a zmenilo sa to na veľa strateného času a vysvetľovania. Postupom času sa nastavenie úloh začalo meniť na akési sémantické bloky a potom na niečo ako technickú špecifikáciu.

Napríklad pre úlohu „Tlačidlo Páči sa mi na stránke“:

1. Popis: na našej webovej stránke musíte vytvoriť tlačidlo „Páči sa mi to“.
2. Účel a ciele: zapojenie používateľov, vydávanie/hodnotenie materiálov na základe počtu lajkov.
3. Požiadavky: nasledujúci dizajn (príklad: odkaz na niečo podobné), funkčnosť (obrázok môže hodnotiť a páčiť sa mu každý používateľ, systém stránky zohľadňuje počet hodnotení Páči sa mi a mení výstup materiálov), technológia (dostupná na ploche a mobilné verzie stránky).
4. Popis práce: nakreslite 3 možnosti rozloženia tlačidiel (pripravený dátum: 10/01/17), vyviňte systém na distribúciu materiálov na základe lajkov (dátum: 14/10/17), testovanie funkcií (dátum: 16/10/17 ), vydanie (dátum: 17.10.2017)
5. Prevzatie práce: používateľ stlačí tlačidlo páči sa mi, systém započíta kliknutie, zmení sa dodávka materiálov.
6. Aplikácie: skice, skice, príklady projektov, kde funguje podobná funkcia.

Nechajte si pre seba tie časti a časti štruktúry, ktoré sú potrebné pre vaše úlohy. Napríklad šiesty blok „Aplikácie“ možno opísať vo funkčných požiadavkách. Základná rada: tak či onak popíšte úlohu podľa štruktúry technických špecifikácií. Týmto spôsobom vám neuniknú dôležité body a ušetríte sa zbytočných otázok a zároveň uľahčíte život svojim kolegom.

Nech sa páči

Pozreli sme sa na to, čo je to technická úloha a ako ju urobiť. Teraz máte možnosť jasne a jasne stanoviť úlohy, sprostredkovať svoje myšlienky iným ľuďom a ušetriť čas na ďalšie vysvetlenia. Dúfam, že teraz už viete, čo s tým všetkým robiť.