Saya sering ditanya: "Bagaimana untuk membangunkan spesifikasi teknikal dengan betul untuk sistem automatik?" Topik yang sama sentiasa dibincangkan di pelbagai forum. Soalan ini sangat luas sehingga mustahil untuk dijawab secara ringkas. Oleh itu, saya memutuskan untuk menulis artikel panjang mengenai topik ini.

• Pada bahagian pertama" Pembangunan spesifikasi teknikal. Apakah itu, mengapa ia diperlukan, di mana untuk bermula dan bagaimana ia sepatutnya kelihatan? Saya akan cuba menjawab soalan topik secara terperinci, mempertimbangkan struktur dan tujuan Terma Rujukan, dan memberikan beberapa cadangan mengenai penggubalan keperluan.
• Bahagian kedua " Pembangunan spesifikasi teknikal. Bagaimana untuk merumus keperluan? akan menumpukan sepenuhnya untuk mengenal pasti dan merumus keperluan untuk sistem maklumat.

Mula-mula, anda perlu memikirkan soalan yang sebenarnya menarik minat mereka yang bertanya "Bagaimana untuk membangunkan spesifikasi teknikal?" Hakikatnya ialah pendekatan untuk membangunkan spesifikasi teknikal akan sangat bergantung pada tujuan ia dilakukan, serta oleh siapa ia akan digunakan. Apakah pilihan yang saya bincangkan:

• Sebuah organisasi komersial memutuskan untuk melaksanakan sistem automatik. Ia tidak mempunyai perkhidmatan IT sendiri dan memutuskan untuk melakukan ini: Pihak yang berminat mesti membangunkan Spesifikasi Teknikal dan menyerahkannya untuk pembangunan kepada pihak ketiga;
• Sebuah organisasi komersial memutuskan untuk melaksanakan sistem automatik. Ia mempunyai perkhidmatan IT sendiri. Kami memutuskan untuk melakukan ini: membangunkan Spesifikasi Teknikal, kemudian bersetuju mengenainya antara perkhidmatan IT dan pihak yang berminat, dan melaksanakannya sendiri;
• Agensi kerajaan memutuskan untuk memulakan projek IT. Segala-galanya di sini sangat keruh, banyak formaliti, sogokan, pemotongan, dll. Saya tidak akan mempertimbangkan pilihan ini dalam artikel ini.

• Sebuah syarikat IT menyediakan perkhidmatan untuk pembangunan dan/atau pelaksanaan sistem automatik. Ini adalah kes yang paling sukar, kerana anda perlu bekerja dalam pelbagai keadaan:

  • Pelanggan mempunyai pakar sendiri dengan pandangan mereka sendiri, dan mereka membuat keperluan khusus untuk Spesifikasi Teknikal;
  • Terma rujukan dibangunkan untuk pembangun dalaman (pelanggan tidak peduli);
  • Terma rujukan dibangunkan untuk pemindahan kepada kontraktor (iaitu sekumpulan pengaturcara pada kakitangan syarikat, atau pakar individu);
  • Salah faham timbul antara syarikat dan pelanggan mengenai hasil yang diperoleh, dan syarikat itu berulang kali bertanya soalan: "Bagaimanakah Spesifikasi Teknikal perlu dibangunkan?" Kes terakhir mungkin kelihatan seperti paradoks, tetapi ia adalah benar.
  • Pilihan lain yang kurang biasa juga mungkin;

Saya fikir pembaca kini harus mempunyai soalan:

• Mengapakah Spesifikasi Teknikal tidak boleh sentiasa dibangunkan dengan cara yang sama?;
• Adakah terdapat sebarang piawaian, kaedah, cadangan? Di mana saya boleh mendapatkannya?
• Siapa yang harus membangunkan Terma Rujukan? Sekiranya orang ini mempunyai pengetahuan khusus?
• Bagaimana untuk memahami sama ada Terma Rujukan ditulis dengan baik atau tidak?
• Atas perbelanjaan siapa ia harus dibangunkan, dan adakah ia perlu?

Senarai ini boleh menjadi tidak berkesudahan. Saya mengatakan ini dengan yakin kerana saya telah berada dalam pembangunan perisian profesional selama 15 tahun, dan persoalan Spesifikasi Teknikal muncul dalam mana-mana pasukan pembangunan yang bekerjasama dengan saya. Sebab-sebab ini adalah berbeza. Membangkitkan topik membangunkan Terma Rujukan, saya amat sedar bahawa saya tidak akan dapat membentangkannya 100% kepada semua orang yang berminat dengan topik tersebut. Tetapi, saya akan cuba, seperti yang mereka katakan, "untuk menyelesaikan segala-galanya." Mereka yang sudah biasa dengan artikel saya tahu bahawa saya tidak menggunakan "copy-paste" karya orang lain, tidak mencetak semula buku orang lain, tidak memetik piawaian berbilang halaman dan dokumen lain yang anda sendiri boleh temui di Internet, menganggapnya sebagai pemikiran genius anda sendiri. Hanya taip enjin carian "Bagaimana untuk membangunkan Spesifikasi Teknikal" dan anda boleh membaca banyak perkara yang menarik, tetapi, malangnya, perkara yang berulang. Sebagai peraturan, mereka yang suka menjadi pandai di forum (cuba cari sahaja!) Tidak pernah membuat sendiri Spesifikasi Teknikal yang betul, dan sentiasa memetik cadangan GOST mengenai isu ini. Dan mereka yang benar-benar serius tentang isu ini biasanya tidak mempunyai masa untuk duduk di forum. Dengan cara ini, kita juga akan bercakap tentang piawaian GOST. Selama bertahun-tahun bekerja saya, saya telah melihat banyak versi dokumentasi teknikal yang disusun oleh kedua-dua pakar individu dan pasukan terkemuka dan syarikat perunding. Kadang-kadang saya juga terlibat dalam aktiviti ini: Saya memperuntukkan masa untuk diri sendiri dan mencari maklumat mengenai topik yang diminati daripada sumber luar biasa (seperti sedikit kecerdasan). Akibatnya, saya terpaksa melihat dokumentasi mengenai raksasa seperti GazProm, Keretapi Rusia dan banyak lagi syarikat menarik. Sudah tentu, saya mematuhi dasar kerahsiaan, walaupun pada hakikatnya dokumen-dokumen ini datang kepada saya daripada sumber yang tersedia secara umum atau tidak bertanggungjawab perunding (menyebarkan maklumat di Internet). Oleh itu, saya katakan dengan segera: Saya tidak berkongsi maklumat sulit yang dimiliki oleh syarikat lain, tanpa mengira sumber (etika profesional).

Apakah spesifikasi teknikal?

Perkara pertama yang akan kita lakukan sekarang ialah mengetahui jenis binatang "Spesifikasi Teknikal" ini.

Ya, memang terdapat GOST dan piawaian yang cuba mengawal selia bahagian aktiviti ini (pembangunan perisian). Pada suatu masa dahulu, semua GOST ini adalah relevan dan digunakan secara aktif. Kini terdapat pendapat yang berbeza tentang kaitan dokumen ini. Ada yang berpendapat bahawa GOST telah dibangunkan oleh orang yang sangat berpandangan jauh dan masih relevan. Yang lain berkata mereka sudah ketinggalan zaman. Mungkin seseorang kini berfikir bahawa kebenaran berada di suatu tempat di tengah-tengah. Saya akan menjawab dengan kata-kata Goethe: “Mereka mengatakan bahawa antara dua pendapat yang bertentangan terletak kebenaran. Walau apa pun! Ada masalah antara mereka." Jadi, tidak ada kebenaran antara pendapat ini. Kerana GOST tidak mendedahkan masalah praktikal pembangunan moden, dan mereka yang mengkritik mereka tidak menawarkan alternatif (khusus dan sistemik).

Perhatikan bahawa GOST jelas tidak memberikan definisi, ia hanya mengatakan: "TK untuk loji tenaga nuklear adalah dokumen utama yang menentukan keperluan dan prosedur untuk mencipta (pembangunan atau pemodenan - kemudian penciptaan) sistem automatik, mengikut mana pembangunan loji tenaga nuklear dijalankan dan penerimaannya selepas pentauliahan beraksi."

Jika sesiapa berminat dengan GOST yang saya maksudkan, inilah mereka:

• GOST 2.114-95 Sistem dokumentasi reka bentuk bersatu. Spesifikasi teknikal;
• GOST 19.201-78 Sistem dokumentasi program bersatu. Tugas teknikal. Keperluan untuk kandungan dan reka bentuk;
• GOST 34.602-89 Teknologi maklumat. Set piawaian untuk sistem automatik. Terma rujukan untuk penciptaan sistem automatik.

Definisi yang lebih baik dibentangkan di Wikipedia (walaupun mengenai spesifikasi teknikal secara umum, dan bukan hanya untuk perisian): " Tugas teknikal– ini adalah dokumen reka bentuk asal teknikal objek. Tugas teknikal menetapkan tujuan utama objek yang sedang dibangunkan, ciri teknikal dan taktikal-teknikalnya, penunjuk kualiti dan keperluan teknikal dan ekonomi, arahan untuk melengkapkan peringkat yang diperlukan untuk mencipta dokumentasi (reka bentuk, teknologi, perisian, dll.) dan komposisinya, sebagai serta keperluan khas. Tugas sebagai dokumen awal untuk mencipta sesuatu yang baharu wujud dalam semua bidang aktiviti, berbeza dalam nama, kandungan, susunan pelaksanaan, dll. (contohnya, tugas reka bentuk dalam pembinaan, tugas pertempuran, kerja rumah, kontrak untuk karya sastera, dll.). d.)"

Oleh itu, seperti berikut dari definisi, tujuan utama Spesifikasi Teknikal adalah untuk merumuskan keperluan untuk objek yang dibangunkan, dalam kes kami, untuk sistem automatik.

Ia adalah perkara utama, tetapi satu-satunya. Masanya telah tiba untuk pergi ke perkara utama: untuk meletakkan segala-galanya "di rak", seperti yang dijanjikan.

Apa yang anda perlu tahu tentang keperluan? Adalah perlu untuk memahami dengan jelas bahawa semua keperluan mesti dibahagikan mengikut jenis dan sifat. Sekarang kita akan belajar bagaimana untuk melakukan ini. Untuk memisahkan keperluan mengikut jenis, GOST akan membantu kami. Senarai jenis keperluan yang dibentangkan terdapat contoh yang baik tentang jenis keperluan yang perlu dipertimbangkan. Sebagai contoh:

• Keperluan kefungsian;
• Keperluan keselamatan dan hak akses;
• Keperluan untuk kelayakan kakitangan;
• …. Dan lain-lain. Anda boleh membaca tentang mereka dalam GOST yang disebutkan (dan di bawah saya juga akan melihatnya dengan lebih terperinci).

Saya fikir adalah jelas kepada anda bahawa faktor utama dalam Spesifikasi Teknikal yang berjaya adalah keperluan fungsi yang dirumus dengan tepat. Kebanyakan kerja dan kaedah yang saya bicarakan ditumpukan kepada keperluan ini. Keperluan kefungsian adalah 90% daripada kerumitan kerja untuk membangunkan Terma Rujukan. Segala-galanya selalunya merupakan "penyamaran" yang meliputi keperluan ini. Sekiranya keperluan dirumuskan dengan buruk, maka tidak kira apa penyamaran cantik yang anda letakkan pada mereka, projek yang berjaya tidak akan keluar. Ya, secara rasmi semua keperluan akan dipenuhi (mengikut GOST J), spesifikasi teknikal telah dibangunkan, diluluskan dan ditandatangani, dan wang telah diterima untuknya. Dan apa? Dan kemudian bahagian yang paling menarik bermula: apa yang perlu dilakukan? Jika ini adalah projek dalam Perintah Negeri, maka tidak ada masalah - bajet yang ada sedemikian rupa sehingga ia tidak akan masuk ke dalam poket sesiapa, dan semasa proses pelaksanaan (jika ada) semuanya akan dijelaskan. Beginilah cara majoriti belanjawan projek dibelanjakan untuk Perintah Negeri (mereka menulis "TZ", kerugian berpuluh-puluh juta, tetapi tidak melakukan projek. Semua formaliti diperhatikan, tidak ada pihak yang bersalah, kereta baru berada berhampiran rumah. Kecantikan!). Tetapi kita bercakap tentang organisasi komersial di mana wang dikira, dan keputusan yang berbeza diperlukan. Oleh itu, mari kita fahami perkara utama, bagaimana untuk berkembang berguna dan berfungsi Spesifikasi teknikal.

Saya berkata tentang jenis keperluan, tetapi bagaimana dengan hartanah? Sekiranya jenis keperluan boleh berbeza (bergantung pada matlamat projek), maka dengan sifat semuanya lebih mudah, terdapat 3 daripadanya:

1. Keperluan mestilah boleh difahami;
2. Keperluan mestilah khusus;
3. Keperluan mestilah pengambil ujian;

Selain itu, harta terakhir adalah mustahil tanpa dua yang sebelumnya, i.e. adalah sejenis "ujian litmus". Jika keputusan sesuatu keperluan tidak dapat diuji, ini bermakna ia tidak jelas atau tidak spesifik. Cuba pertimbangkan. Dalam penguasaan ketiga-tiga sifat keperluan ini terletaknya penguasaan dan profesionalisme. Ia sebenarnya sangat mudah. Apabila anda memikirkannya.

Ini menyimpulkan cerita tentang apa itu Spesifikasi Teknikal dan beralih kepada perkara utama: bagaimana untuk merumuskan keperluan. Tetapi ia tidak begitu pantas. Terdapat satu lagi perkara yang sangat penting:

• Dalam bahasa apakah (dari segi kesukaran memahami) spesifikasi teknikal harus ditulis?
• Patutkah ia menerangkan spesifikasi pelbagai fungsi, algoritma, jenis data dan perkara teknikal lain?
• Apakah reka bentuk teknikal, yang, dengan cara itu, juga disebut dalam GOST, dan bagaimana ia berkaitan dengan Spesifikasi Teknikal?

Terdapat perkara yang sangat berbahaya tersembunyi dalam jawapan kepada soalan-soalan ini. Itulah sebabnya pertikaian sering timbul tentang kecukupan atau kekurangan butiran keperluan yang diperlukan, tentang kefahaman dokumen oleh Pelanggan dan Kontraktor, tentang redundansi, format persembahan, dsb. Di manakah garisan antara Terma Rujukan dan Projek Teknikal?

Tugas teknikal– ini adalah dokumen berdasarkan keperluan yang dirumuskan dalam bahasa yang boleh difahami (biasa, biasa) kepada Pelanggan. Dalam kes ini, istilah industri yang boleh difahami oleh Pelanggan boleh dan harus digunakan. Seharusnya tidak ada sambungan dengan spesifik pelaksanaan teknikal. Itu. pada peringkat spesifikasi teknikal, pada dasarnya, tidak kira di platform mana keperluan ini akan dilaksanakan. Walaupun terdapat pengecualian. Jika kita bercakap tentang melaksanakan sistem berdasarkan produk perisian yang sudah sedia ada, maka pautan sedemikian boleh berlaku, tetapi hanya pada tahap borang skrin, borang laporan, dll. Penjelasan dan perumusan keperluan, serta pembangunan Terma Rujukan hendaklah dilaksanakan penganalisa perniagaan. Dan pastinya bukan pengaturcara (melainkan dia menggabungkan peranan ini, ini berlaku). Itu. orang ini mesti bercakap dengan Pelanggan dalam bahasa perniagaannya.

Projek teknikal– ini adalah dokumen yang bertujuan untuk pelaksanaan teknikal keperluan yang dirumuskan dalam Terma Rujukan. Dokumen ini menerangkan struktur data, pencetus dan prosedur tersimpan, algoritma dan perkara lain yang diperlukan pakar teknikal. Pelanggan tidak perlu mendalami perkara ini sama sekali (malah terma sedemikian mungkin tidak jelas kepadanya). Projek teknikal tidak Arkitek Sistem(menggabungkan peranan ini dengan pengaturcara adalah perkara biasa). Atau sebaliknya, sekumpulan pakar JSC yang diketuai oleh seorang arkitek. Lebih besar projek, lebih ramai orang bekerja pada Terma Rujukan.

Apa yang kita ada dalam amalan? Ia lucu untuk menonton apabila pengarah dibentangkan dengan spesifikasi teknikal untuk kelulusan, yang penuh dengan istilah teknikal, penerangan jenis data dan nilainya, struktur pangkalan data, dll. Dia, sudah tentu, cuba memahami, kerana dia perlu meluluskan , cuba mencari perkataan biasa di antara baris dan tidak kehilangan keperluan perniagaan rantaian. Adakah ini situasi biasa? Dan bagaimana ia berakhir? Sebagai peraturan, spesifikasi teknikal sedemikian diluluskan, kemudian dilaksanakan, dan dalam 80% kes, maka mereka sama sekali tidak sesuai dengan fakta kerja yang dilakukan, kerana mereka memutuskan untuk berubah, membuat semula banyak perkara, salah faham, salah sangka, dsb. dan sebagainya. Dan kemudian siri tentang menghantar kerja bermula. "Tetapi di sini bukan apa yang kami perlukan," tetapi "ini tidak akan berfungsi untuk kami," "ini terlalu rumit," "ini menyusahkan," dll. Macam kenal?!! Itu biasa kepada saya, saya terpaksa memukul lebam dalam masa yang ditetapkan.

