No autora: Kā rakstīt darba uzdevums (TOR) vietņu izstrādei? Tēma ir diezgan plaša, un ir grūti to 100% analizēt vienas nots ietvaros (ja vispār iespējams). Bet es mēģināšu ieskicēt vispārīgos noteikumus par to, kas jāņem vērā un kam jāpievērš uzmanība, pietiekami detalizēti sastādot mājas lapas darba uzdevumu.

Tātad, tehniskās specifikācijas vietņu izstrādei

Tehniskās specifikācijas ir sagatavotas izstrādātājam. Uz darba uzdevumu ir jāatsaucas, sastādot līgumu starp pasūtītāju un darbuzņēmēju. Jāatrunā abu pušu atbildība par punktu un termiņu neizpildīšanu vai nepareizu izpildi. Bet pats svarīgākais (manuprāt), kam tiek veidotas tehniskās specifikācijas, ir priekš projekta izstrādes procesa paātrināšana.

Analizēsim šo piemēru:

Pieņemsim, ka jums ir nepieciešams kalendārs kaut kur jūsu vietnes malā. Tas šķita sīkums. Bet jo detalizētāk aprakstīsit tā funkcionalitāti, jo ātrāk iegūsit rezultātu.

Ļaujiet man šeit nedaudz paskaidrot. Ir kalendārs, kas vienkārši parāda skaitļus pa kārtējā mēneša nedēļas dienām. Un ir iespēja šķirstīt mēnešus. Ir kalendārs ar iespēju šķirstīt mēnešus un gadus.

JavaScript. Ātrs sākums

Teiksim, ka vajag pēdējais variants(ar iespēju ritināt mēnešus un gadus) ar pašreizējā datuma izcelšanu. Darba uzdevumā jūs norādījāt: "sānjoslā ir nepieciešams kalendārs." Viņi sniedz jums pirmo iespēju (tas vienkārši parāda skaitļus pēc pašreizējā mēneša nedēļas dienām).

Kas mums ir? Darbuzņēmējs izpildīja specifikāciju, bet jūs gribējāt kaut ko pavisam citu. Šķiet, ka viss ir saskaņā, neviens nav vainīgs, nav konflikta, bet vissvarīgākais ir zaudēts laiks un nauda.

Šis ir tikai banāla kalendāra piemērs.

Ko darīt, ja jāpārtaisa kas nopietnāks, kura apstrāde prasa vairāk nekā pusi dienas, kā tas ir kalendārā? Darbuzņēmējs ir aizņemts ar jums, kad viņš varētu pabeigt jūsu projektu un sākt jaunu.

Tāpēc, nekā sīkāka informācija Jūs aprakstāt katra moduļa funkcionalitāti, jo ātrāk iegūsit rezultātu. Par to vajadzētu interesēties abām pusēm.

No kādiem punktiem parasti sastāv tehniskā specifikācija?

Iedomāsimies, ka esat uzņēmuma vai firmas īpašnieks. Jūsu uzņēmums nodarbojas ar jebkura produkta ražošanu un tā realizāciju. Jums ir pircēji. Jūs sadarbojaties ar pārdevējiem (veikali un interneta veikali), servisa centriem un preču patērētājiem. Vai arī jūs veidojat resursu šādam uzņēmumam un jums ir jāuzraksta tehniskā specifikācija.

Neatkarīgi no tā, kādu lomu jūs spēlējat, pirmais, kas jums jādara pirms tehnisko specifikāciju izstrādes tīmekļa vietnes dizaina izveidei, ir izpētīt organizācijas struktūru, tās darbību, nomenklatūru, īpašības un kopumā visu, kas ir saistīts ar produktu. un uzņēmums. Tas, kas notiks ar resursu, ir atkarīgs no tā, cik dziļi klients izprot uzņēmumā notiekošā būtību. Tāpēc uzdevums šeit ir abpusējs: pasūtītājam ir jāstāsta par uzņēmumu pēc iespējas detalizētāk, un darbuzņēmējam rūpīgi jāsaprot notiekošā būtība.

Pat ja jūs pats rakstāt tehniskās specifikācijas uzņēmumam, kas veiks jūsu projektu, ieteicams to visu izdomāt uz papīra lapas.

Ejam punktu pa punktam.

Apraksts

Šeit varat pāris teikumos uzrakstīt par uzņēmumu un tā darbību. Dariet kaut ko līdzīgu ievadam.

kam - mērķauditorija:

potenciālie pircēji

