Pengertian Dan Definisi Requirement Menurut Para Jago

Pengertian Dan Definisi Requirement Menurut Para Ahli

Defini Requirement Menurut (Dorf, 1990) yaitu : Sebuah requirement ialah suatu kemampuan yang mesti dimiliki dari sebuah software. Kemampuan ini mampu ditujukan untuk memecahkan sebuah masalah ataupun diharapkan untuk menyanggupi ketentuan-ketentuan tertentu (mirip kriteria tertentu, keputusan administrasi, ataupun alasan-argumentasi politis).

Kumpulan dari berbagai requirement digunakan dalam aneka macam faktor dalam pengembangan suatu metode. Dalam tahap perancangan, requirement digunakan untuk menentukan aneka macam fitur yang akan ada di dalam tata cara. Pada penghujung suatu development effort, himpunan requirement ini digunakan untuk melakukan validation & verification untuk memastikan perangkat lunak yang telah dibuat memang sesuai dengan yang dikehendaki. 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) yakni proses untuk memperoleh sebuah himpunan requirement yang tepat sehingga sebuah perangkat lunak dapat menyanggupi manfaatnya. Proses ini dilaksanakan dengan cara mengenali para stakeholder serta kebutuhan mereka serta mendokumentasikannya di dalam bentuk yang dapat dipakai untuk analisa, komunikasi, dan implementasi yang mengikutinya (Nuse,2000).

Definisi dari requirement (Zave, 1997) yaitu citra dari layanan (services) dan batas-batas bagi sistem yang akan dibangun. Atau requirement yakni pernyataan/citra pelayanan yang disediakan oleh sistem, batasan-batas-batas dari sistem dan bisa juga berbentukdefinisi matematis fungsi-fungsi sistem. 

Proses mendapatkan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan tersebut disebut Requirement Engineering.

Requirement berfungsi ganda yaitu:

• Menjadi dasar penawaran suatu kesepakatan : harus terbuka untuk masukan.
• Menjadi dasar kesepakatan : mesti didefinisikan secara detil.

Metode Pengumpulan Requirement

Pengumpulan requirement bermaksud untuk melakukan survey terhadap keinginan pemakai dan menjelaskan tata cara informasi yang ideal. 

Ada 7 metode pengumpulan requirement, ialah : 

Tanya jawab (interviews)

1. Bagaimana tata cara 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 mampu mengukur tanggapanmelalui pertanyaan dan menyesuaikannya sesuai suasana yang terjadi.
• Baik untuk persoalan yang tidak teratur.
• Menunjukkan kesan interviewer secara langsung.
• Memunculkan respons yang tinggi sejak penyusunan pertemuan.

3. Kerugian metode :

• Membutuhkan waktu dan biaya yang tak sedikit.
• Membutuhkan pembinaan dan pengalaman khusus dari pewawancara.
• Sulit membandingkan laporan wawancara alasannya adalah subyektivitas alamiah.

Kuesioner

1. Bagaimana sistem ini dikerjakan : 

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

2. Keuntungan tata cara :

• Murah dan cepat dari pada interview.
• Tidak memerlukan investigator yang berpengalaman (hanya satu ahli yang diharapkan untuk merancang kuesioner untuk end-user yang terpilih).
• Praktis untuk mensintesis hasil sejak pembuatan kuesioner.
• Dapat mengurangi ongkos untuk semua end-user.

3. Kerugian tata cara : 

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

Observasi

1. Bagaimana metode itu dipakai :

• Secara pribadi seorang analis mengunjungi lokasi pengamatan.
• Analis merekam peristiwa dalam lokasi pengamatan, tergolong volumen dan pembuatan lembar kerja.

2. Keuntungan tata cara :

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

3. Kerugian sistem :

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

Prosedur analisis

1. Bagaimana metode itu dipakai :

• Dengan mekanisme operasi mampu mempelajari dan mengidentifikasikan ajaran dokumen kunci lewat tata cara isu, ialah dengan data flow diagram (DFD).
• Setiap fatwa dokumen kunci menerangkan prosedur operasi metode.
• Melalui pengamatan, analis mempelajari kenyataan ketimbang mendeskripsikan volume distribusi (tinggi, rendah, sedang) dan apa yang selanjutnya dilaksanakan terhadap salinan dari dokumen aslinya.