Jadi apa yang kita ada dalam amalan? Tetapi dalam amalan, kami mempunyai sempadan yang kabur antara Terma Rujukan dan Projek Teknikal. Dia terapung di antara TK dan TP dalam pelbagai manifestasi. Dan itu buruk. Ini berlaku kerana budaya pembangunan telah menjadi lemah. Ini sebahagiannya disebabkan oleh kecekapan pakar, sebahagiannya disebabkan oleh keinginan untuk mengurangkan belanjawan dan tarikh akhir (lagipun, dokumentasi mengambil banyak masa - itu fakta). Terdapat satu lagi faktor penting yang mempengaruhi penggunaan Reka Bentuk Teknikal sebagai dokumen berasingan: pembangunan pesat alat pembangunan pesat, serta metodologi pembangunan. Tetapi ini adalah cerita yang berasingan; Saya akan mengatakan beberapa perkataan mengenainya di bawah.

Satu lagi perkara kecil tetapi penting. Kadangkala Terma Rujukan dipanggil sekeping kecil keperluan, mudah dan boleh difahami. Sebagai contoh, tingkatkan carian untuk objek mengikut beberapa syarat, tambah lajur pada laporan, dll. Pendekatan ini agak wajar, mengapa merumitkan kehidupan. Tetapi ia tidak digunakan pada projek besar, tetapi pada penambahbaikan kecil. Saya akan mengatakan ini lebih dekat dengan penyelenggaraan produk perisian. Dalam kes ini, Terma Rujukan juga boleh menerangkan penyelesaian teknikal khusus untuk melaksanakan keperluan tersebut. Contohnya, "Buat perubahan begini dan begitu kepada algoritma itu dan ini," menunjukkan prosedur khusus dan perubahan khusus untuk pengaturcara. Ini berlaku apabila sempadan antara Terma Rujukan dan Projek Teknikal dipadamkan sepenuhnya, kerana tidak ada kebolehlaksanaan ekonomi untuk mengembang kertas kerja di mana ia tidak diperlukan, tetapi dokumen yang berguna dicipta. Dan memang betul.

Adakah spesifikasi teknikal perlu sama sekali? Bagaimana pula dengan Projek Teknikal?

Adakah saya terlalu panas? Adakah ini mungkin tanpa sebarang Spesifikasi teknikal? Bayangkan ia mungkin (atau lebih tepatnya, mungkin), dan pendekatan ini mempunyai ramai pengikut, dan bilangan mereka semakin meningkat. Sebagai peraturan, selepas pakar muda membaca buku tentang Scrum, Agile dan teknologi pembangunan pesat yang lain. Sebenarnya, ini adalah teknologi yang hebat, dan ia berfungsi, tetapi mereka tidak benar-benar mengatakan "tidak perlu melakukan tugas teknikal." Mereka mengatakan "kertas kerja minimum," terutamanya yang tidak perlu, lebih dekat dengan Pelanggan, lebih spesifik dan hasil yang lebih cepat. Tetapi tiada siapa yang membatalkan rakaman keperluan, dan ini jelas dinyatakan di sana. Di sanalah keperluan ditetapkan berdasarkan tiga sifat luar biasa yang saya nyatakan di atas. Cuma, fikiran sesetengah orang distrukturkan sedemikian rupa sehingga jika sesuatu boleh dipermudahkan, maka marilah kita permudahkan sehingga ketiadaan sepenuhnya. Seperti kata Einstein " Jadikan ia semudah mungkin, tetapi tidak lebih mudah daripada itu." . Ini adalah kata-kata emas yang sesuai dengan segalanya. Jadi Tugas teknikal perlu, jika tidak, anda tidak akan melihat projek yang berjaya. Soalan lain ialah bagaimana untuk mengarangnya dan apa yang perlu disertakan di sana. Berdasarkan metodologi pembangunan pesat, anda hanya perlu memberi tumpuan kepada keperluan, dan semua "penyamaran" boleh dibuang. Pada dasarnya, saya bersetuju dengan ini.

Bagaimana pula dengan Projek Teknikal? Dokumen ini sangat berguna dan tidak kehilangan kaitannya. Lebih-lebih lagi, selalunya anda tidak boleh melakukannya tanpanya. Terutama apabila ia berkaitan dengan kerja pembangunan penyumberan luar, i.e. atas prinsip penyumberan luar. Jika anda tidak melakukan ini, anda berisiko untuk belajar banyak tentang rupa sistem yang anda fikirkan. Sekiranya Pelanggan membiasakan diri dengannya? Jika dia mahu, mengapa tidak, tetapi tidak perlu mendesak dan meluluskan dokumen ini, ia hanya akan menahan dan mengganggu kerja. Hampir mustahil untuk mereka bentuk sistem hingga ke perincian terkecil. Dalam kes ini, anda perlu terus membuat perubahan pada Reka Bentuk Teknikal, yang memerlukan banyak masa. Dan jika organisasi itu sangat birokratik, maka anda akan meninggalkan semua saraf anda di sana. Mengurangkan reka bentuk jenis ini adalah betul-betul metodologi pembangunan pesat moden yang saya nyatakan di atas. By the way, mereka semua berdasarkan XP klasik (pengaturcaraan melampau) - pendekatan yang sudah berusia kira-kira 20 tahun. Jadi buat Spesifikasi Teknikal berkualiti tinggi yang boleh difahami oleh Pelanggan, dan gunakan Reka Bentuk Teknikal sebagai dokumen dalaman untuk hubungan antara arkitek sistem dan pengaturcara.

Perincian yang menarik tentang reka bentuk teknikal: beberapa alat pembangunan yang direka berdasarkan prinsip reka bentuk berorientasikan subjek (seperti 1C dan yang serupa) menganggap bahawa reka bentuk (bermaksud proses dokumentasi) hanya diperlukan dalam kawasan yang benar-benar kompleks di mana interaksi antara keseluruhan subsistem diperlukan. Dalam kes paling mudah, sebagai contoh, mencipta direktori atau dokumen, hanya keperluan perniagaan yang dirumus dengan betul sudah mencukupi. Ini juga dibuktikan dengan strategi perniagaan platform ini dari segi pakar latihan. Jika anda melihat kad peperiksaan pakar (itulah yang dipanggil, bukan "pengaturcara"), anda akan melihat bahawa hanya terdapat keperluan perniagaan, dan cara melaksanakannya dalam bahasa program adalah tugas pakar. Itu. sebahagian daripada masalah yang Projek Teknikal bertujuan untuk menyelesaikan, pakar mesti menyelesaikan "dalam kepalanya" (kita bercakap tentang tugas-tugas kerumitan sederhana), di sini dan sekarang, mengikuti piawaian pembangunan dan reka bentuk tertentu, yang sekali lagi dibentuk oleh syarikat 1C untuk platformnya. Oleh itu, daripada dua pakar yang hasil kerjanya kelihatan sama, seorang boleh lulus peperiksaan, tetapi yang lain tidak boleh, kerana secara terang-terangan melanggar piawaian pembangunan. Iaitu, jelas diandaikan bahawa pakar mesti mempunyai kelayakan sedemikian rupa sehingga mereka boleh mereka bentuk tugas biasa secara bebas, tanpa penglibatan arkitek sistem. Dan pendekatan ini berkesan.

Mari kita teruskan mengkaji soalan: "Apakah keperluan yang perlu disertakan dalam Terma Rujukan?"

Perumusan keperluan untuk sistem maklumat. Struktur Terma Rujukan

Mari kita jelaskan dengan segera: kita akan bercakap secara khusus tentang merumuskan keperluan untuk sistem maklumat, i.e. dengan mengandaikan bahawa kerja membangunkan keperluan perniagaan, memformalkan proses perniagaan dan semua kerja perundingan sebelumnya telah pun selesai. Sudah tentu, beberapa penjelasan boleh dibuat pada peringkat ini, tetapi hanya penjelasan. Projek automasi itu sendiri tidak menyelesaikan masalah perniagaan - ingat ini. Ini adalah aksiom. Atas sebab tertentu, sesetengah pengurus cuba menafikannya, percaya bahawa jika mereka membeli program itu, pesanan akan datang kepada perniagaan yang huru-hara. Tetapi aksiom adalah aksiom kerana ia tidak memerlukan bukti.

Seperti mana-mana aktiviti, keperluan merumus boleh (dan harus) dibahagikan kepada beberapa peringkat. Semuanya ada masanya. Ini adalah kerja intelektual yang sukar. Dan, jika anda merawatnya dengan perhatian yang tidak mencukupi, maka hasilnya akan sesuai. Menurut anggaran pakar, kos membangunkan Terma Rujukan boleh menjadi 30-50%. Saya pun sependapat. Walaupun 50 mungkin terlalu banyak. Lagipun, Spesifikasi Teknikal bukanlah dokumen terakhir yang mesti dibangunkan. Lagipun, mesti ada reka bentuk teknikal. Variasi ini disebabkan oleh platform automasi, pendekatan dan teknologi yang berbeza yang digunakan oleh pasukan projek semasa pembangunan. Sebagai contoh, jika kita bercakap tentang pembangunan dalam bahasa klasik seperti C++, maka reka bentuk teknikal yang terperinci amat diperlukan. Jika kita bercakap tentang melaksanakan sistem pada platform 1C, maka keadaan dengan reka bentuk agak berbeza, seperti yang kita lihat di atas (walaupun, apabila membangunkan sistem dari awal, ia direka mengikut skema klasik).

Walaupun pernyataan keperluan adalah bahagian utama Spesifikasi teknikal, dan dalam beberapa kes ia menjadi satu-satunya bahagian spesifikasi teknikal, anda harus memberi perhatian kepada fakta bahawa ini adalah dokumen penting, dan ia harus disediakan dengan sewajarnya. Di mana untuk bermula? Pertama sekali, anda perlu bermula dengan kandungan. Tulis kandungan dan kemudian mula mengembangkannya. Secara peribadi, saya melakukan ini: mula-mula saya melakar kandungan, menerangkan matlamat, semua maklumat pengenalan, dan kemudian turun ke bahagian utama - perumusan keperluan. Kenapa tidak sebaliknya? Saya tidak tahu, ia lebih mudah untuk saya. Pertama, ini adalah bahagian masa yang lebih kecil (berbanding dengan keperluan), dan kedua, semasa anda menerangkan semua maklumat pengenalan, anda mengikuti perkara utama. Nah, siapa yang suka. Lama kelamaan, anda akan membangunkan templat Spesifikasi Teknikal anda sendiri. Sebagai permulaan, saya cadangkan mengambil sebagai kandungan tepat yang diterangkan dalam GOST. Ia sesuai untuk kandungan! Kemudian kami mengambil dan mula menerangkan setiap bahagian, tidak lupa tentang cadangan tiga sifat berikut: kebolehfahaman, kekhususan dan kebolehujian. Mengapa saya bertegas dengan perkara ini? Lebih lanjut mengenai perkara ini dalam bahagian seterusnya. Dan sekarang saya bercadang untuk melalui titik-titik spesifikasi teknikal yang disyorkan dalam GOST.

1. maklumat am;
2. tujuan dan matlamat penciptaan (pembangunan) sistem;
3. ciri-ciri objek automasi;
4. Keperluan Sistem;
5. komposisi dan kandungan kerja untuk mencipta sistem;
6. prosedur untuk kawalan dan penerimaan sistem;
7. keperluan untuk komposisi dan kandungan kerja untuk menyediakan objek automasi untuk meletakkan sistem beroperasi;
8. keperluan dokumentasi;
9. sumber pembangunan.

Secara keseluruhan, 9 bahagian, setiap satunya juga dibahagikan kepada subseksyen. Mari kita lihat mereka dalam susunan. Untuk kemudahan, saya akan membentangkan semuanya dalam bentuk jadual untuk setiap item.

Bahagian 1. maklumat am.

Cadangan mengikut GOST
nama penuh sistem dan simbolnya;	Segala-galanya jelas di sini: kami menulis apa yang akan dipanggil sistem, nama ringkasnya
kod subjek atau kod (nombor) kontrak;	Ini tidak berkaitan, tetapi anda boleh menentukannya jika perlu
nama perusahaan (persatuan) pembangun dan pelanggan (pengguna) sistem dan butirannya;	nyatakan siapa (organisasi mana) akan mengusahakan projek tersebut. Anda juga boleh menentukan peranan mereka. Anda juga boleh mengalih keluar bahagian ini (agak formal).
senarai dokumen berdasarkan sistem yang dicipta, oleh siapa dan bila dokumen ini diluluskan;	Maklumat berguna. Di sini anda harus menunjukkan dokumentasi kawal selia dan rujukan yang diberikan kepada anda untuk membiasakan diri dengan bahagian tertentu keperluan
tarikh mula dan tamat yang dirancang untuk kerja mencipta sistem;	Permintaan untuk masa. Kadang-kadang mereka menulis tentang ini dalam spesifikasi teknikal, tetapi lebih kerap perkara sedemikian diterangkan dalam kontrak kerja
maklumat mengenai sumber dan prosedur untuk membiayai kerja;	Sama seperti dalam perenggan sebelumnya tentang tarikh akhir. Lebih relevan untuk pesanan kerajaan (untuk kakitangan kerajaan)
prosedur untuk pendaftaran dan pembentangan kepada pelanggan hasil kerja untuk mencipta sistem (bahagiannya), mengenai pengeluaran dan pelarasan cara individu (perkakasan, perisian, maklumat) dan perisian dan perkakasan (perisian dan metodologi) kompleks sistem.	Saya tidak nampak keperluan untuk perkara ini, kerana... Keperluan dokumentasi ditetapkan secara berasingan, dan di samping itu terdapat keseluruhan bahagian berasingan "Prosedur untuk kawalan dan penerimaan" sistem.

Bahagian 2. tujuan dan matlamat penciptaan (pembangunan) sistem.

Cadangan mengikut GOST	Apa yang perlu dilakukan dalam amalan
Tujuan sistem	Di satu pihak, tujuannya mudah. Tetapi dinasihatkan untuk merumuskannya secara khusus. Jika anda menulis sesuatu seperti "automasi perakaunan gudang berkualiti tinggi di syarikat X", maka anda boleh membincangkan hasilnya untuk masa yang lama selepas ia selesai, walaupun tanpa mengira perumusan keperluan yang baik. Kerana Pelanggan sentiasa boleh mengatakan bahawa dengan kualiti dia bermaksud sesuatu yang lain. Secara umum, anda boleh merosakkan saraf satu sama lain, tetapi mengapa? Adalah lebih baik untuk segera menulis sesuatu seperti ini: "Sistem ini direka untuk mengekalkan rekod gudang dalam syarikat X mengikut keperluan yang dinyatakan dalam Spesifikasi Teknikal ini."
Matlamat mencipta sistem	Matlamat pastinya bahagian penting. Jika kita ingin memasukkannya, maka kita mesti dapat merumuskan matlamat ini. Jika anda mengalami kesukaran merumuskan matlamat, maka lebih baik untuk mengecualikan bahagian ini sama sekali. Contoh matlamat yang tidak berjaya: "Pastikan pengurus melengkapkan dokumen dengan cepat." Apa yang cepat? Ini kemudiannya boleh dibuktikan tanpa henti. Jika ini penting, maka adalah lebih baik untuk merumuskan semula matlamat ini seperti berikut: "Pengurus jualan sepatutnya dapat mengeluarkan dokumen "Jualan barang" sebanyak 100 baris dalam masa 10 minit. Matlamat seperti ini mungkin muncul jika, sebagai contoh, seorang pengurus sedang meluangkan masa kira-kira sejam untuk perkara ini, yang terlalu banyak untuk syarikat itu dan ia penting bagi mereka. Dalam rumusan ini, matlamat sudah bersilang dengan keperluan, yang agak semula jadi, kerana apabila mengembangkan pokok matlamat (iaitu, membahagikannya kepada matlamat berkaitan yang lebih kecil), kita sudah akan semakin hampir dengan keperluan. Oleh itu, anda tidak sepatutnya terbawa-bawa.

Secara umum, keupayaan untuk mengenal pasti matlamat, merumuskannya, dan membina pokok matlamat adalah topik yang berasingan sepenuhnya. Ingat perkara utama: jika anda tahu bagaimana, tulis, jika anda tidak pasti, jangan menulis sama sekali. Apa yang berlaku jika anda tidak merumuskan matlamat? Anda akan bekerja mengikut keperluan, ini sering diamalkan.

