Requirement Document atau yang
lebih dikebal Dokumen kebutuhan Sistem, merupakan dokumen yang berisi rincian
kebutuhan user. Requirement Document
harus bersifat jelas dan lengkap, sehingga Tim Proyek (Project Team
dapat memahami seluruh masalah-masalah yang dihadapi oleh user dan dapat
memperkirakan biaya penyelesaian proyek tersebut.. Kejadian penting pertama
yang akan Anda hadapi berupa persetujuan atau penandatanganan dokumen ini oleh
User dan Project Team.
Requirement Document juga
menyatakan masalah-masalah yang dihadapi user dan solusi umum yang dibutuhkan.
Bahasanya berorientasi pada bahasa yang digunakan oleh user sehari-hari, dan
jauh dari bahasa komputer. Kadangkala dokumen ini digunakan sebagai permohonan
untuk sebuah proposal (Request for a proposal (RFP)) ketika user
menawarkan proyeknya kepada 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 ole h komputer, dan sehingga hal ini membuat
dokumen RD tidak menentu tujuan pembuatannya. User sendiri bahkan tidak bias
menerangkan kebutuhan apa saja yang diperlukan secara tepat.
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.
HAL-HAL
YANG TERDAPAT DALAM REQUIREMENT DOCUMENT
1.
Pendaluluan
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. Bagian ini digunakan
untuk memperkenalkan potensi penjual kepada perusahaan user atau departemen
jika diperlukan, jelaskan kultur, lingkungungan, dan bagaimana jalannya bisnis
yang dilakukan. Berikan pengertian kepada Tim Proyek tentang masalah yang
dihadapi user.
2.
Tujuan Proyek (Project Goals)
Sebuah
pernyataan singkat mengapa kita mengajukan proposal untuk pengembangan proyek.
Batasan-batasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan
di sini.
3.
Fungsi-Fungsi Utama
Pernyataan
singkat mengenai bagaimana sistem berfungsi berdasarkan tujuan proyek 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)
Menjelaskan kinerja dari sistem secara rinci. Berapa banyak transaksi
yang akan diproses, berapa banyak data yang akan disimpan, kapan laporan harus
dihasilkan, dan sebagainya. 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. Jika sistem hanya
dapat berjalan dengan komputer yang ada, atau harus dapat deprogram dengan
bahasa yang spesifik, semua dokumen dinyatakan di dalam bagian ini.
10. Reabilitas,
Ketersediaan
penggambaran
waktu diantara kegagalan-kegagalan (Meantime between Failures / MTBF), waktu
untuk perbaikan (Meantime to Repair / MTTR) dan persentase tambahan yang
diperlukan. Semua manufaktur menyatakan penggambaran ini untuk hardware mereka.
11. Pengantarmukaan
Dengan Pemakai
Rincikan pengalaman pengalaman yang dibutuhkan user 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
Jika RD adalah RFP dalam situasi yang kompetitif, mintalah data dari
penjual yang menjelaskan mengapa dokumen tersebut harus dipilih. Minta data
yang relevan dari penjual yang berpengalaman, komitmen, metodologi proyek,
contoh-contoh proyek yang sukses, dan referensi dimana anda dapat menghubungi
penjual tersebut.
16. Persyaratan
dan Kondisi
Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.
Daftar Pustaka
- · Sommerville, Ian & Pete Sawyer. (1997). Requirements Engineering: A good practice guide. West Sussex, England: John Wiley & Sons.
- · Silfi, Widya. Fase Definisi, Memahami Masalah User. http://wsilfi.staff.gunadarma.ac.id/. Diakses pada tanggal 1 April 2013.
- · Wayan, I Simri Wicaksana. Prof., Dr. Memahami Masalah Yang Dihadapi Oleh User. http://iwayan.info. Diakses pada tanggal 1 April 2013.
- · Requirement Document. www.cs.odu.edu. 2001. Diakses pada tanggal 1 April 2013.
- Chaerunnisa, Ullya. Pengantar Requirement Dokumen. http://ichaicha.blogspot.com. 2010. Diakses pada Tanggal 31 Maret 2013.
Tidak ada komentar:
Posting Komentar