Çfarë përfshin detyra teknike. Procedura për zhvillimin e specifikimeve teknike

Në termat e referencës, klienti duhet të tregojë të gjitha kërkesat e tij për objektin e propozuar të prokurimit. Veçanërisht:

Këshilla:Vlen të filloni të përgatitni termat e referencës paraprakisht. Kjo do të zvogëlojë rrezikun që të shkelet koha e publikimit të dokumentacionit të prokurimit në SIE. Në fund të fundit, shërbimit të kontratës (menaxherit të kontratës) i duhen nga disa ditë deri në disa javë për të hartuar një detyrë teknike me cilësi të lartë, në varësi të kompleksitetit teknik të objektit të prokurimit.

Këshilla: Kur hartoni një detyrë teknike, ka kuptim të udhëhiqeni nga:

• GOST. Për shembull, kur krijoni një sistem të automatizuar - GOST 34.602-89 "Teknologji informacioni. Një grup standardesh për sistemet e automatizuara. Kushtet e referencës për krijimin e një sistemi të automatizuar ";

• udhëzimet (rekomandimet) metodologjike të themeluesit. Për shembull, Ministria e Kulturës së Rusisë ka zhvilluar Udhëzime Metodologjike për zhvillimin e specifikimeve teknike për prokurimin në kuadrin e programit të synuar "Kultura e Rusisë (2012-2018)" (letër nga Ministria e Kulturës së Rusisë e datës 25 janar , 2013 Nr. 446-01-56 / 10-NM) ...

Krijimi i një detyre teknike është një detyrë krijuese që kërkon një shpenzim të mjaftueshëm kohe dhe përpjekje nga klienti. Sidoqoftë, një qasje e integruar ndaj zgjidhjes së saj, si dhe një qëndrim i vëmendshëm ndaj çdo blerjeje është kushti kryesor për një prokurim efektiv.

1. Informacion i përgjithshëm për klientin

Në këtë seksion, ia vlen të specifikoni të dhënat e mëposhtme të klientit:

• Emri;

• vendndodhjen e klientit;

• orarin.

Është e rëndësishme të tregohet vendndodhja dhe orët e punës së klientit kur, sipas kushteve të kontratës, pjesëmarrësi duhet të dorëzojë mallrat (të kryejë punë, të ofrojë shërbime) në territorin e klientit.

Gjithashtu, ky seksion mund të përfshijë informacione për prokurimin e përbashkët ose të centralizuar, si dhe për përfshirjen e një eksperti (organizate eksperte).

2. Informacione të përgjithshme rreth blerjes

Këtu vlen të theksohet:

• emri i plotë i objektit të prokurimit,

• metodën e zgjedhur për përcaktimin e furnizuesit (kontraktor, interpretues),

• burim financimi.

Ky seksion mund të përmbajë gjithashtu informacion në lidhje me termat dhe shkurtesat e përdorura në termat e referencës. Ky informacion mund të organizohet, për shembull, në formën e një tabele.

Termat dhe shkurtesat	Përkufizimi
AKTIV	Produkti softuerik “Paga-Buxhet”, i cili është objekt blerjeje
Klienti	Institucioni shtetëror "Alfa"
Ekspert	Specialist i cili ka njohuri të veçanta në fushën e kontabilitetit dhe tatimeve në sferën buxhetore, në çështjet e personelit dhe juridik, me arsim të lartë të specializuar.

3. Përshkrimi i objektit të prokurimit

Ky seksion duhet të përshkruajë sa më poshtë dhe sa më saktë që të jetë e mundur.

1. Karakteristikat cilësore, teknike dhe funksionale. Cilësia e mallrave duhet të jetë në përputhje me kërkesat ligjore dhe kushtet e kontratës.

Në këtë rast, klienti, kur përshkruan karakteristikat teknike dhe cilësore, duhet të përdorë tregues standardë (kërkesa, konventa dhe terminologji). Për ta bërë këtë, duhet të udhëhiqeni nga kërkesat e detyrueshme, në veçanti, GOST, SNiP, legjislacioni civil (nenet 469, 721 të Kodit Civil të Federatës Ruse). Për shembull, kërkesat për cilësinë e produkteve ushqimore përcaktohen në Ligjin Federal të 2 Janarit 2000 Nr. 29-FZ.

Nëse treguesit standard nuk mund të merren nga rregulloret teknike, standardet (aktet e tjera legjislative për rregullimin teknik), atëherë është e nevojshme të justifikohet përdorimi i treguesve të tjerë (kërkesat, emërtimet, terminologjia).

Këshilla: Nuk është e nevojshme të përdoren vlera të sakta të treguesve. Është më mirë t'i zëvendësoni ato me kushte me vlera maksimale dhe / ose minimale, si dhe vlera që nuk mund të ndryshojnë. Kjo do të thotë, tregues të tillë që do t'u lejojnë pjesëmarrësve të përcaktojnë nëse mallrat e blera (punët, shërbimet) plotësojnë kërkesat e përcaktuara. Për shembull, kur blini një njësi të sistemit, do të ishte më e saktë të tregoni në termat e referencës "Kapaciteti i diskut të ngurtë - jo më pak 500 GB ", jo" Kapaciteti i diskut të ngurtë - 500 GB ".

Kjo thuhet në pjesën 2 të nenit 33 të ligjit nr. 44-FZ dhe shpjegohet në letrën e Ministrisë së Zhvillimit Ekonomik të Rusisë, datë 10 dhjetor 2014 Nr. D28i-2796.

2. Karakteristikat e performancës (nëse është e nevojshme).

3. Numri i përgjithshëm i mallrave (vëllimi i punës, shërbimeve). Kur kjo nuk është e mundur, klienti mund të tregojë çmimin e një njësie pune (shërbimi).

4. Kërkesat për paketim. Kjo është një kërkesë shtesë. Në termat e referencës, mund të specifikoni, për shembull, që paketimi i mallrave duhet të sigurojë sigurinë e tij gjatë transportit dhe ruajtjes.

5. Kërkesat për sigurinë e objektit të prokurimit.

6. Kushtet dhe procedura për dorëzimin e mallrave, kryerjen e punës, ofrimin e shërbimeve. Në veçanti, është e nevojshme të përcaktohet vendi i dorëzimit të mallrave (kryerja e punës, ofrimi i shërbimeve). Në këtë rast, mund të specifikoni:

• adresa specifike e dorëzimit;

• diapazoni (alternativa) e pikave të dorëzimit, brenda të cilave pjesëmarrësi duhet të tregojë një adresë specifike në aplikacion (për shembull, brenda kufijve të Moskës).

Kjo është e nevojshme në mënyrë që gjatë paraqitjes së aplikacioneve, pjesëmarrësit të kenë një ide se ku duhet të dorëzojnë mallrat (ku të ofrojnë një shërbim ose të kryejnë punë). Më pas, kur të vendosin të paraqesin një aplikim, ata do të kuptojnë nëse do të jenë në gjendje të përmbushin porosinë në këtë vend të veçantë. Klienti, nga ana tjetër, do të mbrojë veten nga rreziku që ofertuesi fitues do të refuzojë të ekzekutojë.

7. Periudha e garancisë dhe shërbimi i garancisë(pjesa 4 e nenit 33 të ligjit nr. 44-FZ). Periudha e garancisë duhet të përcaktohet në ditë, muaj dhe vite.

Pas kësaj, është e rëndësishme të përshkruhen kushtet e shërbimit të garancisë, domethënë një listë e plotë e veprimeve nga furnizuesi (kontraktori, interpretuesi) për të ruajtur ose sjellë objektin e prokurimit në gjendjen e kërkuar nga klienti.

Për shembull, kur blini një kondicioner, ia vlen të vendosni një periudhë garancie prej të paktën dy vjetësh, gjatë së cilës furnizuesi do të jetë i detyruar të inspektojë pajisjet pa pagesë brenda tre ditëve nga momenti i zbulimit të një avarie dhe të eliminojë të identifikuarat. shkeljet në funksionimin e tij.

8. Karakteristika të tjera që janë të rëndësishme kur përshkruajnë një lloj specifik produkti, pune, shërbimi. Pra, kur blen një produkt në termat e referencës, klienti duhet të tregojë domosdoshmërisht se duhet të jetë i ri dhe i lirë nga të drejtat e palëve të treta. Kjo do të thotë, askush nuk e ka përdorur ose riparuar produktin më parë. Përndryshe, klienti rrezikon të marrë një produkt të përdorur. Kjo thuhet në pikën 7 të pjesës 1 të nenit 33 të ligjit nr. 44-FZ.

Nëse është e nevojshme, termat e referencës duhet të përfshijnë edhe kërkesa shtesë për objektin e prokurimit. Ajo mund të jetë:

• trajnimi i stafit;

• kërkesat e instalimit dhe vënies në punë;

• mirëmbajtje shërbimi;

• konformiteti me kampionin etj.

Lista e informacionit dhe kërkesave mund të ndryshojë në varësi të secilit objekt specifik të prokurimit.

Një shembull i një përshkrimi të një objekti prokurimi

Në përputhje me grafikun e Institucionit Shtetëror “Alpha”, blerja e një serie letre për pajisjet e zyrës është planifikuar për në maj 2016. Gjatë përgatitjes për ankandin elektronik, menaxheri i kontratës A.S. Glebova filloi të përgatisë dokumentacionin e prokurimit, në veçanti, të bërë detyrë teknike .

Kujdes! Informacioni në lidhje me objektin që nuk pasqyrohet në termat e referencës, pjesëmarrësi ka të drejtë të mos marrë parasysh dhe të mos përmbushë.

Nëse produkti (puna, shërbimi) i ofruar nga fituesi nuk i përshtatet klientit, por në të njëjtën kohë korrespondon me termat e referencës, ai nuk ka të drejtë të refuzojë të lidhë një kontratë.

Këshilla:Vlen të përdoret si burim informacioni:

• kontratat e lidhura më parë,

• burime të disponueshme publikisht (katalogë, lista çmimesh, broshura reklamuese, etj.),

• oferta komerciale,

• informacion nga interneti.

E gjithë kjo do të ndihmojë për të pasqyruar në termat e referencës pikërisht ato karakteristika të produktit (punës, shërbimit) që i duhen klientit.

Kujdes! Nëse klienti specifikon informacion në dokumentacionin e prokurimit që mund të çojë në një kufizim të numrit të pjesëmarrësve, atëherë do të ketë rrezik për të marrë përgjegjësi administrative. Kështu, zyrtarët (menaxheri i kontratës, punonjësit e shërbimit të kontratës) mund të gjobiten në shumën prej 1 përqind të çmimit fillestar (maksimal) të kontratës (NMCK), por jo më pak se 10,000 rubla. dhe jo më shumë se 50,000 rubla. (pjesa 4.1 e nenit 7.30 të Kodit të Kundërvajtjeve Administrative të Federatës Ruse).

Kujdes!Gjatë përshkrimit të objektit të prokurimit, është e pamundur të tregohen emrat e prodhuesve, markat tregtare, markat e shërbimit, etj. Kjo do të çojë në një kufizim të konkurrencës dhe, si rezultat, në shkelje të legjislacionit të prokurimit. Përjashtimet - termat e referencës mund të përmbajnë një përmendje të markave tregtare, nëse është e nevojshme:

• tregoni mjetet e punës të përdorura në kryerjen e punës ose shërbimeve, por jo si objekt i kontratës. Në këtë rast, një parakusht është shënimi i formulimit "ose ekuivalent";

• blini mallra të nevojshme për të bashkëvepruar me mallrat e përdorura nga klienti (për shembull, përditësimi i softuerit të instaluar);

• blini pjesë këmbimi ose materiale harxhuese për makinat dhe pajisjet e klientit.

Kjo thuhet në paragrafin 1 të pjesës 1 të nenit 33 të ligjit nr. 44-FZ.

Kujdes! Është e pamundur, në kuadrin e një blerjeje (një loti), të blini produkte të ndryshme (mallra, punë, shërbime) që nuk kanë lidhje teknologjike dhe funksionale me njëra-tjetrën. Kjo do të kufizojë numrin e pjesëmarrësve. Kështu, për shembull, në kuadrin e një blerjeje, shërbimet nuk mund të kombinohen:

• për mbrojtjen e objektit me ndihmën e alarmeve të sigurisë dhe zjarrit dhe

• për mirëmbajtjen e vetë alarmit.

FAS Rusi shpjegoi se kjo vlen për tregje të ndryshme shërbimesh. Në fund të fundit, organizatat e sigurisë, si rregull, nuk i shërbejnë alarmet. Dhe nëse shërbime të tilla përfshihen në një prokurim, kjo do të çojë në një kufizim të numrit të pjesëmarrësve.

Kjo rrjedh nga pjesa 3 e nenit 17 të Ligjit Federal të 26 korrikut 2006 Nr. 135-FZ dhe shpjegohet në letrat e Ministrisë së Zhvillimit Ekonomik të Rusisë, datë 10 mars 2015 Nr. D28i-442, FAS Rusi, datë 21 maj 2014 Nr AЦ / 20578/14 ...

