Ce includ termenii de referință? Procedura de elaborare a specificațiilor tehnice

În specificația tehnică, clientul trebuie să indice toate cerințele sale pentru obiectul de achiziție propus. În special:

Sfat:Merită să începeți să pregătiți specificațiile tehnice din timp. Acest lucru va reduce riscul ca termenele limită pentru publicarea documentației de achiziții în Sistemul Informațional Unificat să fie ratate. La urma urmei, serviciul contractual (managerul contractului) are nevoie de la câteva zile la câteva săptămâni pentru a întocmi o specificație tehnică de înaltă calitate, în funcție de complexitatea tehnică a obiectului achiziției.

Sfat: La elaborarea specificațiilor tehnice, este logic să vă ghidați după:

• GOST-uri. De exemplu, la crearea unui sistem automat - GOST 34.602-89 „Tehnologia informației. Set de standarde pentru sisteme automate. Specificații tehnice pentru realizarea unui sistem automatizat”;

• instrucțiuni metodologice (recomandări) ale fondatorului. De exemplu, Ministerul Culturii al Rusiei a elaborat Orientări privind procedura de elaborare a specificațiilor tehnice atunci când se efectuează achiziții în cadrul programului țintă „Cultura Rusiei (2012-2018)” (scrisoare a Ministerului Culturii din Rusia din ianuarie 25, 2013 Nr. 446-01-56/10-NM).

Crearea unei specificații tehnice este o sarcină creativă care necesită suficient efort și timp din partea clientului. Cu toate acestea, o abordare integrată a soluționării acesteia, precum și o atenție atentă la fiecare achiziție, este condiția principală pentru activități eficiente de achiziție.

1. Informații generale despre client

În această secțiune ar trebui să indicați următoarele date despre clienți:

• Nume;

• localizarea clientului;

• programa.

Indicarea locației și a orelor de funcționare ale clientului este relevantă atunci când, în conformitate cu termenii contractului, participantul trebuie să livreze bunuri (efectuează lucrări, prestează servicii) pe teritoriul clientului.

Această secțiune poate include și informații despre achizițiile comune sau centralizate, precum și despre implicarea unui expert (organizație de experți).

2. Informații generale despre achiziție

Aici merită precizat:

• numele complet al obiectului achiziției,

• metoda aleasă pentru determinarea furnizorului (antreprenor, executant),

• sursa de finantare.

Această secțiune poate conține, de asemenea, informații despre termenii și abrevierile utilizate în specificațiile tehnice. Aceste informații pot fi prezentate, de exemplu, sub forma unui tabel.

Termeni și abrevieri	Definiție
DE	Produsul software „Salariu-Buget”, care face obiectul achiziției
Client	Instituția de stat „Alpha”
Expert	Specialist care are cunoștințe speciale în domeniul contabilității și fiscalității în sectorul public, în materie de personal și juridic și are studii superioare de specialitate

3. Descrierea obiectului achiziției

Această secțiune ar trebui să descrie următoarele cât mai complet și corect posibil.

1. Caracteristici calitative, tehnice și funcționale. Calitatea produsului trebuie să respecte atât cerințele legale, cât și termenii contractului.

În acest caz, clientul trebuie să utilizeze indicatori standard (cerințe, simboluri și terminologie) atunci când descrie caracteristicile tehnice și de calitate. Pentru a face acest lucru, trebuie să fiți ghidat de cerințele obligatorii, în special de GOST, SNiP și legislația civilă (articolele 469, 721 din Codul civil al Federației Ruse). De exemplu, cerințele pentru calitatea alimentelor sunt stabilite în Legea federală nr. 29-FZ din 2 ianuarie 2000.

Dacă indicatorii standard nu pot fi preluați din reglementări tehnice, standarde (alte acte legislative privind reglementarea tehnică), atunci este necesar să se justifice utilizarea altor indicatori (cerințe, denumiri, terminologie).

Sfat: Nu ar trebui să utilizați valori exacte ale indicatorilor. Este mai bine să le înlocuiți cu condiții cu valori maxime și/sau minime, precum și cu valori care nu se pot modifica. Adică, astfel de indicatori care vor permite participanților să determine dacă bunurile achiziționate (lucrări, servicii) îndeplinesc cerințele stabilite. De exemplu, atunci când achiziționați o unitate de sistem, ar fi mai corect să indicați în specificațiile tehnice „Capacitatea hard disk - nu mai puțin 500 GB” și nu „Capacitate hard disk - 500 GB”.

Acest lucru este menționat în partea 2 a articolului 33 din Legea nr. 44-FZ și explicat în scrisoarea Ministerului Dezvoltării Economice al Rusiei din 10 decembrie 2014 nr. D28i-2796.

2. Caracteristici de performanță (dacă este necesar).

3. Cantitatea totală de mărfuri (volum de muncă, servicii). Când acest lucru nu este posibil, clientul poate indica prețul unei unități de lucru (serviciu).

4. Cerințe de ambalare. Aceasta este o cerință suplimentară. În specificațiile tehnice, puteți indica, de exemplu, că ambalajul produsului trebuie să asigure siguranța acestuia în timpul transportului și depozitării.

5. Cerințe de securitate pentru obiectul achiziției.

6. Condiții și procedură de livrare a mărfurilor, efectuarea lucrărilor, prestarea serviciilor.În special, este necesar să se determine locul de livrare a mărfurilor (execuția muncii, prestarea serviciilor). În acest caz, puteți specifica:

• adresa de livrare specifica;

• interval (alternativ) de locații de livrare, în care participantul trebuie să indice o anumită adresă în aplicație (de exemplu, în limitele Moscovei).

Acest lucru este necesar pentru ca atunci când depun cererile, participanții să aibă o idee despre unde trebuie să livreze bunurile (în ce loc să presteze un serviciu sau să efectueze lucrări). Apoi, atunci când decid să depună o cerere, ei vor înțelege dacă pot îndeplini comanda în acest loc anume. Clientul, la rândul său, se va proteja de riscul ca ofertantul câștigător să refuze să execute.

7. Perioada de garanție și service în garanție(Partea 4 a articolului 33 din Legea nr. 44-FZ). Perioada de garanție trebuie stabilită în zile, luni și ani.

După aceasta, este important să specificați termenii serviciului de garanție, adică o listă completă a acțiunilor furnizorului (antreprenor, executant) pentru a menține sau aduce obiectul achiziției în starea cerută de client.

De exemplu, la achiziționarea unui aparat de aer condiționat, merită să se stabilească o perioadă de garanție de cel puțin doi ani, timp în care furnizorul va fi obligat să inspecteze gratuit echipamentul în termen de trei zile de la momentul detectării avariei și să elimine orice identificat. încălcări în funcționarea sa.

8. Alte caracteristici care sunt importante atunci când descriem un anumit tip de produs, muncă, serviciu. Astfel, la achiziționarea unui produs, clientul trebuie să indice în specificațiile tehnice că acesta trebuie să fie nou și lipsit de drepturile terților. Adică nimeni nu a folosit sau reparat produsul înainte. În caz contrar, clientul riscă să primească un produs folosit. Acest lucru este menționat în paragraful 7 al părții 1 a articolului 33 din Legea nr. 44-FZ.

Dacă este necesar, termenii de referință ar trebui să includă și cerințe suplimentare pentru obiectul achiziției. Poate fi:

• instruirea angajaților;

• cerințe de instalare și punere în funcțiune;

• service întreținere;

• potrivirea probei etc.

Lista de informații și cerințe pot varia în funcție de fiecare articol specific de achiziție.

Un exemplu de descriere a unui obiect de achiziție

În conformitate cu programul Instituției de Stat „Alpha”, achiziția unui lot de hârtie pentru echipamente de birou este planificată pentru luna mai 2016. În pregătirea licitației electronice, managerul contractului A.S. Glebova a început să pregătească documentația de achiziție, în special, a compilat-o sarcina tehnica .

Atenţie! Participantul are dreptul de a nu lua în considerare și de a nu implementa date despre obiect care nu sunt reflectate în specificațiile tehnice.

In cazul in care produsul (lucrarea, serviciul) oferit de castigator nu se potriveste clientului, dar in acelasi timp corespunde specificatiilor tehnice, acesta nu are dreptul de a refuza incheierea contractului.

Sfat:Ca sursă de informații ar trebui să utilizați:

• contracte încheiate anterior,

• surse disponibile public (cataloage, liste de prețuri, broșuri publicitare etc.),

• oferte comerciale,

• informații de pe Internet.

Toate acestea vor ajuta la reflectarea in specificatiile tehnice exact a acelor caracteristici ale produsului (lucrare, serviciu) de care clientul are nevoie.

Atenţie! Dacă clientul indică în documentația de achiziție informații care pot duce la o limitare a numărului de participanți, atunci va exista riscul asumării răspunderii administrative. Astfel, funcționarii (managerul contractului, angajații serviciilor contractuale) pot fi amendați în valoare de 1% din prețul contractual inițial (maxim) (NMCP), dar nu mai puțin de 10.000 de ruble. și nu mai mult de 50.000 de ruble. (Partea 4.1 a articolului 7.30 din Codul contravențiilor administrative al Federației Ruse).

Atenţie!Când descrieți articolul de achiziție, nu puteți indica numele organizațiilor de producție, mărci comerciale, mărci de servicii etc. Acest lucru va duce la restrângerea concurenței și, în consecință, la o încălcare a legislației privind achizițiile publice. Excepții - specificația tehnică poate conține o mențiune a mărcilor comerciale, dacă este necesar:

• indicați mijloacele de muncă utilizate în executarea lucrărilor sau a serviciilor, dar nu ca obiect al contractului. În acest caz, o condiție obligatorie este indicarea mențiunii „sau echivalent”;

• achiziționarea de bunuri necesare pentru a interacționa cu bunurile utilizate de client (de exemplu, actualizarea software-ului instalat);

• achiziționarea de piese de schimb sau consumabile pentru mașinile și echipamentele clientului.

Acest lucru este menționat în paragraful 1 al părții 1 a articolului 33 din Legea nr. 44-FZ.

Atenţie! Este imposibil să achiziționați diverse produse (bunuri, lucrări, servicii) care nu au legătură între ele din punct de vedere tehnologic și funcțional în cadrul unei achiziții (un lot). Acest lucru va limita numărul de participanți. De exemplu, următoarele servicii nu pot fi combinate într-o singură achiziție:

• pentru protecția instalației folosind sisteme de securitate și de alarmă împotriva incendiilor și

• pentru întreținerea alarmei în sine.

FAS Rusia a clarificat că acest lucru se aplică diferitelor piețe de servicii. La urma urmei, organizațiile de securitate, de regulă, nu deservesc alarmele. Și dacă includeți astfel de servicii într-o singură achiziție, acest lucru va duce la o limitare a numărului de participanți.

Acest lucru rezultă din partea 3 a articolului 17 din Legea federală din 26 iulie 2006 nr. 135-FZ și este explicat în scrisorile Ministerului Dezvoltării Economice din Rusia din 10 martie 2015 nr. D28i-442, FAS Rusia din mai 21, 2014 Nr AC/20578/14 .

Prin urmare, atunci când planifică o achiziție și întocmește documentația, clientul trebuie să analizeze acest punct și, dacă este necesar:

