Proses Desain Sistem SEH 4.0

Proses desain sistem adalah proses yang saling bergantung, sangat berulang dan rekursif yang menghasilkan seperangkat persyaratan yang divalidasi dan solusi desain yang memenuhi seperangkat harapan pemangku kepentingan. Ada empat proses desain sistem: mengembangkan ekspektasi pemangku kepentingan, persyaratan teknis, dekomposisi logis, dan solusi desain.

_{^{Sumber: nasa.gov gambar 4.0-1 keterkaitan di antara proses-proses desain sistem}}

Gambar 4.0-1 mengilustrasikan hubungan rekursif di antara empat proses desain sistem. Proses-proses ini dimulai dengan tim studi yang mengumpulkan dan mengklarifikasi harapan-harapan pemangku kepentingan, termasuk tujuan misi, kendala, pendorong desain, tujuan operasional, dan kriteria untuk mendefinisikan keberhasilan misi. Kumpulan ekspektasi pemangku kepentingan dan persyaratan tingkat tinggi ini digunakan untuk mendorong loop desain berulang di mana arsitektur/desain manusia, konsep operasi, dan persyaratan turunan dikembangkan. Ketiga produk ini harus konsisten satu sama lain dan akan membutuhkan iterasi dan keputusan desain untuk mencapai konsistensi ini. Setelah konsistensi tercapai, analisis memungkinkan tim proyek untuk memvalidasi desain yang diusulkan terhadap ekspektasi pemangku kepentingan. Validasi yang disederhanakan mengajukan pertanyaan-pertanyaan: Apakah sistem akan bekerja seperti yang diharapkan? Apakah sistem dapat dicapai sesuai dengan batasan anggaran dan jadwal? Apakah sistem menyediakan fungsionalitas dan memenuhi kebutuhan operasional yang mendorong persetujuan pendanaan proyek? Jika jawaban dari pertanyaan-pertanyaan tersebut adalah tidak, maka perubahan pada desain atau ekspektasi pemangku kepentingan akan diperlukan, dan prosesnya dimulai lagi. Proses ini terus berlanjut hingga sistem - arsitektur, ConOps, dan persyaratan - memenuhi ekspektasi pemangku kepentingan.

Kedalaman upaya desain harus cukup untuk memungkinkan verifikasi analitis dari desain terhadap persyaratan. Desain harus layak dan kredibel jika dinilai oleh tim peninjau independen yang berpengetahuan luas dan harus memiliki kedalaman yang cukup untuk mendukung pemodelan biaya dan penilaian operasional.

Setelah sistem memenuhi harapan pemangku kepentingan, tim studi membuat garis dasar produk dan mempersiapkan tahap berikutnya. Seringkali, tingkat dekomposisi menengah divalidasi sebagai bagian dari proses. Pada tingkat dekomposisi berikutnya, persyaratan yang diturunkan (dan dialokasikan) berdasarkan garis dasar menjadi serangkaian persyaratan tingkat tinggi untuk elemen yang didekomposisi dan prosesnya dimulai lagi. Proses desain sistem ini terutama diterapkan di Pra-Fase A dan berlanjut hingga Fase C.

Proses desain sistem selama Pra-Fase A berfokus pada menghasilkan desain yang layak yang akan mengarah pada persetujuan Formulasi. Selama Fase A, desain alternatif dan kematangan analitis tambahan diupayakan untuk mengoptimalkan arsitektur desain. Fase B menghasilkan desain awal yang memenuhi kriteria persetujuan. Selama Fase C, desain yang terperinci dan siap pakai diselesaikan.

Ini adalah deskripsi yang disederhanakan yang dimaksudkan untuk menunjukkan hubungan rekursif di antara proses desain sistem. Proses-proses ini harus digunakan sebagai panduan dan disesuaikan untuk setiap tim studi tergantung pada ukuran proyek dan tingkat hirarki tim studi. Bagian selanjutnya menjelaskan masing-masing dari empat proses desain sistem dan produk terkait untuk misi NASA yang diberikan.

Kunci desain sistem