Prandaj, kur planifikoni një blerje dhe hartoni dokumentacionin, klienti duhet të analizojë këtë moment dhe, nëse është e nevojshme:

• ndani blerjen në pjesë të veçanta,

• të hartojë një detyrë teknike të veçantë për çdo lot.

4. Kërkesat për furnizuesin (kontraktorin, realizuesin)

Në termat e referencës, është e nevojshme të përcaktohet kërkesa që pjesëmarrësit e prokurimit duhet të respektojnë legjislacionin rus. Ky mund të jetë, për shembull, informacion në lidhje me disponueshmërinë e një licence për një lloj të caktuar aktiviteti.

Për më tepër, në disa raste, Qeveria e Federatës Ruse mund të vendosë kërkesa shtesë për pjesëmarrësit e prokurimit, në veçanti, për disponueshmërinë e burimeve financiare dhe materiale, përvojë pune të ngjashme me objektin e kontratës (pjesa 2 e nenit 31 të ligjit Nr. 44-FZ). Pra, në dekretin e Qeverisë së Federatës Ruse të datës 4 shkurt 2015 nr. 99, ka kërkesa shtesë për pjesëmarrësit në prokurimin për punimet për ruajtjen e vendeve të trashëgimisë kulturore. Një pjesëmarrës në një prokurim të tillë duhet të japë informacion për një kontratë që ai e ka realizuar pa penalitete gjatë tre viteve të fundit. Shuma e një kontrate të tillë duhet të jetë së paku 20 për qind e QKMK-së, për lidhjen e së cilës kryhet prokurimi.

2 vota

Ditë të mbarë, të dashur lexues. Puna në një faqe interneti me një klient është gjithmonë e vështirë. Klienti, si rregull, dëshiron ose "diçka të lezetshme" ose "asgjë të pazakontë, le të jetë si gjithë të tjerët". Koncepte abstrakte, dakord. Nëse kjo është porosia juaj e parë, atëherë mund të kënaqeni edhe me fjalë të tilla: "Cool, ata më japin liri krijuese, unë mund të bëj çfarë të dua". Nga përvoja, asgjë e tillë!

Klienti ka kuptimin e tij për "cool" dhe "si gjithë të tjerët". Ju nuk mund të merrni me mend, të futeni në humor të gabuar ose klienti thjesht mund të vendosë se "për ato lloj parash, ky djalë (ose vajzë) mund të bëjë pak më shumë punë". Për të parandaluar që kjo të ndodhë, sot ne do të diskutojmë se si hartohen kushtet e referencës për zhvillimin e faqes.

Plan veprimi për të punuar me klientin

Ju gjeni një klient. Ai është gati të paguajë paratë dhe ju shkoni në punë. Ku të filloni dhe si të vazhdoni?

• Komunikimi i parë.

Pra, keni marrë informacionin fillestar: kjo mund të ndodhë personalisht (nëse i ofroni vetë shërbimet) ose me telefon (kur klienti ju gjen vetë). Le të themi se e dini se klienti dëshiron një dyqan online nga ju, dhe ai vetë zotëron një zinxhir bizhuterish. Asnjëherë mos filloni një bisedë për një faqe menjëherë. Lini një takim në mënyrë që të përgatiteni të gjithë së bashku dhe të punoni së bashku.

Mundohuni ta motivoni personin që të shikojë informacionin në një farë mënyre në mënyrë që të ketë një ide më të qartë se çfarë dëshiron nga ju.

• Përgatitja dhe përmbledhja e parë.

Shikoni faqet që mendoni se janë të përshtatshme për klientin. Shkarkoni disa shabllone dhe tregoni atyre se faqja juaj mund të duket saktësisht kështu. Sa më shumë materiale, aq më mirë. Le të keni diçka për t'i treguar klientit, çfarë të keni një ide të qartë se çfarë i pëlqen dhe çfarë jo. Shmangni konceptet abstrakte nga seria: e bukur, e përshtatshme, me cilësi të lartë. Secili ka idetë e veta për këto kategori.

Idealisht, është edhe më mirë të lini klientin për ditën me këto materiale ose t'i dërgoni ato me postë disa ditë para takimit. Edhe pse, në këtë fazë, klienti, si rregull, nuk është veçanërisht i interesuar për portalin. Ai është gati të shkurtojë barkun e së vërtetës dhe t'ju bëjë të ribërni dhe të shtoni diçka të re, por të mos diskutoni asgjë paraprakisht. Prandaj, e vetmja rrugëdalje është të pyesni sa më shumë dhe të shkruani çdo fjalë.

• Përgatitja dhe nënshkrimi i specifikimeve teknike.

Mos harroni, sa më shumë copa letre, aq më i pastër është prifti. Shkruani, kompozoni dhe nënshkruani gjithçka që mundeni me klientin. Më pas, do të keni diçka për të treguar. Në përgjithësi, kur përshkruani TK, imagjinoni menjëherë se ju dhe klienti nuk jeni dakord dhe mbroni pafajësinë tuaj në gjykatë.

Nuk po flasim për projekte super të shtrenjta dhe shpresoj që të keni fat me klientët tuaj. Por një klient i përpiktë mund t'ju prishë humorin për një kohë të gjatë. Do të dëshironi të pështyni, të hiqni dorë nga paratë, thjesht për të mos u takuar më me të. Kjo është e kuptueshme, por nëse fillimisht tregoni veten si profesionist, studioni gjithçka tërësisht dhe tregoni veten si një person i respektuar, atëherë kjo nuk do të duhet të bëhet.

Një herë isha shumë me fat. Para se të vinte në takim, klienti studioi çështjen dhe ai vetë hartoi jo vetëm një specifikim teknik kompetent, por edhe një detyrë artistike. Kjo është, një përshkrim letrar dhe i detajuar se si duhet të duket e gjitha. Nuk kishte kufi për habinë time, për të cilën ai u përgjigj: "Besoj se vetë klienti, para së gjithash, duhet të dijë se çfarë do dhe të mos mundojë specialistët". Fatkeqësisht, kjo është e rrallë, kështu që ne duhet të bëjmë pyetje, të përshkruajmë dhe të miratojmë.

• Zhvillimi dhe pritja.

Pasi të keni nënshkruar gjithçka, mund të filloni zbatimin e projektit.

Çfarë nuk duhet të jetë në TK dhe çfarë duhet të jetë atje

Në fakt, termat e referencës nuk duhet të përmbajnë udhëzime për vetë dizajnin. Ju shkruani se do të vizatoni një tastierë në faqen e internetit për një programues, dhe pastaj fillon - nuk është kështu, dua të jetë në stilin e komikeve dhe pastaj të provojë që nuk jeni dre. Sa më mirë të provoni veten si profesionist, aq më pak ankesa do të keni!

Ju vetë e dini se në çfarë stili dhe çfarë duhet të vizatoni. Detyra juaj është të përmirësoni vetëdijen e markës ose t'ju motivoni të qëndroni në një vend të tillë. Si do ta zbatoni këtë detyrë është problemi juaj. Nuk mjaftonte që klienti t'ju mësonte se si të shkruani kodin dhe t'ju tregonte se çfarë mjetesh të përdorni.

Lëreni TK-në tuaj të përmbajë frazën: "Gjithçka që nuk është specifikuar kryhet sipas gjykimit të interpretuesit". Dhe nuk është e nevojshme ta bëni këtë rresht me shkronja të vogla. Lëreni të mendojë paraprakisht dhe të mos fillojë të ëndërrojë kur projekti të jetë gati. Sigurisht, ju mund dhe duhet të bëni ndryshime të vogla. Një reputacion i mirë është një garanci për klientët e ardhshëm, por ndonjëherë klienti mund të jetë aq i keq me dëshirat e tij sa nuk dëshiron të jetojë.

Edhe një herë, dëshiroj të tërheq vëmendjen tuaj për faktin se TK nuk duhet të përmbajë koncepte abstrakte: "i përshtatshëm", "i bukur", "cilësi e lartë", etj. Lërini kufijtë të jenë të qartë: në vend të komoditetit të kërkimit, është më mirë të shkruani filtrim sipas datës ose materialit.

Dhe mos harroni nënshkrimin. Gjithçka është serioze, klienti duhet ta kuptojë këtë.

Në përgjithësi, ju rekomandoj shumë që t'i kushtoni vëmendje gjërave të vogla. Imagjinoni që një grua me shkumë të vjen tek ju, duke zbërthyer me nxitim një xhaketë të madhe në mënyrë që të dalë nga ajo një shall i madh. Ai nxjerr nga çanta e tij një shkarravitje të thërrmuar prej 18 fletësh të palosur njëqind herë, përpiqet ta lëmojë me sende aty pranë. Fytyrë e kuqe dhe e paqartë: "Ja, shkrova këtu shkurt, e bëra, kështu do të duket faqja jote, firmos".

Një variant tjetër. Një i ri troket në zyrën tuaj, zhvishet ngadalë, nxjerr një dosje nga një portofol, e hap ngadalë dhe ngadalë ju fton të shikoni vetëm një copë të vogël letre, mban një stilolaps të artë dhe ofron të nënshkruani këtë dokument.

Lëreni të renë nga shembulli i parë të bëjë një punë titanike, ajo lexoi një mijë libra, vizatoi vetë 18 shembuj dhe, në parim, bëri gjithçka vetë. Ajo është e aftë të krijojë një projekt tepër të lezetshëm që do ta çojë kompaninë tuaj drejt prosperitetit dhe lavdisë mbarëbotërore. Dhe i riu nga shembulli i dytë nuk di të bëjë asgjë, ai printoi një mostër nga interneti, i cili nuk ju përshtatet në asnjë mënyrë.

Ju siguroj se çdo klient do ta torturojë gruan e gjorë me bezdi, dëshira dhe ripunim, dhe projekti i të riut do të pranohet, nëse jo menjëherë, atëherë për herë të dytë. Nuk ka të bëjë me atë që mund të bëni, por si veproni dhe çfarë përshtypje krijoni.

Ekziston GOST, sipas të cilit mund të krijoni një detyrë teknike për zhvillimin e një siti, dhe ekziston një praktikë afatgjatë. Standardet shtetërore nuk përputhen gjithmonë me realitetet e jetës. Le të përpiqemi të kombinojmë të dyja këto pjesë.

Kur shkruani një detyrë teknike për administratën e qytetit ose legjendarin Vasily Pupkin, përmbajtja bëhet më së miri në përputhje me GOST. Mësoni këtë paraprakisht.

Duket kështu:

1. Fjalorth
2. Dispozitat e përgjithshme
3. Lënda e zhvillimit
4. Qëllimi i dokumentit
5. Kërkesat për dizajnin grafik të faqes
6. Kërkesat për hartimin e faqes në internet
7. Procedura e miratimit të konceptit të projektimit
8. Kërkesat funksionale
9. Kërkesat për prezantimin e faqes
10. Kërkesat e sistemit të menaxhimit të përmbajtjes
11. Kërkesat për ndarjen e aksesit
12. Kërkesat për llojet e kolateralit
13. Kërkesat për mbështetjen e informacionit
14. Kërkesat e softuerit
15. Kërkesat për mbështetje teknike
16. Kërkesat gjuhësore
17. Kërkesat estetike ergonomike dhe teknike
18. Kërkesat për pranimin dhe dorëzimin e projektit
19. Kërkesat për plotësimin e informacionit
20. Kërkesat e personelit
21. Procedura e provizionimit të shpërndarjes
22. Procedura për transferimin e sitit tek mjetet teknike të klientit

Vërtetë, do t'ju duhet të krijoni dokumentin tuaj me detyrën në një mënyrë tjetër, por, për të thjeshtuar perceptimin, unë do t'ju them të ndiqni këtë plan. Në fund të këtij artikulli, po bashkangjit një mostër me të cilën mund të shkarkoni dhe të punoni, bazuar në transkriptin e dhënë në këtë pjesë të artikullit. Ky shabllon është i mirë sepse ka të gjitha, edhe atë që nuk ju nevojitet kurrë. Por ju duhet ta ripunoni atë për veten tuaj dhe të kapërceni çdo katrahurë të panevojshme që e konsideroni të panevojshme.

Fjalorth

Sipas GOST, dokumenti duhet të fillojë me një fjalor, por në fakt ju do ta shkruani atë në fund. Këtu duhet të jepni kushtet që do të përdorni kur punoni me një klient. Ju po tregoni se çfarë është hostimi, faqe interneti dhe marrëzi të tjera. Të gjitha këto gjëra mund të shkarkohen nga interneti.

Megjithatë, përveç vetë kësaj herezie, është e nevojshme të përmenden termat, pasi t'i kuptoni, ju dhe klienti mund të keni një mendim të ndryshëm. Ju do të thoni një gjë, por ai jep një kuptim krejtësisht të ndryshëm në fjalë.

Dispozitat e përgjithshme

Në këtë pikë, është e nevojshme t'i përgjigjemi pyetjes se çfarë do të bëjmë në të vërtetë dhe pse.

Lënda e zhvillimit

