Pengembangan spesifikasi teknis sesuai dengan GOST 34 sederhana dan mudah

Seringkali Anda mendengar pendapat bahwa persiapan Kerangka Acuan sesuai dengan GOST 34 (TK) tidak hanya melelahkan, tetapi juga sangat menjengkelkan, karena Anda harus menulis banyak jenis omong kosong, air. Tetapi pikirkanlah: seluruh lembaga penelitian terlibat dalam pengembangan GOST ini, itu adalah proyek di tingkat negara bagian, pengalaman ratusan proyek otomasi, proyek-proyek kompleks dirangkum. Bisakah mereka benar-benar menulis omong kosong?

Bahkan, dengan pendekatan yang kompeten, GOST sangat membantu tidak hanya dalam pengembangan spesifikasi teknis, tetapi juga selama implementasi proyek otomasi secara keseluruhan (dan tidak hanya dalam kontrak negara, tetapi juga untuk pengembangan komersial). Orang yang melek menulisnya. Tetapi untuk memanfaatkan hasil kerja mereka, orang perlu memahami sedikit konsep tidak hanya TK, tetapi juga GOST 34 secara keseluruhan.

Pada artikel ini, kami akan menganalisis poin demi poin semua persyaratan GOST dan mencoba membuat pengembangan TK menurut GOST 34 bukan beban, tetapi bantuan besar dalam proyek.

1. Tentang artikel apa?

Seringkali Anda mendengar pendapat bahwa penyusunan Kerangka Acuan sesuai dengan GOST 34 (TK) tidak hanya melelahkan, tetapi juga sangat menjengkelkan, karena Anda harus menulis banyak jenis omong kosong, air. Tapi pikirkanlah: seluruh lembaga penelitian terlibat dalam pengembangan GOST ini, itu adalah proyek di tingkat negara bagian, pengalaman ratusan proyek otomasi, proyek kompleks digeneralisasikan. Bisakah mereka benar-benar menulis omong kosong?

Bahkan, dengan pendekatan yang kompeten, GOST sangat membantu tidak hanya dalam pengembangan spesifikasi teknis, tetapi selama implementasi proyek otomasi secara keseluruhan (dan tidak hanya dalam kontrak negara, tetapi juga untuk pengembangan komersial). Orang yang melek menulisnya. Tetapi untuk memanfaatkan hasil kerja mereka, orang perlu memahami sedikit konsep tidak hanya TK, tetapi juga GOST 34 secara keseluruhan.

Omong-omong, TK bukan dokumen pertama yang sedang dikembangkan selama proyek otomatisasi. Ini secara tegas dinyatakan dalam paragraf 1.5. GOST 34.602-89: "TK di PLTN dikembangkan berdasarkan data awal, termasuk yang terkandung dalam dokumentasi akhir dari tahap" Penelitian dan justifikasi penciptaan PLTN "." Untuk lebih jelasnya, lihat artikel saya Pra-desain survei selama pengembangan sistem informasi .

PERHATIAN: TUJUAN PASAL INI TIDAK UNTUK MENGGANTI GOST, DAN MENJELASKAN BEBERAPA KETENTUANNYA.

2. Fitur karakteristik dari spesifikasi teknis sesuai dengan GOST 34

2.1. Dengan standar apa ToR dikompilasi?

Nama lengkap standar untuk TK menurut GOST 34 adalah sebagai berikut: GOST 34.602-89 “Teknologi Informasi (TI). Seperangkat standar untuk sistem otomatis. Kerangka acuan untuk pembuatan sistem otomatis. "

Standar itu sendiri dicetak hanya pada 15 halaman (ya, sedikit). Bahasanya adalah bahasa Rusia, benar-benar Rusia, dan tidak asing dengan alfabet Cyrillic. Artinya, jika Anda tidak mengarahkan ke kepala Anda di muka bahwa baik teks GOST, atau hukum federal, atau disertasi tidak dapat diakses untuk memahami manusia biasa, maka sangat mungkin untuk membaca dan menembus, walaupun seringkali bukan pertama kalinya.

Memang, standar tersebut menggunakan banyak istilah yang tidak jelas. Apa, misalnya, yang dimaksud dengan dukungan linguistik? Untuk memperjelas konsep yang digunakan, seseorang harus beralih ke GOST 34.003-90 “Teknologi Informasi (TI). Seperangkat standar untuk sistem otomatis. Sistem otomatis. Ketentuan dan definisi. "

2.2. Mengapa Anda membutuhkan GOST untuk Ketentuan Referensi?

Mungkin, ketika Anda perlu membuat beberapa dokumen baru untuk Anda, Anda mencari templat untuk dokumen semacam itu di Internet atau memintanya dari kolega. Jadi, SETIAP standar untuk dokumen atau proses adalah templat. Selain itu, templat sangat menyederhanakan pengembangan dokumen: struktur dan konten telah dipikirkan untuk Anda, di samping itu, templat tersebut memperhitungkan momen-momen yang tidak akan Anda ingat.

2.3. Apa peran yang dimainkan oleh Ketentuan Referensi dalam proyek?

Menurut paragraf 1.7 dari standar RD 50-682-89, "kerangka acuan adalah dokumen utama sesuai dengan mana penciptaan AU dan penerimaan oleh pelanggan dilakukan." Dan ini benar-benar dokumen utama. Ini harus menggambarkan semua yang diperlukan untuk pengembangan dan implementasi sistem.

TOR menetapkan tampilan keseluruhan sistem, jumlah pekerjaan (kerangka kerja pengembangan), serta prosedur pengembangan dan penerimaan. Semuanya dimulai dengan TK dan semuanya berakhir dengan itu. Dokumen ini sangat ideal bagi pelanggan Anda untuk memahami pentingnya dan kompleksitas tugas dan mengapa ia membayar uang.

Selain itu, spesifikasi teknis dikompilasi untuk kontraktor dan pelanggan, karena proyek otomasi dilakukan oleh tim dari kedua belah pihak. Dalam setiap proyek TI, ada sejumlah besar kegiatan organisasi, yang pelaksanaannya tidak mungkin dilakukan tanpa partisipasi aktif dari pelanggan. Jelaskan ini kepada pelanggan di setiap kesempatan, jika tidak mereka memiliki kesan bahwa mereka hanya perlu membayar uang dan duduk tegak: orang-orang yang disewa akan melakukan segalanya. Dan kemudian proyek gagal dan pertikaian dimulai. Secara umum, tanpa tim nyata, di sisi lain, tidak ada gunanya memulai proyek.

Jangan merumuskan TK secara formal. Jika Anda tidak tahu apa yang harus ditulis, itu artinya masih terlalu dini untuk mengembangkan TK, Anda tidak memiliki pemahaman tentang sistem, proses otomatis itu sendiri, objek otomasi, belum dipahami. Anda harus menyusun konsep sistem , kami membicarakan hal ini di awal artikel.

2.4. Berapa umur GOST 34.602-89 dan apakah ada standar yang lebih baru?

Tidak ketinggalan jaman. Saya hampir tidak dapat menemukan hal-hal non-inti. Dan tidak satu pun dari mereka yang mengklaim bahwa GOST 34 sudah usang tidak dapat memberikan contoh tunggal (mungkin hanya tidak memiliki kualifikasi untuk membacanya?) Faktanya adalah bahwa GOST menggambarkan pendekatan umum untuk proyek otomasi, ia tidak berbicara tentang pemrograman, GOST 34 bukan tentang itu.

Nah, jika kita berbicara tentang perbandingan dengan standar lain, maka tidak ada yang istimewa untuk dibandingkan. GOST 34 memberikan pandangan luas tentang proyek otomatisasi sehingga standar lain tidak cocok untuk outsole (menurut saya). Ya, mereka lebih sederhana (karena itu, lebih populer), tetapi kedalamannya tidak sama. Berikut adalah daftar standar yang harus Anda ketahui ketika mengembangkan standar Anda sendiri untuk proyek otomatisasi:

• IEEE 830-1998. Metodologi untuk menyusun spesifikasi untuk persyaratan perangkat lunak.
• GOST R ISO / IEC 12207-2010. Teknologi informasi. Rekayasa sistem dan perangkat lunak. Proses siklus hidup perangkat lunak.
• ISO / IEC / IEEE 29148-2011. Rekayasa sistem dan perangkat lunak - Proses siklus hidup - Rekayasa persyaratan.
• GOST R 54869-2011. Manajemen proyek. Persyaratan manajemen proyek.
• Baik dan nyatakan spesifikasi standar 34 seri.

3. Prinsip-prinsip umum untuk persiapan spesifikasi teknis sesuai dengan GOST 34

3.1. Spesialis mana yang harus menyusun Kerangka Acuan sesuai dengan GOST 34?

Seringkali, pengembang bersumpah banyak saat menyusun TK sesuai dengan GOST 34. Mengapa? Ya, karena itu bukan urusan programmer. Kerangka acuan sesuai dengan GOST 34 umumnya tidak dapat ditampilkan kepada programmer. Ada dokumen proyek teknis untuk ini. Kerangka Acuan - dokumen yang disetujui oleh pelanggan, yang selalu ada di meja manajer proyek. TK menjawab dua pertanyaan: APA yang harus dilakukan sistem dan BAGAIMANA seharusnya dibuat. Proyek teknis menjawab pertanyaan: BAGAIMANA persyaratan ToR harus dipenuhi. Sebagai contoh, di TK Anda menentukan bahwa harus ada otorisasi dengan login dan kata sandi, dan di TP memberikan tata letak antarmuka, skrip, struktur database. Mengapa ada pembagian ke dalam tahapan yang berbeda dan mengapa Anda tidak harus segera melakukan tugas untuk programmer, lihat di artikel saya Rahasia sukses desain IP (sistem informasi) pada contoh pembangunan rumah sakit dan survei pra-desain ketika mengembangkan sistem informasi .