1. Berhasil memahami dan mendefinisikan tujuan misi dan konsep operasi adalah kunci untuk menangkap harapan pemangku kepentingan, yang akan diterjemahkan ke dalam persyaratan kualitas dan efisiensi operasional selama siklus hidup proyek.
2. Penelusuran persyaratan yang lengkap dan menyeluruh merupakan faktor penting dalam keberhasilan validasi persyaratan.
3. Persyaratan yang jelas dan tidak ambigu akan membantu menghindari kesalahpahaman ketika mengembangkan sistem secara keseluruhan dan ketika membuat perubahan besar atau kecil.
4. Dokumentasikan semua keputusan yang dibuat selama pengembangan konsep desain awal dalam paket data teknis. Hal ini akan membuat filosofi desain asli dan hasil negosiasi tersedia untuk menilai perubahan dan modifikasi yang diusulkan di masa depan.
5. Validasi solusi desain merupakan proses rekursif dan berulang yang berkelanjutan di mana solusi desain dievaluasi terhadap ekspektasi pemangku kepentingan.

4.1 definisi harapan pemangku kepentingan

Proses Definisi Ekspektasi Pemangku Kepentingan adalah proses awal dalam mesin SE yang menetapkan fondasi dari mana sistem dirancang dan produk direalisasikan. Tujuan utama dari proses ini adalah untuk mengidentifikasi siapa saja pemangku kepentingan dan bagaimana mereka berniat untuk menggunakan produk. Hal ini biasanya dicapai melalui skenario kasus penggunaan (kadang-kadang disebut sebagai Design Reference Missions [DRMs]) dan ConOps.

4.1.1 Deskripsi proses

Gambar 4.1-1 memberikan diagram alir tipikal untuk Proses Definisi Ekspektasi Pemangku Kepentingan dan mengidentifikasi input, output, dan aktivitas tipikal yang perlu dipertimbangkan dalam mendefinisikan ekspektasi pemangku kepentingan.

^{_{Sumber: nasa.gov gambar 4.1-1 pposes definisi harapan pemangku kepentingan}}

4.1.1.1 masukan

Masukan umum yang diperlukan untuk Proses Definisi Ekspektasi Pemangku Kepentingan meliputi hal-hal berikut:

• Ekspektasi Pelanggan Awal: Ini adalah kebutuhan, tujuan, sasaran, keinginan, kemampuan, dan kendala lain yang diterima dari pelanggan untuk produk dalam lapisan produk. Untuk produk tingkat atas (produk akhir), ini adalah harapan pelanggan awal yang meminta produk tersebut. Untuk produk akhir dalam lapisan produk, ini adalah harapan dari penerima produk akhir ketika ditransisikan.
• Harapan Pemangku Kepentingan Lainnya: Ini adalah harapan pemangku kepentingan utama selain pelanggan. Misalnya, pemangku kepentingan tersebut dapat berupa tim penguji yang akan menerima produk yang ditransisikan (produk akhir dan produk pendukung) atau pelatih yang akan menginstruksikan operator atau manajer yang bertanggung jawab atas produk pada lapisan ini.
• Persyaratan Aliran ke Bawah Pelanggan: Ini adalah setiap persyaratan yang dialirkan ke bawah atau dialokasikan dari tingkat yang lebih tinggi (yaitu persyaratan induk). Mereka sangat membantu dalam menetapkan harapan pelanggan pada lapisan ini.

4.1.1.2 aktivitas proses

4.1.1.2.1 Mengidentifikasi pemangku kepentingan

“Pemangku kepentingan” adalah kelompok atau individu yang terpengaruh atau memiliki kepentingan dalam produk atau proyek. Para pemain kunci untuk sebuah proyek/produk disebut pemangku kepentingan utama. Salah satu pemangku kepentingan utama adalah “pelanggan”. Pelanggan dapat bervariasi tergantung di mana insinyur sistem bekerja di PBS. Misalnya, di tingkat paling atas, pelanggan mungkin adalah orang atau organisasi yang membeli produk. Untuk insinyur sistem yang bekerja tiga atau empat tingkat di bawah di PBS, pelanggan mungkin adalah pemimpin tim yang mengambil elemen dan mengintegrasikannya ke dalam perakitan yang lebih besar. Terlepas dari di mana insinyur sistem bekerja di dalam PBS, penting untuk memahami apa yang diharapkan oleh pelanggan.

