Jumat, 29 Maret 2013

Requirement Document


Dokumen Kebutuhan Sistem (System Requirement Document)

Dokumen RD menyatakan tentang masalah-masalah yang dihadapi user dan solusisolusi
umum yang dibutuhkan. Bahasannya berorientasi pada bahasa yang digunakan
oleh user sehari-hari, dan jauh dari bahasa komputer.
Dokumen RD terkadang dipakai sebagai Request for a Proposal (RFP) ketika user
menawarkan proyeknya kepada pemborong/kontraktor luar.
Tim Proyek (PT) hanya dapat memulai proyeknya setelah menerim dokumen RD
yang akurat. Dalam hal ini manajemen proyek akan langsung dimulai setelah dokumen
RD terlengkapi. Tetapi bagaimanapun juga dokumen RD yang ditulis oleh user biasanya
belum terlalu lengkap untuk membuat suatu perkiraan dan pengembangan. Terdapat
alasan-alasan yang cukup sederhana untuk hal diatas. User mungkin kurang begitu tahu
hal-hal apa saja yang dapat dilakukan oleh komputer, dan sehingga hal ini membuat
dokumen RD tidak menentu tujuan pembuatannya. User sendiri bahkan tidak bisa
menerangkan kebutuhan apa saja yang diperlukan secara tepat.
Sebagai contoh, tentang ‘Analogi Rumah’. Bagaimana jika user menginginkan tenda
yang lebih besar dengan penerangan yang baik ? Maka dapat dikatakan, keinginan user
tersebut tidak sesuai dengan house technology.
Dalam hal ini kita juga menghadapi masalah untuk berkomunikasi. Orang-orang
non teknis tidak dapat diharapkan untuk mempe lajari bahasa komputer dalam kaitannya
untuk menyampaikan dan menerangkan kebutuhan-kebutuhan mereka kepada Computer
Analyst. Semua hal tersebut tergantung dengan tim proyek untuk memperhatikan dan
menyelesaikan masalah-masalah yang dikemukakan di atas. Kesimpulannya banyak
waktu yang akan dihabiskan untuk bekerja membantu user untuk dapat menghasilkan
suatu dokumen RD yang baik
Salah satu cara menyusun Dokumen kebutuhan sistem dengan baik ini adalah wawancara langsung dengan client atau user.

Tujuan dibuatnya dokumen kebutuhan sistem ini adalah
  • Untuk menjelaskan cara kerja sistem. Dengan menggunakan dokumentasi kita dapat menjelaskan cara kerja sistem yang rumit dan panjang dalam waktu yang sangat singkat. 
  • Alat dalam merancang sistem informasi. Rancangan sistem informasi sebelum dikembangkan tidak dapat diingat semua oleh disainer. Kalaupun semuanya dapat diingat rancangan itupun perlu dikomunikasiskan kepada orang lain sebelum dikembangkan.
  • Alat bagi auditor dalam mempelajari, mengevaluasi dan sekaligus mendokumentasikan pemahamannya terhadap sistem pengendalian internal kontrol klienny 
·         Dasar pengembangan sistem lebih lanjut  


Abstraksi Dokumen Kebutuhan sistem  
Jika sebuah perusahaan akan mengadakan kontrak untuk proyek pengembangan sistem/software, harus didefinisikan kebutuhan yang cukup pada saat dimana solusi belum terdefinisi.
Kebutuhan harus ditulis sehingga client dapat menawarkan kontrak,penawaran secara berbeda dengan kebutuhan organisasi client.

Bila kontrak sudah diserahkan, kontraktor harus menulis definisi sistem untuk client secara lebih detail sehingga client mengerti dan dapat mem-validasi sistem/software yang akan dikerjakan.
Dokumen ini lah yang disebut dokumen kebutuhan system


