Requirement Document (Dokumen Kebutuhan)

 

Requirement Document (Dokumen Kebutuhan)

A.    Pengertian Requirement

Defini Requirement Menurut (Dorf, 1990) yaitu : Sebuah requirement adalah sebuah kemampuan yang harus dimiliki dari suatu software. Kemampuan ini dapat ditujukan untuk memecahkan suatu permasalahan ataupun diperlukan untuk memenuhi ketentuan-ketentuan tertentu (seperti standar tertentu, keputusan manajemen, ataupun alasan-alasan politis).

Kumpulan dari berbagai requirement digunakan dalam berbagai aspek dalam pengembangan sebuah sistem. Dalam tahap perancangan, requirement digunakan untuk menentukan berbagai fitur yang akan ada di dalam sistem. Pada penghujung sebuah development effort, himpunan requirement ini digunakan untuk melakukan validation & verification untuk memastikan perangkat lunak yang telah dibuat memang sesuai dengan yang diinginkan. Bahkan selagi pengembangan berjalan, himpunan requirement ini terus dimodifikasi untuk menyesuaikannya dengan berbagai kebutuhan para stakeholder serta tenggat waktu dan dana yang tersedia. Secara luas, software systems requirements engineering (RE) adalah proses untuk menemukan suatu himpunan requirement yang tepat sehingga suatu perangkat lunak dapat memenuhi kegunaannya. Proses ini dilakukan dengan cara mengenali para stakeholder serta kebutuhan mereka serta mendokumentasikannya di dalam bentuk yang dapat digunakan untuk analisa, komunikasi, dan implementasi yang mengikutinya (Nuse,2000).

Definisi dari requirement (Zave, 1997) 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. Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan tersebut disebut Requirement Engineering.

Requirement berfungsi ganda yaitu:

Menjadi dasar penawaran suatu kontrak : harus terbuka untuk masukan.

Menjadi dasar kontrak : harus didefinisikan secara detil.

B.     Jenis Requirement dan Pembacanya

Requirement dapat dibedakan menjadi  tiga jenis, yaitu :

User requirement (kebutuhan pengguna): Pernyataan tentang layanan yang disediakan sistem dan tentang batasanbatasan 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.

C.     Kategori Requirement

Software system requirement sering dibedakan dalam 3 kategori yaitu Functional requirement, Non Functional requirement dan Domain requirement, dengan masing-masing penjelasannya sebagai berikut:

Functional Requirement: Merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana sistem mengatasi situasi-situasi tertentu. Selain itu kadang-kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem.

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. Karena berkaitan dengan kebutuhan sistem secara keseluruhan,maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh kebutuhan jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas penyimpanan yang diperlukan, privasi masing-masing profil /account, bahasa pemrograman yang digunakan, sistem operasi yang digunakan. Non functional requirement dibagi menjadi 3 tipe yaitu: Product requirement, Organisational requirement dan External requirement 

Domain requirement: Berasal dari domain aplikasi sistem. Misalnya karena masalah hak cipta maka beberapa dokumen dalam perpustakaan tidak boleh diakses oleh orang lain yang tidak berhak.

D.    Teknik pengumpulan Requirement

Dalam [Nuse00] disebutkan beberapa jenis teknik pengumpulan requirement:

Traditional techniques merupakan berbagai cara pengumpulan data. Cara-cara ini termasuk kuesioner, survey, wawancara, serta analisis dari berbagai dokumentasi yang ada seperti struktur organisasi, petunjuk pelaksanaan (juklak) serta manual-manual dari sistem yang sudah ada.

Group elicitation techniques bertujuan untuk mengembangkan dan mendapatkan persetujuan stakeholder, sementara memanfaatkan dinamika kelompok untuk memperoleh pengertian yang lebih mendalam. Cara-cara ini termasuk brainstorming dan focus group, juga berbagai workshop RAD/JAD (workshop untuk membangun sebuah konsensus dengan menggunakan seorang fasilitator yang netral).

Prototyping techniques membuat suatu implementasi parsial dari software yang akan dibangun untuk membantu para pengembang, pengguna, serta pelanggan  untuk lebih mengerti berbagai requirement sistem [Leff00]. Digunakan untuk mendapatkan umpan-balik yang cepat dari para stakeholder [Davi92], teknik ini juga dapat digabungkan dengan berbagai teknik yang lain, seperti misalnya digunakan di dalam sebuah acara group elicitation ataupun sebagai basis dari sebuah kuesioner.

