Šta uključuje tehnički zadatak. Postupak izrade tehničkih specifikacija

U projektnom zadatku, naručilac mora navesti sve svoje zahtjeve za predloženi predmet nabavke. posebno:

savjet:Vrijedno je početi pripremati projektni zadatak unaprijed. Ovo će smanjiti rizik da se prekrši vrijeme objavljivanja dokumentacije nabavke u EIS-u. Uostalom, ugovornoj službi (upravljaču ugovora) potrebno je od nekoliko dana do nekoliko sedmica da izradi kvalitetan tehnički zadatak, u zavisnosti od tehničke složenosti predmeta nabavke.

savjet: Kada sastavljate tehnički zadatak, logično je da se rukovodite:

• GOSTs. Na primjer, prilikom kreiranja automatiziranog sistema - GOST 34.602-89 „Informacijska tehnologija. Set standarda za automatizovane sisteme. Projektni zadatak za kreiranje automatiziranog sistema“;

• metodološka uputstva (preporuke) osnivača. Na primjer, Ministarstvo kulture Rusije izradilo je Metodološke smjernice za izradu tehničkih specifikacija za nabavku u okviru ciljnog programa „Kultura Rusije (2012-2018)“ (pismo Ministarstva kulture Rusije od 25. januara , 2013. br. 446-01-56 / 10-NM) ...

Izrada tehničkog zadatka je kreativan zadatak koji od kupca zahtijeva dovoljan utrošak vremena i truda. Međutim, integrirani pristup njegovom rješenju, kao i pažljiv odnos prema svakoj kupovini glavni su uvjet za efikasnu nabavku.

1. Opće informacije o kupcu

U ovom dijelu vrijedi navesti sljedeće podatke o kupcima:

• Ime;

• lokacija kupca;

• raspored.

Važno je navesti lokaciju i radno vrijeme kupca kada, prema uslovima ugovora, učesnik mora isporučiti robu (obavljati radove, pružati usluge) na teritoriju kupca.

Takođe, ovaj odeljak može da sadrži informacije o zajedničkim ili centralizovanim nabavkama, kao io angažovanju stručnjaka (stručne organizacije).

2. Opće informacije o kupovini

Ovdje vrijedi istaći:

• puni naziv predmeta nabavke,

• odabrani metod za određivanje dobavljača (izvođača, izvođača),

• izvor finansiranja.

Ovaj odjeljak također može sadržavati informacije o terminima i skraćenicama koje se koriste u opisu poslova. Ove informacije mogu se urediti, na primjer, u obliku tabele.

Termini i skraćenice	Definicija
ON	Softverski proizvod "Plata-Budžet" koji je predmet kupovine
Kupac	Državna ustanova "Alfa"
Ekspert	Specijalista koji ima posebna znanja iz oblasti računovodstva i oporezivanja u budžetskoj sferi, kadrovskih i pravnih pitanja, sa visokom stručnom spremom

3. Opis predmeta nabavke

Ovaj odjeljak bi trebao opisati sljedeće što je moguće potpunije i tačnije.

1. Kvalitativne, tehničke i funkcionalne karakteristike. Kvalitet robe mora biti u skladu sa zakonskim zahtjevima i uslovima ugovora.

U tom slučaju, kupac pri opisivanju tehničkih i kvalitetnih karakteristika mora koristiti standardne indikatore (zahtjeve, konvencije i terminologiju). Da biste to učinili, morate se rukovoditi obaveznim zahtjevima, posebno GOST-ovima, SNiP-ovima, građanskim zakonodavstvom (članovi 469, 721 Građanskog zakonika Ruske Federacije). Na primjer, zahtjevi za kvalitetu prehrambenih proizvoda utvrđeni su Saveznim zakonom od 2. januara 2000. br. 29-FZ.

Ako se standardni indikatori ne mogu preuzeti iz tehničkih propisa, standarda (drugih zakonskih akata o tehničkoj regulativi), onda je potrebno opravdati upotrebu drugih indikatora (zahtjevi, oznake, terminologija).

savjet: Nije potrebno koristiti tačne vrijednosti indikatora. Bolje ih je zamijeniti uvjetima s maksimalnim i/ili minimalnim vrijednostima, kao i vrijednostima koje se ne mogu promijeniti. Odnosno, takvi pokazatelji koji će omogućiti učesnicima da utvrde da li kupljena roba (radovi, usluge) ispunjavaju utvrđene zahtjeve. Na primjer, kada kupujete sistemsku jedinicu, bilo bi ispravnije naznačiti u opisu poslova „Kapacitet tvrdog diska - ne manje 500 GB “, a ne “ Kapacitet tvrdog diska - 500 GB “.

Ovo je navedeno u dijelu 2 člana 33 Zakona br. 44-FZ i objašnjeno u pismu Ministarstva za ekonomski razvoj Rusije od 10. decembra 2014. br. D28i-2796.

2. Karakteristike performansi (ako je potrebno).

3. Ukupan broj robe (obim posla, usluga). Kada to nije moguće, kupac može navesti cijenu jedinice rada (usluge).

4. Zahtjevi za pakovanje. Ovo je dodatni uslov. U projektnom zadatku možete navesti, na primjer, da pakovanje robe mora osigurati njenu sigurnost tokom transporta i skladištenja.

5. Uslovi za sigurnost predmeta nabavke.

6. Uslovi i postupak za isporuku robe, obavljanje poslova, pružanje usluga. Posebno je potrebno odrediti mjesto isporuke robe (izvođenje radova, pružanje usluga). U ovom slučaju možete odrediti:

• specifična adresa za dostavu;

• raspon (alternativnih) tačaka isporuke, u okviru kojih učesnik mora navesti određenu adresu u aplikaciji (na primjer, unutar granica Moskve).

Ovo je neophodno kako bi prilikom podnošenja prijava učesnici imali ideju gde treba da isporuče robu (gde pružiti uslugu ili obaviti posao). Tada će, kada odluče da podnesu prijavu, shvatiti da li će moći da ispune narudžbu na ovom konkretnom mestu. Kupac će se zauzvrat zaštititi od rizika da će pobjednički ponuđač odbiti da izvrši.

7. Garantni rok i garantni servis(dio 4 člana 33 Zakona br. 44-FZ). Garantni rok mora biti postavljen u danima, mjesecima i godinama.

Nakon toga, važno je propisati uslove garantnog servisa, odnosno kompletan spisak radnji dobavljača (izvođača, izvođača) na održavanju ili dovođenju predmeta nabavke u stanje koje zahteva kupac.

Na primjer, prilikom kupovine klima uređaja vrijedi odrediti garantni rok od najmanje dvije godine, tokom kojeg će dobavljač biti dužan da besplatno pregleda opremu u roku od tri dana od datuma otkrivanja kvara i otkloni kvar. uočena kršenja u njenom radu.

8. Ostale karakteristike koje su bitne pri opisivanju određene vrste proizvoda, posla, usluge. Dakle, prilikom kupovine proizvoda u zadatku, kupac mora obavezno naznačiti da mora biti nov i oslobođen prava trećih lica. To jest, niko ranije nije koristio ili popravljao proizvod. U suprotnom, kupac rizikuje da dobije polovni proizvod. Ovo je navedeno u tački 7. dijela 1. člana 33. Zakona br. 44-FZ.

Ukoliko je potrebno, projektni zadaci treba da sadrže i dodatne zahtjeve za predmet nabavke. To može biti:

• obuka osoblja;

• zahtjevi za instalaciju i puštanje u rad;

• servisno održavanje;

• usklađenost sa uzorkom itd.

Lista informacija i zahtjeva može varirati u zavisnosti od svakog konkretnog predmeta nabavke.

Primjer opisa predmeta nabavke

U skladu sa terminskim planom Državne ustanove „Alfa“, nabavka partije papira za kancelarijsku opremu predviđena je za maj 2016. godine. Prilikom pripreme za elektronsku aukciju, ugovorni rukovodilac A.S. Glebova je počela da priprema dokumentaciju za nabavku, posebno napravljenu tehnički zadatak .

Pažnja! Informacije o objektu koje se ne odražavaju u projektnom zadatku, učesnik ima pravo ne uzeti u obzir i ne ispuniti.

Ukoliko proizvod (rad, usluga) koji je ponudio pobjednik ne odgovara kupcu, ali u isto vrijeme odgovara projektnom zadatku, on nema pravo odbiti sklapanje ugovora.

savjet:Vrijedi koristiti kao izvor informacija:

• ranije sklopljeni ugovori,

• javno dostupni izvori (katalozi, cjenovnici, reklamne brošure, itd.),

• komercijalne ponude,

• informacije sa interneta.

Sve će to pomoći da se u projektnom zadatku odraze upravo one karakteristike proizvoda (rad, usluga) koje su potrebne kupcu.

Pažnja! Ukoliko naručilac u dokumentaciji o nabavci navede podatke koji mogu dovesti do ograničenja broja učesnika, postoji rizik od administrativne odgovornosti. Dakle, službenici (rukovodilac ugovora, zaposleni u ugovornoj službi) mogu biti kažnjeni novčanom kaznom u iznosu od 1 posto početne (maksimalne) ugovorne cijene (NMCK), ali ne manje od 10.000 rubalja. i ne više od 50.000 rubalja. (dio 4.1 člana 7.30 Zakona o upravnim prekršajima Ruske Federacije).

Pažnja!Prilikom opisa predmeta nabavke nemoguće je navesti nazive proizvođača, žigove, uslužne oznake itd. To će dovesti do ograničenja konkurencije i, kao rezultat, kršenja zakona o nabavkama. Izuzeci - opis poslova može sadržavati spominjanje zaštitnih znakova, ako je potrebno:

• označavaju sredstva rada koja se koriste u obavljanju poslova ili usluga, ali ne kao predmet ugovora. U ovom slučaju, preduslov je navođenje teksta "ili ekvivalenta";

• kupiti robu potrebnu za interakciju s robom koju koristi kupac (na primjer, ažuriranje instaliranog softvera);

• nabavka rezervnih dijelova ili potrošnog materijala za mašine i opremu kupca.

Ovo je navedeno u stavu 1. dijela 1. člana 33. Zakona br. 44-FZ.

Pažnja! Nemoguće je u okviru jedne kupovine (jedne partije) kupovati različite proizvode (robe, radove, usluge) koji su međusobno tehnološki i funkcionalno nepovezani. Ovo će ograničiti broj učesnika. Tako, na primjer, u okviru jedne kupovine, usluge se ne mogu kombinirati:

• za zaštitu objekta uz pomoć sigurnosnih i protivpožarnih alarma i

• za održavanje samog alarma.

FAS Rusije je objasnio da se to odnosi na različita tržišta usluga. Uostalom, sigurnosne organizacije, u pravilu, ne servisiraju alarme. A ako takve usluge budu uključene u jednu nabavku, to će dovesti do ograničenja broja učesnika.

Ovo proizilazi iz 3. dijela člana 17. Federalnog zakona od 26. jula 2006. br. 135-FZ i objašnjeno je u pismima Ministarstva za ekonomski razvoj Rusije od 10. marta 2015. br. D28i-442, FAS Rusije od 21. maja 2014. br. AC / 20578/14 ...

