Pengertian Dan Definisi Requirement Menurut Para Ahli

Pengertian Dan Definisi Requirement Menurut Para Ahli

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.

Metode Pengumpulan Requirement

Pengumpulan requirement bertujuan untuk melakukan survey terhadap keinginan pemakai dan menjelaskan sistem informasi yang ideal. 

Ada 7 metode pengumpulan requirement, yaitu : 

Tanya jawab (interviews)

1. Bagaimana metode itu digunakan :

• Pemilihan potential interviewees.
• Membuat perjanjian terhadap potential interviewees.
• Menyiapkan struktur pertanyaan yang lengkap dan jelas.
• Memilih orang yang diinterview secara pribadi dan merekamnya.

2. Keuntungan metode :

• Pewawancara dapat mengukur respon melalui pertanyaan dan menyesuaikannya sesuai situasi yang terjadi.
• Baik untuk permasalahan yang tidak terstruktur.
• Menunjukkan kesan interviewer secara pribadi.
• Memunculkan respons yang tinggi sejak penyusunan pertemuan.

3. Kerugian metode :

• Membutuhkan waktu dan biaya yang tidak sedikit.
• Membutuhkan pelatihan dan pengalaman khusus dari pewawancara.
• Sulit membandingkan laporan wawancara karena subyektivitas alamiah.

Kuesioner

1. Bagaimana metode ini dilakukan : 

• Mendeain dengan menggunakan standar kuesioner.
• Kuesioner dikirimkan ke lingkungan kerja end-users.
• Struktur respon diringkas dalam statistik distribusi.

2. Keuntungan metode :

• Murah dan cepat dari pada interview.
• Tidak membutuhkan investigator yang terlatih (hanya satu ahli yang dibutuhkan untuk mendesain kuesioner untuk end-user yang terpilih).
• Mudah untuk mensintesis hasil sejak pembuatan kuesioner.
• Dapat meminimalkan biaya untuk semua end-user.

3. Kerugian metode : 

• Tidak dapat membuat pertanyaan yang spesifik bagi end-user.
• Analis melibatkan kesan sehingga tidak dapat menampakkan pribadi 
• end-user.
• Tanggapan yang rendah karena tidak adanya dorongan yang kuat untuk 
• mengembalikan kuesioner.
• Tidak dapat menyesuaikan pertanyaan ke end-user secara spesifik.

Observasi

1. Bagaimana metode itu digunakan :

• Secara pribadi seorang analis mengunjungi lokasi pengamatan.
• Analis merekam kejadian dalam lokasi pengamatan, termasuk volumen dan pengolahan lembar kerja.

2. Keuntungan metode :

• Mendapatkan fakta records daripada pendapat (opinion).
• Tidak membutuhkan konstruksi pertanyaan.
• Tidak menganggu atau menyembunyikan sesuatu (end-users tidak mengetahui bahwa mereka sedang diamati).
• Analis tidak bergantung pada penjelasan lisan dari end-users.

3. Kerugian metode :

• Jika terlihat, analis mungkin mengubah operasi (end-user merasa diamati).
• Dalam jangka panjang, fakta yang diperoleh dalam satu observasi mungkin tidak tepat (representative) dalam kondisi harian atau mingguan.
• Membutuhkan pengalaman dan kehlian khusus dari analis.

Prosedur analisis

1. Bagaimana metode itu digunakan :

• Dengan prosedur operasi dapat mempelajari dan mengidentifikasikan aliran dokumen kunci melalui sistem informasi, yaitu dengan data flow diagram (DFD).
• Setiap aliran dokumen kunci menjelaskan prosedur operasi sistem.
• Melalui observasi, analis mempelajari kenyataan daripada mendeskripsikan volume distribusi (tinggi, rendah, sedang) dan apa yang selanjutnya dikerjakan terhadap salinan dari dokumen aslinya.

2. Keuntungan metode : 

• Evaluasi prosedur dapat dikerjakan dengan campur tangan (interferences) yang minimal dan tidak mempengaruhi operasi pemakai.
• Prosedur aliran dapat dapat menjadi sebuah struktur checklist untuk melakukan observasi.

3. Kerugian metode : 

• Prosedure mungkin tidak lengkap dan tidak -up to date lagi.
• Mempelajari bagan aliran dokumen membutuhkan waktu dan keahlian analis.

Pengamatan dokumen 

1. Bagaimana metode itu digunakan : 

