4.1.2 Panduan Definisi Harapan Pemangku Kepentingan

4.2 definisi persyaratan teknis

Catatan: Penting untuk diperhatikan bahwa tim tidak boleh hanya mengandalkan persyaratan yang diterima untuk merancang dan membangun sistem. Komunikasi dan pengulangan dengan pemangku kepentingan yang relevan sangat penting untuk memastikan pemahaman bersama tentang setiap persyaratan. Jika tidak, para perancang akan menghadapi risiko kesalahpahaman dan mengimplementasikan solusi yang tidak diinginkan untuk interpretasi yang berbeda dari persyaratan. Komunikasi pemangku kepentingan yang berulang ini merupakan bagian yang sangat penting dalam validasi proyek. Selalu pastikan bahwa produk dan hasil yang tepat sedang dikembangkan.

Proses Definisi Persyaratan Teknis mengubah ekspektasi pemangku kepentingan menjadi definisi masalah dan kemudian menjadi satu set lengkap persyaratan teknis tervalidasi yang dinyatakan sebagai pernyataan “harus” yang dapat digunakan untuk mendefinisikan solusi desain untuk Struktur Perincian Produk (PBS) dan produk pendukung terkait. Proses definisi persyaratan adalah proses rekursif dan berulang yang mengembangkan persyaratan pemangku kepentingan, persyaratan produk, dan persyaratan produk/komponen tingkat yang lebih rendah. Persyaratan harus memungkinkan deskripsi semua input, output, dan hubungan yang diperlukan antara input dan output, termasuk batasan, dan interaksi sistem dengan operator, pengelola, dan sistem lainnya. Dokumen persyaratan mengatur dan mengkomunikasikan persyaratan kepada pelanggan dan pemangku kepentingan lainnya serta komunitas teknis.

Kegiatan definisi persyaratan teknis berlaku untuk definisi semua persyaratan teknis dari tingkat program, proyek, dan sistem hingga ke dokumen persyaratan produk/komponen tingkat terendah.

4.2.1 deskripsi proses

Gambar 4.2-1 memberikan diagram alir tipikal untuk Proses Definisi Persyaratan Teknis dan mengidentifikasi input, output, dan aktivitas tipikal yang perlu dipertimbangkan dalam menangani definisi persyaratan teknis.

^{_{Sumber: nasa.gov gambar 4.2-1 proses definisi persyaratan teknis}}

4.2.1.1 Masukan

Masukan umum yang diperlukan untuk proses persyaratan meliputi hal-hal berikut:

• Harapan pemangku kepentingan dasar: Ini adalah serangkaian harapan pemangku kepentingan yang telah disepakati (misalnya, kebutuhan, tujuan, sasaran, asumsi, kendala, antarmuka eksternal) untuk produk dari lapisan produk ini.
• Konsep dasar operasi: Ini menjelaskan bagaimana sistem akan dioperasikan selama fase siklus hidup untuk memenuhi harapan pemangku kepentingan. Hal ini menggambarkan karakteristik sistem dari perspektif operasional dan membantu memfasilitasi pemahaman tentang tujuan, sasaran, dan batasan sistem. Ini mencakup skenario, kasus penggunaan, dan/atau Design Reference Missions (DRM) yang sesuai untuk proyek tersebut. Hal ini dapat berupa dokumen, grafik, video, model, dan/atau simulasi.
• Strategi dukungan pendukung dasar: Hal ini menjelaskan produk pendukung yang diidentifikasi dalam Proses Definisi Harapan Pemangku Kepentingan yang diperlukan untuk mengembangkan, menguji, memproduksi, mengoperasikan, atau membuang produk akhir. Strategi ini juga mencakup deskripsi tentang bagaimana produk akhir akan didukung sepanjang siklus hidup.
• Ukuran efektivitas: MOE ini diidentifikasi selama Proses Definisi Harapan Pemangku Kepentingan sebagai ukuran yang dianggap perlu dipenuhi oleh para pemangku kepentingan agar proyek dapat dianggap sukses (yaitu, untuk memenuhi kriteria keberhasilan).