Stoga, prilikom planiranja kupovine i izrade dokumentacije, kupac treba analizirati ovaj trenutak i, ako je potrebno:

• podijelite kupovinu u zasebne lotove,

• izraditi poseban tehnički zadatak za svaku partiju.

4. Zahtjevi za dobavljača (izvođača, izvođača)

U projektnom zadatku je potrebno propisati zahtjev da učesnici u nabavci moraju poštovati rusko zakonodavstvo. To može biti, na primjer, informacija o dostupnosti licence za određenu vrstu djelatnosti.

Osim toga, u nekim slučajevima, Vlada Ruske Federacije može utvrditi dodatne zahtjeve za učesnike nabavke, posebno u pogledu dostupnosti finansijskih i materijalnih resursa, radnog iskustva sličnog predmetu ugovora (dio 2. člana 31. Zakona). br. 44-FZ). Dakle, u Uredbi Vlade Ruske Federacije od 4. februara 2015. broj 99, postoje dodatni zahtjevi za učesnike u nabavci radova na očuvanju objekata kulturnog naslijeđa. Učesnik u takvoj nabavci mora dati podatke o ugovoru koji je izvršio bez kazni u posljednje tri godine. Iznos takvog ugovora mora biti najmanje 20 posto NMCK-a za čije se zaključenje vrši nabavka.

2 glasa

Dobar dan, dragi čitaoci. Rad na web stranici sa klijentom je uvijek težak. Klijent, po pravilu, želi ili „nešto cool“ ili „ništa neobično, neka bude kao svi ostali“. Apstraktni koncepti, slažem se. Ako vam je ovo prva narudžba, možda ćete se čak i oduševiti ovakvim riječima: "Kul, daju mi ​​kreativnu slobodu, mogu da radim šta hoću." Iz iskustva, ništa slično!

Kupac ima svoje razumijevanje "kul" i "kao i svi ostali". Možda nećete pogoditi, doći u pogrešno raspoloženje ili će klijent jednostavno odlučiti da „za takav novac ovaj momak (ili djevojka) može malo više da radi“. Kako se to ne bi dogodilo, danas ćemo razgovarati o tome kako se sastavlja projektni zadatak za razvoj stranice.

Akcioni plan za rad sa kupcem

Nađeš klijenta. On je spreman da uplati novac i bacite se na posao. Odakle početi i kako dalje?

• Prva komunikacija.

Dakle, dobili ste početne informacije: to se može dogoditi lično (ako sami nudite usluge) ili telefonom (kada vas klijent sam pronađe). Recimo da znate da kupac od vas želi internet prodavnicu, a on sam posjeduje lanac nakita. Nikada nemojte odmah započeti razgovor o web lokaciji. Zakažite termin da se svi zajedno pripremite i radite.

Pokušajte motivirati osobu da pogleda informacije na neki način kako bi imala jasniju ideju o tome šta želi od vas.

• Priprema i prvi brif.

Provjerite stranice za koje mislite da su prikladne za klijenta. Preuzmite neke šablone i recite im da vaša stranica može izgledati upravo ovako. Što više materijala, to bolje. Neka imate šta da pokažete kupcu, šta da imate jasnu predstavu šta voli, a šta ne. Izbjegavajte apstraktne koncepte iz serije: lijepo, praktično, kvalitetno. Svako ima svoje ideje o ovim kategorijama.

U idealnom slučaju, još bolje je ostaviti klijenta na dan sa ovim materijalima ili ih poslati poštom nekoliko dana prije sastanka. Iako u ovoj fazi kupac po pravilu nije posebno zainteresiran za portal. On je u stvari spreman da preseče matericu istine i da te natera da prepraviš i dodaš nešto novo, ali ni o čemu ne raspravlja unapred. Stoga je jedini izlaz pitati što više i zapisati svaku riječ.

• Priprema i potpisivanje tehničkih specifikacija.

Zapamtite, što je više papirića, to je svećenik čistiji. Zapišite, sastavite i potpišite sve što možete sa klijentom. Nakon toga, imaćete šta da pokažete. Općenito, kada propisujete TK, odmah zamislite da se vi i klijent niste složili i branite svoju nevinost na sudu.

Ne govorimo o superskupim projektima i nadam se da ćete imati sreće sa svojim klijentima. Ali jedan pedantan klijent može vam pokvariti raspoloženje na duže vrijeme. Htjet ćete pljunuti, odreći se novca, samo da se više ne sretnete s njim. To je razumljivo, ali ako se u početku pokažete kao profesionalac, sve temeljito proučite i pokažete se kao ugledna osoba, onda se to neće morati učiniti.

Jednom sam imao veliku sreću. Prije dolaska na sastanak, klijent je proučio pitanje, a sam je izradio ne samo kompetentnu tehničku specifikaciju, već i umjetnički zadatak. Odnosno, literarni i detaljan opis kako bi sve to trebalo izgledati. Mom iznenađenju nije bilo granice, na šta je on odgovorio: „Smatram da sam kupac, pre svega, treba da zna šta želi, a ne da muči stručnjake“. Nažalost, to je rijetko, pa moramo postavljati pitanja, propisivati ​​i odobravati.

• Razvoj i prijem.

Nakon što ste sve potpisali, možete pristupiti realizaciji projekta.

Šta ne bi trebalo biti u TK, a šta bi trebalo biti tamo

Zapravo, projektni zadatak ne bi trebao sadržavati upute o samom dizajnu. Napišeš da ćeš programeru nacrtati tastaturu na web stranici i onda krene - nije tako, hoću da bude u stilu stripa i onda dokaži da nisi jelen. Što se bolje pokažete kao profesionalac, to ćete imati manje pritužbi!

I sami znate u kom stilu i šta treba nacrtati. Vaš zadatak je poboljšati svijest o brendu ili vas motivirati da ostanete na tom i tom mjestu. Vaš je problem kako ćete implementirati ovaj zadatak. Nije bilo dovoljno da vas kupac nauči kako da napišete kod i da vam kaže koje alate da koristite.

Neka vaš TK sadrži frazu: "Sve što nije navedeno izvodi se po nahođenju izvođača." I nije potrebno ovu liniju praviti malim slovima. Neka razmišlja unaprijed, a ne počinje sanjati kada je projekat gotov. Naravno, možete i trebate napraviti male promjene. Dobra reputacija je garancija budućih kupaca, ali ponekad kupac može toliko da se pokvari sa svojim željama da ne želi da živi.

Još jednom, skrećem vam pažnju na činjenicu da TK ne bi trebao sadržavati apstraktne pojmove: "pogodno", "lijepo", "visoko kvalitetno" itd. Neka granice budu jasne: umjesto pogodnosti pretraživanja, bolje je napisati filtriranje po datumu ili materijalu.

I ne zaboravite na potpis. Sve je ozbiljno, kupac to mora razumjeti.

Generalno, toplo preporučujem da obratite pažnju na male stvari. Zamislite da vam dođe žena sa pjenom, žurno otkopča ogromnu jaknu tako da iz nje viri preveliki šal. Iz torbe vadi zgužvanu škrabotinu od 18 listova presavijenih sto puta, pokušava da je izgladi obližnjim predmetima. Crveno lice i nerazgovijetno: "Evo, napisao sam ovdje ukratko, napravio, ovako će izgledati vaš sajt, potpišite."

Druga varijanta. Mladić vam kuca u kancelariju, polako se svlači, vadi fasciklu iz portfelja, polako je otvara i polako vas poziva da pogledate samo jedan mali komad papira, pruža vam zlatnu olovku i nudi da potpišete ovaj dokument.

Neka mlada dama iz prvog primjera odradi titanski posao, pročitala je hiljadu knjiga, sama nacrtala 18 primjera i u principu sve sama uradila. Ona je sposobna da stvori nevjerovatno cool projekat koji će vašu kompaniju dovesti do prosperiteta i svjetske slave. A mladić iz drugog primjera ne zna ništa, štampao je uzorak sa interneta, što vam nikako ne odgovara.

Uvjeravam vas da će svaki klijent mučiti jadnu ženu prigovaranjem, željama i doradom, a mladićev projekat će biti prihvaćen, ako ne odmah, onda drugi put. Nije važno šta možete učiniti, već kako se ponašate i kakav utisak ostavljate.

Postoji GOST, prema kojem možete izraditi tehnički zadatak za razvoj stranice, a postoji i dugoročna praksa. Državni standardi ne odgovaraju uvijek realnosti života. Pokušajmo spojiti oba ova dijela.

Kada pišete tehnički zadatak za gradsku upravu ili legendarnog Vasilija Pupkina, sadržaj je najbolje uraditi u skladu sa GOST-om. Naučite ovo unaprijed.

izgleda ovako:

1. Glossary
2. Opće odredbe
3. Predmet razvoja
4. Svrha dokumenta
5. Zahtjevi za grafički dizajn stranice
6. Zahtjevi za dizajn web stranice
7. Procedura odobravanja koncepta projekta
8. Funkcionalni zahtjevi
9. Zahtjevi za prezentaciju stranice
10. Zahtjevi sistema upravljanja sadržajem
11. Zahtjevi za dijeljenje pristupa
12. Zahtjevi za vrste kolaterala
13. Zahtjevi za informacijsku podršku
14. Softverski zahtjevi
15. Zahtjevi za tehničku podršku
16. Jezički zahtjevi
17. Ergonomski i tehnički zahtjevi estetike
18. Uslovi za prijem i isporuku projekta
19. Zahtjevi za popunjavanje informacija
20. Zahtjevi za osobljem
21. Procedura obezbjeđenja distribucije
22. Postupak prijenosa stranice na tehnička sredstva kupca

Istina, morat ćete kreirati svoj dokument sa zadatkom drugačijim redoslijedom, ali, da pojednostavim percepciju, reći ću vam da slijedite ovaj plan. Na kraju ovog članka prilažem uzorak koji možete preuzeti i raditi s njim, na osnovu transkripta datog u ovom dijelu članka. Ovaj šablon je dobar jer ima sve, čak i ono što vam nikada ne treba. Ali morate to preraditi za sebe i precrtati svako nepotrebno sranje koje smatrate nepotrebnim.

Glossary

Prema GOST-u, dokument mora početi s pojmovnikom, ali zapravo ćete ga napisati na kraju. Ovdje morate navesti uslove koje ćete koristiti u radu sa kupcem. Govorite šta je hosting, web stranica i ostale gluposti. Sve ove stvari se mogu preuzeti sa interneta.

Međutim, pored same ove jeresi, potrebno je spomenuti uslove, po razumijevanju kojih vi i kupac možete imati različita mišljenja. Mislite jedno, ali on u riječi stavlja potpuno drugo značenje.

Opće odredbe

U ovom trenutku potrebno je odgovoriti na pitanje šta ćemo zapravo i zašto.

Predmet razvoja

Ono što ćemo uraditi je otprilike jasno. Klijent izdaje ove informacije gotovo odmah. Važnije je razumjeti operativnu svrhu stranice, odnosno kakvu korist čeka klijenta. Jasno je da svi kupci žele da ostvare profit putem stranice. Takva formulacija neće raditi.

