IEEE Panduan Teknologi Sistem Informasi

Definisi-Konsep Operasi (ConOps) Dokumen

Sponsor Software Engineering

Komite Standar dari IEEE Computer Society 19 Maret 1998

Disetujui IEEE-SA Standards Board

Abstract: Format dan isi konsep operasi (ConOps) dokumen ini menjelaskan sebuah ConOps
yang berorientasi pengguna dokumen yang menggambarkan karakteristik sistem untuk sistem
yang diusulkan dari 'sudut pandang para pengguna. ConOps dokumen yang digunakan untuk
berkomunikasi secara kuantitatif dan kualitatif karakteristik sistem kepada pengguna, pembeli,
pengembang, dan unsur organisasi lainnya (misalnya, pelatihan, fasilitas, staf, dan
pemeliharaan). Hal ini digunakan untuk menggambarkan organisasi user (s), misi (s), dan •
tujuan-tujuan organisasi dari sistem terpadu sudut pandang.

Kata kunci: pembeli, karakteristik, konsep operasi, konsep dokumen operasi, ConOps,
pengembang, persyaratan operasional, skenario, perangkat lunak sistem intensif, sistem
software, sistem, pengguna, kebutuhan pengguna, sudut pandang.

Dokumen Standar IEEE dikembangkan dalam IEEE Masyarakat dan Komite Koordinasi
Standar IEEE Standards Board. Anggota komite melayani secara sukarela dan tanpa kompensasi.
Mereka tidak perlu anggota Institut. Standar IEEE mewakili dikembangkan dalam konsensus
keahlian yang luas pada subjek dalam Institut serta kegiatan-kegiatan di luar IEEE yang telah
menyatakan minat untuk berpartisipasi dalam pengembangan standar.

Penggunaan IEEE Standard adalah sepenuhnya sukarela. Keberadaan sebuah Standar

IEEE tidak berarti bahwa tidak ada cara lain untuk menghasilkan, menguji, mengukur,
pembelian, pasar, atau menyediakan barang dan jasa lain yang berkaitan dengan lingkup
Standar IEEE.

Selanjutnya, sudut pandang yang diungkapkan pada saat standar disetujui dan
dikeluarkan dapat berubah ditimbulkan melalui perkembangan di negara bagian seni dan
komentar yang diterima dari pengguna standar.
 Setiap IEEE Standar mereview sekurang-kurangnya setiap lima tahun untuk revisi atau
penegasan kembali. Bila dokumen adalah lebih dari lima tahun dan belum ditegaskan kembali,
masuk akal untuk menyimpulkan bahwa isinya, walaupun masih dari beberapa nilai, tidak
sepenuhnya mencerminkan keadaan seni. Pengguna memperingatkan untuk memeriksa untuk
menentukan bahwa mereka memiliki edisi terbaru dari setiap IEEE Standar.

Komentar untuk revisi Standar IEEE dipersilahkan dari pihak yang berkepentingan, tanpa
afiliasi dengan keanggotaan IEEE. Saran untuk perubahan dokumen harus dalam bentuk
perubahan yang diusulkan teks, bersama dengan pendukung yang sesuai komentar.
Interpretasi: Kadang-kadang pertanyaan-pertanyaan yang mungkin timbul mengenai arti dari
bagian-bagian standar karena terkait dengan aplikasi tertentu. Ketika kebutuhan untuk
interpretasi dibawa ke perhatian IEEE, Institute akan melakukan tindakan untuk menyiapkan
respons yang sesuai.

Karena konsensus Standar IEEE mewakili kepentingan semua pihak, adalah penting
untuk memastikan bahwa setiap penafsiran juga telah mendapat persetujuan dari
keseimbangan kepentingan. Untuk alasan ini, IEEE dan anggota dari masyarakat dan Standar
Komite Koordinasi tidak dapat memberikan respon terhadap penafsiran instan permintaan
kecuali dalam kasus-kasus di mana matte / sebelumnya menerima consideration.Comments
resmi mengenai standar dan permintaan untuk penafsiran harus ditujukan untuk:
Sekretaris, IEEE 445 Hoes Strndards Dewan LaneP.O. Box 1331 Piscataway, NJ 08855-1331 USA
Catatan: Perhatian dipanggil untuk kemungkinan bahwa pelaksanaan standar ini mungkin
memerlukan penggunaan subjek yang dicakup oleh hak paten.

Dengan penerbitan standar ini, tidak ada posisi yang diambil sehubungan dengan
adanya atau keabsahan dari setiap hak paten yang berhubungan dengannya. IEEE tidak
bertanggung jawab untuk mengidentifikasi hak paten yang lisensi mungkin diperlukan oleh
standar IEEE atau untuk melakukan penyelidikan keabsahan hukum atau cakupan yang paten
yang akan dibawa ke perhatian.

Tujuan
ini menyajikan format dan isi konsep operasi (ConOps) dokumen yang akan digunakan ketika
mengembangkan atau memodifikasi perangkat lunak sistem intensif. Software-sistem intensif adalah
sistem perangkat lunak yang merupakan tantangan teknis utama dan mungkin merupakan faktor utama
yang mempengaruhi jadwal sistem, biaya, dan risiko.

Dalam kasus yang paling umum, sebuah perangkat lunak sistem intensif terdiri dari
perangkat keras, perangkat lunak, orang, dan manua. " prosedur. Untuk membuat panduan ini
lebih mudah dibaca, istilah "sistem" akan digunakan untuk asoftware-intensif berarti sistem yang
mencakup unsur-unsur untuk dikembangkan atau diubah, di samping perangkat lunak. Istilah.
"Sistem perangkat lunak" akan digunakan untuk maksud-software sistem intensif di mana
perangkat lunak merupakan satu-satunya komponen untuk dikembangkan atau dimodifikasi.
Panduan ini tidak menjelaskan teknik-teknik yang tepat untuk digunakan dalam mengembangkan
dokumen ConOps, tetapi tidak memberikan pendekatan yang dapat digunakan.

Setiap organisasi yang menggunakan panduan ini harus mengembangkan seperangkat

praktek dan prosedur untuk memberikan panduan rinci untuk mempersiapkan dan memperbarui
dokumen ConOps. Ini praktek-praktek dan prosedur rinci harus into'account lingkungan,
organisasi, dan faktor-faktor politik yang mempengaruhi penerapan panduan.

Jantung ConOps dijelaskan dalam buku petunjuk ini terdapat dalam Klausul 3 sampai 5.

 Pasal 3 menjelaskan sistem yang ada (manual atau otomatis) bahwa pengguna ingin
mengganti.

 Ayat 4 memberikan pembenaran untuk yang baru atau diubah sistem dan semua
larangan pada sistem tersebut.

 Ayat 5 menjelaskan sistem yang diusulkan.

Garis untuk Klausul 3 dan pasal 5 adalah hampir identik. Ini bukan untuk mengatakan
bahwa isi dokumen yang telah selesai ConOps akan sama. Sebaliknya, isi harus sangat berbeda ..
Garis yang sama untuk mengingatkan pengembang item yang harus dimasukkan dan tindakan
yang akan diambil.

Tidak semua proyek perangkat lunak yang bersangkutan dengan pengembangan kode
sumber untuk produk software baru. Beberapa proyek perangkat lunak terdiri dari kelayakan s ^
udy dan definisi persyaratan produk. Tenninate proyek-proyek lain setelah menyelesaikan desain
produk atau hanya berkaitan dengan modifikasi produk perangkat lunak yang ada. Penerapan
panduan ini tidak terbatas pada operasional proyek yang mengembangkan versi produk baru,
juga tidak dibatasi oleh ukuran atau cakupan proyek.

Proyek-proyek kecil mungkin membutuhkan lebih sedikit formalitas dari proyek-proyek

besar, tetapi semua komponen dari panduan ini harus ditangani oleh setiap proyek software.
Pendekatan yang ConOps menyediakan kegiatan analisis dan dokumen that'bridges kesenjangan
antara kebutuhan pengguna dan penglihatan dan pengembang spesifikasi teknis.

Selain itu, dokumen menyediakan ConOps berikut:

- Sebuah cara untuk menggambarkan pengguna kebutuhan operasional tanpa menjadi macet
dalam masalah teknis rinci yang ditujukan pada kegiatan analisis sistem.
- Sebuah mekanisme untuk mendokumentasikan karakteristik sistem dan kebutuhan operasional
pengguna dengan cara yang dapat diverifikasi oleh pengguna tanpa memerlukan pengetahuan
teknis apapun di luar apa yang dibutuhkan untuk melakukan normal fungsi pekerjaanku.

- Sebuah tempat bagi pengguna untuk menyatakan keinginan mereka, visi, dan harapan tanpa
memerlukan penyediaan dihitung, diuji spesifikasi. Sebagai contoh, pengguna dapat
mengungkapkan kebutuhan mereka untuk "handal" sistem, dan alasan-alasan yang mereka
butuhkan, tanpa harus menghasilkan kehandalan yang dapat diuji persyaratan.

Dalam hal ini, pengguna perlu untuk "keandalan tinggi" mungkin dinyatakan dalam istilah
kuantitatif oleh pembeli sebelum mengeluarkan permintaan pembuatan proposal (RFP), atau
mungkin dapat dihitung oleh pengembang selama analisis persyaratan. Dalam kasus apapun, itu
adalah tugas dari uyerand pengembang untuk mengukur kebutuhan pengguna

- Sebuah mekanisme untuk pengguna dan pembeli (s) untuk mengekspresikan thougnts dan
kekhawatiran tentang kemungkinan strategi solusi. Dalam beberapa
kasus, kendala desain mendikte pendekatan tertentu. Dalam kasus lain, mungkin ada berbagai
diterima strategi solusi.

Dokumen ConOps memungkinkan para pengguna dan pembeli (s) untuk merekam
kendala desain, yang alasan bagi mereka kendala, dan untuk menunjukkan berbagai strategi
solusi yang dapat diterima. Bermaksud menggunakan .Panduan ini dimaksudkan untuk digunakan
dalam berbagai situasi oleh berbagai pengguna termasuk yang berikut ini:

- Acquirers menggunakan ISO / IEC 12207:1995, teknologi informasi-Software proses siklus hidup,
akan menemukan Panduan saat ini cocok untuk memuaskan persyaratan 5.1.1.1:
"The pengakuisisi memulai proses akuisisi dengan menjelaskan sebuah konsep atau kebutuhan
untuk memperoleh, mengembangkan, atau meningkatkan sistem, perangkat lunak atau
perangkat lunak procuct layanan."

- Pengguna yang sebelumnya diterapkan MIL-STD-498, Software Development dan Dokumentasi,

dan standar yang terkait akan menemukan bahwa dokumen ConOps dijelaskan dalam buku
petunjuk ini sangat mirip dengan konsep operasional deskripsi (OCD) termasuk dalam MIL-STD-
498.

