Requirement Document

Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan pembangun pun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement.
Requirement berfungsi ganda yaitu:
•Menjadi dasar penawaran suatu kontrak –> harus terbuka untuk masukan
•Menjadi dasar kontrak –> harus didefinisikan secara detil
Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan, layanan dan batasan tersebut disebut Requirement Engineering.

Pengumpulan requirement

– Interviews : Memberi informasi yang terbaik,mahal
– Questionnaires: Bagus jika banyak orang terlibat dan tersebar, respon
cenderung kurang baik
– Observation: Akurat jika dilakukan dengan baik, mahal
– Searching :Informasi terbatas, cenderung tidak menampilkan hal-hal yang mungkin jadi masalah.

Beberapa macam requirement :
User requirement (kebutuhan pengguna)
Pernyataan tentang layanan yang disediakan sistem dan tentang batasan batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

System requirement (kebutuhan sistem)
Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

Software design specification (spesifikasi rancangan PL)
• Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

User Requirement
Menggambarkan functional dan non-functional req yang dapat dipahami oleh pengguna (user) yang tidak memiliki latar belakang teknis yang cukup. User requirement menjelaskan perilaku luar dari sistem, tidak secara teknis, karena itu perlu menggunakan bahasa alami, atau bahasa yang sederhana.
Masalah dalam menyiapkan user requirement adalah:
•Bahasa alami kadang tidak cukup untuk menjelaskan, atau membuat
dokumen jadi sulit dibaca
•Jenis-jenis req, kadang jadi sulit dibedakan
•Sering digabungkan menjadi satu kumpulan requirement saja
Dokumen kebutuhan (requirement document)
Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen
desain. Sebisa mungkin berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA sistem mengerjakannya.
Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :
1. menjelaskan perilaku eksternal sistem
2. menjelaskan batasan pada implementasi
3. mudah diubah
4. sebagai alat referensi untuk pemelihara sistem
5. mencatat peringatan awal tentang siklus dari sistem
6. menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal
IEEE menyarankan standar struktur dari dokumen kebutuhan sebagai berikut :
1. introduction
1.1 purpose of the requirement document
1.2 scope of the product
1.3 definitions, acronyms and abbreviations
1.4 references
1.5 overview of the remainder of the document
2. General description
2.1 product perspective
2.2 product functions
2.3 user characteristics
2.4 general constrains
2.5 assumptions and depedencies
3. appendices
4. index
Sekalipun standar IEEE belumlah ideal tetapi telah memberikan masukan format dokumen yang cukup lengkap. Informasi yang dimasukkan ke dalam dokumen tergantung pada tipe software yang dibangun dan pendekatan yang digunakan untuk membangun software tersebut.
Struktur lain yang bisa digunakan adalah sebagai berikut :
1. Preface
2. Introduction
3. Glossary
4. User requirements definition
5. System architecture
6. System requirements specification
7. System models
8. System evolution
9. Appendices
10. Index
Kedua struktur sama baiknya dan salah satu dapat digunakan untuk menyusun dokumen kebutuhan.
Masalah yang mungkin terjadi dalam pendefinisian requirement adalah:
•Sulit mengantisipasi efek dari sistem baru terhadap organisasi
•Beda user, beda pula requirement dan prioritasnya – terpengaruh cara atau gaya
kerja
•End-user sistem, dan organisasi yang membiayai sistem berbeda requirement
•Prototype sering dibutuhkan untuk menjelaskan requirement
•Masalah perbedaan bahasa alami
Software system requirement sering dibedakan dalam 2 katagori yaitu Functional requirement, Non Functional requirement dan domain requirement
dengan masing-masing penjelasannya sebagai berikut:

1. Functional Requirement : Merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana system mengatasi situasi-situasi tertentu. Selain itu kadang-kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem.
Functional requirement menggambarkan system requirement secara detil seperti
input, output dan pengecualian yang berlaku. Contoh dalam kasus peminjaman buku di perpustakaan:
•Pengguna bisa mencari semua informasi tentang buku atau bisa memilih
salah satu dari informasi tentang buku
•Semua peminjam memiliki pengenal yang unik
•Sistem mampu catat transaksi peminjaman, pengembalian dan denda secara
lengkap
•Hari libur bisa di-set sejak awal, dan bisa menerima perubahan dengan
otoritas khusus
•Harus komplit ( kebutuhan layanan jelas dan lengkap) dan konsisten (tidak
kontradiksi dengan yang didefinisikan).
Masalah yang mungkin terjadi dalam menyusun functional requirement adalah:
1. Diintepretasikan/diartikan berbeda oleh user atau developer
2. Hasil intepretasi sering tidak menjawab kebutuhan klien
3. Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan sistem
4. Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan

2. Non-functional Requirement:
Secara umum berisi batasan-batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunan, standar-standar tertentu.

Bagian Requirement Document 

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. 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. 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 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). 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. Jika sistem hanya dapat berjalan dengan komputer yang ada, atau harus dapat diprogram dengan bahasa yang spesifik, semua dokumen dinyatakan di dalam bagian ini.
  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. Semua manufaktur menyatakan penggambaran ini untuk hardware mereka.
  11. Pengantarmukaan dengan Pemakai. Rincikan pengalamanpengalaman 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 (hanya RFP). 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.
Tujuan Requirement Document 
Tujuan dibuatnya dokumen kebutuhan sistem 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 kliennya.
  • Dasar pengembangan sistem lebih lanjut

Bagian Requirement Document 

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. 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. 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 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). 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. Jika sistem hanya dapat berjalan dengan komputer yang ada, atau harus dapat diprogram dengan bahasa yang spesifik, semua dokumen dinyatakan di dalam bagian ini. 
  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. Semua manufaktur menyatakan penggambaran ini untuk hardware mereka. 
  11. Pengantarmukaan dengan Pemakai. Rincikan pengalamanpengalaman 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 (hanya RFP). 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. 
 
Tujuan Requirement Document 
Tujuan dibuatnya dokumen kebutuhan sistem 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 kliennya. 
  • Dasar pengembangan sistem lebih lanjut 

Sumber:

http://nyoman.staf.narotama.ac.id/files/2012/01/salas-requirement-determination.pdf

http://ichachaca.blogspot.com/2010/06/pengantar-requirement-document.html

http://ac-fenrir.blogspot.com/2012/07/system-requirement.html

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 )

Gambar Twitter

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

Foto Facebook

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

Foto Google+

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

Connecting to %s

%d blogger menyukai ini: