Prečo je potrebná špecifikácia?

Príklad TOR pre programátora

Naši odborníci pomohli zákazníkovi vytvoriť Referenčné podmienky pre modernizáciu ventilačného systému.

Viac detailov pod strihom..

Technická úloha

na modernizáciu technologického zariadenia ventilačných systémov laboratórnej budovy č. 451 452, budova 17 na adrese: Moskva

1. Všeobecné ustanovenia

1.1. Tento zadávací poriadok zabezpečuje realizáciu prác na modernizácii technologických zariadení, riadiacich systémov a automatizácie vetracích jednotiek budovy, laboratória č.451,452 budovy 17.

1.2. Pre výkon prác vypracovať pracovnú dokumentáciu pre úseky značiek AOV, EM, KhS, AHS, AK, ktorá by mala byť dohodnutá predpísaným spôsobom.

1.3. Vykonávať prácu v súlade s požiadavkami regulačnej a technickej dokumentácie.

1.4. Po dokončení práce predložte dokumentáciu skutočného stavu vyhotovenú v súlade s požiadavkami GOST a SNiP.

1.5. Hotové dielo odovzdajte klientovi.

1.6. Niektoré ustanovenia týchto zadávacích podmienok môžu byť špecifikované v procese práce po dohode so zákazníkom.

2. Technické požiadavky

2.1. Modernizácia riadiacich jednotiek pre zásobovanie teplom a chladom vetracích jednotiek.

2.1.1. Uzly regulácie dodávky tepla.

Modernizácia podlieha:

· riadiace jednotky dodávky tepla pre prvé vykurovanie vetracích jednotiek K1, K2, K2a, K4 budov MIK-V, P2, P6 laboratória č. 452, P1 laboratória.

· riadiace jednotky dodávky tepla pre druhé vykurovanie vetracích jednotiek K1, K2, K2a objektu MIK-V.

Existujúce riadiace jednotky dodávky tepla podliehajú demontáži, pričom niektoré zariadenia riadiacich jednotiek (obehové čerpadlá, uzatváracie armatúry), zodpovedajúce stavu resp. Technické špecifikácie, sa používa v namontovaných riadiacich jednotkách.

Zloženie výbavy montovaných riadiacich jednotiek, ako aj použitá výbava je uvedená v prílohe č.1.

Vykonajte hydraulické skúšky vykurovacích okruhov a ohrievačov vetracích jednotiek s vyhotovením protokolu o hydraulickej skúške.

Vykonávať nátery potrubí a zatepľovacie práce.

2.1.2 Uzly na reguláciu prívodu chladu do ventilačných jednotiek.

Chladiace jednotky pre vetracie jednotky K1, K2, K2a, K4 budov MIK-V, P2, P6 laboratória „452, P1 laboratória č. 451 sú predmetom modernizácie.

Rozsah prác:

· výmena termostatických ventilov riadiacich jednotiek chladenia;

Demontáž/inštalácia ventilátora kompresorovo-kondenzačnej jednotky K1;

· demontáž/inštalácia filtrov-sušičov kompresorovo-kondenzačných jednotiek K1, K2;

Demontáž/inštalácia výparníka ventilačnej jednotky K4;

· tlaková skúška v prostredí inertného plynu, vysávanie, dopĺňanie chladiacich okruhov freónom;

Obnova tepelnej izolácie potrubí.

2.1.3. Napájacie jednotky pre zvlhčovacie okruhy.

Nainštalujte filtre na čistenie studenej vody na napájacie jednotky zavlažovacích komôr klimatizačných zariadení K1, K2, K2a.

2.2. Skrine na riadenie a automatizáciu ventilačných zariadení.

Ovládacie skrine pre vetracie jednotky K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8 laboratória MIK-V, P2, P6, V1, V2, V3 č. 451, P1, V1 laboratórium č. 452.

Rozloženie novo nainštalovaných ovládacích panelov:

SHUA K1 - riadiaca skriňa a automatizácia ventilačnej jednotky a kompresorovej a kondenzačnej jednotky (KKB) klimatizácie K1 (MIK-V);

SHUA K2 - ovládacia skriňa a automatizácia ventilačnej jednotky a KKB klimatizácie K2 (MIK-V);

SHUA K2 - ovládacia skriňa a automatizácia ventilačnej jednotky a KKB klimatizácie K2a (MIK-V);

SHUA K4 - ovládacia skriňa a automatizácia ventilačnej jednotky a KKB klimatizácie K4 (MIK-V);

SHUV - ovládacia skriňa pre výfukové jednotky RU3, V1, V2, V3, V6, V7, V8 (MIK-V);

ShUA P2, P6 - riadiaca skriňa a automatizácia ventilačných jednotiek a kompresorových a kondenzačných jednotiek P2, P6 (laboratórium č. 452);

SHUV - ovládacia skriňa pre odsávacie jednotky V1, V2, V3 (laboratórium č. 452);

SHUA P1, V1 - rozvádzač a automatizácia ventilačných jednotiek P1, V1 (laboratórium č. 451).

Modernizované riadiace skrine by mali poskytovať:

výber režimu ovládania ventilačnej jednotky (manuálny/automatický) na prednom paneli skrine;

· svetelná signalizácia pravidelných a núdzových režimov prevádzky technologických zariadení vetracích jednotiek (prevádzka/havária);

vypnutie ventilačných systémov v prípade požiaru;

automatickú činnosť ochrán a blokovanie chodu zariadení v prípade mimoriadnych udalostí.

Ďalej sa majú využívať frekvenčné meniče na riadenie elektromotorov ventilátorov a čerpadiel.

2.3. Automatizácia a dispečerský systém

Automatizačný a dispečerský systém je určený na riadenie a riadenie prevádzky ventilačných jednotiek, ako aj na zber, spracovanie, prezentáciu a ukladanie prichádzajúcich informácií.

2.3.1. Automatizačný systém.