- Pengguna EIA / IEEE J-STD-016-1995, EIA / IEEE Interim Trial-Gunakan Standar untuk Teknologi
Informasi Proses Software Life Cycle Software Development Acquirer-Supplier Perjanjian akan
menemukan bahwa dokumen ConOps dijelaskan dalam buku petunjuk ini secara substantif
identik dengan OCD termasuk dalam EIA / IEEE J-STD-016-1995.
- Lain pengguna akan menemukan panduan ini berguna dalam memfasilitasi komunikasi di antara
berbagai pemangku kepentingan dalam suatu proyek.

Tinjauan
Panduan ini berisi empat klausa. Ayat 1 mendefinisikan cakupan panduan ini. Ayat 2
memberikan referensi standar IEEE lain yang harus diikuti ketika menerapkan panduan ini. Ayat 3
memberikan definisi dari istilah yang digunakan di seluruh panduan.

Ayat 4 berisi ikhtisar dan spesifikasi rinci dari ConOps dokumen, termasuk komponen
yang diperlukan yang harus disertakan, dan komponen opsional yang mungkin termasuk dalam
rencana proyek berdasarkan panduan ini.

Organisasi yang bertanggung jawab

Idealnya, ConOps dokumen harus ditulis oleh wakil-wakil komunitas pengguna. Dalam
prakteknya, individu atau organisasi lain dapat menulis ConOps (misalnya, pembeli, konsultan
pihak ketiga, dan / atau pengembang perangkat lunak).

Dalam kasus ini, penting bila user terlibat dalam meninjau, merevisi, dan menyetujui
dokumen ConOps.

Tujuan utama untuk dokumen ConOps adalah untuk menangkap kebutuhan pengguna, dan
untuk mengungkapkan kebutuhan-kebutuhan tersebut dalam terminology pengguna.

Audience
Panduan ini ditujukan untuk pengguna dan pembeli sistem perangkat lunak, pengembang
perangkat lunak, dan personel lain yang menyiapkan dan memperbarui perangkat lunak
persyaratan operasional untuk sistem intensif dan memonitor kepatuhan terhadap persyaratan
tersebut.

Evolusi rencana

Mengembangkan versi awal dari dokumen ConOps harus menjadi salah satu kegiatan pertama
selesai pada proyek perangkat lunak. Sebagai proyek berkembang, sifat pekerjaan yang harus dilakukan
dan rincian pekerjaan akan lebih baik dipahami. ConOps dokumen yang harus diupdate secara berkala
untuk mencerminkan situasi yang berkembang. Jadi, setiap versi dokumen harus ditempatkan di bawah
kontrol konfigurasi.
Terminologi

Panduan ini mengikuti edisi tahun 1996 Standar IEEE Style Manual. Istilah harus, mungkin,
mungkin, dan menyarankan digunakan untuk menunjukkan tindakan yang harus digunakan untuk
mengembangkan dokumen ConOps yang baik tetapi yang tidak wajib. Namun, para penulis dari sebuah
dokumen ConOps harus mempertimbangkan untuk menggunakan semua aspek dari panduan ini untuk
memastikan lengkap dan efektif dokumen. Dokumen yang ConOps kadang-kadang disebut konsep
operasional dokumen (OCD).

Sejarah

Penggunaan dokumen ConOps pertama kali didokumentasikan di Lano, RJ, "A Structured
Pendekatan untuk Perumusan Konsep Operasional," TRW SS-80-02, TRW Pertahanan dan Space Systems
Group, Redondo Beach, CA, 1980. Pada tahun 1992 Sistem Perangkat Lunak Panitia Teknis American
Institute of Aeronautics and Astronautics (alaa), mengembangkan sebuah standar untuk OCD.

Panduan ConOps ini berasal pada Oktober 1993, sebagai Master of Science tesis di California
State University, Sacramento, dan didukung oleh Kantor US Penelitian dan Pengembangan. Itu diterima
sebagai MIL-STD-498, Data Item Description (DID), oleh theDoD-Std-2167A Harmonisasi Working Group
dengan sedikit cnanges. M1L-STD-498-1995 menjadi IEEE Std 1498-1995, yang redesignated J-STD-016-
1995.
Dewan Standar IEEE menyetujui permintaan otorisasi proyek (PAR) untuk pengembangan
panduan ini pada bulan Juni 1993. Draft pertama telah disampaikan kepada Komite Standar Software
Engineering (SESC) pada tanggal 8 Agustus 1995; itu adalah kembali pada tanggal 1 November 1995
dengan permintaan bahwa panduan diselaraskan dengan tertentu lainnya standar rekayasa perangkat
lunak tertentu. Kedua rancangan telah disampaikan kepada SESC pada tanggal 28 Februari 1996. Draft
ini balloted pada tanggal 21 Agustus 1996.

Peserta

Panduan ini ditulis oleh IEEE Panduan untuk Operasi Dokumen Konsep Working Group, yang merupakan
bagian dari IEEE Computer Society. Berikut adalah tiga orang penulis dari panduan ini: Richard H. Thayer
Richard E. Fairley
Per Bjorke

Other individuals who supported the development of this guide are:

Jed Bartlett Merlin Dorfman

Randy
Paul jane
Boris I. Cogan Rajko Milovanovic Radatz

The following persons were on the balloting committee:

 Alan L. Bridges
Mikhail Auguston Peter A. Berggren Kathleen L. Briggs
Thomas G.
Robert E. Barry H. Ronald Berlack Callaghan

Mordechai Ben-Menachem Audrey C. Brewer

Contents

1. Scope (tya)..................................................................................................................................l
2. References (tya)........................................................................................]................................1
3. Definitions (tya)...,................................................................................„;...................................2
4. Elements of a ConOps document.................................................................................................4

4.1 Scope (Clause 1 of the ConOps document) (tya)....................................................................5

4.2 Referenced documents (Clause 2 of the ConOps document) (rida)........................................6
4.3 Current system or situation (Clause 3 of the ConOps document) (rida)......-............................7
4.4 Justification for and nature of changes (Clause 4 of the ConOps document) (qorry)................9
4.5 Concepts for the proposed system (Clause 5 of the ConOps document) (qorry)....................11
4.6 Operational scenarios (Clause 6 of the ConOps document) (onny).......................................14
4.7 Summary of impacts (Clause 7 of the ConOps document) (onny)..........................................15
4.8 Analysis of the proposed system (Clause 8 of the ConOps document)(tya)............................16
4.9 Notes (Clause 9 on the ConOps document) (rida)................................................................16
4.10Appendices (Appendices of die ConOps document) (qorry).................................................16
4.11 Glossary (Glossary of the ConOps document) (onny)...........................................................16

Annex A (Informative) IEEE/EIA 12207.1-1997 Compliance Statement...................................................17

IEEE Panduan untuk Teknologi Informasi

Definisi-Konsep Sistem Operasi (ConOps) Dokumen

1. Lingkup

Panduan ini menentukan format dan isi konsep operasi (ConOps) dokumen. Sebuah ConOps
adalah berorientasi pengguna dokumen yang menggambarkan karakteristik sistem to-be-sistem
disampaikan dari sudut pandang pengguna. ConOps dokumen yang digunakan untuk berkomunikasi
secara kuantitatif dan kualitatif karakteristik sistem kepada pengguna, pembeli, pengembang, dan unsur
organisasi lainnya (misalnya, pelatihan, fasilitas, staf, dan pemeliharaan). Ini menggambarkan organisasi
user (s), misi (s), dan tujuan organisasi dari systeiis terpadu sudut pandang.

Panduan ini dapat diterapkan pada semua jenis perangkat lunak sistem intensif: hanya
perangkat lunak atau perangkat lunak / perangkat keras / orang sistem. Konsep-konsep yang terkandung
dalam buku petunjuk ini juga bisa digunakan untuk hardware-hanya sistem, tetapi cara ini digunakan
tidak ditujukan di sini. Ukuran, ruang lingkup, kompleksitas, atau kritis dari produk perangkat lunak tidak
membatasi penggunaan panduan ini. Panduan ini berlaku untuk sistem yang akan diterapkan di segala
bentuk produk media, termasuk firmware, embedded system code, programmable logic array, dan
software-di-silikon. Panduan ini dapat diterapkan untuk setiap dan semua segmen dari siklus hidup
sistem.
Minimal ret mengidentifikasi unsur-unsur yang harus muncul dalam semua dokumen ConOps.
Namun, pengguna buku petunjuk ini mungkin memasukkan unsur-unsur lain dengan menambahkan
klausul tambahan atau ConOps mereka subclauses dokumen. Dalam setiap kasus, skema penomoran
klausa yang diperlukan dan harus mematuhi subclauses format yang ditetapkan dalam buku petunjuk
ini. Berbagai klausa dan subclauses dari dokumen ConOps dapat dimasukkan oleh penggabungan
langsung atau dengan mengacu pada dokumen-dokumen pendukung lainnya.

2. Referensi

Panduan ini akan digunakan dalam hubungannya dengan publikasi berikut. Secara khusus, pada
persyaratan standar dan rencana harus berkonsultasi dalam menyiapkan ConOps Ketika standar-standar
berikut ini digantikan oleh revisi yang telah disetujui, revisi akan berlaku. IEEE Std 610.12-1990, IEEE
Standard Glossary of Software Engineering Terminology.1
3. Definisi

Definisi yang tercantum di sini menetapkan makna dalam konteks panduan ini. Definisi istilah-istilah lain
yang mungkin sesuai dalam konteks panduan ini dapat ditemukan dalam IEEE Std 610,12-1.990.

3.1 Analisis : Proses mempelajari sistem partisi sistem ke dalam bagian (fungsi, komponen, atau objek)
dan menentukan bagaimana bagian-bagian berhubungan satu sama lain.

3.2 pembeli: (A) Sebuah individuaj atau organisasi yang bertanggung jawab untuk memperoleh suatu
produk atau jasa (misalnya, sistem perangkat lunak) untuk digunakan oleh mereka sendiri atau
pengguna lain. Lihat juga: pelanggan. (B) Orang atau organisasi yang menerima sistem dan membayar
untuk proyek.
Konsep

3.3 Analisis konsep: The derivasi dari konsep sistem melalui penerapan analisis.
3.4 Konsep operasi (ConOps) dokumen: Seorang pengguna yang berorientasi dokumen yang
menggambarkan karakteristik operasional sistem dari sudut pandang pengguna akhir. Sinonim: deskripsi
konsep operasional (OCD).