preču pārdevēji (veikali, interneta veikali)

servisa centri

partneri (firmas)

produktu patērētāji (tie, kuri jau ir iegādājušies)

Kāpēc jums ir nepieciešama vietne:

Uzņēmuma tēla uzlabošanai

Lai palielinātu pārdošanas apjomu

Klientu ērtībām

Korporatīvs

Mājas lapa – vizītkarte

Interneta veikals

Valodu versijas:

angļu valoda

Vietnei ir jāatrisina dažas problēmas. Attiecīgi mēs virzāmies uz mērķiem un uzdevumiem.

Mērķi un uzdevumi

Šajā tehnisko specifikāciju sadaļā mēs ejam cauri visai mērķauditorijai un aprakstām uzdevumu klāstu, kas vietnei viņiem būtu jāatrisina.

Potenciālie produktu pircēji.

Mērķis: piesaistīt vairāk pircēju un pārliecināt jūs veikt pirmo pirkumu, palīdzēt jums izdarīt izvēli.

Problēmas ir jāatrisina:

Sniegt augstas kvalitātes, visaptverošu informāciju par produktiem, papildu pakalpojumi, garantijas, serviss, atlases metodes.

Sniedziet informāciju par izstāžu zālēm

Sniedziet informāciju par mazumtirdzniecības tīklu

Nodrošiniet iespēju uzdot jautājumu, organizējot uzņēmuma speciālistu potenciālo pircēju konsultācijas tiešsaistē par preču izvēles un iegādes jautājumiem.

Tādējādi mēs ejam cauri visai mērķauditorijai. Mēs arī aprakstām mērķus un uzdevumus produktu pārdevējiem (veikali, tiešsaistes veikali), servisa centriem, partneriem (firmām) un produktu patērētājiem. Tas ir, kas vietnei būtu jādara īpaši katram no tiem.

Tagad mēs uzskaitām moduļus.

Vietnes funkcionalitāte

Lai uzskaitītu funkcionalitāti, jums jāizlemj, kas tai nepieciešams:

Vai ir nepieciešama reģistrācija?

Vai man ir nepieciešama slēgta sadaļa (tikai reģistrētiem lietotājiem)

Vai ir nepieciešama atsauksmju veidlapa?

utt. utt.

JavaScript. Ātrs sākums

Izpētīt JavaScript pamati par praktisko tīmekļa lietojumprogrammas izveides piemēru

Pēc tam, kad tas viss ir aprakstīts, mēs nonākam pie vissvarīgākā un interesantākā. Protams, viss iepriekš paveiktais ir ļoti svarīgs, taču tagad tas kļūst vēl karstāks.

Funkcionalitātes apraksts

Ieslēgts šobrīd mēs zinām, kam vietne ir paredzēta, kādi mērķi un uzdevumi tai jāsasniedz, tā papildu funkcionalitāte.

Ir pienācis laiks, kad visu savākto informāciju jāienes sistēmā un skaisti jāsakārto. Lai atvieglotu uzdevumu un neizgudrotu riteni no jauna, varat apskatīt resursus par līdzīgām tēmām. Paņemiet kaut ko no viņiem, apskatiet un izmēģiniet to funkcionalitāti un to, kas šķita neērti, mēģiniet to uzlabot savā projektā. Principā jūs varat apskatīt vietnes par līdzīgām tēmām (un, ja jums nav pieredzes, tad jums pat ir nepieciešams) pašā tehnisko specifikāciju izstrādes sākumā.

Es iesaku sākt ar izvēlnes elementiem. Tam ir jāparāda galvenās lapas un jānodrošina, lai katrs apmeklētājs ātri atrastu informāciju par sevi. Un apmeklētāji ir mūsējie mērķauditorija. Izvēlnē būs daudz vienumu, tāpēc tā būs nolaižamā saraksta veidā.

Pirmkārt, jums ir jāpastāsta par uzņēmumu. Var būt lapas par uzņēmumu, uzņēmuma vēsturi, kontaktiem, atsauksmēm.

Protams, ir jābūt izvēlnes vienumam “produkti”, ar apakšpozīcijām “produktu katalogs”, “izlaidumi”, “produktu apskati”.

Kopumā es ceru, ka ir skaidrs, kā to aprakstīt. Ļaujiet man iepazīstināt ar iespējamās izvēlnes galīgo versiju:

par uzņēmumu

uzņēmuma vēsture

kontaktpersonas

produktiem

produktu katalogs