Pihak-pihak lain yang berkepentingan adalah mereka yang memengaruhi proyek dengan memberikan batasan yang luas dan menyeluruh di mana kebutuhan pelanggan harus dicapai. Pihak-pihak ini mungkin terpengaruh oleh produk yang dihasilkan, cara penggunaan produk, atau memiliki tanggung jawab untuk menyediakan layanan dukungan siklus hidup. Contohnya adalah Kongres, tim perencanaan penasihat, manajer program, pengelola, dan mitra misi. Daftar pemangku kepentingan harus diidentifikasi di awal proses, serta pemangku kepentingan utama yang akan memiliki pengaruh paling signifikan terhadap proyek.

Pelanggan dan pengguna sistem biasanya mudah diidentifikasi. Pemangku kepentingan utama lainnya mungkin lebih sulit untuk diidentifikasi dan mereka dapat berubah tergantung pada jenis proyek dan fase proyek. Tabel 4.1-1 memberikan beberapa contoh pemangku kepentingan dalam fase siklus hidup yang harus dipertimbangkan.

^{_{Sumber: nasa.gov Tabel 4.1-1 Identifikasi Pemangku Kepentingan di Seluruh Siklus Hidup}}

4.1.1.2.2 memahami harapan pemangku kepentingan

Memahami secara menyeluruh harapan pelanggan dan pemangku kepentingan utama lainnya terhadap proyek/produk adalah salah satu langkah terpenting dalam proses rekayasa sistem. Hal ini memberikan fondasi yang menjadi dasar bagi semua pekerjaan rekayasa sistem lainnya. Hal ini membantu memastikan bahwa semua pihak memiliki pemahaman yang sama dan bahwa produk yang dihasilkan akan memuaskan pelanggan. Ketika pelanggan, pemangku kepentingan lainnya, dan perekayasa sistem saling menyetujui fungsi, karakteristik, perilaku, tampilan, dan kinerja yang akan ditunjukkan oleh produk, hal ini akan menetapkan ekspektasi yang lebih realistis dari pihak pelanggan dan membantu mencegah persyaratan yang signifikan merambat di kemudian hari dalam siklus hidup.

Melalui wawancara/diskusi, survei, kelompok pemasaran, email, Pernyataan Pekerjaan (SOW), serangkaian persyaratan awal pelanggan, atau cara lain, pemangku kepentingan menentukan apa yang diinginkan sebagai kondisi akhir atau sebagai barang yang akan diproduksi dan memberikan batasan pada pencapaian tujuan. Batasan ini dapat mencakup pengeluaran (sumber daya), waktu untuk menghasilkan, ekspektasi dukungan siklus hidup, tujuan kinerja, kendala operasional, tujuan pelatihan, atau jumlah lain yang kurang jelas seperti kebutuhan organisasi atau tujuan geopolitik. Informasi ini ditinjau, dirangkum, dan didokumentasikan sehingga semua pihak dapat mencapai kesepakatan tentang harapan-harapan tersebut.

Gambar 4.1-2 menunjukkan jenis informasi yang dibutuhkan ketika mendefinisikan ekspektasi pemangku kepentingan dan menggambarkan bagaimana informasi tersebut berkembang menjadi seperangkat persyaratan tingkat tinggi. Garis kuning menggambarkan jalur validasi. Contoh jenis informasi yang akan didefinisikan selama setiap langkah juga disediakan.

^{_{Sumber: nasa.gov gambar 4.1-2 aliran informasi untuk harapan pemangku kepentingan}}

Mendefinisikan ekspektasi pemangku kepentingan dimulai dengan otoritas misi dan tujuan strategis yang ingin dicapai oleh misi tersebut. Otoritas misi berubah tergantung pada kategori misi. Sebagai contoh, misi sains biasanya didorong oleh rencana strategis Direktorat Misi Sains NASA, sedangkan misi eksplorasi mungkin didorong oleh arahan Presiden. Memahami tujuan misi membantu memastikan bahwa tim proyek bekerja untuk mencapai visi yang sama. Tujuan dan sasaran ini menjadi dasar untuk mengembangkan misi, sehingga perlu didefinisikan dan diartikulasikan dengan jelas.