Masukan lain yang mungkin berguna dalam menentukan persyaratan teknis:

• Alokasi Fungsi Manusia/Sistem: Hal ini menjelaskan interaksi sistem perangkat keras dan perangkat lunak dengan semua personil dan infrastruktur pendukungnya. Ketika operator manusia merupakan komponen sistem total yang penting, peran dan tanggung jawab manusia di dalam sistem harus dipahami dengan jelas. Hal ini harus mencakup semua interaksi manusia/sistem yang diperlukan untuk sebuah misi termasuk perakitan, operasi di darat, logistik, pemeliharaan di dalam dan di darat, operasi di dalam pesawat, dll.

4.2.1.2 kegiatan proses

4.2.1.2.1 Mendefinisikan Kendala, Harapan Fungsional dan Perilaku

Persyaratan dan ekspektasi tingkat atas pada awalnya dinilai untuk memahami masalah teknis yang harus dipecahkan (ruang lingkup masalah) dan menetapkan batas desain. Batasan ini biasanya ditetapkan dengan melakukan aktivitas berikut:

• Mendefinisikan batasan yang harus dipatuhi oleh desain atau yang membatasi bagaimana sistem akan digunakan. Batasan ini biasanya tidak dapat diubah berdasarkan analisis trade-off.
• Mengidentifikasi elemen-elemen yang sudah berada di bawah kendali desain dan tidak dapat diubah. Hal ini membantu menentukan area-area di mana pertukaran lebih lanjut akan dilakukan untuk mempersempit solusi desain potensial.
• Mengidentifikasi sistem eksternal dan pendukung yang harus berinteraksi dengan sistem dan menetapkan antarmuka fisik dan fungsional (misalnya, mekanik, listrik, termal, manusia, dll.).
• Mendefinisikan ekspektasi fungsional dan perilaku untuk berbagai penggunaan sistem yang diantisipasi seperti yang diidentifikasi dalam ConOps. ConOps menjelaskan bagaimana sistem akan dioperasikan dan skenario kasus penggunaan yang mungkin terjadi.

4.2.1.2.2 mendefinisikan persyaratan

Satu set lengkap persyaratan proyek mencakup persyaratan yang diuraikan dan dialokasikan ke elemen desain melalui PBS dan persyaratan yang melintasi batas-batas produk. Persyaratan yang dialokasikan ke PBS dapat berupa persyaratan fungsional (fungsi apa yang perlu dilakukan), persyaratan kinerja (seberapa baik fungsi-fungsi ini harus dilakukan), dan persyaratan antarmuka (persyaratan interaksi produk ke produk). Persyaratan lintas sektoral termasuk lingkungan, keselamatan, faktor manusia, dan yang berasal dari “-kemampuan” dan dari standar Desain dan Konstruksi (D&C). Gambar 4.2-2 adalah gambaran umum tentang aliran persyaratan, apa namanya, dan siapa yang bertanggung jawab (memiliki) untuk menyetujui pengabaian.

^{_{Sumber: nasa.gov gambar 4.2-2 aliran, jenis dan kepemilikan persyaratan}}

• Persyaratan fungsional mendefinisikan fungsi apa yang perlu dilakukan untuk mencapai tujuan.
• Persyaratan kinerja mendefinisikan seberapa baik sistem harus menjalankan fungsi-fungsi tersebut.

Dengan pemahaman menyeluruh tentang batasan, antarmuka fisik/fungsional, dan ekspektasi fungsional/perilaku, persyaratan dapat didefinisikan lebih lanjut dengan menetapkan kinerja dan kriteria teknis lainnya. Kinerja yang diharapkan dinyatakan sebagai ukuran kuantitatif untuk menunjukkan seberapa baik setiap fungsi produk harus dicapai.