Automatizačný systém by mal vo všeobecnosti zabezpečiť autonómnu prevádzku vetracích jednotiek, ktorá si nevyžaduje zásah personálu údržby a prechod v prípade potreby na manuálny mód zvládanie. Pri akýchkoľvek možnostiach ovládania a bez ohľadu na stav lokálneho ovládača musí byť stav zachovaný automatické vypnutie všeobecné ventilačné systémy v prípade požiaru. Vypnutie musí byť vykonané individuálne pre každý systém pri zachovaní napájania protimrazových okruhov.

Miestna automatizácia ventilačných systémov by mala zahŕňať:

regulácia teploty privádzaného vzduchu na výstupe z vetracej jednotky alebo v prípade potreby teploty odvádzaného vzduchu z obsluhovaných priestorov;

regulácia vlhkosti privádzaného vzduchu;

zastavte ventilátory a zatvorte vzduchové ventily, keď sa spustí požiarny poplach;

Vypnutie zvlhčovania klimatizácie, keď sa zastaví jej ventilátor;

Otvorenie a zatvorenie vzduchového ventilu pri spustení a zastavení ventilátora;

· automatické zahrievanie ohrievačov pred spustením systémov v zimnom režime;

· ochrana proti zamrznutiu ohrievačov vzduchom a vodou (vypnutie ventilátora, zatvorenie vzduchovej klapky, otvorenie ventilu kúrenia na 100%);

vypnutie ventilátora pri absencii tlakového rozdielu;

· kontrola znečistenia filtrov zariadení.

Vzdialený vplyv na lokálnu automatizáciu s pracovnými stanicami je určený v nasledujúcom zväzku:

· zmena nastavení regulátorov teploty a vlhkosti;

· povoliť/zakázať nastavenia.

Existujúce periférne zariadenia automatizačného systému podliehajú overovaniu, čisteniu a ďalšiemu používaniu v nasledujúcom poradí:

· snímače teploty a vlhkosti vetracích jednotiek podliehajú overeniu;

· Snímače diferenčného tlaku je potrebné skontrolovať, vyčistiť;

· Termostaty na ochranu ohrievačov vzduchu pred zamrznutím musia byť vymenené.

· Pohony regulačných ventilov riadiacich jednotiek musia byť vymenené v súlade s bodom 2.1.1.

pohony vzduchových ventilov podliehajú kontrole a ďalšiemu používaniu;

Na ovládanie recirkulácie klimatizácie K1 vymeňte zapínacie a vypínacie ovládače vzduchových ventilov za ventily s riadiacim signálom 0..10V.

2.3.2. dispečerský systém.

Zahrňte do expedičného systému nasledujúce komponenty:

komplex meracích zariadení, akčných členov a automatizačných nástrojov na báze softvérových a hardvérových nástrojov „Honeywell“;

· multifunkčný káblový systém;

· komplex softvérových a hardvérových prostriedkov dispečingu.

Pre dispečerské ventilačné systémy zabezpečte zobrazenie, archiváciu a protokolovanie nasledujúcich informácií:

· grafické znázornenie inštalácií so snímačmi teploty a vlhkosti, protimrazovými termostatmi, diferenčnými tlakovými spínačmi, regulačnými ventilmi, zvlhčovačmi vzduchu, vzduchovými ventilmi;

čísla inštalácie;

údaje snímačov teploty a vlhkosti;

čítanie snímačov relé diferenčného tlaku;

indikácie polohy regulačných ventilov 0..100%;

režim prevádzky ventilátora/stop;

· "pracovný / stop" režim čerpadiel;

poloha vzduchových ventilov "otvorené / zatvorené";

zastaviť systémy pri spustení požiarneho poplachu;

vypnutie systémov, keď hrozí zamrznutie ohrievača;

vypnutie jednotky pri absencii poklesu tlaku na ventilátore;

Vypnutie zvlhčovača vzduchu pri zastavení ventilátora klimatizácie;

Prevádzka systémov podľa daného časového harmonogramu alebo bez neho;

· signalizácia havárií a havarijných situácií v prípade poruchy zariadenia, ako aj - výstup hodnôt technologických parametrov mimo stanovených rozsahov;

registrácia nehôd a núdzových situácií v denníku správ;

· protokol registrácie parametrov pre aktuálny čas s uvedením názvu riadených parametrov, merných jednotiek, čísla regulátora a vstupného/výstupného kanálu.

2.3.3. Napájanie automatizačného a dispečerského systému musí byť realizované zo siete striedavého prúdu s napätím 380/220 V, frekvenciou 50 Hz pomocou zdrojov. neprerušiteľný zdroj napájania na dobíjacích batériách a poskytovať ako zdroj energie pre elektrické prijímače prvej kategórie

Často prikladám prototypy stránok, aby klient pochopil, ako bude jeho stránka vyzerať. Potom zostavím samostatnú úlohu pre dizajnéra rozloženia - s technické detaily a vysvetlenia, ktoré mu pomôžu v práci.

Čím zložitejšia je úloha, tým podrobnejší by mal byť TOR. Keď som sa podieľal na veľkých projektoch, videl som zadávacie podmienky a 30 strán.

Guram Sipki, zakladateľ digitálneho štúdia Udix Media

V prvom rade klient potrebuje TK – aby pochopil, aká bude jeho stránka a na čo sa míňajú peniaze. Ak sa niečo urobí zle, môže sa obrátiť na TK a požiadať o zopakovanie.

TOR zostavuje projektový manažér po komunikácii s klientom a prerokovaní úlohy s projektantom.

Veľkí zákazníci často žiadajú veľmi podrobné špecifikácie, ktoré popisujú každé tlačidlo. Malé firmy, naopak, nemajú rady pedantné 100-stranové dokumenty.

Príklad technickej úlohy na finalizáciu lokality

Všeobecné informácie

Názov automatizovaného systému