Bahagian 3. Ciri-ciri objek automasi.

Bahagian 4. Keperluan Sistem

GOST menguraikan senarai keperluan tersebut:

• keperluan untuk struktur dan fungsi sistem;
• keperluan untuk bilangan dan kelayakan kakitangan sistem dan cara operasi mereka;
• penunjuk destinasi;
• keperluan kebolehpercayaan;
• keperluan keselamatan;
• keperluan untuk ergonomik dan estetika teknikal;
• keperluan kebolehangkutan untuk pembesar suara mudah alih;
• keperluan untuk operasi, penyelenggaraan, pembaikan dan penyimpanan komponen sistem;
• keperluan untuk melindungi maklumat daripada capaian yang tidak dibenarkan;
• keperluan untuk keselamatan maklumat sekiranya berlaku kemalangan;
• keperluan untuk perlindungan daripada pengaruh luar;
• keperluan untuk ketulenan paten;
• keperluan untuk penyeragaman dan penyatuan;

Walaupun fakta bahawa bahagian utama pastinya akan menjadi bahagian dengan keperluan khusus (berfungsi), bahagian ini juga boleh menjadi sangat penting (dan dalam kebanyakan kes ia adalah). Perkara yang mungkin penting dan berguna:

• Syarat Kelayakan. Ada kemungkinan sistem yang dibangunkan memerlukan latihan semula pakar. Ini boleh menjadi pengguna sistem masa depan dan pakar IT yang diperlukan untuk menyokongnya. Perhatian yang tidak mencukupi kepada isu ini sering berkembang menjadi masalah. Sekiranya kelayakan kakitangan sedia ada jelas tidak mencukupi, adalah lebih baik untuk menentukan keperluan untuk organisasi latihan, program latihan, masa, dll.
• Keperluan untuk melindungi maklumat daripada capaian yang tidak dibenarkan. Tiada ulasan di sini. Ini adalah tepat keperluan untuk mengehadkan akses kepada data. Sekiranya keperluan sedemikian dirancang, maka ia perlu ditulis secara berasingan, sedetail mungkin, mengikut peraturan yang sama seperti keperluan fungsian (kefahaman, kekhususan, kebolehujian). Oleh itu, keperluan ini boleh dimasukkan ke dalam bahagian dengan keperluan fungsian
• Keperluan untuk penyeragaman. Jika terdapat sebarang piawaian reka bentuk yang boleh digunakan untuk projek, ia boleh dimasukkan dalam keperluan. Sebagai peraturan, keperluan sedemikian dimulakan oleh perkhidmatan IT Pelanggan. Sebagai contoh, syarikat 1C mempunyai keperluan untuk reka bentuk kod program, reka bentuk antara muka, dsb.;
• Keperluan untuk struktur dan fungsi sistem. Di sini keperluan untuk menyepadukan sistem antara satu sama lain boleh diterangkan, dan penerangan tentang seni bina umum dibentangkan. Lebih kerap, keperluan penyepaduan secara amnya dipisahkan kepada bahagian yang berasingan atau malah Spesifikasi Teknikal yang berasingan, kerana keperluan ini boleh menjadi agak rumit.

Semua keperluan lain adalah kurang penting dan tidak perlu diterangkan. Pada pendapat saya, mereka hanya membuat dokumentasi lebih berat dan mempunyai sedikit manfaat praktikal. Dan sangat sukar untuk menerangkan keperluan ergonomik dalam bentuk keperluan umum, lebih baik untuk memindahkannya kepada yang berfungsi. Sebagai contoh, keperluan "Dapatkan maklumat tentang harga produk dengan menekan satu butang sahaja" mungkin dirumuskan. Pada pendapat saya, ini masih lebih dekat dengan keperluan fungsi tertentu, walaupun ia berkaitan dengan ergonomik.Keperluan untuk fungsi (tugas) yang dilakukan oleh sistem Ini adalah perkara utama dan utama yang akan menentukan kejayaan. Walaupun segala-galanya dilakukan dengan sempurna, dan bahagian ini adalah "3", maka hasil projek akan menjadi yang terbaik "3", atau projek itu akan gagal sama sekali. Inilah yang akan kita bincangkan dengan lebih terperinci dalam artikel kedua, yang akan disertakan dalam surat berita keluaran ke-5. Setakat ini, "peraturan tiga sifat keperluan" yang saya bicarakan terpakai. Keperluan untuk jenis cagaran

GOST mengenal pasti jenis berikut:

• Matematik
• Bermaklumat
• Linguistik
• Perisian
• Teknikal
• Metrologi
• berorganisasi
• berkaedah
• dan lain lain…

Pada pandangan pertama, keperluan ini mungkin kelihatan tidak penting. Dalam kebanyakan projek ini adalah benar. Tetapi tidak selalu. Bila hendak menerangkan keperluan ini:

• Tiada keputusan telah dibuat mengenai pembangunan bahasa (atau platform) yang akan dijalankan;
• Sistem ini memerlukan antara muka berbilang bahasa (contohnya, Rusia/Inggeris)
• Untuk sistem berfungsi, unit berasingan mesti diwujudkan atau pekerja baharu mesti diambil;
• Untuk sistem berfungsi, Pelanggan mesti menjalani perubahan dalam kaedah kerja dan perubahan ini mesti dinyatakan dan dirancang;
• Penyepaduan dengan mana-mana peralatan dijangka dan keperluan dikenakan ke atasnya (contohnya, pensijilan, keserasian, dsb.)
• Situasi lain mungkin, semuanya bergantung pada matlamat khusus projek.

Bahagian 5. Komposisi dan kandungan kerja untuk mencipta sistem

Seksyen 6. Prosedur untuk kawalan dan penerimaan sistem

Keperluan am untuk penerimaan kerja secara berperingkat (senarai perusahaan dan organisasi yang mengambil bahagian, tempat dan masa), prosedur untuk penyelarasan dan kelulusan dokumentasi penerimaan; Saya amat mengesyorkan agar anda bertanggungjawab terhadap prosedur untuk menyerahkan kerja dan menyemak sistem. Inilah sebabnya mengapa keperluan yang boleh diuji diperlukan. Tetapi kehadiran keperluan yang boleh diuji mungkin tidak mencukupi apabila sistem dihantar jika prosedur untuk penerimaan dan pemindahan kerja tidak dinyatakan dengan jelas. Sebagai contoh, perangkap biasa: sistem dibina dan beroperasi sepenuhnya, tetapi Pelanggan atas sebab tertentu tidak bersedia untuk bekerja di dalamnya. Sebab ini boleh jadi apa-apa: tiada masa, matlamat telah berubah, seseorang berhenti, dsb. Dan dia berkata: "Memandangkan kami belum bekerja dalam sistem baharu, ini bermakna kami tidak dapat memastikan ia berfungsi." Jadi belajar mengenal pasti peringkat kerja dengan betul, dan cara menyemak keputusan peringkat ini. Selain itu, kaedah sedemikian mestilah jelas kepada Pelanggan dari awal lagi. Jika ia ditetapkan pada tahap Spesifikasi Teknikal, maka anda sentiasa boleh beralih kepada mereka jika perlu dan menyelesaikan kerja dengan pemindahan.

Seksyen 7. Keperluan untuk komposisi dan kandungan kerja untuk menyediakan objek automasi untuk pentauliahan sistem

Mungkin terdapat sebarang peraturan lain untuk memasukkan maklumat yang diterima pakai oleh syarikat (atau dirancang). Sebagai contoh, maklumat tentang kontrak pernah dimasukkan sebagai rentetan teks dalam sebarang bentuk, tetapi kini nombor berasingan, tarikh berasingan, dsb. diperlukan. Terdapat banyak syarat sedemikian. Sesetengah daripada mereka mungkin dilihat dengan rintangan daripada kakitangan, jadi adalah lebih baik untuk mendaftarkan semua kes sedemikian pada tahap keperluan untuk susunan kemasukan data. Perubahan yang perlu dibuat dalam objek automasi

Penciptaan syarat untuk berfungsi objek automasi, di mana pematuhan sistem yang dicipta dengan keperluan yang terkandung dalam spesifikasi teknikal dijamin. Sebarang perubahan yang mungkin diperlukan. Sebagai contoh, syarikat itu tidak mempunyai rangkaian tempatan, kumpulan komputer yang sudah lapuk di mana sistem tidak akan berfungsi.

Mungkin beberapa maklumat yang diperlukan telah diproses di atas kertas, dan kini ia perlu dimasukkan ke dalam sistem. Jika anda tidak melakukan ini, maka beberapa modul tidak akan berfungsi, dsb.

Mungkin sesuatu telah dipermudahkan, tetapi kini perlu diambil kira dengan lebih terperinci, jadi seseorang mesti mengumpul maklumat mengikut peraturan tertentu.

Senarai ini boleh panjang, lihat kes khusus projek anda. Penciptaan jabatan dan perkhidmatan yang diperlukan untuk berfungsi sistem;

Masa dan prosedur untuk kakitangan dan latihan Kami telah pun membincangkan perkara ini sebelum ini. Mungkin sistem sedang dibangunkan untuk struktur atau jenis aktiviti baharu yang tidak wujud sebelum ini. Sekiranya tiada kakitangan yang sesuai, malah mereka yang terlatih, sistem itu tidak akan berfungsi, tidak kira betapa cekapnya ia dibina.

Seksyen 8. Keperluan Dokumentasi

Pertimbangkan cara manual pengguna akan dibentangkan.

Mungkin Pelanggan telah menerima piawaian korporat, yang bermaksud kita perlu merujuk kepada mereka.

Mengabaikan keperluan dokumentasi selalunya membawa kepada akibat yang paling tidak dijangka pada projek. Sebagai contoh, semuanya telah selesai dan semuanya berfungsi. Pengguna juga tahu cara bekerja. Tiada perjanjian atau perbualan sama sekali tentang dokumentasi. Dan tiba-tiba, apabila menyerahkan kerja, salah seorang pengurus tertinggi Pelanggan, yang tidak mengambil bahagian dalam projek itu, tetapi terlibat dalam menerima kerja, bertanya kepada anda: "Di manakah manual pengguna?" Dan ia mula meyakinkan anda bahawa tidak perlu bersetuju dengan ketersediaan manual pengguna, ini sepatutnya "tentu saja" tersirat. Dan itu sahaja, dia tidak mahu mengambil kerja anda. Atas perbelanjaan siapa anda akan membangunkan garis panduan? Banyak pasukan telah jatuh untuk mata kail ini.

Bahagian 9. Sumber Pembangunan

Oleh itu, adalah lebih baik merujuk kepada laporan tinjauan dan keperluan orang penting sahaja.

Oleh itu, kami telah mempertimbangkan semua bahagian yang boleh disertakan dalam Terma Rujukan. “Boleh” dan bukan “Mesti” dengan tepat kerana sebarang dokumen mesti dibangunkan untuk mencapai keputusan. Oleh itu, jika jelas kepada anda bahawa bahagian tertentu tidak akan membawa anda lebih dekat dengan hasilnya, maka anda tidak memerlukannya dan anda tidak perlu membuang masa di atasnya.

Tetapi tiada spesifikasi teknikal yang kompeten boleh dilakukan tanpa perkara utama: keperluan fungsian. Saya ingin ambil perhatian bahawa dalam amalan Spesifikasi Teknikal sedemikian berlaku, dan bagaimana! Terdapat orang yang akan dapat memisahkan perairan di semua bahagian, menerangkan keperluan umum secara umum, dan dokumen itu ternyata sangat berat, dan terdapat banyak perkataan bijak di dalamnya, malah Pelanggan mungkin suka ia (iaitu, dia akan meluluskannya). Tetapi ia mungkin tidak berfungsi mengikutnya, i.e. Ia mempunyai sedikit kegunaan praktikal. Dalam kebanyakan kes, dokumen sedemikian dilahirkan apabila anda perlu mendapatkan banyak wang khusus untuk Terma Rujukan, tetapi ia perlu dilakukan dengan cepat dan tanpa menyelami butiran. Dan terutamanya jika diketahui bahawa perkara itu tidak akan pergi lebih jauh, atau orang yang sama sekali berbeza akan melakukannya. Secara amnya, sekadar mengurus bajet terutamanya belanjawan negeri.

Dalam artikel kedua, kami hanya akan bercakap mengenai bahagian 4 "Keperluan sistem", dan secara khusus kami akan merumuskan keperluan atas sebab kejelasan, kekhususan dan kebolehujian.

Mengapa keperluan mesti jelas, khusus dan boleh diuji.

Kerana amalan menunjukkan: pada mulanya, kebanyakan spesifikasi teknikal yang dibangunkan oleh pakar sama ada ternyata tidak dalam permintaan (tidak sesuai dengan realiti), atau menjadi masalah bagi orang yang mesti melaksanakannya, kerana Pelanggan mula memanipulasi syarat dan keperluan yang tidak jelas. Saya akan memberikan beberapa contoh tentang frasa yang ditemui, apa yang menyebabkannya, dan kemudian saya akan cuba memberikan cadangan tentang cara mengelakkan masalah tersebut.

Adakah keperluan ini boleh diuji? Ia kelihatan seperti perkara yang mudah, tetapi bagaimana anda boleh menyemaknya jika tidak ada yang spesifik?

Bagaimana ini boleh dirumuskan semula: "Jumlah kos yang dinyatakan dalam dokumen mesti diagihkan kepada semua barang yang dinyatakan dalam dokumen ini mengikut perkadaran dengan kos barangan ini." Ternyata jelas dan spesifik. Cara menyemak juga tidak sukar.

Ergonomik Program ini mesti mempunyai antara muka yang mesra pengguna. Saya harus mengakui, saya pernah terpaksa melanggan formula ini sendiri - terdapat banyak masalah kemudian. Sudah tentu, formulasi sedemikian tidak sepatutnya wujud. Tiada butiran khusus di sini, mahupun peluang untuk mengesahkan keperluan ini. Walaupun, sudah tentu, ia boleh difahami (subjektif). Tiada cara untuk merumuskannya semula; setiap elemen "kemudahan" mesti diterangkan secara terperinci, memandangkan Pelanggan berkeras mengenainya. Sebagai contoh:

• Garis hendaklah ditambah pada dokumen kedua-duanya dengan mengklik pada butang "Tambah" dan dengan menekan kekunci "masukkan", serta oleh pengguna yang memasukkan sebahagian daripada nama;
• Apabila melihat senarai produk, anda boleh mencari mengikut nama, kod bar dan artikel;
• Dan lain-lain.

Pembezaan hak aksesAkses kepada data keuntungan seharusnya hanya tersedia kepada pengarah kewangan. Adakah itu jelas? Hampir. Benar, keuntungan berbeza-beza, kita perlu jelaskan. Sudah tentu tidak. Bagaimanakah ini kelihatan seperti dalam pelaksanaan? Jika kita bercakap tentang keuntungan kasar, maka perlu untuk mengehadkan akses kepada data mengenai kos pembelian, kerana jika tidak, keuntungan kasar tidak akan sukar untuk dikira, kerana data mengenai kos jualan diketahui oleh pelbagai orang. Perkara yang berkaitan dengan hak akses mesti ditangani dengan sangat berhati-hati. Dan jika motivasi pengurus jualan adalah berdasarkan keuntungan kasar, maka keperluan ini juga bercanggah antara satu sama lain, kerana pengurus tidak akan dapat mengesahkan perkara ini. Jika kami ingin memasukkan keperluan sedemikian, maka kami perlu menentukan laporan dan objek sistem tertentu yang menunjukkan bahagian data yang sepatutnya tersedia untuk kategori orang tertentu. Dan pertimbangkan setiap kes sedemikian secara individu. Produktiviti Laporan jualan harus dijana dalam masa 1 minit. Ya, saya faham. Malah terdapat had masa tertentu: 1 minit. Tetapi tidak diketahui jenis perincian yang dijangkakan: untuk setiap produk, kumpulan produk, pelanggan atau sesuatu yang lain? Ia boleh dirumuskan seperti ini: "Laporan jualan oleh pelanggan dengan butiran untuk setiap item produk (lihat sampel) harus tidak dipaparkan lebih daripada 1 minit, dengan syarat bilangan produk dalam sampel tidak melebihi 5000 baris.”

Saya harap idea itu jelas. Jika anda mempunyai soalan khusus, tulis, saya akan cuba membantu.

Kepada Terma rujukan terdapat lebih spesifik, terdapat banyak cadangan. Malah terdapat senarai perkataan yang tidak disyorkan untuk digunakan dalam Spesifikasi Teknikal. K. Wiegers menulis dengan menarik tentang perkara ini dalam bukunya "Pembangunan Keperluan Perisian." Saya akan memberikan yang paling menarik dan mudah, pada pendapat saya, cadangan:

• Anda tidak boleh menggunakan perkataan yang mempunyai banyak sinonim. Jika ini perlu, adalah lebih baik untuk memberikan definisi istilah yang jelas dalam bahagian "Terma dan Takrifan" Terma Rujukan.
• Anda harus cuba untuk tidak menggunakan ayat yang panjang;
• Jika keperluan kelihatan terlalu umum kepada anda, ia perlu diperincikan kepada keperluan yang lebih kecil tetapi khusus;
• Gunakan lebih banyak gambar rajah, graf, jadual, lukisan - dengan cara ini maklumat dilihat lebih mudah;
• Perkataan yang perlu dielakkan ialah: “berkesan”, “mencukupi”, “mudah”, “jelas”, “cepat”, “fleksibel”, “diperbaiki”, “optimum”, “telus”, “mampan”, “mencukupi”, “ mesra", "mudah", dsb. Senarai boleh diteruskan, tetapi saya rasa idea itu jelas (cuba teruskan sendiri).

Semua yang ditulis di atas adalah maklumat penting, tetapi bukan yang paling penting. Seperti yang anda ingat, pada permulaan artikel saya memanggil ini istilah "penyamaran", kerana. perkara paling penting yang akan membentuk sekurang-kurangnya 90% daripada masa dan kerumitan kerja pada dokumen ialah mengenal pasti dan merumuskan keperluan. Dan anda masih perlu dapat mengumpul, menstruktur dan merumuskan maklumat tentang keperluan. Ini, dengan cara ini, mempunyai banyak persamaan antara tinjauan aktiviti perusahaan dan penerangan seterusnya mengenai proses perniagaan. Tetapi terdapat juga perbezaan penting. Salah satu perbezaan utama ini ialah kehadiran peringkat membina prototaip sistem masa hadapan, atau kerana ia juga dipanggil "model sistem maklumat".

Dalam artikel seterusnya kita hanya akan bercakap tentang kaedah untuk mengenal pasti keperluan, dan juga mempertimbangkan perkara biasa antara kerja mengumpul keperluan untuk sistem maklumat dan mengumpul maklumat untuk menerangkan proses perniagaan.

Jenis kerja apabila mengumpul keperluan untuk sistem perakaunan dan maklumat untuk menerangkan proses perniagaan. Bahagian 2

Dalam bahagian ini kita akan bercakap tentang cara mengatur peringkat pengumpulan keperluan, apa yang harus terdiri daripada dan alat apa yang boleh digunakan. Saya ulangi bahawa dari sudut pandangan peringkat, kerja ini sangat serupa dengan tinjauan perusahaan untuk menerangkan proses perniagaan.

Seperti yang biasa berlaku dalam kehidupan:

Ini adalah bagaimana ia berlaku dalam kebanyakan projek.
	Bagaimana ini berlaku
	Sudah jelas bahawa ada sebab untuk kegembiraan, terutamanya jika projek itu besar, tidak ada yang salah dengan itu! Perkara utama adalah untuk tidak bergembira terlalu lama, menangguhkan permulaan kerja sebenar, mulai sekarang masa akan bergerak secara berbeza.
	Biasanya proses ini terhad kepada beberapa mesyuarat dengan pihak pengurusan, kemudian dengan ketua jabatan. Setelah merekodkan "desakan" tertentu di pihak Pelanggan, ia direkodkan dalam bentuk rumusan umum. Kadangkala dokumentasi sedia ada ditambah kepada ini (seseorang pernah cuba menjalankan tinjauan, dokumen mengikut peraturan sedia ada, bentuk laporan yang digunakan). Anehnya, selepas ini, majoriti pelaksana sistem automasi dengan gembira berseru: "ya, sistem kami mempunyai semua ini. ! Baiklah, ubah suai sedikit dan semuanya akan berfungsi.” Apabila ditanya sama ada hendak membincangkan cara perkara harus berfungsi (atau cara proses tertentu dilakukan) dengan pengguna akhir, jawapannya biasanya tidak. Pendapat dinyatakan bahawa pemimpin mengetahui segala-galanya untuk orang bawahannya. Tetapi sia-sia... Di sebalik ini terdapat banyak perangkap dan halangan, dan menghantar kerja boleh bertukar menjadi maraton di sepanjang laluan berhalangan. Seperti yang anda ketahui, adalah kebiasaan untuk berlari maraton di jalan yang rata, dan berlari dengan halangan hanya boleh dilakukan dalam jarak yang dekat (anda mungkin tidak selesai).
Mendokumentasikan hasil kerja	Selepas ini, dokumentasi keputusan bermula, bergantung pada matlamat kerja: Jika perlu untuk membangunkan Spesifikasi Teknikal, perunding mula meletakkan maklumat yang diterima ke dalam templat dokumen yang disediakan supaya ia kelihatan cantik dan keperluan utama adalah direkodkan (yang disuarakan oleh pihak pengurusan, jika tidak, mereka mungkin tidak meluluskan). Memahami bahawa dalam amalan Terma Rujukan sedemikian tidak digunakan secara khusus dan segala-galanya perlu difikirkan "sepanjang perjalanan", beliau menetapkan matlamat utama Terma Rujukan sebagai masa minimum untuk penyelarasan dan kelulusan. Dan, jika boleh, maklumat untuk anggaran kasar kos kerja masa depan (dengan cara itu, juga penting). Jika anda perlu menerangkan proses perniagaan. Cukup aneh, tetapi selalunya semua tindakan sebelumnya kelihatan serupa, seperti halnya dengan pembangunan Spesifikasi Teknikal. Satu-satunya perbezaan adalah dalam dokumentasi. Terdapat pilihan di sini: perunding menerangkan proses dalam perkataan sewenang-wenangnya atau menggunakan sebarang peraturan untuk menerangkan proses perniagaan (notasi). Dalam kes pertama, dokumen sedemikian ternyata serupa dengan Spesifikasi Teknikal. Malah berlaku bahawa jika anda menggantikan halaman tajuk, anda tidak akan melihat apa-apa perbezaan. Dalam kes kedua, penekanan sering diberikan bukan pada pematuhan dengan realiti, tetapi pada "ketepatan penerangan," i.e. pematuhan rasmi kepada peraturan penerangan. Malangnya, kedua-dua pilihan bukanlah amalan terbaik, kerana lebih bersifat formal dan tidak membawa banyak faedah.

Mengapakah amalan itu berkembang seperti yang diterangkan di atas? Terus terang, saya tidak tahu. Tanya sesiapa, tiada siapa yang tahu. Pada masa yang sama, keadaan tidak berubah dengan cepat, walaupun orang sentiasa membincangkan topik ini, bertukar pengalaman, menulis buku. Ia juga mungkin disebabkan oleh fakta bahawa ramai pakar datang dari perniagaan lain dan mempelajari segala-galanya dalam amalan, i.e. pengalaman mereka terbentuk dalam persekitaran di mana mereka mendapati diri mereka. Sikap universiti dan ketiadaan keinginan mereka untuk mendekati realiti juga adalah fakta yang diketahui, tetapi kadang-kadang saya terkejut dengan kedudukan mereka. Sebagai contoh, saya mempunyai kes apabila seorang pelajar siswazah, seorang pakar berbakat, ingin menulis tesis pada platform 1C (pembangunan industri yang baik), tetapi jabatan itu memberitahunya bahawa tanpa mengira topik, dia tidak boleh bergantung pada " cemerlang” gred, kerana 1C bukan sistem yang serius. Perkara di sini bukanlah kesungguhan dan objektiviti pendapat ini, tetapi hakikat bahawa tugas primitif dalam bahasa pengaturcaraan klasik segera dianggap layak untuk penarafan "cemerlang".

Mari cuba berikan proses yang dibincangkan di atas pendekatan yang lebih sistematik. Apakah rupa dia kemudian?

Seperti yang anda lihat, proses itu berakhir dengan soalan, kerana Pada ketika ini, kerja masih jauh dari selesai, dan kemudian perkara yang paling sukar dan paling praktikal akan bermula - apa yang akan menentukan kebolehgunaan hasil yang diperoleh dalam kehidupan sebenar. Inilah yang akan menentukan nasib kerja sebelumnya: sama ada ia akan pergi ke almari (di rak atau di tempat lain), atau ia akan mewakili sumber maklumat yang berharga. Dan lebih baik jika ia menjadi model untuk projek seterusnya.

Saya ingin ambil perhatian terutamanya bahawa sehingga langkah terakhir dalam rajah (di mana persoalannya), prinsip umum mengumpul maklumat mengenai aktiviti syarikat kelihatan sama, tidak kira apa yang anda merancang untuk lakukan pada masa hadapan, menerangkan proses perniagaan atau melaksanakan sistem automatik. Ya, urutan langkah itu sendiri adalah sama, tetapi alat yang digunakan dalam sesetengahnya mungkin berbeza. Kami pasti akan mempertimbangkan perkara ini apabila kami mengkaji kaedah dan alat peringkat individu. Kami akan melakukan ini secara terperinci dalam artikel berasingan, tetapi sekarang kami hanya akan mempertimbangkan perkara yang paling penting. Langkah selanjutnya akan berbeza dan akan ditentukan oleh perkara yang diperlukan daripada projek: menerangkan proses perniagaan atau melaksanakan sistem perakaunan.

Mari kita lihat bagaimana kita boleh menyusun semula pendekatan untuk mengumpul maklumat tentang aktiviti syarikat.

Bagaimana ini boleh berlaku dengan organisasi kerja yang lebih cekap
	Bagaimana ini berlaku
Keputusan telah dibuat, projek akan dilancarkan!	Tiada apa-apa yang berubah di sini berbanding dengan pilihan pertama, emosi tidak dibatalkan
Kami mengadakan pertemuan dengan pengurus dan mengumpul beberapa maklumat tentang visi mereka tentang keputusan.	Langkah ini juga kekal, dan ia amat penting. Tetapi tujuan utama pertemuan pertama (atau beberapa mesyuarat) dengan pengurus dan pemilik adalah untuk mengenali satu sama lain. Mengenali orang dan syarikat terlebih dahulu. Matlamat dan hasrat yang dirumuskan pada mesyuarat agung sedemikian boleh menjadi sangat berbeza, termasuk hebat. Kesemua mereka, sudah tentu, akan didengari, tetapi ia bukan fakta bahawa ia akan dilaksanakan. Dengan menyelami lebih mendalam dalam perniagaan syarikat, matlamat lain akan muncul dan matlamat sebelumnya akan ditolak. Apa yang saya maksudkan ialah mustahil untuk merumuskan matlamat yang jelas dari mesyuarat awal; semua ini memerlukan kajian yang teliti. Pada mesyuarat sedemikian, adalah perlu untuk mencatat semua mesej daripada pemilik dan pegawai atasan, supaya kemudian anda boleh kembali kepada mereka dan membincangkannya apabila jumlah maklumat yang mencukupi telah dikumpulkan. Malah keperluan yang kelihatan mudah mungkin menjadi mustahil untuk dilaksanakan atau sangat intensif buruh.
Pembentukan kumpulan kerja daripada Pelanggan dan Kontraktor, pengagihan peranan	Adalah perlu untuk memutuskan siapa yang akan bekerja pada projek itu, baik di pihak Pelanggan dan di pihak Kontraktor. Walaupun kesederhanaan jelas tahap ini, ia mempunyai peranan yang sangat penting. Jika anda tidak merekodkan dengan jelas siapa yang bertanggungjawab untuk apa, anda berisiko menghadapi kekeliruan semasa pelaksanaan kerja. Jika, bagi pihak anda, anda sentiasa boleh menentukan peranan dalam pasukan anda, maka Pelanggan mungkin menghadapi masalah dengan perkara ini. Perkara yang perlu anda perhatikan: Kumpulan kerja Pelanggan mesti termasuk mereka yang pada masa hadapan sekurang-kurangnya akan mempengaruhi penerimaan keputusan. Jika kita menganggap situasi bahawa apabila kerja diserahkan, pekerja Pelanggan yang tidak mengambil bahagian dalam kerja untuk merumuskan matlamat dan mengenal pasti keperluan akan terlibat, maka masalah dijamin. Malah situasi yang tidak masuk akal seperti itu adalah mungkin bahawa segala-galanya ternyata tidak dilakukan seperti yang diperlukan. Dalam amalan saya, saya telah menghadapi situasi sedemikian lebih daripada sekali. Oleh itu, anda boleh melindungi diri anda jika anda menetapkan dan mendokumenkan bahawa tiada siapa kecuali pelanggan bekerja kumpulan boleh mengambil bahagian dalam penerimaan dan penyampaian kerja. Dan yang terbaik adalah menulis ini dalam syarat kontrak (dalam kontrak atau piagam projek). Saya masih ingat ada kes sedemikian: dalam satu projek besar, pengasas memutuskan untuk menyertai proses (saya tidak tahu mengapa, ia kelihatan membosankan) dan menghadiri salah satu mesyuarat kerja di mana isu penjanaan invois untuk pelanggan dibincangkan. Dia terkejut apabila mengetahui bahawa pengurus jualan mengeluarkan invois kepada pelanggan. Dalam fikirannya, akauntan harus mengeluarkan invois, dan tidak ada yang lain. Tetapi sebenarnya, akauntan itu tidak tahu apa yang dia bercakap tentang, dan pengurus tidak dapat membayangkan bagaimana untuk bekerja seperti ini jika dia terpaksa pergi ke akauntan untuk setiap bil. Akibatnya, kami kehilangan banyak masa, tetapi tiada apa yang berubah, pengurus terus mengeluarkan invois. Dan pengasas tetap tidak yakin, tetapi tidak campur tangan dalam proses itu lagi. Pada peringkat yang sama ini, adalah dinasihatkan untuk membangunkan Piagam Projek, yang menetapkan peranan peserta, prosedur untuk komunikasi, peraturan dan pelaporan, serta semua perkara lain yang perlu dinyatakan dalam Piagam. Pembangunan Piagam Projek sekali lagi menjadi topik yang berasingan.
Melatih pasukan projek dalam kaedah dan alatan kerja, bersetuju dengan peraturan kerja, jenis dan komposisi dokumentasi	Pertama sekali, adalah perlu untuk menerangkan kepada pasukan projek semua yang dinyatakan dalam Piagam dan bagaimana ia akan digunakan dalam amalan. Kedua, pasukan projek Pelanggan mesti dilatih dalam kaedah kerja yang akan anda gunakan pada semua peringkat seterusnya. Adalah wajar untuk membincangkan format dokumen yang akan digunakan dan mempertimbangkan sampel. Jika sebarang peraturan untuk menerangkan model atau proses perniagaan akan digunakan, maka peraturan ini juga mesti dibincangkan supaya ia jelas.
soal selidik	Peringkat tinjauan membolehkan anda mendapatkan keratan rentas maklumat yang agak boleh dipercayai tentang syarikat dengan cara yang agak cepat. Kualiti maklumat tersebut akan ditentukan oleh tiga faktor: Pertama sekali, cara anda melatih pasukan projek Pelanggan. Mereka mesti memahami dengan jelas bagaimana proses tinjauan berfungsi dan dapat menyampaikan maklumat kepada semua peserta Borang soal selidik itu sendiri. Soal selidik mesti boleh difahami. Adalah dinasihatkan untuk mempunyai arahan untuk mengisi borang soal selidik. Lebih baik lagi jika ada contoh cara mengisinya. Senarai peserta. Ia adalah perlu untuk memilih komposisi peserta yang betul. Jika anda mengehadkan diri anda hanya kepada pengurus, anda tidak akan dapat mengumpul maklumat yang boleh dipercayai. Saya syorkan termasuk dalam tinjauan semua orang yang akan menjadi pengguna hasil akhir pada masa hadapan. Sebagai contoh, jika kita bercakap tentang melaksanakan sistem automatik, maka ia patut memasukkan semua orang yang akan menjadi pengguna. Ada kalanya daripada 10 pekerja satu jawatan ada seorang yang melaksanakan beberapa fungsi khas yang tidak diketahui oleh 9 orang yang tinggal lagi (contohnya, menyediakan laporan khas untuk pengurusan). Jika kita bercakap tentang pengagihan semula tanggungjawab atau pembangunan huraian kerja, anda harus melakukan perkara yang sama. Sila ambil perhatian bahawa metodologi tinjauan untuk pelaksanaan seterusnya sistem automatik atau perihalan proses perniagaan dalam kes yang betul berbeza. Sudah tentu, struktur soal selidik mungkin sama, tetapi ini bukan pilihan terbaik. Apabila kita menerangkan proses perniagaan, soal selidik biasanya lebih bersifat umum, kerana Ia tidak diketahui dengan tepat apa yang akan anda hadapi. Jika kita bercakap tentang pelaksanaan sistem automatik tertentu, maka adalah lebih baik untuk mempunyai soal selidik yang mengambil kira ciri-ciri sistem ini. Dengan pendekatan ini, anda boleh mengenal pasti dengan segera semua kesesakan sistem yang tidak sesuai untuk perusahaan tertentu. Sebagai peraturan, kaedah untuk melaksanakan sistem siap sedia menyediakan kehadiran soal selidik tersebut. Soal selidik tersebut boleh dibangunkan sama ada untuk bidang perakaunan tertentu (contohnya, perakaunan pesanan, jualan, harga) atau untuk jawatan tertentu (contohnya pengarah kewangan). Komposisi soalan adalah lebih kurang sama.
Undian	Tinjauan ialah temu bual lisan dengan pakar untuk mengetahui ciri-ciri proses individu. Adalah perlu untuk mengatur tinjauan supaya ia tidak kelihatan seperti hanya "bertemu dan bercakap", tetapi dengan cara yang lebih teratur. Untuk melakukan ini, anda perlu menyediakan pelan tinjauan yang dipanggil. Anda boleh memasukkan di dalamnya bahagian-bahagian soal selidik yang menimbulkan soalan untuk anda, bercanggah dengan maklumat daripada soal selidik lain, atau maklumat itu dibentangkan secara cetek. Adalah dinasihatkan untuk menambah soalan hanya dari pengalaman peribadi. Jawapan mesti dicatat tanpa gagal. Ia sesuai jika anda bersetuju dengan rakaman audio. Pada peringkat yang sama, anda harus memastikan kesempurnaan maklumat yang diberikan pada aliran dokumen (kedua-dua bentuk dokumen utama dan pelbagai laporan)
Pengenalpastian proses perniagaan utama atau bidang automasi	Selepas soal selidik dan tinjauan, boleh diandaikan secara munasabah bahawa terdapat maklumat yang mencukupi untuk membuat kesimpulan tentang pengenalpastian proses perniagaan utama. Malah, sudah mungkin untuk mengenal pasti bukan sahaja proses perniagaan utama, tetapi hampir semuanya (jika peserta dipilih dengan betul). Isu mengenal pasti proses perniagaan adalah topik yang berasingan dan bukan mudah. Belajar di sini adalah sukar dan dibangunkan terutamanya oleh pengalaman. Senarai (pengelas) harus disusun daripada proses perniagaan yang dikenal pasti. Anda kemudian boleh membuat keputusan tentang mana yang perlu diterokai dengan lebih mendalam, yang mana tidak dan keutamaan.
Perumusan keperluan utama untuk sistem, matlamat, kriteria kejayaan projek, proses untuk kajian terperinci	Pada peringkat ini, semua maklumat utama tentang aktiviti syarikat harus dikumpulkan dan senarai proses perniagaan mesti disusun. Sekarang adalah masa untuk kembali kepada matlamat, nyatakannya, dan, jika perlu, bincangkannya dengan pegawai atasan syarikat. Apabila merumuskan matlamat, kita harus mengambil kira petunjuk khusus, apabila pencapaiannya kita akan menganggap projek itu berjaya. Jika kita bercakap tentang pelaksanaan sistem automatik, maka senarai berasingan boleh menyerlahkan keperluan untuk sistem daripada pengguna utama. Saya melakukan ini dalam bentuk jadual berasingan, di mana semua keperluan dikumpulkan mengikut subsistem, untuk setiap keperluan pengarang keperluan, kata-kata dan keutamaan ditunjukkan. Maklumat ini boleh digunakan untuk merangka pelan penggunaan sistem (urutan pelaksanaan subsistem individu), serta cadangan untuk pembangunan selanjutnya sistem (jika subsistem individu tidak dirancang untuk dilaksanakan dalam projek semasa). Jika perlu untuk menerangkan proses perniagaan, keputusan dibuat tentang proses tersebut yang perlu dikaji dengan lebih terperinci.