produktu atsauksmes

servisa nodaļa

garantijas serviss

pēcgarantijas serviss

patērētājam

pirkšana un piegāde

izmantot

par pakalpojumu

veikali un interneta veikali

produktu fotogrāfijas

Bieži uzdotie jautājumi

servisa centri

Kā kļūt servisa centrs

Bieži uzdotie jautājumi

partneriem

uzaicinājumu uz sadarbību

Bieži uzdotie jautājumi

Šķiet, ka esam sakārtojuši ēdienkarti. Tagad jums jāapraksta, kas būs katrā lapā un kā tas viss darbojas. Turklāt sniedziet aptuvenu izkārtojumu. To var uzzīmēt uz papīra ar zīmuli, ieskenēt un pievienot tehniskajām specifikācijām. Vienīgais, ko es teikšu, ir neierobežojiet dizainera iztēli, ieskicējiet to pats vispārējs skats.

Šī daļa mainās atkarībā no tā, kā vēlaties, lai jūsu lapa izskatītos. Varbūt nevajag tik daudz baneru augšpusē, varbūt augšpusē jānorāda kontakti (adrese, tālrunis, fakss), varbūt ikonu “vietnes karte”, “mājas”, “kontakti” veidā. Varbūt jums nav vajadzīgas ziņas kreisajā pusē, bet kreisajā pusē rāda “akcijas un izlaidumi”.

Tagad galvenais ir aprakstīt darba loģiku.

Darbības loģika

Es aprakstīšu, pamatojoties uz iepriekš redzamo attēlu.

Galvene katrā lapā paliek nemainīga. Ziņu plūsma ir redzama tikai mājas lapa. Kreisajā pusē esošajās sekundārajās lapās mēs parādām tās preces izvēlnes apakšpunktus, kurā pašlaik atrodamies (piemēram, ja atrodamies lapā “klientu apkalpošana”, mēs rādām saites uz “garantijas serviss”, “pēcgarantijas serviss”. ”). Attiecīgi, noklikšķinot uz šīm saitēm, tiek atvērtas atbilstošās lapas. Šeit zem apakšvienumiem kreisajā pusē tiek parādīti dati saziņai ar tiešsaistes konsultantiem (Skype, ICQ). Reklāmu un izlaidumu bloks paliek katrā lapā. Kājene tiek rādīta vienādi katrā lapā.

Aptuveni šādi tiek aprakstīta vispārējā darba loģika.

Tagad mūsu tīmekļa vietnes izstrādes darba uzdevumā mēs sīki aprakstām katru norādīto vietnes bloku. Piemēram, “Ziņu plūsma”.

"Ziņu plūsma" no 10 jaunākās ziņas. Katrai ziņai ir jāsastāv no ziņas nosaukuma, publicēšanas datuma, īsa ziņas sākuma (4-5 rindiņas) un saites “lasīt pilnībā”. Noklikšķinot uz saites “lasīt pilnībā”, jūs tiksit novirzīts uz ziņu lapu. Galvenā satura vietā tiek rādītas ziņas, kuras jūs sastapāt. Tas ietver arī ziņu nosaukumu un publicēšanas datumu. Kreisajā pusē tiek parādīta arī ziņu plūsma. Pēdējo mēnešu un gadu ziņas tiek arhivētas. Tas ir, zem ziņām par kārtējais mēnesis parādīt “arhīvs par (šāda un tāda mēneša vai gada)”. Noklikšķinot uz saites “arhīvs par (šādu un tādu mēnesi vai gadu)”, tiek parādīts atbilstošā mēneša/gada ziņu saraksts.

Šādi mēs aprakstām katra bloka darbību. Neaizmirsīsim par kalendāra notikumu. Un pats galvenais, jums ir jāapraksta produktu kataloga darbs. Šeit es jums dodu uzdevumu: mēģiniet pārdomāt un aprakstīt, kā katalogs darbosies. Nosūtiet savas iespējas pa e-pastu. Mēs publicēsim labāko.

Kam vēl vajadzētu būt? Būtu jauki norādīt saderību.

Saderība

Šajā tīmekļa vietnes izveides darba uzdevuma punktā mēs norādām, kura operētājsistēmas un kurās pārlūkprogrammās vietnei vajadzētu izskatīties vienlīdz labi. Kādā versijā, kādā valodā tas jāraksta. Kāda CMS tiek izmantota. Ir vērts to norādīt, ja jūs patiešām zināt, par ko jūs runājat.