• împărțiți achiziția în loturi separate,

• Pentru fiecare lot, întocmește o specificație tehnică separată.

4. Cerințe pentru furnizor (antreprenor, executant)

Termenii de referință trebuie să includă o cerință conform căreia participanții la achiziții trebuie să respecte legislația rusă. Aceasta ar putea fi, de exemplu, informații despre disponibilitatea unei licențe pentru un anumit tip de activitate.

În plus, în unele cazuri, guvernul Federației Ruse poate stabili cerințe suplimentare pentru participanții la achiziții, în special, disponibilitatea resurselor financiare și materiale, experiență de lucru similară cu obiectul contractului (Partea 2 a articolului 31 din Legea nr. 44-FZ). Astfel, în Decretul Guvernului Federației Ruse din 4 februarie 2015 nr. 99 există cerințe suplimentare pentru participanții la achiziții pentru lucrările de conservare a siturilor de patrimoniu cultural. Participantul la o astfel de achiziție trebuie să furnizeze informații despre contractul pe care l-a îndeplinit fără penalități în ultimii trei ani. Valoarea unui astfel de contract trebuie să fie de cel puțin 20 la sută din NMCC pentru a cărui încheiere se efectuează achiziția.

2 voturi

O zi bună, dragi cititori. Lucrul pe un site web cu un client este întotdeauna dificil. Clientul, de regulă, vrea fie „ceva cool”, fie „nimic neobișnuit, să fie ca toți ceilalți”. Concepte abstracte, veți fi de acord. Dacă aceasta este prima ta comandă, atunci s-ar putea chiar să fii mulțumit de cuvinte similare: „Mișto, îmi dau libertate de creație, pot face tot ce vreau”. Vă spun din experiență, nimic asemănător!

Clientul are propria înțelegere a „cool” și „ca toți ceilalți”. S-ar putea să nu ghiciți, să fiți într-o dispoziție greșită sau clientul va decide pur și simplu că „pentru astfel de bani, acest tip (sau fata) poate lucra puțin mai mult”. Pentru a preveni acest lucru, astăzi vom discuta despre modul în care sunt întocmite specificațiile tehnice pentru dezvoltarea site-ului web.

Plan de acțiune pentru lucrul cu clientul

Găsiți un client. El este gata să plătească banii, iar tu te apuci de treabă. De unde să începeți și cum să procedați?

• Prima comunicare.

Așadar, ați primit informațiile inițiale: acest lucru se poate întâmpla în persoană (dacă oferiți singuri serviciile) sau la telefon (când clientul vă găsește singur). Să presupunem că știi că clientul dorește un magazin online de la tine, iar el însuși deține un lanț de bijuterii. Nu începeți niciodată o conversație despre site imediat. Faceți o programare ca să vă puteți pregăti cu toții împreună și la unison.

Încearcă să motivezi cumva persoana să se uite la informații, astfel încât să aibă o idee mai clară despre ce vrea de la tine.

• Pregătirea și primul brief.

Priviți site-urile pe care le considerați potrivite pentru client. Descărcați câteva șabloane și spuneți că site-ul ar putea arăta exact așa. Cu cât mai multe materiale, cu atât mai bine. Să aveți ceva de arătat clientului, să aveți o idee clară despre ceea ce îi place și ce nu. Evitați conceptele abstracte din serie: frumoase, convenabile, de înaltă calitate. Fiecare are propriile idei despre aceste categorii.

În mod ideal, este mai bine să lăsați chiar clientul cu aceste materiale pentru o zi sau să le trimiteți prin poștă cu câteva zile înainte de întâlnire. Deși, în această etapă, clientul, de regulă, nu este deosebit de interesat de portal. El este gata să taie adevărul imediat după fapt și să te oblige să-l refaci și să adaugi ceva nou, dar să nu discute nimic în avans. Prin urmare, singura cale de ieșire este să ceri cât mai mult posibil și să notezi fiecare cuvânt.

• Intocmirea si semnarea specificatiilor tehnice.

Amintiți-vă, cu cât sunt mai multe bucăți de hârtie, cu atât fundul este mai curat. Notează, întocmește și semnează tot ce este posibil de la client. Ulterior, vei avea ceva de arătat. În general, atunci când scrieți specificațiile tehnice, imaginați-vă imediat că dvs. și clientul nu vă vedeți ochi în ochi și vă apărați cazul în instanță.

Nu vorbim de proiecte super scumpe, și sper că veți avea noroc cu clienții. Dar un client meticulos îți poate distruge starea de spirit pentru o lungă perioadă de timp. Vei dori să scuipi, să refuzi bani, doar să nu te mai întâlnești cu el. Acest lucru este de înțeles, dar dacă inițial te arăți ca un profesionist, studiezi totul cu atenție și te arăți ca o persoană respectabilă, atunci nu va trebui să faci asta.

Într-o zi am fost foarte norocos. Înainte de a veni la întâlnire, clientul a studiat problema și a întocmit el însuși nu numai o specificație tehnică competentă, ci și o misiune artistică. Adică, o descriere literară și detaliată a modului în care ar trebui să arate totul. Surpriza mea nu a cunoscut limite, la care el a răspuns: „Cred că însuși clientul, în primul rând, ar trebui să știe ce vrea, și nu să chinuie specialiștii.” Din păcate, acest lucru este rar, așa că trebuie să punem întrebări, să prescriem și să aprobăm.

• Dezvoltare și recepție.

După ce ați semnat totul, puteți începe implementarea proiectului.

Ce nu ar trebui să fie în specificația tehnică și ce ar trebui să fie acolo

De fapt, specificația tehnică nu trebuie să conțină instrucțiuni privind designul în sine. Scrii că pe un site web pentru un programator vei desena o tastatură și apoi începe - nu este așa, vreau să fie în stilul benzilor desenate și apoi să demonstrezi că nu ești un căprior. Cu cât vă dovediți mai bine ca profesionist, cu atât vor fi mai puține plângeri împotriva dumneavoastră!

Tu însuți știi în ce stil și ce ar trebui desenat. Te confrunți cu o sarcină: să îmbunătățești gradul de cunoaștere a mărcii sau să motivezi oamenii să plece în vacanță într-un astfel de loc. Modul în care veți implementa această sarcină este problema dvs. Ceea ce lipsea, de asemenea, era ca clientul să te învețe cum să scrii cod și să-ți spună ce instrumente să folosești.

Lăsați declarația dvs. de muncă să conțină expresia: „Tot ceea ce nu este convenit este executat la discreția interpretului.” Și nu este necesar să faceți această linie cu font mic. Lasă-l să se gândească în avans și să nu înceapă să viseze când proiectul este deja gata. Desigur, puteți și ar trebui să faceți mici modificări. O bună reputație este cheia viitorilor clienți, dar uneori un client poate fi atât de enervant cu dorințele sale încât nu vrea să trăiască.

Încă o dată aș dori să vă concentrez atenția asupra faptului că specificația tehnică nu trebuie să conțină concepte abstracte: „convenient”, „frumos”, „de înaltă calitate”, etc. Lăsați granițele să fie clare: în loc de comoditatea căutării, este mai bine să scrieți filtrarea după dată sau material.

Și nu uitați de semnătură. Totul este serios, clientul trebuie să înțeleagă acest lucru.

În general, vă recomand să fiți atenți la lucrurile mărunte. Imaginați-vă că vine la tine o femeie spumată și își descheie în grabă jacheta uriașă, astfel încât o eșarfă supradimensionată să iasă din ea. Scoate din geantă un bilet mototolit de 18 coli, împăturit de o sută de ori și încearcă să o netezească cu obiectele din apropiere. Față roșie și nearticulată: „Uite, am scris și am făcut-o mai scurtă, așa va arăta site-ul tău, semnează-l.”

O altă variantă. Un tânăr ciocăne în biroul tău, se dezbracă încet, scoate un dosar din servietă, îl deschide încet și te invită pe îndelete să te uiți la o singură bucată de hârtie, îți întinde un stilou auriu și te invită să semnezi acest document.

Lasă domnișoara din primul exemplu să facă o treabă titanică, a citit o mie de cărți, a desenat 18 exemple din care să aleagă și, practic, a făcut totul singură. Ea este capabilă să creeze un proiect incredibil de cool, care vă va conduce compania către prosperitate și faimă în întreaga lume. Iar tânărul din cel de-al doilea exemplu nu știe să facă nimic; a tipărit o mostră de pe Internet, care nu ți se potrivește deloc.

Vă asigur că orice client o va tortura pe biata femeie cu cicăli, dorințe și modificări și va accepta proiectul tânărului, dacă nu imediat, atunci pentru a doua oară. Nu este vorba despre ce poți face, ci despre cum acționezi și despre impresia pe care o creezi.

Există GOST, conform căruia puteți crea specificații tehnice pentru dezvoltarea site-ului web și există o practică pe termen lung. Standardele de stat nu se potrivesc întotdeauna cu realitățile vieții. Să încercăm să combinăm ambele părți.

Indiferent dacă scrieți specificații tehnice pentru administrația orașului sau legendarul Vasily Pupkin, conținutul este cel mai bine realizat în conformitate cu GOST. Învață acest lucru în avans.

Arata cam asa:

1. Glosar
2. Dispoziții generale
3. Subiect de dezvoltare
4. Scopul documentului
5. Cerințe pentru designul grafic al site-ului web
6. Cerințe de proiectare a site-ului web
7. Procedura de aprobare a conceptului de proiectare
8. Cerințe funcționale
9. Cerințe pentru prezentarea site-ului
10. Cerințe pentru un sistem de management al conținutului
11. Cerințe pentru partajarea accesului
12. Cerințe pentru tipurile de garanții
13. Cerințe pentru suport informațional
14. Cerințe software
15. Cerinte tehnice
16. Cerințe pentru suport lingvistic
17. Cerințe de ergonomie și estetică tehnică
18. Cerințe pentru acceptarea și livrarea proiectului
19. Cerințe pentru completarea informațiilor
20. Cerințe de personal
21. Procedura de furnizare a distribuirii
22. Procedura de transfer al site-ului către mijloacele tehnice ale clientului

Adevărat, nu va trebui să vă creați documentul cu sarcina în această ordine, dar pentru a fi mai ușor de înțeles, vă voi spune conform acestui plan. La sfârșitul acestui articol atașez un eșantion pe care îl puteți descărca și lucra la el, pe baza transcripției oferite în această parte a articolului. Acest șablon este bun pentru că are Toate, chiar și ceea ce nu vei avea niciodată nevoie. Dar trebuie să o procesezi pentru tine și să tai orice prostie inutile pe care o consideri inutilă.

Glosar

Potrivit GOST, documentul ar trebui să înceapă cu un glosar, dar de fapt îl veți scrie la sfârșit. Aici trebuie să oferiți termenii pe care îi veți folosi atunci când lucrați cu clientul. Spune-ne ce sunt găzduirea, un site web și alte prostii. Toate aceste prostii pot fi descărcate de pe Internet.

Cu toate acestea, pe lângă această erezie, este necesar să menționați termeni, în înțelegerea cărora dvs. și clientul puteți avea o diferență de opinie. Vrei să spui un lucru, dar el dă un sens complet diferit cuvintelor.