Razmislite o tome kako će klijent zaraditi, šta mu je cilj. Ako je ovo internetska trgovina, onda bi se trebala baviti prodajom, ako je korporativna web stranica, onda im se sviđa lijepa fraza: „povećanje lojalnosti brendu“, informiranje o aktivnostima kompanije i tako dalje.

Svrha dokumenta

Ovdje objašnjavamo koliko je ovaj dokument važan. Pokazujemo da ovo nije jednostavan trik, ali wow! Koristimo pravne termine. Ovaj dio možete kopirati sa interneta, ali ne zaboravite pažljivo pročitati šta pišete!

Inače, u istom dijelu treba nagurati informaciju da sve ono o čemu ne razgovarate unaprijed sa klijentom ostaje na vašoj savjesti. Slobodni ste da radite šta god želite ako je "zaboravio", "predomislio se" ili "želi sve potpuno drugačije".

Zahtjevi za grafički dizajn stranice

Zahtjevi za dizajn web stranice

Ovdje trebate općenito opisati dizajn stranice, šta bi tu trebalo biti i kojih se tačaka treba pridržavati: korporativne boje, fontovi i tako dalje. Uopšteno govoreći, ne ulazite u detalje.

Procedura odobravanja koncepta projekta

U ovom dijelu ponovo zastrašujete klijenta pravnim terminima. Recite mu da ćete mu dati dizajn web stranice u obliku slike napravljene u Photoshopu. On je dužan da ga pogleda u određeno vrijeme. Nakon toga će vam biti dostavljene izmjene, a vi ćete zauzvrat razmisliti da li on nije jelen, a vi ćete se složiti i shvatiti koliko su te promjene logične i da li ćete preduzeti "ispravku".

Funkcionalni zahtjevi

Ovdje opisujete šta ćemo zapravo raditi. Opisujemo vizuelnu komponentu. Poglavlje se razvija u tri dijela: opisujemo glavnu stranicu, internu i strukturu stranice.

Budi pazljiv. Ovo je važna tačka u kojoj je bolje pisati više. Na primjer, trebali biste imati odjeljak "Srodne vijesti". Šta ćete učiniti: napisati algoritam koji će izračunati koji su članci najbliži temi, dati listu poslednjih pet članaka dodatih na sajt ili će autor teksta imati priliku da ubaci linkove u ovaj blok na svom posjedovati?

Zahtjevi za prezentaciju stranice

1. Struktura sajta: opisujemo koje će kategorije (naslovi) biti na sajtu.
2. Glavna stranica: najbolje sa shematskom slikom i opisom glavnih elemenata.
3. Interne stranice: isto kao u prethodnom pasusu. Šema i opis internih stranica.

Ako pravite online prodavnicu, ovdje možete natrpati šemu stranice za narudžbu, potvrdu plaćanja i tako dalje. Opišite sve stranice koje će se razlikovati od standardnog predloška.

Zahtjevi sistema upravljanja sadržajem

Moj blog je za ljude koji kreiraju WordPress stranice. Stoga neću pridavati ozbiljan značaj ovoj tački. Propisujemo da ćemo koristiti ovaj motor i to će biti dovoljno.

Ako ćete sami napraviti sistem upravljanja, onda je sve mnogo komplikovanije. Moraćemo ponovo da nacrtamo dijagrame i opišemo opšte zahteve, upravljanje sekcijama, sadržaj i podešavanja. Nacrtajte svaki element koji je drugačiji.

Zahtjevi za dijeljenje pristupa

Ovdje, zapravo, žele da znaju od nas kada i zašto će korisnik morati da se registruje. Koje rubrike zatvaramo, a koje od njih čitaoci mogu bezbedno koristiti. Ako je ovo stranica za posjetnice, informativna ili prodajna, bit će potpuno otvorena, a Vkontakte, na primjer, ima ograničen pristup osobnoj stranici i može se izvršiti samo nakon unosa korisničkog imena i lozinke.

Zahtjevi za vrste kolaterala

Zahtjevi za informacijsku podršku

Ovaj dio je kreiran jednostavno da pokažete vlastitu svijest i još jednom pokažete klijentu kakav ste profesionalni profesionalac, koje zeznute termine koristite.

Kažete im da ćete podatke pohraniti na određeno mjesto na serveru, a ne na svom stolu ili ispod jastuka. Koristite programske jezike.

Saglasni ste da otpremate slike samo u gif ili jpg formatu, a stranice neće prelaziti određenu težinu. Usput, odlična poenta. Zatim, ako kupac izbulji oči i kaže da mu treba nešto drugo, možete pokazati ovu poentu i reći: „Pa vi ste sami potpisali za težinu, ne znam ništa, sve je to nemoguće!“.

Još jedna zaista korisna stvar koju također možete spomenuti ovdje: ograničavanje ponuđenog sadržaja. Morate definirati okvir - radite li sav sadržaj ili kreirate administratorski račun, dajte kupcu korisničko ime i lozinku i pustite ga da shvati!

Softverski zahtjevi

1. Ovdje govorimo o hostingu ili serverima. Pošto je moj blog fokusiran na kreatore koji rade na Timewebu ( https://timeweb.ru ) - sve je vrlo jednostavno. Ako niste jedan od naših, onda morate pogledati tehničke specifikacije. Na primjer, neko vrlo pametan napravi kul stranicu, a zatim pokuša da je poveže sa hostingom, a tehničke karakteristike su toliko prenaglašene da nijedan hosting u Rusiji ne može da se nosi. Stavka je neophodna, ali nije za početnike u oblasti razvoja.
2. Ovdje opisujemo da li će portal imati mobilnu verziju, prilagođenu za prijenosne uređaje, ili će se moći otvarati samo preko Google Chrome-a, a bilo kakva izobličenja u drugim pretraživačima nam uopće ne smetaju.

Jezički zahtjevi

Da li će sajt biti napravljen na dva jezika ili će nam trebati samo ruski.

Ergonomski i tehnički zahtjevi estetike

Još jednom ukratko spominjemo glavne odredbe dizajna. Sve će biti jasno, jednostavno, istog tipa. Logo i kontakt informacije će biti vidljivi svuda. Sve je super, sve je divno.

Uslovi za prijem i isporuku projekta

Zahtjevi za popunjavanje informacija

U ovom trenutku vam kažemo šta se obavezujemo da ispunimo, kao i šta kupac treba da nam obezbedi kako bi posao prošao brže i bolje. Obično su mu potrebne informacije i fotografije.

Također ponovo pišemo da će, ako želi nešto ispraviti ili promijeniti, morati ponovo sastaviti sličan ugovor, koji ili potpišete ili ne.

Zahtjevi za osobljem

Ko će moći koristiti stranicu. Na primjer, neke kompanije rade sa kodovima, a čak se i ne trude sa kontrolnim sistemom za normalne ljude. Za elementarne radnje na gradilištu potrebno je značajno znanje osoblja. U ovom slučaju je stavka relevantna, ali u našem slučaju samo papirologija.

Procedura obezbjeđenja distribucije

Šta ćete dati kupcu kada posao bude gotov: login, lozinka, napred i nazad.

Ispunjavamo cijenu tehničkog zadatka

Kao što ste već shvatili, glavni zadatak TK-a nije toliko razumjeti, iako je i ovo važno. Ipak, njegova dodatna funkcija je da stvori ispravan dojam o sebi i zaštiti od svih vrsta promjena.

Sve u ovom dokumentu treba da bude impresivno! Ako ćete ga poslati na pregled poštom, obavezno koristite PDF format. I klijent se vjerovatno neće htjeti mučiti uređivanjem i mislit će o vama kao o profesionalcu. Sitnica, ali značajna. Da biste konvertovali Word dokument, možete koristiti uslugu https://smallpdf.com/ru/ .

Ne zaboravite da u pozadinu umetnete logo svoje kompanije ili brenda, kao i kontakte. Mogu se izdati brzo i efikasno na web stranici. https://logaster.ru .

Pa, to je sve, samo morate preuzeti primjer koji sam napravio posebno za vas. To će vam pomoći da shvatite i uzmete za osnovu neke stereotipne tačke koje neće biti drugačije i urađene.

Sada možete sigurno otići do kupca i ne bojati se da ćete biti optuženi za nepotpunost.

PREUZMITE TK PREDLOG

Sretno u vašim nastojanjima i vidimo se uskoro. Pretplatite se na moj blog i dobijte najkorisnije informacije koje će vam svakako dobro doći u radu na razvoju dobre web stranice za vaše klijente.

Često me pitaju: "Kako pravilno izraditi tehnički zadatak za automatizirani sistem?" O temi izrade tehničkog zadatka se stalno raspravlja na raznim forumima. Ovo pitanje je toliko široko da je nemoguće odgovoriti ukratko. Stoga sam odlučio da napišem poduži članak na ovu temu. U procesu rada na članku shvatio sam da ne bi uspjelo sve staviti u jedan članak, jer ispast će ispod 50 stranica i odlučio sam ga podijeliti na 2 dijela:

• U prvom dijelu" Izrada tehničkih specifikacija. Šta je to, zašto je potrebno, odakle početi i kako bi trebalo da izgleda?" Pokušat ću detaljno odgovoriti na pitanja iz teme, razmotriti strukturu i svrhu Projektnog zadatka i dati neke preporuke o formuliranju zahtjeva.
• Drugi dio" Izrada tehničkih specifikacija. Kako formulirati zahtjeve?" biće u potpunosti posvećen identifikovanju i formulisanju zahteva za informacioni sistem.

Prvo, morate shvatiti koje pitanje zaista zanima one koji pitaju "Kako izraditi tehnički zadatak?" Činjenica je da će pristup izradi tehničkih specifikacija umnogome zavisiti i od svrhe za koju se to radi, kao i od toga ko će ga koristiti. O kojim opcijama govorim:

• Jedna komercijalna organizacija odlučila je da implementira automatizovani sistem. Ona nema sopstvenu IT uslugu i odlučila je da uradi sledeće: Dotična osoba treba da izradi Projektni zadatak i da ga dostavi trećoj organizaciji na razvoj;
• Jedna komercijalna organizacija odlučila je da implementira automatizovani sistem. Ima sopstvenu IT uslugu. Odlučili smo da uradimo ovo: izradimo Projektni zadatak, zatim ga koordiniramo između IT službe i zainteresovanih strana i sami ga implementiramo;
• Vladina agencija je odlučila da pokrene IT projekat. Ovdje je sve tako blatnjavo, puno formalnosti, mitinga, rezova itd. Ovu opciju neću razmatrati u ovom članku.
• IT kompanija se bavi uslugama razvoja i/ili implementacije automatizovanih sistema. Ovo je najteži slučaj, jer morate raditi u različitim uslovima:

  Klijent ima svoje stručnjake sa sopstvenim stavovima, koji postavljaju specifične zahteve za Projektni zadatak;

  • Projektni zadaci su razvijeni za naše vlastite programere (klijenta nije briga);
  • Projektni zadaci se izrađuju za prijenos na izvođača (tj. grupu programera koji se nalaze izvan osoblja kompanije, ili pojedinačnog stručnjaka);
  • Nastaje nesporazum između kompanije i klijenta u vezi sa postignutim rezultatom, a kompanija iznova postavlja pitanje: „Kako treba izraditi Projektni zadatak?“ Možda ovaj drugi slučaj izgleda kao paradoks, ali je istina.
  • Moguće su i druge, manje uobičajene opcije;

Mislim da bi čitalac sada trebao imati nekoliko pitanja:

• Zašto je nemoguće razviti projektni zadatak je uvijek isti?;
• Postoje li neki standardi, metode, preporuke? Gdje ih mogu nabaviti?
• Ko bi trebao izraditi Projektni zadatak? Da li ova osoba treba da ima neka posebna znanja?
• Kako razumjeti da li je Projektni zadatak dobro napisan ili ne?
• O čijem trošku ga treba razvijati i da li je to uopšte potrebno?

Lista može biti beskonačna. Govorim tako samouvjereno jer se bavim profesionalnim razvojem softvera već 15 godina, a pitanje projektnog zadatka dolazi u svakom razvojnom timu s kojim moram raditi. Razlozi za to su različiti. Pokrećući temu izrade Projektnog zadatka, potpuno sam svjestan da ga neću moći 100% prezentirati za sve zainteresovane za ovu temu. Ali, pokušaću, kako kažu, "sve staviti na police". Oni koji su već upoznati sa mojim člancima znaju da ne koristim "copy-paste" tuđe radove, ne preštampam tuđe knjige, ne citiram standarde na više stranica i druge dokumente na kojima se i sami možete naći. Internetu, predstavljajući ih kao moje briljantne misli. Dovoljno je upisati u tražilicu "Kako izraditi tehnički zadatak" i možete pročitati mnogo zanimljivog, ali, nažalost, mnogo puta ponavljajućeg. Po pravilu, oni koji vole da budu pametni na forumima (pokušaju svejedno da pretražuju!) nikada sami nisu uradili razuman Projektni zadatak i neprestano citiraju preporuke GOST-a po ovom pitanju. A za one koji se ozbiljno bave ovim pitanjem, obično nema vremena za sjedenje na forumima. Usput, razgovarat ćemo i o GOST-ovima. Tokom godina svog rada naišao sam na mnoge opcije tehničke dokumentacije koju su sastavljali kako pojedinačni stručnjaci, tako i eminentni timovi i konsultantske kuće. Ponekad radim i ovu aktivnost: odvojim vrijeme za sebe i tražim informacije o temi koja me zanima iz neobičnih izvora (kao što je malo inteligencije). Kao rezultat toga, morao sam vidjeti dokumentaciju za takva čudovišta kao što su GazProm, Ruske željeznice i mnoge druge zanimljive kompanije. Naravno, pridržavam se politike privatnosti, uprkos činjenici da ovi dokumenti dolaze do mene iz javno dostupnih izvora ili neodgovornosti konsultanata (razbacivanje informacija po internetu). Stoga odmah kažem: ne dijelim povjerljive informacije koje pripadaju drugim kompanijama, bez obzira na izvore nastanka (profesionalna etika).

Šta je projektni zadatak?

Prva stvar koju ćemo sada da uradimo je da shvatimo kakva je ovo zver, "Terms of Reference".

Da, zaista postoje GOST-ovi i standardi u kojima se pokušava regulirati ovaj dio aktivnosti (razvoj softvera). Nekada su svi ovi GOST-ovi bili relevantni i aktivno korišteni. Sada postoje različita mišljenja o relevantnosti ovih dokumenata. Neki tvrde da su GOST-ove razvili vrlo dalekovidi ljudi i da su još uvijek relevantni. Drugi kažu da su beznadežno zastarjeli. Možda je neko tek sada pomislio da je istina negdje na sredini. Odgovorio bih Geteovim rečima: „Kažu da postoji istina između dva suprotna mišljenja. Ni u kom slučaju! Postoji problem između njih." Dakle, između ovih mišljenja nema istine. Zato što GOST-ovi ne otkrivaju praktične probleme modernog razvoja, a oni koji ih kritikuju ne nude alternative (specifične i sistemske).

Imajte na umu da GOST jasno ne daje čak ni definiciju, već samo kaže: „Tehnička specifikacija za NPP je glavni dokument koji definiše zahtjeve i postupak za stvaranje (razvoj ili modernizaciju - daljnje stvaranje) automatiziranog sistema, u u skladu sa kojim se izrada AU i njeno prihvatanje vrši po puštanju u rad”.

Ako nekoga zanima o kojim GOST-ovima govorim, evo ih:

• GOST 2.114-95 Jedinstveni sistem projektne dokumentacije. Tehnički uslovi;
• GOST 19.201-78 Jedinstveni sistem programske dokumentacije. Tehnički zadatak. Zahtjevi za sadržaj i dizajn;
• GOST 34.602-89 Informaciona tehnologija. Set standarda za automatizovane sisteme. Projektni zadatak za kreiranje automatizovanog sistema.

Mnogo prikladnija definicija je predstavljena na Wikipediji (tačno za TK općenito, a ne samo za softver): “ Tehnički zadatak- ovo je početni projektni dokument tehnički objekt. Tehnički zadatak utvrđuje glavnu namjenu izrađenog objekta, njegove tehničko-taktičko-tehničke karakteristike, pokazatelje kvaliteta i tehničko-ekonomske zahtjeve, uputstva za izvođenje potrebnih faza izrade dokumentacije (projektantske, tehnološke, softverske i dr.) i njen sastav, kao i kao posebne zahteve. Zadatak kao izvorni dokument za stvaranje nečeg novog postoji u svim oblastima djelovanja, koji se razlikuje po nazivu, sadržaju, redoslijedu registracije i sl. (npr. projektni zadatak u građevinarstvu, borbeni zadatak, domaći zadatak, ugovor o književnom rad, itd.) itd.) "

