Menulis Kebutuhan dengan Baik

(Laporan Informasi Sebuah Kebutuhan Kelompok Kerja)

Pendahuluan

Sebuah aspek penting dari rekayasa perangkat lunak adalah mengkonversi  “kebutuhan” pengguna menjadi jelas, ringkas, dan persyaratan sistem yang diverifikasi. Tulisan ini membahas tingkat sistem kebutuhan, yang diterapkan di semua tingkat. Bagian pertama membahas apa yang merupakan kebutuhan yang baik. Ini diikuti dengan sebuah diskusi masalah umum dan bagaimana untuk menghindari kesalahan, termasuk contoh-contoh masalah persyaratan dan bagaimana memperbaikinya.

Kebutuhan Yang Baik

Kebutuhan  yang baik menyatakan sesuatu yang penting, dapat diverifikasi, dan terjangkau. Untuk dapat diverifikasi, kebutuhan harus menyatakan sesuatu yang dapat diverifikasi dengan melakukan pengujian, analisis, pengujian, atau demonstrasi. Setiap kebutuhan harus menyatakan satu pikiran, ringkas, dan sederhana. Hal ini penting bahwa kebutuhan tidak disalah pahami, dan harus jelas.

 

Masalah Umum

Berikut ini adalah daftar masalah yang paling umum pada saat  menulis kebutuhan:

–          Asumsi/pemikiran buruk ( Making Bad Assumptions)

ini terjadi karena penulis kebutuhan tidak punya akses informasi atau informasi yang dibutuhkan tidak ada. Dapat dihindari dengan cara mendokumentasikan informasi yang penting untuk program yaitu : kebutuhan, tujuan, objektif, kendala, misi, konsep operasi, anggaran, jadwal, manajemen/organisasi.

Informasi ini kemudian harus tersedia untuk semua penulis. Anda dapat membuat daftar dari dokumen lain yang relevan dan membuat mudah diakses ke penulis masing-masing.

–          Pelaksanaan (Implementation (HOW/WHAT))

Syarat pertama adalah “menyediakan basis data”. Spesifikasi harus menyatakan APA diperlukan, bukan BAGAIMANA itu harus disediakan. Namun ini adalah kesalahan umum yang dibuat oleh penulis kebutuhan. Kebanyakan penulis tidak melakukan implementasi karena mereka tidak tahu bagaimana melakukan implementasi dengan benar. Untuk menghindarinya, tanyakan pada diri sendiri MENGAPA Anda membutuhkan persyaratan. Ada dua bahaya utama dalam menyatakan implementasi. Yang paling sering adalah bahwa untuk memaksa desain yang tidak diinginkan. Jika semua kebutuhan dapat dipenuhi tanpa data base, maka mengapa ada kebutuhan basis data. Jika mereka tidak dapat dipenuhi, dengan cara yang lebih baik, maka basis data akan menjadi solusi, masalahnya adalah apakah ada atau tidak ada persyaratan untuk basis data.

–          Operasi VS Kebutuhan (Describing Operations Instead of Writing Requirement)

Masalah ini agak mirip dengan masalah implementasi. Misalnya penulis ingin menulis kebutuhan Test Uji Terbang Dengan Aman. Pasal (FTA) Spesifikasi. Pernyataan itu ditulis sebagai gambaran operasi, tidak persyaratan tentang lingkungan.

* FTA aman harus disimpan dalam Orbiter airlock Stowage Bag untuk memulai pendaratan, dan pada orbit.

Kebutuhan  sebenarnya adalah:

* FTA aman harus didesain untuk lingkungan penyimpanan dari airlock Penyimpanan Bag untuk peluncuran, masuk, mendarat, dan on-orbit, sebagaimana didefinisikan dalam TBD.

kebutuhan berikutnya lagi menggambarkan operasi dan membingungkan.

*FTA aman harus dioperasikan oleh anggota Crew EVA memakai ukuran Emu
kecil melalui ekstra besar tanpa membatasi mobilitas sesuai.

 

 

 

–          Penggunaan Istilah (Use Of Terms)

Dalam sebuah spesifikasi, ada istilah harus dihindari dan istilah yang harus digunakan secara sangat spesifik. Penulis perlu memahami penggunaan dari kata “dapat”, “akan”, dan “harus” :

  1. Gunakan “dapat” untuk menulis Kebutuhan
  2. Gunakan “Akan” untuk menulis kalimat kebenaran
  3. Gunakan “Harus” untuk menilis tujuan

Ada sejumlah istilah yang harus dihindari dalam menulis kebutuhan, misalnya : “Dukungan”, “Tapi tidak dibatasi”, “dll”, “dan “/ “atau”.

 

–          Kebutuhan Struktur/Tata Bahasa (Requirement Structure/Grammar)

kebutuhan harus mudah dibaca dan dimengerti. kebutuhan dalam suatu sistem spesifikasi harus baik untuk sistem atau level berikutnya, misalnya subsistem. Setiap kebutuhan biasanya ditulis dalam format:

  • Sistem harus menyediakan ……..
  • Sistem harus mampu ……..
  • The Subsistem # 1 harus menyediakan ……..
  • The Subsistem # 2 harus interface dengan …..

Catatan: Nama sistem anda dan nama setiap subsistem muncul dalam lokasi. Jika Anda memiliki nama kompleks, silakan gunakan singkatan. Setiap kebutuhan harus diverifikasi.  Karena penggunaan istilah yang ambiguistilah. Berikut ini daftar kata-kata ambigu: Memperkecil,Maksimalkan,singkat,User-friendly,Mudah,Cukup,Memadai,Cepat.

–          Kebutuhan Yang Hilang (Missing Requirement)

Hilang item dapat dihindari dengan menggunakan garis standar untuk spesifikasi. Banyak persyaratan terlewatkan karena tim penulisan persyaratan difokuskan pada hanya satu bagian dari system. Berikut ini adalah daftar kebutuhan driver Anda perlu mempertimbangkan : Keandalan, Fungsional , Kinerja, Maintainability, antarmuka, operability,  Lingkungan, Keselamatan, Fasilitas, Peraturan, Transportasi, Keamanan, Deployment, Privasi,  Pelatihan, Desain, kendala, Personil. Anda juga mungkin memiliki sejumlah persyaratan bahwa Anda harus menyertakan referensi. Detil analisis kebutuhan diperlukan untuk menjamin bahwa semua kebutuhan dilindungi.

–          Penetapan Yang Berlebihan (Over Specifying)

spesifikasi yang berlebihan adalah penyebab utama terjadinya overruns biaya pada program. Over-Specifying yang paling sering adalah menyatakan sesuatu yang tidak perlu atau
menyatakan kebutuhan terlalu ketat. Persyaratan yang tidak perlu ada dalam spesifikasi dengan sejumlah cara, satu-satunya untuk memperbaiki adalah manajemen perlahan dengan mencermati ulang dan kontrol.

Contoh: Stasiun Luar Angkasa Fasilitas Pelatihan (SSTF) memiliki persyaratan untuk suatu highfidelity bintang lapangan. Penulis tahu bahwa medan tinggi kesetiaan bintang baru yang sedang dikembangkan untuk Shuttle Mission Simulator (SMS) dan diasumsikan mereka mungkin juga menempatkan sama hal di SSTF. awak perlu latar belakang untuk melihat di luar Stasiun Luar Angkasa, tetapi tidak perlu untuk sebuah bidang bintang tinggi kesetiaan, karena mereka tidak menggunakan bintang-bintang untuk navigasi.

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout /  Ubah )

Foto Google

You are commenting using your Google account. Logout /  Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout /  Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout /  Ubah )

Connecting to %s