Ja nezināt šos jautājumus, vienkārši norādiet pārlūkprogrammas, kurās vietne ir jāparāda pareizi. Pārējā gadījumā paļaujieties uz izpildītāja sirdsapziņu.

Secinājums

Šajā rakstā necentos parādīt, ka tehniskās specifikācijas ir sastādītas tieši tā un ne citādi. Dariet to, un nebūs problēmu. Sastādiet kvalitatīvu mājas lapas izstrādes darba uzdevums- tas ir vairāk jautājums pieredze. Ne visi pirmajos pāris gados varēs izveidot kompetentu tehnisko specifikāciju.

Šajā rakstā vēlējos parādīt piemēru un principus, uz kuriem tiek veidota tehniskās specifikācijas paraugs mājas lapas dizaina un loģikas izstrādei, kā arī galvenos punktus, kam ir vērts pievērst uzmanību. Cik man izdevās, es ceru uzzināt no jūsu komentāriem.

Un neaizmirstiet par uzdevumu!

Viena no svarīgākajām sastāvdaļām jebkurā iepirkumā ir darba uzdevums. To apkopo klients, lai vislabāk raksturotu produktu vai pakalpojumu, kas viņam jāsaņem.

Jo precīzākas un pareizākas būs tehniskās specifikācijas, jo vieglāk būs gan piegādātājam, gan pašam klientam.

Pirkuma darba uzdevumam ir jāatbilst tiesību aktu prasībām. Un papildus 44-FZ, sagatavojot tehniskās specifikācijas, ir jāņem vērā Pretmonopola dienesta normatīvās prasības un tiesību akti par tehniskajiem noteikumiem.

Galu galā to pārkāpums, kā arī nepilnīgs vai neprecizēts nepieciešamo pakalpojumu vai preču apraksts var izraisīt neatbilstošu pieteikumu iesniegšanu, bet atteikuma gadījumā šiem piegādātājiem - sūdzību FAS par nepamatotu atteikumu.

44-FZ tehnisko specifikāciju izstrāde

Kvalitatīva iepirkuma tehnisko specifikāciju sagatavošana ir veiksmīga konkursa atslēga, jo, kad būs izstrādāti visi tehniskās specifikācijas punkti, Jūs saņemsiet konkurētspējīgus, atbilstošus un spēcīgus pieteikumus dalībai ar precīzas preces piedāvājumu, darbu. vai pakalpojumu, kuru plānojat saņemt.

Padoms: Ir vērts atcerēties, ka pārmērīgas prasības un specifikācijas var būt pretrunā ar 44-FZ prasībām, tāpēc jums vienmēr jāievēro tā standarti.

Ja jums nepieciešama palīdzība dokumentu noformēšanā atbilstoši klienta specifikācijām vai neesat pārliecināts par aizpildīšanas pareizību, varat izmantot mūsu pieteikuma veidlapu pakalpojumu vai saņemt bezmaksas konsultāciju pie mūsu speciālistiem.

Visu tehnisko specifikāciju kopums, kas sastādīts saskaņā ar 44-FZ iepirkumam, tieši ietekmē iepirkuma plānu un veido grafiku nākamajam periodam. Ideālā gadījumā klients, sastādot visu nepieciešamo preču vai pakalpojumu sarakstu, kas būs jāsaņem nākamajā periodā, plāno noteiktus punktus:

kādā formā tiks rīkoti konkursi;

vai ir iespējams apvienot dažas partijas vienā pirkumā vai prātīgāk būtu veikt vairākas operācijas;

kādā daudzumā un formā iesniegt piedāvājumu konkrētai precei, jo vienreizēju pirkumu konkursa veidā var veikt reizi periodā vai veikt piedāvājuma pieprasījumu, piemēram, katru ceturksni.

No visām šīm niansēm atkarīgs, kā tieši tiks sastādīts iepirkuma plāns un attiecīgi grafiks.

Tehnisko specifikāciju sagatavošana

Sagatavojot iepirkuma darba uzdevumu, pasūtītājam pēc iespējas atklātāk un precīzāk jānorāda visi parametri, lai izpildītājs varētu sagatavot kvalitatīvu piedāvājumu, izvērtējot apjomu un sarežģītību. Ir ļoti svarīgi norādīt prasības saskaņā ar 44-FZ, nepārsniedzot pilnvaras.

Parasti iepirkuma specifikācijā ir ietverti šādi elementi:

pirkuma apraksts, t.i. preču, darbu vai pakalpojumu nosaukums;