"AKO PREDAJ"

Zákazník

Exekútor

Základ pre prácu

Plánované termíny začatia a ukončenia prác na vytvorení systému

Začiatok prác: 01.09.2010

Ukončenie prác: 31.12.2010

Účel a ciele vytvorenia systému

Účel systému

Vyvinuté automatizovaný systém navrhnutý na automatizáciu obchodných procesov podniku.

Ciele vytvorenia systému

Ciele vytvorenia automatizovaného systému

Ciele rozvoja AS SBYT sú:

1. 3. Charakteristika objektu automatizácie

3.1 Obchodné procesy podniku

3.1. 1 Obchodný proces "Uzavretie zmluvy"

Stane sa vaším štítom, v tomto dokumente vy, v takom prípade môžete ukázať prstom na bezohľadného vývojára a požadovať, aby bol váš web uvedený do súladu s ním.

Technická úloha(skrátene „TOR“) je dokument, ktorý čo najpodrobnejšie a najjednoznačnejšie odráža požiadavky na vašu budúcu stránku.

Stránka je vytvorená na základe TK. Čím je podrobnejší a jednoznačnejší, tým viac bude vaša nová stránka spĺňať vaše očakávania.

Zadávacie podmienky pre tvorbu stránky – ako zákon, by nemali umožňovať výklady a nezrovnalosti.

Všetko, čo nie je uvedené v TOR, vývojár robí podľa vlastného uváženia.

· Príručka správcu;

· Príručka správcu obsahu;

· Návod na inštaláciu;

· Príručka programátora.

2.20. Organizácia a vedenie odbornej prípravy pre špecialistov vyšetrovacieho výboru pod prokuratúrou Ruskej federácie

Platia nasledujúce požiadavky na školenie:

Exekútor musí vykonať školenie pre zamestnancov vyšetrovacieho výboru v rámci prokuratúry Ruská federácia pozostáva z najviac 10 osôb.

· Školenie by malo prebiehať v ruštine.

· Miestnosť na školenie poskytuje objednávateľ.

· Miesto a čas školenia je potrebné dohodnúť so zákazníkom.

Školenie by sa malo vykonávať o všetkých funkciách systému.

V rámci školenia je potrebné zrealizovať informačný obsah jednej pilotnej stránky Ring of Sites vyšetrovacieho výboru pod prokuratúrou Ruskej federácie.

3.

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

Dôležité

Počas procesu implementácie bude Dodávateľ poskytovať Zákazníkovi súčinnosť v rámci Harmonogramu implementácie.

6.1.11. V prípade zlej prípravy personálu Objednávateľa na implementáciu a potreby ďalšej asistencie zo strany Dodávateľa pre úspešnú implementáciu softvéru by mal byť spísaný dodatkový protokol o dohodnutí zmluvných cien za poskytovanie informačných a poradenských prác.

6.2 Postup ďalšej podpory úloh AS „PRODEJ“.

V TOR by sa mala uvádzať pracovná náročnosť a náklady na prácu na implementáciu dodatočných požiadaviek.

6.2.2. Zhotoviteľ sa zaväzuje udržiavať telefón horúcu linku» na údržbu softvéru.

Aspekty interakcie Predtým, ako pristúpime k príprave procesu tvorby technickej úlohy, povedzme si o štvoruholníku, do ktorého sa zhotoviteľ a objednávateľ dostanú pri spustení projektu. Požiadavky- požadované správanie systému, ako je opísané zákazníkom alebo držiteľom procesu, ktoré sa má implementovať. Požiadavky sa spravidla vytvárajú na základe skúseností, reprezentácie správneho správania programu.

Pre vývojára (vendora) ide o kľúčovú informáciu, avšak práve v štádiu zbierania požiadaviek dochádza k najväčšiemu počtu kolízií, chýb, nadbytočných požiadaviek a pod.

Zdroje- ľudia, stroje, zásoby, vývojové prostredie, čas a peniaze, ktoré sa majú použiť v procese implementácie požiadaviek. Zdroje vyžadujú jasné plánovanie a hodnotenie vo fáze schvaľovania zadávacích podmienok.

Patria sem požiadavky na rôzne druhy triedenia, integrácie chatu a možností telefonovania.

Úroveň služieb- v skutočnosti by požiadavky tejto úrovne mali byť prvé, ktoré sa dostanú do nových verzií s opravami. Ide o úlohy z hľadiska rýchlosti odozvy systému, práce pri vysokej záťaži a bezpečnosti.

Pozornosť

V ideálnom prípade by predajca nemal mať takéto vylepšenia – firemný softvér by nemal spomaľovať, nestratiť dáta, nezbaliť formuláre a distribuovať prístupové práva na rovnakej úrovni. Ale ak sa objavila požiadavka, ktorá nesúvisí s osobnou paranojou zákazníka alebo problémami na strane hardvér treba tomu venovať väčšiu pozornosť.

Technologická úroveň- posledný v zozname, ale pred ostatnými v dôležitosti a zložitosti.

Microsoft World alebo Microsoft Excel.

Osobne sa rozvíjame vstupná stránka Používame špeciálne softvérové ​​produkty.

S ich pomocou môžete rýchlo a jednoducho navrhnúť aj zložité stránky - to je napríklad Balsamiq. Ako však robíme celý prototyp sme už popísali v článku.

Na tému: Prototypovanie stránok: tvorba, nástroje a programy.

Predprojektový dizajn môže byť urobený spoločne s developerom alebo úplne posunutý na jeho plecia.
Hlavná vec, nezabudnite, potom sa na tom dohodnite a podpíšte to oboma stranami.

ŽIVOTNÉ HACKY PRE VÝVOJ TOR

Tieto body sa vzťahujú rovnako na vypĺňanie briefu aj na vypracovanie zadávacích podmienok.