Tim proyek juga harus mengidentifikasi kendala yang mungkin ada. “Kendala” adalah kondisi yang harus dipenuhi. Terkadang kendala ditentukan oleh faktor eksternal seperti mekanika orbit, sistem yang ada yang harus digunakan (antarmuka eksternal), pembatasan peraturan, atau keadaan teknologi; terkadang kendala adalah hasil dari lingkungan anggaran secara keseluruhan. Konsep operasi dan kendala juga perlu disertakan dalam mendefinisikan ekspektasi pemangku kepentingan. Hal ini mengidentifikasi bagaimana sistem harus dioperasikan untuk mencapai tujuan misi.

CATATAN: Sangatlah penting untuk melibatkan para pemangku kepentingan dalam semua fase proyek. Keterlibatan tersebut harus dibangun sebagai lingkaran umpan balik yang mengoreksi diri sendiri yang secara signifikan akan meningkatkan peluang keberhasilan misi. Melibatkan para pemangku kepentingan dalam sebuah proyek akan membangun kepercayaan diri dalam produk akhir dan berfungsi sebagai validasi dan penerimaan dengan audiens target.

Dalam mengidentifikasi serangkaian ekspektasi, insinyur sistem perlu berinteraksi dengan berbagai komunitas, seperti mereka yang bekerja di bidang puing-puing orbital, perlindungan aset ruang angkasa, integrasi sistem manusia, jaminan kualitas, dan keandalan. Memastikan bahwa serangkaian ekspektasi yang lengkap ditangkap akan membantu mencegah fitur “kejutan” muncul di kemudian hari dalam siklus hidup. Sebagai contoh, perlindungan aset ruang angkasa mungkin memerlukan enkripsi tambahan untuk perintah forward link, perisai atau penyaringan tambahan untuk sistem RF, penggunaan frekuensi yang berbeda, atau perubahan desain lainnya yang mungkin mahal untuk ditambahkan ke sistem yang telah dikembangkan.

4.1.1.2.3 mengidentifikasi kebutuhan, sasaran, dan tujuan

Untuk menentukan tujuan dan sasaran, perlu untuk mendapatkan kebutuhan, keinginan, keinginan, kemampuan, antarmuka eksternal, asumsi, dan kendala dari para pemangku kepentingan. Mencapai tujuan dan sasaran yang telah disepakati dapat menjadi tugas yang panjang dan sulit. Iterasi proaktif dengan para pemangku kepentingan selama proses rekayasa sistem adalah cara agar semua pihak dapat mencapai pemahaman yang benar tentang apa yang harus dilakukan dan apa yang diperlukan untuk melakukan pekerjaan tersebut. Penting untuk mengetahui siapa pemangku kepentingan utama dan siapa yang memiliki otoritas keputusan untuk membantu menyelesaikan konflik.

Kebutuhan, Sasaran, dan Tujuan (KST) menyediakan mekanisme untuk memastikan bahwa semua orang (pelaksana, pelanggan, dan pemangku kepentingan lainnya) sepakat di awal proyek dalam hal mendefinisikan masalah yang perlu diselesaikan dan ruang lingkupnya. LSM bukanlah persyaratan atau desain kontrak.

Kebutuhan didefinisikan sebagai jawaban dari pertanyaan “Masalah apa yang ingin kita selesaikan?” Sasaran membahas apa yang harus dilakukan untuk memenuhi kebutuhan; yaitu, apa yang pelanggan ingin sistem lakukan. Sasaran memperluas tujuan dan menyediakan sarana untuk mendokumentasikan ekspektasi yang spesifik. (Alasan harus diberikan jika diperlukan untuk menjelaskan mengapa kebutuhan, tujuan, atau sasaran itu ada, asumsi yang dibuat, dan informasi lain yang berguna dalam memahami atau mengelola LSM).

NGO yang ditulis dengan baik memberikan penelusuran yang jelas dari kebutuhan, kemudian ke tujuan, dan kemudian ke sasaran. Sebagai contoh, jika tujuan tertentu tidak mendukung kebutuhan, atau tujuan tidak mendukung sasaran, maka tujuan tersebut tidak boleh menjadi bagian dari rangkaian LSM yang terintegrasi. Ketertelusuran ini membantu memastikan bahwa tim benar-benar menyediakan apa yang dibutuhkan.