2. Keuntungan sistem : 

• Evaluasi mekanisme mampu dilaksanakan dengan campur tangan (interferences) yang sekurang-kurangnyadan tidak mempengaruhi operasi pemakai.
• Prosedur ajaran mampu dapat menjadi sebuah struktur checklist untuk melaksanakan pengamatan.

3. Kerugian tata cara : 

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

Pengamatan dokumen 

1. Bagaimana sistem itu digunakan : 

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

2. Keuntungan metode : 

• Meminimalkan interupsi dari fungsi operasionalnya.
• Permulaan unsur kamus data.
• Seringkali, mampu menimbang-nimbang modifikasi major procedural.

3. Kerugian sistem :

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

Sampling

Sampling dapat membantu meminimalkan waktu dan biaya. Perlu ketelitian untuk 

memilih sample dari populasi, sehingga membutuhkan keterampilan statistik supaya 

tidak mengalami kegagalan atau bahaya. 

Jenis Requirement dan Pembacanya

Requirement dapat dibedakan menjadi tiga jenis, yakni : 

• User requirement (kebutuhan pengguna) 
• Pernyataan ihwal layanan yang ditawarkan tata cara dan wacana batasanbatasan operasionalnya. Pernyataan ini mampu dilengkapi dengan gambar/diagram yang mampu dimengerti dengan gampang.

System requirement (kebutuhan sistem) 

Sekumpulan layanan/kemampuan metode dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), mesti menerangkan dengan sempurna dan detil. Ini bisa berlaku selaku kontrak antara klien dan pembangun.

Software design specification (spesifikasi rancangan PL) 

Gambaran absurd dari desain software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil. 

Ketiga jenis requirement tersebut diharapkan dalam pembangunan software alasannya adalah 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 selaku berikut:

Functional Requirement : 

Merupakan klarifikasi tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem mendapatkan dan mengolah masukan, dan bagaimana sistem menangani suasana-suasana tertentu. Selain itu adakala juga secara terperinci menentukan apa yang tidak dilaksanakan oleh metode.

Functional requirement menggambarkan system requirement secara detil mirip input, output dan pengecualian yang berlaku. Contoh dalam perkara peminjaman buku di perpustakaan: 

• Pengguna bisa mencari semua berita tentang buku atau mampu menentukan salah satu dari info tentang buku. 
• Semua peminjam mempunyai pengenal yang unik. 
• Sistem bisa catat transaksi peminjaman, pengembalian dan denda secara lengkap. 
• Hari libur mampu di-set sejak permulaan, dan mampu mendapatkan perubahan dengan otoritas khusus. 
• Harus komplit ( keperluan layanan terang dan lengkap) dan konsisten (tidak pertentangan dengan yang didefinisikan). 

Masalah yang mungkin terjadi dalam menyusun functional requirement yaitu: 

• Diintepretasikan/diartikan berlainan oleh user atau developer. 
• Hasil intepretasi sering tidak menjawab kebutuhan klien. 
• Untuk sistem yang besar, kelengkapan keperluan dan konsisten sulit diraih 
• alasannya adalah kerumitan metode. 
• Perlu analisis yang dalam dan menyeluruh untuk meminimalisir kesalahan. 

Non-functional Requirement : 

Secara lazim berisi batas-batas-batasan pada pelayanan atau fungsi yang ditawarkan oleh tata cara. Termasuk di dalamnya yaitu batasan waktu, batasan proses pembangunan, kriteria-tolok ukur tertentu. Karena berkaitan dengan kebutuhan tata cara secara keseluruhan,maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh keperluan jenis ini yaitu kecepatan akses, keamanan data, besarnya kapasitas penyimpanan yang dibutuhkan, privasi masing-masing profil /account, bahasa pemrograman yang dipakai, tata cara operasi yang digunakan.

Non functional requirement dibagi menjadi 3 tipe adalah: 

Product requirement 

Berkaitan dengan kehandalan, kecepatan, fasilitas dipakai, kapasitas memori yang diharapkan dan efisiensi tata cara. 