izsoles priekšmeta tehniskās īpašības;

daudzums un konfigurācija, ja mēs runājam par produktu;

piegādes vai pabeigšanas datumi;

garantijas un drošības prasības;

apmaksas un piegādes noteikumi;

citas prasības, kas nav pretrunā ar likumā noteiktajiem nosacījumiem;

Būtisks ir tas, ka pasūtītājam elektroniskās izsoles darba uzdevumā ir jānorāda minimālās vai maksimālās rādītāju robežas, bet izpildītājam, novērtējot savas iespējas, precīzas vērtības jānorāda 2. veidlapā.

Ņemot vērā šos konkrētos rādītājus, pasūtītājs lems par piegādātāju pielaišanu dalībai izsolē.

Iepirkuma noteikumu paraugs

Sastādot tehniskās specifikācijas, daudzi klienti vēlas atrast kaut kādu vienotu vienotu formu. Likumā strikti reglamentētas formas nav, bet ir vispārīgās prasības sadaļām un pieņemto noformējuma formātu.

Jūs varat redzēt 44 federālo likumu tehniskās specifikācijas piemēru un atbildi uz to mūsu tīmekļa vietnē lapa “Pieteikuma sagatavošana un iesniegšana”. IN šajā piemērā tajā ir sīki aprakstīts, kā tehniskajām specifikācijām vajadzētu izskatīties pasūtītāja konkursa dokumentācijā un kā darbuzņēmējam jāraksta atbilde. Šī informācija būs noderīga visiem pretendentiem.

OOO ICC"RusTender"

Materiāls ir vietnes īpašums. Jebkura raksta izmantošana, nenorādot avotu - vietne ir aizliegta saskaņā ar Krievijas Federācijas Civilkodeksa 1259.

Kas ir tehniskā specifikācija? Kā to izdarīt un kam tas paredzēts? Piemēri, paraugi, padomi un ieteikumi.

Šķiet, cik lieliski ir, ja kāds tevi lieliski saprot. Jūs izteicāt dažas frāzes, un tas ir tieši tas, ko jūs iedomājāties. Diemžēl tas tā nedarbojas.

Informācijas uztveres problēma ir mūžīga. “Sabojāta tālruņa” efekts ir izplatīta parādība. Bet ko darīt, ja jūs vienkārši nezināt, kā iestatīt uzdevumu? Jā, tā arī notiek, un ar to kaut kā jāstrādā, bet kā? Lai nodrošinātu, ka izvirzīto uzdevumu rezultāti atbilst jūsu cerībām, uzrakstiet tehnisko specifikāciju.

Kas ir tehniskā specifikācija

Tehniskā specifikācija (vai TOR) ir dokuments, kas satur klienta prasības attiecībā uz darbuzņēmēja sniegtajiem produktiem vai pakalpojumiem. Vienkāršiem vārdiem sakot: Es gribu tā un tā, lai ir septiņas savstarpēji perpendikulāras līnijas, kā arī dažas zīmējiet sarkanā krāsā un dažas bezkrāsas (iesaku materiāla beigās noskatīties video par šo tēmu).

Dizaina birojs

Šis dokuments var aizņemt vai nu vienu A4 lapu, vai veselu sējumu, tas viss ir atkarīgs no tajā iekļautajiem uzdevumiem un vēlmēm. Piemēram, varat uzrakstīt tehnisko specifikāciju nelielai galvenajai lapai (vienas lapas vietnei) vai sarežģītai programmatūrai ar mašīnmācīšanos un citām funkcijām.

Kāpēc jums ir nepieciešamas tehniskās specifikācijas?

• Uzdot izpildītājiem uzdevumus.
• Detalizēti aprakstīt, ko vēlaties iegūt beigās.
• Vienoties par darba kārtību.
• Novērtēt un pieņemt darbu pēc realizācijas.
• Uz… (pievienojiet savas iespējas komentāros).

Faktiski tehniskajai specifikācijai ir daudz vairāk mērķu un priekšrocību nekā iepriekš minētajā sarakstā. Man personīgi galvenais uzdevums, ko risina tehniskās specifikācijas, ir man nepieciešamā realizācija ar minimālām novirzēm no cerībām (manām cerībām).

Pateicoties tehniskajām specifikācijām, jūs vienmēr varat jautāt par ieviešanas laiku, naudu un atbilstību gala produkta vai pakalpojuma deklarētajām īpašībām.