Definisi berikut (sumber: Rekayasa Sistem Ruang Angkasa Terapan yang diedit oleh Larson, Kirkpatrick, Sellers, Thomas, dan Verma) disediakan untuk membantu pembaca menginterpretasikan LSM yang terkandung dalam produk ini.

• Kebutuhan: Sebuah pernyataan tunggal yang mendorong segala sesuatu yang lain. Pernyataan ini harus berhubungan dengan masalah yang seharusnya dipecahkan oleh sistem, namun bukan merupakan solusi. Pernyataan kebutuhan bersifat tunggal. Mencoba untuk memenuhi lebih dari satu kebutuhan membutuhkan pertukaran antara keduanya, yang dapat dengan mudah mengakibatkan kegagalan untuk memenuhi setidaknya satu, dan mungkin beberapa, harapan pemangku kepentingan.
• Tujuan: Penjabaran dari kebutuhan, yang merupakan seperangkat harapan spesifik untuk sistem. Tujuan membahas isu-isu kritis yang diidentifikasi selama penilaian masalah. Tujuan tidak harus dalam bentuk kuantitatif atau terukur, tetapi harus memungkinkan kita untuk menilai apakah sistem telah mencapainya.
• Sasaran: Tingkat target spesifik dari output yang harus dicapai oleh sistem. Setiap sasaran harus berhubungan dengan tujuan tertentu. Secara umum, sasaran harus memenuhi empat kriteria. (1) Tujuan harus cukup spesifik untuk memberikan arahan yang jelas, sehingga pengembang, pelanggan, dan penguji dapat memahaminya. Tujuan harus mengarah pada hasil dan mencerminkan apa yang harus dilakukan oleh sistem, tetapi tidak menguraikan bagaimana cara mengimplementasikan solusi. (2) Sasaran harus dapat diukur, dikuantifikasi, dan diverifikasi. Proyek perlu memantau keberhasilan sistem dalam mencapai setiap tujuan. (3) Sasaran harus agresif namun dapat dicapai, menantang namun dapat dijangkau, dan target harus realistis. Tujuan “Untuk Ditentukan” (TBD) dapat dimasukkan sampai studi perdagangan dilakukan, konsep operasi dimantapkan, atau teknologi menjadi matang. Tujuan harus dapat dilaksanakan sebelum persyaratan ditulis dan sistem dirancang. (4) Tujuan harus berorientasi pada hasil yang berfokus pada keluaran dan hasil yang diinginkan, bukan pada metode yang digunakan untuk mencapai target (apa, bukan bagaimana). Penting untuk selalu diingat bahwa tujuan bukanlah persyaratan. Tujuan diidentifikasi selama pengembangan pra-Fase A dan membantu perumusan persyaratan yang akhirnya ditetapkan, tetapi persyaratan itu sendiri yang mengikat secara kontraktual dan akan diverifikasi terhadap desain sistem “as-built”.

Harapan para pemangku kepentingan ini ditangkap dan dianggap sebagai awal hingga dapat disempurnakan lebih lanjut melalui pengembangan konsep operasi dan kesepakatan akhir oleh para pemangku kepentingan.

4.1.1.2.4 menetapkan konsep operasi dan strategi dukungan

Setelah ekspektasi awal pemangku kepentingan ditetapkan, pengembangan Konsep Operasi (ConOps) selanjutnya akan memastikan bahwa tim teknis sepenuhnya memahami ekspektasi dan bagaimana mereka dapat dipuaskan oleh produk, dan pemahaman tersebut telah disetujui oleh para pemangku kepentingan. Hal ini dapat mengarah pada penyempurnaan lebih lanjut dari serangkaian ekspektasi pemangku kepentingan awal jika ditemukan kesenjangan atau pernyataan yang ambigu. Skenario dan konsep tentang bagaimana sistem akan berperilaku ini memberikan pemahaman bebas implementasi tentang harapan pemangku kepentingan dengan mendefinisikan apa yang diharapkan tanpa membahas bagaimana (desain) untuk memenuhi kebutuhan. Hal ini menangkap karakteristik perilaku yang dibutuhkan dan cara orang akan berinteraksi dengan sistem. Strategi dukungan mencakup ketentuan untuk fabrikasi, pengujian, penerapan, operasi, keberlanjutan, dan pembuangan.

ConOps adalah komponen penting dalam menangkap harapan pemangku kepentingan dan digunakan dalam mendefinisikan persyaratan dan arsitektur proyek. Hal ini merangsang pengembangan persyaratan dan arsitektur yang terkait dengan elemen pengguna sistem. Ini berfungsi sebagai dasar untuk dokumen definisi berikutnya seperti rencana operasi, rencana peluncuran dan orbit awal, dan buku pedoman operasi, dan memberikan dasar untuk kegiatan perencanaan operasional jangka panjang seperti fasilitas operasional, staf, dan penjadwalan jaringan.

ConOps adalah pendorong penting dalam persyaratan sistem dan oleh karena itu harus dipertimbangkan di awal proses desain sistem. Memikirkan ConOps dan kasus penggunaan sering kali mengungkapkan persyaratan dan fungsi desain yang mungkin terlewatkan. Sebagai contoh, menambahkan persyaratan sistem untuk memungkinkan komunikasi selama fase tertentu dari sebuah misi mungkin memerlukan antena tambahan di lokasi tertentu yang mungkin tidak diperlukan selama misi nominal. ConOps harus mencakup skenario untuk semua situasi operasional yang signifikan, termasuk situasi di luar nominal yang diketahui. Untuk mengembangkan serangkaian skenario yang berguna dan lengkap, kerusakan penting dan situasi operasional mode degradasi harus dipertimbangkan. ConOps juga merupakan alat bantu yang penting untuk mengkarakterisasi tujuan staf siklus hidup dan alokasi fungsi antara manusia dan sistem. Dalam menjalani pencapaian tujuan misi, harus menjadi jelas kapan keputusan perlu dibuat tentang apa yang dikontribusikan oleh operator manusia vs. apa yang menjadi tanggung jawab sistem.

ConOps harus mempertimbangkan semua aspek operasi termasuk operasi nominal dan di luar nominal selama integrasi, pengujian, dan peluncuran hingga pembuangan. Informasi umum yang terkandung dalam ConOps mencakup deskripsi fase utama; jadwal operasi; skenario operasional dan/atau DRM (lihat Gambar 4.1-3 untuk contoh DRM); strategi manajemen kesalahan, deskripsi interaksi manusia dan pelatihan yang diperlukan, strategi komunikasi ujung ke ujung; arsitektur komando dan data; fasilitas operasional; dukungan logistik terintegrasi (pasokan ulang, pemeliharaan, dan perakitan); tingkat staf dan keahlian yang diperlukan; dan peristiwa kritis. Skenario operasional menggambarkan pandangan dinamis dari operasi sistem dan mencakup bagaimana sistem dianggap berfungsi di seluruh berbagai mode dan transisi mode, termasuk interaksi dengan antarmuka eksternal, respons terhadap bahaya dan kesalahan yang diantisipasi, dan selama mitigasi kegagalan. Untuk misi eksplorasi, beberapa DRM membentuk sebuah ConOps. Desain dan analisis kinerja yang mengarah pada persyaratan harus memenuhi semuanya.

_{^{Sumber: nasa.gov gambar 4.1-3 contoh DRM sortie bulan di awal siklus hidup}}

Lampiran S berisi satu garis besar yang memungkinkan untuk mengembangkan ConOps. Bagian-bagian spesifik dari ConOps akan bervariasi tergantung pada ruang lingkup dan tujuan proyek.

Konsep operasi vs konsep operasi

Konsep operasi

Dikembangkan di awal Pra-Fase A oleh tim teknis, menggambarkan konsep tingkat tinggi secara keseluruhan tentang bagaimana sistem akan digunakan untuk memenuhi harapan pemangku kepentingan, biasanya dengan cara yang berurutan. Ini menggambarkan sistem dari perspektif operasional dan membantu memfasilitasi pemahaman tentang tujuan sistem. Ini merangsang pengembangan persyaratan dan arsitektur yang terkait dengan elemen pengguna sistem. Ini berfungsi sebagai dasar untuk dokumen definisi berikutnya dan memberikan dasar untuk kegiatan perencanaan operasional jangka panjang.