Berikut ini adalah bagian-bagian dari RD :
  1. Pendahuluan. Identifikasi perusahaan (user) dan juga penjual dimana RD tersebut ditujukan. Tentukan masalah yang perlu diselesaikan, latar belakang, contoh situasi yang sedang dihadapi, motivasi-motivasi untuk menanggulanginya, dll.
  2. Tujuan Proyek.  Sebuah pernyataan singkat mengapa kita mengajukan proposal untuk pengembangan proyek. Batasan-batasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan.
  3. Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana sistem berfungsi berdasarkan tujuanproyek yang telah ditetapkan.
  4. Keluaran Umum.Penjelasan secara singkat tentang informasi yang dibutuhkan dari sistem
  5. Informasi Input secara Umum.Input data apa yang diperlukan untuk menghasilkan output. Ini adalah waktu yang tepat untuk memastikan bahwa seluruh data yang dibutuhkan dapat tersedia pada waktu yang tepat pula.
  6. Kinerja(Performance).  Berapa banyak transaksi yang akan diproses, berapa banyak data yang akan disimpan, kapan laporan harus dihasilkan, dsb. Jelaskan waktu rata-rata dan waktu maksimal proses (dalam hari atau jam)
  7. Perkembangan(Growth). Hal ini mungkin sulit untuk diramalkan, tetapi cobalah untuk menghitung kemajuan bisnis dan menetapkan berapa tahun lagi sistem masih dapat diharapkan untuk berfungsi. Kemukakan dalam bentuk persentase atau angka sebenarnya.
  8. Pengoperasian dan Lingkungan.  Dimana komputer akan ditempatkan, dimana terminal-terminal yang interaktif ditempatkan, dan siapa yang akan menggunakannya.
  9. Kompatibilitas, Pengantarmukaan. Jelaskan jika fasilitas antar komputer dibutuhkan, adakah alat-alat yang harus disatukan, atau jika pengiriman akses dibutuhkan.
  10. Reliabilitas, Ketersediaan.  Tulis penggambaran waktu diantara kegagalan-kegagalan (Meantime between Failures / MTBF), waktu untuk perbaikan (Meantime to Repair / MTTR) dan persentase tambahan yang diperlukan.
  11. Pengantarmukaan dengan Pemakai.Rincikan pengalaman-pengalaman yang dibutuhkanuser dalam menggunakan komputer, jelaskan bagaimana menangani sistem kapada user yang baru.
  12. Pengaruh Organisasi.Departemen-departemen apa yang akan sangat berpengaruh dan seberapa jauh cara kerja mereka harus berubah. Bagaimana sistem yang baru dapat berkomunikasi dengan sistem manual yang ada.
  13. Pemeliharaan dan Dukungan.  Jaminan-jaminan yang dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman.
  14. Dokumentasi dan Pelatihan.  Rincikan semua dokumen-dokumen umum dan / atau pelatihan yang dibutuhkan.
  15. Keuntungan (hanya RFP). Jika RD adalah RFP dalam situasi yang kompetitif, mintalah data dari penjual yang menjelaskan mengapa dokumen tersebut harus dipilih.
  16. Persyaratan dan Kondisi.Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.


Tipe-Tipe Kebutuhan
  • Kebutuhan User = Pernyataan dalam bahasa natural plus diagram layanan yang tersedia dan batasan operasional.
  • Kebutuhan Sistem = Dokumentasi terstruktur berisi deskripsi detail dan layanan sistem. Ditulis sebagai kontrak antara klien dan kontraktor.
  • Spesifikasi Software = Deskripsi software detail sebagai dasar untuk desain dan implementasi ditulis oleh developer
  
Jenis Kebutuhan
  • Kebutuhan Fungsional 
Pertanyaan layanan sistem yang harus disediakan,bagaimana sistem berinteraksi pada input tertentu dan bagai mana perilaku sistem pada situasi tertentu.
  • Kebutuhan Non-Fungsional 
Batasan Layanan atau fungsi yang ditawarkan sistem seperti batasan waktu, batasan pengembangan proses, standarisasi dll.

Struktur Umum Dokumen Kebutuhan Sistem
  • Pendahuluan
  • Daftar Istilah
  • Definisi Kebutuhan User
  • Arsitektur Sistem
  • Spesifikasi Kebutuhan Sistem
  • Model Sistem
  • Evolusi Sistem
  • Lampiran
  • Index
Daftar pustaka :
1.         wsilfi.staff.gunadarma.ac.id
4.      my-refurbished-laptops.blogspot.com/
5.      jurnal.untad.ac.id/jurnal/index.php/Mektek/article/download/497/427