I tako, kao što slijedi iz definicije, glavna svrha Projektnog zadatka je da formuliše zahtjeve za objekt koji se razvija, u našem slučaju za automatizirani sistem.

Upravo glavni, ali jedini. Došlo je vrijeme da se pozabavimo glavnom: da sve posložimo "po policama", kako je obećano.

Šta trebate znati o zahtjevima? Potrebno je jasno razumjeti da svi zahtjevi moraju biti podijeljeni po vrsti i po svojstvima. Sada ćemo naučiti kako to učiniti. GOST će nam pomoći da odvojimo zahtjeve prema vrsti. Spisak tipova zahteva koji je tamo predstavljen je dobar primer o tome koje vrste zahteva treba uzeti u obzir. Na primjer:

• Zahtjevi funkcionalnosti;
• Zahtjevi za sigurnost i prava pristupa;
• Zahtjevi za kvalifikacije osoblja;
• …. itd. O njima možete pročitati u spomenutom GOST-u (a u nastavku ću ih također razmotriti malo detaljnije).

Mislim da vam je očigledno da je ključni faktor za uspješan projektni zadatak upravo dobro formulirani zahtjevi za funkcionalnost. Većina radova i tehnika o kojima sam govorio posvećena je ovim zahtjevima. Zahtjevi za funkcionalnost su 90% složenosti posla na izradi Projektnog zadatka. Sve ostalo je često "kamuflaža" koja se stavlja na ove zahtjeve. Ako su zahtjevi loše formulirani, onda kakvu lijepu kamuflažu ne stavite, uspješan projekt neće uspjeti. Da, formalno će svi zahtjevi biti ispunjeni (prema GOST J), TK je razvijen, odobren i potpisan, novac je za to primljen. Pa šta? A onda će početi ono najzanimljivije: šta učiniti? Ako se radi o projektu o državnoj narudžbi, onda nema problema - tamo je budžet takav da neće stati ni u jedan džep, u procesu implementacije (ako ga ima) sve će se razjasniti. Upravo na taj način se reže većina projektnih budžeta za državne narudžbe (zapalili "TZ", izlili deset miliona, ali projekat nije urađen. Sve formalnosti ispoštovane, krivaca nema, nov auto je u blizini kuće. Ljepota!). Ali govorimo o komercijalnim organizacijama u kojima se broji novac, a rezultat je drugačiji. Stoga, hajde da se pozabavimo glavnom stvari, kako se razvijati korisni i radni Zadaci.

Rekao sam o vrstama zahtjeva, ali šta je sa svojstvima? Ako vrste zahtjeva mogu biti različite (ovisno o ciljevima projekta), onda je sa svojstvima sve jednostavnije, postoje 3 njih:

1. Zahtjev mora biti razumljivo;
2. Zahtjev mora biti specifično;
3. Zahtjev mora biti testirano;

Štaviše, posljednje svojstvo je nemoguće bez prethodna dva, tj. je svojevrsni "lakmus test". Ako se rezultat ispunjavanja zahtjeva ne može testirati, onda on ili nije jasan ili nije specifičan. Razmisli o tome. U posedovanju ova tri svojstva zahteva leže veština i profesionalizam. U stvari, sve je vrlo jednostavno. Kad shvatiš.

Na ovome bi se priča o tome šta je Projektni zadatak mogla završiti i preći na ono glavno: kako formulisati zahtjeve. Ali nije sve tako brzo. Postoji još jedna izuzetno važna tačka:

• Na kom jeziku (u smislu složenosti razumijevanja) treba napisati projektni zadatak?
• Treba li u njemu opisati specifikaciju različitih funkcija, algoritama, tipova podataka i drugih tehničkih stvari?
• A što je tehnički dizajn, koji se, inače, također spominje u GOST-ovima, i kako je povezan s Projektnim zadatkom?

Postoji jedna vrlo podmukla stvar u odgovorima na ova pitanja. Zbog toga se često javljaju sporovi o dovoljnosti ili nedostatku potrebnog detaljisanja zahtjeva, o jasnoći dokumenta od strane naručioca i izvođača radova, o redundantnosti, formatu prezentacije itd. A gdje je granica između projektnog zadatka i tehničkog projekta?

Tehnički zadatak je dokument zasnovan na zahtjevima formulisanim na razumljivom (običnom, poznatom) jeziku za Kupca. Istovremeno se može i treba koristiti terminologija industrije koja je razumljiva Kupcu. Ne bi trebalo biti vezivanja za specifičnosti tehničke implementacije. One. u fazi TK, u principu, nije bitno na kojoj će platformi ovi zahtjevi biti implementirani. Ipak, postoje izuzeci. Ako je riječ o implementaciji sistema baziranog na postojećem softverskom proizvodu, onda se takvo uvezivanje može dogoditi, ali samo na nivou ekranskih obrazaca, obrazaca izvještaja itd. poslovni analitičar. I sigurno ne programer (osim ako ne kombinuje ove uloge u sebi, to se dešava). One. ova osoba treba da razgovara sa Klijentom na jeziku njegovog poslovanja.