• Mengidentifikasikan dokumen utama dan laporan (physical data flow diagram).
• Mengumpulkan salinan dokumen aktual dan laporan.
• Setiap dokumen atau laporan, digunakan untuk record data, meliputi field (ukuran dan tipe), frekuensi penggunaan dan struktur kodingnya (coding structure).

2. Keuntungan metode : 

• Meminimalkan interupsi dari fungsi operasionalnya.
• Permulaan elemen kamus data.
• Seringkali, dapat mempertimbangkan modifikasi major procedural.

3. Kerugian metode :

• Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami kebanjiran dokumen dan laporan).

Sampling

Sampling dapat membantu mengurangi waktu dan biaya. Perlu kecermatan untuk 

memilih sample dari populasi, sehingga membutuhkan keahlian statistik supaya 

tidak mengalami kegagalan atau ancaman. 

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. 

Ketiga jenis requirement tersebut diperlukan dalam pembangunan software karena masing-masing memberi pengertian ke pihak yang berbeda kepentingan. Pembaca dari ketiga requirement tersebut bisa dijelaskan dengan gambar.

Gambar Jenis Requirement dan Pembacanya 

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.

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: 

• Diintepretasikan/diartikan berbeda oleh user atau developer. 
• Hasil intepretasi sering tidak menjawab kebutuhan klien. 
• Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai 
• karena kerumitan sistem. 
• Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan. 

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 

Berkaitan dengan kehandalan, kecepatan, kemudahan digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem. 

Organisational requirement 

Berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan. 

External requirement 

Berkaitan dengan masalah etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi.

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. 

Key activity

· Elicitation 

Pada tahap ini dikumpulkan berbagai requirement dari para stakeholder [Pres01]. Seorang pelanggan mempunyai masalah yang dapat ditangani oleh solusi berbasis komputer. Tantangan ini ditanggapi oleh seorang pengembang. Di sinilah komunikasi dimulai antara pelanggan, pengembang, dan calon pengguna dari sistem yang akan dibuat. Namun istilah elicitation agak diperdebatkan. Ada yang menganalogikannya dengan seperti yang dilakukan oleh para arkeolog ketika mengumpulkan runtuhan-runtuhan di situs purbakala [Leff00]. Ada yang memberikan istilah requirements capture karena dilakukan terutama dengan mengumpulkan fakta-fakta [Benn00]. Bahkan [Gudg00] menyatakan bahwa requirement sebenarnya dibuat ketimbang didapatkan (elicitated). Walau yang terakhir ini nampaknya “lain sendiri”, argumen ini dapat diterima untuk pengembangan software yang sama sekali baru maupun untuk software-software permainan (games) yang terkadang permasalahan yang akan dipecahkan oleh game tersebut cenderung tidak berhubungan dengan solusinya ataupun sebenarnya masalah yang ada berasal dari bagian marketing2. Sejalan dengan proses RE secara keseluruhan, tujuan dari requirements elicitation adalah [Gudg00] :

· Untuk mengetahui masalah apa saja yang perlu dipecahkan dan mengenali perbatasan-perbatasan sistem (system boundaries).· Untuk mengenali siapa saja para stakeholder.

· Untuk mengenali tujuan dari sistem; yaitu sasaran-sararan yang harus dicapainya.

Teknik pengumpulan Requirement

Dalam 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, 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  dan juga cara-cara berbasis skenario seperti CREWS.
• Cognitive techniques termasuk serangkaian cara yang semulanya dikembangkan untuk knowledge acquisistion untuk digunakan di knowledge-based systems. 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. 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. 

Dalam aktivitas requirements elicitation, ada baiknya untuk mengkategorikan berbagai requirement yang ditemukan. Suatu requirement dapat diklasifikasi sebagai functional requirement, non-functional requirement, maupun constraints [Grad92]. Sedangkan [Koto98] mengatakan bahwa suatu requirement dapat diklasifikasikan menjadi very general requirements, functional requirements, implementation requirements, performance requirements, dan usability requirements. 

Namun nyatanya klasifikasi (atau cara-cara pengkategorian lainnya) requirement ini tidak mutlak diperlukan; klasifikasi requirement ditujukan terutama untuk menuntun proses elicitation. Hal ini perlu diwaspadai karena gara-gara para anggota tim tidak dapat setuju akan klasifikasi dari sekumpulan requirement, maka development effort dari sebuah perusahaan Fortune 500 mengalami stagnasi [Leff00]. Terjebaknya mereka di dalam masalah semantik ini merupakan salah satu contoh dari analysis paralysis [Whit99]. 

Analyze