3.5 kendala: Sebuah eksternal pada sistem pembatasan dikenakan persyaratan, desain, atau
pelaksanaan atau pada proses yang digunakan untuk mengembangkan atau memodifikasi sebuah
sistem.
3.6 kontrak: Dalam manajemen proyek, dokumen yang mengikat secara hukum disepakati oleh nasabah
dan pengembang perangkat keras atau perangkat lunak atau pemasok; mencakup teknis, organisasi,
biaya, dan / atau persyaratan penjadwalan proyek.

3.7 pelanggan: (A) Orang pribadi atau organisasi yang menetapkan persyaratan dan menerima
penyerahan secara resmi baru atau diubah produk perangkat keras atau perangkat lunak dan
dokumentasi; pelanggan mungkin atau tidak menjadi pengguna utama dari sistem.

Ada potensial, banyak tingkat pelanggan, masing-masing dengan tingkat yang berbeda untuk
memuaskan kebutuhan. Pelanggan mungkin internal atau eksternal bagi organisasi pembangunan untuk
proyek. Lihat juga: user.

(B) Seorang individu atau organisasi yang bertindak bagi pengguna akhir yang baru atau diubah produk
perangkat keras atau perangkat lunak untuk mendapatkan produk dan dokumentasinya. Lihat juga:
pembeli.
3.8 pengembang: Suatu organisasi yang mengembangkan produk-produk perangkat lunak;
"mengembangkan" dapat mencakup perkembangan baru, modifikasi, menggunakan kembali, rekayasa
ulang, pemeliharaan, atau kegiatan lain yang menghasilkan produk-produk perangkat lunak, dan
termasuk pengujian, jaminan mutu, manajemen konfigurasi, dan kegiatan lainnya diterapkan untuk
produk ini. Sinonim: pemasok.

3.9 lingkungan: Keadaan, benda, dan kondisi yang mengelilingi sebuah sistem yang akan dibangun;
mencakup teknis, politik, komersial, budaya, organisasi, dan pengaruh fisik serta standar dan kebijakan
yang mengatur sistem apa yang harus dilakukan atau bagaimana, akan melakukannya.

3.10 fungsi: Kemampuan dari berbagai komputasi, user interface, input, output, manajemen data, dan
fitur lain yang diberikan oleh produk.
3.11 mode: Satu set fitur terkait atau kemampuan fungsional dari suatu produk, (misalnya, on-line, off-
line, dan pemeliharaan mode).

3.12 N diagram: Sebuah sistem rekayasa perangkat lunak teknik atau alat untuk tabulasi,
mendefinisikan, menganalisis, dan menggambarkan antarmuka fungsional dan interaksi di antara
komponen sistem. The N2 diagram struktur matriks yang menampilkan grafis bidirectional fungsi dan
keterkaitan antara komponen dalam suatu sistem atau struktur.
3.13 konsep operasional deskripsi (OCD): Lihat: konsep operasi (ConOps) dokumen.
3,14 prioritas: Sebuah urutan peringkat status, kegiatan, atau tugas-tugas. Prioritas sangat penting
ketika sumber daya terbatas.,

3.15 masalah domain: Satu set masalah yang sama yang terjadi dalam suatu lingkungan dan
meminjamkan diri ke solusi umum.

3.16 permintaan proposal (RFP): Sebuah permintaan layanan, penelitian, atau produk yang disiapkan
oleh pelanggan dan dikirimkan kepada calon pengembang dengan harapan bahwa calon pengembang
akan merespons dengan biaya yang diusulkan, jadwal, dan pendekatan pembangunan.

3.7 skenario: (A) Sebuah langkah-demi-langkah deskripsi dari rangkaian peristiwa yang mungkin terjadi
secara bersamaan atau secara berurutan. (B) Sebuah rekening atau sinopsis dari suatu kursus
diproyeksikan peristiwa atau tindakan.

3.18 software-sistem intensif: Sebuah sistem untuk perangkat lunak mana yang merupakan tantangan
teknis utama dan mungkin merupakan faktor utama yang mempengaruhi jadwal sistem, biaya, dan
risiko. Dalam kasus yang paling umum, sebuah perangkat lunak sistem intensif terdiri dari perangkat
keras, perangkat lunak, orang, dan manual prosedur.

3.19 siklus hidup perangkat lunak: Sistem atau siklus produk yang diprakarsai oleh pengguna kebutuhan
atau dirasakan kebutuhan pelanggan dan diberhentikan oleh menghentikan penggunaan produk. Siklus
hidup perangkat lunak biasanya menyertakan sebuah konsep fase, persyaratan tahap, tahap desain,
tahap pelaksanaan, tahap pengujian, instalasi dan checkout fase, fase operasi dan pemeliharaan, dan,
kadang-kadang, fase pensiun. Fase-fase ini mungkin tumpang tindih dalam waktu atau mungkin terjadi
iteratively.
3.20 sistem perangkat lunak: software-sistem intensif yang lunak, adalah satu-satunya komponen untuk
dikembangkan atau dimodifikasi. Lihat juga: perangkat lunak sistem intensif.
3.21 solusi domain: The lingkungan di mana solusi atau serangkaian solusi berada. Lihat juga: masalah
domain.
3.22 pemasok: Lihat: pengembang.
3.23 Sistem (A) Asekumpulan komponen yang berinteraksi terorganisir untuk mencapai fungsi tertentu
atau sekumpulan fungsi dalam lingkungan tertentu. (B) Sekelompok orang, benda, dan merupakan
prosedur untuk mencapai tujuan yang telah ditetapkan beberapa peran operasional dengan melakukan
fungsi-fungsi tertentu. Sebuah sistem lengkap yang mencakup semua peralatan yang terkait, fasilitas,
bahan, program komputer, firmware, dokumentasi teknis, layanan, dan personel yang diperlukan untuk
Operas dan dukungan ke tingkat yang diperlukan untuk mandiri dimaksudkan digunakan dalam
lingkungan. (
3.24 Penelusuran: Identifikasi dan dokumentasi derivasi jalan (ke atas) dan alokasi atau flowdown jalan
(ke bawah) dari produk kerja dalam hirarki produk kerja. Penting jenis pelacakan meliputi: ke atau dari
sumber eksternal atau dari persyaratan sistem; ke atau dari sistem persyaratan ke atau dari tingkat
terendah persyaratan; ke atau dari persyaratan ke atau dari desain atau dari desain ke atau dari
pelaksanaan; ke atau dari pelaksanaan untuk menguji dan ke atau dari persyaratan untuk menguji.
3.25 pengguna: (A) Orang pribadi atau organisasi yang menggunakan perangkat lunak sistem intensif
dalam aktivitas kerja sehari-hari atau recreatiorjaj pursuits. (B) seseorang (atau orang) yang
mengoperasikan atau berinteraksi secara langsung dengan perangkat lunak sistem intensif.
3.26 kebutuhan user: Seorang pengguna persyaratan untuk sistem user percaya akan menyelesaikan
masalah yang dialami oleh pengguna

4. Unsur dokumen ConOps

Klausul ini menggambarkan masing-masing dari unsur-unsur penting dari sebuah dokumen ConOps.
Elemen-elemen ini harus dipesan dalam urutan klausa dan subclauses ditunjukkan pada Tabel 1. Setiap
versi dokumen ConOps didasarkan pada panduan ini harus berisi judul dan revisi perhatikan bahwa
pengenal yang unik pada dokumen.

Informasi revisi proyek dapat mencakup nama, nomor versi dokumen, tanggal rilis, tanda tangan
persetujuan, daftar suhclauses yang telah diubah dalam versi dokumen, dan daftar nomor versi dan
tanggal pembebasan semua sebelumnya versi dokumen.

ConOps yang disetujui dokumen harus ditempatkan di bawah kontrol konfigurasi.

Sebagaimana ditunjukkan pada Tabel 1, pengantar dari dokumen ConOps memberikan informasi
bahwa penulis ingin pembaca tahu sebelum membaca dokumen. Kata pengantar harus mencakup
tujuan dokumen, ruang lingkup kegiatan yang mengakibatkan perkembangannya, yang menulis
dokumen dan mengapa, yang dimaksudkan penonton untuk dokumen, dan evolusi yang diharapkan
dokumen.Daftar isi, daftar angka, dan daftar tabel harus dimasukkan dalam setiap ConOps dokumen,
seperti ditunjukkan dalam Gambar 1
 Persyaratan untuk dokumen kepatuhan dibahas dalam subclauses berikut:
A.3.1 membahas informasi sesuai dengan persyaratan yang tercantum dalam kolom 2
Tabel A.2 seperti yang ditentukan oleh Pasal 5.1.1.1 dari IEEE / EIA 12.207,0-1.996.

 A.3.2 membahas sesuai dengan pedoman konten generik (the "jenis" dokumen) dicatat
dalam kolom 3 dari Tabel A.2 sebagai "deskripsi." Panduan konten generik untuk
"deskripsi" muncul di 5,1 dari IEEE / EIA 12.207,1-1.997.

 A.3.3 membahas sesuai dengan persyaratan tertentu untuk dokumen ConOps dicatat
dalam kolom 4 dari Tabel A.2 seperti yang ditentukan oleh 6,3 dari IEEE / EIA 12.207,1-
1.997.

 A.3.4 membahas sesuai dengan data siklus hidup tujuan dari Lampiran H dari IEEE / EIA
12.207,0-1.996 seperti yang dijelaskan dalam 4,2 dari IEEE / EIA 12.207,1-1.997.

 A.3.1 Kepatuhan dengan informasi persyaratan lEEE / EIA 12.207,0-1.996

Informasi persyaratan untuk dokumen ConOps adalah yang ditentukan oleh 5.1.1.1 dari
IEEE / EIA 12.207,0-1.996. Dalam kasus ini, persyaratan tersebut secara substansial
identik seperti A.3.3 mereka yang dianggap dalam standar ini.

 A.3.2 Kepatuhan dengan panduan konten generik dari lEEE / EIA 12.207,1-1.997
Panduan konten generik untuk "deskripsi" di IEEE / EIA 12.207,1-1.997 diresepkan oleh
5,1 dari IEEE / EIA 12.207,1-1.997.

 Sebuah deskripsi memenuhi akan mencapai tujuan yang tercantum dalam 5.1.1 dan
termasuk informasi yang tercantum dalam 5.1.2 dari IEEE / EIA 12.207,1-1.997.
Tujuan dari deskripsi adalah:

IEEE / EIA 12.207,1-1.997, subclause 5.1.1: Tujuan: Jelaskan yang direncanakan atau fungsi yang
sebenarnya, desain, kinerja, atau proses.

4.1.1 Indentiflcation (1.1 dari dokumen ConOps)

Subclause ini berisi nomor identifikasi, judul, dan singkatan (jika berlaku) dari sistem atau
subsistem yang ConOps ini berlaku. Jika dokumen-dokumen yang terkait ConOps untuk sistem
secara keseluruhan telah dikembangkan secara hirarki atau jaringan dengan cara, posisi
dokumen ini relatif terhadap dokumen-dokumen ConOps lain harus dijelaskan.

4.1.2 Dokumen ikhtisar (1.2 dari dokumen ConOps)

Subclause ini meringkas dan memperluas tujuan motivasi untuk ConOps dokumen. Tujuan
khalayak untuk dokumen juga harus disebutkan. Selain itu, subclause ini menjelaskan apapun
pertimbangan keamanan atau privasi yang terkait dengan penggunaan ConOps. Subclause ini
juga menguraikan sisa bagian panduan ini.

Tujuan dari dokumen ConOps akan, dalam banyak kasus, menjadi;

- Untuk berkomunikasi pengguna kebutuhan dan harapan dari sistem yang diusulkan kepada
pembeli dan / atau pengembang;

- Untuk berkomunikasi pembeli atau pengembang pemahaman pengguna 'kebutuhan dan

bagaimana sistem akan beroperasi untuk memenuhi kebutuhan tersebut.
Namun, sebuah dokumen ConOps mungkin juga melayani tujuan lain, seperti membangun
konsensus di antara beberapa kelompok pengguna, di antara beberapa organisasi pembeli,
dan / atau di antara beberapa pengembang. Para penonton dari: ConOps dokumen ini dapat
beragam orang.

- User dapat membacanya untuk menentukan apakah kebutuhan dan keinginan mereka telah
benar ditentukan oleh perwakilan mereka atau untuk memverifikasi pengembang under:
anding dari kebutuhan mereka.

- Pembeli dapat membacanya untuk mendapatkan pengetahuan tentang kebutuhan pengguna

dan / atau pengembang pemahaman kebutuhan tersebut.

- Pengembang akan biasanya menggunakan ConOps dokumen sebagai dasar untuk kegiatan
pengembangan sistem, dan membiasakan anggota tim baru dengan masalah domain dan
sistem yang berlaku ConOps.
4.1.3 ikhtisar Sistem (1.3 dari dokumen ConOps)

Subclause ini menyatakan secara singkat tujuan dari sistem yang diusulkan atau subsistem
mana ConOps berlaku. Ini menggambarkan sifat umum dari sistem, dan mengidentifikasi
proyek sponsor, lembaga pengguna, organisasi pembangunan, dukungan lembaga, badan-
badan sertifikasi atau sertifikasi, dan pusat-pusat operasi atau situs yang akan menjalankan
sistem. Hal ini juga menunjukkan dokumen-dokumen lain yang relevan hingga saat ini atau
sistem yang diusulkan.

Sebuah gambaran grafis dari sistem sangat dianjurkan. Hal ini bisa dalam bentuk diagram
konteks, tingkat atas objek diagram, atau beberapa jenis diagram yang menggambarkan sistem
dan lingkungannya.

Dokumen yang mungkin dikutip termasuk, tetapi tidak terbatas pada: otorisasi proyek,
dokumentasi teknis yang relevan, signifikan korespondensi, dokumen tentang proyek terkait,
laporan analisis risiko, dan studi kelayakan.

4.2 Referenced dokumen (Pasal 2 dari dokumen ConOps)

Klausul ini daftar nomor dokumen, judul, revisi, dan tanggal dari semua dokumen yang
direferensikan di dalam dokumen ConOps. Klausul ini juga harus mengidentifikasi soi rce untuk
semua dokumen yang tidak tersedia melalui saluran normal.

4.3 Sistem atau situasi (Pasal 3 dari dokumen ConOps)

Ayat 3 menjelaskan sistem atau situasi (baik otomatis atau manual) seperti saat ini. Jika tidak
ada sistem yang sekarang yang akan menjadi dasar perubahan, subclause ini menggambarkan
situasi yang memotivasi pengembangan sistem yang diusulkan. Dalam kasus ini, berikut akan
subclauses disesuaikan sesuai untuk menggambarkan situasi yang memotivasi.

Klausul ini juga menyediakan pembaca dengan pengenalan masalah domain. Hal ini
memungkinkan pembaca untuk lebih memahami alasan-alasan untuk perubahan dan perbaikan
yang diinginkan.

4.3.1 Latar Belakang, tujuan, dan ruang lingkup (3,1 dari dokumen ConOps)

Subclause ini memberikan ikhtisar tentang sistem atau situasi saat ini, termasuk sebagai
berlaku, latar belakang, misi, tujuan, dan ruang lingkup. Selain menyediakan latar belakang
untuk sistem yang sekarang, subclause ini harus memberikan ringkasan singkat dari motivasi
untuk sistem yang sekarang.
 Contoh motivasi untuk sistem otomatisasi dapat mencakup tugas-tugas tertentu atau
melawan ancaman situasi tertentu. Para goafs untuk sistem yang sekarang juga harus
ditetapkan, bersama-sama dengan strategi, solusi, taktik, metode, dan teknik yang digunakan
untuk mencapai mereka.

Modus operasi, kelas pengguna, dan interface kelingkungan operasional menetapkan cakupan
sistem yang diusulkan, yang dirangkum dalamklausul ini dan didefinisikan secara lebih rinci
dalam pasal-pasal berikutnya.

4.3.2 kebijakan operasional dan kendala (3.2 dari dokumen ConOps)

Subclause ini menggambarkan kebijakan operasional dan kendala yang berlaku untuk sistem
yang sekarang atau situasi.

Kebijakan operasional yang telah ditetapkan keputusan manajemen operasi mengenai sistem
saat ini, biasanya dalam bentuk pernyataan atau pemahaman umum yang membimbing
kegiatan pengambilan keputusan.

Kebijakan pengambilan keputusan membatasi kebebasan tapi apakah memungkinkan untuk

beberapa kebijaksanaan. Operasional kendala keterbatasan ditempatkan pada operasi sistem
yang sekarang.

Contoh kendala operasional meliputi:

- Sebuah kendala pada jam operasi dari sistem, mungkin dibatasi oleh akses ke terminal aman
- Sebuah kendala pada jumlah personil yang tersedia untuk mengoperasikan sistem
- Sebuah kendala pada perangkat keras komputer (misalnya, harus beroperasi di komputer X)
- Sebuah kendala operasional pada fasilitas, seperti ruang kantor
4.3.3 Deskripsi sistem yang sekarang atau situasi (3,3 dari dokumen ConOps)
Subclause ini akan berisi bagian utama dari deskripsi sistem yang sekarang. Ini memberikan
gambaran mengenai sistem yang sekarang atau situasi, termasuk yang berikut, yang sesuai:
a) lingkungan operasional dan karakteristiknya