A v nich vám prezradím niekoľko trikov, ako vytvoriť technickú špecifikáciu stránky a uľahčiť tak už aj tak ťažký život podnikateľa:

1.

Uistite sa, že klient a interpret si správne rozumejú.

Zadávacie podmienky by nemali obsahovať kvalitné prívlastky: krásny, spoľahlivý, moderný. Nedajú sa jasne pochopiť. Každý má svoje vlastné predstavy o kráse a modernosti.

Pozri. Koniec koncov, niekto si myslel, že tento dizajn je krásny a dovolil ho použiť na svojej webovej stránke:

To isté - s nejasným znením, ktoré samo o sebe nič neznamená:

• Stránka sa musí zákazníkovi páčiť.Čo ak má zlú náladu?
• Stránka musí byť užívateľsky prívetivá.Čo to znamená? Na čo pohodlné?
• Miesto musí vydržať veľké zaťaženie. 10 tisíc návštevníkov? Alebo 10 miliónov?
• Kvalitný odborný obsah. Dobre, chápete.

Skontrolujte, či v texte nie sú nejasnosti. Ak existuje - prepíšte.

Rozhodli ste sa objednať si webovú stránku (aka vstupnú stránku)? Ako ukazuje prax, nie je to také jednoduché. Stovky zákazníkov, ktorí videli svoju hotovú stránku, zistia, že im nevyhovuje: dizajn nie je rovnaký, rozloženie je chabé, chýbajú texty, pokazili veľa nepotrebných funkcií.

Aby ste sa vyhli takýmto následkom, potrebujete technickú úlohu na vývoj stránky.

POTREBUJEM TO?!

Nezáleží na tom, kto bude realizátorom stránky - vy sami, váš príbuzný, nezávislí pracovníci za skromný plat, špecializovaná spoločnosť za obrovské množstvo peňazí ...

Referenčné podmienky pre stránku by mali byť.

Môžete napríklad požiadať o vytvorenie vlastnej zostavy pre RegionSoft CRM alebo si môžete objednať integráciu so stránkou. Ide o úlohy, ktoré sú časovo úplne odlišné, priorita je tu veľmi dôležitá.Po zozbieraní, analýze a odsúhlasení požiadaviek so zamestnancami a manažmentom môžete začať vytvárať technickú úlohu.
Formulár môžete buď požiadať predajcu, alebo si ho vytvoriť sami – v každom prípade existuje niekoľko pevných pravidiel, ktoré vám aj vášmu poskytovateľovi CRM ušetria bolesť hlavy.

Anatómia referenčného rámca

Ak hovoríme o procese vytvárania technickej úlohy, potom existuje niekoľko etáp. Ich dôsledná pasáž vedie zákazníka k želanému zlepšeniu.
Tu sú.

Tu je dôležité vypočuť si názor predajcu, pretože presne vie, koľko času bude konkrétna úloha trvať. Verte mi, pre vývojára sa nevypláca hrať o čas a naťahovať termín – je pre neho výhodné dokončiť čo najviac projektov a urobiť to dobre, aby nedostal ranu do svojej povesti.

Čo sa týka realizmu, je ľahké vyhnúť sa požiadavkám na dokončenie CRM na úroveň riadiaceho systému collider: do požiadaviek by ste mali zahrnúť to, čo je skutočne potrebné na tento moment a v dohľadnej dobe.

Napríklad RegionSoft CRM je desktopový program, nemáme klienta prehliadača. Žiadať od nás vytvorenie webovej aplikácie pre jednu spoločnosť je nezmyselné, ide o veľký vývoj, v súčasnosti prebieha a nejde o možné dolaďovanie pre jednu spoločnosť.

Úplný a krátky názov informačného systému

Celý názov systému je oficiálna webová stránka Vyšetrovacieho výboru pod prokuratúrou Ruskej federácie.

Skrátený názov systému je "Site SKP", "System", "Site".

1.2. Meno zákazníka systému a jeho údaje

Názov: Vyšetrovací výbor pri prokuratúre Ruskej federácie

Miesto: Mr.

Info

Moskva, Technický pruh, budova 2

Skutočná adresa: A

Kontaktná osoba zákazníka:

Telefón: (4, (4;

Emailová adresa

1.3. Zoznam dokumentov, na základe ktorých je Systém vytvorený

Štátna zmluva č. ________________ zo dňa ___ ___________ 2010

1.4.

Určené v súlade s Dohodou.

2. Systémové požiadavky

2.1.

dátum platby

Číslo platby

Číslo platby v platobnom systéme

Výška platby

1. Vyberte riadky súboru prenosu údajov
2. Začnite prechádzať riadkami súboru prenosu údajov
3. Prečítajte si riadok súboru prenosu údajov
4. Získajte kód zmluvy z riadku súboru prenosu údajov
5. Nájdite zodpovedajúci prvok podľa kódu v adresári „Dohody protistrán“, ak sa prvok nenájde, zobrazte správu „Dohoda s kódom nebola nájdená ...“
6. Ak je prvok nájdený, pridajte riadok do tabuľky hodnôt, kde: "Dohoda" - nájdený prvok, "Dátum" - "Data_plat", "Číslo platby" - "Nomer_plat", "Suma" - "Summa_plat"
7. Po prijatí posledný riadok koniec slučky súboru prenosu dát
8. Pre každý riadok tabuľky hodnôt vytvorte doklad „Príkaz k úhrade príjem prostriedkov“.

Pri vypĺňaní briefu alebo zostavovaní špecifikácie dizajnu stránky v ňom nenechávajte medzery.

Musíte pochopiť, že „Podľa uváženia vývojára“ znamená „čo chcem, vrátim sa“ alebo „Všetko, čo nie je špecifikované, robí podľa uváženia interpreta“. A verte, že to nie je len diera, ale celé okno do Európy pre developera.

A samozrejme, nie vždy to tak je.

Ak máte kompetentného špecialistu, potom sa nemôžete obávať výsledku.

Tu však nastáva ďalší problém, on to naozaj vie urobiť správne, ale nebude sa vám to páčiť čisto subjektívne. A všetko bude ako vo vtipe, ktorý poznajú mnohí vývojári:

STRUČNE O HLAVNOM

Čas strávený pri zostavovaní a odsúhlasovaní zadávacích podmienok pre tvorbu webstránky či landing page určite neoľutujete.

Koniec koncov, je to vaše najlepší nástroj kontrola a riešenie nezhôd, ktoré v procese vzniknú.

Keď kliknete na konkrétny okres, mal by prejsť na stránku s textovým popisom tohto okresu.

· Blokovať „Blog predsedu“- mal by byť zoznam posledných troch tém vytvorených na blogu vo forme názvu témy a dátumu zverejnenia. Názov témy bude odkaz, po kliknutí by ste sa mali dostať na stránku blogu s popisom tejto témy. Tento blok by mal obsahovať aj video, ktoré je možné prehrať bez opustenia domovskej stránke. Video musí mať odkaz "Komentáre", čo je počet komentárov k videu. Odkaz "Komentáre" by mal viesť na stránku blogu s komentármi k odoslanému videu.

Päta by mala obsahovať vyhľadávacie pole, informácie o autorských právach atď.

2.3.

stručný- ide o dotazník s otázkami o obsahu, dizajne, technických možnostiach vašej budúcej stránky.

Zadanie môže samozrejme nahradiť podrobný brief podpísaný oboma stranami.

Koniec koncov, je to prakticky to isté, len s tým rozdielom, že brief je vašou víziou a referenčný dokument je konečný dokument založený na vašom briefe a samotných komentároch vývojára.

Ak niektoré body spôsobujú ťažkosti, neváhajte a položte vývojárovi otázky ako „Čo to znamená?“, „Ako to ovplyvní moju stránku?“, pretože nie všetci vývojári chápu to isté ako vy.

Buď v kolóne Ďalšie informácie„Uistite sa, že uvediete všetky svoje želania, ktoré neboli zahrnuté v odpovediach na otázky.

Ak tento stĺpec chýba, stačí ich pridať na koniec briefu.

VK, Google, Facebook.

3.2.2 B osobný účet v sekcii objednávky pridajte pole na pridanie promo kódu.

3.2.3 Namiesto stránky, ktorá sa používateľovi zobrazí po požiadavke na obnovenie hesla (v tvare name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), vytvorte stránku (v tvare názvu formulára. com/login/forgot/change_password=yes&lang =ru&USER_CHECKWORD=), ktorý zobrazí obsah stránky, bude mať pole „E-mail pri registrácii“, kontrolný reťazec, Nové heslo, potvrdenie hesla, tlačidlo odoslania údajov.

3.2.4 Pri pridávaní tovaru do košíka by sa malo zobraziť hlásenie, že tovar bol pridaný do košíka.

3.2.5 Pri registrácii nového používateľa pridajte správu, že heslo sa nezhoduje s bezpečnostnými nastaveniami.

» _» _______________ 2010

Postupne sa zmeny dostali do vydania a neskôr umožnili vytvoriť Nový produkt pre veľkoobchody, maloobchody a hypermarkety - RegionSoft Retail.

Úroveň používateľa alebo skupiny používateľov. Na tejto úrovni sa implementujú úlohy na spresnenie existujúceho rozhrania. Používateľ môže napríklad chcieť, aby sa pri umiestnení kurzora myši na zákazníka zobrazilo okno s číslom a stavom poslednej objednávky, alebo vlastný prehľad so špeciálnym zoskupením údajov.

Vylepšenia na tejto úrovni zaberú menej času, ale môže ich byť veľa – napríklad viaceré požiadavky z oddelení marketingu, logistiky a technickej podpory.

úroveň funkčnosti.Často je ťažké ho oddeliť od predchádzajúceho, funguje tu formálne kritérium - spresnenie nie je na úrovni zobrazenia niečoho v rozhraní, ale na úrovni spresnenia systémovej logiky.

Ak je tam napísané kaša, možno by stálo za to bežať a neobzerať sa späť.

• Poistiť sa proti nečestnosti interpreta. Keď je stránka pripravená, môžete ju skontrolovať referenčné podmienky. Existujú nezrovnalosti? Developer ich musí opraviť. Ak spolupracujete oficiálne a uzatvoríte dohodu, môžete byť dokonca donútení súdnou cestou.
• Zjednodušte výmenu účinkujúcich. Ak sa klient a vývojár pohádali a utiekli, vytvorenie stránky môže trvať dlho. Keď budú podrobné zadávacie podmienky, môže sa preniesť do nového tímu – zapojí sa do práce mnohonásobne rýchlejšie.
• Zistite náklady na vývoj zložitého produktu. Je nemožné odhadnúť presné načasovanie a náklady na vývoj komplexnej webovej služby hneď na začiatku. Najprv musíte pochopiť, ako bude služba fungovať a aké funkcie bude mať.

K dispozícii je root prístup, súkromné ​​​​IP adresy, porty, pravidlá filtrovania a smerovacie tabuľky.

Google PageSpeed ​​​​Insights je bezplatná služba odporúčania pre webové stránky na zrýchlenie zobrazenia stránky v prehliadači používateľa (https://developers.google.com/speed/pagespeed/insights/).

Optimalizácia pre vyhľadávače (alebo SEO) je súbor opatrení pre interné a externá optimalizácia zvýšiť pozíciu stránky vo výsledkoch vyhľadávačov pre určité požiadavky používateľov.

Externá optimalizácia stránky je registrácia stránky v vyhľadávače, spin-up in v sociálnych sieťach, budovanie odkazov prilákaním odkazov z iných zdrojov na propagované stránky, bannerová reklama, kontextová reklama.

Interná optimalizácia stránok je optimalizácia textu, URL adries, úprava štruktúry stránok, prelinkovanie, kontrola odoziev servera.

Dostupné materiály Odkazy na stránky, ktoré sa vám páčia, ako aj brožúry, časopisy, fotografie – čokoľvek, alebo možno máte hotovú knihu značiek. Priložené v samostatnom archíve. Minimálne rozlíšenie a zobrazovacie zariadenia V tomto odseku špecifikujte zariadenia, z ktorých chcete stránku prezerať – PC, notebooky, smartfóny... PC monitory od 19 do 27 palcov; Notebooky od 15,6 do 17,3 palcov; Smartfóny od 3,5 do 6 palcov; Tablety od 7 do 12 palcov mobilná verzia? Áno FUNKČNÉ POŽIADAVKY Približná sada modulov (pre používateľov) V tejto časti je potrebné uviesť všetky funkcie, ktoré chcete na stránke vidieť.

Môže to byť nákupný košík, filtre katalógov podľa rôznych parametrov, možnosť zadať online objednávku, zanechať požiadavku na spätné volanie, prihlásiť sa na odber noviniek a ďalšie možnosti.Katalógové filtre podľa ceny, abecedne, podľa výrobcu.
CRUпtCj9B:s»XVzhb╟▌╤└u╟J_■E╘Dj»J■╛EXHJya(gTT┬Pb╟▌╤└u╟╛#╜┘al+Kqѐ▕²╛#╜┘al+Kqѐ╈█al+Kqѐ╈3█ ╜IWA▓BOЬ└vOЗb╟▌╤└u╟╛#╜┘al+КaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+Пѕ⤕┘al+Пѕ⤕┘al+Пѕ⤖Gu. #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG╜┘al+KaXG╕Xu▀ ≈≈K&ОQТё╦▒'%[n╓≥Lk"[Ts(b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~y╚b╖~ ╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚b╖~s╚bD'═\┘*NlkZ ⌡ . ©OlM²K%j ┼╖`СsА≈K▐f²Yh▐Hd╟Fg╬lн∙╥е#⌡i<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Pamätáte si Murphyho zákony? Ak môžete byť nepochopení, musíte byť nepochopení. Platí to nielen v komunikácii medzi ľuďmi, ale aj pri tvorbe stránok. Klient chcel druhý Facebook, ale dostal fórum pre mladých chovateľov psov. Vývojár neuhádol zákaznícky Wishlist - stratil čas.

V tejto príručke vám poviem, čo a prečo musíte napísať do podmienok. Zároveň vám ukážem, ako nepísať, aby sa tvorba technickej špecifikácie nestala strateným časom.

Článok bude užitočný:

• Každý, kto súvisí s tvorbou stránok: vývojári, dizajnéri, dizajnéri rozloženia.
• Projektoví manažéri.
• Vedúci digitálnych štúdií.
• Podnikatelia, ktorí si plánujú objednať vývoj stránky.

Aby bol materiál funkčný, zozbieral som pripomienky od viacerých vývojárov, dizajnérov, projektových manažérov a majiteľov digitálnych štúdií. Tie najcennejšie sú pridané na koniec článku. Poďme na to.

Čo je špecifikácia a prečo je potrebná

Referenčné podmienky sú dokument, v ktorom sú stanovené požiadavky na lokalitu. Čím sú tieto požiadavky jasnejšie a podrobnejšie, tým lepšie všetci účastníci procesu chápu, ako by to malo byť. To znamená, že šanca, že s výsledkom budú všetci spokojní, rastie.

Hlavným cieľom zadávacích podmienok je zabezpečiť, aby si klient a interpret správne rozumeli.

Technické špecifikácie majú veľa výhod. Každá strana má svoje.

Výhoda pre klienta:

• Pochopte, za čo platí peniaze a aká bude stránka. Môžete okamžite vidieť štruktúru, pochopiť, čo bude fungovať a ako. Zistite, či vám všetko vyhovuje. Ak nie - nie je problém zmeniť pred začiatkom vývoja.
• Pozrite si kompetenciu interpreta. Ak sú zadávacie podmienky zrozumiteľné a jasné, zvyšuje sa dôvera v developera. Ak je tam napísané kaša, možno by stálo za to bežať a neobzerať sa späť.
• Poistiť sa proti nečestnosti interpreta. Keď je stránka pripravená, je možné ju skontrolovať podľa zadávacích podmienok. Existujú nezrovnalosti? Developer ich musí opraviť. Ak spolupracujete oficiálne a uzatvoríte dohodu, môžete byť dokonca donútení súdnou cestou.
• Zjednodušte výmenu účinkujúcich. Ak sa klient a vývojár pohádali a utiekli, vytvorenie stránky môže trvať dlho. Keď budú podrobné zadávacie podmienky, môže sa preniesť do nového tímu – zapojí sa do práce mnohonásobne rýchlejšie.
• Zistite náklady na vývoj zložitého produktu. Je nemožné odhadnúť presné načasovanie a náklady na vývoj komplexnej webovej služby hneď na začiatku. Najprv musíte pochopiť, ako bude služba fungovať a aké funkcie bude mať. Aby ste to dosiahli, musíte pripraviť technickú úlohu.

Výhody pre účinkujúceho:

• Pochopte, čo zákazník chce. Klientovi sa kladú desiatky otázok, ukazujú sa príklady, ponúkajú sa riešenia. Potom sa všetko zapíše do jedného dokumentu a skoordinuje. Ak je všetko v poriadku - na zdravie, pochopili ste správne.
• Poistiť sa proti náhlemu Wishlistu klienta. Niekedy sú zákazníci, ktorí chcú zmeniť úlohu v polovici. Ak ste súhlasili a podpísali TOR, tohto sa nebojíte. V takom prípade bude na vašej strane aj súd.
• Ukážte svoju kompetenciu. Dobre pripravené zadávacie podmienky klientovi ukážu odbornosť vývojárov. Ak spoločnosť pochybuje, či vám má dôverovať pri vývoji stránky, pochybnosti sa pravdepodobne rozptýlia.
• Zarobiť peniaze. Niektoré štúdiá a vývojári ponúkajú prípravu technických špecifikácií ako samostatnú službu.

• Uľahčiť a urýchliť proces vývoja. Dobrý TOR označuje štruktúru webu, potrebné funkcie a prvky na každej stránke. Keď sú všetky požiadavky už pred vašimi očami, zostáva len navrhnúť a napísať kód.

Teraz poďme zistiť, ako napísať dobrý TOR, ktorý vykonáva všetky tieto funkcie.

Referenčné podmienky stanovuje výkonný umelec

Vo všeobecnosti môže každý vykonať technickú úlohu. „Potrebujeme webovú stránku s vizitkou pre zubnú kliniku“ – toto je už technická úloha. Ale bude to robiť svoju prácu? Sotva.

Dobrý TOR vždy vytvára účinkujúci: projektový manažér alebo vývojár. Je zrejmé, že webový vývojár rozumie vytváraniu webových stránok viac ako majiteľ kaviarne alebo zubnej ambulancie. Preto bude musieť projekt opísať.

To neznamená, že klient zmizne a objaví sa úplne na konci, aby napísal: "Zbs, schvaľujem." Musí sa tiež zúčastniť procesu:

Zákazník si samozrejme môže načrtnúť vlastnú verziu TK. Možno to urýchli proces vytvárania konečných zadávacích podmienok. A možno z toho bude odpad, ktorý sa potichu hádže do koša.

Napíšte jasne a presne

Táto rada vyplýva z hlavného cieľa zadávacích podmienok – „Uistite sa, že si objednávateľ a zhotoviteľ správne porozumeli“.

Zadávacie podmienky by nemali obsahovať kvalitné prívlastky: krásny, spoľahlivý, moderný. Nedajú sa jasne pochopiť. Každý má svoje vlastné predstavy o kráse a modernosti.

Pozri. Koniec koncov, niekto si myslel, že tento dizajn je krásny a dovolil ho použiť na svojej webovej stránke:

To isté - s nejasným znením, ktoré samo o sebe nič neznamená:

• Stránka sa musí zákazníkovi páčiť.Čo ak má zlú náladu?
• Stránka musí byť užívateľsky prívetivá.Čo to znamená? Na čo pohodlné?
• Miesto musí vydržať veľké zaťaženie. 10 tisíc návštevníkov? Alebo 10 miliónov?
• Kvalitný odborný obsah. Dobre, chápete.

Skontrolujte, či v texte nie sú nejasnosti. Ak existuje - prepíšte. Vaša formulácia musí byť jasná a presná:

• Stránka sa musí načítať rýchlo → Každá stránka webu musí mať viac ako 80 bodov v Google PageSpeed ​​​​Insights.
• Veľké zaťaženie → 50 tisíc návštevníkov súčasne.
• Na hlavnej stránke sa zobrazí zoznam článkov → Hlavná stránka zobrazuje zoznam posledných 6 publikovaných článkov.
• Minimalistické užívateľsky prívetivé rozhranie predplatného → Nechajte pole pre e-mail a tlačidlo Prihlásiť sa → *nakreslený náčrt*.

Vymysleli sme formuláciu, poďme na štruktúru.

Zadajte všeobecné informácie

Všetci členovia tímu musia správne pochopiť, čo spoločnosť robí a kto je jej cieľová skupina. Aby sa nikto nezmýlil, je lepšie ho predpísať na samom začiatku zadávacích podmienok.

A tiež stojí za to uviesť účel stránky a opísať jej funkčnosť v skratke - aby ste namiesto blogu nezískali internetový obchod.

Vysvetlite ťažké pojmy

Prvým pravidlom zadania je, že by malo byť každému jasné, komu je určený. Ak sa chystáte použiť výrazy, ktorým váš klient – ​​majiteľ detského hračkárstva – nemusí rozumieť, určite mu ich vysvetlite. V jednoduchom jazyku, nie copy-paste z Wikipédie.

Popíšte nástroje a požiadavky na hosting

Predstavte si, že už 2 mesiace robíte skvelú webovú stránku. Každá fáza bola koordinovaná s klientom - je spokojný. A teraz je čas odovzdať dielo. Ukážete admin panel a klient zakričí: „Čo je toto? Modex?! Myslel som, že to urobíš na WordPress!“

Aby ste sa vyhli takýmto problémom, popíšte použité nástroje, motory a knižnice. Zároveň špecifikujte požiadavky na hosting. Nikdy neviete, urobíte to v PHP - a klient má server v .NET.

Uveďte požiadavky na lokalitu

Stránka by mala fungovať vo všetkých prehliadačoch aktuálnych verzií a na všetkých typoch zariadení. Áno, je to zrejmé každému vývojárovi a každému zákazníkovi. Ale je lepšie písať, aby ste klienta ochránili pred nepoctivo vykonanou prácou.

Napíšte sem požiadavky na rýchlosť načítania stránok, odolnosť voči zaťaženiu, ochranu pred útokmi hackerov a podobné veci.

Zadajte štruktúru lokality

Pred nakreslením návrhu a rozloženia sa musíte s klientom dohodnúť na štruktúre stránky.

Chatujte so zákazníkom, zistite, čo potrebuje. Zhromaždite vývojárov, SEO, marketérov, šéfredaktorov – a rozhodnite sa, ktoré stránky sú na webe potrebné. Zamyslite sa nad tým, ako budú vzájomne prepojené, z ktorých môžete prejsť.

Môžete zobraziť štruktúru ako zoznam, môžete nakresliť blokovú schému. Ako chcete.

Toto je jedna z najdôležitejších etáp práce na webe. Štruktúra je základ. Ak je neúspešná, stránka sa ukáže ako krivá.

Vysvetlite, čo bude na každej stránke

Klient musí pochopiť, prečo je každá stránka potrebná a aké prvky na nej budú. Sú dva spôsoby, ako to ukázať.

Prototyp- vizuálnejší a jednoznačnejší spôsob. Dodávateľ nakreslí náčrty každej strany a pripojí ich k zadávacím podmienkam. Klient vidí, ako bude vyzerať rozhranie jeho budúcej stránky a povie, čo sa mu páči a čo by sa malo zmeniť.

Vyčíslenie prvkov je lenivá alternatíva k prototypu. Stačí napísať, aké bloky majú byť na stránke a čo robia.

Zapíšte si scenáre používania stránky

Ak vytvárate nejaké neštandardné rozhranie, nestačí len ukázať štruktúru a miniatúry stránok. Je dôležité, aby celý realizačný tím aj klient pochopili, ako budú návštevníci stránku využívať. Skripty sú na to skvelé. Náčrt skriptu je veľmi jednoduchý:

• Akcia používateľa.
• Odpoveď webovej stránky.
• Výsledok.

Samozrejme, ak robíte štandardnú vizitku alebo vstupnú stránku, nemusíte písať skripty. Ale ak sú na stránke nejaké interaktívne služby, je to veľmi žiaduce.

Prečítajte si viac o prípadoch použitia na Wikipédii.

Zistite, kto je zodpovedný za obsah

Niektorí vývojári okamžite vytvoria stránku s obsahom. Iní dali ryby. Iní môžu písať texty, ale za príplatok. Dohodnite si to na brehu a zafixujte si v zadávacích podmienkach, aký obsah máte pripraviť.

Je dosť ťažké nájsť objektívne kritériá na hodnotenie kvality textov. Radšej nepíšte nič iné ako „Vysokokvalitný, zaujímavý a predajný obsah, ktorý je užitočný pre cieľové publikum“. Je to svinstvo, nikto to nepotrebuje.

Je užitočné určiť, že všetok obsah musí byť jedinečný. Ďalšia ochrana klienta pred bezohľadnými účinkujúcimi.

Opíšte dizajn (ak môžete)

Rovnako ako v prípade textu je ťažké prísť s objektívnymi kritériami na hodnotenie dizajnu stránky. Ak ste sa s klientom dohodli na farebnej schéme, napíšte ju. Ak má knihu značiek, v ktorej sú zapísané písma, uveďte ich tiež.

O krásnom a modernom dizajne nie je potrebné písať. Nič to neznamená, nemá žiadnu silu a vo všeobecnosti je to fu.

Namiesto záveru: štruktúra zadávacích podmienok

Pre rôzne úlohy bude štruktúra TOR odlišná. Je hlúpe vytvárať rovnaké technické špecifikácie pre novú sociálnu sieť a vstupnú stránku pre veľkoobchodnú mrkvu. Vo všeobecnosti však potrebujete sekcie ako je táto:

• Informácie o spoločnosti a cieľovom publiku, cieľoch a zámeroch stránky.
• Slovník pojmov, ktorým klient nemusí rozumieť.
• Technické požiadavky na usporiadanie a prevádzku lokality.
• Popis použitých technológií a zoznam požiadaviek na hosting.
• Podrobná štruktúra stránky.
• Prototypy stránok alebo popisy prvkov, ktoré by na nich mali byť.
• Scenáre používania neštandardného rozhrania (voliteľné).
• Zoznam obsahu, ktorý vytvára vývojár.
• Požiadavky na dizajn (voliteľné).

• Pravidlá pre zostavovanie Špecifikácie softvérových požiadaviek. SRS je ďalším krokom vo vývoji zadávacích podmienok. Potrebné pre veľké a zložité projekty.
• Štandardy a šablóny TOR pre vývoj softvéru. Popisy rôznych GOST a metodík na vytváranie technických špecifikácií.

Toto je koniec časti, ktorú som napísal. Ale je tu ešte jeden - pripomienky odborníkov, ktorí pomáhali pri tvorbe sprievodcu. Prečítajte si, tiež je to zaujímavé.

Komentáre vývojárov

Hovoril som s niekoľkými vývojármi, aby som zistil, ako píšu špecifikácie. Podávam im mikrofón.

V prvom rade klient potrebuje TK – aby pochopil, aká bude jeho stránka a na čo sa míňajú peniaze. Ak sa niečo urobí zle, môže sa obrátiť na TK a požiadať o zopakovanie.

TOR zostavuje projektový manažér po komunikácii s klientom a prerokovaní úlohy s projektantom.

Veľkí zákazníci často žiadajú veľmi podrobné špecifikácie, ktoré popisujú každé tlačidlo. Malé firmy, naopak, nemajú rady pedantné 100-stranové dokumenty. Je to dlhé čítanie a ľahko sa stane, že vám unikne niečo dôležité. Častejšie robíme stručné technické špecifikácie na 10–15 strán.

Označujeme:

• Informácie o spoločnosti a účele stránky.
• Požiadavky na dizajn, farby.
• Použité technológie a CMS.
• Kto sa podieľa na obsahu – my alebo klient.
• Štruktúra stránky až po každú stránku.
• Popis každej stránky. Nerobíme prototypy, ale špecifikujeme, aké prvky majú byť na stránke a ako majú fungovať.

Najdôležitejšie sú posledné 2 časti. Poskytujú pochopenie toho, aká bude stránka a ako bude fungovať.

Veľmi dôležitý bod - nemôžete len zadať podmienky vývojárom a dúfať, že urobia všetko dobre. TK je zoznam požiadaviek na stránku, nemôže nahradiť komunikáciu. Je dôležité uistiť sa, že každý člen tímu rozumie spoločnému cieľu, a nielen plní úlohy v rámci toku. Ak niečo nie je jasné - je potrebné vysvetliť, diskutovať, podrobne komentovať.