Konsep operasi

Deskripsi tentang bagaimana sistem penerbangan dan sistem darat digunakan bersama untuk memastikan bahwa konsep operasi masuk akal. Hal ini dapat mencakup bagaimana data misi yang menarik, seperti data teknik atau ilmiah, diambil, dikembalikan ke Bumi, diproses, disediakan untuk pengguna, dan diarsipkan untuk referensi di masa mendatang. Ini biasanya dikembangkan oleh tim operasional. (Lihat NPR 7120.5.)

4.1.1.2.5 mendefinisikan harapan pemangku kepentingan dalam pernyataan yang dapat diterima

Setelah ConOps dikembangkan, kesenjangan atau ambiguitas telah diselesaikan, dan pemahaman antara tim teknis dan pemangku kepentingan tentang apa yang diharapkan/dimaksudkan untuk sistem/produk telah tercapai, harapan dapat didokumentasikan secara formal. Hal ini sering kali muncul dalam bentuk LSM, kriteria keberhasilan misi, dan pendorong desain. Hal ini dapat dicatat dalam dokumen, spreadsheet, model, atau bentuk lain yang sesuai dengan produk.

Penggerak desain akan sangat bergantung pada ConOps, termasuk lingkungan operasional, orbit, dan persyaratan durasi misi. Untuk misi sains, pendorong desain mencakup, setidaknya, tanggal peluncuran misi, durasi, dan orbit, serta pertimbangan operasional. Jika orbit alternatif harus dipertimbangkan, konsep terpisah diperlukan untuk setiap orbit. Misi eksplorasi harus mempertimbangkan tujuan, durasi, urutan operasional (dan perubahan konfigurasi sistem), interaksi kru, kegiatan pemeliharaan dan perbaikan, pelatihan yang diperlukan, dan kegiatan eksplorasi in-situ yang memungkinkan eksplorasi berhasil.

4.1.1.2.6 menganalisis pernyataan harapan untuk mengukur efektivitas

Kriteria keberhasilan misi mendefinisikan apa yang perlu dicapai oleh misi agar berhasil. Hal ini dapat berupa misi sains, konsep eksplorasi untuk misi eksplorasi manusia, atau tujuan teknologi untuk misi demonstrasi teknologi. Kriteria keberhasilan juga mendefinisikan seberapa baik pengukuran konsep atau kegiatan eksplorasi harus dicapai. Kriteria keberhasilan menangkap harapan pemangku kepentingan dan, bersama dengan persyaratan dan kendala program, digunakan dalam persyaratan tingkat tinggi.

Ukuran Efektivitas (Measures of Effectiveness/MOE) adalah ukuran keberhasilan yang dirancang untuk sesuai dengan pencapaian tujuan sistem sebagaimana didefinisikan oleh harapan pemangku kepentingan. Ukuran-ukuran ini dinyatakan dari sudut pandang pemangku kepentingan dan mewakili kriteria yang harus dipenuhi agar pemangku kepentingan dapat menganggap proyek tersebut berhasil. Dengan demikian, mereka dapat disamakan dengan kriteria keberhasilan misi/proyek. MOE dikembangkan ketika LSM atau dokumentasi ekspektasi pemangku kepentingan lainnya dikembangkan. Informasi tambahan mengenai MOE terdapat di Bagian 6.7.2.4 dari dokumen NASA Expanded Guidance for SE di https://nen.nasa.gov/web/se/doc-repository.

4.1.1.2.7 memvalidasi bahwa pernyataan harapan yang ditetapkan mencerminkan ketertelusuran dua arah

LSM atau dokumentasi ekspektasi pemangku kepentingan lainnya juga harus menangkap sumber ekspektasi. Bergantung pada lokasi dalam lapisan produk, ekspektasi dapat ditelusuri ke LSM atau persyaratan produk lapisan yang lebih tinggi, ke rencana strategis organisasi, atau sumber lainnya. Fungsi dan persyaratan selanjutnya akan ditelusuri ke LSM ini. Penggunaan alat atau model manajemen persyaratan atau aplikasi lain sangat berguna dalam menangkap dan menelusuri harapan dan persyaratan.