Kerangka acuan harus dibuat oleh seorang analis bisnis, karena ia adalah "penerjemah" antara pelanggan dan tim pengembangan. Tugas seorang analis bisnis adalah memahami apa yang dibutuhkan pelanggan dan mengungkapkannya dengan cara yang jelas bagi tim. Dan mengungkapkannya dalam bentuk spesifikasi teknis. Selain itu, seorang analis bisnis diharuskan tidak hanya mendengarkan pelanggan dan karyawannya, tetapi untuk mengetahui apa yang tidak mereka katakan (dan ini biasanya lebih dari 50%). Oleh karena itu, analis harus memiliki pengetahuan yang baik tentang proses yang diotomatisasi dan, karena pengetahuannya, mengisi kekosongan yang tersisa pada hasil survei.

3.2. Sisi mana yang harus menjadi Kerangka Acuan?

Pada dasarnya, Kerangka Acuan ini disusun oleh kontraktor? Mengapa

Bukan hanya karena sangat dianjurkan dalam Lampiran 1 hingga GOST 34-602-89. Bahkan, pelanggan, sebagai suatu peraturan, tidak memiliki spesialis yang sesuai. Tetapi TK perlu dikembangkan dan disetujui oleh pelanggan. Dan di sini perlu untuk memastikan bahwa perjanjian itu tidak formal. Saya selalu berusaha menegaskan bahwa kami, bersama pelanggan, menganalisis setiap item secara terperinci. Tujuan Anda adalah untuk melibatkan pelanggan dalam proyek. Kalau tidak, ia tidak akan membentuk harapannya terhadap sistem, yang berarti bahwa, pertama, ia akan tidak puas dengan hasil apa pun, dan, kedua, ia tidak akan dapat melakukan langkah-langkah organisasi yang diperlukan.

3.3. Seberapa jauh Anda bisa pergi dari GOST 34?

Template apa pun juga memiliki kelemahan yang signifikan - ini adalah template. Artinya, langkah ke kanan dan kiri adalah ukuran perlindungan sosial tertinggi (seperti hukuman mati disebut sebelumnya).

Sebenarnya tidak demikian. Setiap standar proses (yaitu, standar bukan untuk sosis, tetapi untuk beberapa aktivitas) hanya memberikan indikasi umum, garis besar. Itu diciptakan untuk membantu tidak melupakan sesuatu yang penting, untuk memberikan pengalaman generasi kepada Anda, dan tidak untuk mengarahkan Anda di belakang bendera.

Tidak percaya Kemudian bacalah klausa 2.2 dari GOST 34.602-89 (omong-omong, angka-angka setelah tanda hubung adalah tahun penerbitan standar atau edisi): “Bergantung pada jenis, tujuan, fitur spesifik dari objek otomatisasi dan kondisi fungsi sistem, diperbolehkan untuk membuat bagian-bagian TK dalam bentuk aplikasi, memperkenalkan tambahan, mengecualikan atau menggabungkan subbagian TK. ” Juga dalam paragraf 1.2. RD 34.698-90 menyatakan: “Isi dokumen adalah umum untuk semua jenis AS dan, jika perlu, dapat dilengkapi oleh pengembang dokumen tergantung pada fitur-fitur AS yang dibuat. Diperbolehkan untuk memasukkan bagian dan informasi tambahan dalam dokumen, untuk menggabungkan dan mengecualikan bagian. "

Secara umum, jika Anda hanya dapat mengutip frasa umum, untuk semuanya baik, melawan semuanya buruk, jangan menulis apa pun. Kalau tidak, spesialis yang membaca dokumen, setelah memenuhi bagian-bagian itu, akan berhenti menganggap serius dokumen itu, dan poin-poin penting akan terlewatkan. Jangan membuat membaca dokumen sebagai siksaan!

3.4. Mengapa TK menurut GOST 34 menggambarkan begitu banyak persyaratan yang tidak terkait langsung dengan fungsi sistem?

Memang, dalam TOR 30 halaman, hanya 7-10 halaman yang dapat dikhususkan untuk fungsi. Ini punya penjelasan. Faktanya adalah bahwa pengembang GOST 34 memandang proyek otomasi dengan cara yang sama sekali berbeda dari yang kami lakukan. Dan mereka terlihat lebih benar, lebih komprehensif.

Pertama , pada paruh pertama TK, informasi umum tentang sistem dan persyaratan umum tidak hanya disajikan. Kita perlu memahami mengapa sistem dibuat, proses apa yang diotomatiskan, apa yang perlu dilakukan agar sistem bekerja, sistem seperti apa yang dimiliki sistem. Tampaknya hal-hal yang biasa, tetapi tanpa mereka, anggota tim akan berbeda memahami tujuan pekerjaan dan sarana untuk mencapai tujuan. Sangat penting bagi kami untuk memastikan bahwa semua peserta disetel ke gelombang yang sama, dan tidak seperti angsa, kanker, dan tombak.

Kedua , kompiler GOST 34 melihat sistem terutama sebagai manusia, dan kemudian sebagai kompleks perangkat keras-perangkat lunak. Inilah cara GOST 34.003-90 mendefinisikan sistem otomatis: "Suatu sistem yang terdiri dari personel dan seperangkat alat otomasi untuk aktivitasnya yang mengimplementasikan teknologi informasi untuk melakukan fungsi yang telah ditetapkan." Dengan demikian, sistem informasi adalah personel yang terlatih, kompleks perangkat lunak dan perangkat keras, semuanya. Memang, mengambil komputer dari akuntan, mereka sulit, tetapi akan dapat melakukan pekerjaan mereka, meskipun dengan registrasi kertas. Tetapi 1C tidak akan bekerja secara independen tanpa seorang akuntan. Karenanya banyak bagian TK tentang langkah-langkah organisasi. Seperti yang mereka katakan, sistem IT adalah 20% IT, sisanya adalah ukuran organisasi. Artinya, TK adalah dokumen yang menjabarkan segala yang diperlukan untuk implementasi sistem, dari A hingga Z.

Ketiga , perhatikan nama GOST 34.602-89: "Kerangka Acuan untuk pembuatan sistem otomatis." TK bukan untuk sistem, tetapi untuk penciptaan sistem. Apa bedanya? Perbedaannya adalah bahwa Kerangka Acuan menetapkan tidak hanya persyaratan untuk sistem itu sendiri, tetapi juga mengatur proses penciptaannya, yaitu, dokumen tersebut memuat persyaratan untuk semua tindakan organisasi, yang diperlukan untuk mencapai hasil. Memang, selama implementasi proyek otomasi, seringkali perlu untuk merestrukturisasi sejumlah proses, melatih personil, dan menyiapkan perangkat keras.

Keempat , Kerangka Acuan adalah dokumen yang dapat Anda gunakan untuk menandai: sudahkah kami memperhitungkan persyaratan ini atau tidak. Mungkin Anda menempatkan 10 ticks secara otomatis, karena ini akan menjadi solusi standar. Tetapi tanda centang nomor 11 akan mengungkapkan masalah yang sangat besar, dan jika Anda melewatkan masalah ini sekarang, itu akan muncul di suatu tempat dalam proses implementasi, ketika semua tenggat waktu dan anggaran telah ditentukan.

Kelima , seperti yang kami katakan di atas, subbagian yang tidak perlu dapat dikecualikan, ini diizinkan. Misalnya, jika Anda tahu pasti bahwa tidak ada yang dapat dipatenkan dalam desain Anda, lalu mengapa membawa persyaratan kemurnian paten? Ini tidak terjadi ketika tidak ada air dan tidak ada syud tanpa air.

3.5. Mengapa bagian yang berbeda mengatakan hal yang sama?

Memang, di TK ada sub-bagian yang sebagian besar mengulangi konten sub-sub bagian lainnya. Misalnya, ada persyaratan untuk dukungan organisasi dan untuk jumlah dan kualifikasi personel. Dalam kedua paragraf kita berbicara tentang staf.Tetapi dalam kasus pertama, kami memberikan informasi tentang struktur organisasi: departemen apa yang seharusnya, bagaimana interaksi dengan departemen lain harus dibentuk. Setuju, ini sama sekali tidak sama dengan persyaratan untuk jumlah dan kualifikasi personel.

Tetapi untuk sistem kecil, hanya satu atau dua administrator dan beberapa moderator yang diperlukan. Dalam hal ini, kami tidak memiliki apa pun untuk dijelaskan dalam dua bagian. Kemudian hilangkan beberapa bagian, dan di bagian lain, berikan pernyataan persyaratan lengkap.

3.6. Apakah saya perlu menerbitkan TK dengan cara yang berkualitas?

Meskipun persyaratan untuk desain TK diberikan dalam paragraf 3 dari GOST 34.602-89, mari kita katakan beberapa kata tentang aspek ini.

Tentu saja konten utamanya. Tapi, pertama, mereka disambut oleh pakaian, dan kedua, sulit untuk membaca teks yang buta huruf dengan skipping font. Pembaca akan terganggu oleh desain berkualitas rendah dan akan lebih sulit bagi mereka untuk mempelajari isinya. Oleh karena itu, konten teknis yang ketat dan terminologi terbatas diterima dalam dokumen teknis, tanpa ekspresi warna-warni: pembaca harus fokus pada esensi, dan bukan pada perubahan artistik.