Ajo që do të bëjmë është afërsisht e qartë. Klienti e lëshon këtë informacion pothuajse menjëherë. Është më e rëndësishme të kuptohet qëllimi operacional i faqes, domethënë, çfarë lloj përfitimi e pret klientin. Është e qartë se të gjithë klientët duan të bëjnë një fitim përmes faqes. Një formulim i tillë nuk do të funksionojë.

Mendoni se si klienti do të fitojë para, cili është qëllimi i tij. Nëse ky është një dyqan në internet, atëherë duhet të angazhohet në shitje, nëse një faqe në internet e korporatës, atëherë u pëlqen një frazë e bukur: "rritja e besnikërisë së markës", informimi për aktivitetet e kompanisë, etj.

Qëllimi i dokumentit

Këtu shpjegojmë se sa i rëndësishëm është ky dokument. Ne tregojmë se ky nuk është një truk i thjeshtë, por wow! Ne përdorim terma ligjorë. Kjo pjesë mund të kopjohet nga interneti, por mos harroni të lexoni me kujdes atë që shkruani!

Nga rruga, në të njëjtën pjesë ju duhet të grumbulloni informacione se gjithçka që nuk diskutoni me klientin paraprakisht mbetet në ndërgjegjen tuaj. Jeni të lirë të bëni çfarë të doni nëse ai “harroi”, “ndryshoi mendjen” ose “do gjithçka krejtësisht ndryshe”.

Kërkesat për dizajnin grafik të faqes

Kërkesat për hartimin e faqes në internet

Këtu ju duhet të përshkruani në terma të përgjithshëm dizajnin e faqes, çfarë duhet të jetë atje dhe cilat pika duhet t'i përmbahen: ngjyrat e korporatës, shkronjat, etj. Në terma të përgjithshëm, mos u fut në detaje.

Procedura e miratimit të konceptit të projektimit

Në këtë pjesë ju përsëri e frikësoni klientin duke përdorur terma ligjorë. Tregoni se do t'i siguroni atij një dizajn faqe interneti në formën e një fotografie të bërë në Photoshop. Ai është i detyruar ta shikojë atë në kohën e caktuar. Pas kësaj, do të pajiseni me redaktimet dhe ju nga ana tjetër do të mendoni nëse ai nuk është dre dhe do të bini dakord dhe do të kuptoni se sa logjike janë këto ndryshime dhe nëse do të ndërmerrni "korrigjimin".

Kërkesat funksionale

Këtu ju përshkruani se çfarë do të bëjmë në të vërtetë. Ne përshkruajmë komponentin vizual. Kapitulli zhvillohet në tre pjesë: ne përshkruajmë faqen kryesore, strukturën e brendshme dhe të faqes.

Bej kujdes. Kjo është një pikë e rëndësishme ku është më mirë të shkruani më shumë. Për shembull, duhet të keni një seksion "Lajme të ngjashme". Çfarë do të bëni: shkruani një algoritëm që do të llogarisë se cilët artikuj janë më të afërt me temën, do të japë një listë të pesë artikujve të fundit të shtuar në sit, ose autori i tekstit do të ketë mundësinë të fusë lidhje në këtë bllok në faqen e tij. vet?

Kërkesat për prezantimin e faqes

1. Struktura e faqes: ne përshkruajmë se cilat kategori (tituj) do të jenë në faqe.
2. Faqja kryesore: më e mira me një pamje skematike dhe përshkrim të elementeve kryesore.
3. Faqet e brendshme: njësoj si në paragrafin e mëparshëm. Skema dhe përshkrimi i faqeve të brendshme.

Nëse jeni duke bërë një dyqan në internet, mund të grumbulloni gjithashtu skemën e faqes së porosisë, konfirmimin e pagesës, etj. Përshkruani çdo faqe që do të ndryshojë nga shablloni standard.

Kërkesat e sistemit të menaxhimit të përmbajtjes

Blogu im është për njerëzit që krijojnë faqe WordPress. Prandaj, nuk do t'i kushtoj rëndësi serioze kësaj pike. Ne përshkruajmë që do të përdorim këtë motor dhe kjo do të jetë e mjaftueshme.

Nëse do të bëni vetë një sistem kontrolli, atëherë gjithçka është shumë më e ndërlikuar. Do të na duhet të vizatojmë sërish diagramet dhe të përshkruajmë kërkesat e përgjithshme, menaxhimin e seksioneve, përmbajtjen dhe cilësimet. Vizatoni çdo element që është i ndryshëm.

Kërkesat për ndarjen e aksesit

Këtu, në fakt, ata duan të dinë nga ne se kur dhe pse përdoruesi do të duhet të regjistrohet. Cilat seksione mbyllim dhe cilat prej tyre lexuesit mund t'i përdorin me siguri. Nëse kjo është një faqe kartëvizitash, informative ose shitëse, ajo do të jetë plotësisht e hapur, dhe Vkontakte, për shembull, ka qasje të kufizuar në një faqe personale dhe mund të kryhet vetëm pasi të keni futur një emër përdoruesi dhe fjalëkalim.

Kërkesat për llojet e kolateralit

Kërkesat për mbështetjen e informacionit

Kjo pjesë është krijuar thjesht për të treguar vetëdijen tuaj dhe për t'i treguar edhe një herë klientit se çfarë profesionisti profesionist jeni, çfarë termash të ndërlikuar përdorni.

Ju u thoni atyre se do t'i ruani të dhënat në një vend të caktuar në server, jo në tryezën tuaj ose nën jastëk. Ju përdorni gjuhë programimi.

Ju pranoni të ngarkoni imazhe vetëm në formatin gif ose jpg dhe faqet nuk do të kalojnë një peshë të caktuar. Pika e shkëlqyeshme, meqë ra fjala. Pastaj, nëse klienti fryn sytë dhe thotë se i duhet diçka tjetër, mund ta tregoni këtë pikë dhe të thoni: "Epo, ju vetë keni nënshkruar për peshën, nuk di asgjë, e gjithë kjo është e pamundur!".

Një tjetër gjë vërtet e dobishme që mund ta përmendni këtu: kufizimi i përmbajtjes së ofruar. Ju duhet të përcaktoni kornizën - po bëni të gjithë përmbajtjen apo po krijoni një llogari administratori, jepni klientit një emër përdoruesi dhe fjalëkalim dhe lëreni ta kuptojë!

Kërkesat e softuerit