Sebuah model adalah perwakilan dari benda lain yang mempunyai rincian yang cukup untuk membantu penyelesaian tugas-tugas tertentu [Benn00]. Data modeling bertujuan untuk mendapatkan pengertian dari pemrosesan serta pengaturan informasi. Behavioral modeling memodelkan berbagai perilaku dari para stakeholder serta berbagai sistem lain yang berhubungan dengannya. Domain modeling menyediakan suatu bentuk abstrak dari dunia tempat beroperasinya sistem yang akan dibuat. Model-model yang dihasilkan dalam tahap ini ditujukan untuk analisa terhadap berbagai requirement yang ada. Para stakeholder berunding untuk mendapatkan suatu himpunan requirement akhir yang akan digunakan untuk tahap pengembangan selanjutnya. 

Menurut [Koto98] setelah selesainya tahap idealnya ini akan berlaku:

• Berbagai requirement dari masing-masing stakeholder tidak bertentangan.
• Informasi di dalam semua requirement harus lengkap.
• Berbagai requirement yang ada harus selaras dengan anggaran yang dimiliki. 

Walaupun dengan adanya batasan-batasan tersebut, seluruh requirement sebaiknya mudah diubah ataupun disesuaikan. 

Spesification 

Tahap ini adalah penulisan dari requirements document, yang terkadang disebut dokumen Software Requirements Specification (SRS). Menurut [Hen80], dokumen ini sebaiknya:

• Hanya menetapkan perilaku sistem sebagaimana terlihat dari luar
• Menetapkan batasan-batasan (constraints) yang diberikan kepada implementasinya.
• Mudah diubah.
• Berguna sebagai alat referensi untuk pemeliharaan sistem.· Memuat gambaran akan siklus kehidupan sistem di masa yang akan datang.

Untuk meningkatkan readability, beberapa standar dokumentasi SRS telah dikembangkan. Namun menurut [Kov99], serangkaian standar dan template apabila berdiri sendiri tidak dapat digunakan sebagai cara yang mandraguna untuk memberi struktur bagi sekumpulan requirement; tetapi struktur yang digunakan haruslah dikembangkan sendiri-sendiri tergantung dari masalah yang sedang ditangani. Masalah standarisasi notasi dan pendokumentasian requirement membuat pendekatan sistematis terhadap RE menjadi sulit. [McDe94] memberikan sebuah daftar praktis ciri-ciri yang dinginkan pada sebuah requirements document:

• Unambigous. Idealnya, hanya ada satu interpretasi terhadap sebuah requirements document.
• Complete. Semua aspek yang bersangkutan haruslah dijelaskan secara lengkap di dalam requirements document.
• Consistent. Tidak ada pernyataan yang bertentangan dalam requirements document.
• Verifiable. Setelah sebuah sistem diimplementasikan, sebaiknya dapat dipastikan bahwa sistem tersebut memenuhi requirement awal.
• Validatable. Suatu requirement sebaiknya dapat diperiksa oleh pelanggan untuk memastikan bahwa requirement tersebut memang memenuhi kebutuhannya.
• Modifiable. Perubahan sebaiknya mudah dilakukan dan efek dari perubahan ini terhadap bagian-bagian lain sebaiknya minimal.
• Understandable. Semua stakeholder sebaiknya dapat mengerti requirement seperti ditetapkan di dalam dokumen.
• Testable. Semua requirement sebaiknya cukup kuantitatif untuk digunakan sebagai titik tolak pengujian sistem.
• Traceable. Harus dimungkinkan adanya pengacuan (reference) antar berbagai bagian di dokumen requirement ataupun ke bagian-bagian lain dari proses pembuatan perangkat lunak. 
• Validation & Verification 

Dalam tahap ini, dokumen dari tahap sebelumnya diperiksa agar memenuhi kriteriakriteria sebagai berikut [Koto98]:

• Lengkap.
• Konsisten.
• Tunduk pada keputusan-keputusan yang diambil pada tahap requirements analysis.

Apabila ada requirement yang tidak memenuhi kriteria-kriteria tersebut, mungkin ada baiknya bagi proses RE untuk kembali ke tahap-tahap sebelumnya. Beberapa contoh masalah requirement yang terungkap pada tahap validasi antara lain [Koto98]:

• Kurang/tidak cocok dengan bakuan-bakuan kualitas.
• Kata-kata yang digunakan kurang baik sehingga requirement menjadi ambigu.
• Berbagai kesalahan yang terdapat pada model-model baik model system ataupun model permasalahan yang hendak dipecahkan.
• Pertentangan antar requirement yang tidak ditemukan pada tahap analisis.