Dispoziții generale

În acest moment, trebuie să răspundem la întrebarea ce vom face de fapt și de ce.

Subiect de dezvoltare

Ceea ce vom face este aproximativ clar. Clientul oferă aceste informații aproape imediat. Este mai important să înțelegem scopul operațional al site-ului, adică ce beneficii îl așteaptă pe client. Este clar că toți clienții vor să facă profit prin intermediul site-ului. Această formulare nu va funcționa.

Gândiți-vă la modul în care clientul va câștiga bani, care este scopul lui. Dacă acesta este un magazin online, atunci ar trebui să fie angajat în vânzări; dacă este un site web corporativ, atunci le place o frază frumoasă: „creșterea loialității mărcii”, informarea despre activitățile companiei și așa mai departe.

Scopul documentului

Aici vă spunem cât de important este acest document. Arătăm că acesta nu este un truc simplu, dar wow! Folosim termeni legali. Această parte poate fi copiată de pe Internet, dar nu uitați să citiți cu atenție ceea ce scrieți!

Apropo, în aceeași parte trebuie să includeți informații că tot ceea ce nu discutați cu clientul în avans rămâne în conștiința dumneavoastră. Ești liber să faci ce vrei dacă el „a uitat”, „s-a răzgândit” sau „vrea totul cu totul altfel”.

Cerințe pentru designul grafic al site-ului web

Cerințe de proiectare a site-ului web

Aici trebuie să descrieți în termeni generali designul site-ului, ce ar trebui să existe și ce puncte trebuie respectate: culori corporative, fonturi și așa mai departe. În termeni generali, nu intra în detalii.

Procedura de aprobare a conceptului de proiectare

În această parte, intimidați din nou clientul folosind termeni legali. Îi spui că îi vei oferi un design de site web sub forma unei imagini realizate în Photoshop. El este obligat să-l urmărească în termenul specificat. După care vă vom oferi modificările, iar dvs., la rândul său, vă veți gândi dacă este un căprior și vă veți coordona și înțelege cât de logice sunt aceste modificări și dacă veți prelua „corecția”.

Cerințe funcționale

Aici descrii ce vom face de fapt. Descriem componenta vizuală. Capitolul se dezvoltă în trei părți: descriem pagina principală, structura internă și structura site-ului.

Atenție. Acesta este un punct important în care este mai bine să scrieți mai mult. De exemplu, ar trebui să aveți o secțiune „Știri similare”. Ce veți face: scrieți un algoritm care va calcula ce articole sunt cele mai apropiate de subiect, oferiți o listă cu ultimele cinci articole adăugate pe site sau autorul textului va avea posibilitatea de a introduce link-uri în acest bloc independent?

Cerințe pentru prezentarea site-ului

1. Structura site-ului: descriem ce categorii (titluri) vor fi pe site.
2. Pagina de pornire: cel mai bine cu o imagine schematică și descrierea elementelor principale.
3. Pagini interne: la fel ca în paragraful anterior. Diagrama și descrierea paginilor interne.

Dacă faceți un magazin online, puteți introduce și o diagramă a paginii comenzii, confirmarea plății și așa mai departe aici. Descrieți orice pagină care va diferi de șablonul standard.

Cerințe pentru un sistem de management al conținutului

Blogul meu este destinat persoanelor care creează site-uri web folosind WordPress. Prin urmare, nu voi acorda o importanță serioasă acestui punct. Declarăm că vom folosi acest motor și asta va fi suficient.

Dacă aveți de gând să vă faceți singur un sistem de control, atunci totul este mult mai complicat. Va trebui să desenați din nou diagrame și să descrieți cerințele generale, gestionarea secțiunilor, conținutul și setările. Desenați fiecare element care va fi diferit.

Cerințe pentru partajarea accesului

Aici, în esență, vor să afle de la noi când și de ce utilizatorul va avea nevoie de înregistrare. Ce secțiuni închidem și pe care dintre ele cititorii le pot folosi în siguranță. Dacă acesta este un site de cărți de vizită, informativ sau de vânzare, acesta va fi complet deschis, dar pe VKontakte, de exemplu, accesul la o pagină personală are acces limitat și se poate face numai după introducerea numelui de utilizator și a parolei.

Cerințe pentru tipurile de garanții

Cerințe pentru suport informațional

Această parte este creată pur și simplu pentru a vă arăta propria conștientizare și pentru a arăta încă o dată clientului ce profesionist sunteți, ce termeni sofisticați cunoașteți.

Le vei spune că vei stoca datele într-un anumit loc de pe server, și nu în birou sau sub pernă. Utilizați limbaje de programare.

Sunteți de acord să postați imagini numai în format gif sau jpg, iar paginile nu vor depăși o anumită greutate. Apropo, mare punct. Apoi, dacă clientul își umflă ochii și spune că are nevoie de altceva, puteți arăta acest articol și spune: „Ei bine, tu însuți ai semnat despre greutate, nu știu nimic, toate acestea sunt imposibile!”

Un alt lucru cu adevărat util pe care îl puteți menționa aici este limitarea conținutului oferit. Trebuie să determinați domeniul de aplicare - vă ocupați de tot conținutul sau creați un cont de administrator, oferiți clientului un login și o parolă și îi lăsați să-și dea seama!

Cerințe software

1. Aici vorbim despre hosting sau servere. Deoarece blogul meu se adresează creatorilor care lucrează pe Timeweb ( https://timeweb.ru ) - totul este foarte simplu. Dacă nu sunteți unul dintre „noi”, atunci trebuie să vă uitați la specificațiile tehnice. De exemplu, cineva foarte inteligent face un site web cool și apoi încearcă să-l conecteze la găzduire, dar specificațiile tehnice sunt atât de înalte încât nicio găzduire din Rusia nu se poate descurca. Elementul este necesar, dar nu și pentru începătorii în domeniul dezvoltării.
2. Aici descriem dacă portalul va avea o versiune mobilă, adaptată pentru dispozitive portabile sau poate fi deschis doar prin Google Chrome și nu ne pasă deloc de distorsiunile din alte browsere.

Cerințe pentru suport lingvistic

Site-ul va fi realizat în două limbi sau vom avea nevoie doar de rusă?

Cerințe de ergonomie și estetică tehnică

Încă o dată menționăm pe scurt principiile principale ale designului. Totul va fi clar, simplu și uniform. Sigla și informațiile de contact vor fi vizibile peste tot. Totul este super, totul este minunat.

Cerințe pentru acceptarea și livrarea proiectului

Cerințe pentru completarea informațiilor

În acest moment vă spunem ce ne angajăm să facem, precum și ce trebuie să ne ofere clientul pentru ca munca să meargă mai repede și mai bine. El are nevoie de obicei de informații și fotografii.

Mai scriem din nou ca daca vrea sa corecteze sau sa schimbe ceva, va trebui sa intocmeasca din nou un acord similar, pe care fie sa il semnati, fie nu.

Cerințe de personal

Cine poate folosi site-ul. De exemplu, unele companii lucrează cu coduri și nici măcar nu se deranjează cu un sistem de control pentru oamenii normali. Pentru acțiunile de bază pe șantier, vor fi necesare cunoștințe semnificative din partea personalului. În acest caz, punctul este relevant, dar în cazul nostru este doar hârtie mâzgălită.

Procedura de furnizare a distribuirii

Ce îi vei oferi clientului când lucrarea este finalizată: autentificare, parolă, înainte și înapoi.

Completam pretul specificatiei tehnice

După cum înțelegeți deja, sarcina principală a specificațiilor tehnice nu este atât de mult să înțelegeți, deși acest lucru este important. Și totuși, funcția sa suplimentară este de a crea impresia corectă de sine și de a proteja împotriva tot felul de modificări.

Totul despre acest document ar trebui să fie impresionant! Dacă urmează să-l trimiteți spre examinare preliminară prin poștă, atunci trebuie utilizat formatul PDF. Iar clientul probabil nu va dori să se tortureze cu editări și se va gândi la tine ca la un profesionist. Un lucru mic, dar unul semnificativ. Pentru a converti un document Word, puteți utiliza serviciul https://smallpdf.com/ru/ .

Nu uitați să introduceți propria companie sau logo-ul mărcii în fundal, precum și să inserați informații de contact. Acestea pot fi emise rapid și eficient pe site https://logaster.ru .

Ei bine, asta e tot, tot ce trebuie să faci este să descarci exemplul pe care l-am creat special pentru tine. Vă va ajuta să înțelegeți și să luați ca bază câteva puncte șablon care nu vor fi diferite și ați terminat.

Acum poți să mergi în siguranță la client și să nu-ți fie teamă că vei fi acuzat că ești incomplet.

DESCARCĂ șablonul TK

Mult succes in demersurile tale si ne revedem. Abonați-vă la blogul meu și primiți cele mai utile informații care vă vor fi cu siguranță utile atunci când lucrați la dezvoltarea unui site web bun pentru clienții dvs.

Sunt adesea întrebat: „Cum să dezvolt corect specificațiile tehnice pentru un sistem automat?” Subiectul dezvoltării specificațiilor tehnice este discutat constant în diferite forumuri. Această întrebare este atât de largă încât este imposibil să răspunzi pe scurt. Prin urmare, am decis să scriu un articol lung pe această temă. În procesul de lucru la articol, mi-am dat seama că nu ar fi posibil să pun totul într-un singur articol, pentru că... Va avea aproximativ 50 de pagini și am decis să-l împart în 2 părți:

• In prima parte" Elaborarea specificațiilor tehnice. Ce este, de ce este nevoie, de unde să începi și cum ar trebui să arate? Voi încerca să răspund la întrebările subiectului în detaliu, să iau în considerare structura și scopul Termenilor de referință și să dau câteva recomandări cu privire la formularea cerințelor.
• A doua parte " Elaborarea specificațiilor tehnice. Cum se formulează cerințe? va fi dedicat în întregime identificării și formulării cerințelor pentru un sistem informațional.

În primul rând, trebuie să vă dați seama ce întrebare îi interesează de fapt pe cei care întreabă „Cum se dezvoltă o specificație tehnică?” Cert este că abordarea dezvoltării specificațiilor tehnice va depinde în mare măsură de scopurile pentru care se realizează, precum și de cine va fi utilizat. Despre ce optiuni vorbesc:

• O organizație comercială a decis să implementeze un sistem automatizat. Nu are propriul serviciu IT și a decis să facă acest lucru: Partea interesată trebuie să elaboreze o Specificație Tehnică și să o prezinte spre dezvoltare unei terțe părți;
• O organizație comercială a decis să implementeze un sistem automatizat. Are propriul serviciu IT. Am decis să facem acest lucru: să dezvoltăm o Specificație tehnică, apoi să cădem de acord asupra acesteia între serviciul IT și părțile interesate și să o implementăm pe cont propriu;
• Agenția guvernamentală a decis să demareze un proiect IT. Totul aici este atât de tulbure, o mulțime de formalități, comisioane, tăieturi etc. Nu voi lua în considerare această opțiune în acest articol.
• O companie IT oferă servicii pentru dezvoltarea și/sau implementarea sistemelor automatizate. Acesta este cel mai dificil caz, deoarece trebuie să lucrați într-o varietate de condiții:

  Clientul are proprii sai specialisti cu opinii proprii, si fac cerinte specifice pentru Specificatiile Tehnice;

  • Termenii de referință sunt dezvoltați pentru dezvoltatorii interni (clientului nu-i pasă);
  • Termenii de referință sunt dezvoltați pentru transferul către contractant (adică un grup de programatori din personalul companiei sau un specialist individual);
  • Între companie și client apare o neînțelegere cu privire la rezultatul obținut, iar compania își pune din nou și din nou întrebarea: „Cum ar trebui elaborate Specificațiile Tehnice?” Ultimul caz poate părea un paradox, dar este adevărat.
  • Sunt posibile și alte opțiuni, mai puțin obișnuite;

Cred că cititorul ar trebui să aibă acum întrebări:

• De ce specificațiile tehnice nu pot fi dezvoltate întotdeauna în același mod?;
• Există standarde, metode, recomandări? De unde le pot lua?
• Cine ar trebui să elaboreze Termenii de referință? Această persoană ar trebui să aibă cunoștințe speciale?
• Cum să înțelegeți dacă Termenii de referință sunt bine redactați sau nu?
• Pe cheltuiala cui ar trebui să fie dezvoltat și este chiar necesar?

Această listă poate fi nesfârșită. Spun asta cu încredere pentru că sunt de 15 ani în dezvoltarea de software profesională, iar întrebarea Specificațiilor Tehnice apare în orice echipă de dezvoltare cu care lucrez. Motivele pentru aceasta sunt diferite. Ridicând subiectul dezvoltării Termenilor de referință, sunt foarte conștient că nu îl voi putea prezenta 100% tuturor celor interesați de subiect. Dar, voi încerca, după cum se spune, „să rezolv totul”. Cei care sunt deja familiarizați cu articolele mele știu că nu folosesc „copy-paste” din munca altora, nu retipăresc cărțile altora, nu citez standarde cu mai multe pagini și alte documente pe care le puteți găsi pe Internet, trecându-le drept propriile tale gânduri de geniu. Doar introduceți într-un motor de căutare „Cum se dezvoltă o specificație tehnică” și puteți citi o mulțime de lucruri interesante, dar, din păcate, repetitive. De regulă, cei cărora le place să fie inteligenți pe forumuri (încercați doar să căutați!) nu au făcut niciodată ei înșiși o specificație tehnică adecvată și citează în mod constant recomandări GOST în această problemă. Iar cei care sunt cu adevărat serioși în privința problemei, de obicei, nu au timp să stea pe forumuri. Apropo, vom vorbi și despre standardele GOST. De-a lungul anilor de muncă, am văzut multe versiuni ale documentației tehnice compilate atât de specialiști individuali, cât și de echipe eminente și companii de consultanță. Uneori mă angajez și în această activitate: îmi aloc timp și caut informații despre un subiect de interes din surse neobișnuite (cum ar fi puțină inteligență). Drept urmare, a trebuit să văd documentație despre astfel de monștri precum GazProm, Căile Ferate Ruse și multe alte companii interesante. Desigur, respect politica de confidențialitate, în ciuda faptului că aceste documente îmi vin din surse accesibile publicului sau din iresponsabilitatea consultanților (împrăștierea informațiilor pe Internet). Prin urmare, spun imediat: nu împărtășesc informații confidențiale care aparțin altor companii, indiferent de surse (etică profesională).

Ce este o specificație tehnică?

Primul lucru pe care îl vom face acum este să ne dăm seama ce fel de fiară este această „Specificație tehnică”.

Da, există într-adevăr GOST și standarde care încearcă să reglementeze această parte a activității (dezvoltare software). Pe vremuri, toate aceste GOST-uri erau relevante și utilizate în mod activ. Acum există opinii diferite despre relevanța acestor documente. Unii susțin că GOST-urile au fost dezvoltate de oameni foarte lungi de vedere și sunt încă relevante. Alții spun că sunt iremediabil depășiți. Poate că cineva a crezut acum că adevărul este undeva la mijloc. Aș răspunde cu cuvintele lui Goethe: „Se spune că între două păreri opuse se află adevărul. În niciun caz! Există o problemă între ei.” Deci, nu există adevăr între aceste opinii. Pentru că GOST-urile nu dezvăluie problemele practice ale dezvoltării moderne, iar cei care le critică nu oferă alternative (specifice și sistemice).

Rețineți că GOST în mod clar nu oferă nici măcar o definiție, spune doar: „TK pentru o centrală nucleară este documentul principal care definește cerințele și procedura pentru crearea (dezvoltarea sau modernizarea - apoi crearea) unui sistem automatizat, în conformitate cu care se realizează dezvoltarea unei centrale nucleare și acceptarea acesteia la punerea în funcțiune.”

Dacă cineva este interesat de ce GOST-uri vorbesc, iată-le:

• GOST 2.114-95 Sistem unificat de documentație de proiectare. Specificatii tehnice;
• GOST 19.201-78 Sistem unificat de documentare a programului. Sarcina tehnică. Cerințe pentru conținut și design;
• GOST 34.602-89 Tehnologia informației. Set de standarde pentru sisteme automate. Termeni de referință pentru crearea unui sistem automatizat.

O definiție mult mai bună este prezentată pe Wikipedia (deși despre specificațiile tehnice în general, și nu doar pentru software): „ Sarcina tehnică- acesta este documentul original de proiectare tehnic obiect. Sarcina tehnică stabilește scopul principal al obiectului în curs de dezvoltare, caracteristicile tehnice și tactico-tehnice ale acestuia, indicatorii de calitate și cerințele tehnice și economice, instrucțiunile de parcurgere a etapelor necesare realizării documentației (proiectare, tehnologică, software etc.) și alcătuirea acestuia, ca precum și cerințe speciale. O sarcină ca document inițial pentru crearea a ceva nou există în toate domeniile de activitate, care diferă în nume, conținut, ordine de execuție etc. (de exemplu, o sarcină de proiectare în construcție, o sarcină de luptă, teme pentru acasă, un contract pentru o operă literară etc.). d.)"