Jadi kita sampai kepada soalan "Apa yang seterusnya?" Seterusnya kita akan mempertimbangkan tugas-tugas menerangkan proses perniagaan dan membangunkan spesifikasi teknikal secara berasingan. Bukan kebetulan saya menganggap tugas-tugas ini selari. Terdapat banyak persamaan antara mereka, itulah yang saya ingin tunjukkan. Mula-mula, mari kita lihat urutan kerja apabila menerangkan proses perniagaan.

	Apa dan bagaimana untuk dilakukan
Kami menyerlahkan proses perniagaan	Daripada senarai umum proses perniagaan yang diperoleh pada peringkat sebelumnya, kami memilih satu (mengikut keutamaan) untuk pembangunan terperinci. Kami kemudian melakukan perkara yang sama dengan yang lain.
Kajian terperinci tentang proses perniagaan	Kami menundukkan proses perniagaan yang dipilih kepada kajian terperinci: kami menganalisis dokumen utama yang diterima, laporan dan strukturnya yang digunakan dalam proses program, pelbagai fail (contohnya, Excel), dan berbincang dengan pelaksana akhir. Kami mengumpul pelbagai idea tentang cara proses itu boleh diperbaiki. Ia sangat berguna jika anda berjaya memerhatikan proses itu dengan tepat di bawah keadaan di mana ia sedang dijalankan (tidak ramai orang suka ditonton, tetapi apa yang boleh anda lakukan)
Perihalan grafik dan/atau teks proses perniagaan (utama)	Kami mula menerangkan maklumat terperinci yang diterima. Sebelum menerangkan proses, kami perlu memutuskan sama ada ia memerlukan penerangan grafik. Sekiranya proses itu mudah dan jelas, terdapat beberapa fungsi di dalamnya, dan perwakilan grafik tidak akan meningkatkan pemahaman atau persepsinya, maka tidak perlu membuang masa untuk itu. Dalam kes ini, cukup untuk menerangkannya dalam bentuk teks dalam bentuk jadual. Sekiranya proses itu rumit, dengan pelbagai keadaan logik, maka lebih baik untuk menyediakan gambarajah grafiknya. Gambar rajah sentiasa lebih mudah difahami. Jika anda memutuskan untuk menerangkan proses secara grafik, ini tidak bermakna anda tidak perlu memberikan penerangan teks. Itu. Harus ada penerangan teks proses dalam apa jua keadaan, dan ia harus dilakukan mengikut skema yang sama. Adalah mudah untuk melakukan ini dalam bentuk jadual di mana anda menunjukkan: pelaku setiap langkah, maklumat yang mereka terima sebagai input, penerangan setiap langkah, maklumat yang dihasilkan pada output. Di bawah ini kita akan melihat contoh bagaimana ini mungkin kelihatan.
Penyelarasan dengan penghibur dan pemilik proses perniagaan	Cara terbaik untuk memahami sejauh mana anda telah memilih gaya penyampaian maklumat ialah dengan menunjukkan hasil kepada pengguna (pelaku) proses tersebut. Perkara yang paling penting dalam demonstrasi sedemikian adalah untuk memahami sejauh mana anda memahami dengan betul bagaimana proses itu Jika latihan pasukan projek berjaya, anda boleh mengharapkan maklum balas yang mencukupi daripada penghibur. Dan jika mereka berminat, maka semuanya akan bergerak ke hadapan dengan lebih pantas. Penjelasan dan ketidakkonsistenan yang dikenal pasti mesti ditunjukkan dalam huraian (dikemas kini), dan jika perlu, operasi mesti diulang.
Pengasingan penunjuk proses perniagaan	Sebaik sahaja anda telah membangunkan pemahaman yang betul tentang cara proses perniagaan dilakukan, anda perlu memikirkan penunjuk yang boleh mengukur kualiti atau kelajuan proses. Ini tidak mudah, tetapi ia perlu. Penunjuk mestilah boleh diukur, i.e. dinyatakan dalam istilah berangka dan mesti ada cara mudah untuk mendapatkan nilai ini. Jika penunjuk yang diukur tidak dapat dikenal pasti, terdapat risiko proses perniagaan telah dikenal pasti tidak berjaya. Di samping itu, tidak akan ada cara untuk memahami (lagipun, ia tidak boleh diukur) sama ada perubahan pada proses akan membawa kepada peningkatan atau tidak.
Dokumentasi akhir proses perniagaan	Setelah kami memastikan bahawa kami mempunyai pemahaman yang baik tentang cara sesuatu proses itu (atau sepatutnya) dilaksanakan, kami boleh memasukkannya ke dalam dokumentasi.
	Pilihan selanjutnya adalah mungkin: proses yang sedang dipertimbangkan akan dianalisis dan dioptimumkan, huraian kerja akan dibangunkan, keputusan akan dibuat tentang keperluan untuk mengautomasikan proses individu, dsb. Ini boleh menjadi projek yang berasingan: penerangan tentang proses perniagaan.

Sekarang mari kita lihat bagaimana pendekatan untuk mengkaji keperluan untuk sistem maklumat akan kelihatan dengan refleksi mereka selanjutnya dalam Terma Rujukan

	Apa dan bagaimana untuk dilakukan
Kami menyerlahkan keperluan perniagaan/bidang automasi	Mengasingkan keseluruhan kawasan automasi (contohnya, "Inventori") sebagai keperluan digunakan dalam amalan, bagaimanapun, ini bukanlah cara paling berkesan untuk memperincikan keperluan. Kawasan automasi ialah sekumpulan keperluan, dan sebaiknya pertimbangkan secara individu. Sebagai contoh, "Perakaunan untuk penerimaan barang di gudang"
Kajian terperinci tentang keperluan perniagaan	Kajian terperinci tentang keperluan perniagaan merujuk kepada bagaimana pengguna akhir ingin melihatnya dan akan menggunakannya (sudah tentu, mengikut matlamat projek). Dalam teknologi kejuruteraan perisian ini sering dirujuk sebagai "kes penggunaan". Oleh itu, kajian terperinci tentang keperluan perniagaan adalah untuk membangunkan kes penggunaan. Contoh pilihan ini diberikan dalam Lampiran 2 kepada artikel. Dalam kes yang paling mudah, kes penggunaan tidak semestinya perlu dilukis dalam bentuk gambar rajah grafik; anda boleh menghadkan diri anda kepada penggubalan teks. Sebagai contoh, keperluan "Apabila memasukkan item, harga mesti dikira sebagai harga belian + 20%" tidak masuk akal. Dalam bentuk gambar rajah, masuk akal untuk mewakili keperluan yang digabungkan ke kawasan automasi, seperti yang ditunjukkan dalam contoh dalam Lampiran 2.
Keperluan pemodelan dalam sistem maklumat	Ini dia! Seperti yang anda mungkin ingat, saya telah menarik perhatian kepada elemen terpenting ini dalam metodologi untuk membangunkan Spesifikasi Teknikal. "Bina model - anda akan mendapat hasilnya!" Apa yang perlu dimodelkan? Ia adalah perlu untuk memodelkan kes penggunaan yang diperoleh pada peringkat sebelumnya. Apakah yang sepatutnya menjadi output simulasi? Hasilnya mestilah program demonstrasi di mana data pengguna dimasukkan, sebaik-baiknya yang biasa dengan pendengarannya (pengguna), dengan mengambil kira spesifik industri dan masalah semasa. Dan mereka dimasukkan atas sebab tertentu, tetapi harus jelas dari mana data ini datang dan bagaimana ia dikira. Pada ketika ini pembaca harus mempunyai soalan: Tetapi bagaimana jika anda merancang untuk membangunkan sistem baharu dan tiada apa-apa untuk dimodelkan? Bagaimana jika demo tidak mempunyai fungsi dan sistem perlu diperbaiki? Sudah tentu, anda perlu menghadapi situasi sedemikian, dan itu adalah perkara biasa. Apa nak buat? Jika sistem itu benar-benar baharu (seperti yang mereka katakan, "dari awal"), maka anda perlu memodelkan kebanyakannya di atas kertas, di sini rajah kes penggunaan akan banyak membantu anda. Sebahagiannya, masuk akal untuk melakar beberapa bentuk skrin yang sepatutnya dibangunkan (betul-betul dalam persekitaran di mana pembangunan akan dijalankan), kerana melukisnya dalam sesetengah editor akan mengambil masa yang lebih lama dan kerja ini membosankan. Jika sistem siap sedia sedang dilaksanakan dan ia tidak mempunyai fungsi, maka tiada apa yang perlu dikhuatiri, data dimasukkan secara manual, dan pengguna diberitahu bahawa selepas pengubahsuaian yang diperlukan ia harus dikira sedemikian dan sedemikian (dan dia nampak). Adalah dinasihatkan untuk mengiringi model sedemikian dengan penerangan teks, walaupun ringkas, supaya pengguna boleh secara bebas cuba bekerja dengan model pada masa lapangnya. Dalam huraian yang sama, anda boleh merumuskan keperluan untuk penambahbaikan.
Demonstrasi model maklumat kepada kumpulan kerja	Kami menunjukkan model yang terhasil kepada Pelanggan dan memberitahu bagaimana semuanya harus berfungsi. Adalah lebih baik untuk menunjukkan model mengikut subsistem, i.e. mengikut kumpulan keperluan. Jika ternyata skim yang dicadangkan tidak akan berfungsi untuk pelanggan, anda perlu memikirkan kes penggunaan lain, membuat perubahan pada model dan menunjukkannya semula. Hanya jika terdapat keyakinan bahawa model yang dirancang akan "hidup" untuk pelanggan tertentu boleh model itu dianggap berjaya.
Pembangunan ujian	Mengapakah ujian diperlukan? Bagaimana kami dapat melaksanakan keperluan perlu diuji. Sehubungan itu, adalah dinasihatkan untuk melakukan ujian untuk semua bidang utama, algoritma kompleks, dsb. Ujian ini juga boleh digunakan semasa menghantar kertas kerja. Tidak perlu melakukan ujian untuk setiap fungsi sistem; akal sehat harus digunakan di mana-mana. Jika kita bercakap tentang sistem sedia, maka melakukan ujian untuk "memasukkan elemen baru ke dalam direktori pelanggan" akan kelihatan bodoh dan membuang masa dan usaha. Tetapi jika ini adalah sistem yang sama sekali baru, ini agak mungkin. Mengapa ujian jika belum ada sistem? Pertama, ia akan lebih jelas kepada pemaju apa yang mereka mahu capai daripadanya. Kedua, kami menjadikan kehidupan lebih mudah untuk penguji (seseorang akan menguji hasil pembangunan). Secara umum, ujian adalah disiplin yang berasingan, tidak begitu mudah dengan banyak teknik. Dalam amalan, sebagai peraturan, kaedah ujian paling mudah masih digunakan.
Mendokumentasikan keperluan dalam bentuk Spesifikasi Teknikal	Maklumat yang dikumpul pada peringkat sebelumnya adalah tepat seperti yang harus dimasukkan dalam asas dokumen "Spesifikasi Teknikal" dalam bahagian dengan keperluan. Jadi yang tinggal hanyalah memformat semuanya dengan betul.
Langkah seterusnya (atau kekurangannya), bergantung pada matlamat projek	Proses pembangunan mungkin mengambil masa yang lebih lama untuk dimulakan, pencarian rakan kongsi untuk projek, tender, dsb., semuanya bergantung pada keadaan.

Ya, pembangunan Terma Rujukan adalah proses intensif buruh, dan oleh itu memerlukan kos yang tinggi. Tetapi jika ia dilakukan dengan betul, ia melegakan Pelanggan daripada jangkaan yang tidak tercapai. Kontraktor perlu melakukan apa yang diperlukan oleh Pelanggan dan tidak membuat semula perkara yang sama seratus kali. Dan secara umum, ia memberikan ketelusan keseluruhan projek.

Persediaan untuk kerja makmal

Biasakan diri anda dengan bahan kuliah mengenai topik “Model kitaran hayat perisian. Peringkat kitaran hayat mengikut GOST 19.102-77. Pernyataan masalah" disiplin akademik "Pembangunan dan penyeragaman perisian dan IT".

1. Kaji bahagian yang berkaitan dalam penerbitan.

Bahagian teori. Pembangunan spesifikasi teknikal

Tugas teknikal ialah dokumen yang merumuskan matlamat pembangunan utama, keperluan untuk produk perisian, mentakrifkan masa dan peringkat pembangunan, dan mengawal selia proses ujian penerimaan. Kedua-dua wakil pelanggan dan wakil kontraktor mengambil bahagian dalam pembangunan spesifikasi teknikal. Dokumen ini berdasarkan keperluan awal pelanggan, analisis pencapaian teknologi canggih, hasil kerja penyelidikan, kajian pra-reka bentuk, ramalan saintifik, dsb.

Prosedur untuk membangunkan spesifikasi teknikal

Pembangunan spesifikasi teknikal dijalankan mengikut urutan berikut. Pertama sekali, satu set fungsi yang perlu dilakukan diwujudkan, serta senarai dan ciri-ciri data awal. Kemudian senarai keputusan, ciri-ciri dan kaedah persembahan ditentukan.