Berikut adalah beberapa saran untuk pelaksanaan dokumen besar, seperti TK.

Pertama, sangat penting untuk menggunakan gaya dalam dokumen besar, dan kecuali untuk menggarisbawahi atau menyoroti dalam paragraf, jangan mengubah font dan pengaturan paragraf hanya untuk satu fragmen. Jika Anda berubah, maka gaya.

Kedua , kita tidak boleh lupa tentang unsur-unsur wajib seperti daftar isi autocomplete, daftar istilah dan singkatan (yah, tidak ada sukacita dalam menebak apa artinya ini dengan satu atau lain singkatan), halaman judul. Dianjurkan juga untuk memberikan daftar versi dokumen, daftar perubahan: sangat mudah untuk melacak nanti tanggal berapa versi tertentu dikirim.

Keempat, setiap persyaratan individu harus ditetapkan dalam paragraf nomor terpisah. Jika ada 2-3 persyaratan dalam satu fragmen, maka hanya yang pertama dibaca, dan otak kita melewatkan sisanya. TK adalah dokumen di mana, di depan setiap paragraf, Anda dapat memeriksa apakah persyaratannya dipenuhi atau tidak.

Kelima , jangan berhemat pada penempatan tautan. Terkadang Anda membaca paragraf di mana beberapa fungsi atau persyaratan disebutkan, dan Anda tidak mengerti, ini dari dokumen yang sama atau dari yang lain. Jika dari sini, maka di bagian mana. Oleh karena itu, cobalah merujuk ke bagian lain jika disebutkan dalam teks saat ini. Secara alami, tautan harus otomatis.

Perhatikan bahwa, menurut aturan ketat, pernyataan kerja dibuat tanpa bingkai (ini dinyatakan dalam paragraf 3), tetapi sisa dokumen dengan bingkai. Ini ditetapkan dalam GOST 24.301-80 “Sistem dokumentasi teknis untuk ACS. Persyaratan umum untuk implementasi dokumen teks (sebagaimana Diubah No. 1, 2). " Standar ini menetapkan aturan untuk pelaksanaan semua dokumen, kecuali untuk TK dan dokumen yang dibuat pada tahap pra-desain. Meskipun saya pribadi tidak suka bingkai dalam dokumen apa pun.

4. Bagian 1. "Informasi umum" / hal. 2.3 GOST 34.602-89 /

Sebagian besar informasi yang disajikan dalam bagian ini tidak perlu dikomentari, jadi kami hanya akan fokus pada beberapa subbagian.

Jadi, dengan "daftar dokumen yang menjadi dasar sistem dibuat", yang kami maksudkan adalah undang-undang, perintah, atau perjanjian. Juga, dokumen semacam itu mungkin TK lain, jika kita mengembangkan TK untuk subsistem. Secara umum, ada beberapa bagian dalam Kerangka Acuan yang berisi daftar dokumen, dan orang harus sangat memahami perbedaan antara tujuan dari bagian-bagian tugas teknis ini.

Dalam ayat "Prosedur untuk memproses dan menyajikan kepada pelanggan hasil pekerjaan pada penciptaan sistem (bagian-bagiannya), pada pembuatan dan commissioning alat individu (perangkat keras, perangkat lunak, informasi) dan kompleks perangkat lunak dan perangkat keras (perangkat lunak dan metodologi)" memberikan informasi umum tentang penerimaan pekerjaan. Misalnya, fakta bahwa kami mentransfer dokumentasi dan melakukan serangkaian pengujian sistem. Di sini kami hanya menyebutkan prosedur untuk mentransfer hasil pekerjaan, dan di bawah ini, di bagian lain, topik ini diungkapkan secara rinci.

5. Bagian 2. "Maksud dan tujuan menciptakan (mengembangkan) sistem" / hal. 2.4 GOST 34.602-89 /

Di sini kita perlu memahami perbedaan antara maksud dan tujuan pembuatan sistem. Sangat sering, konsep-konsep ini membingungkan. Misalnya, mereka menulis bahwa tujuan sistem adalah otomatisasi akun pribadi Anda, dan tujuannya adalah untuk membuat akun pribadi. Minyak adalah minyak. Dalam beberapa kasus, konsep-konsep ini benar-benar bersamaan, kemudian hanya menulis janji temu.

Dengan tujuan, semuanya jelas: kami memberikan jenis aktivitas otomatis. Misalnya, jika kita membuat sistem untuk akuntansi produksi, maka ada baiknya mengutip jenis akuntansi otomatis, operasi otomatis, serta objek yang otomatisasi seharusnya.

Dengan tujuan, semuanya berbeda. Tujuannya adalah untuk apa kami merencanakan proyek. Anda dapat menyebutnya sebagai tujuan bisnis. Saya menyoroti kemungkinan sasaran berikut untuk proyek otomatisasi:

1. ( , ..)
2. (, -, , ).
3. ( , , ).
4. : , .
5. , . , , «», .

GOST juga mengatakan bahwa perlu memberikan kriteria untuk menilai pencapaian tujuan, yaitu, indikator spesifik. Misalnya, kami memiliki 3 orang mengumpulkan total 20 pesanan per hari. Dan setelah implementasi sistem, kami ingin semua orang mengumpulkan 20 pesanan, yaitu tiga kali lebih banyak. Jika indikator tersebut diketahui di sana, kami sajikan dalam paragraf ini.

6. Bagian 3. "Karakteristik objek otomatisasi" / hal. 2.5 GOST 34.602-89 /

Bagian yang sangat penting, dan seringkali sering dijelaskan secara formal. Meskipun, menurut pendapat saya, ini adalah bagian terpenting dari TK, tanpanya kita tidak akan mengerti tentang sistem apa yang sedang dibuat.

Pertama-tama mari kita mendefinisikan apa "objek otomatisasi". Jika kita mengotomatiskan gudang atau pabrik, departemen akuntansi, maka semuanya jelas. Dan jika, misalnya, kita membuat jejaring sosial baru, maka objeknya, seolah-olah, tidak ada. Tetapi pada kenyataannya, suatu objek lebih cenderung berarti proses otomatis. Dan bahkan dalam kasus gudang, kami tidak mengotomatiskan gudang itu sendiri (bagaimana cara penyimpanan kotak otomatis?), Tetapi proses gudang.

Jika Anda melakukan bagian ini secara formal, itu akan sangat mirip dengan deskripsi tujuan sistem, dan danau air lainnya akan muncul di TOR, tetapi tidak akan jelas apa yang harus dilakukan sistem.

Bagian ini harus mencakup:

1. Deskripsi pelanggan: kegiatan pelanggan, jumlah cabang, karyawan. Tentu saja, Anda perlu mengkarakterisasi pelanggan di bagian yang secara langsung berkaitan dengan sistem yang sedang dibuat.
2. Informasi tentang pengguna sistem: jenis pengguna, peran apa yang dimainkan sistem untuk pengguna yang berbeda.
3. Deskripsi objek otomatis. Misalnya, jika kita mengotomatisasi gudang, kita harus menjelaskan berapa jumlahnya, berapa banyak jalan setapak, berapa lebar jalan setapak, rak apa, apakah ada area perakitan terpisah, berapa banyak orang yang bekerja dan apa tanggung jawab yang mereka miliki. Kemudian kita akan memahami bahwa kita secara khusus mengotomatisasikan seperti apa proses pergudangan dan peralatan apa yang digunakan.
4. Deskripsi proses otomatis. Tentu saja, tidak perlu menjelaskan proses secara rinci dalam TK. Tapi skenario umum diperlukan. Baru setelah itu menjadi jelas bagi kami fungsi apa yang harus tersedia.
5. Daftar dokumen yang memberikan deskripsi terperinci tentang objek otomatisasi.

Saya memiliki kasus ketika deskripsi bagian ini membutuhkan lebih dari setengah pengembangan TK, karena butuh waktu lama dan dengan cermat untuk mengumpulkan informasi yang berbeda, menganalisisnya, dan dengan hati-hati menggambarkannya.

7. Bagian 4 “Persyaratan Sistem”

Di TK menurut GOST 34 ada satu bagian raksasa: bagian 4 “Persyaratan sistem”. Ini memiliki tiga subbagian:

• Persyaratan untuk sistem secara keseluruhan.
• Persyaratan untuk fungsi (tugas) yang dilakukan oleh sistem.
• Persyaratan untuk jenis agunan.

Kami akan mempertimbangkan subbagian ini secara terpisah.

7.1. Subbab 4.1. "Persyaratan untuk sistem secara keseluruhan" / hal. 2.6.1 GOST 34.602-89 /

Dalam ayat 4.1 "Persyaratan untuk sistem secara keseluruhan", persyaratan yang disebut non-fungsional, umum dijelaskan yang menggambarkan sistem yang dibuat dari sudut yang berbeda.

By the way, seperti yang telah kami sebutkan, subbagian dapat ditambahkan dan dihilangkan. Oleh karena itu, penomoran yang diberikan di sini adalah perkiraan, berfungsi untuk orientasi dalam artikel.

7.1.1. Klausul 4.1.1. "Persyaratan untuk struktur dan fungsi sistem" / hal. 2.6.1.1 GOST 34.602-89 /

Item ini cukup luas, harus memberikan gambaran umum tentang arsitektur sistem. Kami akan menganalisis persyaratan ini secara lebih rinci.

1. Daftar subsistem, tujuan dan karakteristik utamanya, persyaratan untuk jumlah tingkat hierarki dan tingkat sentralisasi sistem.

Dalam paragraf ini, saya biasanya mengutip:

• ( , , , -, , , ) , ( , SMTP, SMS-, -, -, , , ..);
• .