Și astfel, după cum reiese din definiție, scopul principal al Specificației tehnice este de a formula cerințele pentru obiectul care se dezvoltă, în cazul nostru, pentru un sistem automatizat.

Este principalul, dar singurul. A sosit momentul să ajungem la principalul lucru: să punem totul „pe rafturi”, așa cum am promis.

Ce trebuie să știți despre cerințe? Este necesar să înțelegeți clar că toate cerințele trebuie împărțite în funcție de tip și proprietăți. Acum vom învăța cum să facem asta. Pentru a separa cerințele după tip, GOST ne va ajuta. Lista de tipuri de cerințe care este prezentată acolo este un bun exemplu al tipurilor de cerințe care trebuie luate în considerare. De exemplu:

• Cerințe de funcționalitate;
• Cerințe de securitate și drepturi de acces;
• Cerințe pentru calificarea personalului;
• …. etc. Puteți citi despre ele în GOST menționat (și mai jos le voi privi și eu puțin mai detaliat).

Cred că este evident pentru dumneavoastră că factorul cheie într-o specificație tehnică de succes este exact cerințele de funcționalitate bine formulate. Majoritatea lucrărilor și metodelor despre care am vorbit sunt dedicate acestor cerințe. Cerințele de funcționalitate reprezintă 90% din complexitatea muncii de dezvoltare a Termenilor de referință. Orice altceva este adesea un „camuflaj” care acoperă aceste cerințe. Dacă cerințele sunt formulate prost, atunci indiferent ce camuflaj frumos le-ați pune, un proiect de succes nu va ieși. Da, în mod oficial vor fi îndeplinite toate cerințele (conform GOST J), specificația tehnică a fost elaborată, aprobată și semnată și s-au primit bani pentru aceasta. Si ce? Și apoi începe partea cea mai interesantă: ce să faci? Dacă acesta este un proiect privind Ordinul de stat, atunci nu există probleme - bugetul este astfel încât să nu intre în buzunarul nimănui, iar în timpul procesului de implementare (dacă există unul) totul va fi clarificat. Exact așa sunt cheltuite majoritatea bugetelor proiectelor pentru comenzi de stat (au mâzgălit „TZ”, au pierdut zeci de milioane, dar nu au făcut proiectul. Toate formalitățile au fost respectate, nu au existat părți vinovate, o mașină nouă este în apropierea casa.Frumusete!). Dar vorbim de organizații comerciale în care se numără banii și este nevoie de un alt rezultat. Prin urmare, să înțelegem principalul lucru, cum să ne dezvoltăm Utile si functionale Specificatii tehnice.

Am spus despre tipurile de cerințe, dar cum rămâne cu proprietățile? Dacă tipurile de cerințe pot fi diferite (în funcție de obiectivele proiectului), atunci cu proprietăți totul este mai simplu, există 3 dintre ele:

1. Cerința trebuie să fie de inteles;
2. Cerința trebuie să fie specific;
3. Cerința trebuie să fie examinatorii;

Mai mult, ultima proprietate este imposibilă fără cele două anterioare, adică. este un fel de „test de turnesol”. Dacă rezultatul unei cerințe nu poate fi testat, înseamnă că este fie neclar, fie nespecific. Gandeste-te la asta. În stăpânirea acestor trei proprietăți ale cerințelor stau măiestria și profesionalismul. De fapt, este foarte simplu. Când îți dai seama.

Aceasta încheie povestea despre ce este o specificație tehnică și trece la principalul lucru: cum să formulezi cerințele. Dar nu este atât de rapid. Mai este un punct extrem de important:

• În ce limbă (din punct de vedere al dificultății de înțelegere) trebuie scrisă specificația tehnică?
• Ar trebui să descrie specificațiile diferitelor funcții, algoritmi, tipuri de date și alte lucruri tehnice?
• Ce este designul tehnic, care, apropo, este menționat și în GOST și cum este legat de specificațiile tehnice?

Există un lucru foarte insidios ascuns în răspunsurile la aceste întrebări. De aceea apar adesea dispute cu privire la suficiența sau lipsa detalierii necesare a cerințelor, despre înțelegerea documentului de către Client și Antreprenori, despre redundanță, format de prezentare etc. Unde este linia dintre Termenii de Referință și Proiectul Tehnic?

Sarcina tehnică- acesta este un document bazat pe cerințe formulate într-o limbă care este pe înțelesul (obișnuit, familiar) Clientului. În acest caz, terminologia industrială care este pe înțelesul Clientului poate și ar trebui utilizată. Nu ar trebui să existe conexiuni cu specificul implementării tehnice. Acestea. la etapa de specificare tehnică, în principiu, nu contează pe ce platformă vor fi implementate aceste cerințe. Deși există și excepții. Dacă vorbim despre implementarea unui sistem bazat pe un produs software deja existent, atunci o astfel de legătură poate avea loc, dar numai la nivel de formulare de ecran, formulare de raport etc. Clarificarea și formularea cerințelor, precum și dezvoltarea termenilor de referință ar trebui să fie îndeplinite analist de afaceri.Și cu siguranță nu un programator (cu excepția cazului în care combină aceste roluri, asta se întâmplă). Acestea. această persoană trebuie să vorbească cu Clientul în limba afacerii sale.