Faktiski tas ir nopietns dokuments, ko sastāda pasūtītājs un darbuzņēmējs. Ciktāl ir noteikti pušu sodi un pienākumi. Ir vairāki GOST, lasiet vairāk vietnē Habré.

Tehnisko specifikāciju izstrāde

Ja mēs runājam par “pieaugušo” spēli, piemēram, tehniskās specifikācijas izstrādei mobilā aplikācija vai vietne, tad tas ir atsevišķs darbs, par kuru tiek maksāta liela nauda. Jūs piesaistāt kādu personu, parasti bijušo vai pašreizējo galveno tehnisko vadītāju, un lūdzat viņam palīdzēt.

Bārda nav obligāta

Atkarībā no projekta/uzdevumu apjoma šis cilvēks apkopo visas jūsu “vēlmes”, pārtulko tehniskajā valodā, iespējams, sagatavo skices (kā tam vajadzētu aptuveni izskatīties) un iedod gatavo dokumentu. Pēc tam jūs nododat šo dokumentu izpildītājiem (jūsu uzņēmuma kolektīvam vai ārpakalpojumam), vienojaties par naudu, termiņiem un ķeraties pie darba.

Padoms: CTO ir jābūt jūsu komandā, pretējā gadījumā jūs, visticamāk, kaut ko palaidīsit garām ieviešanas procesā. Jums vienkārši nepietiek zināšanu visam. Tas, kurš piedalījās tehnisko specifikāciju rakstīšanā, to pārbauda.

No kā sastāv tehniskā specifikācija?

Viss būs atkarīgs no izvēlētās veidnes (nedaudz tālāk es sniegšu dažas saites uz veidnēm/piemēriem), taču ir pamata bloki, kas ir iekļauti tehniskajās specifikācijās:

1. Projekta/uzdevuma apraksts. Īsi uzrakstām, kas ir projekts vai uzdevums, kas jāpabeidz.
2. Mērķis un mērķi. Kādi ir projekta mērķi?
3. Prasības. Dizains, funkcijas, tehnoloģijas, kas ir nepieciešamas.
4. Darba apraksts. Kas, kad un kā tiks darīts.
5. Kontroles un pieņemšanas procedūra. Kā darbs tiks pieņemts, ko var uzskatīt par pabeigtu.
6. Lietojumprogrammas. Skices, skices, prototipi.

Darbu izmaksas parasti tiek iekļautas atsevišķā līguma pielikumā, bet tas notiek, kad puses pašas norāda summas tehniskajās specifikācijās.

Atvainojiet, ka pārtraucu lasīšanu. Pievienojieties manam telegrammas kanālam. Svaigi paziņojumi par rakstiem, digitālo produktu izstrāde un izaugsmes uzlaušana, tas viss ir tur. Es tevi gaidu! Turpināsim...

Tehnisko specifikāciju piemēri

Neskatoties uz to, ka tehnisko specifikāciju izstrāde ir sarežģīts process, tas ir ļoti interesants. Tavs uzdevums ir no jauna izveidot gala rezultāta attēlu un pēc tam aprakstīt to pa daļām.

Piemērs vienai no manām atjauninājuma tehniskajām specifikācijām Viedās lietotnes TV. Uzdevumi sarežģītākiem un sarežģītākiem produktiem tika sastādīti ar tehniskās nodaļas kolēģu palīdzību. Nevilcinieties lūgt palīdzību saviem komandas biedriem, iesaistiet viņus procesā pēc iespējas biežāk. Un neaizmirstiet dot atsauksmes! Nav nekas sliktāks, kā kaut kam veltīt pūles un laiku, nezinot rezultātus. Pastāstiet, kā cilvēka padoms noderēja jūsu darbā, pretējā gadījumā tā ir vienpusēja spēle.

Darba uzdevums interneta veikala izstrādei

Darba uzdevums mobilās aplikācijas izstrādei

Vietnes darba uzdevumi

Pakalpojumu/atjauninājumu darba uzdevumi

Ja jums ir nepieciešami vairāk paraugu, vienkārši izmantojiet Google.

Galvenais ieteikums ir to darīt. Problēma ir tā, ka mātes slinkums pārvar visus un tam nav viegli pretoties. Apkopojiet visu savu gribasspēku un sāciet rakstīt tehniskās specifikācijas, vienkārši rakstiet un neapstājies. Neuztraucieties, ka tas neizdodas "perfekti", es jums pateikšu noslēpumu, tas nekad nenotiek. Vienkārši rakstiet, ar katru reizi kļūs labāk un labāk.