Seterusnya, persekitaran pengendalian perisian ditentukan: konfigurasi dan parameter khusus perkakasan, versi sistem pengendalian yang digunakan dan, mungkin, versi dan parameter perisian lain yang dipasang yang mana produk perisian masa depan akan berinteraksi.

Dalam kes di mana perisian yang dibangunkan mengumpul dan menyimpan beberapa maklumat atau disertakan dalam kawalan mana-mana proses teknikal, ia juga perlu untuk mengawal selia tindakan program dengan jelas sekiranya peralatan dan kegagalan bekalan kuasa.

1. Peruntukan Am

1.1. Terma rujukan disediakan mengikut GOST 19.106-78 pada helaian format A4 dan A3 mengikut GOST 2.301-68, sebagai peraturan, tanpa mengisi medan helaian. Nombor helaian (halaman) diletakkan di bahagian atas helaian di atas teks.

1.2. Helaian kelulusan dan halaman tajuk disediakan mengikut GOST 19.104-78. Bahagian maklumat (anotasi dan kandungan), helaian pendaftaran perubahan mungkin tidak disertakan dalam dokumen.

1.3. Untuk membuat perubahan dan penambahan kepada latar belakang teknikal pada peringkat seterusnya pembangunan program atau produk perisian, tambahan kepadanya dikeluarkan. Penyelarasan dan kelulusan penambahan kepada spesifikasi teknikal dijalankan dengan cara yang sama seperti yang ditetapkan untuk spesifikasi teknikal.

1.4. Terma rujukan mesti mengandungi bahagian berikut:

Pengenalan;

Nama dan skop permohonan;

Asas pembangunan;

Tujuan pembangunan;

Keperluan teknikal untuk program atau produk perisian;

Penunjuk teknikal dan ekonomi;

Peringkat dan peringkat pembangunan;

Prosedur kawalan dan penerimaan;

Aplikasi.

Bergantung pada ciri program atau produk perisian, adalah mungkin untuk menjelaskan kandungan bahagian, memperkenalkan bahagian baharu atau menggabungkan bahagian individu. Jika perlu, ia dibenarkan untuk memasukkan aplikasi dalam spesifikasi teknikal.

2.1.Pengenalan hendaklah merangkumi penerangan ringkas tentang skop aplikasi program atau produk perisian, serta objek (contohnya, sistem) di mana ia bertujuan untuk digunakan. Tujuan utama pengenalan adalah untuk menunjukkan perkaitan pembangunan ini dan menunjukkan kedudukan pembangunan ini antara yang serupa.

2.2 Dalam bahagian “Nama dan skop” nyatakan nama, penerangan ringkas tentang skop aplikasi program atau produk perisian dan objek di mana program atau produk perisian digunakan.

2.3 Bahagian "Asas untuk pembangunan" mesti menunjukkan:

Dokumen (-dokumen) berdasarkan pembangunan yang dijalankan. Dokumen sedemikian boleh menjadi pelan, pesanan, kontrak, dll.;

Organisasi yang meluluskan dokumen ini dan tarikh kelulusannya;

Nama dan (atau) simbol topik pembangunan.

2.4. Bahagian "Tujuan pembangunan" mesti menunjukkan tujuan fungsian dan operasi program atau produk perisian.

2.5. Bahagian "Keperluan teknikal untuk program atau produk perisian" hendaklah mengandungi subseksyen berikut:

Keperluan untuk ciri fungsi;

Keperluan kebolehpercayaan;

Syarat Penggunaan;

Keperluan untuk komposisi dan parameter cara teknikal;

Keperluan untuk maklumat dan keserasian perisian;

Keperluan untuk pelabelan dan pembungkusan;

Keperluan untuk pengangkutan dan penyimpanan;

Keperluan khas.

2.5.1 Subseksyen "Keperluan untuk ciri fungsi" mesti menunjukkan keperluan untuk komposisi fungsi yang dilakukan, organisasi data input dan output, ciri pemasaan, dsb.

2.5.2 Subseksyen "Keperluan Kebolehpercayaan" mesti menunjukkan keperluan untuk memastikan operasi yang boleh dipercayai (memastikan operasi yang stabil, memantau maklumat input dan output, masa pemulihan selepas kegagalan, dsb.).

2.5.3 Subseksyen "Keadaan operasi" mesti menunjukkan keadaan operasi (suhu ambien, kelembapan relatif, dsb. untuk jenis media storan terpilih) di mana ciri-ciri tertentu mesti dipastikan, serta jenis perkhidmatan, kuantiti yang diperlukan dan kakitangan kelayakan.

2.5.4 Dalam subseksyen "Keperluan untuk komposisi dan parameter cara teknikal" menunjukkan komposisi cara teknikal yang diperlukan dengan petunjuk ciri teknikalnya.

2.5.5 Dalam subseksyen "Keperluan untuk maklumat dan keserasian perisian," keperluan untuk struktur maklumat pada input dan output dan kaedah penyelesaian, kod sumber dan bahasa pengaturcaraan mesti dinyatakan. Di mana perlu, perlindungan maklumat dan program mesti dipastikan.

2.5.6 Dalam subseksyen "Keperluan untuk menanda dan pembungkusan", secara amnya, keperluan untuk menanda produk perisian, pilihan pembungkusan dan kaedah ditunjukkan.

2.5.7 Dalam subseksyen "Keperluan untuk pengangkutan dan penyimpanan", keadaan pengangkutan, lokasi penyimpanan, keadaan penyimpanan, keadaan penyimpanan, tempoh penyimpanan dalam pelbagai keadaan mesti ditunjukkan untuk produk perisian.

2.5.8. Bahagian "Penunjuk teknikal dan ekonomi" harus menunjukkan: anggaran kecekapan ekonomi, anggaran permintaan tahunan, kelebihan ekonomi pembangunan berbanding dengan sampel atau analog domestik dan asing terbaik.

2.6 Dalam bahagian "Peringkat dan fasa pembangunan", peringkat pembangunan, peringkat dan kandungan kerja yang diperlukan ditetapkan (senarai dokumen program yang mesti dibangunkan, dipersetujui dan diluluskan), serta, sebagai peraturan , jangka masa pembangunan dan pelaksana ditentukan.

2.7 Bahagian "Prosedur untuk kawalan dan penerimaan" mesti menunjukkan jenis ujian dan keperluan am untuk penerimaan kerja.

2.8 Dalam lampiran kepada spesifikasi teknikal, jika perlu, sediakan:

Senarai penyelidikan dan kerja lain yang mewajarkan pembangunan;

Gambar rajah algoritma, jadual, penerangan, justifikasi, pengiraan dan dokumen lain yang boleh digunakan semasa pembangunan;

Sumber pembangunan lain.

Dalam kes di mana pelanggan tidak mengemukakan sebarang keperluan yang ditetapkan oleh spesifikasi teknikal, "Tiada keperluan dibentangkan" hendaklah ditunjukkan di tempat yang sesuai.

Contoh pembangunan spesifikasi teknikal diberikan dalam Lampiran B dan C.

Soalan kawalan

1.Berikan konsep model kitaran hayat perisian.

2.Berikan peringkat pembangunan perisian.

3. Apakah yang termasuk penyataan masalah dan penyelidikan pra-projek?

4. Senaraikan keperluan fungsian dan operasi untuk produk perisian.

5. Senaraikan peraturan untuk membangunkan spesifikasi teknikal.

6. Namakan bahagian utama spesifikasi teknikal.

Lampiran A

Pilihan tugas

Kerja-kerja makmal No. 1-5 dilakukan untuk pilihan yang sama.

1. Membangunkan modul perisian "Perakaunan untuk kemajuan pelajar." Modul perisian direka bentuk untuk merekodkan operasi kemajuan pelajar semasa sesi oleh dekan, timbalan dekan dan kakitangan pejabat dekan. Maklumat tentang prestasi akademik pelajar hendaklah disimpan sepanjang tempoh pengajian mereka dan digunakan dalam penyediaan sijil kursus yang diambil dan tambahan diploma.

2. Membangunkan modul perisian "Fail peribadi pelajar". Modul perisian direka bentuk untuk mendapatkan maklumat tentang pelajar oleh pekerja pejabat dekan, jawatankuasa kesatuan sekerja dan jabatan sumber manusia. Maklumat mesti disimpan sepanjang tempoh pengajian pelajar dan digunakan dalam penyediaan sijil dan laporan.

3. Bangunkan modul perisian "Menyelesaikan masalah pengoptimuman gabungan." Modul mesti mengandungi algoritma untuk mencari kitaran panjang minimum (masalah jurujual perjalanan), mencari laluan terpendek dan mencari pokok rentang minimum.

4. Membangunkan modul perisian "Pemprosesan Matriks". Modul mesti mengandungi algoritma untuk mencari jumlah dan produk unsur matriks mengikut baris dan lajur, serta mengira nilai purata, minimum dan maksimum dalam matriks.

5. Bangunkan aplikasi Windows "Organizer". Aplikasi ini bertujuan untuk merekod, menyimpan dan mencari alamat dan nombor telefon individu dan organisasi, serta jadual, mesyuarat, dll. Aplikasi ini bertujuan untuk mana-mana pengguna komputer.

6. Bangunkan aplikasi Windows "Kalkulator". Aplikasi ini bertujuan untuk mana-mana pengguna dan mesti mengandungi semua operasi aritmetik (berkenaan dengan keutamaan) dan sebaik-baiknya (tetapi tidak semestinya) beberapa fungsi matematik.

7. Membangunkan modul perisian "Jabatan", yang mengandungi maklumat tentang pekerja jabatan (nama penuh, jawatan, ijazah akademik, disiplin, beban kerja, khidmat masyarakat, kerja sambilan, dll.). Modul ini bertujuan untuk digunakan oleh pekerja jabatan HR dan pejabat dekan.

8. Membangunkan modul perisian "Makmal" yang mengandungi maklumat tentang pekerja makmal (nama penuh, jantina, umur, status perkahwinan, kehadiran anak, jawatan, ijazah akademik). Modul ini bertujuan untuk digunakan oleh pekerja jawatankuasa kesatuan sekerja dan jabatan kakitangan.

9. Membangunkan modul perisian “Cucian Kering”. Apabila mendaftar untuk perkhidmatan, permohonan diisi, yang menunjukkan nama pemilik, perihalan produk, jenis perkhidmatan, tarikh penerimaan pesanan dan kos perkhidmatan. Selepas kerja siap, resit dicetak.

10. Bangunkan modul perisian "Perakaunan untuk pelanggaran lalu lintas." Untuk setiap kereta (dan pemiliknya) senarai pelanggaran disimpan dalam pangkalan data. Bagi setiap pelanggaran, tarikh, masa, jenis pelanggaran dan jumlah denda direkodkan. Apabila semua denda dibayar, kereta itu dikeluarkan daripada pangkalan data.

11. Membangunkan modul perisian "Indeks Kad Kedai Automotif", bertujuan untuk digunakan oleh pekerja agensi. Pangkalan data mengandungi maklumat tentang kereta (buatan, saiz enjin, tarikh pengeluaran, dsb.). Apabila permintaan pembelian diterima, pilihan yang sesuai dicari. Jika tiada pilihan sedemikian, pelanggan dimasukkan ke dalam pangkalan data pelanggan dan diberitahu apabila pilihan itu muncul.

12. Membangunkan modul perisian “PBX Subscriber Index”. Indeks kad mengandungi maklumat tentang telefon dan pemiliknya. Merekod tunggakan pembayaran (langganan dan berasaskan masa). Adalah dipercayai bahawa pembayaran berasaskan masa untuk panggilan telefon tempatan telah pun diperkenalkan.

13. Bangunkan modul perisian "Avtokassa" yang mengandungi maklumat tentang ketersediaan tempat duduk percuma di laluan bas. Pangkalan data mesti mengandungi maklumat tentang nombor penerbangan, laluan, pemandu, jenis bas, tarikh dan masa berlepas, serta harga tiket. Apabila permohonan tiket diterima, program mencari penerbangan yang sesuai.

14. Membangunkan modul perisian "Kedai Buku" yang mengandungi maklumat tentang buku (pengarang, tajuk, penerbit, tahun penerbitan, harga). Pembeli mengisi permintaan untuk buku yang dia perlukan; jika tiada, dia dimasukkan ke dalam pangkalan data dan diberitahu apabila buku yang dia perlukan tiba di kedai.

15. Membangunkan modul perisian “Car Parking”. Program ini mengandungi maklumat tentang pembuatan kereta, pemiliknya, tarikh dan masa masuk, kos letak kereta, diskaun, bayaran tertunggak, dsb.

Mencipta spesifikasi teknikal adalah salah satu peringkat pertama dan sangat penting dalam kebanyakan projek. Spesifikasi teknikal (TOR) yang jelas dan disediakan dengan betul membolehkan anda menjelaskan hubungan antara pelanggan dan kontraktor, merumuskan keperluan untuk ciri-ciri objek masa depan, dan juga menjadi asas untuk menyemak kerja yang dilakukan.

Apakah spesifikasi teknikal

Takrifan umum istilah ini adalah seperti berikut: spesifikasi teknikal ialah dokumen khas yang dibangunkan oleh pelanggan dan diluluskan oleh kontraktor, yang menetapkan keperluan, parameter dan ciri operasi utama projek, kemudahan atau sistem.

Antara lain, dokumen ini mungkin termasuk senarai keperluan yang berkaitan dengan ujian (berkaitan dengan pembangunan perisian).

Ia digunakan dalam kerja mereka oleh pembina, pembaikan, pengaturcara, pereka dan ramai pakar lain.

Spesifikasi teknikal ialah dokumen yang dibangunkan oleh seorang profesional yang mahir dalam spesifik jenis kerja tertentu. Kejayaan keseluruhan acara bergantung pada seberapa terperinci jangkaan pelanggan diterangkan. Dalam erti kata lain, spesifikasi teknikal ialah arahan untuk pekerja yang membolehkan anda membandingkan hasil akhir dengan yang dirancang.

Ciri-ciri terma rujukan

Selalunya proses merangka arahan itu sendiri membolehkan pelanggan memahami bagaimana dia ingin melihat projek yang telah siap. Ini disebabkan oleh hakikat bahawa keperluan untuk menetapkan matlamat tertentu merangsang dia untuk mengkaji kemungkinan dan batasan yang wujud dalam jenis aktiviti ini. Ramai pelanggan, menyedari kekurangan maklumat, ketidaktahuan tentang istilah profesional dan kekurangan pengetahuan khusus, lebih suka mengupah pakar untuk membangunkan spesifikasi teknikal.

Secara paradoks, pendekatan ini membolehkan kami mencapai kerja yang paling diselaraskan, kerana setiap orang melakukan apa yang mereka tahu bagaimana untuk melakukannya dengan baik: pelanggan tahu apa yang dia ingin dapatkan pada akhirnya, pengarang spesifikasi teknikal menterjemah maklumat ini kepada data yang boleh difahami oleh kontraktor, dan tuan mempunyai peluang untuk bekerja mengikut arahan yang jelas .

Tujuan spesifikasi teknikal

Tugas ini melaksanakan fungsi penting: ia membantu menyelesaikan kemungkinan situasi kontroversi. Setelah ditetapkan secara bertulis, keperluan projek atau skop kerja menjadi panduan kepada kedua-dua pihak. Kontraktor berhak untuk tidak melaksanakan kerja yang tidak ditetapkan dalam spesifikasi teknikal. Arahan tambahan memerlukan arahan baharu.

Pada masa yang sama, pelanggan dilindungi daripada penyiapan tugas yang tidak lengkap atau tidak betul, kerana dia boleh menyemak ciri dan parameternya untuk setiap item individu spesifikasi teknikal.

Biasanya, produk siap melalui fasa pemeriksaan, ujian atau ujian. Jika ciri-cirinya berbeza daripada yang dirancang, ia boleh dihantar untuk semakan atau kontraktor boleh menolak pembayaran (ini dibincangkan apabila spesifikasi teknikal untuk kerja disediakan).

Komposisi spesifikasi teknikal: keperluan fungsi

Semua keperluan yang dinyatakan dalam spesifikasi teknikal boleh dikelaskan mengikut jenis dan sifat.

Kebanyakan GOST menjadi contoh keperluan pelbagai jenis. Mereka mengawal proses merangka spesifikasi teknikal untuk pembinaan kemudahan besar dan kerja penting lain. Mereka biasanya menyenaraikan keperluan berikut:

• Kepada komponen berfungsi.
• Untuk parameter keselamatan (untuk sistem automatik dan perisian).
• Ke arah tahap kelayakan pakar.
• Ke arah penampilan.
• Kepada bahan yang digunakan.

Senarai keperluan, dikumpulkan mengikut jenis, agak panjang, kepelbagaiannya disebabkan oleh matlamat projek yang berbeza.