Proiect tehnic- acesta este un document care este destinat implementarii tehnice a cerintelor formulate in Termenii de Referinta. Acest document descrie structuri de date, declanșatoare și proceduri stocate, algoritmi și alte lucruri care vor fi necesare specialisti tehnici. Clientul nu trebuie să se aprofundeze deloc în acest lucru (chiar și astfel de termeni ar putea să nu fie clari pentru el). Proiectul tehnic face Arhitect de sistem(combinarea acestui rol cu ​​un programator este destul de normală). Sau mai bine zis, un grup de specialiști SA condus de un arhitect. Cu cât proiectul este mai mare, cu atât mai mulți oameni lucrează la Termenii de referință.

Ce avem în practică? Este amuzant să urmărești când directorului i se prezintă o specificație tehnică pentru aprobare, care este plină cu terminologie tehnică, descrieri ale tipurilor de date și valorile acestora, structura bazei de date etc. El, desigur, încearcă să înțeleagă, deoarece trebuie să aprobe , încercând să găsească cuvinte familiare între rânduri și să nu piardă cerințele lanțului de afaceri. Este aceasta o situație familiară? Și cum se termină? De regulă, astfel de specificații tehnice sunt aprobate, apoi implementate și, în 80% din cazuri, atunci nu corespund deloc faptului lucrării efectuate, deoarece au decis să schimbe, să refacă multe lucruri, au înțeles greșit, au gândit greșit etc. și așa mai departe. Și apoi începe seria despre depunerea lucrărilor. „Dar aici nu este ceea ce avem nevoie”, ci „acest lucru nu va funcționa pentru noi”, „acest lucru este prea complicat”, „acest lucru este incomod,” etc. Suna familiar?!! Asta îmi este familiar, a trebuit să lovesc denivelările la timp.

Deci, ce avem în practică? Dar, în practică, avem o graniță neclară între termenii de referință și proiectul tehnic. Ea plutește între TK și TP într-o varietate de manifestări. Și asta e rău. Acest lucru se întâmplă deoarece cultura dezvoltării a devenit slabă. Acest lucru se datorează parțial competențelor specialiștilor, parțial din cauza dorinței de a reduce bugetele și termenele limită (la urma urmei, documentarea necesită mult timp - acesta este un fapt). Există un alt factor important care influențează utilizarea Proiectului tehnic ca document separat: dezvoltarea rapidă a instrumentelor de dezvoltare rapidă, precum și a metodologiilor de dezvoltare. Dar aceasta este o poveste separată; voi spune câteva cuvinte despre ea mai jos.

Un alt punct mic, dar important. Uneori, Termenii de referință sunt numiți o mică parte de cerințe, simple și de înțeles. De exemplu, îmbunătățiți căutarea unui obiect în funcție de anumite condiții, adăugați o coloană la raport etc. Această abordare este destul de justificată, de ce vă complicați viața. Dar nu este folosit pentru proiecte mari, ci pentru îmbunătățiri minore. Aș spune că acest lucru este mai aproape de întreținerea produsului software. În acest caz, Termenii de referință pot descrie și o soluție tehnică specifică pentru implementarea cerinței. De exemplu, „Efectuați cutare sau cutare modificare la un astfel de algoritm”, indicând o procedură specifică și o modificare specifică pentru programator. Acesta este cazul când granița dintre Termenii de referință și Proiectele tehnice este complet ștearsă, deoarece nu există fezabilitate economică de a umfla documentele acolo unde nu este nevoie, dar se creează un document util. Și este corect.

Este deloc necesară specificația tehnică? Dar proiectul tehnic?

Mă supraîncălzim? Este posibil acest lucru fără niciunul? Specificatii tehnice? Imaginați-vă că este posibil (sau mai bine zis, este posibil), iar această abordare are mulți adepți, iar numărul lor este în creștere. De regulă, după ce tinerii specialiști au citit cărți despre Scrum, Agile și alte tehnologii de dezvoltare rapidă. De fapt, acestea sunt tehnologii minunate și funcționează, dar nu spun literal „nu trebuie să faci sarcini tehnice”. Ei spun „un minim de documente”, mai ales cele inutile, mai aproape de Client, mai multe detalii și rezultate mai rapide. Dar nimeni nu a anulat înregistrarea cerințelor, iar acest lucru este clar menționat acolo. Acolo sunt stabilite cerințele pe baza celor trei proprietăți remarcabile pe care le-am menționat mai sus. Doar că mințile unor oameni sunt structurate în așa fel încât, dacă ceva poate fi simplificat, atunci să simplificăm până la punctul de absență completă. Cum spunea Einstein: Fă-l cât mai simplu posibil, dar nu mai simplu decât atât.” . Acestea sunt cuvinte de aur care merg cu totul. Asa de Sarcina tehnică necesar, altfel nu veți vedea un proiect de succes. O altă întrebare este cum să-l compune și ce să includă acolo. În lumina metodologiilor de dezvoltare rapidă, trebuie să vă concentrați numai pe cerințe, iar toate „camuflajul” pot fi aruncate. În principiu, sunt de acord cu asta.

Dar proiectul tehnic? Acest document este foarte util și nu și-a pierdut relevanța. În plus, de multe ori pur și simplu nu poți face fără ea. Mai ales când vine vorba de externalizarea activității de dezvoltare, de ex. pe principiul externalizării. Dacă nu faci asta, riști să înveți multe despre cum ar trebui să arate sistemul pe care îl ai în minte. Ar trebui clientul să se familiarizeze cu acesta? Dacă dorește, de ce nu, dar nu este nevoie să insiste și să aprobe acest document, acesta doar va reține și va interfera cu munca. Este aproape imposibil să proiectezi un sistem până la cel mai mic detaliu. În acest caz, va trebui să faceți continuu modificări în Designul tehnic, ceea ce necesită mult timp. Și dacă organizația este puternic birocratică, atunci îți vei lăsa toți nervii acolo. Reducerea acestui tip de design este exact ceea ce se referă la metodologiile moderne de dezvoltare rapidă pe care le-am menționat mai sus. Apropo, toate se bazează pe clasicul XP (programare extremă) - o abordare care are deja aproximativ 20 de ani. Așadar, faceți o specificație tehnică de înaltă calitate, care să fie înțeleasă de client și utilizați proiectul tehnic ca document intern pentru relația dintre arhitectul de sistem și programatori.

Un detaliu interesant despre proiectarea tehnică: unele instrumente de dezvoltare concepute pe principiul proiectării orientate pe subiect (cum ar fi 1C și similare) presupun că proiectarea (adică procesul de documentare) este necesară doar în zone cu adevărat complexe în care este necesară interacțiunea între subsisteme întregi. În cel mai simplu caz, de exemplu, crearea unui director sau document, sunt suficiente doar cerințele de afaceri formulate corect. Acest lucru este evidențiat și de strategia de afaceri a acestei platforme în ceea ce privește formarea specialiștilor. Dacă te uiți la carnetul de examen al unui specialist (așa se numește, nu un „programator”), vei vedea că există doar cerințe de afaceri și cum să le implementezi într-un limbaj de program este sarcina specialistului. Acestea. acea parte a problemei pe care Proiectul Tehnic își propune să o rezolve, specialistul trebuie să o rezolve „în cap” (vorbim de sarcini de complexitate medie), aici și acum, urmând anumite standarde de dezvoltare și proiectare, care din nou sunt formate din compania 1C pentru platforma sa. Astfel, dintre doi specialiști ale căror rezultate la muncă par identice, unul poate promova examenul, dar celălalt nu poate, deoarece a încălcat în mod flagrant standardele de dezvoltare. Adică, se presupune în mod evident că specialiștii trebuie să aibă astfel de calificări încât să poată proiecta sarcini tipice în mod independent, fără implicarea arhitecților de sistem. Și această abordare funcționează.

Să continuăm să studiem întrebarea: „Ce cerințe ar trebui incluse în Termenii de referință?”

Formularea cerinţelor pentru sistemul informaţional. Structura termenilor de referință

Să fim clari imediat: vom vorbi în mod specific despre formularea cerințelor pentru un sistem informațional, adică. presupunând că munca de dezvoltare a cerințelor de afaceri, formalizarea proceselor de afaceri și toate lucrările anterioare de consultanță au fost deja finalizate. Desigur, în această etapă pot fi făcute unele precizări, dar doar clarificări. Proiectul de automatizare în sine nu rezolvă problemele de afaceri - rețineți acest lucru. Aceasta este o axiomă. Din anumite motive, unii manageri încearcă să o infirme, crezând că dacă vor cumpăra programul, ordinea va ajunge la o afacere haotică. Dar o axiomă este doar o axiomă; nu necesită dovezi.

Ca orice activitate, formularea cerințelor poate (și ar trebui) să fie împărțită în etape. Toate la timpul lor. Aceasta este o muncă intelectuală grea. Și, dacă îl tratați cu o atenție insuficientă, atunci rezultatul va fi potrivit. Conform estimărilor experților, costul dezvoltării Termenilor de referință poate fi de 30-50%. Eu sunt de aceeasi parere. Deși 50 este poate prea mult. Până la urmă, Specificația tehnică nu este ultimul document care trebuie elaborat. La urma urmei, trebuie să existe și design tehnic. Această variație se datorează diferitelor platforme de automatizare, abordări și tehnologii utilizate de echipele de proiect în timpul dezvoltării. De exemplu, dacă vorbim despre dezvoltarea într-un limbaj clasic precum C++, atunci designul tehnic detaliat este indispensabil. Dacă vorbim despre implementarea unui sistem pe platforma 1C, atunci situația cu designul este oarecum diferită, așa cum am văzut mai sus (deși, la dezvoltarea unui sistem de la zero, acesta este proiectat după schema clasică).

Deși declarația cerințelor este partea principală Specificatii tehnice, iar în unele cazuri devine singura secțiune a specificațiilor tehnice, ar trebui să acordați atenție faptului că acesta este un document important și ar trebui întocmit în consecință. Unde sa încep? În primul rând, trebuie să începeți cu conținutul. Scrieți conținutul și apoi începeți să-l extindeți. Personal, fac asta: mai întâi schițez conținutul, descriu obiectivele, toate informațiile introductive și apoi cobor la partea principală - formularea cerințelor. De ce nu invers? Nu stiu, imi este mai convenabil. În primul rând, aceasta este o parte mult mai mică a timpului (comparativ cu cerințele) și, în al doilea rând, în timp ce descrieți toate informațiile introductive, vă conectați la lucrul principal. Ei bine, cui îi place. În timp, veți dezvolta propriul șablon de specificații tehnice. Pentru început, recomand să luați ca conținut exact cel descris în GOST. Este perfect pentru conținut! Apoi luăm și începem să descriem fiecare secțiune, fără a uita de recomandările următoarelor trei proprietăți: înțelegere, specificitate și testabilitate. De ce insist atât de mult pe asta? Mai multe despre asta în secțiunea următoare. Și acum îmi propun să trec prin acele puncte ale specificațiilor tehnice care sunt recomandate în GOST.

1. Informații generale;
2. scopul și scopurile creării (dezvoltării) sistemului;
3. caracteristicile obiectelor de automatizare;
4. Cerințe de sistem;
5. compoziția și conținutul lucrării pentru a crea sistemul;
6. procedura de control și acceptare a sistemului;
7. cerințe pentru compoziția și conținutul lucrării pentru pregătirea obiectului de automatizare pentru punerea în funcțiune a sistemului;
8. cerințe de documentare;
9. sursele de dezvoltare.