Tā tam ir jābūt

Mani pirmie pamati tehnisko specifikāciju rakstīšanai sāka parādīties pirms vairākiem gadiem. Es strādāju ar dizaineriem, un man bija uzdevums izveidot reklāmas kampaņām. Es to vēlējos nesakarīgi un tas izvērtās par daudz izniekota laika un skaidrojumiem. Laika gaitā uzdevumu iestatīšana sāka pārvērsties par kaut kādiem semantiskiem blokiem un pēc tam par kaut ko līdzīgu tehniskai specifikācijai.

Piemēram, uzdevumam “Poga Patīk vietnē”:

1. Apraksts: mūsu vietnē ir jāizveido poga “Patīk”.
2. Mērķis un mērķi: lietotāju iesaistīšana, materiālu izdošana/vērtēšana pēc atzīmju Patīk skaita.
3. Prasības: sekojošs dizains (piemērs: saite uz kaut ko līdzīgu), funkcionalitāte (jebkurš lietotājs var novērtēt attēlu un patikt, vietnes sistēma ņem vērā atzīmju skaitu un maina materiālu iznākumu), tehnoloģija (pieejama uz darbvirsmas un vietnes mobilajām versijām).
4. Darba apraksts: uzzīmējiet 3 pogu izkārtojuma variantus (pabeigšanas datums: 10.01.17), izstrādājiet sistēmu materiālu izplatīšanai, pamatojoties uz like (datums: 14.10.17), funkciju pārbaudi (datums: 16.10.) 17), izlaidums (datums: 17.10.17.)
5. Darba pieņemšana: lietotājs nospiež like pogu, sistēma uzskaita klikšķi, un mainās materiālu piegāde.
6. Lietojumprogrammas: skices, skices, projektu piemēri, kuros darbojas līdzīga funkcija.

Atstājiet sev tās sadaļas un struktūras daļas, kas nepieciešamas jūsu uzdevumu veikšanai. Piemēram, sesto bloku “Lietojumprogrammas” var aprakstīt funkcionālajās prasībās. Pamata padoms: tā vai citādi aprakstiet uzdevumu atbilstoši tehnisko specifikāciju struktūrai. Tādā veidā jūs nepalaidīsit garām svarīgus punktus un pasargāsit sevi no liekiem jautājumiem, vienlaikus atvieglojot savu kolēģu dzīvi.

Lūk

Apskatījām, kas ir tehniskais uzdevums un kā to izdarīt. Tagad jums ir iespēja skaidri un skaidri noteikt uzdevumus, nodot savas domas citiem cilvēkiem un ietaupīt laiku papildu paskaidrojumiem. Es ceru, ka tagad jūs zināt, ko darīt ar šo visu.

Nesen viņi vērsās pie manis, lai konsultētu par standartiem tehnisko specifikāciju (TOR) rakstīšanai automatizētu sistēmu (AS) un programmatūras (programmatūras) izstrādei. Tāpēc es domāju, ka tagad došos uz Yandex, atradīšu piemērotu rakstu un nosūtīšu to. Bet tas tā nebija! Es neatradu vienu rakstu, kurā būtu uzskaitīti tehnisko specifikāciju standarti, ieskaitot veidnes un gatavu dokumentu piemērus. Šis raksts būs jāizveido pašam...

Tātad, galvenie standarti, metodoloģijas un zināšanu kopumi, kas piemin TK vai SRS (programmatūras (vai sistēmas) prasību specifikāciju):

GOST 34
GOST 19
IEEE STD 830-1998
ISO/IEC/IEEE 29148-2011
RUP
SWEBOK, BABOK utt.

GOST 34

GOST 34.602-89 Darba uzdevums automatizētas sistēmas izveidei regulē SISTĒMAS izveides tehnisko specifikāciju struktūru, kas ietver programmatūru, aparatūru, cilvēkus, kas strādā ar programmatūru, un automatizētos procesus.

Saskaņā ar GOST 34 tehniskajā specifikācijā jāiekļauj šādas sadaļas:

1. Vispārīga informācija
2. Sistēmas izveides (attīstīšanas) mērķis un mērķi
3. Automatizācijas objektu raksturojums
4. Sistēmas prasības
5. Sistēmas izveides darba sastāvs un saturs
6. Sistēmas kontroles un pieņemšanas kārtība
7. Prasības darbu sastāvam un saturam, lai sagatavotu automatizācijas objektu sistēmas nodošanai ekspluatācijā
8. Dokumentācijas prasības
9. Attīstības avoti