Jika Anda merencanakan arsitektur layanan mikro, maka masuk akal untuk membuat daftar dan menjelaskan fungsionalitas layanan.

Untuk kejelasan, diinginkan untuk melampirkan diagram struktural sistem dengan penunjukan bagian-bagiannya dan sistem terkait, seperti yang ditunjukkan dalam contoh di bawah ini.



... atau lebih:



2. Persyaratan untuk metode komunikasi dan sarana untuk pertukaran informasi antara komponen sistem.

3. Persyaratan untuk karakteristik hubungan sistem yang dibuat dengan sistem terkait, persyaratan untuk kompatibilitasnya, termasuk petunjuk tentang cara bertukar informasi (secara otomatis, mengirim dokumen, melalui telepon, dll.)

Dalam kondisi modern, sebagian besar interaksi dilakukan menggunakan protokol HTTP (S). Sepertinya, selain ini, tidak ada yang bisa ditulis. Namun, barang-barang ini bisa sangat besar sehingga dikirimkan ke aplikasi. Mereka harus memberikan informasi berikut:

• daftar informasi yang ditransmisikan, setidaknya deskripsi umum, untuk secara umum memahami mengapa kami berintegrasi dengan sistem tertentu;
• deskripsi protokol (atau tautan deskripsi), terutama dalam hal lampiran perangkat;
• struktur jaringan lokal;
• kecepatan data yang dibutuhkan;
• penggunaan Internet seluler atau WiFi;
• Deskripsi metode transmisi data non-otomatis.

4. Persyaratan untuk mode operasi sistem.
Mode operasi dapat memiliki beberapa klasifikasi:

• : , , (, , , API, );
• : , , , ;
• : 24/7 ( );
• : ;
• : , , ( );
• : -, , (, , );
• : ( ), , (, , , );
• : , « »;
• Visibilitas Aplikasi: Dialog atau Latar Belakang
• tentang kemungkinan dampak pada sistem: reguler, pelatihan, mode uji.

5. Persyaratan untuk mendiagnosis sistem.

Persyaratan untuk diagnosis berkelanjutan atau berkala harus dibuat untuk sistem yang didasarkan pada arsitektur microservice (spasi), sistem yang mencakup peralatan: sensor, sistem kontrol, terminal, dll. Tentu saja, jika hanya perangkat lunak yang dikembangkan yang berjalan pada satu server, persyaratan ini berlebihan: Anda akan mengetahui apakah sesuatu berhenti berfungsi.

6. Prospek untuk pengembangan, modernisasi sistem.

Tampaknya, apa prospek untuk pengembangan sistem ke ayat "Persyaratan untuk struktur dan fungsi sistem"? Tapi bayangkan, sekarang Anda membuat versi alfa untuk 100 orang, dan dalam setahun Anda ingin mendapatkan lebih dari satu juta pengguna yang bekerja secara bersamaan di berbagai belahan dunia. Kemudian, pada tahap penciptaan, Anda harus segera menyediakan arsitektur cluster.

Atau sekarang Anda bekerja dari satu organisasi, dan dalam enam bulan akan ada beberapa dari mereka, yang berarti bahwa perlu untuk meramalkan kemungkinan ekspansi di muka.

Dengan kata lain, di bagian ini Anda dapat menuliskan semua prospek untuk modernisasi, tetapi terutama perhatikan yang pasti akan mempengaruhi arsitektur.

7.1.2. Klausul 4.1.2. "Persyaratan untuk jumlah dan kualifikasi personel" / hal. 2.6.1.2 GOST 34.602-89 /

Seperti yang kami sebutkan sebelumnya, sistem otomatis apa pun terdiri dari "personel dan seperangkat alat otomasi untuk aktivitasnya". Oleh karena itu, persyaratan untuk personel dan kualifikasinya ditunjukkan dalam TOR.

Jika Anda mengotomatiskan jalur produksi tertentu, maka Anda tahu jumlah staf. Tetapi dalam banyak kasus, itu tergantung pada jumlah pekerjaan yang dilakukan. Oleh karena itu, tunjukkan posisi, jadwal kerja, deskripsi kegiatan (untuk menetapkan hak akses) dan perkiraan kualifikasi. Minimal, Anda memerlukan administrator sistem dan operator, cukup sering dengan moderator. Mungkin saja Anda harus menyediakan beberapa jenis operator dengan berbagai tingkat akses.

Jelas bahwa persyaratan untuk personel sering ditetapkan oleh pelanggan, mengapa kemudian membawanya? Tetapi, pertama, kami telah mengatakan bahwa spesifikasi teknis disiapkan untuk kedua belah pihak, dan kedua, kontraktor akan dilindungi: kondisi pemilihan staf tidak terpenuhi, lalu apa yang diinginkan pelanggan jika sistem tidak diterapkan?

7.1.3. Klausul 4.1.3. "Persyaratan untuk indikator kinerja" / hal. 2.6.1.3 GOST 34.602-89 /

Dalam subbagian ini, sering ditulis sesuai keinginan Anda, karena daftar indikator yang mungkin tidak ada dalam teks GOST, dan hampir tidak mungkin menemukannya di sumber terbuka. Harap dicatat bahwa "tingkat kemampuan beradaptasi", "batas modernisasi" dan "karakteristik probabilitas-waktu" yang diberikan dalam GOST, pertama, diindikasikan untuk ACS (sistem kontrol otomatis) dan, kedua, agak sulit untuk diukur. Jadi, karakteristik ini tidak selalu cocok.

Namun demikian, dalam teks itu sendiri, "indikator penunjukan" didefinisikan sebagai "parameter yang mencirikan tingkat kepatuhan sistem dengan tujuannya". Dalam sistem komputer modern, nilai-nilai kuantitatif yang menjadi ciri sistem ini terutama berkaitan dengan kinerja dan volume penyimpanan data.

Indikator tujuan meliputi:

• jumlah pengguna yang bekerja secara bersamaan dalam sistem;
• jumlah permintaan yang dieksekusi secara bersamaan ke server;
• jumlah transaksi (dicatat) per unit waktu transaksi;
• waktu respons untuk sejumlah permintaan satu kali dan pengguna yang bekerja, untuk jumlah data yang diproses berbeda (terutama ketika mencari dan menggabungkan laporan);
• jumlah data yang disimpan (khususnya, gambar dan video);
• waktu koneksi untuk daya komputasi tambahan saat mencapai beban maksimum;
• waktu koneksi dari kapasitas tambahan dengan peningkatan volume data yang disimpan secara signifikan.

Semua karakteristik ini mempengaruhi pilihan perangkat keras server, server aplikasi dan arsitektur DBMS, DBMS relasional atau non-relasional, layanan mikro, dll.

7.1.4. Klausul 4.1.4. "Persyaratan untuk keandalan" / hal. 2.6.1.4 GOST 34.602-89 /

Teks GOST menjelaskan secara terperinci apa yang perlu ditunjukkan dalam persyaratan keandalan. Namun demikian, untuk memahami pendekatan untuk memastikan keandalan yang melekat dalam standar ini, Anda harus mempelajari GOST dari seri 27. Untuk mulai dengan, Anda harus membiasakan diri dengan terminologi: ini akan cukup untuk memahami konsep keandalan, bagaimana mengukur dan bagaimana disediakan. Oleh karena itu, lihat GOST 27.002-89. “Keandalan dalam teknologi. Konsep dasar. Ketentuan dan definisi. "

Konsep dasar yang dapat diterapkan pada sistem otomatis adalah faktor ketersediaan: 99%, 99,9%, 99,99%. Setiap jumlah "sembilan" disediakan oleh langkah-langkah tertentu.

Solusi teknis apa yang dapat dipengaruhi persyaratan ini? Ini adalah jumlah kapasitas cadangan (bervariasi), dan ketersediaan staf teknis di lapangan, dan penggunaan tidak hanya pasokan listrik yang tidak pernah terputus, tetapi juga generator diesel, serta koneksi dari dua sumber independen (koneksi ke jaringan listrik sesuai dengan kategori keandalan I atau II).

7.1.5. Klausul 4.1.5. "Persyaratan Keamanan" / hal. 2.6.1.5 GOST 34.602-89 /

Subbagian ini menjelaskan persyaratan keselamatan untuk menangani peralatan (instalasi, commissioning, dan operasi). Sekarang persyaratan ini disebut perlindungan tenaga kerja dan tercantum dalam GOST dari seri ke-12 (SSBT - sistem standar keselamatan kerja). Di TK, cukup untuk memberikan daftar bagian-bagian ini, sekali lagi, jika seseorang akan serius terlibat dalam keamanan.

7.1.6. Klausul 4.1.6. "Persyaratan untuk ergonomi dan estetika teknis" / hal. 2.6.1.6 GOST 34.602-89 /

Kami memberikan persyaratan GOST: "Persyaratan untuk ergonomi dan estetika teknis termasuk indikator AC yang menentukan kualitas yang diperlukan dari interaksi manusia dengan mesin dan kenyamanan kondisi kerja staf."

Biasanya dalam paragraf ini tertulis bahwa sistem harus memiliki antarmuka yang nyaman dan indah. Tetapi bagaimana mengukur kenyamanan dan keindahan? Oleh karena itu, kami mengabaikan persyaratan ini, atau kami mengatakan bahwa antarmuka akan sesuai dengan proyek desain yang dikembangkan nanti, atau kami memberikan standar, misalnya, apa yang disebut "pedoman" untuk mengembangkan aplikasi seluler: Desain Bahan untuk Android dan Pedoman Antarmuka Manusia untuk iOS.