Organisational requirement 

Berkaitan dengan patokan, bahasa pemrograman dan tata cara rancangan yang digunakan. 

External requirement 

Berkaitan dengan persoalan adat penggunaan, interoperabilitas dengan metode lain, legalitas, dan privasi.

Domain requirement : 

Berasal dari domain aplikasi tata cara. Misalnya sebab problem hak cipta maka beberapa dokumen dalam perpustakaan dilarang diakses oleh orang lain yang tidak berhak. 

Key activity

· Elicitation 

Pada tahap ini dikumpulkan banyak sekali requirement dari para stakeholder [Pres01]. Seorang konsumen mempunyai masalah yang dapat ditangani oleh penyelesaian berbasis komputer. Tantangan ini ditanggapi oleh seorang pengembang. Di sinilah komunikasi dimulai antara konsumen, pengembang, dan calon pengguna dari sistem yang mau dibentuk. Namun istilah elicitation agak diperdebatkan. Ada yang menganalogikannya dengan mirip yang dijalankan oleh para arkeolog saat menghimpun runtuhan-runtuhan di situs purbakala [Leff00]. Ada yang memberikan istilah requirements capture sebab dikerjakan khususnya dengan menghimpun fakta-fakta [Benn00]. Bahkan [Gudg00] menyatakan bahwa requirement bahu-membahu dibuat ketimbang didapatkan (elicitated). Walau yang terakhir ini kelihatannya “lain sendiri”, argumen ini dapat diterima untuk pengembangan software yang serupa sekali baru maupun untuk software-software permainan (games) yang kerap kali urusan yang mau dipecahkan oleh game tersebut cenderung tidak berhubungan dengan solusinya ataupun sebenarnya duduk perkara yang ada berasal dari bab marketing2. Sejalan dengan proses RE secara keseluruhan, tujuan dari requirements elicitation adalah [Gudg00] :

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

· Untuk mengenali tujuan dari tata cara; yaitu target-sararan yang mesti dicapainya.

Teknik pengumpulan Requirement

Dalam disebutkan berbagai macam teknik pengumpulan requirement:

• Traditional techniques ialah banyak sekali cara pengumpulan data. Cara-cara ini termasuk kuesioner, survey, wawancara, serta analisis dari banyak sekali dokumentasi yang ada seperti struktur organisasi, isyarat pelaksanaan (juklak) serta manual-manual dari metode yang sudah ada.
• Group elicitation techniques bertujuan untuk mengembangkan dan mendapatkan kesepakatan stakeholder, sementara memanfaatkan dinamika kalangan untuk mendapatkan pemahaman yang lebih mendalam. Cara-cara ini tergolong brainstorming dan focus group, juga berbagai workshop RAD/JAD (workshop untuk membangun suatu konsensus dengan memakai seorang fasilitator yang netral).
• Prototyping techniques menciptakan sebuah implementasi parsial dari software yang hendak dibangun untuk membantu para pengembang, pengguna, serta konsumen untuk lebih mengetahui aneka macam requirement sistem [Leff00]. Digunakan untuk menerima umpan-balik yang cepat dari para stakeholder, teknik ini juga mampu digabungkan dengan berbagai teknik lainnya, seperti contohnya digunakan di dalam sebuah acara group elicitation ataupun selaku basis dari sebuah kuesioner.
• Model-driven techniques menempatkan sebuah versi khusus dari jenis gosip yang mau dikumpulkan untuk dipakai sebagai pedoman proses elicitation. Termasuk di antaranya yaitu goal based methods mirip KAOS  dan juga cara-cara berbasis skenario seperti CREWS.
• Cognitive techniques tergolong 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 peran sembari mengutarakan anggapan-pikirannya), laddering (menggunakan aneka macam investigasi untuk mendapatkan struktur dan isi dari wawasan stakeholder), card sorting (meminta para stakeholder untuk menysun kartu-kartu secara berkelompok, di mana setiap kartu tertera nama suatu domain entity), dan repertory grids (menciptakan suatu 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 mirip pengamatan kepada para peserta. Juga termasuk ethnomethodogy dan analisis percakapan, yang keduanya memakai analisis terinci untuk mengenali acuan-acuan dalam percakapan dan interaksi. 

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

Namun nyatanya penjabaran (atau cara-cara pengkategorian yang lain) requirement ini tidak mutlak diharapkan; pembagian terstruktur mengenai requirement ditujukan terutama untuk menuntun proses elicitation. Hal ini perlu diwaspadai sebab gara-gara para anggota tim tidak mampu baiklah akan pembagian terstruktur mengenai dari sekumpulan requirement, maka development effort dari suatu perusahaan Fortune 500 mengalami stagnasi [Leff00]. Terjebaknya mereka di dalam dilema semantik ini merupakan salah satu contoh dari analysis paralysis [Whit99]. 

Analyze

Sebuah model adalah perwakilan dari benda lain yang memiliki detail yang cukup untuk membantu solusi peran-tugas tertentu [Benn00]. Data modeling bermaksud untuk menerima pengertian dari pemrosesan serta pengaturan informasi. Behavioral modeling memodelkan aneka macam perilaku dari para stakeholder serta berbagai metode lain yang berhubungan dengannya. Domain modeling menawarkan sebuah bentuk abstrak dari dunia tempat beroperasinya metode yang mau dibuat. Model-versi yang dihasilkan dalam tahap ini ditujukan untuk analisa terhadap banyak sekali 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 berlawanan.
• Informasi di dalam semua requirement harus lengkap.
• Berbagai requirement yang ada mesti selaras dengan budget yang dimiliki. 

Walaupun dengan adanya batas-batas-batasan tersebut, seluruh requirement semestinya mudah diubah ataupun diadaptasi. 

Spesification 

Tahap ini yaitu penulisan dari requirements document, yang seringkali disebut dokumen Software Requirements Specification (SRS). Menurut [Hen80], dokumen ini seharusnya:

• Hanya memutuskan sikap metode sebagaimana terlihat dari luar
• Menetapkan batas-batas-batasan (constraints) yang diberikan kepada implementasinya.
• Praktis diubah.
• Berguna sebagai alat referensi untuk pemeliharaan metode.· Memuat gambaran akan siklus kehidupan metode di kurun yang hendak tiba.

Untuk memajukan readability, beberapa standar dokumentasi SRS telah dikembangkan. Namun menurut [Kov99], serangkaian kriteria dan template apabila bangkit sendiri tidak dapat digunakan sebagai cara yang mandraguna untuk memberi struktur bagi sekumpulan requirement; namun struktur yang dipakai haruslah dikembangkan sendiri-sendiri tergantung dari duduk perkara yang sedang dikerjakan. Masalah standarisasi notasi dan pendokumentasian requirement membuat pendekatan sistematis kepada RE menjadi sulit. [McDe94] memberikan sebuah daftar simpel ciri-ciri yang dinginkan pada sebuah requirements document:

• Unambigous. Idealnya, cuma ada satu interpretasi kepada sebuah requirements document.
• Complete. Semua aspek yang bersangkutan haruslah diterangkan secara lengkap di dalam requirements document.
• Consistent. Tidak ada pernyataan yang bertentangan dalam requirements document.
• Verifiable. Setelah sebuah metode diimplementasikan, sebaiknya dapat dipastikan bahwa tata cara tersebut menyanggupi requirement permulaan.
• Validatable. Suatu requirement sebaiknya dapat diperiksa oleh konsumen untuk memutuskan bahwa requirement tersebut memang menyanggupi kebutuhannya.
• Modifiable. Perubahan seharusnya gampang dikerjakan dan efek dari perubahan ini kepada bagian-bab lain semestinya minimal.
• Understandable. Semua stakeholder semestinya dapat memahami requirement mirip ditetapkan di dalam dokumen.
• Testable. Semua requirement seharusnya 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 supaya memenuhi kriteriakriteria sebagai berikut [Koto98]:

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

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

• Kurang/tidak sesuai dengan bakuan-bakuan mutu.
• Kata-kata yang dipakai kurang baik sehingga requirement menjadi ambigu.
• Berbagai kesalahan yang terdapat pada versi-model baik versi system ataupun model problem yang hendak dipecahkan.
• Pertentangan antar requirement yang tidak ditemukan pada tahap analisis.