În total, 9 secțiuni, fiecare dintre acestea fiind, de asemenea, împărțită în subsecțiuni. Să le privim în ordine. Pentru comoditate, voi prezenta totul sub forma unui tabel pentru fiecare articol.

Secțiunea 1. informații generale.

Recomandări conform GOST
numele complet al sistemului și simbolul acestuia;	Totul este clar aici: scriem cum se va numi sistemul, numele scurt
codul subiectului sau codul (numărul) contractului;	Acest lucru nu este relevant, dar îl puteți specifica dacă este necesar
numele întreprinderilor (asociațiilor) dezvoltatorului și clientului (utilizatorului) sistemului și detaliile acestora;	indicați cine (ce organizații) va lucra la proiect. De asemenea, puteți specifica rolurile lor. Puteți chiar să eliminați această secțiune (destul de formală).
o listă a documentelor pe baza cărora este creat sistemul, de către cine și când au fost aprobate aceste documente;	Informații utile. Aici ar trebui să indicați documentația de reglementare și de referință care v-a fost furnizată pentru a vă familiariza cu o anumită parte a cerințelor
datele planificate de început și de sfârșit pentru lucrările de creare a sistemului;	Solicitări de cronometrare. Uneori ei scriu despre acest lucru în specificațiile tehnice, dar mai des astfel de lucruri sunt descrise în contractele de muncă
informatii despre sursele si procedura de finantare a lucrarii;	La fel ca în paragraful anterior despre termene limită. Mai relevante pentru ordinele guvernamentale (pentru angajații de stat)
procedura de înregistrare și prezentare către client a rezultatelor lucrărilor de creare a sistemului (părțile sale), de producere și reglare a mijloacelor individuale (hardware, software, informații) și a complexelor software și hardware (software și metodologice) ale sistem.	Nu văd necesitatea acestui punct, pentru că... Cerințele de documentare sunt stabilite separat și, în plus, există o secțiune separată completă „Procedura de control și acceptare” a sistemului.

Secțiunea 2. scopul și scopurile creării (dezvoltării) sistemului.

Recomandări conform GOST	Ce să faci în practică
Scopul sistemului	Pe de o parte, scopul este simplu. Dar este recomandabil să-l formulezi în mod specific. Dacă scrieți ceva de genul „automatizarea de înaltă calitate a contabilității de depozit în compania X”, atunci puteți discuta rezultatul mult timp după finalizarea acestuia, chiar și indiferent de formularea bună a cerințelor. Deoarece Clientul poate spune întotdeauna că prin calitate a vrut să spună altceva. În general, vă puteți strica nervii unul altuia, dar de ce? Este mai bine să scrieți imediat ceva de genul: „Sistemul este conceput pentru a menține înregistrările depozitului în compania X în conformitate cu cerințele specificate în această specificație tehnică”.
Obiectivele creării sistemului	Golurile sunt cu siguranță o secțiune importantă. Dacă vrem să-l includem, atunci trebuie să fim capabili să formulăm aceste obiective. Dacă aveți dificultăți în formularea obiectivelor, atunci este mai bine să excludeți cu totul această secțiune. Un exemplu de obiectiv nereușit: „Asigurați-vă că managerul completează documentele rapid.” Ce este rapid? Acest lucru poate fi apoi dovedit la nesfârșit. Dacă acest lucru este important, atunci este mai bine să reformulați acest obiectiv după cum urmează: „Directorul de vânzări ar trebui să poată emite un document „Vânzări de mărfuri” de 100 de rânduri în 10 minute.” Un astfel de obiectiv ar putea apărea dacă, de exemplu, un manager petrece în prezent aproximativ o oră pentru asta, ceea ce este prea mult pentru acea companie și este important pentru ei. În această formulare, scopul se intersectează deja cu cerințele, ceea ce este destul de firesc, deoarece atunci când extindem arborele obiectivelor (adică, împărțirea lor în obiective mai mici conexe), ne vom apropia deja de cerințe. Prin urmare, nu ar trebui să te lași dus.

În general, capacitatea de a identifica obiective, de a le formula și de a construi un arbore de obiective este un subiect complet separat. Amintește-ți principalul lucru: dacă știi cum, scrie, dacă nu ești sigur, nu scrie deloc. Ce se întâmplă dacă nu formulezi obiective? Vei lucra conform cerințelor, asta se practică adesea.

Secțiunea 3. Caracteristicile obiectelor de automatizare.

Secțiunea 4. Cerințe de sistem

GOST descifrează lista de astfel de cerințe:

• cerințe pentru structura și funcționarea sistemului;
• cerințe privind numărul și calificarea personalului sistemului și modul de funcționare al acestora;
• indicatori de destinație;
• cerințe de fiabilitate;
• cerințe de siguranță;
• cerințe de ergonomie și estetică tehnică;
• cerințe de transportabilitate pentru difuzoarele mobile;
• cerințe pentru operarea, întreținerea, repararea și depozitarea componentelor sistemului;
• cerințe pentru protejarea informațiilor împotriva accesului neautorizat;
• cerințe pentru siguranța informațiilor în caz de accidente;
• cerințe de protecție împotriva influențelor externe;
• cerințe pentru puritatea brevetului;
• cerințe pentru standardizare și unificare;

În ciuda faptului că principala va fi cu siguranță secțiunea cu cerințe specifice (funcționale), această secțiune poate fi și ea de mare importanță (și în majoritatea cazurilor este). Ce poate fi important și util:

• Cerințe de calificare. Este posibil ca sistemul în curs de dezvoltare să necesite recalificarea specialiștilor. Aceștia pot fi atât utilizatorii viitorului sistem, cât și specialiști IT care vor fi necesari pentru a-l susține. Atenția insuficientă la această problemă se transformă adesea în probleme. Dacă calificările personalului existent sunt în mod clar insuficiente, este mai bine să specificați cerințele pentru organizarea formării, programului de formare, calendarului etc.
• Cerințe pentru protejarea informațiilor împotriva accesului neautorizat. Nu există comentarii aici. Acestea sunt tocmai cerințele pentru delimitarea accesului la date. Dacă sunt planificate astfel de cerințe, atunci ele trebuie scrise separat, cât mai detaliat posibil, conform acelorași reguli ca și cerințele funcționale (înțelegerea, specificitatea, testabilitatea). Prin urmare, aceste cerințe pot fi incluse în secțiunea cu cerințe funcționale
• Cerințe pentru standardizare. Dacă există standarde de proiectare care sunt aplicabile proiectului, acestea pot fi incluse în cerințe. De regulă, astfel de cerințe sunt inițiate de serviciul IT al Clientului. De exemplu, compania 1C are cerințe pentru proiectarea codului de program, proiectarea interfeței etc.;
• Cerințe pentru structura și funcționarea sistemului. Aici pot fi descrise cerințele pentru integrarea sistemelor între ele și este prezentată o descriere a arhitecturii generale. Mai des, cerințele de integrare sunt în general separate într-o secțiune separată sau chiar într-o specificație tehnică separată, deoarece aceste cerințe pot fi destul de complexe.

Toate celelalte cerințe sunt mai puțin importante și nu trebuie descrise. După părerea mea, fac documentația mai grea și au puține beneficii practice. Și este foarte dificil să descrii cerințele ergonomice sub formă de cerințe generale; este mai bine să le transferi la cele funcționale. De exemplu, poate fi formulată cerința „Obțineți informații despre prețul unui produs prin apăsarea unui singur buton”. În opinia mea, acesta este încă mai aproape de cerințele funcționale specifice, deși se referă la ergonomie.Cerințe pentru funcțiile (sarcinile) îndeplinite de sistem Acesta este punctul principal și cheie care va determina succesul. Chiar dacă totul este făcut perfect, iar această secțiune este „3”, atunci rezultatul proiectului va fi în cel mai bun caz „3”, sau chiar proiectul va eșua cu totul. De asta ne vom ocupa mai detaliat în al doilea articol, care va fi inclus în numărul 5 al newsletter-ului. În acest punct se aplică „regula celor trei proprietăți ale cerințelor” despre care am vorbit. Cerințe pentru tipurile de garanții.

GOST identifică următoarele tipuri:

• Matematic
• Informațional
• Lingvistic
• Software
• Tehnic
• Metrologic
• organizatoric
• Metodic
• si altii…

La prima vedere, aceste cerințe pot părea neimportante. În majoritatea proiectelor acest lucru este adevărat. Dar nu in totdeauna. Când să descriem aceste cerințe:

• Nu s-au luat decizii asupra limbii (sau platformei) care se va realiza;
• Sistemul necesită o interfață multilingvă (de exemplu, rusă/engleză)
• Pentru ca sistemul să funcționeze, trebuie creată o unitate separată sau trebuie angajați noi angajați;
• Pentru ca sistemul să funcționeze, Clientul trebuie să sufere modificări ale metodelor de lucru și aceste modificări trebuie specificate și planificate;
• Se așteaptă integrarea cu orice echipament și îi sunt impuse cerințe (de exemplu, certificare, compatibilitate etc.)
• Sunt posibile și alte situații, totul depinde de obiectivele specifice ale proiectului.

Secțiunea 5. Compoziția și conținutul lucrării pentru crearea sistemului

Secțiunea 6. Procedura de control și acceptare a sistemului

Cerințe generale pentru acceptarea lucrărilor pe etape (lista întreprinderilor și organizațiilor participante, locul și calendarul), procedura de coordonare și aprobare a documentației de acceptare; vă recomand cu tărie să vă asumați responsabilitatea pentru procedura de depunere a lucrărilor și verificarea sistemului. Tocmai de aceea sunt necesare cerințe testabile, dar chiar și prezența cerințelor testabile poate să nu fie suficientă atunci când sistemul este livrat dacă procedura de acceptare și transfer al lucrării nu este clar precizată. De exemplu, o capcană obișnuită: sistemul este construit și este pe deplin operațional, dar Clientul din anumite motive nu este pregătit să lucreze în el. Aceste motive pot fi oricare: fără timp, obiectivele s-au schimbat, cineva a renunțat etc. Și el spune: „Din moment ce nu lucrăm încă în noul sistem, înseamnă că nu putem fi siguri că funcționează.” Așadar, învață să identifici corect etapele de lucru și cum să verifici rezultatele acestor etape. Mai mult, astfel de metode trebuie să fie clare pentru Client încă de la început. Dacă sunt fixate la nivelul Specificațiilor tehnice, atunci puteți oricând să apelați la ele dacă este necesar și să finalizați munca cu transferul.

Secțiunea 7. Cerințe pentru compoziția și conținutul lucrării pentru pregătirea obiectului de automatizare pentru punerea în funcțiune a sistemului

Pot exista și alte reguli de introducere a informațiilor adoptate de companie (sau planificate). De exemplu, informațiile despre un contract erau introduse ca șir de text sub orice formă, dar acum sunt necesare un număr separat, o dată separată etc. Pot exista o mulțime de astfel de condiții. Unele dintre ele pot fi percepute cu rezistență din partea personalului, așa că este mai bine să înregistrați toate astfel de cazuri la nivelul cerințelor pentru ordinea introducerii datelor.Modificări care trebuie făcute în obiectul de automatizare