Anda juga dapat memberikan jumlah transisi (klik) maksimum ketika menerapkan fungsi tertentu yang sangat penting bagi kami, kecepatan rata-rata pencarian data, dll.

7.1.7. Klausul 4.1.7. "Persyaratan pengangkutan untuk pengeras suara ponsel" / hal. 2.6.1.7 GOST 34.602-89 /

Katakan beberapa persyaratan usang. Sekarang server di truk, seperti komputer besar sebelumnya, tidak membawa. Namun demikian, bayangkan Anda memiliki semacam perlindungan super, sirkuit internal di belakang DMZ dan ... kebutuhan untuk pekerjaan jarak jauh melalui laptop. Ya, VPN dikonfigurasi kapan saja, tetapi lebih baik jika tercermin dalam Panduan Administrasi, dan kemungkinan itu sendiri disediakan oleh konfigurasi jaringan.

7.1.8. Klausul 4.1.8. "Persyaratan untuk operasi, pemeliharaan, perbaikan dan penyimpanan" / hal. 2.6.1.8 GOST 34.602-89 /

Persyaratan ini terkait dengan pemeliharaan kompleks sarana teknis (server, firewall, sakelar, workstation, dll.) Jika peralatan tersebut memerlukan pemeliharaan khusus, perlu dijelaskan di bagian ini. Misalnya, Anda memiliki perangkat khusus yang perlu dikalibrasi sebulan sekali.

7.1.9. Klausul 4.1.9. "Persyaratan untuk perlindungan informasi dari akses tidak sah" / hal. 2.6.1.9 GOST 34.602-89 /

Topik melindungi informasi dari akses tidak sah cukup luas, demikian pula langkah-langkah untuk memastikannya. Tentu saja, jika kita berbicara tentang akses ke akun pribadi situs web dan panel administrasi situs web ini, maka ada cukup persyaratan untuk otorisasi, kompleksitas kata sandi, model akses peran. Tetapi jika sistem keuangan atau sistem diciptakan untuk kebutuhan negara, maka persyaratan khusus akan muncul.

Penting untuk dicatat bahwa dalam ayat ini diberikan tidak hanya langkah-langkah yang perlu diterapkan selama pengembangan sistem, tetapi juga operasinya.

Jadi, untuk sistem keuangan, Anda harus menggunakan "Standar Keamanan Data Industri Kartu Pembayaran" (PCI DSS). Untuk sistem di mana data pribadi disimpan, - Keputusan Pemerintah Federasi Rusia tertanggal 01.11.2012 No. 1119 “Atas persetujuan persyaratan untuk perlindungan data pribadi selama pemrosesan dalam sistem informasi data pribadi”. Mungkin ada standar lain di bidang subjek Anda.

Secara umum, peralatan pelindung dapat dibagi menjadi beberapa tipe berikut:

1. Berarti disediakan oleh produk perangkat lunak yang dibuat.
2. Tindakan yang diberikan oleh administrator sistem.
3. Langkah-langkah perlindungan fisik.
4. Langkah-langkah organisasi umum.
5. Langkah-langkah yang diambil selama proses pengembangan perangkat lunak.

1. Langkah-langkah keamanan yang disediakan oleh produk perangkat lunak yang dibuat:

• Persyaratan kata sandi untuk pengguna, terutama untuk pengguna dengan peran administrator.
• Menerapkan model akses berbasis peran.
• Persyaratan untuk menggunakan kunci tanda tangan elektronik untuk melakukan operasi kritis.
• Menghapus komponen perangkat lunak yang bertanggung jawab untuk berinteraksi dengan sistem eksternal ke DMZ.
• Menyediakan pendaftaran acara dan tindakan pengguna.

2. Tindakan yang diberikan oleh administrator sistem:

• Penggunaan firewall (firewall).
• Mendokumentasikan dan memantau layanan dan protokol yang digunakan.
• Konfigurasi Zona Demiliterisasi (DMZ).
• Memantau implementasi aturan untuk menggunakan komputer laptop: menghubungkan ke jaringan internal, menggunakan firewall.
• Menonaktifkan akun default sebelum menghubungkan peralatan dan sistem ke jaringan.
• Mengkonfigurasi Perangkat Akses Nirkabel: Tetapkan kata sandi dan ubah pengaturan akses default.
• Instal pembaruan yang mengatasi kerentanan perangkat keras dan perangkat lunak yang diidentifikasi.
• Memberikan keamanan untuk akses jarak jauh ke sistem (misalnya, menggunakan VPN).
• Instalasi, pembaruan, dan pemantauan perangkat lunak anti-virus.
• Lakukan pemindaian dan pemindaian jaringan secara berkala setelah melakukan perubahan penting.
• Penugasan akun unik untuk setiap karyawan, pemeriksaan berkala untuk keberadaan akun yang dihapus dari karyawan yang diberhentikan, perubahan kata sandi. Masalah dan akuntansi token tanda tangan elektronik.
• Konfigurasikan pembatasan akses basis data.
• Kontrol sinkronisasi waktu pada semua server dan workstation (untuk memastikan kebenaran waktu yang dicatat dalam log peristiwa).
• Konfigurasikan log peristiwa.
• Inventarisasi berkala titik akses nirkabel dan perangkat lunak yang diinstal peralatan lainnya.

3. Langkah-langkah perlindungan fisik:

• Akses terbatas ke kamar-kamar penting.
• Putuskan koneksi jaringan di tempat-tempat umum.
• Pemasangan kamera CCTV untuk tempat kritis.

4. Langkah-langkah organisasi umum:

• Penerapan kebijakan keamanan dan pelatihan personel secara berkala dalam aturan keamanan informasi.
• Menerapkan prosedur respons insiden keamanan.
• Verifikasi layar atau laporan data rahasia.
• Mengeluarkan lencana untuk semua pengunjung, mengantar pengunjung saat berada di daerah kritis.
• Tinjauan komprehensif karyawan yang direkrut.
• Memberikan keamanan pada bagian dari organisasi-penyedia layanan yang terkait dengan perangkat lunak dan perangkat keras.

5. Langkah-langkah yang diambil selama proses pengembangan perangkat lunak:

• Orang yang bertanggung jawab mengontrol untuk membuat perubahan pada kode program, memeriksa kode untuk kepatuhan dengan aturan keamanan informasi (kontrol buffer overflow, penanganan kesalahan yang benar, memeriksa skrip lintas situs, kesalahan mekanisme akses, dll.)
• Penggunaan kriptografi yang kuat.
• Penerapan aturan keamanan untuk aplikasi web publik.
• Kembangkan prosedur pembatalan untuk setiap perubahan.
• Dokumentasi perubahan.

7.1.10. Klausul 4.1.10. "Persyaratan untuk keamanan informasi jika terjadi kecelakaan" / h. 2.6.1.10 GOST 34.602-89 /

Bagian ini memberikan daftar kemungkinan kecelakaan dan kegagalan di mana keamanan informasi harus dipastikan. Peristiwa semacam itu dapat meliputi:

• kehilangan nutrisi;
• kegagalan server;
• kegagalan perangkat penyimpanan (hard disk).

7.1.11. Klausul 4.1.11. "Persyaratan untuk perlindungan terhadap pengaruh pengaruh eksternal" / hal. 2.6.1.11 GOST 34.602-89 /

Bagian ini akan berguna jika server, workstation dan peralatan lainnya berada di gudang dingin atau, sebaliknya, di tempat industri dengan suhu tinggi, di tempat berdebu atau tempat dengan kelembaban tinggi. Terkadang juga layak untuk mempertimbangkan getaran, radiasi atau pengaruh lainnya.

7.1.12. Subbab 4.1.12. "Persyaratan untuk kemurnian paten" / hal. 2.6.1.12 GOST 34.602-89 /

Jika Anda memiliki kecurigaan bahwa Anda akan menggunakan teknologi yang dipatenkan di negara lain (atau di negara kami) dan pemegang paten dapat mengajukan gugatan terhadap pemilik sistem, paragraf ini menunjukkan daftar negara tempat Anda ingin memeriksa untuk kemurnian paten.

7.1.13. Klausul 4.1.13. "Persyaratan untuk standardisasi dan unifikasi" / hal. 2.6.1.13 GOST 34.602-89 /

Item ini juga jarang terkandung dalam Kerangka Acuan sehubungan dengan perangkat lunak secara khusus. Ini menunjukkan persyaratan untuk penggunaan teknologi tertentu, dan bentuk standar dokumen dan pengklasifikasi.

Deskripsi ini sangat penting jika Anda memiliki persyaratan khusus untuk kerangka kerja yang digunakan, plugin, protokol, perangkat, algoritma matematika, perangkat lunak pihak ketiga, dll. Jangan lupa untuk menunjukkan di bagian mana dan untuk tujuan apa alat ini harus digunakan.

Juga kadang-kadang dalam sistem beberapa kelas biasanya menggunakan protokol pertukaran data tertentu. Misalnya, standar OCG digunakan untuk bertukar data antara sistem informasi geografis, dan OCPP digunakan untuk mengontrol stasiun pengisian daya untuk kendaraan listrik.

7.1.14. Klausul 4.1.14. "Persyaratan tambahan" / hal. 2.6.1.14 GOST 34.602-89 /

Paragraf ini harus ditemukan dalam teks GOST. Dia tidak butuh komentar.

7.2. Subbab 4.2. "Persyaratan untuk fungsi (tugas) yang dilakukan oleh sistem" / hal. 2.6.2 GOST 34.602-89 /

Bagian ini merupakan pusat sistem komputer modern. Sebenarnya, sistem dibuat untuk kinerja fungsi-fungsi tertentu. Seringkali TK, dibuat berdasarkan standar asing dan umumnya tanpa standar, hanya berisi bagian ini.