Catatan: Persyaratan dapat dihasilkan dari pemangku kepentingan yang tidak jelas dan mungkin tidak secara langsung mendukung misi saat ini dan tujuannya, tetapi memberikan peluang untuk mendapatkan manfaat atau informasi tambahan yang dapat mendukung Agensi atau Negara. Di awal proses, perekayasa sistem dapat membantu mengidentifikasi area potensial di mana sistem dapat digunakan untuk mengumpulkan informasi unik yang tidak terkait langsung dengan misi utama. Seringkali kelompok luar tidak menyadari tujuan dan kemampuan sistem hingga hampir terlambat dalam prosesnya.

Persyaratan teknis berasal dari sejumlah sumber termasuk fungsional, kinerja, antarmuka, lingkungan, keselamatan, antarmuka manusia, standar dan untuk mendukung “kemampuan” seperti keandalan, keberlanjutan, kemampuan produksi, dan lainnya. Pertimbangan dan penyertaan semua jenis persyaratan diperlukan untuk membentuk seperangkat persyaratan teknis yang lengkap dan konsisten yang darinya sistem akan diarsiteki dan dirancang. Gambar 4.2-3 menunjukkan contoh dari alur kebutuhan induk dan anak.

Pernyataan fungsi awal

Pengendali Vektor Dorong (TVC) harus menyediakan kontrol kendaraan tentang sumbu pitch dan yaw.

Pernyataan ini menjelaskan fungsi tingkat tinggi yang harus dilakukan oleh TVC. Tim teknis perlu mengubah pernyataan ini menjadi serangkaian persyaratan desain-ke-fungsional dan kinerja.

Persyaratan fungsional dengan persyaratan kinerja terkait

• TVC harus melakukan gimbal pada mesin maksimal 9 derajat, ± 0,1 derajat.
• TVC harus mengimbangi mesin dengan kecepatan maksimum 5 derajat/detik ± 0,3 derajat/detik.
• TVC harus memberikan kekuatan 40.000 pound, ± 500 pound.
• TVC harus memiliki respons frekuensi 20 Hz, ± 0,1 Hz.

^{_{Sumber: nasa.gov gambar 4.2-3 alur persyaratan}}

4.2.1.2.3 mendefinisikan persyaratan dalam pernyataan yang dapat diterima

Terakhir, persyaratan harus didefinisikan dalam pernyataan “harus” yang dapat diterima, yang merupakan kalimat lengkap dengan satu kata “harus” per pernyataan. Alasan untuk persyaratan juga harus dicantumkan untuk memastikan alasan dan konteks dari persyaratan tersebut dapat dipahami. Persyaratan Pendorong Utama (Key Driving Requirements/KDR) harus diidentifikasi. Ini adalah persyaratan yang dapat berdampak besar pada biaya atau jadwal ketika diimplementasikan. KDR dapat memiliki prioritas atau kekritisan. Mengetahui dampak KDR terhadap desain memungkinkan pengelolaan persyaratan yang lebih baik.

Lihat Lampiran C untuk panduan dan daftar periksa tentang cara menulis persyaratan yang baik dan Lampiran E untuk memvalidasi persyaratan. Dokumen persyaratan yang ditulis dengan baik memberikan beberapa manfaat khusus bagi para pemangku kepentingan dan tim teknis seperti yang ditunjukkan pada Tabel 4.2-1.

Berguna untuk menangkap informasi tentang setiap persyaratan, yang disebut metadata, untuk referensi dan penggunaan di masa mendatang. Banyak alat bantu manajemen kebutuhan akan meminta atau memiliki opsi untuk menyimpan jenis informasi ini. Tabel 4.2-2 memberikan contoh jenis metadata yang mungkin berguna.

^{_{Sumber: nasa.gov}}

Alasan harus selalu diperbarui dan mencakup informasi berikut:

• Alasan untuk Pprsyaratan: Seringkali alasan untuk persyaratan tidak jelas, dan mungkin hilang jika tidak dicatat saat persyaratan didokumentasikan. Alasannya dapat mengarah pada batasan atau konsep operasi. Jika ada persyaratan induk yang jelas atau studi perdagangan yang menjelaskan alasannya, maka itu harus direferensikan.
• Asumsi dokumen: Jika persyaratan ditulis dengan asumsi penyelesaian program pengembangan teknologi atau misi teknologi yang sukses, asumsi tersebut harus didokumentasikan.
• Hubungan dokumen: Hubungan dengan operasi produk yang diharapkan (misalnya, harapan tentang bagaimana pemangku kepentingan akan menggunakan produk) harus didokumentasikan. Hal ini dapat dilakukan dengan menghubungkannya dengan ConOps.
• Kendala desain dokumen: Kendala yang dikenakan oleh hasil dari keputusan yang dibuat saat desain berkembang harus didokumentasikan. Jika persyaratan menyatakan metode implementasi, alasannya harus menyatakan mengapa keputusan dibuat untuk membatasi solusi pada satu metode implementasi.

4.2.1.2.4 memvalidasi persyaratan teknis

Bagian penting dari definisi persyaratan adalah validasi persyaratan terhadap harapan pemangku kepentingan, tujuan dan kendala misi, konsep operasi, dan kriteria keberhasilan misi. Memvalidasi persyaratan dapat dibagi menjadi enam langkah:

1. Apakah Persyaratan Ditulis dengan Benar? Mengidentifikasi dan memperbaiki kesalahan format pernyataan “harus” dan kesalahan editorial.
2. Apakah Persyaratan Secara Teknis Sudah Benar? Beberapa peninjau terlatih dari tim teknis mengidentifikasi dan menghapus sebanyak mungkin kesalahan teknis sebelum meminta semua pemangku kepentingan yang relevan untuk meninjau persyaratan. Peninjau harus memeriksa bahwa pernyataan persyaratan (a) memiliki penelusuran dua arah ke ekspektasi pemangku kepentingan yang telah ditetapkan; (b) dibentuk dengan menggunakan asumsi yang valid; dan (c) sangat penting dan konsisten dengan merancang dan mewujudkan bentuk solusi produk yang sesuai yang akan memenuhi kriteria keberhasilan fase siklus hidup produk yang berlaku.
3. Apakah Persyaratan Memuaskan Pemangku Kepentingan? Semua kelompok pemangku kepentingan yang relevan mengidentifikasi dan menghilangkan cacat.
4. Apakah Persyaratan Dapat Dilaksanakan? Semua persyaratan harus masuk akal secara teknis dan memungkinkan untuk dicapai.
5. Apakah Persyaratan Dapat Diverifikasi? Semua persyaratan harus dinyatakan dengan cara dan dengan informasi yang cukup sehingga memungkinkan untuk memverifikasi persyaratan setelah produk akhir diimplementasikan.
6. Apakah Persyaratannya Berlebihan atau Terlalu Spesifik? Semua persyaratan harus unik (tidak redundan dengan persyaratan lain) dan diperlukan untuk memenuhi fungsi, kinerja, atau perilaku yang diperlukan.

Hasil validasi persyaratan sering kali menjadi faktor penentu apakah akan melanjutkan ke proses berikutnya yaitu Logical Decomposition atau Design Solution Definition. Tim proyek harus siap untuk:

1. Menunjukkan bahwa persyaratan proyek sudah lengkap dan dapat dimengerti;
2. Menunjukkan bahwa kriteria evaluasi konsisten dengan persyaratan dan konsep operasi dan logistik;
3. Mengkonfirmasi bahwa persyaratan dan MOE konsisten dengan kebutuhan pemangku kepentingan;
4. Menunjukkan bahwa konsep operasi dan arsitektur mendukung kebutuhan misi, tujuan, sasaran, asumsi, pedoman, dan kendala; dan Menunjukkan bahwa proses untuk mengelola perubahan persyaratan telah dibuat, didokumentasikan dalam repositori informasi proyek, dan dikomunikasikan kepada para pemangku kepentingan.