Tehnički projekat je dokument koji je namijenjen tehničkoj implementaciji zahtjeva formuliranih u Projektnom zadatku. Ovaj dokument opisuje strukture podataka, pokretače i pohranjene procedure, algoritme i druge stvari koje su potrebne. tehničari... Uopšte nije neophodno da se kupac upušta u ovo (možda ne razume takve uslove). Tehnički dizajn čini Arhitekta sistema(sasvim je normalno kombinovati ovu ulogu sa programerom). Da budemo precizniji, grupu AO stručnjaka predvodi arhitekta. Što je projekat veći, više ljudi radi na Projektnom zadatku.

Šta imamo u praksi? Smiješno je gledati kada direktora dovode na odobrenje Projektni zadatak, koji obiluje tehničkom terminologijom, opisom tipova podataka i njihovih vrijednosti, strukturom baze podataka itd. poslovnim zahtjevima. Je li ovo poznata situacija? I kako se to završava? Takva TK se po pravilu odobrava, zatim implementira, au 80% slučajeva onda uopšte ne odgovara činjenici obavljenog posla, jer odlučili su da se promene, poprave mnoge stvari, pogrešno shvatili, pogrešno razmišljali itd. itd. A onda počinje serijal o isporuci radova. “Ali ovo nije onako kako nam treba”, ali “ovo nam neće uspjeti”, “ovo je preteško”, “ovo je nezgodno” itd. Zvuči poznato?!! To mi je poznato, morao sam svojevremeno napuniti čunjeve.

Dakle, šta imamo u praksi? U praksi imamo zamagljenu granicu između projektnog zadatka i tehničkog projekta. Ona lebdi između TK i TP u raznim oblicima. I to je loše. A ispada tako jer je razvojna kultura oslabila. To je dijelom zbog kompetencija stručnjaka, dijelom sa željom da se smanje budžeti i rokovi (na kraju krajeva, dokumentacija traje dugo - to je činjenica). Postoji još jedan važan faktor koji utiče na upotrebu tehničkog projekta kao zasebnog dokumenta: brzi razvoj alata za brzi razvoj, kao i razvojnih metodologija. Ali ovo je posebna priča, odmah u nastavku ću reći nekoliko riječi o tome.

Još jedna mala, ali važna tačka. Ponekad je Projektni zadatak mali dio zahtjeva, jednostavan i razumljiv. Na primjer, da biste precizirali pretragu objekta prema nekim uvjetima, dodajte kolonu u izvještaj itd. Ovakav pristup je sasvim opravdan, čemu komplicirati život. Ali ne koristi se na velikim projektima, već na manjim poboljšanjima. Rekao bih da je ovo bliže održavanju softverskog proizvoda. U ovom slučaju, konkretno tehničko rješenje za implementaciju zahtjeva može se opisati u Projektnom zadatku. Na primjer, "Učinite tu i takvu promjenu u algoritmu tako i tako", što ukazuje na specifičnu proceduru i specifičnu promjenu za programera. To je slučaj kada je granica između projektnog zadatka i tehničkih projekata potpuno izbrisana, jer ne postoji ekonomska izvodljivost da se hara papirologija tamo gde ona nije potrebna, a stvara se koristan dokument. I to je tačno.

Da li vam je uopšte potreban tehnički zadatak? Šta je sa tehničkim dizajnom?

Jesam li pregrijana? Da li je ovo moguće, bez Projektni zadaci? Zamislite da je moguće (tačnije, dešava se), a ovaj pristup ima mnogo sljedbenika, a njihov broj se povećava. Po pravilu, nakon što mladi stručnjaci pročitaju knjige o Scrum-u, Agile-u i drugim tehnologijama brzog razvoja. U stvari, to su divne tehnologije, i rade, samo što ne kažu doslovno „nema potrebe za tehničkim specifikacijama“. Kažu „minimum papirologije“, posebno nepotrebne, bliže Kupcu, konkretnije i brže do rezultata. Ali niko nije otkazao fiksiranje zahtjeva i to je tamo jasno navedeno. Tamo su zahtjevi fiksirani na osnovu tri izuzetna svojstva o kojima sam govorio gore. Samo neki ljudi imaju tako strukturiranu svijest da ako se nešto može pojednostaviti, onda hajde da to pojednostavimo do potpunog odsustva. Kao što je Ajnštajn rekao “ Neka bude što jednostavnije, ali ne i lakše." ... Zlatne riječi, na kraju krajeva, odgovaraju za sve. Tako da Tehnički zadatak to je neophodno, inače nećete vidjeti uspješan projekat. Drugo je pitanje kako komponovati i šta tu uključiti. U svjetlu metodologija brzog razvoja, trebate se fokusirati samo na zahtjeve, a sva "kamuflaža" se može odbaciti. U principu se slažem sa ovim.

Šta je sa tehničkim projektom? Ovaj dokument je veoma koristan i nije izgubio na važnosti. Štaviše, često je nemoguće bez toga. Pogotovo kada je u pitanju outsourcing razvojnih poslova, tj. na osnovu outsourcinga. Ako se to ne učini, postoji rizik da naučite mnogo novih stvari o tome kako bi sistem koji ste zamislili trebao izgledati. Da li ga Kupac treba upoznati? Ako hoće, zašto ne, ali ne treba insistirati i odobravati ovaj dokument, on će samo sputavati i ometati rad. Gotovo je nemoguće dizajnirati sistem do najsitnijih detalja. U tom slučaju ćete morati kontinuirano unositi izmjene u Tehnički dizajn, što oduzima dosta vremena. A ako je organizacija visoko birokratska, onda općenito ostavite sve živce tamo. Upravo o redukciji ovakvog dizajna govorimo u savremenim metodologijama brzog razvoja, koje sam već pomenuo. Inače, svi su bazirani na klasičnom XP-u (ekstremno programiranje) - pristupu starom već oko 20 godina. Zato napravite visokokvalitetan Projektni zadatak, razumljiv kupcu, i koristite Tehnički dizajn kao interni dokument za odnos između arhitekte sistema i programera.

Zanimljiv detalj o tehničkom dizajnu: neki razvojni alati zasnovani na principu predmetne orijentacije (kao što su 1C i slični) pretpostavljaju da je dizajn (što znači proces dokumentovanja) potreban samo u zaista složenim oblastima gde je potrebna interakcija između čitavih podsistema. U najjednostavnijem slučaju, na primjer, za izradu priručnika, dokumenta, dovoljni su samo ispravno formulirani poslovni zahtjevi. O tome svjedoči i poslovna strategija ove platforme u smislu obuke stručnjaka. Ako pogledate ispitni list specijaliste (tako se zove, a ne "programer"), vidjet ćete da postoje samo poslovni zahtjevi, a kako ih implementirati u programskom jeziku je zadatak specijaliste. One. onaj dio zadatka za koji je Tehnički projekat osmišljen da riješi, specijalista mora riješiti "u glavi" (govorimo o zadacima srednje složenosti), a ovdje i sada, slijedeći određene razvojne i projektantske standarde, koji se ponovo formiraju od strane 1C za svoju platformu. Dakle, od dva specijalista, čiji rezultat rada izgleda isto, jedan može položiti ispit, a drugi ne, jer grubo narušeni razvojni standardi. Odnosno, očigledno se pretpostavlja da stručnjaci moraju imati takve kvalifikacije da mogu sami dizajnirati tipične zadatke, bez uključivanja sistemskih arhitekata. I ovaj pristup funkcionira.

Nastavimo proučavanje pitanja: "Koje zahtjeve treba uključiti u Projektni zadatak?"

Formulisanje zahteva za informacioni sistem. Struktura Projektnog zadatka

Odlučimo odmah: konkretno ćemo govoriti o formulaciji zahtjeva za informacioni sistem, tj. pod pretpostavkom da su poslovi razvoja poslovnih zahtjeva, formalizacije poslovnih procesa i svi prethodni konsultantski poslovi već obavljeni. Naravno, i u ovoj fazi se mogu izvršiti neke dorade, ali upravo dorade. Sam projekat automatizacije ne rješava poslovne probleme - zapamtite ovo. Ovo je aksiom. Iz nekog razloga, neki menadžeri pokušavaju to opovrgnuti, vjerujući da će, ako kupe program, red doći u haotičnom poslu. Ali aksiom je također aksiom da nisu potrebni dokazi.

Kao i kod svake aktivnosti, formulacija zahtjeva se može (i treba) podijeliti u faze. Sve ima svoje vrijeme. Ovo je težak intelektualni rad. A, ako se prema tome odnosi s nedovoljnom pažnjom, onda će rezultat biti odgovarajući. Prema procjenama stručnjaka, troškovi izrade Projektnog zadatka mogu biti 30-50%. Ja sam istog mišljenja. Iako je 50 vjerovatno previše. Uostalom, Projektni zadatak nije posljednji dokument koji treba izraditi. Uostalom, trebalo bi da postoji i tehnički dizajn. Ovo širenje je zbog različitih platformi za automatizaciju, pristupa i tehnologija koje koriste projektni timovi tokom razvoja. Na primjer, ako govorimo o razvoju na klasičnom jeziku kao što je C ++, onda se ne može bez detaljnog tehničkog dizajna. Ako govorimo o implementaciji sistema na 1C platformi, onda je situacija s dizajnom nešto drugačija, kao što smo vidjeli gore (iako je pri razvoju sistema "od nule" dizajniran prema klasičnoj shemi) .

Uprkos činjenici da je izjava o zahtjevima glavni dio Projektni zadaci, a u nekim slučajevima postaje i jedini odjeljak TK-a, treba obratiti pažnju da se radi o važnom dokumentu, te da ga u skladu s tim treba i sastaviti. Gdje početi? Prije svega, morate početi sa sadržajem. Sastavite svoj sadržaj, a zatim ga počnite širiti. Ja lično radim ovo: prvo skiciram sadržaj, opisujem ciljeve, sve pozadinske informacije, a zatim preuzimam glavni dio – formulaciju zahtjeva. Zašto ne i obrnuto? Ne znam, meni je zgodnije. Prvo, ovo je mnogo manji dio vremena (u poređenju sa zahtjevima), a drugo, dok opisujete sve uvodne informacije, prelazite na ono glavno. Pa, ovo je kako želiš. Vremenom ćete razviti sopstveni šablon za Uslove posla. Za početak, preporučujem da kao sadržaj uzmete upravo onaj opisan u GOST-u. Savršeno se uklapa u sadržaj! Zatim uzimamo i počinjemo opisivati ​​svaki odjeljak, ne zaboravljajući na preporuke za pridržavanje tri svojstva: jasnoća, konkretnost i mogućnost testiranja. Zašto toliko insistiram na tome? Više o tome u sljedećem odjeljku. A sada predlažem da prođemo skroz kroz točke TK-a, koje se preporučuju u GOST-u.

1. opće informacije;
2. svrha i ciljevi stvaranja (razvoja) sistema;
3. karakteristike objekata automatizacije;
4. Zahtjevi sustava;
5. sastav i sadržaj rada na kreiranju sistema;
6. postupak kontrole i prihvatanja sistema;
7. zahtjeve za sastav i sadržaj rada na pripremi objekta automatizacije za puštanje sistema u rad;
8. zahtjevi za dokumentacijom;
9. razvojni izvori.

Ukupno ima 9 odjeljaka, od kojih je svaki također podijeljen na pododjeljke. Analizirajmo ih redom. Radi praktičnosti, predstavit ću sve u obliku tabele za svaku stavku.

Odjeljak 1. opšte informacije.

Preporuke prema GOST-u
puni naziv sistema i njegov simbol;	Ovdje je sve jasno: pišemo kako će se sistem zvati, njegov kratki naziv
šifra predmeta ili šifra (broj) ugovora;	Ovo nije relevantno, ali možete odrediti ako je potrebno
naziv preduzeća (udruženja) programera i korisnika (korisnika) sistema i njihovi detalji;	naznačiti ko (koje organizacije) će raditi na projektu. Također možete odrediti njihove uloge.Ovaj odjeljak možete potpuno izbrisati (prilično formalno).
spisak dokumenata na osnovu kojih je sistem kreiran, ko i kada su ti dokumenti odobreni;	Korisne informacije. Ovdje je vrijedno navesti normativnu i referentnu dokumentaciju koja vam je dostavljena da biste se upoznali s određenim dijelom zahtjeva
planirane datume početka i završetka stvaranja sistema;	Zahtjevi za tajming. Ponekad o tome pišu u TK, ali češće se takve stvari opisuju u ugovorima o radu
podatke o izvorima i postupku finansiranja radova;	Isto tako, kao u prethodnom paragrafu o vremenu. Relevantnije za vladine naloge (za zaposlene u javnom sektoru)
postupak registracije i predstavljanja kupcu rezultata rada na izradi sistema (njegovih dijelova), na izradi i prilagođavanju pojedinačnih sredstava (hardver, softver, informacije) i softversko-hardverskih (softversko-metodoloških) kompleksa sistema.	Ne vidim potrebu za ovom tačkom, tk. posebno se izrađuju zahtjevi za dokumentaciju, a pored toga postoji i cijeli poseban odjeljak „Procedura kontrole i prijema“ sistema.

Odjeljak 2. svrha i ciljevi stvaranja (razvoja) sistema.

Preporuke prema GOST-u	Šta učiniti po tom pitanju u praksi
Svrha sistema	S jedne strane, sve je jednostavno sa terminom. Ali poželjno je biti konkretan. Ako napišete nešto poput „kvalitativno automatizirajte kontrolu zaliha u kompaniji X“, onda možete dugo razgovarati o rezultatu po njegovom završetku, čak i bez obzira na dobru formulaciju zahtjeva. Jer Kupac uvijek može reći da je pod kvalitetom mislio na nešto drugo. Općenito, možete jedni drugima pokvariti mnogo živaca, ali zašto? Bolje je odmah napisati nešto ovako: "Sistem je dizajniran za kontrolu zaliha u kompaniji X u skladu sa zahtjevima navedenim u ovom Projektnom zadatku."
Ciljevi sistema	Ciljevi su svakako važan dio. Ako ga zaista uključite, onda morate biti u stanju formulirati ove ciljeve. Ako imate poteškoća s formuliranjem ciljeva, onda je bolje da ovaj odjeljak potpuno isključite. Primjer neuspješnog cilja: "Osigurajte brzu papirologiju za menadžera." Šta je brzo? To se onda može dokazivati ​​beskonačno. Ako je ovo važno, onda je bolje preformulisati ovaj cilj na sljedeći način: "Menadžer prodaje bi trebao biti u mogućnosti da sastavi dokument" Prodaja robe "od 100 linija za 10 minuta." Sličan cilj može se pojaviti ako, na primjer, menadžer trenutno potroši oko sat vremena na ovo, što je za ovu kompaniju previše i važno za njih. U takvoj formulaciji cilj se već ukršta sa zahtjevima, što je sasvim prirodno, budući da pri proširenju stabla ciljeva (tj. dijeljenju na manje povezane ciljeve), svejedno ćemo pristupiti zahtjevima. Stoga se ne treba zanositi.

Općenito, sposobnost identificiranja ciljeva, njihovog formuliranja, izgradnje stabla ciljeva je potpuno zasebna tema. Zapamtite glavnu stvar: ako znate kako - pišite, niste sigurni - ne pišite nikako. Šta će se dogoditi ako ne formulirate ciljeve? Radit ćete prema zahtjevima, to se često praktikuje.

Odjeljak 3. Opis objekata automatizacije.

Odjeljak 4. Sistemski zahtjevi

GOST dešifruje listu takvih zahtjeva:

• zahtjevi za strukturom i funkcionisanjem sistema;
• zahtjeve za brojem i kvalifikacijama osoblja sistema i načinom njihovog rada;
• indikatori odredišta;
• zahtjevi za pouzdanost;
• sigurnosni zahtjevi;
• zahtjevi za ergonomiju i tehničku estetiku;
• zahtjevi za prenosivosti mobilnih zvučnika;
• zahtjevi za rad, održavanje, popravku i skladištenje komponenti sistema;
• zahtjevi za zaštitu informacija od neovlaštenog pristupa;
• zahtjevi za sigurnost informacija u slučaju nesreća;
• zahtjevi za zaštitu od utjecaja vanjskih utjecaja;
• zahtjevi za čistoću patenta;
• zahtjevi za standardizaciju i unifikacija;

Uprkos činjenici da će glavna sekcija svakako biti sa specifičnim zahtjevima (funkcionalna), ova sekcija također može biti od velike važnosti (i u većini slučajeva jeste). Šta može biti važno i korisno:

• Kvalifikacijski zahtjevi... Možda će sistem koji se razvija zahtijevati prekvalifikaciju stručnjaka. To mogu biti i korisnici budućeg sistema i IT stručnjaci koji će biti potrebni za njegovu podršku. Nedovoljna pažnja ovom pitanju često prerasta u probleme. Ukoliko su kvalifikacije postojećeg kadra očigledno nedovoljne, bolje je propisati uslove za organizaciju obuke, program obuke, vrijeme i sl.
• Zahtjevi za zaštitu informacija od neovlaštenog pristupa. Komentari su ovdje nepotrebni. Upravo su to zahtjevi za diferencijaciju pristupa podacima. Ako se takvi zahtjevi planiraju, onda ih je potrebno posebno opisati, što je detaljnije moguće prema istim pravilima kao i funkcionalni zahtjevi (jasnoća, specifičnost, mogućnost testiranja). Stoga se ovi zahtjevi mogu uključiti u odjeljak sa funkcionalnim zahtjevima.
• Zahtjevi za standardizaciju. Ako postoje standardi dizajna koji su primjenjivi na projekat, oni se mogu uključiti u zahtjeve. Takve zahtjeve po pravilu inicira IT služba Kupca. Na primjer, kompanija 1C ima zahtjeve za dizajn programskog koda, dizajn interfejsa itd.;
• Zahtjevi za strukturu i funkcioniranje sistema. Ovdje se mogu opisati zahtjevi za međusobnu integraciju sistema, dat je opis opšte arhitekture. Češće se zahtjevi za integraciju općenito izdvajaju u posebnom dijelu ili čak u zasebnom Projektnom zadatku. ovi zahtjevi mogu biti prilično složeni.

Svi ostali zahtjevi su manje važni i ne moraju se opisivati. Po mom mišljenju, oni samo otežavaju dokumentaciju i od male su praktične koristi. I vrlo je teško opisati zahtjeve za ergonomiju u obliku općih zahtjeva, bolje ih je prenijeti na funkcionalne. Na primjer, može se formulirati zahtjev "Dobijte informacije o cijeni artikla klikom na samo jedno dugme". Po mom mišljenju, ovo je ipak bliže specifičnim funkcionalnim zahtjevima, iako se odnosi na ergonomiju.Zahtjevi za funkcije (zadatke) koje sistem obavlja Ovo je vrlo glavna i ključna tačka koja će odrediti uspjeh. Čak i ako je sve ostalo savršeno urađeno, a ovaj odjeljak je "3", onda će rezultat projekta u najboljem slučaju biti "3", ili će čak projekt potpuno propasti. O njima ćemo se detaljnije pozabaviti u drugom članku, koji će biti uključen u 5. broj mailing liste. Upravo do te tačke dolazi do "pravila tri svojstva potraživanja", o čemu sam govorio. Zahtjevi za vrste kolaterala

GOST razlikuje sljedeće vrste:

• Matematički
• Informacije
• Lingvistički
• Softver
• Technical
• metrološki
• Organizacijski
• Metodički
• ostalo…

Na prvi pogled može izgledati da ti zahtjevi nisu važni. U većini projekata to je tačno. Ali ne uvek. Kada opisati ove zahtjeve:

• Odluke o tome koji jezik (ili koja platforma) će se koristiti za razvoj nisu donesene;
• Sistem ima zahtjeve za višejezično sučelje (na primjer, ruski / engleski)
• Da bi sistem funkcionisao, potrebno je stvoriti poseban odjel ili zaposliti nove zaposlenike;
• Da bi sistem funkcionisao kod Kupca, moraju postojati promene u metodama rada, a te promene moraju biti specificirane i planirane;
• Pretpostavlja se integracija sa bilo kojom opremom i na nju se postavljaju zahtjevi (na primjer, certifikacija, kompatibilnost, itd.)
• Moguće su i druge situacije, sve zavisi od konkretnih ciljeva projekta.

Odjeljak 5. Sastav i sadržaj rada na kreiranju sistema

Odjeljak 6. Procedura za kontrolu i prihvatanje sistema

Opšti zahtevi za prijem radova po fazama (spisak preduzeća i organizacija koje učestvuju, mesto i termin), procedura za ugovaranje i odobravanje prijemne dokumentacije, toplo preporučujem da preuzmete odgovornost za proceduru isporuke radova i proveru sistema. To je ono čemu služe provjerljivi zahtjevi, ali ni prisustvo provjerljivih zahtjeva možda neće biti dovoljno prilikom primopredaje sistema, ako redoslijed prijema i primopredaje radova nije jasno naveden. Na primjer, uobičajena zamka: sistem je napravljen, potpuno je funkcionalan, ali Kupac iz nekog razloga nije spreman za rad u njemu. Ti razlozi mogu biti bilo koji: nekada su se ciljevi promijenili, neko je dao otkaz itd. I kaže: "Pošto još ne radimo u novom sistemu, to znači da ne možemo biti sigurni da on funkcioniše." Zato naučite ispravno identificirati faze rada, načine za provjeru rezultata za ove faze. Štaviše, takve metode bi trebale biti jasne Kupcu u početku. Ako su oni fiksirani na nivou Projektnog zadatka, onda ih uvijek možete kontaktirati, ako je potrebno, i donijeti posao uz prijenos.

Odjeljak 7. Zahtjevi za sastav i sadržaj rada na pripremi objekta automatizacije za puštanje sistema u rad

Mogu postojati neka druga pravila za unos informacija koje je kompanija usvojila (ili planira). Na primjer, informacije o ugovoru su se ranije unosile u tekstualni red u proizvoljnom obliku, ali sada se traži zasebno broj, posebno datum itd. Takvih uslova može biti mnogo. Neki od njih se mogu uočiti uz otpor osoblja, pa je bolje sve takve slučajeve registrovati na nivou zahtjeva za proceduru unosa podataka Promjene koje je potrebno izvršiti u objektu automatizacije