7.2.1. Struktur Uraian Fungsional

Pertama, kami mempertimbangkan struktur persyaratan fungsional untuk sistem: subsistem - set fungsi - fungsi - tugas. Tugas adalah bagian dari suatu fungsi, dan tugas tersebut dapat digambarkan sebagai fungsi yang terpisah. Misalnya, untuk fungsi login, kami memperkenalkan kata sandi sebagai salah satu tugas. Dan kita dapat menggambarkan prosedur entri kata sandi sebagai fungsi terpisah: verifikasi kebenaran, pemulihan kata sandi, tampilan prompt, dll. Kompleks adalah apa yang menyatukan fungsi. Misalnya, "Akuntansi untuk informasi dasar", "Memegang lelang", dll. Kompleks memiliki dua fungsi atau lebih.

Jika sistem Anda terdiri dari beberapa subsistem, maka pada dasarnya TK harus memberikan daftar fungsi untuk subsistem, dan sudah menjelaskan secara rinci persyaratan fungsional untuk subsistem dalam TK individu untuk subsistem (mereka sering disebut CTZ sekarang - tugas teknis pribadi).

7.2.2. Jenis fungsi dalam hal implementasinya

Bahkan, semua fungsi (atau tugas mereka; beberapa tugas dapat hadir dalam suatu fungsi sekaligus) dapat dibagi menjadi beberapa tipe berikut:

• Memasukkan informasi. Kadang-kadang disebut sebagai "informasi akuntansi."
• Output informasi.
• Pemrosesan informasi secara otomatis.

7.2.3. Jenis fungsi dalam hal perannya

Fungsi dapat bersifat umum dan khusus. Fungsi umum, misalnya, termasuk bekerja dengan daftar objek, bekerja dengan kartu objek, dan bekerja dengan peta interaktif. Fungsi-fungsi ini dapat berlaku untuk semua fungsi khusus atau bagian.

7.2.4. Persyaratan, bukan skrip

Jangan lupa bahwa Kerangka Acuan memuat persyaratan untuk sistem dan proses pembuatannya. Bukan skrip. TK menjawab pertanyaan APA yang harus dilakukan sistem. Untuk pertanyaan BAGAIMANA jawaban desain teknis. Jika Anda mulai mendeskripsikan secara rinci implementasi teknis, maka terjunlah ke detail dan gagal memberikan daftar persyaratan lengkap: otak kita tidak dapat bekerja secara bersamaan dalam mode cakupan luas dan pertimbangan detail.

Struktur fungsi TOR dan proyek teknis dapat sangat berbeda: dalam satu skenario beberapa fungsi dapat diimplementasikan, dan sebaliknya.

7.2.5. Persyaratan fungsional

Berikut adalah beberapa rekomendasi tentang cara menyusun deskripsi fungsi:

1. Persyaratan untuk fungsi dan tugas biasanya harus dibuat untuk aplikasi. Dengan demikian, dokumen tersebut secara organik dibagi menjadi bagian-bagian yang tidak berfungsi dan fungsional. Selain itu, aplikasi selalu dapat dicetak dan dilihat secara terpisah.
2. Hindari paragraf besar. Yang terbaik adalah jika persyaratan dibagi menjadi beberapa paragraf dan sub-paragraf: Lebih mudah untuk melihatnya dan mengendalikan implementasinya (centang kotak). Jika daftar persyaratan atau informasi disediakan, biarkan diberikan oleh daftar bernomor atau berpoin.
3. Untuk fungsi yang tujuannya tidak jelas dari namanya, perlu untuk menunjukkan tujuan dan masalah yang harus dipecahkan. Jika tidak, bahkan kompiler TK berisiko lupa mengapa ia menggambarkan fungsi ini atau itu.

7.2.6. Contoh Deskripsi Fungsi

5.6. Pendaftaran kendaraan di Sistem

Persyaratan berikut disajikan:

1) Sistem harus memungkinkan informasi umum berikut ini diperhitungkan:

• tanda pendaftaran negara (GRNZ);
• Nama pemilik;
• alamat pemilik;
• data dari layanan akuisisi data kendaraan (lihat ayat 3.3, Lampiran B);
• perhatikan.

2) Sistem harus memungkinkan untuk memperhitungkan informasi berikut yang terkait dengan pembayaran ongkos (informasi yang ditentukan bersifat informasi, kemungkinan untuk mengubahnya secara langsung di kartu registrasi kendaraan tidak diperlukan):

• kelas kendaraan saat ini (lihat ayat 3.3, Lampiran A);
• tarif saat ini (lihat klausul 5.1, Lampiran A);
• kontrak saat ini (lihat pasal 5.5, Lampiran A);
• kelas kendaraan menurut informasi dari Kementerian Dalam Negeri Republik Kazakhstan;
• informasi tentang akun pribadi dan kondisinya (lihat pasal 3.6, Lampiran A);
• informasi tentang berada di registrasi kendaraan dengan ongkos yang lebih murah (lihat klausul 3.5, Lampiran A).

3) Sistem harus memungkinkan untuk mendaftar dan mengubah informasi tentang kendaraan dengan cara berikut:

• secara manual oleh operator;
• setelah menerima informasi dari sistem pendaftaran tag RFID (lihat ayat 1.1, Lampiran B);
• saat mengidentifikasi kendaraan menggunakan kamera GRNZ.

4) Saat mendaftarkan kendaraan baru dalam sistem, sistem harus meminta data tentang kendaraan dari layanan untuk menerima data tentang kendaraan (lihat paragraf 3.3, Lampiran B). Seharusnya dimungkinkan untuk memperbarui informasi yang ditentukan dari kendaraan individu.

7.3. Subbab 4.3. "Persyaratan untuk jenis keamanan" / hal. 2.6.3 GOST 34.602-89 /

Bagian persyaratan untuk jenis dukungan umumnya dikutip sebagai contoh kelebihan volume TK menurut GOST. Ketika sampai pada apakah semua bagian dan subbagian harus diberikan, mereka mengingat perangkat lunak, yang dalam banyak kasus tidak ada apa-apa untuk ditulis.

Sebenarnya, ini adalah ayat yang sangat penting, meskipun tidak semua orang mengerti tujuannya. Ini menggambarkan kondisi yang tanpanya mustahil untuk mengimplementasikan pengembangan atau commissioning. Kondisi ini digambarkan sebagai "jaminan".

Ketika membaca subbagian ini, orang bertanya-tanya apa yang dimaksud oleh perancang standar dengan "perangkat lunak", "perangkat lunak linguistik", "perangkat lunak informasi", dll. Jawaban harus dicari dalam GOST 34.003-90, di mana semua istilah ini diuraikan.

7.3.1. Klausul 4.3.1 "Perangkat Lunak" / hal. 2.6.3.1 GOST 34.602-89 /

Bayangkan situasi yang Anda butuhkan untuk membuat sistem di mana Anda ingin menerapkan perhitungan otomatis dari rute optimal. Tombol "Hitung rute" mungkin terlihat sederhana, tetapi algoritma dan perhitungan matematis yang sangat rumit bisa ada di belakangnya. Jelas bahwa tidak layak melakukan pengembangan algoritma seperti itu, ahli matematika profesional terlibat dalam hal ini. Jika algoritma tersebut tersedia, persyaratan untuk pengembangannya atau penggunaan yang sudah jadi juga ditulis.

7.3.2. Klausul 4.3.2 "Dukungan informasi" / hal. 2.6.3.2 GOST 34.602-89 /

Saat membaca deskripsi persyaratan ini dalam teks GOST, tampaknya ini adalah pengulangan dari apa yang telah dikatakan di bagian lain. Sebagai contoh, mengapa lagi menggambarkan persyaratan untuk "komposisi, struktur dan metode pengorganisasian data dalam sistem" dan "untuk pertukaran informasi antara komponen sistem"? Tetapi kita kembali lupa bahwa kompiler GOST di bawah sistem tidak hanya memiliki perangkat lunak, tetapi juga seluruh rangkaian tindakan organisasi.

Ketika memperkenalkan Anda, Anda menghadapi situasi sedemikian rupa sehingga pelanggan, untuk bagiannya, belum menyediakan operator yang akan memasukkan data apa pun ke dalam sistem, dan pada saat yang sama menyatakan bahwa sistem tidak berfungsi. Situasi yang biasa? Tetapi jika persyaratan untuk memberikan input ini dijabarkan dalam laporan kerja, maka akan mungkin untuk langsung menyodok pelanggan pada titik ini. Atau Anda memerlukan akses ke pengklasifikasi alamat tertentu untuk bekerja, tetapi pelanggan tidak memberikannya kepada Anda.

Jadi, dalam paragraf ini masuk akal untuk menentukan persyaratan untuk informasi yang masuk dan informasi yang dikirim dari komponen ke komponen sistem dengan cara yang tidak otomatis. Pemrosesan informasi otomatis, penggunaan DBMS, pertukaran informasi dalam sistem sepenuhnya dijelaskan di bagian lain.

7.3.3. Klausul 4.3.3 "Dukungan bahasa" / h. 2.6.3.3 GOST 34.602-89 /

Paragraf ini menyediakan:

• persyaratan untuk penggunaan bahasa pemrograman (jika ada preferensi spesifik);
• bahasa antarmuka (bahasa apa, antarmuka multibahasa);
• bahasa untuk komunikasi antara tim proyek, persyaratan terjemahan;
• fitur lain input dan output data, jika tersedia: enkripsi, metode interaksi pengguna yang tidak standar dengan sistem.