Crearea conditiilor de functionare a obiectului de automatizare, in care sa fie garantata conformitatea sistemului creat cu cerintele cuprinse in specificatiile tehnice.Orice modificari care pot fi necesare. De exemplu, compania nu are o rețea locală, o flotă de calculatoare învechită pe care sistemul nu va funcționa.

Poate că unele informații necesare au fost procesate pe hârtie, iar acum trebuie introduse în sistem. Dacă nu faceți acest lucru, atunci un modul nu va funcționa, etc.

Poate că ceva a fost simplificat, dar acum trebuie luat în considerare mai detaliat, așa că cineva trebuie să colecteze informații în conformitate cu anumite reguli.

Această listă poate fi lungă, uitați-vă la cazul specific al proiectului dvs. Crearea de departamente și servicii necesare funcționării sistemului;

Timpul și procedura pentru personal și formare Am vorbit deja despre acest lucru mai devreme. Poate că sistemul este dezvoltat pentru o nouă structură sau tip de activitate care nu exista înainte. Dacă nu există personal adecvat și chiar instruit, sistemul nu va funcționa, indiferent cât de competent este construit.

Secțiunea 8. Cerințe de documentare

Luați în considerare modul în care vor fi prezentate manualele de utilizare.

Poate că Clientul a acceptat standardele corporative, ceea ce înseamnă că trebuie să ne referim la ele.

Ignorarea cerințelor de documentare de foarte multe ori duce la cele mai neașteptate consecințe asupra proiectelor. De exemplu, totul este făcut și totul funcționează. Utilizatorii știu și cum să lucreze. Nu a existat niciun acord sau conversație despre documentare. Și brusc, la predarea lucrării, unul dintre managerii de vârf ai Clientului, care nici măcar nu a participat la proiect, dar este implicat în acceptarea lucrării, vă întreabă: „Unde sunt manualele de utilizare?” Și începe să vă convingă că nu a fost nevoie să fiți de acord cu disponibilitatea manualelor de utilizare, acest lucru se presupune că este „desigur” implicit. Și asta este, nu vrea să-ți ia slujba. Pe cheltuiala cui vei elabora liniile directoare? Multe echipe s-au îndrăgostit deja de acest cârlig.

Secțiunea 9. Surse de dezvoltare

Recomandări conform GOST	Ce să faci în practică
Trebuie enumerate documentele și materialele informative (studii de fezabilitate, rapoarte privind lucrările de cercetare finalizate, materiale informative privind sistemele analogice interne și străine etc.) pe baza cărora au fost elaborate specificațiile tehnice și care ar trebui utilizate la crearea sistemului.	Sincer să fiu, acesta este mai aproape de versuri. Mai ales când se vorbește despre efectul economic și despre alte lucruri aproape imposibil de calculat în mod obiectiv. Acestea. Desigur, va fi mai probabil pe hârtie, pur teoretic.

Prin urmare, este mai bine să vă referiți pur și simplu la raportul sondajului și la cerințele persoanelor cheie.

Și astfel, am luat în considerare toate secțiunile care pot fi incluse în Termenii de referință. „Poate” și nu „Trebuie” tocmai pentru că orice document trebuie dezvoltat pentru a obține un rezultat. Prin urmare, dacă este evident pentru dvs. că o anumită secțiune nu vă va aduce mai aproape de rezultat, atunci nu aveți nevoie de el și nu trebuie să pierdeți timpul cu ea.

Dar nicio specificație tehnică competentă nu poate face fără principalul lucru: cerințele funcționale. Aș dori să observ că în practică apar astfel de Specificații tehnice și cum! Există oameni care vor putea separa apele în toate secțiunile, vor descrie cerințele generale în termeni generali, iar documentul se dovedește a fi foarte greu și există o mulțime de cuvinte inteligente în el și chiar și Clientului i-ar putea plăcea aceasta (adică o va aproba). Dar s-ar putea să nu funcționeze conform acesteia, de exemplu. Are puțină utilizare practică. În cele mai multe cazuri, astfel de documente se nasc atunci când trebuie să obțineți o mulțime de bani special pentru Termenii de referință, dar trebuie făcut rapid și fără să vă scufundați în detalii. Și mai ales dacă se știe că problema nu va merge mai departe sau o vor face oameni complet diferiți. În general, doar pentru a gestiona bugetul, în special bugetul de stat.

În al doilea articol vom vorbi doar despre secțiunea 4 „Cerințe de sistem”, și în mod specific vom formula cerințe din motive de claritate, specificitate și testabilitate.

De ce cerințele trebuie să fie clare, specifice și testabile.

Pentru că practica arată: la început, majoritatea specificațiilor tehnice care sunt elaborate de specialiști fie se dovedesc a nu fi solicitate (nu corespund realității), fie devin o problemă pentru cel care trebuie să le implementeze, deoarece Clientul începe să manipuleze termenii și cerințele vagi. Voi da câteva exemple despre ce fraze au fost întâlnite, la ce a condus acest lucru, apoi voi încerca să dau recomandări despre cum să evit astfel de probleme.

Tipul de cerință

Formulare incorectă

Termenii de referință sunt materialul sursă pentru crearea unui sistem informatic sau a altui produs. Prin urmare, specificația tehnică (abreviată ca TK) trebuie să conțină în primul rând cerințele tehnice de bază pentru produs și să răspundă la întrebarea ce ar trebui să facă acest sistem, cum să funcționeze și în ce condiții.

De regulă, etapa de elaborare a specificațiilor tehnice este precedată de o cercetare a domeniului subiectului, care se încheie cu realizarea unui raport analitic. Raportul analitic (sau nota analitică) constituie baza documentului Termenilor de referință.

Dacă raportul poate prezenta cerințele clientului în termeni generali și le poate ilustra cu diagrame UML, specificațiile tehnice ar trebui să descrie în detaliu toate cerințele funcționale și ale utilizatorului pentru sistem. Cu cât specificațiile tehnice sunt mai detaliate, cu atât vor apărea mai puține situații controversate între client și dezvoltator în timpul testelor de acceptare.

Astfel, specificația tehnică este un document care permite atât dezvoltatorului, cât și clientului să prezinte produsul final și să verifice ulterior respectarea cerințelor.

Standardele directoare pentru scrierea specificațiilor tehnice sunt GOST 34.602.89 „Specificații tehnice pentru crearea unui sistem automat” și GOST 19.201-78 „Specificații tehnice. Cerințe pentru conținut și design.” Primul standard este destinat dezvoltatorilor de sisteme automate, al doilea pentru software (am discutat despre diferența dintre aceste serii în articolul „Ce este GOST”).

Deci, mai jos vă prezentăm o listă și o descriere a secțiunilor pe care trebuie să le conțină specificațiile tehnice în conformitate cu GOST.

GOST 19.201-78 Specificații tehnice. Cerințe pentru conținut și design	GOST 34.602.89 Specificații tehnice pentru crearea unui sistem automatizat
1. Introducere	1. Informații generale
2. Motive de dezvoltare
3. Scopul dezvoltării	2. Scopul și scopurile creării sistemului
	3. Caracteristicile obiectului de automatizare
4. Cerințe pentru un program sau un produs software	4. Cerințe de sistem
4.1. Cerințe funcționale	4.2. Cerințe pentru funcțiile (sarcinile) îndeplinite de sistem
	4.1. Cerințe pentru sistemul în ansamblu
	4.1.1. Cerințe pentru structura și funcționarea sistemului
	4.1.3. Indicatori de destinație
4.2. Cerințe de fiabilitate	4.1.4. Cerințe de fiabilitate
	4. 1.5. Cerințe de securitate
	4. 1.6. Cerințe de ergonomie și estetică tehnică
4.3. termeni de utilizare	4.1.2. Cerințe privind numărul și calificarea personalului sistemului și modul de funcționare al acestora
	4. 1.9. Cerințe pentru protejarea informațiilor împotriva accesului neautorizat
	4. 1.10. Cerințe privind siguranța informațiilor în caz de accidente
	4. 1.11. Cerințe de protecție împotriva influențelor externe
	4. 1.12. Cerințe pentru puritatea brevetului
	4. 1.13. Cerințe pentru standardizare și unificare
4.4. Cerințe pentru compoziția și parametrii mijloacelor tehnice	4. 1.8. Cerințe pentru operarea, întreținerea, repararea și depozitarea componentelor sistemului
4.5. Cerințe pentru informații și compatibilitate software
4.6. Cerințe de etichetare și ambalare
4.7. Cerințe de transport și depozitare	4. 1.7. Cerințe de transportabilitate pentru sistemele mobile
4.8. Cerinte speciale	4. 1.14. Cerințe suplimentare
	4.3. Cerințe pentru tipurile de garanții
5. Cerințe pentru documentația programului	8. Cerințe de documentare
6. Indicatori tehnico-economici
7. Etape și etape de dezvoltare	5. Compoziția și conținutul lucrării pentru crearea sistemului
8. Procedura de control si acceptare	6. Procedura de control și acceptare a sistemului
	7. Cerințe privind compoziția și conținutul lucrării de pregătire a obiectului de automatizare pentru punerea în funcțiune a sistemului
	9.Surse de dezvoltare

Deci, documentul Specificații tehnice ar trebui, de fapt, să reflecte toate cerințele pentru produsul proiectat, identificate în etapa cercetării analitice a obiectului de automatizare.

Pe baza tabelului de mai sus, putem evidenția principalele secțiuni ale specificațiilor tehnice:

• Informații generale despre sistem (program);
• Scopul, scopurile și obiectivele sistemului (programului);
• Cerințe de sistem (cerințe funcționale, cerințe ale utilizatorului, cerințe pentru sistem în ansamblu etc.);
• Cerințe pentru tipurile de securitate;
• Cerințe de documentare;
• Etape și stadii de dezvoltare;
• Procedura de control și acceptare a sistemului (programului).

Informații generale
Această secțiune a documentului de specificații tehnice trebuie să conțină numele complet al sistemului și toate abrevierile care vor fi utilizate în elaborarea documentației.

Exemplu:

„În acest document, sistemul informațional creat se numește „Fereastra unică pentru acces la resursele educaționale”, prescurtat ca EO.
Sistemul de fereastră unică pentru acces la resursele educaționale poate fi denumit „Greșa unică sau sistem” mai târziu în acest document.”

Tot aici ar trebui să includeți subsecțiuni care oferă detalii despre organizațiile implicate în dezvoltare (Client și Antreprenor).

Subsecțiunea „Baze de dezvoltare” a documentului Specificații tehnice enumeră principalele documente pe baza cărora se realizează această lucrare. De exemplu, pentru un sistem comandat de Guvernul unei țări sau alt organism guvernamental, trebuie specificate legile, decretele și reglementările Guvernului.

O parte integrantă a documentului cu specificațiile tehnice ar trebui să fie și o listă de termeni și abrevieri. Este mai bine să prezentați termenii și abrevierile sub forma unui tabel cu două coloane „Termen” și „Forma completă”.