Stvaranje uslova za rad objekta automatizacije, pod kojima je zagarantovana usklađenost kreiranog sistema sa zahtjevima sadržanim u TZ.Sve eventualne promjene. Na primjer, kompanija nema lokalnu mrežu, zastarjelu flotu računara na kojima sistem neće raditi.

Možda su neke potrebne informacije obrađene na papiru, a sada ih treba unijeti u sistem. Ako se to ne uradi, onda nijedan modul neće raditi itd.

Možda je nešto pojednostavljeno, ali sada je potrebno detaljnije uzeti u obzir, odnosno, neko mora prikupljati informacije prema određenim pravilima.

Ova lista može biti duga, pogledajte konkretan slučaj vašeg projekta Kreiranje jedinica i servisa neophodnih za funkcionisanje sistema;

Vrijeme i procedura za popunjavanje osoblja i obuku osoblja O tome smo već govorili ranije. Možda se sistem razvija za novu strukturu ili vrstu djelatnosti koja prije nije postojala. Ako nema odgovarajućeg kadra, pa čak i obučenog, onda sistem neće raditi, ma koliko kompetentno nije izgrađen.

Odjeljak 8. Zahtjevi za dokumentaciju

Razmislite kako će biti predstavljeni korisnički priručnici.

Možda je Kupac prihvatio korporativne standarde, pa se na njih treba pozvati.

Ignoriranje zahtjeva za dokumentacijom vrlo često dovodi do najneočekivanijih posljedica na projekte. Na primjer, sve je urađeno i sve radi. Korisnici također znaju kako raditi. O dokumentaciji se uopće nismo slagali niti razgovarali. I odjednom, kada se posao preda, jedan od top menadžera Kupca, koji nije ni učestvovao u projektu, ali učestvuje u prijemu posla, pita vas: "Gde su uputstva za upotrebu?" I počinje vas uvjeravati da nije bilo potrebno dogovarati se o dostupnosti korisničkih priručnika, to se "samo po sebi" navodno podrazumijeva. I to je sve, on ne želi da uzme tvoj posao. O čijem trošku ćete izraditi smjernice? Mnogi timovi su već pali na ovu udicu.

Odjeljak 9. Izvori razvoja

Preporuke prema GOST-u	Šta učiniti po tom pitanju u praksi
Treba navesti dokumente i informativne materijale (studija izvodljivosti, izvještaji o završenim istraživačkim radovima, informacioni materijali za domaće, strane analogne sisteme i dr.), na osnovu kojih je TK razvijen i koji treba koristiti pri kreiranju sistema.	Da budem iskren, ovo je bliže stihovima. Pogotovo kada se govori o ekonomskom efektu i ostalim stvarima koje je praktično nemoguće objektivno izračunati. One. moguće je naravno, biće pre na papiru, čisto teoretski.

Stoga je bolje jednostavno se pozvati na izvještaj ankete, zahtjeve ključnih osoba.

I tako, razmotrili smo sve dijelove koji mogu biti uključeni u Projektni zadatak. “Maj” a ne “Obavezno” upravo zato što se svaki dokument mora izraditi da bi se postigao rezultat. Stoga, ako vam je očigledno da vas neka zasebna sekcija neće približiti rezultatu, onda vam nije potrebna i ne trebate gubiti vrijeme na to.

Ali bez glavne stvari: funkcionalnih zahtjeva, niti jedan tehnički zadatak nije završen. Želim da napomenem da se u praksi susrećemo sa takvim Projektnim zadatkom, i to kako! Postoje brojke koje će moći razblažiti vodu u svim odjeljcima, opisati opće zahtjeve općenito, a dokument se ispostavi da je vrlo težak, i u njemu ima mnogo pametnih riječi, pa čak i Kupcu može se svidjeti (tj. on će to odobriti). Ali rad na tome možda neće uspjeti, tj. malo je praktične koristi od toga. U većini slučajeva, takvi dokumenti se rađaju kada trebate dobiti puno novca posebno za Projektni zadatak, a to se mora uraditi brzo i bez ulaženja u detalje. A pogotovo ako se zna da stvari neće ići dalje, ili će to učiniti potpuno drugi ljudi. Uglavnom, samo za razvoj budžeta, posebno državnog.

U drugom članku ćemo govoriti samo o Odjeljku 4 "Sistemski zahtjevi", a posebno ćemo formulisati zahtjeve iz razloga jasnoće, specifičnosti i mogućnosti testiranja.

Zašto zahtjevi trebaju biti jasni, specifični i provjerljivi.

Jer praksa pokazuje: u početku se većina tehničkih specifikacija koje razvijaju stručnjaci ili ispostavi da nisu tražene (ne odgovaraju stvarnosti), ili postanu problem za onoga koji mora implementirati, jer Kupac počinje da manipuliše nespecifičnim uslovima i zahtevima. Navest ću nekoliko primjera na koje fraze su se susreli, do čega je to dovelo, a zatim ću pokušati dati preporuke kako izbjeći takve probleme.

Vrsta zahtjeva

Pogrešna formulacija

Projektni zadatak je polazni materijal za kreiranje informacionog sistema ili drugog proizvoda. Stoga bi projektni zadatak (skraćeno TK) prije svega trebao sadržavati osnovne tehničke zahtjeve za proizvod i odgovoriti na pitanje šta ovaj sistem treba da radi, kako da radi i pod kojim uslovima.

Po pravilu, fazi izrade tehničkog zadatka prethodi pregled predmetne oblasti, koji se završava izradom analitičkog izvještaja. Analitički izvještaj (ili analitička bilješka) čini osnovu dokumenta Projektnog zadatka.

Ako izvještaj može sažeti zahtjeve korisnika i ilustrovati UML dijagramima, projektni zadatak treba detaljno opisati sve funkcionalne i korisničke zahtjeve za sistem. Što će opis poslova biti detaljniji, to će se manje kontroverznih situacija pojaviti između kupca i programera tokom testova prihvatanja.

Dakle, projektni zadatak je dokument koji omogućava i programeru i kupcu da predstave finalni proizvod i naknadno provjere usklađenost sa zahtjevima.

Vodeći standardi za pisanje tehničkog zadatka su GOST 34.602.89 „Zahtjevi za izradu automatiziranog sistema“ i GOST 19.201-78 „Zahtjevi. Zahtjevi za sadržaj i dizajn". Prvi standard je namijenjen programerima automatiziranih sistema, drugi softverskim alatima (razliku između ovih serija smo raspravljali u članku "Šta je GOST").

Dakle, u nastavku predstavljamo listu i opis odjeljaka koje bi tehnički zadatak trebao sadržavati u skladu s GOST-om.

GOST 19.201-78 Zadaci. Zahtjevi za sadržaj i dizajn	GOST 34.602.89 Zadaci za kreiranje automatizovanog sistema
1. Uvod	1. Opće informacije
2. Osnova za razvoj
3. Svrha razvoja	2. Svrha i ciljevi sistema
	3. Opis objekta automatizacije
4. Zahtjevi za program ili softverski proizvod	4. Sistemski zahtjevi
4.1. Zahtjevi za performanse	4.2. Zahtjevi za funkcije (zadatke) koje sistem obavlja
	4.1. Sistemski zahtjevi u cjelini
	4.1.1. Zahtjevi za strukturu i funkcioniranje sistema
	4.1.3. Indikatori imenovanja
4.2. Zahtjevi za pouzdanost	4.1.4. Zahtjevi za pouzdanost
	4.1.5. Sigurnosni zahtjevi
	4.1.6. Ergonomski i tehnički zahtjevi estetike
4.3. Radni uslovi	4.1.2. Zahtjevi za brojem i kvalifikacijama osoblja sistema i načinom njihovog rada
	4.19. Zahtjevi za zaštitu informacija od neovlaštenog pristupa
	4.1.10. Zahtjevi za sigurnost informacija u slučaju nezgoda
	4.1.11. Zahtjevi za zaštitu od utjecaja vanjskih utjecaja
	4.1.12. Zahtjevi za odobrenje patenta
	4.13. Zahtjevi za standardizaciju i unifikacija
4.4. Zahtjevi za sastav i parametre tehničkih sredstava	4.1.8. Zahtjevi za rad, održavanje, popravku i skladištenje komponenti sistema
4.5. Zahtjevi za informacije i kompatibilnost softvera
4.6. Zahtjevi za etiketiranje i pakovanje
4.7. Zahtjevi za transport i skladištenje	4.1.7. Zahtjevi prenosivosti za mobilne sisteme
4.8. Posebni zahtjevi	4.14. Dodatni zahtjevi
	4.3. Zahtjevi za vrste kolaterala
5. Zahtjevi za softversku dokumentaciju	8. Zahtjevi za dokumentacijom
6. Tehnički i ekonomski pokazatelji
7. Faze i faze razvoja	5. Sastav i sadržaj rada na kreiranju sistema
8. Postupak kontrole i prihvatanja	6. Procedura kontrole i prihvatanja sistema
	7. Zahtjevi za sastav i sadržaj radova na pripremi objekta automatizacije za puštanje sistema u rad
	9. Izvori razvoja

Dakle, projektni zadatak bi, zapravo, trebao odražavati sve zahtjeve za projektovani proizvod, istaknute u fazi analitičke studije objekta automatizacije.

Na osnovu gornje tabele možemo izdvojiti glavne dijelove tehničkog zadatka:

• Opće informacije o sistemu (programu);
• Svrha, ciljevi i zadaci sistema (programa);
• Sistemski zahtjevi (funkcionalni zahtjevi, zahtjevi korisnika, sistemski zahtjevi u cjelini, itd.);
• Zahtjevi za vrste kolaterala;
• Zahtjevi za dokumentaciju;
• Faze i faze razvoja;
• Postupak kontrole i prihvatanja sistema (programa).

Opće informacije
Ovaj dio dokumenta Projektni zadatak treba da sadrži pun naziv sistema i sve opcije skraćenica koje će se koristiti u izradi dokumentacije.

primjer:

„U ovom dokumentu informacioni sistem koji se kreira naziva se „Jedinstveni prozor za pristup obrazovnim resursima“, skraćeno SW.
Sistem Jedinstveni prozor za pristup obrazovnim resursima može se u daljem tekstu u ovom dokumentu nazivati ​​Jedinstveni prozor ili Sistem."

Takođe, ovo bi trebalo da sadrži pododeljke koji informišu detalje o organizacijama uključenim u razvoj (Kupac i Izvođač).

U pododjeljku „Osnove za izradu“ dokumenta Projektnog zadatka navedeni su glavni dokumenti na osnovu kojih se ovi radovi izvode. Na primjer, za sistem koji je naručila vlada zemlje ili druga državna agencija, zakoni, uredbe i naredbe Vlade moraju biti specificirani.

Lista termina i skraćenica takođe treba da bude sastavni deo dokumenta o zadatku. Termini i skraćenice najbolje su predstavljeni kao tabela sa dve kolone "Term" i "Full Form".