7.3.4. Klausul 4.3.4 "Perangkat Lunak" / hal. 2.6.3.4 GOST 34.602-89 /

Paragraf ini menyediakan daftar perangkat lunak yang dibeli, jika mereka diidentifikasi pada tahap pengembangan Kerangka Acuan.

7.3.5. Klausul 4.3.5 "Dukungan teknis" / hal. 2.6.3.5 GOST 34.602-89 /

Sistem informasi apa pun tidak dapat berfungsi tanpa perangkat keras, server, jaringan, dll. Menentukan karakteristik spesifik peralatan biasanya disarankan untuk dimasukkan dalam desain teknis, tetapi komposisi perkiraan dapat diberikan dalam laporan kerja sehingga pelanggan memiliki gagasan tentang biaya di masa depan.

7.3.6. Klausul 4.3.6 "Dukungan metrologi" / hal. 2.6.3.6 GOST 34.602-89 /

Jika direncanakan menerima data dari sensor dalam sistem, maka perlu dipahami instrumen pengukuran apa yang akan digunakan, instrumen pengukuran akurasi apa yang harus disediakan, apakah alat ini harus disertifikasi dan disertifikasi.

7.3.7. Klausul 4.3.7 "Dukungan organisasi" / hal. 2.6.3.7 GOST 34.602-89 /

Bayangkan Anda membuat sistem dari awal. Misalnya, ini adalah sistem manajemen gudang untuk kompleks logistik baru. Dengan kata lain, hanya ada tembok. Atau Anda meningkatkan sistem, dan untuk menerapkan perubahan yang Anda butuhkan untuk memodifikasi struktur organisasi. Dalam kasus seperti itu, Anda harus menentukan kondisi mengenai organisasi proses di mana sistem yang disediakan oleh Anda akan benar-benar berfungsi.

7.3.8. Klausul 4.3.8 "Dukungan metodologis" / hal. 2.6.3.8 GOST 34.602-89 /

Terkadang, untuk mengelola sistem, personel dengan kompetensi khusus diperlukan. Dalam hal ini, daftar metode, norma dan standar harus diberikan dalam TOR, yang dengannya karyawan berinteraksi dengan sistem harus dibiasakan.

7.3.9. Jenis jaminan lainnya

Ketika mengembangkan setiap TK baru, Anda harus mempertimbangkan apa yang Anda perlukan untuk commissioning yang sukses. Sebagai contoh, saya sering menuliskan persyaratan untuk dukungan hukum, ketika kerangka hukum yang digunakan tidak sepenuhnya didefinisikan dan pengembangannya dapat mempengaruhi implementasi. Meskipun masalah seperti itu paling baik diselesaikan sebelum menyusun spesifikasi teknis .

8. Bagian 5 "Komposisi dan konten pekerjaan pada penciptaan (pengembangan) sistem" / hal. 2.7 GOST 34.602-89 /

Bagian ini bersifat organisasi dan sering dimasukkan ke dalam kontrak. Namun, informasi dalam ToR ini dapat ditentukan.

Intinya, ini adalah rencana singkat untuk pengembangan dan implementasi. Saat mengompilasinya, saya biasanya memberikan tabel yang mencantumkan semua atau beberapa kolom berikut:

• Nama panggung (sub-stage).
• Konten pekerjaan (deskripsi singkat, daftar tugas).
• Hasil pekerjaan (dokumen yang disetujui, dikembangkan dan diserahkan solusi).
• Desain, dokumentasi kerja atau pelaporan.
• Bertanggung jawab (yang melakukan pekerjaan ini: pelanggan, kontraktor atau orang lain). Jika kedua belah pihak harus memberikan hasil bersama, peran ditunjukkan.
• Durasi (tanggal, tanggal, waktu mulai).

Contoh isi bagian ini diberikan pada tabel di bawah ini.

9. Bagian 6 "Prosedur untuk pemantauan dan penerimaan sistem" / hal. 2.8 GOST 34.602-89 /

Bagian ini menjelaskan secara terperinci proses penerimaan sistem oleh pelanggan: tes apa yang harus dilakukan, apa yang akan dimasukkan dalam data uji, sesuai dengan dokumen apa yang akan diuji, bagaimana komentar akan dibuat dan dihilangkan.

9.1. Subbab 6.1. "Jenis, komposisi, volume dan metode pengujian sistem dan komponennya" / hal. 2.8.1 GOST 34.602-89 /

Biasanya, di sini saya menunjukkan daftar tes dan menyebutkan bahwa metode pengujian akan diberikan dalam dokumen "Program Uji dan Metodologi", yang merupakan deskripsi dari kasus uji utama, skrip pengujian.

Mari kita membahas jenis-jenis tes. Jenis-jenis pengujian, komposisi mereka, persyaratan untuk dokumen ditetapkan oleh GOST 34.603-92 “Teknologi informasi. Jenis pengujian sistem otomatis. " Karena itu, ketika mengembangkan bagian ini dan proyek teknis, pastikan untuk merujuk pada standar ini, di sini kami hanya akan menjelaskan poin utama.

Mari kita coba untuk memahami apa jenis tes:

1. Tes dibagi menjadi beberapa tipe berikut:

• Pendahuluan.
• Operasi percobaan.
• Penerimaan.

2. Tes pendahuluan (dan penerimaan sebagian) pada gilirannya dibagi menjadi:

• ( ).
• ( ).

Mengapa tes dibagi menjadi beberapa tahapan? Pertama, karena GOST 34.603-92 tidak membedakan antara penerimaan internal dan eksternal, bagian dari pengujian dapat dilakukan tanpa pelanggan. Kedua, proses pengujian berurutan dijelaskan, bagian demi bagian, dan kemudian semuanya terintegrasi.

Mari kita coba menggambarkan proses pengujian dengan kata-kata sederhana:

1. Tes awal otonom dari bagian-bagian sistem. Bagian dari sistem diuji secara individual jika ada beberapa subsistem atau modul besar dalam komposisi. Biasanya, pengujian semacam itu dilakukan secara otonom, yaitu tanpa integrasi dengan sistem yang berdekatan. Jika sistemnya sederhana, langkah ini dapat dilewati dengan aman.

2. Tes otonom awal sistem secara keseluruhan.Seluruh sistem diuji dalam kompleks dalam mode otonom, yaitu, tanpa integrasi dengan sistem yang berdekatan. Fungsi yang terkait dengan sistem yang berdekatan tidak diuji. Dalam kasus ekstrem, "stubs" diletakkan (emulation of integrasi) atau database diisi dengan data yang harus berasal dari sumber eksternal.

3. Tes komprehensif awal. Sistem diuji secara terintegrasi, yaitu dalam interaksi dengan sistem yang berdekatan. Dalam bentuk ini, sistem ditransfer ke pelanggan untuk operasi percobaan.

4. Operasi pilot.MA dapat terjadi dalam mode yang berbeda. Yang terbaik adalah eksploitasi data nyata, dengan pengguna nyata dan dengan tugas nyata. Hanya jenis tes ini yang akan memastikan bahwa sistem benar-benar operasional. Selama operasi uji coba, kerugiannya dieliminasi.

5. Tes penerimaan. Ini jenis cek terakhir. Katakan padaku, mengapa operasi uji coba setelah menghilangkan semua kekurangan tidak akan lancar masuk ke industri? Jadi itu biasanya terjadi. Tetapi paman yang tinggi perlu melihat bahwa sistem itu benar-benar berfungsi, untuk "merasakannya". Tes penerimaan ditujukan untuk mereka, untuk komisi tinggi. Dengan demikian, tes penerimaan berbeda dari tes pendahuluan terutama dalam status komisi.

Juga dalam dokumen paragraf ini ditunjukkan metode pengujian yang akan diberikan:

• « () ». . — 34.603-92 (. 2.2.2 4.1) — 50-34.698-90 « . . . . ».
• « », . 3.1 34.003-90. « » (. . 3.2 34.603-92), .

9.2. Subbab 6.2. "Persyaratan umum untuk penerimaan pekerjaan secara bertahap" / hal. 2.8.2 GOST 34.602-89 /

Di bagian ini, saya biasanya menunjukkan:

1. Di wilayah siapa dan di peralatan siapa tes akan dilakukan: pelanggan atau kontraktor.
2. Deskripsi umum tentang bagaimana pengujian akan dilakukan (misalnya, bahwa dokumen akan diperiksa, keberadaan elemen antarmuka pengguna, skrip dikerjakan).
3. Daftar peserta.
4. Daftar dokumen yang menyusun hasil tes:
   
   
   • Untuk tes pendahuluan dan penerimaan, ini adalah laporan pengujian yang memberikan daftar cek dan hasilnya.
   • Untuk operasi percobaan - jurnal operasi percobaan.

10. Bagian 7 "Persyaratan untuk komposisi dan konten pekerjaan pada persiapan objek otomasi untuk menempatkan sistem ke dalam operasi" / hal. 2.9 GOST 34.602-89 /

Proses yang dijelaskan dalam bagian ini sering disebut sebagai implementasi. Harap dicatat bahwa karya-karya ini juga diberikan di bagian 5 "Komposisi dan konten pekerjaan pada penciptaan (pengembangan) sistem" . Namun, dalam bagian 5 mereka hanya disebutkan secara singkat, dan deskripsi rinci diberikan di sini.

Saat menyiapkan objek, sebagai aturan, pekerjaan berikut harus dilakukan:

1. Reorganisasi, rekrutmen staf baru, jika perlu.
2. Pelatihan staf.
3. Untuk aplikasi web: pengembangan bagian umum situs dan persetujuan pengguna (persetujuan untuk pemrosesan data pribadi).
4. Mengisi direktori dan informasi latar belakang lainnya.
5. Transfer data dari sistem lama.
6. Menyebarkan sistem pada server industri.
7. Konfigurasikan integrasi dengan sistem yang berdekatan.
8. Menyiapkan sistem akses dan membuat akun.

Beberapa poin ini harus dijelaskan dengan sangat rinci, terutama yang berkaitan dengan transfer data dan mengisi direktori.

11. Bagian 8 “Persyaratan Dokumentasi” / h. 2.10 GOST 34.602-89 /

Tidak layak mengacu pada dokumen secara resmi. Dokumen - ini adalah manajemen proyek, alur kerja proyek. Anda tidak akan menyimpan segalanya di kepala Anda, dan keberhasilan proyek tergantung pada ketersediaan dan kualitas dokumen. Tentu saja, ada dokumen "untuk berat", dan mereka harus diperlakukan sesuai, tetapi tanpa dokumen dalam mode yang tenang dan teratur, proyek tidak dapat dilaksanakan.

Dokumentasi proyek otomasi sesuai dengan GOST 34 diatur oleh standar berikut:

• GOST 34.201-89 Jenis, kelengkapan, dan penunjukan dokumen saat membuat sistem otomatis.
• RD 50-34.698-90 Panduan. Teknologi informasi. Seperangkat standar dan pedoman untuk sistem otomatis. Sistem otomatis. Persyaratan untuk isi dokumen.
• Untuk Kerangka Acuan - GOST 34.602-89, yang sedang kita diskusikan sekarang.

Standar pertama (GOST 34.201-89) menyediakan daftar dan struktur dokumentasi. Dalam yang kedua - RD 50-34.698-90 - isi dari dokumen-dokumen berikut ditunjukkan:

• Dokumen desain awal dan proyek teknis.
• Dokumen dikembangkan pada tahap pra-desain.
• Dokumen organisasi dan administrasi (tindakan, protokol, dll.)

11.1 Fitur struktur dokumentasi

Ketika menyusun daftar dokumen yang diperlukan, mereka biasanya melihat RD 50-34.698-90 dan memilih yang diperlukan. Pada saat yang sama, banyak kesalahan dibuat, karena dokumentasi memiliki struktur yang agak rumit, yang dijelaskan dalam GOST 34.201-89.

Mari kita coba mengidentifikasi beberapa aturan yang akan membantu dalam menyusun daftar dokumen.

1. Setiap tahap memiliki set dokumentasi sendiri.

Setiap tahap memiliki set dokumentasi sendiri. Ini sangat penting untuk dipahami. Tidak perlu menentukan pengembangan dokumen operasional pada tahap desain dan sebaliknya. Ternyata kertas murni formal, yang Anda akan menghabiskan banyak waktu. Dan jika "Panduan Pengguna" hingga akhir pengembangan sistem, biasanya tidak ada yang menyusun (walaupun saya telah bertemu angka-angka seperti itu juga), maka "Deskripsi Fungsi Otomatis", yang biasanya berisi skrip untuk programmer, terus-menerus disusun setelah akhir pengembangan. Juga, ketika membaca RD 50-34.698-90, orang mungkin mendapat kesan bahwa beberapa dokumen memiliki konten yang tumpang tindih: ini juga disebabkan oleh fakta bahwa dokumen-dokumen tersebut dimaksudkan untuk tahapan yang berbeda.

Karena beberapa dokumen dapat dikembangkan pada satu tahap atau yang lain, GOST 34.201-89, untuk menghindari pengulangan, secara terpisah menyediakan, misalnya, daftar dokumen yang dapat dikeluarkan baik pada tahap desain teknis dan dokumentasi kerja, dan secara terpisah, daftar dokumen untuk masing-masing tahapan ini secara terpisah. Jadi, ketika menyusun daftar dokumen untuk salah satu tahapan, Anda harus melihat daftar dokumen di beberapa bagian standar.

Agar tidak bingung, saya menyusun lembar kerja Excel di mana menggunakan filter Anda dapat segera menampilkan daftar dokumen lengkap untuk tahap tertentu.

2. Dokumen dibagi menjadi beberapa topik (bagian dari proyek).

GOST 34 berisi dokumen yang menjelaskan solusi seluruh sistem, serta dukungan organisasi, teknis, matematika, perangkat lunak, informasi (kami berbicara tentang jenis dukungan di atas ). Dalam RD 50-34.698-90 dokumen-dokumen ini diberikan secara tepat dengan uraian oleh bagian-bagian proyek (topik). Anda harus selalu memperhatikan hal ini untuk menentukan tujuan dokumen.

3. Dokumen dapat digabungkan.

GOST 34.201-89 secara langsung menunjukkan dalam kasus mana satu dokumen dimasukkan dalam yang lain. Ini dilakukan agar tidak ada lagi dokumen yang merosot, dengan satu atau dua halaman. Jika ada sesuatu yang perlu dijelaskan, tetapi volumenya sangat kecil, yang terbaik adalah memasukkan teks ke dalam dokumen lain. Dalam kebanyakan kasus, ada dokumen seperti "Catatan penjelasan untuk desain teknis", di mana Anda dapat menambahkan bagian.

4. Estimasi operasional dan desain disorot secara terpisah.

Penyusun GOST 34.201-89 dalam kolom terpisah dari tabel dengan daftar dokumen yang diindikasikan milik perkiraan operasional dan desain.

Perkiraan desain meliputi dokumen yang mengatur konstruksi dan pekerjaan listrik: perkiraan, rencana pengadaan, gambar dan diagram listrik.

Dokumen operasional termasuk dokumen yang memandu penggunaan dan pemeliharaan sistem: manual dan instruksi, daftar bahan dan data, dokumen yang berisi informasi tentang pelanggaran selama operasi.

11.2 Fitur desain daftar dokumen

Seperti yang Anda catat sebelumnya, ketika menjelaskan tahapan pekerjaan di bagian 5, “Komposisi dan konten pekerjaan untuk membuat (mengembangkan) sistem” , daftar dokumentasi juga disediakan. Daftar ganda dokumen disediakan untuk alasan sederhana: tidak cukup untuk menunjukkan nama dokumen, masih perlu untuk menjelaskan tujuannya dan memberikan ringkasan singkat (tentu saja, untuk "Panduan Pengguna" tidak masuk akal untuk menunjukkan konten). Jika tidak, itu tidak akan dapat menentukan signifikansi apa yang dimiliki dokumen tertentu dalam manajemen proyek. GOST adalah tamu, dan pada setiap proyek konten dan peran dokumen mungkin berbeda. Selain itu, daftar dapat berisi dokumen yang tidak diatur oleh GOST 34, yang perlu diklarifikasi tanpa gagal.

Dalam aturan dokumentasi, saya biasanya memberikan tabel dengan kolom berikut:

• Panggung.
• Nama dokumen.
• Catatan: menunjukkan standar pengembangan, tujuan, ringkasan, dan fitur utama dokumen.

11.3 Contoh Daftar Dokumentasi

Untuk proyek besar untuk mengimplementasikan sistem yang kompleks, daftar dokumentasi yang cukup besar mungkin diperlukan. Kami memberikan contoh daftar tersebut pada tabel di bawah ini.

12. Bagian 9 "Sumber pengembangan" / hal. 2.11 GOST 34.602-89 /

Tampaknya menjadi bagian formal, tetapi sangat bermanfaat. Bayangkan sebuah situasi ketika Anda ingat bahwa selama pengembangan TK Anda membaca sebuah artikel, dan untuk beberapa alasan Anda perlu menemukannya, misalnya, untuk mengklarifikasi sesuatu atau membenarkan keputusan Anda. Tetapi Anda benar-benar tidak ingat namanya atau di mana ia berada. Karena itu, ketika saya menggunakan materi yang bermanfaat, pastikan untuk memasukkannya ke dalam daftar. Dan dalam teks saya menaruh catatan kaki yang menunjukkan sumbernya.

Jika ada banyak sumber, maka mereka harus dibagi menjadi subbagian, misalnya:

• Materi yang menggambarkan analog (prototipe) dari sistem yang dikembangkan.
• Materi yang menggambarkan ide umum sistem. Seringkali, dokumen-dokumen ini dikompilasi pada tahap pra-desain, dan ini biasanya dirujuk dalam bagian "Karakteristik objek otomatisasi".
• Bahan pengembangan proyek: daftar GOST yang digunakan dari seri 34, standar yang digunakan untuk manajemen proyek.
• Materi yang terkait dengan implementasi proses utama: daftar undang-undang, standar, peraturan internal, dan pesanan yang menetapkan aturan untuk implementasi proses otomatis.
• Bahan dan standar yang memuat persyaratan untuk keamanan umum dan informasi.

Kesimpulan

Tentu saja, persiapan Kerangka Acuan sesuai dengan GOST 34 tidak dapat disebut mudah dan sederhana. Dan bukan karena GOST itu buruk, tetapi GOST hanya membuat Anda memikirkan seluruh proyek, melukis semua hal kecil. Tetapi TOR yang ditulis dengan baik adalah setengah dari keberhasilan proyek.

Tulis di komentar jika Anda menganggap perlu untuk mengklarifikasi atau menambah sesuatu. Pastikan untuk membuat perubahan pada artikel.

Baca artikel lain oleh penulis:

• Survei pra-desain dalam pengembangan sistem informasi.
• Rahasia sukses desain IP (sistem informasi) pada contoh pembangunan rumah sakit.
• Beberapa catatan tentang desain sistem informasi.