Izstrādājot tehniskās specifikācijas valdības projektiem, Klienti parasti pieprasa atbilstību šim konkrētajam standartam.

GOST 19

“GOST 19.xxx Vienota sistēma programmu dokumentācija (ESPD)” ir valsts standartu kopums, kas nosaka savstarpēji saistītus noteikumus programmu (vai programmatūras) un programmu dokumentācijas izstrādei, projektēšanai un apritei. Tie. Šis standarts īpaši attiecas uz programmatūras izstrādi.
Saskaņā ar GOST 19.201-78 Tehniskās specifikācijas, prasības saturam un dizainam, tehniskajās specifikācijās jāiekļauj šādas sadaļas:

1. Ievads;
2. Attīstības iemesli;
3. Attīstības mērķis;
4. Prasības programmai vai programmatūras produktam;
5. Prasības programmas dokumentācijai;
6. Tehniskie un ekonomiskie rādītāji;
7. Attīstības stadijas un stadijas;
8. Kontroles un pieņemšanas kārtība;
9. Pieteikumi.

Protams, GOST 34 (un 19) jau ir novecojuši, un man nepatīk tos izmantot, taču, pareizi interpretējot standartus, jūs varat iegūt labas tehniskās specifikācijas, skatiet Secinājumu.

IEEE STD 830-1998

Diezgan laba standarta 830-1998 definīcija — IEEE ieteicamā prakse programmatūras prasību specifikācijām ir sniegta pašā tā aprakstā:

Apraksta pareizi sastādītas prasību specifikācijas saturu un kvalitātes raksturlielumus programmatūra(VID) un nodrošina vairākas VID veidnes. Šī ieteicamā prakse ir paredzēta, lai noteiktu prasības programmatūrai, kas tiek izstrādāta, taču to var izmantot arī, lai palīdzētu izvēlēties patentētu un komerciālu programmatūras produktu.

Saskaņā ar standartu darba uzdevumā jāiekļauj šādas sadaļas:

1. Ievads

• 1. Mērķis
• 2. Darbības joma
• 3. Definīcijas, akronīmi un saīsinājumi
• 4. Saites
• 5. Īss pārskats

2. Vispārīgs apraksts

• 1. Produktu mijiedarbība (ar citiem produktiem un komponentiem)
• 2. Produkta īpašības (īss apraksts)
• 3. Lietotāja īpašības
• 4. Ierobežojumi
• 5. Pieņēmumi un atkarības

3. Detalizētas prasības (var tikt organizētas dažādos veidos, piemēram, šādi)

• 1. Prasības ārējām saskarnēm
  • 1. Lietotāja saskarnes
  • 2. Aparatūras saskarnes
  • 3. Programmatūras saskarnes
  • 4. Mijiedarbības saskarnes
• 2. Funkcionālās prasības
• 3. Veiktspējas prasības
• 4. Dizaina ierobežojumi (un atsauces uz standartiem)
• 5. Nefunkcionālas prasības (uzticamība, pieejamība, drošība utt.)
• 6. Citas prasības

4. Pieteikumi
5. Alfabētiskais rādītājs

Patiesībā iesācējam ir diezgan grūti saprast, kas šajās sadaļās ir jāiekļauj saskaņā ar iepriekš minēto struktūru (kā GOST gadījumā), tāpēc jums ir jāizlasa pats standarts, kas. tomēr angļu valodā. valodu.

Tiem, kas izlasa līdz galam, ir bonuss: tehnisko specifikāciju paraugs, ko rakstīju pirms daudziem gadiem (tagad es jau sen nestrādāju par analītiķi, un citus veiksmīgākus piemērus ir aizliegts atvērta publiskai apskatei NDA).

• Jurija Buluja prezentācija Programmatūras prasību klasifikācija un tās atspoguļojums standartos un metodoloģijās.
• Automatizēto prasību analīze informācijas sistēmas. 11. lekcija: Dokumentācijas prasības.
• Programmatūras prasību specifikācijas izstrādes noteikumi (lasīt kopā ar komentāriem)
• Tehnisko specifikāciju un citas dokumentācijas piemēri AS izstrādei Ekonomikas attīstības ministrijai
• GOST vadības stils. Gapertona raksts pareiza darbība no tehniskajām specifikācijām saskaņā ar GOST
• Biznesa analītiķa dokumentu veidnes no