Izrazi i skraćenice su navedeni po abecednom redu. Prije svega, uobičajeno je dati dekodiranje pojmova i skraćenica na ruskom jeziku, zatim onih na engleskom.

Svrha i ciljevi sistema

Ovaj dio dokumenta Projektni zadatak treba da sadrži svrhu i ciljeve kreiranja sistema.

primjer:

"Informacioni sistem" Jedinstveni prozor pristupa obrazovnim resursima "je dizajniran da korisnicima pruži potpune, operativne i pogodne informacije o obrazovnom sistemu Ruske Federacije, organizacijama koje obavljaju funkciju obrazovnih institucija.

Osnovna svrha Sistema je formiranje jedinstvenog informacionog okruženja i automatizacija poslovnih procesa obrazovnih institucija Ruske Federacije.

Stvaranje informacionog sistema "Jedinstveni prozor" trebalo bi da obezbedi:

• pružanje korisnicima širokog spektra informacionih resursa;
• povećanje nivoa informacione sigurnosti;
• poboljšanje efikasnosti obrazovnih institucija i odeljenja optimizacijom niza poslovnih procesa;
• povećanje efikasnosti procesa interakcije informacionih sistema i usluga unutar odeljenja.

Stvaranje Sistema će smanjiti operativne troškove kao rezultat povećanja efikasnosti odjela."

Zahtjevi sustava

Ovaj odjeljak Izjave o radu ima za cilj da opiše osnovne funkcionalne zahtjeve sistema. Ovo je najvažniji dio tehničkog zadatka, jer će to biti vaš glavni argument u sporovima sa Kupcem u procesu puštanja sistema u rad. Stoga je potrebno najpažljivije pristupiti njegovom pisanju.

Projektni dokument mora sadržavati sve zahtjeve identifikovane u fazi analize objekta automatizacije. Najbolje je istaknuti glavne poslovne procese, koje treba razotkriti kroz opis funkcionalnih zahtjeva.

primjer:

"4.1 Poslovni proces" Pružanje informacija o obrazovnim institucijama Ruske Federacije

U ovom poslovnom procesu izdvajaju se sljedeći učesnici:

Moderator - zaposlenik odeljenja, koji je deo servisnog osoblja sistema, koji je odgovoran za tačnost datih podataka

Korisnik - građanin kojem su potrebne informacije o radu obrazovnih institucija Ruske Federacije.

4.1.1 Registracija obrazovne ustanove u sistemu

Registraciju obrazovne ustanove Ruske Federacije vrši odgovorni zaposlenik institucije ("Uredba Vlade ...").

Proces registracije obrazovne ustanove uključuje sljedeće korake:

• Autor kreira zapis o organizaciji;
• Autor unosi podatke organizacije;
• Sistem provjerava licencu za ovu organizaciju

• Ako licenca postoji u bazi podataka, Sistem šalje poruku Autoru o uspješnoj registraciji;
• Ako licenca nije pronađena u bazi podataka, sistem šalje poruku Autoru o nepostojanju licence za ovu organizaciju."

Ako vreme dozvoljava, informacije date u ovom odeljku trebalo bi potpunije da se obelodane u aneksu dokumenta Uslovi rada. U prilogu projektnog zadatka možete donijeti ekranski obrazac i u nastavku opisati sve događaje koji su prisutni na njemu (kreiranje, pregled, uređivanje, brisanje itd.).

Zahtjevi za sistem u cjelini uključuju otkrivanje njegove arhitekture sa opisom svih podsistema. Ovaj dio Projektnog zadatka treba da opiše zahtjeve za integraciju sistema sa drugim proizvodima (ako ih ima). Nadalje, projektni zadatak bi trebao uključivati:

• zahtjevi za režime rada sistema
• indikatori odredišta
• zahtjevi za pouzdanost
• sigurnosnih zahtjeva
• zahtjeve za brojem i kvalifikacijama osoblja i načinom njihovog rada
• zahtjevi zaštite informacija
• zahtjevi za sigurnost informacija u slučaju nezgoda
• zahtjevi za čistoću patenta
• zahtjevi za standardizaciju i unifikacija
• itd.

Zahtjevi za vrste kolaterala

U ovom dijelu dokumenta, Projektni zadatak treba da predstavi zahtjeve za matematičku, informatičku, lingvističku, softversku, tehničku i druge vrste podrške (ako ih ima).

Zahtjevi za dokumentaciju

Odjeljak „Zahtjevi za dokumentaciju“ tehničkog zadatka sadrži spisak projektne i operativne dokumentacije koja se mora dostaviti naručiocu.

Ovaj odjeljak tehničkog zadatka je jednako važan kao i opis funkcionalnih zahtjeva, stoga se ne treba ograničiti na frazu „Kupcu mora biti dostavljena sva dokumentacija u skladu sa GOST 34“. To znači da morate dostaviti cijeli paket dokumenata uključujući "obrazac", "pasoš" itd. Većina dokumenata sa liste navedene u GOST 34.201-89 nije potrebna ni vama ni kupcu, stoga je bolje da se odmah dogovorite o listi u fazi izrade dokumenta Projektni zadatak.

Minimalni paket dokumenata obično uključuje:

• Tehnički zadatak;
• Spisak nacrta (tehničkog) projekta;
• Objašnjenje tehničkog projekta;
• Opis organizacije informacione baze;
• Korisnički vodič;
• Administrator's Guide;
• Program i metodologija testiranja;
• Izvještaj o prijemnom ispitivanju;
• Potvrda o završetku

Listu dokumenata u projektnom zadatku je bolje prikazati u obliku tabele, u kojoj se navodi naziv dokumenta i standard na osnovu kojeg treba da se razvije.

Faze i faze razvoja

U ovom dijelu dokumenta, Projektni zadaci treba da daju informacije o svim fazama posla koji će se izvršiti.

Opis faze treba da sadrži naziv, vrijeme, opis rada i konačni rezultat.

Kontrola sistema i postupak prihvatanja

U ovom odeljku Projektnog zadatka potrebno je navesti dokument na osnovu kojeg treba izvršiti testove prihvata.

Ako je potrebno, projektni zadatak se može dopuniti drugim odjeljcima ili smanjiti uklanjanjem neprikladnih stavki.

Prilikom promjene strukture tehničkog zadatka, kako bi se izbjegle konfliktne situacije, ona mora biti dogovorena sa naručiocem prije izrade dokumenta.

Narudžbu za izradu korporativnog identiteta, dizajna ambalaže, logotipa ili web stranice uvijek prati priprema i izrada relevantne dokumentacije – ugovora, briefa i tehničkog zadatka (TZ). Izrada tehničke specifikacije je prva faza zajedničkog rada naručioca i izvođača.

Jedan od najčešćih načina za smanjenje troškova i budžeta za projekat je da to uradite sami. pisanje TK (tehnički zadatak) .

Međutim, bez određenog iskustva, prilično je teško sastaviti kompetentnu tehničku specifikaciju, koja će biti jasna i izvođaču i kupcu.

U projektnom zadatku potrebno je tačno i jasno opisati zahtjeve za predmetom rada, utvrditi tehničke parametre, namjenu objekta, pripremiti sastav potrebne projektne dokumentacije, odrediti rokove i proceduru izvođenja radova. .

Prije nego što se pristupi izradi tehničkih specifikacija, potrebno je provesti istraživanje, preliminarne proračune i prikupiti početne informacije.

Izrada tehničkog zadatka je složen proces, koji je bolji za realizaciju profesionalaca, osim toga vaš "kraljevski brend" ima važnije i prioritetnije zadatke od pisanja tehničkog zadatka.

Tehnički zadatak je

Tehnički zadatak - ovo je temeljni dokument cjelokupnog projekta i odnosa između naručitelja i izvođača, koji vam omogućava da jasno definirate redoslijed radova, odgovornosti strana i vrijeme realizacije projekta.

Uslovi implementacije i uspjeh projekta u cjelini ovisit će o tome koliko je ispravno, precizno i ​​jasno sastavljen projektni zadatak za izvođača.

Vrste tehničkih specifikacija (tehničke specifikacije)

Projektni zadatak je prvi korak ka implementaciji svakog projekta. Postoji bezbroj vrsta tehničkih specifikacija za izvođenje radova:
- projektni zadatak za razvoj stranice;
- projektni zadatak za izradu logotipa;
- projektni zadatak za izradu programa;
- projektni zadatak za razvoj korporativnog identiteta;
- projektni zadatak za razvoj dizajna;
- projektni zadatak za razvoj naziva kompanije;
- projektni zadatak za promociju web stranice itd.

Bez obzira na to koga ste odabrali za ulogu izvršioca projekta – freelancera ili brending agenciju, prije početka rada na projektu potrebno je analizirati i obraditi velike količine heterogenih informacija. Proučite podatke u vezi sa ciljevima i zadacima projekta, strateškim i trenutnim ciljevima kompanije, zahtjevima za predmetom rada, željama naručioca, rokovima isporuke gotovog projekta i očekivanim rezultatima. Zatim morate zajedno prikupiti ove informacije, strukturirati podatke i dati izvođaču radova u obliku tehničkog zadatka.

Izrada tehničkih specifikacija je u pravilu zadatak voditelja projekta. Niko osim kupca neće na najbolji način opisati ideje, principe rada, ciljeve projekta i aktivnosti kompanije. Ovaj opis treba da bude što jasniji i predstavljen u obliku opšte priče o kompaniji i njenom brendu.

Struktura tehničkog zadatka

Struktura tehničkog zadatka (oblik tehničkog zadatka) je sljedeća:

1. Ciljevi projekta
U TOR-u je potrebno naznačiti koje ciljeve kompanija želi postići koristeći rezultate završenog projekta. Takvi ciljevi, na primjer, mogu biti: izdavanje novog proizvoda, rebrendiranje kompanije ili robne marke, reklamna kampanja itd.
2. Opis firme kupca
- Područje djelatnosti i obim kompanije, njena misija i tržišna pozicija;
- Opis portfelja brendova kompanije - sa kojim brendovima kompanija radi;
- Spisak najvećih konkurentskih kompanija;
- Lista glavnih konkurentskih prednosti kompanije i USP (jedinstvena prodajna ponuda).
3. Opis situacije i najnovijih tržišnih trendova za koji se brend razvija
- Cjenovni segment proizvoda ili usluga kompanije;
- Portret potrošača (starost, pol, geografski podaci, društveni nivo ciljne publike);
- Taktički i strateški marketinški ciljevi kompanije (za period od 1 do 3 godine);
- model ponašanja potrošača i opis situacija u kojima potrošač kupuje;
- Opis osnovnih karakteristika postojećeg brenda, koncept njegovog pozicioniranja, slogan, marketinške komunikacije, potrebne u slučaju rebrendiranja.
4. Reference
Spisak primjera sličnih radova koji se dopadaju kupcu u kontekstu ovog projekta.
5. Zahtjevi
U ovom dijelu potrebno je registrovati sve tehničke i funkcionalne zahtjeve za projekat. Kao i zahtjeve i želje kupca za grafiku, tekst, boje, stil, fontove,