1. Këtu po flasim për hosting ose serverë. Meqenëse blogu im është i fokusuar te krijuesit që punojnë në Timeweb ( https://timeweb.ru ) - gjithçka është shumë e thjeshtë. Nëse nuk jeni një nga tanët, atëherë duhet të shikoni specifikimet teknike. Për shembull, dikush shumë i zgjuar bën një sit të lezetshëm, dhe më pas përpiqet ta lidhë atë me hostin, dhe karakteristikat teknike janë aq të mbivlerësuara sa që asnjë host në Rusi nuk mund ta përballojë. Artikulli është i nevojshëm, por jo për fillestarët në fushën e zhvillimit.
2. Këtu përshkruajmë nëse portali do të ketë një version celular, të përshtatur për pajisjet portative, apo do të mund të hapet vetëm përmes Google Chrome, dhe çdo shtrembërim në shfletues të tjerë nuk na shqetëson aspak.

Kërkesat gjuhësore

A do të bëhet faqja në dy gjuhë apo do të na duhet vetëm rusishtja.

Kërkesat estetike ergonomike dhe teknike

Edhe një herë, ne përmendim shkurtimisht dispozitat kryesore të dizajnit. Gjithçka do të jetë e qartë, e drejtpërdrejtë, e të njëjtit lloj. Logoja dhe informacioni i kontaktit do të jenë të dukshme kudo. Gjithçka është super, gjithçka është e mrekullueshme.

Kërkesat për pranimin dhe dorëzimin e projektit

Kërkesat për plotësimin e informacionit

Në këtë pikë, ne ju tregojmë se çfarë marrim përsipër të përmbushim, si dhe çfarë duhet të sigurojë klienti për ne që puna të shkojë më shpejt dhe më mirë. Ai zakonisht kërkohet informacion dhe fotografi.

Ne gjithashtu shkruajmë përsëri se nëse ai dëshiron të korrigjojë ose ndryshojë diçka, do të duhet të hartojë përsëri një marrëveshje të ngjashme, të cilën ju ose e nënshkruani ose jo.

Kërkesat e personelit

Kush do të jetë në gjendje të përdorë faqen. Për shembull, disa kompani punojnë me kode dhe as nuk shqetësohen me një sistem kontrolli për njerëzit normalë. Për veprime elementare në sit, kërkohet njohuri domethënëse nga stafi. Në këtë rast, artikulli është i rëndësishëm, por në rastin tonë, vetëm shkresa.

Procedura e provizionimit të shpërndarjes

Çfarë do t'i jepni klientit kur të përfundojë puna: hyrje, fjalëkalim, mbrapa dhe mbrapa.

Ne plotësojmë çmimin e detyrës teknike

Siç e keni kuptuar tashmë, detyra kryesore e TK nuk është aq shumë për të kuptuar, megjithëse kjo është gjithashtu e rëndësishme. Dhe megjithatë, funksioni i tij shtesë është të krijojë përshtypjen e duhur për veten dhe të mbrohet nga të gjitha llojet e ndryshimeve.

Gjithçka në këtë dokument duhet të jetë mbresëlënëse! Nëse do ta dërgoni për shikim paraprak me postë, atëherë sigurohuni që të përdorni formatin PDF. Dhe klienti ndoshta nuk do të dëshirojë të mundojë veten me modifikime dhe ai do të mendojë për ju si një profesionist. Një gjë e vogël, por domethënëse. Për të kthyer një dokument Word, mund të përdorni shërbimin https://smallpdf.com/ru/ .

Mos harroni të futni logon e kompanisë tuaj ose të markës tuaj në sfond, si dhe të futni kontakte. Ato mund të lëshohen shpejt dhe me efikasitet në faqen e internetit. https://logaster.ru .

Epo, kjo është e gjitha, ju vetëm duhet të shkarkoni shembullin që kam krijuar posaçërisht për ju. Do t'ju ndihmojë të kuptoni dhe të merrni si bazë disa pika stereotipe që nuk do të jenë të ndryshme dhe të kryera.

Tani mund të shkoni me siguri te klienti dhe të mos keni frikë se do të akuzoheni për paplotësi.

SHKARKO SHBALLIN TK

Fat i mirë në përpjekjet tuaja dhe shihemi së shpejti. Regjistrohu në blogun tim dhe merr informacionin më të dobishëm që patjetër do të jetë i dobishëm për të punuar në zhvillimin e një faqe interneti të mirë për klientët tuaj.

Më pyesin shpesh: "Si të zhvilloni saktë një detyrë teknike për një sistem të automatizuar?" Tema e zhvillimit të një detyre teknike diskutohet vazhdimisht në forume të ndryshme. Kjo pyetje është aq e gjerë sa është e pamundur t'i përgjigjesh me pak fjalë. Prandaj, vendosa të shkruaj një artikull të gjatë mbi këtë temë. Në procesin e punës për artikullin, kuptova se nuk do të funksiononte të vendosja gjithçka në një artikull, sepse do të dalë më pak se 50 faqe dhe vendosi ta ndajë në 2 pjesë:

• Në pjesën e parë " Zhvillimi i specifikimeve teknike. Çfarë është ajo, pse është e nevojshme, ku të fillojë dhe si duhet të duket?" Do të përpiqem t'u përgjigjem në detaje pyetjeve të temës, të marr parasysh strukturën dhe qëllimin e Termave të Referencës dhe të jap disa rekomandime për formulimin e kërkesave.
• pjesa e dyte " Zhvillimi i specifikimeve teknike. Si të formuloni kërkesat?" do t'i kushtohet plotësisht identifikimit dhe formulimit të kërkesave për sistemin e informacionit.

Së pari, duhet të kuptoni se cila pyetje intereson vërtet ata që pyesin "Si të zhvilloni një detyrë teknike?" Fakti është se qasja ndaj zhvillimit të specifikimeve teknike gjithashtu do të varet shumë nga qëllimi për të cilin bëhet kjo, si dhe nga kush do të përdoret. Për cilat opsione e kam fjalën:

• Një organizatë tregtare vendosi të zbatojë një sistem të automatizuar. Ai nuk ka shërbimin e vet të TI-së dhe vendosi të bëjë sa më poshtë: Personi në fjalë duhet të zhvillojë Termat e Referencës dhe t'ia dorëzojë atë një organizate të palës së tretë për zhvillim;
• Një organizatë tregtare vendosi të zbatojë një sistem të automatizuar. Ka shërbimin e vet IT. Ne vendosëm ta bëjmë këtë: të zhvillojmë Termat e Referencës, më pas t'i koordinojmë ato ndërmjet shërbimit të IT dhe palëve të interesuara dhe ta zbatojmë vetë;
• Agjencia qeveritare vendosi të nisë një projekt IT. Gjithçka është kaq e turbullt këtu, shumë formalitete, ryshfete, shkurtime, etj. Unë nuk do ta konsideroj këtë opsion në këtë artikull.
• Një kompani IT është e angazhuar në shërbime për zhvillimin dhe / ose zbatimin e sistemeve të automatizuara. Ky është rasti më i vështirë, sepse duhet të punoni në kushte të ndryshme:

  Klienti ka specialistët e tij me pikëpamjet e tyre, dhe ata bëjnë kërkesa specifike për Termat e Referencës;

  • Kushtet e referencës janë zhvilluar për zhvilluesit tanë (klientit nuk i intereson);
  • Termat e referencës zhvillohen për transferim te kontraktori (d.m.th. një grup programuesish të vendosur jashtë stafit të kompanisë, ose një specialist individual);
  • Një keqkuptim lind midis kompanisë dhe klientit në lidhje me rezultatin e marrë dhe kompania vazhdimisht shtron pyetjen: "Si duhet të zhvillohen Termat e Referencës?" Ndoshta rasti i fundit duket si një paradoks, por është e vërtetë.
  • Opsione të tjera, më pak të zakonshme janë gjithashtu të mundshme;

Unë mendoj se lexuesi tani duhet të ketë disa pyetje:

• Pse është e pamundur të zhvillohen Termat e Referencës janë gjithmonë të njëjta?;
• A ka ndonjë standard, metodë, rekomandim? Ku mund t'i marr ato?
• Kush duhet të zhvillojë Termat e Referencës? A duhet të ketë ky person ndonjë njohuri të veçantë?
• Si të kuptoni nëse Termat e Referencës janë shkruar mirë apo jo?
• Me shpenzimet e kujt duhet të zhvillohet dhe a është fare e nevojshme?

Lista mund të jetë e pafund. Unë flas me shumë besim sepse kam 15 vjet që jam në zhvillimin profesional të softuerit dhe çështja e Termave të Referencës lind në çdo ekip zhvillimi me të cilin duhet të punoj. Arsyet për këtë janë të ndryshme. Duke ngritur temën e zhvillimit të Termave të Referencës, jam plotësisht i vetëdijshëm se nuk do të mund ta paraqes atë 100% për të gjithë të interesuarit për këtë temë. Por, do të përpiqem, siç thonë ata, "të vendos gjithçka në rafte". Ata që tashmë janë njohur me artikujt e mi e dinë që unë nuk përdor "copy-paste"-in e veprave të të tjerëve, nuk ribotoj libra të të tjerëve, nuk citoj standarde me shumë faqe dhe dokumente të tjera që ju vetë mund t'i gjeni në interneti, duke i kaluar ato si mendimet e mia brilante. Mjafton të shkruani në motorin e kërkimit "Si të zhvilloni një detyrë teknike" dhe mund të lexoni shumë interesante, por, për fat të keq, shumë herë të përsëritura. Si rregull, ata që pëlqejnë të jenë të zgjuar në forume (përpiqen të kërkojnë të gjithë njësoj!) nuk kanë bërë kurrë një term të arsyeshëm të referencës vetë, dhe vazhdimisht citojnë rekomandimet e GOST-ve për këtë çështje. Dhe për ata që janë vërtet seriozë për këtë çështje, zakonisht nuk ka kohë për t'u ulur në forume. Nga rruga, ne gjithashtu do të flasim për GOST. Gjatë viteve të punës sime, kam parë shumë opsione për dokumentacionin teknik, të përpiluar si nga specialistë individualë, ashtu edhe nga ekipe dhe kompani konsulente eminente. Ndonjëherë bëj edhe këtë aktivitet: i lë kohë vetes dhe kërkoj informacion për një temë me interes nga burime të pazakonta (aq pak inteligjencë). Si rezultat, më duhej të shihja dokumentacionin për monstra të tillë si GazProm, Hekurudhat Ruse dhe shumë kompani të tjera interesante. Sigurisht, unë i përmbahem politikës së privatësisë, pavarësisht se këto dokumente më vijnë nga burime të disponueshme publikisht ose nga papërgjegjshmëria e konsulentëve (shpërndarja e informacionit në internet). Ndaj them menjëherë: Nuk ndaj informacione konfidenciale që i përkasin kompanive të tjera, pavarësisht nga burimet e shfaqjes (etika profesionale).

Cilat janë termat e referencës?

Gjëja e parë që do të bëjmë tani është të kuptojmë se çfarë lloj bishe është kjo, "Termat e Referencës".

Po, ka vërtet GOST dhe standarde në të cilat bëhen përpjekje për të rregulluar këtë pjesë të aktivitetit (zhvillimin e softuerit). Njëherë e një kohë, të gjitha këto GOST ishin të rëndësishme dhe përdoreshin në mënyrë aktive. Tani ka mendime të ndryshme në lidhje me rëndësinë e këtyre dokumenteve. Disa argumentojnë se GOST-të u zhvilluan nga njerëz shumë largpamës dhe janë ende të rëndësishme. Të tjerë thonë se janë të vjetëruar pa shpresë. Ndoshta dikush vetëm tani mendoi se e vërteta është diku në mes. Unë do të përgjigjesha me fjalët e Gëtes: “Thonë se ka të vërtetë mes dy mendimeve të kundërta. Në asnjë rast! Ka një problem mes tyre”. Pra, nuk ka asnjë të vërtetë mes këtyre mendimeve. Sepse GOST-të nuk zbulojnë problemet praktike të zhvillimit modern, dhe ata që i kritikojnë ato nuk ofrojnë alternativa (specifike dhe sistematike).

Vini re se GOST qartë nuk jep as një përkufizim, ai vetëm thotë: "Specifikimi teknik për NPP është dokumenti kryesor që përcakton kërkesat dhe procedurën për krijimin (zhvillimin ose modernizimin - krijimin e mëtejshëm) të një sistemi të automatizuar, në në përputhje me të cilën zhvillimi i AU dhe pranimi i tij kryhet me vënien në veprim”.

Nëse dikush është i interesuar për cilat GOST po flas, atëherë këtu janë:

• GOST 2.114-95 Sistemi i unifikuar për dokumentacionin e projektimit. Kushtet teknike;
• GOST 19.201-78 Sistemi i unifikuar i dokumentacionit të programit. Detyrë teknike. Kërkesat për përmbajtjen dhe dizajnin;
• GOST 34.602-89 Teknologjia e informacionit. Një grup standardesh për sistemet e automatizuara. Kushtet e referencës për krijimin e një sistemi të automatizuar.

Një përkufizim shumë më i përshtatshëm është paraqitur në Wikipedia (e vërtetë për TK në përgjithësi, dhe jo vetëm për softuerin): " Detyrë teknike- ky është dokumenti fillestar i projektimit teknike Objekt. Detyrë teknike përcakton qëllimin kryesor të objektit të zhvilluar, karakteristikat e tij tekniko-taktike dhe teknike, treguesit e cilësisë dhe kërkesat teknike dhe ekonomike, udhëzimet për kryerjen e fazave të nevojshme të krijimit të dokumentacionit (dizajn, teknologjik, softuer, etj.) dhe përbërjen e tij, si dhe si kërkesa të veçanta. Një detyrë si një dokument burimor për krijimin e diçkaje të re ekziston në të gjitha fushat e veprimtarisë, të ndryshme në emër, përmbajtje, renditje regjistrimi, etj. (për shembull, një detyrë projekti në ndërtim, një detyrë luftarake, detyra shtëpie, një kontratë për një letërsi punë, etj.) etj.) "

Dhe kështu, siç del nga përkufizimi, qëllimi kryesor i Termave të Referencës është të formulojë kërkesat për objektin që po zhvillohet, në rastin tonë për një sistem të automatizuar.

Pikërisht kryesori, por i vetmi. Ka ardhur koha për të trajtuar gjënë kryesore: të zgjidhim gjithçka "në rafte", siç është premtuar.

Çfarë duhet të dini për kërkesat? Është e nevojshme të kuptohet qartë se të gjitha kërkesat duhet të ndahen sipas llojit dhe veçorive. Tani do të mësojmë se si ta bëjmë këtë. GOST do të na ndihmojë të ndajmë kërkesat sipas llojit. Lista e llojeve të kërkesave që paraqitet atje është një shembull i mirë se cilat lloje të kërkesave duhet të merren parasysh. Për shembull:

• Kërkesat për funksionalitet;
• Kërkesat për sigurinë dhe të drejtat e aksesit;
• Kërkesat për kualifikimet e personelit;
• …. etj. Ju mund të lexoni rreth tyre në GOST-in e përmendur (dhe më poshtë do t'i konsideroj ato në pak më shumë detaje).

Mendoj se është e qartë për ju se faktori kryesor për një Terma Referencë të suksesshme janë kërkesat saktësisht të formuluara mirë për funksionalitetin. Shumica e veprave dhe teknikave për të cilat fola i kushtohen këtyre kërkesave. Kërkesat për funksionalitet janë 90% e kompleksitetit të punës për zhvillimin e Termave të Referencës. Gjithçka tjetër shpesh është “kamuflimi” që u bëhet këtyre kërkesave. Nëse kërkesat janë formuluar dobët, atëherë çfarë lloj kamuflazhi të bukur nuk vendosni, një projekt i suksesshëm nuk do të funksionojë. Po, zyrtarisht të gjitha kërkesat do të plotësohen (sipas GOST J), TK është zhvilluar, miratuar dhe nënshkruar, paratë janë marrë për të. Edhe çfarë? Dhe pastaj do të fillojë gjëja më interesante: çfarë të bëni? Nëse ky është një projekt për Urdhrin Shtetëror, atëherë nuk ka probleme - buxheti atje është i tillë që nuk do të futet në asnjë xhep, në proces zbatimi (nëse ka), gjithçka do të sqarohet. Pikërisht kështu shkurtohen buxhetet e projekteve për Urdhrat e Shtetit (kanë ndezur "TZ", kanë derdhur dhjetë milionë, por projekti nuk u krye. U ndoqën të gjitha formalitetet, nuk ka fajtorë, një makinë e re. është afër shtëpisë.Bukuroshja!). Por ne po flasim për organizata tregtare ku llogariten paratë dhe rezultati është i ndryshëm. Prandaj, le të merremi me gjënë kryesore, si të zhvillojmë Termat e Referencës së dobishme dhe funksionale.

Thashë për llojet e kërkesave, po pronat po? Nëse llojet e kërkesave mund të jenë të ndryshme (në varësi të qëllimeve të projektit), atëherë me vetitë gjithçka është më e thjeshtë, ka 3 prej tyre:

1. Kërkesa duhet të jetë e kuptueshme;
2. Kërkesa duhet të jetë specifike;
3. Kërkesa duhet të jetë testuar;

Për më tepër, prona e fundit është e pamundur pa dy të mëparshmet, d.m.th. është një lloj “lakmus testi”. Nëse rezultati i përmbushjes së një kërkese nuk mund të testohet, atëherë ai ose nuk është i qartë ose jo specifik. Mendoni për këtë. Pikërisht në zotërimin e këtyre tre vetive të kërkesave qëndron aftësia dhe profesionalizmi. Në fakt, gjithçka është shumë e thjeshtë. Kur ta kuptoni.

Mbi këtë, historia se çfarë janë Termat e Referencës, mund të plotësohet dhe të kalohet te gjëja kryesore: si të formulohen kërkesat. Por jo gjithçka është kaq e shpejtë. Ekziston edhe një pikë shumë e rëndësishme:

• Në cilën gjuhë (përsa i përket kompleksitetit të të kuptuarit) duhet të shkruhen termat e referencës?
• A duhet të përshkruhen në të specifikimet e funksioneve të ndryshme, algoritmeve, llojeve të të dhënave dhe gjërave të tjera teknike?
• Dhe çfarë është dizajni teknik, i cili, nga rruga, përmendet edhe në GOST, dhe si lidhet me Termat e Referencës?

Ka një gjë shumë tinëzare në përgjigjet e këtyre pyetjeve. Prandaj shpesh lindin mosmarrëveshje për mjaftueshmërinë ose mungesën e detajimit të nevojshëm të kërkesave, për qartësinë e dokumentit nga Klienti dhe Kontraktorët, për tepricën, formatin e paraqitjes etj. Dhe ku është kufiri midis Termave të Referencës dhe Projektimit Teknik?

Detyrë teknikeështë një dokument i bazuar në kërkesa të formuluara në një gjuhë të kuptueshme (të zakonshme, të njohur) për Klientin. Në të njëjtën kohë, mund dhe duhet të përdoret terminologjia e industrisë që është e kuptueshme për Klientin. Nuk duhet të ketë detyrime për specifikat e zbatimit teknik. ato. në fazën TK, në parim, nuk ka rëndësi se në cilën platformë do të zbatohen këto kërkesa. Megjithatë ka përjashtime. Nëse po flasim për zbatimin e një sistemi të bazuar në një produkt softuer ekzistues, atëherë një lidhje e tillë mund të ndodhë, por vetëm në nivelin e formularëve të ekranit, formularëve të raportit, etj. ANALIST Biznesi. Dhe sigurisht jo një programues (nëse ai nuk i kombinon këto role në vetvete, kjo ndodh). ato. ky person duhet të flasë me Klientin në gjuhën e biznesit të tij.

Projekt teknikështë një dokument që synon zbatimin teknik të kërkesave të formuluara në Termat e Referencës. Ky dokument përshkruan strukturat e të dhënave, nxitësit dhe procedurat e ruajtura, algoritmet dhe gjërat e tjera që kërkohen. teknikë... Nuk është aspak e nevojshme që klienti të thellohet në këtë (ai mund të mos kuptojë terma të tillë). Dizajni teknik bën Arkitekt i sistemit(është krejt normale ta kombinosh këtë rol me një programues). Për të qenë më të saktë, një grup specialistësh të AO drejtohet nga një arkitekt. Sa më i madh të jetë projekti, aq më shumë njerëz po punojnë me Termat e Referencës.

Çfarë kemi në praktikë? Është qesharake të shikosh kur drejtori sillet për miratim nga Termat e Referencës, e cila është e mbushur me terminologji teknike, një përshkrim të llojeve të të dhënave dhe vlerat e tyre, strukturën e bazës së të dhënave, etj. kërkesat e biznesit. A është kjo një situatë e njohur? Dhe si përfundon? Si rregull, një TK e tillë miratohet, më pas zbatohet dhe në 80% të rasteve nuk korrespondon fare me faktin e punës së kryer, sepse vendosën të ndryshojnë, të ribëjnë shumë gjëra, të keqkuptohen, menduan gabim, etj. etj. Dhe pastaj fillon seria për dorëzimin e punës. "Por kjo nuk është mënyra se si na nevojitet", por "kjo nuk do të funksionojë për ne", "kjo është shumë e vështirë", "kjo është e papërshtatshme", etj. Tingëllon e njohur? !! Kjo është e njohur për mua, më duhej të mbushja kone në kohën e duhur.

Pra, çfarë kemi ne në praktikë? Në praktikë, ne kemi një kufi të paqartë midis Termave të Referencës dhe Projektimit Teknik. Ajo lundron midis TK dhe TP në forma të ndryshme. Dhe kjo është e keqe. Dhe kështu rezulton sepse kultura e zhvillimit është dobësuar. Kjo është pjesërisht për shkak të kompetencave të specialistëve, pjesërisht me dëshirën për të reduktuar buxhetet dhe afatet (në fund të fundit, dokumentacioni kërkon shumë kohë - ky është një fakt). Ekziston një faktor tjetër i rëndësishëm që ndikon në përdorimin e Projektimit Teknik si një dokument më vete: zhvillimi i shpejtë i mjeteve të zhvillimit të shpejtë, si dhe i metodologjive të zhvillimit. Por kjo është një histori më vete, pak më poshtë do të them disa fjalë për të.

Një tjetër pikë e vogël por e rëndësishme. Ndonjëherë Termat e Referencës janë një pjesë e vogël e kërkesave, të thjeshta dhe të kuptueshme. Për shembull, për të përmirësuar kërkimin e një objekti sipas disa kushteve, shtoni një kolonë në raport, etj. Kjo qasje është mjaft e justifikuar, pse e ndërlikoni jetën. Por nuk përdoret në projekte të mëdha, por në përmirësime të vogla. Unë do të thoja se kjo është më afër mirëmbajtjes së një produkti softuer. Në këtë rast, një zgjidhje teknike specifike për zbatimin e kërkesës mund të përshkruhet në Termat e Referencës. Për shembull, "Bëni një ndryshim të tillë në algoritmin ashtu dhe kaq", duke treguar një procedurë specifike dhe një ndryshim specifik për programuesin. Ky është rasti kur kufiri ndërmjet Termave të Referencës dhe Projekteve Teknike fshihet plotësisht, sepse nuk ka fizibilitet ekonomik për të reklamuar dokumentet aty ku nuk nevojiten dhe krijohet një dokument i dobishëm. Dhe është e drejtë.

Keni nevojë fare për një detyrë teknike? Po në lidhje me dizajnin teknik?

A jam mbinxehur? A është e mundur kjo, pa fare Termat e referencës? Imagjinoni që është e mundur (më saktë, ndodh), dhe kjo qasje ka shumë ndjekës dhe numri i tyre po rritet. Si rregull, pasi specialistët e rinj lexojnë libra për Scrum, Agile dhe teknologji të tjera të zhvillimit të shpejtë. Në fakt, këto janë teknologji të mrekullueshme dhe funksionojnë, vetëm se nuk thonë fjalë për fjalë "nuk ka nevojë të bësh specifikime teknike". Ata thonë "një minimum dokumentesh", veçanërisht të panevojshme, më afër klientit, më specifikë dhe më të shpejtë në rezultat. Por askush nuk e anuloi fiksimin e kërkesave dhe aty thuhet qartë. Pikërisht aty fiksohen kërkesat bazuar në tre vetitë e jashtëzakonshme për të cilat fola më lart. Thjesht disa njerëz kanë një vetëdije të tillë të strukturuar, saqë nëse diçka mund të thjeshtohet, atëherë le ta thjeshtojmë atë në një mungesë të plotë. Siç tha Ajnshtajni " Bëjeni sa më të thjeshtë, por jo më të lehtë.” ... Fjalët e arta, në fund të fundit, janë të përshtatshme për gjithçka. Kështu që Detyrë teknikeështë e nevojshme, përndryshe nuk do të shihni një projekt të suksesshëm. Një pyetje tjetër është se si të kompozoni dhe çfarë të përfshini atje. Në dritën e metodologjive të Zhvillimit të Shpejtë, ju duhet vetëm të përqendroheni në kërkesat dhe i gjithë "kamuflimi" mund të hiqet. Në parim, jam dakord me këtë.

Po projekti teknik? Ky dokument është shumë i dobishëm dhe nuk e ka humbur rëndësinë e tij. Për më tepër, shpesh është e pamundur të bëhet pa të. Sidomos kur bëhet fjalë për kontraktimin e punës së zhvillimit, d.m.th. në bazë të kontraktimit. Nëse kjo nuk bëhet, ekziston rreziku për të mësuar shumë gjëra të reja se si duhet të duket sistemi që keni konceptuar. A duhet që Klienti ta njohë atë? Nëse do, pse jo, por nuk ka nevojë të insistojë dhe të miratojë këtë dokument, ai vetëm do të frenojë dhe ndërhyjë në punë. Është pothuajse e pamundur të projektosh një sistem deri në detajet më të vogla. Në këtë rast, do t'ju duhet të bëni vazhdimisht ndryshime në Dizajn Teknik, i cili kërkon shumë kohë. Dhe nëse organizata është shumë burokratike, atëherë në përgjithësi, lini të gjitha nervat atje. Bëhet fjalë pikërisht për reduktimin e këtij lloj dizajni për të cilin po flasim në metodologjitë moderne të zhvillimit të shpejtë, që përmenda më lart. Nga rruga, të gjitha ato bazohen në XP klasik (programim ekstrem) - një qasje që tashmë është rreth 20 vjeç. Pra, bëni një Termat Referenci me cilësi të lartë, të kuptueshme për Klientin, dhe përdorni Projektimin Teknik si një dokument të brendshëm për marrëdhënien midis arkitektit të sistemit dhe programuesve.

Një detaj interesant në lidhje me dizajnin teknik: disa mjete zhvillimi të bazuara në parimin e orientimit të lëndës (të tilla si 1C dhe të ngjashme) supozojnë se dizajni (që nënkupton procesin e dokumentimit) kërkohet vetëm në zona vërtet komplekse ku kërkohet ndërveprimi midis nënsistemeve të tëra. Në rastin më të thjeshtë, për shembull, për të krijuar një libër referimi, një dokument, mjaftojnë vetëm kërkesat e biznesit të formuluara saktë. Këtë e dëshmon edhe strategjia e biznesit të kësaj platforme në drejtim të trajnimit të specialistëve. Nëse shikoni biletën e provimit të një specialisti (kështu quhet, dhe jo "programues"), do të shihni se ka vetëm kërkesa biznesi dhe se si t'i zbatoni ato në një gjuhë programimi është detyrë e specialistit. ato. atë pjesë të detyrës që Projekti Teknik është krijuar për të zgjidhur, specialisti duhet ta zgjidhë "në kokë" (po flasim për detyra me kompleksitet mesatar), dhe këtu dhe tani, duke ndjekur disa standarde zhvillimi dhe projektimi, të cilat janë formuar përsëri nga 1C për platformën e saj. Kështu, nga dy specialistë, rezultati i punës së të cilëve duket i njëjtë, njëri mund të kalojë provimin dhe tjetri nuk mundet, sepse shkelur rëndë standardet e zhvillimit. Kjo do të thotë, padyshim supozohet se specialistët duhet të kenë kualifikime të tilla që të mund të hartojnë detyra tipike vetë, pa përfshirë arkitektë të sistemit. Dhe kjo qasje funksionon.

Le të vazhdojmë studimin e pyetjes: "Çfarë kërkesash duhet të përfshihen në Termat e Referencës?"

Formulimi i kërkesave për sistemin e informacionit. Struktura e Termave të Referencës

Le të vendosim menjëherë: do të flasim konkretisht për formulimin e kërkesave për një sistem informacioni, d.m.th. duke supozuar se puna për zhvillimin e kërkesave të biznesit, formalizimin e proceseve të biznesit dhe të gjitha punët paraprake konsultative tashmë janë kryer. Sigurisht, edhe në këtë fazë mund të bëhen disa përpunime, por pikërisht përpunime. Vetë projekti i automatizimit nuk zgjidh problemet e biznesit - mbani mend këtë. Kjo është një aksiomë. Për disa arsye, disa menaxherë përpiqen ta hedhin poshtë atë, duke besuar se nëse blejnë programin, atëherë rendi do të vijë në një biznes kaotik. Por aksioma është gjithashtu një aksiomë që nuk kërkohen prova.

Ashtu si me çdo aktivitet, formulimi i kërkesave mund (dhe duhet) të ndahet në faza. Çdo gjë ka kohën e vet. Kjo është punë e vështirë intelektuale. Dhe, nëse ai e trajton atë me vëmendje të pamjaftueshme, atëherë rezultati do të jetë i përshtatshëm. Sipas vlerësimeve të ekspertëve, kostoja e zhvillimit të Termave të Referencës mund të jetë 30-50%. Unë jam i të njëjtit mendim. Edhe pse 50 është ndoshta shumë. Në fund të fundit, Termat e Referencës nuk janë dokumenti i fundit për t'u zhvilluar. Në fund të fundit, duhet të ketë edhe dizajn teknik. Kjo përhapje është për shkak të platformave, qasjeve dhe teknologjive të ndryshme të automatizimit të përdorura nga ekipet e projektit gjatë zhvillimit. Për shembull, nëse po flasim për zhvillim në një gjuhë klasike si C ++, atëherë nuk mund të bëhet pa dizajn teknik të detajuar. Nëse po flasim për zbatimin e sistemit në platformën 1C, atëherë situata me dizajnin është disi e ndryshme, siç e pamë më lart (megjithëse, kur zhvillohet sistemi "nga e para", ai është projektuar sipas skemës klasike) .

Pavarësisht se deklarata e kërkesave është pjesa kryesore e Termat e referencës, dhe në disa raste ai bëhet i vetmi seksion i TK, duhet t'i kushtoni vëmendje faktit që ky është një dokument i rëndësishëm dhe duhet të hartohet në përputhje me rrethanat. Ku të fillojë? Para së gjithash, duhet të filloni me përmbajtjen. Përpiloni përmbajtjen tuaj dhe më pas filloni ta zgjeroni atë. Personalisht, unë e bëj këtë: së pari skicoj përmbajtjen, përshkruaj qëllimet, të gjithë informacionin e sfondit dhe më pas marr pjesën kryesore - formulimin e kërkesave. Pse jo anasjelltas? Nuk e di, është më i përshtatshëm për mua. Së pari, kjo është një pjesë shumë më e vogël e kohës (krahasuar me kërkesat), dhe së dyti, ndërsa përshkruani të gjithë informacionin hyrës, ju përshtateni me gjënë kryesore. Epo, kjo është si të duash. Me kalimin e kohës, ju do të zhvilloni shabllonin tuaj për Termat e Referencës. Për të filluar, unë rekomandoj që të merrni pikërisht atë të përshkruar në GOST si përmbajtje. Përshtatet në mënyrë të përkryer për përmbajtjen! Pastaj marrim dhe fillojmë të përshkruajmë secilën pjesë, duke mos harruar rekomandimet për respektimin e tre vetive: qartësinë, konkretitetin dhe testueshmërinë. Pse jam kaq insistues për këtë? Më shumë për këtë në seksionin tjetër. Dhe tani unë propozoj të kaloj deri në fund pikat e TK, të cilat rekomandohen në GOST.

1. informacion i pergjithshem;
2. qëllimi dhe qëllimet e krijimit (zhvillimit) të sistemit;
3. karakteristikat e objekteve të automatizimit;
4. Kërkesat e sistemit;
5. përbërja dhe përmbajtja e punës për krijimin e sistemit;
6. procedurën për kontrollin dhe pranimin e sistemit;
7. kërkesat për përbërjen dhe përmbajtjen e punës për përgatitjen e objektit të automatizimit për vënien në punë të sistemit;
8. kërkesat e dokumentacionit;
9. burimet e zhvillimit.

Në total, ka 9 seksione, secila prej të cilave është e ndarë gjithashtu në nënseksione. Le t'i analizojmë ato me radhë. Për lehtësi, unë do të paraqes gjithçka në formën e një tabele për secilin artikull.

Seksioni 1. informacion i përgjithshëm.

Rekomandime sipas GOST
emri i plotë i sistemit dhe simboli i tij;	Gjithçka është e qartë këtu: ne shkruajmë se si do të quhet sistemi, emri i tij i shkurtër
kodi i lëndës ose kodi (numri) i kontratës;	Kjo nuk është e rëndësishme, por ju mund të specifikoni nëse kërkohet
emri i ndërmarrjeve (shoqatave) të zhvilluesit dhe klientit (përdoruesit) të sistemit dhe detajet e tyre;	tregoni se kush (cilat organizata) do të punojnë në projekt. Ju gjithashtu mund të specifikoni rolet e tyre. Ju mund ta fshini këtë seksion fare (më tepër formal).
një listë dokumentesh mbi bazën e të cilave është krijuar sistemi, nga kush dhe kur janë miratuar këto dokumente;	Informacion i dobishëm. Këtu ia vlen të tregoni dokumentacionin normativ dhe referues që ju është ofruar për t'u njohur me një pjesë të caktuar të kërkesave
datat e planifikuara të fillimit dhe përfundimit për krijimin e sistemit;	Kërkesat për kohën. Ndonjëherë ata shkruajnë për këtë në TK, por më shpesh gjëra të tilla përshkruhen në kontratat e punës
informacione për burimet dhe procedurën e financimit të punës;	Po kështu, si në paragrafin e mëparshëm për kohën. Më e rëndësishme për urdhrat e qeverisë (për punonjësit e sektorit publik)
procedura për regjistrimin dhe paraqitjen tek klienti i rezultateve të punës për krijimin e sistemit (pjesët e tij), për prodhimin dhe rregullimin e mjeteve individuale (hardware, softuer, informacion) dhe komplekse softuerësh dhe harduerësh (softuerësh dhe metodologjikë) të sistemi.	Unë nuk e shoh të nevojshme për këtë pikë, tk. kërkesat për dokumentacion bëhen veçmas, dhe përveç kësaj ekziston një seksion i tërë i veçantë "Procedura e kontrollit dhe pranimit" të sistemit.

Seksioni 2. qëllimi dhe qëllimet e krijimit (zhvillimit) të sistemit.

Rekomandime sipas GOST	Çfarë duhet bërë për këtë në praktikë
Qëllimi i sistemit	Nga njëra anë, gjithçka është e thjeshtë me takimin. Por është e dëshirueshme të jesh specifik. Nëse shkruani diçka si "automatizoni cilësisht kontrollin e inventarit në kompaninë X", atëherë mund të diskutoni rezultatin për një kohë të gjatë në përfundimin e tij, edhe pavarësisht nga formulimi i mirë i kërkesave. Sepse Klienti mund të thotë gjithmonë se ai nënkuptonte diçka të ndryshme me cilësi. Në përgjithësi, ju mund të prishni shumë nerva njëri-tjetrit, por pse? Është më mirë të shkruani menjëherë diçka të tillë: "Sistemi është krijuar për kontrollin e inventarit në kompaninë X në përputhje me kërkesat e specifikuara në këtë Terma të Referencës".
Objektivat e sistemit	Objektivat janë padyshim një seksion i rëndësishëm. Nëse vërtet e përfshini atë, atëherë duhet të jeni në gjendje t'i formuloni këto qëllime. Nëse keni vështirësi me formulimin e qëllimeve, atëherë është më mirë ta përjashtoni këtë pjesë krejtësisht. Një shembull i një qëllimi të pasuksesshëm: "Siguroni dokumente të shpejta për menaxherin". Çfarë është e shpejtë? Kjo pastaj mund të vërtetohet pafundësisht. Nëse kjo është e rëndësishme, atëherë është më mirë ta riformuloni këtë qëllim si më poshtë: "Menaxheri i shitjeve duhet të jetë në gjendje të hartojë një dokument" Shitjet e mallrave "me 100 rreshta në 10 minuta". Një objektiv i ngjashëm mund të shfaqet nëse, për shembull, menaxheri aktualisht shpenzon rreth një orë për këtë, gjë që është shumë për këtë kompani dhe është e rëndësishme për ta. Në një formulim të tillë, qëllimi tashmë kryqëzohet me kërkesat, gjë që është krejt e natyrshme, pasi kur zgjerojmë pemën e qëllimeve (d.m.th. duke i ndarë ato në qëllime më të vogla të lidhura), ne do t'u qasemi kërkesave gjithsesi. Prandaj, nuk duhet të tërhiqeni.

Në përgjithësi, aftësia për të identifikuar qëllimet, për t'i formuluar ato, për të ndërtuar një pemë qëllimesh është një temë krejtësisht e veçantë. Mos harroni gjënë kryesore: nëse dini si - shkruani, nuk jeni të sigurt - mos shkruani fare. Çfarë do të ndodhë nëse nuk formuloni qëllime? Do të punoni sipas kërkesave, kjo praktikohet shpesh.

Seksioni 3. Përshkrimi i objekteve të automatizimit.

Seksioni 4. Kërkesat e Sistemit

GOST deshifron listën e kërkesave të tilla:

• kërkesat për strukturën dhe funksionimin e sistemit;
• kërkesat për numrin dhe kualifikimet e personelit të sistemit dhe mënyrën e punës së tyre;
• treguesit e destinacionit;
• kërkesat e besueshmërisë;
• kërkesat e sigurisë;
• kërkesat për ergonomi dhe estetikë teknike;
• kërkesat e transportueshmërisë për altoparlantët celularë;
• kërkesat për funksionimin, mirëmbajtjen, riparimin dhe ruajtjen e komponentëve të sistemit;
• kërkesat për mbrojtjen e informacionit nga aksesi i paautorizuar;
• kërkesat për sigurinë e informacionit në rast aksidentesh;
• kërkesat për mbrojtje nga ndikimet e ndikimeve të jashtme;
• kërkesat për pastërtinë e patentës;
• kërkesat për standardizim dhe unifikim;

Pavarësisht se pjesa kryesore do të jetë me siguri me kërkesa specifike (funksionale), edhe ky seksion mund të ketë një rëndësi të madhe (dhe në shumicën e rasteve ka). Çfarë mund të jetë e rëndësishme dhe e dobishme:

• Kërkesat e kualifikimit... Ndoshta sistemi që po zhvillohet do të kërkojë rikualifikim të specialistëve. Këta mund të jenë përdorues të sistemit të ardhshëm dhe specialistë të TI-së që do të nevojiten për ta mbështetur atë. Vëmendja e pamjaftueshme ndaj kësaj çështje shpesh shndërrohet në probleme. Nëse kualifikimet e stafit ekzistues janë qartësisht të pamjaftueshme, është më mirë të përcaktohen kërkesat për organizimin e trajnimit, programin e trajnimit, kohën, etj.
• Kërkesat për mbrojtjen e informacionit nga aksesi i paautorizuar. Komentet janë të panevojshme këtu. Këto janë pikërisht kërkesat për diferencimin e aksesit në të dhëna. Nëse këto kërkesa janë planifikuar, atëherë ato duhet të përshkruhen veçmas, në sa më shumë detaje që të jetë e mundur sipas të njëjtave rregulla si kërkesat funksionale (qartësia, specifika, testueshmëria). Prandaj, këto kërkesa mund të përfshihen në seksionin me kërkesat funksionale.
• Kërkesat për standardizim. Nëse ka ndonjë standard projektimi që është i zbatueshëm për projektin, ato mund të përfshihen në kërkesat. Si rregull, kërkesa të tilla iniciohen nga shërbimi IT i Klientit. Për shembull, kompania 1C ka kërkesa për hartimin e kodit të programit, dizajnin e ndërfaqes, etj.;
• Kërkesat për strukturën dhe funksionimin e sistemit. Kërkesat për integrimin e sistemeve me njëri-tjetrin mund të përshkruhen këtu, jepet një përshkrim i arkitekturës së përgjithshme. Më shpesh, kërkesat për integrim në përgjithësi veçohen në një seksion të veçantë ose edhe në një Terma të Referencës të veçantë. këto kërkesa mund të jenë mjaft komplekse.

Të gjitha kërkesat e tjera janë më pak të rëndësishme dhe nuk kanë nevojë të përshkruhen. Sipas mendimit tim, ato vetëm sa e bëjnë dokumentacionin më të rëndë, dhe kanë pak përdorim praktik. Dhe është shumë e vështirë të përshkruash kërkesat për ergonomi në formën e kërkesave të përgjithshme; është më mirë t'i transferosh ato në ato funksionale. Për shembull, mund të formulohet kërkesa "Merr informacion për çmimin e një artikulli duke klikuar vetëm një buton". Për mendimin tim, kjo është akoma më afër kërkesave funksionale specifike, megjithëse ka të bëjë me ergonominë.Kërkesat për funksionet (detyrat) që kryen sistemi Kjo është pika shumë kryesore dhe kyçe që do të përcaktojë suksesin. Edhe nëse gjithçka tjetër është bërë në mënyrë të përsosur, dhe ky seksion është "3", atëherë rezultati i projektit do të jetë "3" në rastin më të mirë, ose edhe projekti do të dështojë krejtësisht. Me këto do të merremi më në detaje në artikullin e dytë, i cili do të përfshihet në numrin e 5-të të listës së postimeve. Është në këtë pikë që "rregulli i tre pronave të pretendimeve", për të cilin fola. Kërkesat për llojet e kolateralit

GOST dallon llojet e mëposhtme:

• Matematikore
• Informacion
• Gjuhësore
• Software
• teknike
• Metrologjike
• Organizative
• Metodike
• tjera…

Në pamje të parë, mund të duket se këto kërkesa nuk janë të rëndësishme. Në shumicën e projekteve, kjo është e vërtetë. Por jo gjithmonë. Kur të përshkruani këto kërkesa:

• Nuk janë marrë vendimet se cila gjuhë (ose cila platformë) do të përdoret për zhvillim;
• Sistemi ka kërkesa për një ndërfaqe shumëgjuhëshe (për shembull, rusisht / anglisht)
• Që sistemi të funksionojë, duhet të krijohet një nënndarje e veçantë ose të punësohen punonjës të rinj;
• Që sistemi të funksionojë tek Klienti, duhet të ketë ndryshime në metodat e punës dhe këto ndryshime duhet të specifikohen dhe planifikohen;
• Integrimi me çdo pajisje supozohet dhe i imponohen kërkesa (për shembull, certifikimi, pajtueshmëria, etj.)
• Situata të tjera janë të mundshme, gjithçka varet nga qëllimet specifike të projektit.

Seksioni 5. Përbërja dhe përmbajtja e punës për krijimin e sistemit

Seksioni 6. Procedura për kontrollin dhe pranimin e sistemit

Kërkesat e përgjithshme për pranimin e punës sipas fazave (lista e ndërmarrjeve dhe organizatave pjesëmarrëse, vendi dhe koha), procedura për miratimin dhe miratimin e dokumentacionit të pranimit; Unë rekomandoj fuqimisht që të merrni përgjegjësinë për procedurën e dorëzimit të punës dhe kontrollit të sistemit. Për këtë janë kërkesat e testueshme, por edhe prania e kërkesave të testueshme mund të mos jetë e mjaftueshme kur sistemi dorëzohet, nëse rendi i pranimit dhe dorëzimit të punimeve nuk është i përcaktuar qartë. Për shembull, një kurth i zakonshëm: sistemi është bërë, është plotësisht funksional, por Klienti, për disa arsye, nuk është i gatshëm të punojë në të. Këto arsye mund të jenë çdo: një herë e një kohë, qëllimet kanë ndryshuar, dikush është larguar, etj. Dhe ai thotë: “Meqenëse nuk po punojmë ende në sistemin e ri, do të thotë se nuk mund të jemi të sigurt se ai funksionon”. Pra, mësoni të identifikoni saktë fazat e punës, mënyrat për të kontrolluar rezultatet për këto faza. Për më tepër, këto metoda duhet të jenë të qarta për Klientin fillimisht. Nëse ato janë të fiksuara në nivelin e Termave të Referencës, atëherë mund t'i kontaktoni gjithmonë, nëse është e nevojshme, dhe të sillni punën me transferimin.

Seksioni 7. Kërkesat për përbërjen dhe përmbajtjen e punës për përgatitjen e objektit të automatizimit për vënien në punë të sistemit

Mund të ketë rregulla të tjera për futjen e informacionit të miratuar nga kompania (ose e planifikuar). Për shembull, informacioni rreth kontratës ishte futur më parë në një rresht teksti në një formë arbitrare, por tani numri kërkohet veçmas, data veç e veç, etj. Mund të ketë shumë kushte të tilla. Disa prej tyre mund të perceptohen me rezistencën e personelit, kështu që është më mirë të regjistrohen të gjitha rastet e tilla në nivelin e kërkesave për procedurën e futjes së të dhënave Ndryshimet që duhet të bëhen në objektin e automatizimit.

Krijimi i kushteve për funksionimin e objektit të automatizimit, në të cilat garantohet përputhshmëria e sistemit të krijuar me kërkesat që përmban TZ Çdo ndryshim që mund të kërkohet. Për shembull, kompania nuk ka një rrjet lokal, një flotë të vjetëruar kompjuterësh në të cilët sistemi nuk do të funksionojë.

Ndoshta disa informacione të nevojshme janë përpunuar në letër dhe tani duhet të futen në sistem. Nëse kjo nuk është bërë, atëherë asnjë modul nuk do të funksionojë, etj.

Ndoshta diçka është thjeshtuar, por tani është e nevojshme të merret parasysh më në detaje, përkatësisht, dikush duhet të mbledhë informacione sipas rregullave të caktuara.

Kjo listë mund të jetë e gjatë, shikoni rastin konkret të projektit tuaj Krijimi i njësive dhe shërbimeve të nevojshme për funksionimin e sistemit;

Koha dhe procedura për stafin dhe trajnimin e stafit Ne kemi folur tashmë për këtë më herët. Ndoshta sistemi po zhvillohet për një strukturë ose lloj aktiviteti të ri që nuk ekzistonte më parë. Nëse nuk ka personel të përshtatshëm, madje edhe të trajnuar, atëherë sistemi nuk do të funksionojë, pavarësisht se sa me kompetencë nuk është ndërtuar.

Seksioni 8. Kërkesat për dokumentacion

Konsideroni se si do të paraqiten manualet e përdorimit.

Ndoshta Klienti ka pranuar standardet e korporatës, ndaj është e nevojshme t'u referoheni atyre.

Injorimi i kërkesave të dokumentacionit shumë shpesh çon në pasojat më të papritura në projekte. Për shembull, gjithçka është bërë dhe gjithçka funksionon. Përdoruesit dinë gjithashtu se si të punojnë. Nuk jemi pajtuar dhe as nuk kemi folur fare për dokumentacionin. Dhe befas, kur puna dorëzohet, një nga menaxherët e lartë të Klientit, i cili as nuk ka marrë pjesë në projekt, por merr pjesë në pranimin e punës, të pyet: "Ku janë manualet e përdorimit?" Dhe ai fillon t'ju bindë se nuk ishte e nevojshme të bini dakord për disponueshmërinë e manualeve të përdoruesit, kjo "në vetvete" supozohet se nënkuptohet. Dhe kjo është e gjitha, ai nuk dëshiron të marrë punën tuaj. Me shpenzimet e kujt do të zhvilloni udhëzime? Shumë skuadra tashmë kanë rënë në këtë goditje.

Seksioni 9. Burimet e zhvillimit

Rekomandime sipas GOST	Çfarë duhet bërë për këtë në praktikë
Dokumentet dhe materialet informative (studimi i fizibilitetit, raportet për punët e kryera kërkimore, materialet informative për sistemet analoge vendase, të huaja, etj.), mbi bazën e të cilave është zhvilluar TK dhe të cilat duhet të përdoren gjatë krijimit të sistemit, duhet të renditen.	Të them të drejtën, kjo është më afër tekstit. Sidomos kur flitet për efektin ekonomik dhe gjëra të tjera që praktikisht është e pamundur të llogariten objektivisht. ato. sigurisht që është e mundur, do të jetë më tepër në letër, thjesht teorikisht.

Prandaj, është më mirë t'i referohemi thjesht raportit të anketës, kërkesave të personave kyç.

Dhe kështu, ne kemi shqyrtuar të gjitha seksionet që mund të përfshihen në Termat e Referencës. “Maj” dhe jo “I detyruar” pikërisht sepse çdo dokument duhet të zhvillohet për të arritur një rezultat. Prandaj, nëse është e qartë për ju se një pjesë e veçantë nuk do t'ju afrojë me rezultatin, atëherë nuk keni nevojë për të dhe nuk keni nevojë të humbni kohë për të.

Por pa gjënë kryesore: kërkesat funksionale, asnjë detyrë e vetme teknike nuk është e plotë. Dua të vërej se në praktikë, terma të tillë të referencës hasen dhe si! Ka figura që do të jenë në gjendje të hollojnë ujin në të gjitha seksionet, të përshkruajnë kërkesat e përgjithshme në terma të përgjithshëm, dhe dokumenti rezulton të jetë shumë i rëndë, dhe ka shumë fjalë të zgjuara në të, dhe madje edhe klientit mund t'i pëlqejë (d.m.th. ai do ta miratojë atë). Por puna në të mund të mos funksionojë, d.m.th. ka pak përfitim praktik prej tij. Në shumicën e rasteve, dokumente të tilla lindin kur ju duhet të merrni shumë para posaçërisht për Termat e Referencës, dhe kjo duhet bërë shpejt dhe pa hyrë në detaje. Dhe sidomos nëse dihet se gjërat nuk do të shkojnë më tej, ose do ta bëjnë njerëz krejtësisht të ndryshëm. Në përgjithësi, vetëm për zhvillimin e buxhetit, veçanërisht të shtetit.

Në artikullin e dytë, do të flasim vetëm për seksionin 4 "Kërkesat e sistemit", dhe konkretisht do të formulojmë kërkesat për arsye të qartësisë, specifikës dhe testueshmërisë.

Pse kërkesat duhet të jenë të qarta, specifike dhe të testueshme.

Sepse praktika tregon: në fillim, shumica e specifikimeve teknike që zhvillohen nga specialistë ose rezultojnë të mos jenë të kërkuara (nuk korrespondojnë me realitetin), ose bëhen problem për atë që duhet të zbatojë, sepse Klienti fillon të manipulojë terma dhe kërkesa jo specifike. Unë do të jap disa shembuj se çfarë frazash janë hasur, në çfarë ka çuar kjo dhe më pas do të përpiqem të jap rekomandime se si të shmangen probleme të tilla.

Lloji i kërkesës

Formulimi i gabuar

Termat e referencës janë materiali fillestar për krijimin e një sistemi informacioni ose produkti tjetër. Prandaj, termat e referencës (shkurtuar si TK) duhet para së gjithash të përmbajnë kërkesat themelore teknike për produktin dhe t'i përgjigjen pyetjes se çfarë duhet të bëjë ky sistem, si të funksionojë dhe në çfarë kushtesh.

Si rregull, faza e hartimit të një detyre teknike paraprihet nga një studim i fushës lëndore, i cili përfundon me krijimin e një raporti analitik. Është raporti analitik (ose shënimi analitik) që përbën bazën e dokumentit të Termave të Referencës.

Nëse kërkesat e klientit mund të përmblidhen në raport dhe të ilustrohen me diagrame UML, termat e referencës duhet të përshkruajnë në detaje të gjitha kërkesat funksionale dhe të përdoruesit për sistemin. Sa më të detajuara të jenë termat e referencës, aq më pak situata të diskutueshme do të lindin midis klientit dhe zhvilluesit gjatë testeve të pranimit.

Kështu, termat e referencës janë një dokument që lejon zhvilluesin dhe klientin të paraqesin produktin përfundimtar dhe më pas të kontrollojnë për përputhjen me kërkesat.

Standardet udhëzuese për të shkruar një detyrë teknike janë GOST 34.602.89 "Kushtet e referencës për krijimin e një sistemi të automatizuar" dhe GOST 19.201-78 "Kushtet e referencës. Kërkesat për përmbajtjen dhe dizajnin ". Standardi i parë është menduar për zhvilluesit e sistemeve të automatizuara, i dyti për mjetet softuerike (ne diskutuam ndryshimin midis këtyre serive në artikullin "Çfarë është GOST").

Pra, më poshtë paraqesim një listë dhe përshkrim të seksioneve që duhet të përmbajë detyra teknike në përputhje me GOST.

GOST 19.201-78 Termat e referencës. Kërkesat për përmbajtjen dhe dizajnin	GOST 34.602.89 Kushtet e referencës për krijimin e një sistemi të automatizuar
1. Hyrje	1. Informacion i përgjithshëm
2. Baza për zhvillim
3. Qëllimi i zhvillimit	2. Qëllimi dhe qëllimet e sistemit
	3. Përshkrimi i objektit të automatizimit
4. Kërkesat për programin ose produktin softuer	4. Kërkesat e sistemit
4.1. Kërkesat e performancës	4.2. Kërkesat për funksionet (detyrat) që kryen sistemi
	4.1. Kërkesat e sistemit në tërësi
	4.1.1. Kërkesat për strukturën dhe funksionimin e sistemit
	4.1.3. Treguesit e emërimit
4.2. Kërkesat e besueshmërisë	4.1.4. Kërkesat e besueshmërisë
	4.1.5. Kërkesat e sigurisë
	4.1.6. Kërkesat estetike ergonomike dhe teknike
4.3. Kushtet e funksionimit	4.1.2. Kërkesat për numrin dhe kualifikimet e personelit të sistemit dhe mënyrën e punës së tyre
	4.19. Kërkesat për mbrojtjen e informacionit nga aksesi i paautorizuar
	4.1.10. Kërkesat për sigurinë e informacionit në rast aksidentesh
	4.1.11. Kërkesat për mbrojtje nga ndikimet e ndikimeve të jashtme
	4.1.12. Kërkesat për lejimin e patentës
	4.13. Kërkesat për standardizimin dhe unifikimin
4.4. Kërkesat për përbërjen dhe parametrat e mjeteve teknike	4.1.8. Kërkesat për funksionimin, mirëmbajtjen, riparimin dhe ruajtjen e komponentëve të sistemit
4.5. Kërkesat për përputhshmërinë e informacionit dhe softuerit
4.6. Kërkesat për etiketim dhe paketim
4.7. Kërkesat e transportit dhe ruajtjes	4.1.7. Kërkesat për transportueshmëri për sistemet celulare
4.8. Kërkesa të veçanta	4.14. Kërkesa shtesë
	4.3. Kërkesat për llojet e kolateralit
5. Kërkesat për dokumentacionin e softuerit	8. Kërkesat për dokumentacion
6. Treguesit tekniko-ekonomikë
7. Fazat dhe fazat e zhvillimit	5. Përbërja dhe përmbajtja e punës për krijimin e sistemit
8. Procedura e kontrollit dhe pranimit	6. Procedura e kontrollit dhe pranimit të sistemit
	7. Kërkesat për përbërjen dhe përmbajtjen e punës për përgatitjen e objektit të automatizimit për vënien në punë të sistemit
	9. Burimet e zhvillimit

Pra, dokumenti Termat e Referencës duhet, në fakt, të pasqyrojë të gjitha kërkesat për produktin e projektuar, të theksuara në fazën e studimit analitik të objektit të automatizimit.

Bazuar në tabelën e mësipërme, ne mund të veçojmë seksionet kryesore të detyrës teknike:

• Informacione të përgjithshme rreth sistemit (programit);
• Qëllimi, qëllimet dhe objektivat e sistemit (programit);
• Kërkesat e sistemit (kërkesat funksionale, kërkesat e përdoruesve, kërkesat e sistemit në tërësi, etj.);
• Kërkesat për llojet e kolateralit;
• Kërkesat për dokumentacion;
• Fazat dhe fazat e zhvillimit;
• Procedura për kontrollin dhe pranimin e sistemit (programit).

Informacion i pergjithshem
Ky seksion i dokumentit Termat e Referencës duhet të përmbajë emrin e plotë të sistemit dhe të gjitha opsionet për shkurtesat që do të përdoren në zhvillimin e dokumentacionit.

Shembull:

"Në këtë dokument, sistemi i informacionit që krijohet quhet" Dritarja e vetme e aksesit në burimet arsimore", shkurtuar si SW.
Dritarja e vetme e sistemit për qasje në burimet arsimore mund të referohet si Dritarja e vetme ose Sistemi në vijim në këtë dokument.

Gjithashtu, kjo duhet të përfshijë nënseksione që informojnë detajet e organizatave të përfshira në zhvillim (Klienti dhe Kontraktori).

Në nënseksionin "Bazat e zhvillimit" të dokumentit Termat e Referencës renditen dokumentet kryesore mbi bazën e të cilave kryhen këto punime. Për shembull, për një sistem të porositur nga qeveria e një vendi ose agjencie tjetër shtetërore, ligjet, dekretet dhe urdhrat e qeverisë duhet të specifikohen.

Një listë e termave dhe shkurtesave duhet të jetë gjithashtu një pjesë integrale e dokumentit të Termave të Referencës. Termat dhe shkurtesat paraqiten më së miri si një tabelë me dy kolona "Afati" dhe "Forma e plotë".

Termat dhe shkurtesat janë renditur sipas alfabetit. Para së gjithash, është zakon të jepet një dekodim i termave dhe shkurtesave në gjuhën ruse, pastaj ato në gjuhën angleze.

Qëllimi dhe qëllimet e sistemit

Ky seksion i dokumentit Termat e Referencës duhet të përmbajë qëllimin dhe qëllimet e krijimit të sistemit.

Shembull:

"Sistemi i informacionit" Dritarja e vetme e aksesit në burimet arsimore "është krijuar për t'u ofruar përdoruesve informacion të plotë, operacional dhe të përshtatshëm në lidhje me sistemin arsimor të Federatës Ruse, organizatat që kryejnë funksionin e institucioneve arsimore.

Qëllimi kryesor i sistemit është formimi i një mjedisi të unifikuar informacioni dhe automatizimi i proceseve të biznesit të institucioneve arsimore të Federatës Ruse.

Krijimi i sistemit të informacionit "Single Window" duhet të sigurojë:

• ofrimi i përdoruesve me një gamë të gjerë burimesh informacioni;
• rritja e nivelit të sigurisë së informacionit;
• përmirësimi i efikasitetit të institucioneve dhe departamenteve arsimore duke optimizuar një sërë procesesh biznesi;
• rritjen e efikasitetit të procesit të ndërveprimit të sistemeve dhe shërbimeve të informacionit brenda departamentit.

Krijimi i Sistemit do të reduktojë kostot operative si rezultat i rritjes së efikasitetit të departamentit.

Kërkesat e sistemit

Ky seksion i Deklaratës së Punës synon të përshkruajë kërkesat themelore funksionale të sistemit. Kjo është pjesa më e rëndësishme e detyrës teknike, pasi do të jetë argumenti juaj kryesor në mosmarrëveshjet me Klientin në procesin e vënies në funksion të sistemit. Prandaj, është e nevojshme t'i qasemi me kujdes shkrimit të tij.

Dokumenti i Termave të Referencës duhet të përmbajë të gjitha kërkesat e identifikuara në fazën e analizës së objektit të automatizimit. Është mirë të theksohen proceset kryesore të biznesit, të cilat duhet të shpalosen përmes përshkrimit të kërkesave funksionale.

Shembull:

"4.1 Procesi i biznesit" Sigurimi i informacionit në lidhje me institucionet arsimore të Federatës Ruse

Në këtë proces biznesi dallohen pjesëmarrësit e mëposhtëm:

Moderator - një punonjës i departamentit, i cili është pjesë e personelit të shërbimit të sistemit, i cili është përgjegjës për korrektësinë e të dhënave të dhëna

Përdorues - një qytetar që ka nevojë për informacion në lidhje me punën e institucioneve arsimore të Federatës Ruse.

4.1.1 Regjistrimi i një institucioni arsimor në Sistem

Regjistrimi i një institucioni arsimor të Federatës Ruse kryhet nga një punonjës përgjegjës i institucionit ("Dekreti i Qeverisë ...").

Procesi i regjistrimit të një institucioni arsimor përfshin hapat e mëposhtëm:

• Autori krijon një shënim për organizatën;
• Autori fut të dhënat e organizatës;
• Sistemi kontrollon për një licencë për këtë organizatë

• Nëse licenca ekziston në bazën e të dhënave, Sistemi i dërgon një mesazh Autorit për regjistrimin e suksesshëm;
• Nëse licenca nuk gjendet në bazën e të dhënave, Sistemi i dërgon një mesazh Autorit për mungesën e një licence për këtë organizatë.

Nëse koha e lejon, informacioni i dhënë në këtë seksion duhet të zbulohet më plotësisht në aneksin e dokumentit Termat e Referencës. Në shtojcën e termave të referencës, mund të sillni një formular ekrani dhe më poshtë të përshkruani të gjitha ngjarjet që janë të pranishme në të (krijimi, shikimi, redaktimi, fshirja, etj.).

Kërkesat për sistemin në tërësi përfshijnë një zbulim të arkitekturës së tij me një përshkrim të të gjitha nënsistemeve. Kjo pjesë e Termave të Referencës duhet të përshkruajë kërkesat për integrimin e sistemit me produkte të tjera (nëse ka). Më tej, termat e referencës duhet të përfshijnë:

• kërkesat për mënyrat e funksionimit të sistemit
• treguesit e destinacionit
• kërkesat e besueshmërisë
• kërkesat e sigurisë
• kërkesat për numrin dhe kualifikimet e personelit dhe mënyrën e punës së tyre
• kërkesat për mbrojtjen e informacionit
• kërkesat për sigurinë e informacionit në rast aksidentesh
• kërkesat e pastërtisë së patentës
• kërkesat për standardizimin dhe unifikimin
• etj.

Kërkesat për llojet e kolateralit

Në këtë seksion të dokumentit, Termat e Referencës duhet të paraqesin kërkesat për mbështetje matematikore, informative, gjuhësore, softuerike, teknike dhe lloje të tjera (nëse ka).

Kërkesat për dokumentacion

Seksioni "Kërkesat për dokumentacion" i detyrës teknike përfshin një listë të dokumenteve të projektimit dhe operacional që duhet t'i sigurohen klientit.

Ky seksion i detyrës teknike është po aq i rëndësishëm sa përshkrimi i kërkesave funksionale, prandaj, nuk duhet kufizuar në shprehjen "Klienti duhet të pajiset me të gjithë dokumentacionin në përputhje me GOST 34". Kjo do të thotë që ju duhet të siguroni të gjithë paketën e dokumenteve duke përfshirë "Formularin", "Pasaportën" etj. Shumica e dokumenteve nga lista e specifikuar në GOST 34.201-89 nuk janë të nevojshme as nga ju, as nga klienti, prandaj është më mirë që menjëherë të bini dakord për listën në fazën e zhvillimit të dokumentit Termat e Referencës.

Paketa minimale e dokumenteve zakonisht përfshin:

• Detyrë teknike;
• Lista e projekt projektimit (teknik);
• Shënim shpjegues për projektin teknik;
• Përshkrimi i organizimit të bazës së informacionit;
• Udhëzues Përdorues;
• Udhëzues Administratori;
• Programi dhe metodologjia e testimit;
• Raporti i testit të pranimit;
• Çertifikatë e përfundimit

Është më mirë të paraqitet lista e dokumenteve në termat e referencës në formën e një tabele, e cila tregon emrin e dokumentit dhe standardin mbi bazën e të cilit duhet të zhvillohet.

Fazat dhe fazat e zhvillimit

Në këtë seksion të dokumentit, Termat e Referencës duhet të japin informacion për të gjitha fazat e punës që do të kryhet.

Përshkrimi i skenës duhet të përfshijë emrin, kohën, përshkrimin e punës dhe rezultatin përfundimtar.

Procedura e kontrollit dhe pranimit të sistemit

Në këtë seksion të dokumentit Termat e Referencës, është e nevojshme të tregohet dokumenti mbi bazën e të cilit duhet të kryhen testet e pranimit.

Nëse është e nevojshme, termat e referencës mund të plotësohen nga seksione të tjera ose të reduktohen duke hequr artikujt e papërshtatshëm.

Kur ndryshoni strukturën e detyrës teknike, për të shmangur situatat e konfliktit, duhet të bihet dakord me klientin përpara zhvillimit të dokumentit.

Një urdhër për zhvillimin e një identiteti të korporatës, dizajn paketimi, logo ose faqe interneti shoqërohet gjithmonë me përgatitjen dhe ekzekutimin e dokumentacionit përkatës - një kontratë, një përmbledhje dhe një detyrë teknike (TOR). Krijimi i specifikacionit teknik është faza e parë e punës së përbashkët të klientit dhe kontraktorit.

Një nga mënyrat më të zakonshme për të ulur kostot dhe buxhetin për një projekt është ta bëni vetë. shkrimi TK (detyrë teknike) .

Sidoqoftë, pa ndonjë përvojë, është mjaft e vështirë të hartohet një specifikim teknik kompetent, i cili do të jetë i qartë si për kontraktorin ashtu edhe për klientin.

Në termat e referencës, është e nevojshme të përshkruhen saktë dhe qartë kërkesat për objektin e punës, të përcaktohen parametrat teknikë, qëllimi i objektit, të përgatitet përbërja e dokumentacionit të nevojshëm të projektit, të përcaktohet koha dhe procedura për kryerjen e punës. .

Para se të vazhdohet me zhvillimin e specifikimeve teknike, është e nevojshme të kryhen kërkime, llogaritjet paraprake dhe të mblidhen informacionet fillestare.

Krijimi i një detyre teknike është një proces kompleks, i cili është më i mirë për zbatimin e profesionistëve, përveç kësaj, "marka juaj mbretërore" ka detyra më të rëndësishme dhe prioritare sesa të shkruani një detyrë teknike.

Detyra teknike është

Detyrë teknike - ky është dokumenti themelor i të gjithë projektit dhe marrëdhëniet midis klientit dhe kontraktorit, i cili ju lejon të përcaktoni qartë rendin e punës, përgjegjësitë e palëve dhe kohën e projektit.

Kushtet e zbatimit dhe suksesi i projektit në tërësi do të varen nga sa saktë, saktë dhe qartë janë hartuar kushtet e referencës për kontraktorin.

Llojet e specifikimeve teknike (specifikimet teknike)

Termat e referencës janë hapi i parë drejt zbatimit të çdo projekti. Ekzistojnë lloje të panumërta të specifikimeve teknike për kryerjen e punës:
- termat e referencës për zhvillimin e faqes;
- termat e referencës për zhvillimin e një logoje;
- termat e referencës për zhvillimin e programit;
- termat e referencës për zhvillimin e identitetit të korporatës;
- termat e referencës për zhvillimin e dizajnit;
- termat e referencës për zhvillimin e emrit të shoqërisë;
- termat e referencës për promovimin e faqes në internet, etj.

Pavarësisht se kë keni zgjedhur për rolin e ekzekutuesit të projektit - një profesionist i pavarur apo një agjenci marke, përpara se të filloni punën në një projekt, është e nevojshme të analizoni dhe përpunoni sasi të mëdha informacioni heterogjen. Studioni të dhënat në lidhje me qëllimet dhe objektivat e projektit, qëllimet strategjike dhe aktuale të kompanisë, kërkesat për objektin e punës, dëshirat e klientit, afatet për dorëzimin e projektit të përfunduar dhe rezultatet e pritura. Më pas, ju duhet të mblidhni këtë informacion së bashku, të strukturoni të dhënat dhe t'i jepni kontraktorit në formën e një detyre teknike.

Si rregull, zhvillimi i specifikimeve teknike është detyrë e menaxherit të projektit. Askush përveç klientit nuk do të përshkruajë në mënyrën më të mirë idetë, parimet e punës, qëllimet e projektit dhe aktivitetet e kompanisë. Ky përshkrim duhet të jetë sa më i qartë dhe duhet të paraqitet në formën e një historie të përgjithshme për kompaninë dhe markën e saj.

Struktura e detyrës teknike

Struktura e detyrës teknike (formulari i detyrës teknike) është si më poshtë:

1. Objektivat e projektit
Në TOR, është e nevojshme të tregohet se cilat qëllime dëshiron të arrijë kompania duke përdorur rezultatet e projektit të përfunduar. Qëllime të tilla, për shembull, mund të jenë: lëshimi i një produkti të ri, riemërtimi i një kompanie ose marke tregtare, fushata reklamuese, etj.
2. Përshkrimi i kompanisë së klientit
- Fusha e veprimtarisë dhe shkalla e shoqërisë, misioni dhe pozicioni i saj në treg;
- Përshkrimi i portofolit të markës së kompanisë - me cilat marka punon kompania;
- Lista e kompanive kryesore konkurruese;
- Një listë e avantazheve kryesore konkurruese të kompanisë dhe USP (propozim unik i shitjes).
3. Përshkrimi i situatës dhe tendencat më të fundit të tregut për të cilën po zhvillohet marka
- Segmenti i çmimeve të produktit ose shërbimeve të kompanisë;
- Portreti i konsumatorit (mosha, gjinia, të dhënat gjeografike, niveli social i audiencës së synuar);
- Qëllimet taktike dhe strategjike të marketingut të kompanisë (për një periudhë 1 deri në 3 vjet);
- Modeli i sjelljes së konsumatorit dhe përshkrimi i situatave në të cilat konsumatori bën një blerje;
- Përshkrimi i karakteristikave kryesore të markës ekzistuese, koncepti i pozicionimit të saj, slogani, komunikimet e marketingut, të kërkuara në rast riemërtimi.
4. Referencat
Një listë me shembuj të punimeve të ngjashme që klienti i pëlqen në kontekstin e këtij projekti.
5. Kërkesat
Në këtë seksion është e nevojshme të regjistrohen të gjitha kërkesat teknike dhe funksionale për projektin. Si dhe kërkesat dhe dëshirat e klientit për grafikë, tekst, ngjyra, stil, shkronja,