Model-driven techniques menempatkan suatu model khusus dari jenis informasi yang akan dikumpulkan untuk digunakan sebagai pedoman proses elicitation. Termasuk di antaranya adalah goal based methods seperti KAOS [Lams98] dan [Chun00] dan juga cara-cara berbasis skenario seperti CREWS [Maid96].

Cognitive techniques termasuk serangkaian cara yang semulanya dikembangkan untuk knowledge acquisistion untuk digunakan di knowledge-based systems [Shaw96]. Teknik-teknik ini termasuk protocol analysis (di mana seorang ahli melakukan sebuah tugas sembari mengutarakan pikiran-pikirannya), laddering (menggunakan berbagai pemeriksaan untuk mendapatkan struktur dan isi dari pengetahuan stakeholder), card sorting (meminta para stakeholder untuk menysun kartu-kartu secara berkelompok, di mana setiap kartu tertera nama sebuah domain entity), dan repertory grids (membuat sebuah attribute matrix for entities di mana para stakeholder diminta untuk mengisi matriks tersebut).Contextual techniques muncul pada tahun 1990-an sebagai sebuah pilihan di luar traditional maupun cognitive techniques [Gogu94]. Termasuk di antaranya penggunaan teknik etnografis seperti pengamatan terhadap para peserta. Juga termasuk ethnomethodogy dan analisis percakapan, yang keduanya menggunakan analisis terinci untuk mengenali pola-pola dalam percakapan dan interaksi [Vill99].

E.     Dokumen kebutuhan (requirement document)

Merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun system

Berisi definisi dan spesifikasi requirement dan bukan dokumen desain

Sebisa mungkin berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA sistem mengerjakannya

Pengguna dari dokumen kebutuhan adalah pihak-pihak yang dijelaskan pada Gambar dibawah ini yang menjelaskan pihak pengguna dokumen dan kepentingannya dengan dokumen tersebut

Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :

Menjelaskan perilaku eksternal system

Menjelaskan batasan pada implementasi

Mudah diubah

Sebagai alat referensi untuk pemelihara system

Mencatat peringatan awal tentang siklus dari system

Menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal

F.     Bagian-bagian dalam Requirement Document

Berikut ini adalah bagian-bagian dari RD :

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.

Tujuan Proyek. Sebuah pernyataan singkat mengapa kita mengajukan proposal untuk pengembangan proyek. Batasanbatasan utama dalam penggunaan waktu dan keuangan dapat juga disebutkan.

Fungsi-fungsi Utama. Pernyataan singkat mengenai bagaimana sistem berfungsi berdasarkan tujuan proyek yang telah ditetapkan.

Keluaran Umum. Penjelasan secara singkat tentang informasi yang dibutuhkan dari sistem.

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.

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

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.

Pengoperasian dan Lingkungan. Dimana komputer akan ditempatkan, dimana terminal-terminal yang interaktif ditempatkan, dan siapa yang akan menggunakannya.

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.

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.

Pengantarmukaan dengan Pemakai. Rincikan pengalamanpengalaman yang dibutuhkan user dalam menggunakan komputer, jelaskan bagaimana menangani sistem kapada user yang baru.

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.

Pemeliharaan dan Dukungan. Jaminan-jaminan yang dibutuhkan : berapa lama, sampai kapan, bagaimana pengiriman.

Dokumentasi dan Pelatihan. Rincikan semua dokumendokumen umum dan / atau pelatihan yang dibutuhkan.

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.

Persyaratan dan Kondisi. Menyatakan syarat untuk seleksi, kapan dan bagaimana akan dilakukan.

Daftar Pustaka

http://weha88.blog.binusian.org/files/2009/06/gabungan-paper-2.doc

http://maulana.staff.gunadarma.ac.id/Downloads/files/32488/4)+Requirement+Elicitation.pdf

http://www.scribd.com/doc/16067339/Requirement

http://wsilfi.staff.gunadarma.ac.id/Downloads/files/17470/Pertemuan+02+-+Fase+Definisi.pdf

http://mohiqbal.staff.gunadarma.ac.id/Downloads/files/5150/Standard_Dokumentasi+TI.pdf

Diposting oleh Sarah Yumeita K Rompas di 20.31