Termenii și abrevierile sunt aranjate în ordine alfabetică. În primul rând, se obișnuiește să se descifreze termenii și abrevierile în limba rusă, apoi pe cei în limba engleză.

Scopul și scopurile creării sistemului

Această secțiune a documentului de specificații tehnice trebuie să conțină scopul și obiectivele creării sistemului.

Exemplu:

„Sistemul informațional „Fereastra unică de acces la resursele educaționale” este conceput pentru a oferi utilizatorilor informații complete, oportune și convenabile despre sistemul de învățământ al Federației Ruse și organizațiile care îndeplinesc funcția instituțiilor de învățământ.

Scopul principal al sistemului este de a crea un mediu informațional unificat și de a automatiza procesele de afaceri ale instituțiilor de învățământ din Federația Rusă.

Crearea sistemului informatic al ghișeului unic ar trebui să asigure:

• furnizarea utilizatorilor cu o gamă largă de resurse informaționale;
• creșterea nivelului de securitate a informațiilor;
• creșterea eficienței instituțiilor și departamentelor de învățământ prin optimizarea unui număr de procese de afaceri;
• creşterea eficienţei procesului de interacţiune între sistemele informaţionale şi serviciile din cadrul departamentului.

Crearea Sistemului va reduce costurile de operare ca urmare a creșterii eficienței departamentului.”

Cerințe de sistem

Această secțiune a documentului de specificații tehnice are scopul de a descrie cerințele funcționale de bază ale sistemului. Aceasta este cea mai importantă parte a specificației tehnice, deoarece va fi principalul argument al dumneavoastră în disputele cu Clientul în timpul procesului de punere în funcțiune a sistemului. Prin urmare, este necesar să abordăm cu multă atenție scrierea lui.

Documentul Termeni de Referință trebuie să conțină toate cerințele identificate în etapa de analiză a obiectului de automatizare. Cel mai bine este să evidențiați principalele procese de afaceri, care ar trebui dezvăluite printr-o descriere a cerințelor funcționale.

Exemplu:

„4.1 Procesul de afaceri „Oferirea de informații despre instituțiile de învățământ din Federația Rusă

Următorii participanți sunt identificați în acest proces de afaceri:

Moderator – un angajat al departamentului, parte din personalul de întreținere al Sistemului, responsabil de corectitudinea datelor furnizate

Utilizatorul este un cetățean care trebuie să primească informații despre activitatea instituțiilor de învățământ din Federația Rusă.

4.1.1 Înregistrarea unei instituții de învățământ în Sistem

Înregistrarea unei instituții de învățământ a Federației Ruse este efectuată de către angajatul responsabil al instituției („Decretul Guvernului ...”).

Procesul de înregistrare a unei instituții de învățământ include următorii pași:

• Autorul creează o înregistrare despre organizație;
• Autorul introduce datele organizației;
• Sistemul verifică o licență pentru o anumită organizație

• Dacă licența există în baza de date, Sistemul trimite un mesaj către Autor despre înregistrarea cu succes;
• Dacă licența nu este găsită în baza de date, Sistemul trimite un mesaj către Autor despre absența unei licențe pentru această organizație.”

Dacă timpul permite, informațiile furnizate în această secțiune ar trebui să fie dezvăluite mai complet în anexa la documentul Termenilor de referință. În anexa la specificațiile tehnice, puteți furniza un formular de ecran și mai jos puteți descrie toate evenimentele care sunt prezente pe acesta (creare, vizualizare, editare, ștergere etc.).

Cerințele pentru sistem în ansamblu includ o dezvăluire a arhitecturii sale cu o descriere a tuturor subsistemelor. Această parte a Termenilor de referință ar trebui să descrie cerințele pentru integrarea sistemului cu alte produse (dacă există). În plus, termenii de referință ar trebui să includă:

• cerințele pentru modurile de operare ale sistemului
• indicatori de destinație
• cerințe de fiabilitate
• cerințe de siguranță
• cerințe privind numărul și calificarea personalului și programul de lucru al acestora
• cerințele de protecție a informațiilor
• cerințe pentru siguranța informațiilor în caz de accidente
• cerințele de autorizare a brevetului
• cerințe pentru standardizare și unificare
• etc.

Cerințe pentru tipurile de garanții

Această secțiune a documentului cu specificațiile tehnice ar trebui să conțină cerințe pentru asistență matematică, informațională, lingvistică, software, tehnică și alte tipuri de suport (dacă există).

Cerințe de documentare

Secțiunea „Cerințe de documentare” a specificației tehnice include o listă de documente de proiectare și operaționale care trebuie furnizate clientului.

Această secțiune a specificației tehnice este la fel de importantă ca și descrierea cerințelor funcționale, așa că nu trebuie să vă limitați la expresia „Clientului trebuie să i se furnizeze toată documentația în conformitate cu GOST 34”. Aceasta înseamnă că trebuie să furnizați întregul pachet de documente, inclusiv „Formularul”, „Pașaportul”, etc. Majoritatea documentelor din lista specificată în GOST 34.201-89 nu sunt necesare nici dvs., nici clientului, deci este mai bine să conveniți imediat asupra listei în etapa de elaborare a documentului Specificații tehnice.

Pachetul minim de documente include de obicei:

• Sarcina tehnica;
• Declarație de proiectare preliminară (tehnică);
• Notă explicativă la Proiectul Tehnic;
• Descrierea organizării bazei de informații;
• Manualul utilizatorului;
• Ghidul Administratorului;
• Programul și metodologia de testare;
• Raport test de acceptare;
• Certificat de finalizare

Este mai bine să prezentați lista documentelor din specificațiile tehnice sub forma unui tabel, care indică numele documentului și standardul pe baza căruia ar trebui elaborat.

Etape și stadii de dezvoltare

Această secțiune a documentului Termenii de referință ar trebui să ofere informații despre toate etapele de lucru care trebuie efectuate.

Descrierea etapei ar trebui să includă numele, calendarul, descrierea lucrării și rezultatul final.

Procedura de control si acceptare a sistemului

În această secțiune a documentului Specificații tehnice, este necesar să se indice documentul pe baza căruia trebuie efectuate testele de acceptare.

Dacă este necesar, specificația tehnică poate fi completată cu alte secțiuni sau redusă prin eliminarea articolelor necorespunzătoare.

La modificarea structurii specificațiilor tehnice, pentru a evita situațiile conflictuale, aceasta trebuie convenită cu clientul înainte de elaborarea documentului.

O comandă pentru dezvoltarea unei identități corporative, design de ambalaj, logo sau site web este întotdeauna însoțită de pregătirea și executarea documentației relevante - un acord, un brief și o specificație tehnică (TOR). Crearea specificațiilor tehnice este prima etapă a colaborării dintre client și antreprenor.

Una dintre cele mai comune modalități de a reduce costurile și de a reduce bugetul proiectului este să o faci singur redactarea specificațiilor tehnice (specificații tehnice) .

Cu toate acestea, fără o anumită experiență, este destul de dificil să se întocmească o specificație tehnică competentă, care să fie înțeleasă atât de antreprenor, cât și de client.

În termenii de referință, este necesar să se descrie cu acuratețe și clar cerințele pentru obiectul de lucru, să se stabilească parametrii tehnici, scopul obiectului, să se pregătească compoziția documentației de proiectare necesare, să se determine calendarul și procedura de finalizare a lucrării.

Înainte de a începe elaborarea specificațiilor tehnice, este necesar să se efectueze cercetări, calcule preliminare și să colecteze informații inițiale.

Crearea specificațiilor tehnice este un proces complex care este mai bine lăsat pe seama profesioniștilor; în plus, „marca regală” are sarcini mai importante și prioritare decât scrierea specificațiilor tehnice.

Termenii de referință sunt

Sarcina tehnică - acesta este documentul fundamental al întregului proiect și al relației dintre client și antreprenor, care vă permite să definiți clar ordinea lucrărilor, responsabilitățile părților și calendarul proiectului.

Termenele limită de finalizare și succesul proiectului în ansamblu vor depinde de cât de corect, exact și clar sunt redactați termenii de referință pentru antreprenor.

Tipuri de specificații tehnice (specificații tehnice)

Termenii de referință sunt primul pas către implementarea oricărui proiect. Există nenumărate tipuri de specificații tehnice pentru efectuarea lucrărilor:
- termeni de referință pentru dezvoltarea site-ului web;
- termeni de referință pentru dezvoltarea logo-ului;
- termeni de referință pentru dezvoltarea programului;
- termeni de referință pentru dezvoltarea unei identități corporative;
- termeni de referință pentru dezvoltarea designului;
- termeni de referință pentru dezvoltarea denumirii companiei;
- termeni de referință pentru promovarea site-ului etc.

Indiferent de cine alegeți să realizeze proiectul - un freelancer sau o agenție de branding, înainte de a începe lucrul la proiect este necesar să analizați și să procesați volume mari de informații diverse. Studiați date privind scopurile și obiectivele proiectului, obiectivele strategice și actuale ale companiei, cerințele pentru obiectul lucrării, dorințele clientului, termenele limită de livrare a proiectului finit și rezultatele așteptate. În continuare, trebuie să colectați împreună aceste informații, să structurați datele și să le furnizați contractantului sub formă de specificații tehnice.

De regulă, elaborarea specificațiilor tehnice este sarcina managerului de proiect. Nimeni, altul decât clientul, nu poate descrie cel mai bine ideile, principiile de lucru, scopurile proiectului și activitățile companiei. Această descriere ar trebui să fie cât mai clară posibil și prezentată sub forma unei povești generale despre companie și marca acesteia.

Structura specificațiilor tehnice

Structura specificațiilor tehnice (formularul specificațiilor tehnice) este următoarea:

1. Obiectivele proiectului
Declarația de lucru trebuie să indice ce obiective dorește să atingă compania folosind rezultatele proiectului finalizat. Astfel de obiective, de exemplu, ar putea fi: lansarea unui produs nou, rebranding-ul unei companii sau mărci, desfășurarea unei campanii de publicitate etc.
2. Descrierea companiei clientului
- Domeniul de activitate si dimensiunea companiei, misiunea si pozitia acesteia pe piata;
- Descrierea portofoliului de mărci al companiei - cu ce mărci lucrează compania;
- Lista principalelor companii concurente;
- Lista principalelor avantaje competitive ale companiei și USP (propunere unică de vânzare).
3. Descrierea situației și ultimele tendințe ale pieței pentru care se dezvoltă marca
- Segmentul de preț al produsului sau serviciilor companiei;
- Portretul consumatorului (vârsta, sexul, datele geografice, nivelul social al publicului țintă);
- Obiectivele de marketing tactice si strategice ale companiei (pe o perioada de la 1 la 3 ani);
- Modelul comportamentului consumatorului și descrierea situațiilor în care consumatorul efectuează o achiziție;
- Descrierea principalelor caracteristici ale brandului existent, conceptul de pozitionare al acestuia, slogan, comunicatii de marketing, necesare in cazul rebrandingului.
4. Referințe
O listă de exemple de lucrări similare care îi plac clientului în contextul acestui proiect.
5. Cerințe
În această secțiune este necesar să se precizeze toate cerințele tehnice și funcționale ale proiectului. Precum și cerințele și dorințele clientului pentru grafică, text, culori, stil, fonturi,