4.2.1.2.5 mendefinisikan MOP dan TPM

Ukuran Kinerja (Measures of Performance/MOPs) mendefinisikan karakteristik kinerja yang harus ditunjukkan oleh sistem ketika digunakan dan dioperasikan di lingkungan yang dimaksudkan. MOPs berasal dari MOE tetapi dinyatakan dalam istilah yang lebih teknis dari sudut pandang pemasok. Biasanya, beberapa MOP, yang bersifat kuantitatif dan terukur, diperlukan untuk memenuhi MOE, yang dapat bersifat kualitatif. Dari sudut pandang verifikasi dan penerimaan, MOP mencerminkan karakteristik sistem yang dianggap perlu untuk mencapai MOE.

Ukuran Kinerja Teknis (TPM) adalah karakteristik fisik atau fungsional dari sistem yang terkait dengan atau ditetapkan dari MOP yang dianggap penting atau kunci keberhasilan misi. TPM dipantau selama implementasi dengan membandingkan pencapaian aktual saat ini atau estimasi terbaik dari parameter dengan nilai-nilai yang diantisipasi untuk waktu saat ini dan diproyeksikan untuk tanggal di masa depan. TPM digunakan untuk mengonfirmasi kemajuan dan mengidentifikasi kekurangan yang dapat membahayakan pemenuhan persyaratan sistem yang kritis atau menempatkan proyek pada risiko biaya atau jadwal.

4.2.1.2.6 menetapkan dasar persyaratan teknis

Setelah persyaratan teknis diidentifikasi dan divalidasi sebagai persyaratan yang baik (jelas, benar, lengkap, dan dapat dicapai), dan persetujuan telah diperoleh oleh pelanggan dan pemangku kepentingan utama, persyaratan tersebut dibuat berdasarkan garis dasar dan ditempatkan di bawah kendali konfigurasi. Biasanya, Tinjauan Persyaratan Sistem (System Requirements Review/SRR) diadakan untuk memberikan komentar pada setiap perubahan yang diperlukan dan untuk mendapatkan kesepakatan pada serangkaian persyaratan sehingga dapat di-baseline. Untuk informasi tambahan tentang SRR, lihat Bagian 6.7.

4.2.1.2.7 menangkap produk kerja

Produk kerja yang dihasilkan selama kegiatan di atas harus dicatat bersama dengan keputusan-keputusan penting yang dibuat, alasan dan asumsi pendukung keputusan, dan pelajaran yang dipetik dalam melakukan kegiatan ini.

4.2.1.3 keluaran

• Persyaratan Teknis yang divalidasi: Ini adalah serangkaian persyaratan yang disetujui yang mewakili deskripsi lengkap dari masalah yang harus diselesaikan dan persyaratan yang telah divalidasi dan disetujui oleh pelanggan dan pemangku kepentingan. Contoh dokumen yang menangkap persyaratan adalah Dokumen Persyaratan Sistem (SRD), Dokumen Persyaratan Proyek (PRD), Dokumen Persyaratan Antarmuka (IRD), dan Spesifikasi Persyaratan Perangkat Lunak (SRS).
• Ukuran Kinerja: Ini adalah ukuran kuantitatif yang teridentifikasi yang, ketika dipenuhi oleh solusi desain, membantu memastikan bahwa satu atau lebih MOP akan terpenuhi. Mungkin ada dua atau lebih MOP untuk setiap MOE.
• Ukuran Kinerja Teknis: Ini adalah serangkaian ukuran kinerja yang dipantau dan menjadi tren dengan membandingkan pencapaian aktual saat ini dari parameter dengan yang diharapkan atau diperlukan pada saat itu. TPM digunakan untuk mengonfirmasi kemajuan dan mengidentifikasi kekurangan.

Disadur dari: nasa.gov