Selalunya, keperluan mengenai fungsi bertindak sebagai teras di mana setiap tugas teknikal dibangunkan. Sistem syarat dan arahan teknikal lain menjadi sejenis "penyamaran" yang dikenakan pada keperluan ini. Sekiranya tugas utama dirumuskan dengan buruk, walaupun "penyamaran" terbaik tidak akan menyelamatkan keadaan, dan projek itu akan gagal.

Ciri-ciri keperluan

Berbeza dengan pelbagai jenis keperluan, terdapat lebih sedikit sifat untuk mencirikannya:

• Kejelasan.
• Kekhususan.
• Kebolehujian.

Sifat terakhir tidak boleh dipisahkan daripada dua yang pertama, kerana keperluan yang jelas dan khusus boleh dilaksanakan dan diuji. Walau bagaimanapun, jika tidak ada cara untuk mengesahkan keputusan, maka boleh dikatakan bahawa keperluan tidak mempunyai salah satu daripada dua sifat pertama.

Terma rujukan bukan projek teknikal

Terdapat banyak pendapat tentang tahap perincian yang harus digunakan semasa membangunkan spesifikasi teknikal.

Kadang-kadang ia disusun menggunakan istilah khusus dan sejumlah besar nuansa yang hanya boleh difahami oleh pakar. Kelemahan pendekatan ini ialah pelanggan, apabila meluluskan spesifikasi teknikal ini, tidak memahami sepenuhnya apa yang akan diterimanya sebagai produk siap. Oleh itu, proses ujian, penyemakan dan penerimaan kerja boleh ditangguhkan, dan projek itu berulang kali dihantar untuk semakan dan penambahbaikan.

Penyokong kaedah lain menegaskan bahawa draf spesifikasi teknikal hendaklah semudah dan boleh difahami yang mungkin. Dokumen ini mungkin termasuk terminologi industri yang boleh difahami oleh pelanggan, tetapi tidak sepatutnya menunjukkan aspek teknikal yang berkaitan dengan pelaksanaan projek. Dalam bidang pembangunan perisian, penganalisis perniagaan, tetapi bukan pengaturcara, bertanggungjawab untuk menyesuaikan keperluan pelanggan ke dalam spesifikasi teknikal (sudah tentu, jika dia tidak melaksanakan tugas kedua-duanya).

Projek teknikal ialah dokumentasi yang menerangkan secara terperinci prosedur untuk melaksanakan perkara-perkara spesifikasi teknikal. Di sinilah istilah, singkatan dan konsep profesional hanya perlu. Pelanggan tidak melihat mereka (kata-kata ini mungkin tidak bermakna apa-apa kepadanya), teks dibaca oleh tuan yang akan terlibat dalam projek itu, dan dia memerlukan data yang tepat dan khusus: dimensi, parameter, kualiti, ciri. ialah arkitek sistem.

Struktur spesifikasi teknikal

Bagi memudahkan penyediaan dan pelaksanaan spesifikasi teknikal, ia dibangunkan mengikut sistem tertentu.

Sebagai peraturan, pada mulanya, di bahagian pengenalan, tujuan dan tujuan projek dinyatakan. Yang berikut ialah senarai bahagian, keperluan dan penjelasannya. Untuk memahami rupa spesifikasi teknikal untuk sistem automatik, anda boleh mempertimbangkan struktur yang disyorkan oleh GOST 34.602-89:

• Petunjuk maklumat am.
• Penerangan tentang tujuan dan tujuan penciptaan atau pembangunan sistem dirancang.
• Ciri-ciri objek tertakluk kepada automasi.
• Penyata keperluan sistem.
• Komposisi dan kandungan aktiviti dan kerja yang digunakan untuk mencipta sistem.
• Penerangan tentang cara kawalan penciptaan dan prosedur penerimaan sistem siap harus dijalankan.
• Senarai keperluan untuk kerja yang akan dijalankan dengan objek automasi untuk penyediaannya.
• Prosedur untuk mengekalkan dokumentasi.
• Petunjuk sumber pembangunan.

Spesifikasi teknikal sedemikian (sampel yang mengandungi penerangan terperinci tentang semua mata) merangkumi kebanyakan aspek projek, tetapi, jika perlu, boleh ditambah dengan mata penjelasan.

Mengapa perlu menyediakan spesifikasi teknikal untuk mengubah suai bilik?

Proses pengubahsuaian dalaman utama tidak semudah yang mungkin kelihatan pada pandangan pertama. Ini bukan sahaja mengenai menukar kertas dinding dan melukis radiator, ia adalah mengenai membetulkan geometri yang rosak, menghapuskan kekurangan seni bina, membuat pelarasan pada susun atur, melengkapkan dan menambah baik bilik.

Atas sebab ini, spesifikasi teknikal untuk pembaikan menjadi salah satu peringkat yang paling penting, kerana ia membolehkan:

• Fikirkan terlebih dahulu tentang kandungan kerja masa depan.
• Sediakan anggaran terperinci dan kenal pasti peluang untuk penjimatan.
• Mencapai kejelasan sepenuhnya mengenai hasil yang diinginkan untuk semua peserta dalam proses (pelanggan, kontraktor, penghibur).

Seperti dalam contoh dengan terma rujukan untuk automasi sistem, perantara antara pelanggan dan pelaku utama merangka terma rujukan. Menjalankan aktiviti untuk melaksanakan kerja yang dirancang dijalankan berdasarkan projek teknikal, ia dibangunkan mengikut mata spesifikasi teknikal.

Apakah item yang disertakan dalam spesifikasi teknikal untuk mengubah suai bilik?

Untuk pengubahsuaian setiap bilik, spesifikasi teknikal yang unik disediakan. Contoh struktur yang paling biasa bagi dokumen ini diberikan di bawah.

1. Nama dan tujuan bilik. Ini perlu, kerana spesifikasi bilik memerlukan pematuhan peraturan tertentu semasa menghiasnya (ruang tamu, bilik tidur, pejabat).

2. Ciri-ciri lantai: jumlah kerja yang perlu dilakukan di kawasan ini. Di sini anda boleh menentukan secara terperinci perkara yang perlu dilakukan oleh pakar:

• Buka penutup, papan tiang dan lantai bawah yang telah menjadi tidak boleh digunakan (jenis dan segi empat sama).
• Sapukan meratakan, membahagi senarai yg panjang lebar dan penebat haba (luas dan ketinggian bahan).
• Jika perlu, pasang sistem "lantai panas" (jenis dan ketinggian struktur).
• Sapukan senarai yg panjang lebar di atas kabel pemanas (lebih kurang 30-50 mm).
• Sediakan permukaan untuk meletakkan jubin, lamina, permaidani atau bahan lain (sifat susunan unsur).
• Pasang alas tiang (nyatakan bilangan meter linear, serta semua sudut dalaman dan luaran).

3. Kerja siling:

• Kapur atau kertas dinding yang jelas (luas dalam meter persegi).
• Aras dengan dempul (kawasan).
• Sapukan plaster (ketebalan segi empat sama dan sederhana).
• Jika anda perlu memasang siling eternit, anda perlu menunjukkan jenis, rakaman persegi dan ketinggiannya. Untuk model pelbagai peringkat, lukisan diperlukan.
• Dempul dan cat siling (kawasan, warna).

4. Apa yang perlu dilakukan dengan dinding:

• Kosongkan lapisan kertas dinding sebelumnya atau penutup lain (kawasan).
• Keluarkan plaster.
• Plaster dinding (dengan atau tanpa tetulang). Di sini adalah perlu untuk menunjukkan bukan sahaja rakaman persegi keseluruhan dinding, tetapi juga ketebalan lapisan. Panjang cerun yang digunakan diberikan dalam meter linear.
• Dempul dinding.
• Tunjukkan berapa banyak sudut luar yang terdapat di dalam bilik supaya anda boleh mengira panjang sudut berlubang.

5. Parameter tetingkap:

• Berikan maklumat tentang pengilang.
• Berikan maklumat tentang jenis profil, kelengkapan, tingkap berlapis dua, ambang tingkap. Terangkan sama ada akan ada kelambu, dan lampirkan lukisan dengan dimensi. Untuk kerja berkualiti yang lebih baik, lebih baik membuat spesifikasi teknikal yang berasingan untuk memesan tetingkap.

6. Ciri-ciri pintu:

• Terangkan parameter pintu, pengilang, bahan yang digunakan (termasuk kelengkapan), jenis bingkai, trim dan engsel.
• Nyatakan secara berasingan keperluan untuk menukar saiz pintu (meningkat, mengurangkan, mengalih) dengan dimensi dan senarai kerja.

7. Bekerja dengan rangkaian elektrik:

• Senarai kerja (pemasangan, penggantian,
• Keperluan untuk meletakkan kabel telefon atau Internet.
• Lampirkan gambar rajah.

8. Langkah-langkah untuk pemasangan sistem pemanasan dan penghawa dingin:

• Memasang, mengalih, menggantikan atau hanya mengecat peranti pemanas.
• Membongkar peranti tradisional dan pemasangan sistem "lantai panas".
• Tandakan pada rajah lokasi penghawa dingin dan laluan. Jelaskan cara ia akan dikuasakan daripada rangkaian elektrik.

Adakah perlu untuk memeriksa premis sebelum merangka spesifikasi teknikal untuk pembaikan?

Semua pakar bersetuju bahawa memeriksa bilik adalah langkah wajib semasa merangka spesifikasi teknikal untuk pengubahsuaian. Dalam kes ini, prosedur harus dijalankan bukan sahaja sebelum pembangunan spesifikasi teknikal, tetapi juga semasa proses penyediaan.

Objektif utama acara ini adalah untuk mendapatkan maklumat tentang keadaan premis dan penerangan yang lebih tepat mengenai kerja-kerja pembaikan yang akan datang.

Apabila memeriksa bilik, perhatikan parameter utama dan lakukan tindakan berikut:

• Semak ketepatan geometri.
• Mereka mengkaji mendatar siling (adakah terdapat cerun, perbezaan). Ini membantu menentukan jenis kemasan dan memberikan gambaran tentang ketinggian masa depan bilik.
• Periksa menegak dinding dan sudut yang betul. Jika perlu diratakan, tukang harus tahu bahan apa yang hendak digunakan dan dalam kuantiti yang perlu dibeli.
• Memeriksa paras lantai. Selalunya, lantai perlu diganti sepenuhnya (terutamanya jika sistem pemanasan dipasang di bawahnya), jadi skop kerja harus ditentukan terlebih dahulu.

Untuk mengelakkan ketidakpastian dan menyediakan semua nuansa yang mungkin, semasa peperiksaan lantai dibongkar di beberapa tempat dan kesimpulan dibuat dari apa yang dilihat.

Data yang diperoleh hasil tinjauan dibandingkan dengan projek, jenis bahan kemasan dan kerja persediaan yang diperlukan untuk pemasangannya.

Maklumat ini membolehkan anda menganggarkan tahap kos buruh dan kewangan. Terma rujukan mesti mengandungi lukisan kerja masa hadapan.

Kerja-kerja pengubahsuaian bilik yang digariskan bukanlah tipikal. Bergantung pada skop kerja, ia mungkin kelihatan berbeza sama sekali, lebih pendek atau termasuk data yang lebih terperinci.

Pesanan untuk pembangunan identiti korporat, reka bentuk pembungkusan, logo atau laman web sentiasa disertakan dengan penyediaan dan pelaksanaan dokumentasi yang berkaitan - perjanjian, spesifikasi ringkas dan teknikal (TOR). Penciptaan spesifikasi teknikal adalah peringkat pertama kerjasama antara pelanggan dan kontraktor.

Salah satu cara yang paling biasa untuk mengurangkan kos dan mengurangkan belanjawan projek adalah dengan melakukannya sendiri menulis spesifikasi teknikal (spesifikasi teknikal) .

Walau bagaimanapun, tanpa pengalaman adalah agak sukar untuk merangka spesifikasi teknikal yang cekap yang akan difahami oleh kedua-dua kontraktor dan pelanggan.

Dalam terma rujukan, adalah perlu untuk menerangkan dengan tepat dan jelas keperluan untuk objek kerja, menetapkan parameter teknikal, tujuan objek, menyediakan komposisi dokumentasi reka bentuk yang diperlukan, menentukan masa dan prosedur untuk menyiapkan kerja.

Sebelum mula membangunkan spesifikasi teknikal, adalah perlu untuk menjalankan penyelidikan, pengiraan awal, dan mengumpul maklumat awal.

Mencipta spesifikasi teknikal ialah proses yang kompleks yang lebih baik diserahkan kepada profesional; Selain itu, "jenama diraja" anda mempunyai tugas yang lebih penting dan keutamaan daripada menulis spesifikasi teknikal.

Terma rujukan ialah

Tugas teknikal - ini adalah dokumen asas keseluruhan projek dan hubungan antara pelanggan dan kontraktor, yang membolehkan anda menentukan dengan jelas susunan kerja, tanggungjawab pihak-pihak dan masa projek.

Tarikh akhir untuk penyiapan dan kejayaan projek secara keseluruhan akan bergantung pada bagaimana terma rujukan yang betul, tepat dan jelas disediakan untuk kontraktor.

Jenis spesifikasi teknikal (spesifikasi teknikal)

Terma rujukan adalah langkah pertama ke arah pelaksanaan mana-mana projek. Terdapat banyak jenis spesifikasi teknikal untuk melaksanakan kerja:
- terma rujukan untuk pembangunan laman web;
- terma rujukan untuk pembangunan logo;
- terma rujukan untuk pembangunan program;
- terma rujukan untuk pembangunan identiti korporat;
- terma rujukan untuk pembangunan reka bentuk;
- terma rujukan untuk membangunkan nama syarikat;
- terma rujukan untuk promosi laman web, dsb.

Tidak kira siapa yang anda pilih untuk melaksanakan projek itu - seorang pekerja bebas atau agensi penjenamaan, sebelum memulakan kerja pada projek itu adalah perlu untuk menganalisis dan memproses sejumlah besar maklumat yang pelbagai. Kajian data mengenai matlamat dan objektif projek, matlamat strategik dan semasa syarikat, keperluan untuk objek kerja, kehendak pelanggan, tarikh akhir untuk penghantaran projek siap dan hasil yang diharapkan. Seterusnya, anda perlu mengumpul maklumat ini bersama-sama, menyusun data dan memberikannya kepada kontraktor dalam bentuk spesifikasi teknikal.

Sebagai peraturan, membangunkan spesifikasi teknikal adalah tugas pengurus projek. Tiada siapa selain pelanggan yang boleh menerangkan idea, prinsip kerja, matlamat projek dan aktiviti syarikat dengan terbaik. Penerangan ini hendaklah sejelas mungkin dan dibentangkan dalam bentuk cerita umum tentang syarikat dan jenamanya.

Struktur spesifikasi teknikal

Struktur spesifikasi teknikal (borang spesifikasi teknikal) adalah seperti berikut:

1. Matlamat projek
Kenyataan kerja mesti menunjukkan matlamat yang ingin dicapai oleh syarikat menggunakan hasil projek yang telah siap. Matlamat sedemikian, sebagai contoh, boleh menjadi: mengeluarkan produk baharu, penjenamaan semula syarikat atau jenama, menjalankan kempen pengiklanan, dsb.
2. Penerangan syarikat pelanggan
- Skop aktiviti dan skala syarikat, misi dan kedudukannya dalam pasaran;
- Perihalan portfolio jenama syarikat - jenama yang digunakan oleh syarikat itu;
- Senarai syarikat pesaing utama;
- Senarai kelebihan daya saing utama syarikat dan USP (cadangan jualan unik).
3. Penerangan tentang situasi dan trend pasaran terkini yang mana jenama itu sedang dibangunkan
- Segmen harga produk atau perkhidmatan syarikat;
- Potret pengguna (umur, jantina, data geografi, tahap sosial khalayak sasaran);
- Matlamat pemasaran taktikal dan strategik syarikat (untuk tempoh 1 hingga 3 tahun);
- Model tingkah laku pengguna dan perihalan situasi di mana pengguna membuat pembelian;
- Penerangan tentang ciri-ciri utama jenama sedia ada, konsep kedudukannya, slogan, komunikasi pemasaran, perlu sekiranya penjenamaan semula.
4. Rujukan
Senarai contoh kerja serupa yang disukai pelanggan dalam konteks projek ini.
5. Keperluan
Dalam bahagian ini adalah perlu untuk menentukan semua keperluan teknikal dan fungsian untuk projek itu. Serta keperluan dan kehendak pelanggan untuk grafik, teks, warna, gaya, fon,

Ingat Hukum Murphy? Jika anda boleh disalah ertikan, anda pasti akan disalah ertikan. Ini benar bukan sahaja dalam komunikasi antara orang, tetapi juga dalam mencipta laman web. Pelanggan mahukan Facebook kedua, tetapi mendapat forum untuk penternak anjing muda. Pemaju tidak meneka apa yang pelanggan mahu - dia membuang masanya.

Dalam panduan ini saya akan memberitahu anda apa dan mengapa anda perlu menulis dalam terma rujukan. Pada masa yang sama, saya akan menunjukkan kepada anda cara untuk tidak menulis supaya penciptaan spesifikasi teknikal tidak bertukar menjadi masa yang sia-sia.

Artikel itu akan berguna:

• Untuk semua orang yang terlibat dalam penciptaan tapak web: pembangun, pereka bentuk, pereka reka letak.
• Pengurus projek.
• Ketua studio digital.
• Usahawan yang merancang untuk memesan pembangunan laman web.

Untuk menjadikan bahan itu berguna, saya mengumpulkan ulasan daripada beberapa pembangun, pereka bentuk, pengurus projek dan pemilik studio digital. Saya menambah yang paling berharga pada akhir artikel. Jom cari tahu.

Apakah spesifikasi teknikal dan mengapa ia diperlukan?

Spesifikasi teknikal ialah dokumen yang menetapkan keperluan untuk tapak. Lebih jelas dan lebih terperinci keperluan ini, lebih baik semua peserta dalam proses memahami apa yang sepatutnya. Ini bermakna peluang bahawa semua orang akan berpuas hati dengan hasilnya meningkat.

Matlamat utama spesifikasi teknikal adalah untuk memastikan bahawa pelanggan dan kontraktor memahami satu sama lain dengan betul.

Terdapat banyak faedah daripada spesifikasi teknikal. Ia berbeza untuk setiap pihak.

Faedah untuk pelanggan:

• Fahami untuk apa dia membayar wang dan seperti apa tapak itu. Anda boleh segera melihat struktur, memahami apa yang akan berfungsi dan bagaimana. Fikirkan jika semuanya sesuai dengan anda. Jika tidak, tiada masalah untuk mengubahnya sebelum pembangunan bermula.
• Lihat kecekapan pelaku. Jika terma rujukan jelas dan tepat, keyakinan terhadap pembangun meningkat. Jika ia berkata bubur, mungkin anda perlu lari dan jangan menoleh ke belakang.
• Menginsuranskan terhadap ketidakjujuran pelaku. Apabila tapak sudah siap, ia boleh disemak mengikut spesifikasi teknikal. Adakah terdapat sebarang percanggahan? Pemaju bertanggungjawab untuk membetulkannya. Jika anda bekerjasama secara rasmi dan telah memeterai perjanjian, anda juga boleh memaksanya melalui mahkamah.
• Permudahkan penggantian penghibur. Jika pelanggan dan pemaju bergaduh dan melarikan diri, penciptaan tapak boleh mengambil banyak masa. Apabila terdapat spesifikasi teknikal terperinci, ia boleh dipindahkan ke pasukan baharu - mereka akan terlibat dalam kerja berkali-kali lebih cepat.
• Ketahui kos untuk membangunkan produk yang kompleks. Adalah mustahil untuk menganggarkan masa dan kos yang tepat untuk membangunkan perkhidmatan web yang kompleks dengan segera. Mula-mula anda perlu memahami bagaimana perkhidmatan akan berfungsi dan fungsi apa yang akan ada. Untuk ini, anda perlu menyediakan spesifikasi teknikal.

Faedah untuk pelaku:

• Fahami apa yang pelanggan mahu. Pelanggan ditanya berpuluh-puluh soalan, ditunjukkan contoh, dan ditawarkan penyelesaian. Kemudian mereka menulis segala-galanya dalam satu dokumen dan bersetuju mengenainya. Jika semuanya ok - hore, anda faham dengan betul.
• Insuranskan diri anda terhadap kehendak pelanggan yang tiba-tiba. Kadangkala anda terserempak dengan pelanggan yang ingin menukar tugas di separuh jalan. Jika anda telah bersetuju dan menandatangani terma rujukan, anda tidak takut akan perkara ini. Jika sesuatu berlaku, malah mahkamah akan menyebelahi anda.
• Tunjukkan kecekapan anda. Spesifikasi teknikal yang disediakan dengan baik akan menunjukkan kepada pelanggan kepakaran pembangun. Jika syarikat ragu-ragu sama ada untuk mempercayai anda dengan pembangunan laman web, kemungkinan besar keraguan akan dihilangkan.
• Untuk mendapatkan wang. Sesetengah studio dan pembangun menawarkan penyediaan spesifikasi teknikal sebagai perkhidmatan yang berasingan.

• Memudahkan dan mempercepatkan proses pembangunan. Spesifikasi teknikal yang baik menunjukkan struktur tapak, fungsi dan elemen yang diperlukan pada setiap halaman. Apabila semua keperluan sudah ada di depan mata anda, yang tinggal hanyalah mereka bentuk dan menulis kod.

Sekarang mari kita fikirkan cara untuk mencipta spesifikasi teknikal yang baik yang melaksanakan semua fungsi ini.

Terma rujukan disediakan oleh penghibur

Secara umum, sesiapa sahaja boleh membuat spesifikasi teknikal. "Kami memerlukan tapak web kad perniagaan untuk klinik pergigian" - ini sudah menjadi tugas teknikal. Tetapi adakah ia akan memenuhi fungsinya? hampir tidak.

Spesifikasi teknikal yang baik sentiasa disediakan oleh pelaksana: pengurus projek atau pemaju. Jelas sekali, pembangun web lebih memahami tentang membuat tapak web berbanding pemilik kafe atau klinik pergigian. Oleh itu, dia perlu menerangkan projek itu.

Ini tidak bermakna bahawa pelanggan hilang dan muncul pada penghujung untuk menulis: "Zbs, saya meluluskan." Dia juga harus mengambil bahagian dalam proses:

Sudah tentu, pelanggan boleh melakar versi spesifikasi teknikalnya sendiri. Mungkin ini akan mempercepatkan proses mencipta spesifikasi teknikal akhir. Atau mungkin akibatnya adalah sampah yang akan dibuang secara rahsia ke dalam tong sampah.

Tulis dengan jelas dan tepat

Nasihat ini mengikuti matlamat utama terma rujukan - "Pastikan pelanggan dan kontraktor memahami satu sama lain dengan betul."

Terma rujukan tidak boleh mengandungi kata sifat yang berkualiti: cantik, boleh dipercayai, moden. Mereka tidak dapat difahami dengan jelas. Setiap orang mempunyai konsep kecantikan dan kemodenan mereka sendiri.

Tengok. Seseorang menganggap reka bentuk ini cantik dan membenarkannya digunakan di tapak web mereka:

Perkara yang sama berlaku dengan rumusan samar-samar yang tidak bermakna apa-apa dalam diri mereka sendiri:

• Pelanggan mesti menyukai tapak tersebut. Bagaimana jika dia dalam mood yang tidak baik?
• Tapak haruslah mudah. Apakah maksudnya? Mudah untuk apa?
• Tapak mesti menahan beban berat. 10 ribu pengunjung? Atau 10 juta?
• Kandungan pakar berkualiti tinggi. Nah, anda mendapat idea itu.

Semak kekaburan dalam teks. Jika ada, tulis semula. Kata-kata anda hendaklah jelas dan tepat:

• Tapak mesti dimuatkan dengan cepat → Mana-mana halaman di tapak mesti mempunyai lebih daripada 80 mata dalam Google PageSpeed ​​​​Insights.
• Beban berat → 50 ribu pengunjung pada masa yang sama.
• Halaman utama memaparkan senarai artikel → Halaman utama memaparkan senarai 6 artikel terakhir yang diterbitkan.
• Antara muka langganan mesra pengguna yang minimalis → medan "Tinggalkan e-mel anda" dan butang "Langgan" → *lakaran yang dilukis*.

Kami telah menyusun kata-kata, mari kita lihat strukturnya.

Sila berikan maklumat am

Semua ahli pasukan mesti memahami dengan betul apa yang syarikat lakukan dan siapa khalayak sasarannya. Supaya tiada siapa yang keliru, adalah lebih baik untuk menulis ini pada awal terma rujukan.

Ia juga berbaloi untuk menunjukkan tujuan tapak dan menerangkan fungsinya secara ringkas - supaya tidak berakhir dengan kedai dalam talian dan bukannya blog.

Terangkan istilah yang sukar

Peraturan pertama terma rujukan ialah ia mesti difahami oleh semua orang yang dimaksudkan untuknya. Jika anda akan menggunakan istilah yang pelanggan anda, pemilik kedai mainan kanak-kanak, mungkin tidak faham, pastikan anda menerangkannya. Dalam bahasa yang jelas, bukan copy-paste dari Wikipedia.

Terangkan alatan dan keperluan pengehosan

Bayangkan anda menghabiskan 2 bulan mencipta laman web yang hebat. Setiap peringkat diselaraskan dengan pelanggan - dia gembira. Dan kini tiba masanya untuk menyerahkan kerja. Anda menunjukkan panel pentadbir, dan pelanggan menjerit: “Apakah ini? Modex?! Saya fikir anda akan melakukannya di WordPress!”

Untuk mengelakkan masalah sedemikian, terangkan alatan, enjin dan perpustakaan yang digunakan. Pada masa yang sama, nyatakan keperluan pengehosan anda. Anda tidak pernah tahu, anda akan melakukannya dalam PHP - dan pelanggan mempunyai pelayan dalam .NET.

Senaraikan keperluan untuk operasi tapak

Tapak ini mesti berfungsi dalam semua penyemak imbas semasa dan pada semua jenis peranti. Ya, ini jelas kepada mana-mana pembangun dan mana-mana pelanggan. Tetapi lebih baik menulis untuk melindungi pelanggan daripada kerja yang dilakukan dengan niat jahat.

Tulis di sini keperluan untuk kelajuan memuatkan tapak, rintangan beban, perlindungan daripada serangan penggodam dan perkara yang serupa.

Nyatakan struktur tapak

Sebelum anda mula melukis reka bentuk dan susun atur, anda perlu bersetuju dengan struktur tapak dengan pelanggan.

Bercakap dengan pelanggan dan ketahui apa yang dia perlukan. Kumpulkan pembangun, pakar SEO, pemasar, ketua editor - dan tentukan halaman yang diperlukan di tapak. Fikirkan tentang cara mereka akan disambungkan antara satu sama lain, yang mana anda boleh bertukar.

Anda boleh menunjukkan struktur dengan senarai, anda boleh melukis gambar rajah blok. Seperti yang anda suka.

Ini adalah salah satu peringkat paling penting untuk bekerja di tapak. Struktur adalah asas. Jika ia tidak berjaya, laman web itu akan menjadi bengkok.

Terangkan apa yang akan ada pada setiap halaman

Pelanggan mesti memahami mengapa setiap halaman diperlukan dan elemen apa yang akan ada padanya. Terdapat dua cara untuk menunjukkan ini.

Prototaip- cara yang lebih visual dan tidak jelas. Kontraktor melukis lakaran setiap halaman dan melampirkannya pada terma rujukan. Pelanggan melihat rupa antara muka tapak web masa depannya dan mengatakan perkara yang dia suka dan perkara yang perlu diubah.

Penghitungan unsur- alternatif yang malas kepada prototaip. Tulis sahaja blok yang sepatutnya ada pada halaman dan perkara yang mereka lakukan.

Terangkan senario untuk menggunakan tapak

Jika anda membuat beberapa jenis antara muka bukan standard, hanya menunjukkan struktur dan lakaran kecil halaman tidak mencukupi. Adalah penting bahawa seluruh pasukan pelaksana dan pelanggan memahami cara pelawat akan menggunakan tapak tersebut. Skrip sangat bagus untuk ini. Gambar rajah senario adalah sangat mudah:

• Tindakan pengguna.
• Respons tapak.
• Hasilnya.

Sudah tentu, jika anda membuat kad perniagaan atau halaman pendaratan standard, anda tidak perlu menulis skrip. Tetapi jika terdapat beberapa perkhidmatan interaktif di tapak, ia adalah sangat wajar.

Baca lebih lanjut mengenai kes penggunaan dalam Wikipedia.

Tentukan siapa yang bertanggungjawab untuk kandungan

Sesetengah pembangun membuat tapak web dengan kandungan serta-merta. Orang lain letak ikan. Yang lain boleh menulis teks, tetapi dengan bayaran tambahan. Bersetuju mengenai perkara ini di pantai dan tulis dalam terma rujukan kandungan yang perlu anda sediakan.

Agak sukar untuk menghasilkan kriteria objektif untuk menilai kualiti teks. Adalah lebih baik untuk tidak menulis apa-apa selain daripada "Kandungan berkualiti tinggi, menarik dan menjual yang berguna untuk khalayak sasaran." Ia adalah sampah, tiada siapa yang memerlukannya.

Menentukan bahawa semua kandungan mestilah unik adalah berguna. Satu lagi perlindungan untuk pelanggan daripada pelaku yang tidak bertanggungjawab.

Terangkan reka bentuk (jika anda boleh)

Seperti teks, sukar untuk menghasilkan kriteria objektif untuk menilai reka bentuk. Jika anda dan pelanggan telah bersetuju dengan skema warna, tuliskannya. Jika dia mempunyai buku jenama di mana fonnya dinyatakan, nyatakan juga.

Tidak perlu menulis tentang reka bentuk yang cantik dan moden. Ia tidak bermakna apa-apa, tidak mempunyai kuasa dan secara amnya ugh.

Daripada kesimpulan: struktur terma rujukan

Struktur spesifikasi teknikal akan berbeza untuk tugasan yang berbeza. Adalah bodoh untuk membuat spesifikasi teknikal yang sama untuk rangkaian sosial baharu dan halaman pendaratan untuk penjualan borong lobak merah. Tetapi secara umum anda memerlukan bahagian ini:

• Maklumat tentang syarikat dan khalayak sasaran, matlamat dan objektif tapak.
• Glosari istilah yang mungkin tidak jelas kepada pelanggan.
• Keperluan teknikal untuk susun atur dan operasi tapak.
• Penerangan tentang teknologi yang digunakan dan senarai keperluan pengehosan.
• Struktur tapak terperinci.
• Prototaip halaman atau perihalan elemen yang sepatutnya ada padanya.
• Senario untuk menggunakan antara muka bukan standard (pilihan).
• Senarai kandungan yang dibuat oleh pembangun.
• Keperluan reka bentuk (pilihan).

• Peraturan untuk menyusun Spesifikasi Keperluan Perisian. SRS ialah langkah seterusnya dalam evolusi spesifikasi teknikal. Diperlukan untuk projek besar dan kompleks.
• Piawaian dan templat spesifikasi teknikal untuk pembangunan perisian. Penerangan pelbagai GOST dan metodologi untuk mencipta spesifikasi teknikal.

Ini adalah penghujung bahagian yang saya tulis. Tetapi ada satu lagi - komen daripada pakar yang membantu membuat panduan. Bacalah, menarik juga.

Komen Pembangun

Saya bercakap dengan beberapa pembangun untuk mengetahui cara mereka mencipta spesifikasi teknikal. Saya menyampaikan mikrofon kepada mereka.

Pertama sekali, pelanggan memerlukan spesifikasi teknikal - supaya dia memahami seperti apa laman webnya dan wang itu akan dibelanjakan. Jika ada kesilapan, dia boleh merujuk kepada spesifikasi teknikal dan meminta ia dibuat semula.

Spesifikasi teknikal disediakan oleh pengurus projek selepas berkomunikasi dengan pelanggan dan membincangkan tugas dengan pereka bentuk.

Pelanggan besar sering meminta spesifikasi teknikal yang sangat terperinci, yang menerangkan setiap butang. Syarikat kecil, sebaliknya, tidak suka dokumen 100 muka surat yang teliti. Ia adalah bacaan yang panjang dan mudah terlepas sesuatu yang penting. Lebih kerap kami membuat spesifikasi teknikal yang ringkas sebanyak 10–15 halaman.

Kami menunjukkan:

• Maklumat tentang syarikat dan tujuan tapak.
• Keperluan untuk reka bentuk, skema warna.
• Teknologi dan CMS yang digunakan.
• Siapa yang menghasilkan kandungan - kami atau pelanggan.
• Struktur tapak turun ke setiap halaman.
• Penerangan setiap halaman. Kami tidak membuat prototaip, tetapi kami menentukan elemen yang perlu ada pada halaman dan cara ia berfungsi.

2 bahagian terakhir adalah yang paling penting. Mereka adalah orang yang memberikan pemahaman tentang bagaimana laman web itu akan menjadi dan bagaimana ia akan berfungsi.

Perkara yang sangat penting - anda tidak boleh hanya memberikan terma rujukan kepada pembangun dan berharap mereka akan melakukan semuanya dengan baik. Spesifikasi teknikal ialah senarai keperluan untuk tapak; ia tidak boleh menggantikan komunikasi. Adalah penting untuk memastikan bahawa setiap ahli pasukan memahami matlamat keseluruhan dan bukan hanya melakukan tugasan dengan cepat. Jika ada yang kurang jelas, perlu diterangkan, dibincangkan dan diberikan ulasan yang terperinci.