4.1.1.2.8 mendapatkan komitmen pemangku kepentingan terhadap kumpulan harapan yang telah divalidasi

Setelah pemangku kepentingan dan tim teknis sepakat dengan ekspektasi pemangku kepentingan yang diungkapkan dan konsep operasi, tanda tangan atau bentuk komitmen lainnya diperoleh. Untuk mendapatkan komitmen ini, tinjauan konsep biasanya dilakukan secara formal atau informal, tergantung pada ruang lingkup dan kompleksitas sistem (lihat Bagian 6.7). Harapan pemangku kepentingan (misalnya LSM), KLH, dan konsep operasi dipresentasikan, didiskusikan, dan disempurnakan seperlunya untuk mencapai kesepakatan akhir. Kesepakatan ini menunjukkan bahwa kedua belah pihak telah berkomitmen untuk pengembangan produk ini.

4.1.1.2.9 harapan pemangku kepentingan dasar

Kumpulan ekspektasi pemangku kepentingan (misalnya, LSM dan KLH) dan konsep operasi yang telah disepakati saat ini telah menjadi dasar. Setiap perubahan lebih lanjut akan diminta untuk melalui proses persetujuan formal atau informal (tergantung pada sifat produk) yang melibatkan pemangku kepentingan dan tim teknis.

4.1.1.2.10 Mengabadikan produk kerja

Selain mengembangkan, mendokumentasikan, dan membuat garis dasar ekspektasi pemangku kepentingan, ConOps dan MOE yang dibahas di atas dan produk kerja lainnya dari proses ini harus dicatat. Hal ini dapat mencakup keputusan-keputusan penting yang dibuat, alasan dan asumsi pendukung keputusan, dan pelajaran yang dipetik dalam melakukan kegiatan ini.

4.1.1.3 Keluaran

Keluaran yang umum untuk menangkap harapan pemangku kepentingan meliputi yang berikut ini:

• Harapan Pemangku Kepentingan yang telah divalidasi: Ini adalah serangkaian harapan yang telah disepakati untuk lapisan produk ini. Mereka biasanya ditangkap dalam bentuk kebutuhan, tujuan, dan sasaran dengan kendala dan asumsi yang diidentifikasi. Harapan tersebut juga dapat berupa model atau bentuk grafis lainnya.
• Konsep operasi: ConOps menjelaskan bagaimana sistem akan dioperasikan selama fase siklus hidup yang akan memenuhi harapan pemangku kepentingan. Hal ini menggambarkan karakteristik sistem dari perspektif operasional dan membantu memfasilitasi pemahaman tentang tujuan dan sasaran sistem serta ekspektasi pemangku kepentingan lainnya. Contohnya adalah dokumen ConOps, model, atau Design Reference Mission (DRM).
• Mengaktifkan strategi dukungan produk: Ini mencakup ketentuan khusus yang mungkin diperlukan untuk fabrikasi, pengujian, penerapan, keberlanjutan operasi, dan pembuangan produk akhir. Strategi ini mengidentifikasi dukungan apa saja yang diperlukan dan produk pendukung apa saja yang perlu dikembangkan untuk menghasilkan produk akhir.
• Ukuran efektivitas: Satu set MOE dikembangkan berdasarkan ekspektasi pemangku kepentingan. Ini adalah ukuran yang mewakili harapan yang sangat penting bagi keberhasilan sistem, dan kegagalan untuk memenuhi ukuran ini akan menyebabkan pemangku kepentingan menganggap sistem tersebut tidak dapat diterima.

Output lain yang mungkin dihasilkan:

• Alokasi fungsi manusia atau sistem: Ini menggambarkan interaksi sistem perangkat keras dan perangkat lunak dengan seluruh personel dan infrastruktur pendukungnya. Dalam banyak desain (misalnya penerbangan manusia ke luar angkasa), operator manusia merupakan komponen keseluruhan sistem yang penting dan peran serta tanggung jawab manusia dalam sistem harus dipahami dengan jelas. Hal ini harus mencakup semua interaksi manusia/sistem yang diperlukan untuk suatu misi termasuk perakitan, operasi darat, logistik, pemeliharaan dalam penerbangan dan darat, operasi dalam penerbangan, dll.

Disadur dari: nasa.gov