REQUIREMENT DOCUMENT

• REQUIREMENT DOCUMENT

  
  

  Dokumen Kebutuhan Sistem

  
  

  I. Pengertian Requirement Document 

  Requirement Document atau dokumen kebutuhan, yaitu dokumen yang berisi rincian kebutuhan user. Requirement Document 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 Requirement Document digunakan sebagai permohonan untuk sebuah proposal (Request for a proposal (RFP)) ketika user menawarkan proyeknya kepada kontraktor luar. 

  
  

  Dalam IEEE Standard Glossary of Software Engineering Technology (IEEE Std 610.12-1990) [IEEE] requirement dapat diartikan sebagai berikut: 

  1.     Suatu kondisi atau kemampuan yang diperlukan oleh user untuk memecahkan

          masalah atau mencapai tujuan. 

  2.     Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau

          komponen sistem untuk memenuhi kontrak, standard, spesifikasi atau dokumen

          formal lain. 

  3.     Gambaran yang terdokumentasi dari kondisi atau kemampuan yang disebut pada

          kondisi 1 dan 2 diatas.

  
  

  II. Macam-macam Requirement Document 

  Menurut sommerville [SOMM] requirement adalah spesifikasi dari apa yang harus diimplementasikan, deskripsi bagaimana sistem harusnya berkerja atau bagian-bagian yang ada didalam sistem, bisa juga dijadikan batasan dalam proses pengembangan sistem. 

  Ada beberapa macam requirement menurut sommerville [SOMM] yaitu: 

  a. User Requirement (kebutuhan pengguna): Pernyataan tentang layanan yang disediakan

      sistem dan tentangbatasan-batasan perasionalnya. Pernyataan ini dapat dilengkapi

      dengan gambar/diagram yang dapat dimengerti dengan mudah. 

  
  

  b.  System requirement (kebutuhan system): 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. 

  c . Software design specification ( spesifikasi rancangan perangkat lunak): Gambaran

       abstrak dari rancangan software yang menjadi dasar bagi perancangan dan

       implementasi yang lebih detil. 

  Disitus Wikipedia menjelaskan bahwa requirement khususnya dalam engineering mempunyai arti a singular documented need of what a particular product or service should be or do. Istilah tersebut sering digunakan dalam bidang system engineering dan software enginnering. Fase dalam pengembangan requirement dapat dipecah-pecah menjadi : requirements elicitation (mengumpulkan kebutuhan stakeholders), analysis (memeriksa konsistensi dan keterlengkapan), specification (mendokumentasikan requirements) and verification (memastikan bahwa requirements yang telah dispesifikasikan benar) Secara umum, requirement dibagi menjadi 2 yaitu: 

  ·   Functional requirement : menjelaskan tentang fungsional dari sistem 

  ·  Non-Functional requirement : yang berperan untuk member batasan pada solusi atau biasa disebut quality requirement. 

  Requirement adalah pernyataan yang menidentifikasikan kebutuhan yang penting dalam sistem dan didalamnya mencakup aspek kebenaran, Realistis, Dibutuhkan, tidak ambigu, dan terukur. Langkah yang paling penting dalam proses requirement adalah komunikasi yang akurat antara user yang memerlukan sistem dengan pembuat sistem. Requirement yang baik menyatakan sesuatu yang dibutuhkan, dapat diverifikasi, memungkinkan, dan Jelas. Terdapat beberapa masalah yang sering ditemui dalam membuat requirement, diantaranya adalah : membuat asumsi yang buruk, menulis implementasi (HOW) daripada requirement (WHAT), menjelaskan operasional daripada kebutuhan, mengunakan istilah yang salah, mengunakan bahasa yang kurang tepat, requirement tidak lengkap, dan menspesifikasikan requirement secara berlebihan. 

  
  

  Dokumen kebutuhan (Requirement Document) 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. 

  
  

  III. 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.

  
  IV. Tujuan Requirement Document  
    

  Tujuan dibuatnya dokumen kebutuhan sistem adalah : 

  1.      Untuk menjelaskan cara kerja sistem. Dengan menggunakan dokumentasi kita dapat menjelaskan cara kerja sistem yang rumit dan panjang dalam waktu yang sangat singkat.

  2.      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. 

  3.                  Alat bagi auditor dalam mempelajari, mengevaluasi dan sekaligus mendokumentasikan pemahamannya terhadap sistem pengendalian internal kontrol kliennya.

  4.      Dasar pengembangan sistem lebih lanjut

  
  

  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

  
  

  Daftar Pustaka :

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

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

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

  4.  wsilfi.staff.gunadarma.ac.id

  5.  http://bloody-machine.blogspot.com/2013/03/dokumen-kebutuhan-sistem.html