b) komponen sistem Mayor dan keterkaitan antara komponen-komponen;

c) Penghubung ke sistem eksternal atau prosedur

d) Kemampuan, fungsi, dan fitur dari sistem yang sekarang

e) Grafik dan deskripsi yang menyertainya yang menggambarkan input, output, aliran data,
aliran kontrol, dan proses manual dan otomatis cukup untuk memahami sistem yang sekarang
atau situasi dari pengguna sudut pandang;
f) Biaya sistem operasi;

g) faktor-faktor risiko operasional;

h) Kinerja karakteristik, seperti kecepatan, throughput, volume, frekuensi;

i) Kualitas atribut, seperti: ketersediaan, ketepatan, efisiensi, upgrade, fleksibilitas,

interoperabilitas, menjaga-kemampuan, portabilitas, reliabilitas, usabilitas, supportability,
survivability, dan kegunaan, dan

j) Ketentuan untuk keselamatan, keamanan, privasi, integritas, dan kesinambungan operasi

dalam keadaan darurat. Ayat ini bertujuan untuk menggambarkan sistem yang digunakan saat
ini dan cara system beroperasi, yang tepat untuk menggunakan alat atau teknik yang
melayani tujuan ini.

Perlu diketahui bahwa deskripsi dari sistem cukup sederhana dan cukup jelas sehingga
semua pembaca dokumen yang dimaksud dapat memahami sepenuhnya. Perlu diingat juga
bahwa dokumen ConOps akan ditulis menggunakan user 'terminologi. Dalam kebanyakan
kasus, hal ini berarti menghindari terminologi yang spesifik untuk komputer (misalnya, "jargon
komputer").

Alat grafis harus sedapat mungkin digunakan, disebabkan karena ConOps dokumen
harus dimengerti oleh beberapa jenis pembaca. Perangkat grafis yang berguna termasuk,
namun tidak terbatas pada, pekerjaan struktur breakdown (WBS), N2 grafik, atau kegiatan
urutan bagan, diagram blok aliran fungsional, struktur bagan, alokasi bagan, data flow diagram
(DFD), diagram objek, diagram konteks, storyboard, dan entitas-hubungan diagram.

Deskripsi lingkungan operasional harus mengidentifikasi, sebagaimana berlakunya

fasilitas peralatan computer (hardware, software) personalia, dan prosedur operasional yang
digunakan untuk mengoperasikan sistem yang ada. Deskripsi ini harus sedetail yang diperlukan
sehingga memberikan pembaca pemahaman kepada pembaca : angka mentega, versi,
kapasitas, dll, dari peralatan operasional yang digunakan. Sebagai contoh, jika sistem yang
sekarang berisi sebuah database, kapasitas unit penyimpanan (s) harus ditentukan, informasi
yang diberikan memberikan pengaruh pada pengguna 'kemampuan operasional. Demikian juga,
jika sistem komunikasi menggunakan link, kapasitas link tersebut harus dilengkapi jika mereka
mempengaruhi faktor-faktor seperti kemampuan pengguna, waktu tanggap, atau throughput.

Aspek-aspek keselamatan, keamanan, dan privasi yang memberikan pengaruh pada

pengoperasian atau lingkungan operasional sistem yang sekarang harus dijelaskan. Penulis (s)
dari sebuah dokumen ConOps harus mengatur informasi dalam subclause ini yang sesuai
dengan sistem atau situasi, selama uraian yang jelas tentang sistem yang ada akan tercapai. Jika
bagian dari deskripsi produktif, mereka dapat dimasukkan dalam lampiran atau didirikan oleh
referensi. Contoh bahan yang mungkin akan dimasukkan dalam lampiran akan menjadi kamus
data.

Contoh bahan yang akan dimasukkan oleh mungkin referensi manual rinci kebijakan
operasional dan prosedur untuk sistem yang sekarang.

4.3.4. Model operasi untuk sistem yang sekarang atau situasi (3,4 dalam dokumen ConOps)
Subclause ini menggambarkan berbagai modus operasi untuk sistem atau situasi saat ini
(misalnya : operasional, rusak, pemeliharaan, pelatihan, darurat, alternatif-situs, masa
damai, masa perang, tanah-based, penerbangan, aktif, dan idle mode)

Semua cara-cara yang berlaku untuk semua kelas pengguna harus dimasukkan.
Penting menyertakan mode untuk yang mengalami degradasi, cadangan dan mode
darurat, jika ada seperti itu. Hal ini terutama benar jika modus ini melibatkan situs
geografis yang berbeda dan peralatan yang memiliki dampak signifikan pada aspek-
aspek operasional dari sistem.

Subclause ini dapat dibagi lagi menjadi subclauses tingkat bawah, satu untuk
setiap mode dijelaskan. Proses sistem, prosedur, dan kemampuan atau fungsi harus
berkaitan dengan setiap mode, sebagaimana mestinya, mungkin menggunakan matriks
referensi silang.

4.3.5. Pengguna kelas dan Terlibat lain personel (3,5 dari dokumen ConOps) Seorang pengguna
kelas dibedakan oleh cara-cara di mana pengguna berinteraksi dengan sistem.

Faktor-faktor yang membedakan kelas pengguna termasuk tanggung jawab

umum, tingkat keterampilan, aktivitas kerja, dan cara interaksi dengan sistem. Kelas-
kelas pengguna yang berbeda mungkin telah berbeda skenario operasional untuk
interaksi mereka dengan sistem.

Dalam konteks ini, pengguna adalah orang yang berinteraksi dengan sistem yang
ada, termasuk operasional pengguna, entri data personalia, operator sistem, dukungan
operasional personel, perangkat lunak pengelola, dan pelatih.

Subclause ini dapat diatur lebih lanjut, sebagai berikut, jika membantu dalam
mengkomunikasikan konten.

4.3.5.1. Struktur Organisasi (3.5.1 dari dokumen ConOps)

 Subclause ini menggambarkan struktur organisasi yang ada dari berbagai
kelompok pengguna dan kelas pengguna yang terlibat dengan sistem yang sekarang.
Bagan organisasi adalah alat grafis berguna untuk tujuan ini.

Subclause ini memberikan profil pengguna masing-masing kelas untuk sistem

yang sekarang. Jika beberapa pengguna memainkan beberapa peran, peran masing-
masing harus diidentifikasi sebagai pengguna terpisah kelas. Setiap user kelas untuk
sistem saat ini, termasuk operator dan pengelola, harus dijelaskan dalam subclause
terpisah. Masing-masing harus memberikan penjelasan mengenai kelas pengguna,
termasuk tanggung jawab, pendidikan, latar belakang, tingkat keterampilan, kegiatan,
dan cara interaksi dengan sistem yang sekarang.

4.3.5.2. Interaksi antara pengguna kelas (3.5.3 dari dokumen ConOps)

Subclause ini menjelaskan interaksi di antara berbagai kelas pengguna

yang terlibat dengan sistem yang sekarang. Secara khusus, interaksi di antara
kelompok pengguna, operator, dan pengelola harus dijelaskan. Interaksi yang
terjadi di antara para pengguna sistem, dan antara pengguna dan non-pengguna,
baik dalam organisasi dan melintasi batas-batas organisasi, jika memang relevan
pengoperasian sistem yang ada, harus dijelaskan. Informal serta interaksi formal
harus dimasukkan.

4.3.5.3. Terlibat Lainnya personel (3.5.4 dari dokumen ConOps)

Ini menggambarkan subclause personil yang lain tidak akan secara langsung
berinteraksi dengan sistem, tetapi yang mempunyai pengaruh terhadap,
dan busur dipengaruhi oleh, sistem sekarang. Contohnya termasuk eksekutif
manajer, pembuat kebijakan, dan pengguna klien. Walaupun orang-orang ini
tidak memiliki tangan-on interaksi dengan sistem, mereka dapat secara signifikan
mempengaruhi, dan dipengaruhi oleh, yang baru atau diubah sistem.

4.3.6. Dukungan lingkungan (3,6 dari dokumen ConOps)

Subclause ini menggambarkan dukungan environmeni konsep dan dukungan

untuk sistem saat ini, termasuk dukungan badan atau lembaga; fasilitas peralatan
perangkat lunak pendukung; perbaikan atau penggantian kriteria tingkat dan siklus
pemeliharaan dan penyimpanan, distribusi, dan metode pasokan.

4.4. Pembenaran untuk perubahan sifat (Pasal 4 dari dokumen ConOps)

 Klausul 4 dari dokumen ConOps menggambarkan kelemahan dari sistem yang
sekarang atau situasi yang memotivasi pengembangan sistem baru atau modifikasi
sistem yang ada. Klausul ini memberikan sebuah transisi dari pasal 3 dari ConOps, yang
menggambarkan sistem yang sekarang atau situasi, untuk Clause.5 dari ConOps, yang
menggambarkan sistem yang diusulkan. Jika tidak ada sistem yang sekarang yang akan
menjadi dasar perubahan, ini harus jadi subclause menunjukkan dan memberikan
pembenaran untuk fitur dari sistem baru.

4.4.1. Pembenaran untuk perubahan (4.1 dari dokumen ConOps)

Subclause ini harus:

a. Secara ringkas meringkas baru atau diubah aspek kebutuhan pengguna, misi,
tujuan, lingkungan, interface, personalia,, atau faktor lain yang memerlukan
sistem baru atau yang diubah;
b. Ringkaskan UV kekurangan atau keterbatasan dari sistem yang sekarang atau
situasi yang membuatnya tidak mampu untuk merespon faktor-faktor baru atau
yang diubah dan
c. Menyediakan pembenaran untuk sebuah sistem yang baru atau dimodifikasi.
 Jika sistem yang diusulkan untuk memenuhi peluang baru, menjelaskan
alasan mengapa sebuah sistem baru harus dikembangkan untuk
memenuhi kesempatan ini.
 Jika sistem yang diusulkan meningkatkan operasi arus, menjelaskan alasan
di balik keputusan untuk mengubah sistem yang ada (misalnya, untuk
mengurangi biaya-biaya siklus hidup atau meningkatkan efisiensi personil).
 Jika sistem yang diusulkan menerapkan kemampuan fungsional baru,
menjelaskan mengapa fungsi ini diperlukan.
4.4.2. Deskripsi perubahan yang diinginkan (4,2 dari dokumen
ConOps)
Subclause ini merangkum baru atau diubah kemampuan, fungsi, proses,
antarmuka, dan perubahan lain yang diperlukan untuk merespon faktor-faktor
yang diidentifikasi dalam 4.1. Perubahan harus didasarkan pada sistem yang
sekarang yang dijelaskan dalam Klausul 3 dari dokumen ConOps Jika tidak ada
sistem yang ada sebagai dasar perubahan, ini harus meringkas subclause
kemampuan untuk menjadi yang disediakan oleh sistem baru. Deskripsi ini harus
mencakup berikut ini, yang sesuai:
a. Kemampuan perubahan. Penjelasan tentang fungsi dan fitur yang akan
ditambahkan, dihapus, dan dimodifikasi agar yang baru atau diubah sistem
untuk memenuhi tujuan dan persyaratan.
 b. Sistem pengolahan perubahan. Deskripsi perubahan dalam proses Drocess
atau mengubah data yang akan menghasilkan output yang baru dengan data
yang sama, output yang sama dengan data baru, atau keduanya.
c. Interface perubahan. Deskripsi perubahan dalam sistem yang akan
menyebabkan perubahan dalam antarmuka dan perubahan dalam
antarmuka yang akan menyebabkan perubahan dalam sistem.
d. Personil perubahan. Deskripsi perubahan dalam personil yang disebabkan
oleh persyaratan baru, perubahan dalam kelas pengguna, atau keduanya.
e. Lingkungan perubahan. Deskripsi perubahan dalam lingkungan operasional
yang akan menyebabkan perubahan? dalam fungsi sistem, proses, interface,
atau personil dan / atau perubahan yang harus dilakukan dalam lingkungan
karena perubahan dalam fungsi sistem, proses, interface, atau personil.
f. Operasional perubahan. Deskripsi perubahan pada operasional pengguna
kebijakan, prosedur, metode, atau rutinitas kerja sehari-hari disebabkan oleh
perubahan di atas.
g. Membantu perubahan. Deskripsi perubahan dalam persyaratan dukungan
yang disebabkan oleh perubahan dalam fungsi sistem, proses, interface, atau
personil dan / atau perubahan fungsi sistem, proses, interface, atau personil
yang disebabkan oleh perubahan dalam lingkungan dukungan.
h. Perubahan-perubahan lain. Deskripsi perubahan lain yang akan berdampak
pada pengguna, tetapi yang tidak sesuai dalam salah satu kategori di atas.
4.4.3. Prioritas di antara perubahan (4.3 dari dokumen ConOps)
Subclause ini mengidentifikasi prioritas di antara perubahan yang diinginkan dan
fitur baru. Setiap perubahan harus diklasifikasikan sebagai penting, diinginkan,
atau opsional. Diinginkan dan biaya opsional harus diprioritaskan dalam kelas
mereka. Jika tidak ada sistem yang ada sebagai dasar perubahan, subclause ini
harus mengelompokkan dan memprioritaskan fitur dari sistem yang diusulkan.
A. Fitur penting. Fitur yang harus disediakan oleh sistem yang baru atau
diubah. Dampak yang akan dihasilkan jika fitur yang tidak dilaksanakan
harus dijelaskan untuk setiap fitur penting.
B. Desirable fitur. Fitur yang harus disediakan oleh sistem yang baru atau
dimodifikasi. Fitur diinginkan harus diprioritaskan. Alasan mengapa fitur
deshable harus dijelaskan untuk setiap fitur yang diinginkan.
C. Opsional fitur. Fitur yang mungkin disediakan oleh sistem yang baru atau
dimodifikasi. Fitur opsional harus diprioritaskan. Alasan mengapa fitur
opsional harus dijelaskan untuk setiap fitur opsional. Mengklasifikasikan
perubahan yang diinginkan dan fitur-fitur baru menjadi penting, diinginkan,
dan opsional kategori adalah penting untuk membimbing proses
 pengambilan keputusan selama pengembangan sistem yang diusulkan.
Informasi ini juga membantu dalam kasus anggaran atau jadwal luka atau
overruns, karena memungkinkan penentuan fitur yang harus diselesaikan,
dan mana yang dapat ditunda atau dihilangkan.
4.4.4. Termasuk Perubahan tetapi tidak dianggap (4,4 dari dokumen ConOps)
Subclause ini mengidentifikasi perubahan dan fitur-fitur baru dianggap tetapi
tidak termasuk dalam 4,2 dari ConOps dokumen, dan alasan karena tidak
termasuk mereka. Dengan menggambarkan perubahan dan fitur dianggap tetapi
tidak termasuk dalam usulan sistem, penulis dokumen hasil kegiatan analisis
mereka. Informasi ini dapat berguna untuk personil lain yang terlibat dengan
pengembangan sistem, apakah itu pengguna, pembeli, atau pengembang harus
mereka ingin tahu apakah tertentu.

KONSEP OPERASI (CONOPS) DOKUMEN

 
IEEE Std 1362-1998
 mengubah atau fitur dianggap, dan jika demikian, mengapa hal itu tidak termasuk.
Dalam software khususnya, ada beberapa, jika ada, tanda-tanda luar dari apa yang telah
diubah, diperbaiki atau masih tidak aman atau tidak aman (misalnya, dalam skenario
tertentu atau workarounds).

4.4.5. Asumsi dan kendala (4,5 dari dokumen ConOps)

Subclause ini menggambarkan asumsi atau batasan yang berlaku untuk
perubahan dan fitur baru yang diidentifikasi dalam ketentuan ini. Ini harus
mencakup semua asumsi dan kendala yang akan mempengaruhi pengguna
selama pembangunan dan pengoperasian sistem baru atau diubah. Sebuah
asumsi adalah suatu kondisi yang dianggap benar. Contoh dari asumsi adalah
bahwa sistem akan melipatgandakan beban kerja selama dua tahun, sehingga
sistem baru dengan kinerja yang lebih tinggi diperlukan. Sebuah kendala adalah
pembatasan dikenakan eksternal ditempatkan di baru atau diubah sistem atau
proses yang digunakan untuk mengembangkan atau memodifikasi sistem.
Contoh kendala antarmuka eksternal meliputi persyaratan, dan batas-batas
sesuai jadwal dan anggaran.
4.5. Konsep yang diusulkan untuk sistem (Pasal 5 dari dokumen ConOps)
Klausul ini menggambarkan sistem yang diusulkan hasil dari perubahan yang diinginkan
yang dijelaskan dalam Klausul 4 dari dokumen ConOps. Klausul ini menggambarkan sistem
yang diusulkan pada cara tingkat tinggi, menunjukkan fitur operasional yang akan
diberikan tanpa menentukan detil desain. Metode deskripsi yang akan digunakan dan
tingkat detail dalam deskripsi akan tergantung pada situasi. Tingkat detail harus cukup
untuk sepenuhnya menjelaskan bagaimana sistem yang diusulkan dibayangkan untuk
beroperasi dalam memenuhi kebutuhan pengguna dan kebutuhan pembeli.
Dalam beberapa kasus, mungkin perlu untuk memberikan beberapa detail desain tingkat
di ConOps. Yang tidak boleh mengandung ConOps spesifikasi desain, tetapi mungkin
mengandung beberapa contoh strategi desain khas, untuk tujuan klarifikasi rincian
operasional sistem yang diusulkan. Dalam hal desain sebenarnya kendala perlu
dimasukkan dalam 'deskripsi sistem yang diusulkan, mereka harus secara eksplisit
diidentifikasi sebagai diperlukan untuk menghindari kemungkinan kesalahpahaman.
CATATAN - Jika beberapa fitur sistem yang diusulkan busur sama dengan ciri-ciri sistem
yang asli, maka komentar "tidak berubah" akan muncul setelah nomor dan nama
subclause.
4.5.1. Latar Belakang, tujuan, dan ruang lingkup (5.1 dari dokumen ConOps)
Subclause ini memberikan ikhtisar yang baru atau diubah sistem, termasuk, seperti
yang berlaku, latar belakang, misi, tujuan, dan ruang lingkup. Selain menyediakan
latar belakang untuk sistem yang diusulkan, subclause ini harus memberikan
ringkasan singkat dari motivasi untuk sistem. Contoh motivasi untuk sistem
otomatisasi dapat mencakup tugas-tugas tertentu atau pajak keuntungan dari
peluang baru. Tujuan untuk sistem yang baru atau diubah juga harus didefinisikan,
bersama-sama dengan strategi, solusi, taktik, metode, dan teknik yang diusulkan
untuk mencapai tujuan tersebut. Modus operasi, kelas pengguna, dan interface ke
lingkungan operasional menetapkan cakupan sistem yang diusulkan, yang
dirangkum dalam subclause ini dan didefinisikan secara lebih rinci dalam
subclauses berikutnya.
4.5.2. kebijakan dan kendala Operasional (5,2 dari dokumen ConOps)
Subclause ini menggambarkan kebijakan operasional dan kendala yang berlaku
untuk sistem yang diusulkan. Kebijakan operasional yang telah ditetapkan
keputusan manajemen tentang pengoperasian sistem baru atau diubah, biasanya
dalam bentuk pernyataan umum atau pemahaman yang membimbing kegiatan
pengambilan keputusan. Kebijakan pengambilan keputusan membatasi
kebebasan, tapi jangan biarkan untuk beberapa kebijaksanaan. Operasional
kendala keterbatasan ditempatkan pada operasi sistem yang diusulkan. Contoh
kendala operasional meliputi:
 Sebuah kendala pada jam operasi dari sistem, mungkin dibatasi oleh akses
untuk mengamankan terminal;
 Sebuah kendala membatasi jumlah personil yang tersedia untuk
mengoperasikan sistem;
 Sebuah membatasi kendala pada perangkat keras komputer (misalnya,
harus beroperasi di komputer X); dan
  Sebuah membatasi kendala operasional pada fasilitas, seperti ruang kantor.
Deskripsi sistem yang diusulkan (5,3 dari dokumen ConOps)
Subclause ini akan berisi bagian utama dari deskripsi sistem yang diusulkan.
Ini memberikan gambaran mengenai sistem yang diusulkan, termasuk yang
berikut, yang sesuai:
a. lingkungan operasional dan karakteristiknya;
b. komponen sistem utama dan saling keterkaitan antara komponen-
komponen ini;
c. Penghubung ke sistem eksternal atau prosedur;
d. Kemampuan atau fungsi-fungsi dari sistem yang diusulkan;
e. Grafik dan deskripsi yang menyertainya menggambarkan input, output,
data flow, dan proses manual dan otomatis cukup untuk memahami
sistem yang diusulkan atau situasi dari pengguna sudut pandang;
f. Biaya operasi syste.ns;
g. faktor-faktor risiko operasional;
h. Kinerja karakteristik, seperti kecepatan, throughput, volume, frekuensi;
i. Kualitas atribut, seperti: keandalan, ketersediaan, ketepatan, efisiensi,
upgrade, fleksibilitas, interoperabilitas, Kemampu-rawatan, portabilitas,
usabilitas, supportability, survivability, dan kegunaan, dan
j. Ketentuan selama keselamatan, keamanan, privasi, integritas, dan
kesinambungan operasi dalam keadaan darurat.

Karena tujuan subclause ini adalah untuk menggambarkan sistem yang

diusulkan dan bagaimana harus beroperasi, itu yang tepat untuk menggunakan
alat dan / atau teknik yang melayani tujuan itu. Adalah penting bahwa deskripsi
dari sistem cukup sederhana dan cukup jelas bahwa semua pembaca dimaksud
dokumen dapat sepenuhnya memahaminya. Penting untuk diingat bahwa akan
ConOps ditulis dalam bahasa pengguna. Dalam kebanyakan kasus, hal ini berarti
menghindari terminologi yang spesifik untuk komputer-dengan kata lain, "jargon
komputer." Grafik dan gambar-gambar alat-alat harus digunakan sedapat
mungkin, terutama karena ConOps dokumen harus dimengerti menjadi beberapa
jenis pembaca.

Perangkat grafis yang berguna termasuk, namun tidak terbatas pada,

WBS, diagram N2, urutan atau kegiatan bagan, diagram blok aliran fungsional,
struktur bagan, alokasi bagan, DFDs, objek diagram, storyboard, dan diagram
hubungan entitas.
Deskripsi lingkungan operasional harus mengidentifikasi, sebagaimana
berlaku, fasilitas, peralatan, komputer hardware, software, personalia, dan
 prosedur operasional yang dibutuhkan untuk mengoperasikan sistem yang
diusulkan. Deskripsi ini harus sedetail yang diperlukan untuk memberikan
pembaca pemahaman mengenai angka, versi, kapasitas, dll, dari peralatan
operasional yang akan digunakan. Sebagai contoh, jika sistem yang diusulkan
berisi database, kapasitas unit penyimpanan harus dilengkapi, asalkan informasi
mempengaruhi pengguna kemampuan operasional. Demikian juga, jika sistem
komunikasi menggunakan link, maka kapasitas link tersebut harus dilengkapi jika
mereka menggunakan pengaruh pada kemampuan pengguna atau waktu respon.
Aspek-aspek keselamatan, keamanan, dan privasi yang memberikan pengaruh
pada lingkungan operasi atau operasional dari sistem yang diusulkan harus
dijelaskan. Penulis (s) dari sebuah dokumen ConOps harus mengatur informasi
dalam subclause ini yang sesuai dengan sistem atau situasi, selama uraian yang
jelas tentang sistem yang diusulkan akan tercapai. Jika bagian dari deskripsi yang
produktif, mereka dapat dimasukkan dalam lampiran atau didirikan oleh
referensi. Contoh bahan yang mungkin akan dimasukkan ke dalam appendi .. akan
menjadi kamus data. Contoh bahan yang akan dimasukkan oleh mungkin
referensi rinci operasi manual kebijakan dan prosedur untuk sistem yang
diusulkan.
4.5.3. Model operasi (5,4 dari dokumen ConOps)
Subclause ini menggambarkan berbagai modus operasi untuk mengusulkan sistem
(misalnya, biasa, rusak,
pemeliharaan, pelatihan, darurat, alternatif-situs, masa damai, masa perang,
tanah-based, (cahaya, aktif, dan idle mode). Sertakan semua mode yang berlaku
untuk semua kelas pengguna. Penting mode untuk memasukkan yang mengalami
degradasi, cadangan, dan mode darurat, jika ada seperti Ini terutama berlaku jika
modus ini melibatkan situs-situs geografis yang berbeda dan peralatan yang
memiliki dampak signifikan pada sistem. Subclause ini dapat dibagi lagi menjadi
subclauses tingkat bawah, satu untuk setiap mode dijelaskan. Proses sistem,
prosedur, dan kemampuan atau fungsi harus berkaitan dengan setiap mode.
4.5.4. Pengguna kelas dan personel lain yang Terlibat (5.5 dari dokumen ConOps)
Seorang pengguna kelas dibedakan oleh cara-cara di mana pengguna berinteraksi
dengan sistem. Faktor-faktor yang membedakan kelas pengguna termasuk
tanggung jawab, tingkat keterampilan, aktivitas kerja, dan cara interaksi dengan
sistem. Kelas-kelas pengguna yang berbeda mungkin telah berbeda skenario
operasional untuk interaksi mereka dengan sistem. Dalam konteks ini, pengguna
adalah siapa pun, yang akan berinteraksi dengan sistem yang diusulkan, termasuk
operasional pengguna, entri data personalia, operator sistem, dukungan
operasional personel, perangkat lunak pengelola, dan pelatih.
 Subclause ini dapat dibagi lagi menjadi tingkat rendah subclauses jika membantu
dalam berkomunikasi konten.
4.5.5.1 Struktur Organisasi (5.5.1 dari dokumen ConOps)
subclause ini menggambarkan struktur organisasi dari berbagai kelompok
pengguna dan pengguna kelas yang akan terlibat dengan sistem yang diusulkan.
Bagan organisasi adalah alat grafis berguna untuk tujuan ini.
4.5.5.2 Profil pengguna kelas (5.5.2 dari dokumen ConOps)
Subclause ini menyediakan profil pengguna masing-masing kelas untuk sistem
yang diusulkan. Jika beberapa pengguna memainkan beberapa peran, peran
masing-masing harus diidentifikasi sebagai pengguna terpisah kelas. Setiap user
kelas untuk sistem yang diusulkan, termasuk operator dan pengelola, harus
dijelaskan dalam subclause terpisah. Setiap subclause harus memberikan
penjelasan mengenai kelas pengguna, termasuk responsibi'ities, pendidikan, latar
belakang, tingkat keterampilan, kegiatan, dan membayangkan cara-cara interaksi
dengan sistem yang diusulkan.
4.5.5.3. Interaksi antara pengguna 4.5.5.3 kelas (5.5.3 dari dokumen ConOps) Subclause
ini menjelaskan interaksi di antara berbagai kelas pengguna yang mungkin terlibat
dengan sistem yang diusulkan. Secara khusus, interaksi di antara kelompok
pengguna, operator, dan pengelola harus dijelaskan. Interaksi yang akan terjadi di
antara para pengguna sistem yang diusulkan, dan antara pengguna dan non-
pengguna, baik dalam organisasi dan seluruh organisasi interfacing, jika memang
relevan pengoperasian sistem yang diusulkan, harus dijelaskan. Informal serta
interaksi formal harus dimasukkan.
4.5.5.4 Terlibat Lainnya personel (5.5.4 dari dokumen ConOps)
Ini menggambarkan subclause personil yang lain tidak akan secara langsung
berinteraksi dengan sistem, tetapi yang mempunyai pengaruh terhadap, dan
dipengaruhi oleh sistem yang ada sekarang. Contohnya termasuk eksekutif
manajer, pembuat kebijakan, dan pengguna klien. Walaupun orang-orang ini tidak
memiliki tangan-on interaksi dengan sistem, mereka dapat secara signifikan
mempengaruhi dan dipengaruhi oleh, yang baru atau diubah sistem.

4.5.6 Dukungan lingkungan (5,6 dari dokumen ConOps)

Subclause ini menjelaskan konsep-konsep dukungan dan dukungan lingkungan untuk

sistem yang diusulkan, termasuk dukungan badan atau lembaga; fasilitas peralatan
perangkat lunak pendukung; perbaikan atau penggantian kriteria tingkat dan siklus
pemeliharaan dan penyimpanan, distribusi, dan metode pasokan.

4.6. Scenario Operasional (Pasal 6 dari dokumen ConOps)

Sebuah skenario adalah langkah-demi-langkah deskripsi bagaimana sistem yang
diusulkan harus beroperasi dan berinteraksi dengan para pengguna dan antarmuka
eksternal di bawah keadaan himpunan. Skenario harus dijelaskan dengan cara yang
akan memungkinkan para pembaca untuk berjalan melalui mereka dan mendapatkan
di. pemahaman tentang bagaimana semua berbagai bagian dari sistem yang diusulkan
fungsi dan berinteraksi.
Skenario mengikat bersama semua bagian dari sistem, pengguna, dan entitas
lain dengan menjelaskan bagaimana mereka berinteraksi. Skenario juga dapat
digunakan untuk menggambarkan sistem apa yang tidak boleh dilakukan.
Skenario harus diatur dalam pasal dan subclauses, masing-masing
menggambarkan urutan operasional yang menggambarkan peranan dari sistem, maka
interaksi dengan pengguna, dan interaksi dengan sistem lain.
Skenario operasional harus dijelaskan untuk semua mode operasional dan
semua kelas pengguna diidentifikasi untuk sistem yang diusulkan. Setiap skenario harus
mencakup peristiwa, tindakan, rangsangan, informasi, dan interaksi yang sesuai untuk
memberikan pemahaman yang komprehensif tentang aspek-aspek operasional dari
sistem yang diusulkan. Prototipe, storyboard, dan media lainnya, seperti video atau
hypermedia presentasi, dapat digunakan untuk menyediakan sebagian informasi ini.
Dalam kebanyakan kasus, akan diperlukan untuk mengembangkan beberapa variasi
dari setiap skenario, termasuk satu untuk operasi normal, satu untuk menangani beban
stres, satu untuk penanganan pengecualian, satu untuk operasi mode degradasi, dll
Skenario memainkan beberapa peran penting. Yang pertama adalah untuk mengikat
bersama semua panci individua1 suatu sistem menjadi dipahami secara keseluruhan.
Skenario juga dapat membantu para pembaca sebuah dokumen ConOps memahami
bagaimana semua bagian berinteraksi untuk menyediakan kemampuan operasional. Cf
peran kedua skenario adalah untuk menyediakan pembaca dengan rincian untuk
operasional sistem yang diusulkan; ini memungkinkan mereka untuk memahami
pengguna peran, bagaimana sistem harus beroperasi, dan berbagai
fitur operasional harus disediakan. Skenario juga dapat mendukung pengembangan
model simulasi yang membantu dalam definisi dan alokasi yang diperoleh persyaratan,
identifikasi, dan persiapan prototipe untuk mengatasi isu-isu kunci.
Selain itu, skenario dapat digunakan sebagai dasar untuk mati rancangan pertama
pengguna manual, dan sebagai dasar untuk pengembangan
rencana uji penerimaan. Skenario yang juga berguna bagi pembeli dan pengembang
untuk memverifikasi bahwa sistem desain akan memenuhi kebutuhan pengguna dan
harapan. Skenario dapat disajikan dalam beberapa cara berbeda. Satu pendekatan
adalah untuk menentukan skenario untuk masing-masing fungsi pemrosesan utama
dari sistem yang diusulkan. Dengan menggunakan pendekatan ini, klausul ini akan
 berisi satu subclause untuk setiap proses. Setiap subclause kemudian akan berisi
beberapa tingkat lebih rendah subclauses, satu untuk setiap skenario yang didukung
oleh proses itu. Pendekatan alternatif adalah untuk mengembangkan skenario berbasis
thread, dimana setiap skenario berikut satu jenis tipe transaksi melalui sistem yang
diusulkan. Dalam kasus ini, masing-masing subclause akan berisi satu skenario untuk
tiap jenis interaksi, ditambah skenario untuk mengalami degradasi, stres dimuat, dan
back-up modus operasi. Alternatif lain termasuk mengikuti arus informasi melalui
sistem untuk setiap pengguna kemampuan, mengikuti aliran kontrol, atau berfokus
pada objek-objek dan peristiwa-peristiwa dalam sistem.
Skenario adalah komponen penting dari suatu ConOps, dan karenanya harus
menerima penekanan substansial. Jumlah skenario dan level detail yang ditentukan
akan sebanding dengan risiko yang dirasakan dan kritis proyek.
4.7. Dampak Ringkasan (Pasal 7 dari dokumen ConOps)
Klausul ini menjelaskan tentang dampak operasional sistem yang diusulkan pada
pengguna, para pengembang, dan dukungan pemeliharaan organisasi. Ini juga
menggambarkan dampak sementara pengguna, pembeli, pengembang, dan dukungan
dan pemeliharaan organisasi selama periode waktu ketika sistem baru sedang
dikembangkan, diinstal, atau dilatih. Informasi ini disediakan untuk membolehkan
semua organisasi terpengaruh untuk mempersiapkan perubahan-perubahan yang akan
ditimbulkan oleh sistem baru dan untuk memungkinkan perencanaan pembeli dampak
pada badan atau lembaga, kelompok pengguna, dan dukungan organisasi
pemeliharaan selama pengembangan, dan transisi ke sistem baru.

4.7.1 Dampak Operasional (7.1 ConOps dokumen)

Subclause ini harus dibagi lagi menjadi tingkat rendah untuk menggambarkan
subclauses mengantisipasi dampak operasional di USI r, pengembangan, dan dukungan
atau badan atau lembaga pemeliharaan selama pengoperasian sistem yang diusulkan.

Dampak tersebut dapat mencakup sebagai berikut:

 Interface dengan alternatif primer atau pusat operasi komputer;

 Perubahan dalam prosedur;
 Penggunaan sumber-sumber data baru;
 Perubahan dalam jumlah, jenis, dan waktu data yang akan masukan ke
dalam sistem;
 Perubahan dalam persyaratan penyimpanan data;
 New modus operasi berdasarkan keadaan darurat, bencana, atau kondisi
kecelakaan;
  New metode untuk memberikan masukan data jika data yang dibutuhkan
tidak tersedia;
 Perubahan dalam anggaran operasional dan
 Perubahan dalam risiko operasional.
4.7.2. Dampak Organisasi (7,2 dari dokumen ConOps)
Subclause ini harus dibagi lagi menjadi tingkat rendah untuk menggambarkan
subclauses mengantisipasi dampak operasional pada pengguna, pengembangan,
dan dukungan atau badan atau lembaga pemeliharaan selama pengoperasian
sistem yang diusulkan. Dampak tersebut dapat mencakup sebagai berikut:
 Modifikasi tanggung jawab; tanggung jawab;
 Penambahan atau penghapusan posisi pekerjaan; posisi;
 Training atau pelatihan ulang pengguna; pengguna;
 Perubahan dalam angka, tingkat keterampilan, posisi pengidentifikasi,
atau lokasi personil; personil dan
 Bilangan dan tingkat kemampuan personil yang diperlukan untuk operasi
kontingensi pada satu atau lebih alternatif situs
berikut keadaan darurat, bencana, atau kecelakaan.
4.7.3. Dampak selama perkembangan (7.3 dari dokumen ConOps)
Subclause ini harus dibagi lagi menjadi subclauses tingkat rendah yang
menggambarkan mengantisipasi dampak pada pengguna, pengembangan, dan
dukungan atau badan atau lembaga pemeliharaan selama proyek
pengembangan sistem yang diusulkan.
Dampak tersebut dapat mencakup sebagai berikut:
 Keterlibatan dalam studi, rapat, dan diskusi sebelum penghargaan dari
kontrak;
 User dan dukungan keterlibatan dalam tinjauan dan demonstrasi,
evaluasi kemampuan operasional awal dan berkembang versi sistem,
pengembangan atau modifikasi dari database, dan pelatihan yang
dibutuhkan;
 Paralel pengoperasian sistem baru dan yang sudah ada dan
 Dampak operasional sistem selama pengujian sistem yang diusulkan.
4.8. Analisis sistem yang diusulkan (Klausul 8 atau dokumen yang ConOps)
Klausul ini memberikan analisis manfaat, keterbatasan, keuntungan, kerugian, dan
alternatif dan perdagangan-offs dipertimbangkan untuk sistem yang diusulkan.
4.8.1. Ringkasan perbaikan (8,1 dari dokumen ConOps)
Subclause ini menyediakan kualitatif (dan sejauh mungkin, kuantitatif) ringkasan
manfaat yang dapat diberikan oleh sistem yang diusulkan. Ringkasan ini harus
mencakup barang-barang di bawah ini, sebagaimana berlaku. Dalam setiap kasus,
 manfaat harus berkaitan dengan kekurangan-kekurangan yang diidentifikasi
dalam.
 New kemampuan. Tambahan fitur atau fungsi baru.
 Peningkatan kemampuan. Upgrade ke kemampuan yang ada.
 Dihapus kemampuan. Tidak terpakai, usang, membingungkan, atau
kemampuan berbahaya dihapus.
 Peningkatan kinerja. Waktu respons yang lebih baik, mengurangi
persyaratan penyimpanan, peningkatan mutu, dll
4.8.2. Kekurangan dan keterbatasan (8,2 dari dokumen ConOps)
Subclause ini menyediakan kualitatif (dan sejauh mungkin, kuantitatif) ringkasan
dari kerugian dan / atau keterbatasan dari sistem yang diusulkan. Kekurangan
mungkin termasuk kebutuhan untuk melatih personel, mengatur ulang ruang
kerja, atau perubahan ke gaya baru antarmuka pengguna; keterbatasan mungkin
mencakup fitur yang diinginkan oleh pengguna tetapi tidak termasuk, degradasi
kemampuan yang ada untuk mendapatkan kemampuan baru, atau lebih besar-
daripada-respon yang diinginkan waktu untuk operasi kompleks tertentu.
4.8.3. Alternatif dan trade-off dianggap (8,3 dari dokumen ConOps)
Subclause ini harus menjelaskan alternatif utama dipertimbangkan, trade-off di
antara mereka, dan alasan bagi keputusan tercapai. Dalam konteks dokumen
ConOps, alternatif yang operasional alternatif dan bukan desain alternatif, kecuali
sejauh bahwa alternatif desain mungkin dibatasi oleh kemampuan operasional
yang diinginkan dalam sistem baru. Infonnation ini dapat bermanfaat untuk
menentukan, sekarang dan di kemudian hari, apakah pendekatan tertentu
dianalisis dan dievaluasi, atau mengapa suatu solusi pendekatan atau ditolak.
Informasi ini mungkin akan hilang jika tidak tercatat.
4.9. Catatan (Pasal 9 di dokumen ConOps)
Klausul ini harus berisi informasi tambahan yang akan membantu pemahaman tentang
dokumen ConOps tertentu. Klausul ini harus mencakup suatu urutan sesuai abjad dari
semua akronim dan singkatan, bersama dengan maknanya sebagaimana digunakan
dalam dokumen ini, dan daftar istilah dan definisi apapun yang diperlukan untuk
memahami dokumen.
4.10. Lampiran (Lampiran dari dokumen ConOps)
Untuk memfasilitasi kemudahan penggunaan dan pemeliharaan dokumen ConOps,
beberapa informasi mungkin ditempatkan dalam lampiran dokumen. Grafik dan data
diklasifikasikan contoh khas. Setiap lampiran harus dirujuk dalam tubuh utama dari
dokumen di mana informasi yang biasanya telah disediakan. Lampiran dapat terikat
sebagai dokumen terpisah untuk penanganan lebih mudah.
4.11. Kamus (Istilah dari dokumen ConOps)
 Penyertaan yang jelas dan ringkas tentang definisi istilah yang digunakan dalam
dokumen ConOps (terutama untuk pembaca dokumen ConOps yang mungkin belum
terbiasa) sangat penting. Seorang glossary harus dipelihara dan diperbarui selama
proses analisis dan konsep pengembangan dokumen ConOps. Untuk menghindari
pekerjaan yang tidak perlu akibat salah tafsir, semua definisi harus ditinjau ulang dan
disepakati oleh semua pihak yang terlibat.

Lampiran A

IEEE / EIA 12.207,1-1.997 Compliance Statement (Informatif)

A.1 Overview

Rekayasa Perangkat Lunak Standards Committee (SESC) dari IEEE Computer Society
telah mendukung kebijakan mengadopsi standar internasional. Pada tahun 1995, standar
internasional, 1SO/IEC 12.207, teknologi informasi-Software siklus hidup proses, selesai.
Menetapkan standar kerangka umum untuk proses siklus hidup perangkat lunak, dengan
terminologi yang terdefinisi dengan baik, yang dapat direferensikan oleh industri perangkat
lunak. Pada tahun 1995 dievaluasi SESC ISO / IEC 12207 dan memutuskan bahwa standar harus
diadopsi dan digunakan sebagai dasar untuk proses siklus kehidupan dalam IEEE Software
Engineering Collection. IEEE adaptasi dari ISO / IEC 12207 adalah IEEE / EIA 12.207,0-1.996.
Berisi ISO / IEC 12.207 dan tambahan berikut: meningkatkan pendekatan kepatuhan, proses
siklus hidup tujuan, tujuan data siklus hidup, dan errata. Implementasi ISO / IEC 12.207 dalam
IEEE juga mencakup sebagai berikut:

 IEEE / EIA 12.207,1-1.997, IEEE / EIA Panduan untuk Teknologi Informasi-

Software siklus hidup Siklus hidup proses-data;
 IEEE / EIA 12.207,2-1.997, IEEE / EIA Panduan untuk Teknologi Informasi-
Software siklus hidup-Pelaksanaan proses pertimbangan dan
 Penambahan sampai 11 SESC standar yang ada (yakni, Stds IEEE 730, 828, 829,
830, 1012, 1016, 1058, 1062,1219, 1233, dan 1362) untuk menentukan korelasi
antara data yang dihasilkan oleh SESC ada standar dan data dihasilkan oleh
penerapan IEEE / EIA 12.207,1-1.997.

CATATAN
 Meskipun IEEE / EIA 12.207,1-1.997 adalah panduan, juga mengandung ketentuan untuk
aplikasi sebagai standar sesuai dengan persyaratan tertentu. Lampiran ini memperlakukan
IEEE / EIA 12.207,1-1.997 sebagai standar. Untuk mencapai sesuai dengan kedua standar ini
dan IEEE / EIA 12207,1 -1997, adalah penting bahwa pengguna meninjau dan memenuhi
persyaratan data untuk kedua standar. Ketika standar ini secara langsung direferensikan, yang
Urutan untuk kesesuaian didasarkan pada standar ini sendirian. Ketika standar ini adalah
direferensikan dengan IEEE / EIA standar 12207.x seri, yang Urutan untuk kesesuaian
didasarkan atas direferensikan langsung IEEE / EIA standar 12207.x, kecuali ada pernyataan
bahwa standar ini telah diutamakan.

A.1.1 Ruang Lingkup dan tujuan

Kedua standar ini dan IEEE / EIA tempat 12207,1 -1997 persyaratan pada dokumen ConOps.
Tujuan dari lampiran ini adalah untuk menjelaskan hubungan antara dua set persyaratan,
sehingga pengguna akan menghasilkan dokumen yang dimaksudkan untuk
memenuhi kedua standar dapat melakukannya.

A.2 Korelasi

Klausul ini menjelaskan hubungan antara standar ini dan IEEE/E1A 12.207,0-1.996 di bidang-
bidang berikut: terminologi, proses, dan siklus hidup data.

A.2.1 Terminologi korelasi

Kedua standar ini dan lEEE / EIA 12.207,0-1.996 memiliki semantik yang sama untuk tenns kunci
perubahan, kendala, lingkungan, modus operasi, kebijakan, dan sistem.

A.2.2 Proses korelasi

Standar ini tidak ada persyaratan pada tempat-tempat proses.

A.2.3 Hidup data siklus konsep korelasi dan operasi dokumen

Informasi yang diperlukan dalam sebuah dokumen ConOps standar ini dan informasi yang
diperlukan dalam sebuah dokumen ConOps oleh IEEE / EIA 12.207,1-1.997 serupa. Masuk akal
untuk mengharapkan bahwa dokumen tunggal dapat memenuhi kedua standar. Kedua
dokumen menggunakan konteks yang berorientasi proses untuk menggambarkan isi dari
dokumen ConOps.
A.2.4 Siklus hidup korelasi antara lain data data Pada IEEE / EIA 12.207,1-1.997 dan standar ini
Ini berkorelasi sublause data siklus kehidupan selain dokumen antara ConOps IEEE / EIA
12.207,1-1.997 dan standar ini. Memberikan informasi kepada pengguna dari kedua standar.
Tabel A-1-Llfe data siklus korelasi antara lain data Pada lEEE / EIA 12.207,1-1.997
dan IEEE Std 1362-1998 Informasi item IEEE / EIA 12.207,0-1.996 Jenis subclause IEEE / EIA
12.207,1-1.997 subclause lEEEStd 1362-1998 subclause Arsitektur sistem alokasi dan
persyaratan deskripsi 5.3.3.1.5.3.3.2 Keterangan 6,25 4.5.3 Dokumen kepatuhan
Klausul ini memberikan rincian berpengaruh pada klaim bahwa dokumen ConOps sesuai
dengan standar ini juga akan mencapai "dokumen kepatuhan" dengan "dokumen ConOps
dijelaskan dalam IEEE / EIA 12207,1 -1997. Persyaratan untuk dokumen kepatuhan dirangkum
dalam satu baris dari Tabel 1 dari IEEE / EIA 12.207,1-1.997. Baris yang direproduksi dalam
Tabel A.2.

Tujuan dari deskripsi adalah: IEEE / EIA 12.207,1-1.997, subclause 5.1.1: Tujuan: Jelaskan yang
direncanakan atau fungsi yang sebenarnya, desain, kinerja, atau proses.
Sebuah dokumen ConOps sesuai dengan standar ini akan mencapai tujuan yang disebutkan.
Deskripsi apapun sesuai dengan IEEE / EIA 12.207,1-1.997 harus memenuhi persyaratan konten
generik 5.1.2 diberikan dalam standar itu. Tabel A.3 standar ini daftar konten generik item dan,
dimana tepat, referensi yang subclause standar ini yang memerlukan informasi yang sama.
Kolom ketiga berisi informasi yang akan ditambahkan dalam rangka untuk memenuhi
persyaratan konten generik.