Jenis Requirement Dan Pembacanya
Saturday, January 15, 2022
Edit
2.3 Jenis Requirement dan Pembacanya
Requirement sanggup dibedakan menjadi tiga jenis, yaitu :
User requirement (kebutuhan pengguna) Pernyataan perihal layanan yang disediakan sistem dan perihal batasanbatasan operasionalnya. Pernyataan ini sanggup dilengkapi dengan gambar/diagram yang sanggup 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 sempurna dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
Software design specification (spesifikasi rancangan PL)
Gambaran ajaib dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil. Ketiga jenis requirement tersebut diharapkan dalam pembangunan software alasannya ialah masing-masing memberi pengertian ke pihak yang berbeda kepentingan. Pembaca dari ketiga requirement tersebut bisa dijelaskan dengan gambar 1.
2.4 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 klarifikasi perihal layanan yang perlu disediakan oleh sistem, bagaimana sistem mendapatkan dan mengolah masukan, dan bagaimana sistem mengatasi situasi-situasi tertentu. Selain itu adakala juga secara terang menentukan apa yang tidak dikerjakan oleh sistem.
Functional requirement menggambarkan system requirement secara detil menyerupai input, output dan pengecualian yang berlaku. Contoh dalam kasus peminjaman buku di perpustakaan:
Pengguna bisa mencari semua informasi perihal buku atau bisa menentukan salah satu dari informasi perihal buku.
- Semua peminjam mempunyai pengenal yang unik.
- Sistem bisa catat transaksi peminjaman, pengembalian dan denda secara lengkap.
- Hari libur bisa di-set semenjak awal, dan bisa mendapatkan perubahan dengan otoritas khusus.
- Harus komplit ( kebutuhan layanan terang dan lengkap) dan konsisten (tidak pertentangan 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 ialah 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 ialah 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, akomodasi digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem.
Organisational requirement
Berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan.
External requirement
Berkaitan dengan persoalan etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi.
Domain requirement :
Berasal dari domain aplikasi sistem. Misalnya alasannya ialah persoalan hak cipta maka beberapa dokumen dalam perpustakaan dihentikan diakses oleh orang lain yang tidak berhak.
2.5 Key activity
Elicitation
Pada tahap ini dikumpulkan banyak sekali requirement dari para stakeholder [Pres01]. Seorang pelanggan mempunyai persoalan yang sanggup 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 menyerupai yang dilakukan oleh para arkeolog dikala mengumpulkan runtuhan-runtuhan di situs purbakala [Leff00]. Ada yang memperlihatkan istilah requirements capture alasannya ialah dilakukan terutama dengan mengumpulkan fakta-fakta [Benn00]. Bahkan [Gudg00] menyatakan bahwa requirement sebetulnya dibentuk ketimbang didapatkan (elicitated). Walau yang terakhir ini nampaknya “lain sendiri”, argumen ini sanggup diterima untuk pengembangan software yang sama sekali gres maupun untuk software-software permainan (games) yang terkadang permasalahan yang akan dipecahkan oleh game tersebut cenderung tidak berafiliasi dengan solusinya ataupun sebetulnya persoalan yang ada berasal dari bab marketing2. Sejalan dengan proses RE secara keseluruhan, tujuan dari requirements elicitation ialah [Gudg00] :
- Untuk mengetahui persoalan 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.
2.5.1 Teknik pengumpulan Requirement
- Dalam [Nuse00] disebutkan beberapa jenis teknik pengumpulan requirement:Traditional techniques merupakan banyak sekali cara pengumpulan data. Cara-cara ini termasuk kuesioner, survey, wawancara, serta analisis dari banyak sekali dokumentasi yang ada menyerupai struktur organisasi, petunjuk pelaksanaan (juklak) serta manual-manual dari sistem yang sudah ada.
- Group elicitation techniques bertujuan untuk membuatkan dan mendapatkan persetujuan stakeholder, sementara memanfaatkan dinamika kelompok untuk memperoleh pengertian yang lebih mendalam. Cara-cara ini termasuk brainstorming dan focus group, juga banyak sekali workshop RAD/JAD (workshop untuk membangun sebuah konsensus dengan memakai seorang fasilitator yang netral).
- Prototyping techniques menciptakan suatu implementasi parsial dari software yang akan dibangun untuk membantu para pengembang, pengguna, serta pelanggan untuk lebih mengerti banyak sekali requirement sistem [Leff00]. Digunakan untuk mendapatkan umpan-balik yang cepat dari para stakeholder [Davi92], teknik ini juga sanggup digabungkan dengan banyak sekali teknik yang lain, menyerupai contohnya dipakai di dalam sebuah program group elicitation ataupun sebagai basis dari sebuah kuesioner.
- Model-driven techniques menempatkan suatu model khusus dari jenis informasi yang akan dikumpulkan untuk dipakai sebagai fatwa proses elicitation. Termasuk di antaranya ialah goal based methods menyerupai KAOS [Lams98] dan [Chun00] dan juga cara-cara berbasis skenario menyerupai CREWS [Maid96].
- Cognitive techniques termasuk serangkaian cara yang semulanya dikembangkan untuk knowledge acquisistion untuk dipakai di knowledge-based systems [Shaw96]. Teknik-teknik ini termasuk protocol analysis (di mana spesialis melaksanakan sebuah kiprah sembari mengutarakan pikiran-pikirannya), laddering (menggunakan banyak sekali investigasi 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 menyerupai pengamatan terhadap para peserta. Juga termasuk ethnomethodogy dan analisis percakapan, yang keduanya memakai analisis terinci untuk mengenali pola-pola dalam percakapan dan interaksi [Vill99].
- Dalam acara requirements elicitation, ada baiknya untuk mengkategorikan banyak sekali requirement yang ditemukan. Suatu requirement sanggup diklasifikasi sebagai functional requirement, non-functional requirement, maupun constraints [Grad92]. Sedangkan [Koto98] menyampaikan bahwa suatu requirement sanggup diklasifikasikan menjadi very general requirements, functional requirements, implementation requirements, performance requirements, dan usability requirements.
- Namun nyatanya pembagian terstruktur mengenai (atau cara-cara pengkategorian lainnya) requirement ini tidak mutlak diperlukan; pembagian terstruktur mengenai requirement ditujukan terutama untuk menuntun proses elicitation. Hal ini perlu diwaspadai alasannya ialah gara-gara para anggota tim tidak sanggup baiklah akan pembagian terstruktur mengenai dari sekumpulan requirement, maka development effort dari sebuah perusahaan Fortune 500 mengalami stagnasi [Leff00]. Terjebaknya mereka di dalam persoalan semantik ini merupakan salah satu contoh dari analysis paralysis [Whit99].
Analyze
Sebuah model ialah 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 banyak sekali sikap dari para stakeholder serta banyak sekali sistem lain yang berafiliasi dengannya. Domain modeling menyediakan suatu bentuk ajaib dari dunia kawasan beroperasinya sistem yang akan dibuat. Model-model yang dihasilkan dalam tahap ini ditujukan untuk analisa terhadap banyak sekali requirement yang ada. Para stakeholder berunding untuk mendapatkan suatu himpunan requirement tamat yang akan dipakai untuk tahap pengembangan selanjutnya.
Menurut [Koto98] sesudah 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 gampang diubah ataupun disesuaikan.
Spesification
Tahap ini ialah penulisan dari requirements document, yang terkadang disebut dokumen Software Requirements Specification (SRS). Menurut [Hen80], dokumen ini sebaiknya:
- Hanya memutuskan sikap sistem sebagaimana terlihat dari luar
- Menetapkan batasan-batasan (constraints) yang diberikan kepada implementasinya.
- Mudah diubah.
- Berguna sebagai alat referensi untuk pemeliharaan sistem.· Memuat citra akan siklus kehidupan sistem di masa yang akan datang.
Untuk meningkatkan readability, beberapa standar dokumentasi SRS telah dikembangkan. Namun berdasarkan [Kov99], serangkaian standar dan template apabila berdiri sendiri tidak sanggup dipakai sebagai cara yang mandraguna untuk memberi struktur bagi sekumpulan requirement; tetapi struktur yang dipakai haruslah dikembangkan sendiri-sendiri tergantung dari persoalan yang sedang ditangani. Masalah standarisasi notasi dan pendokumentasian requirement menciptakan pendekatan sistematis terhadap RE menjadi sulit. [McDe94] memperlihatkan sebuah daftar mudah 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 sanggup dipastikan bahwa sistem tersebut memenuhi requirement awal.
- Validatable. Suatu requirement sebaiknya sanggup diperiksa oleh pelanggan untuk memastikan bahwa requirement tersebut memang memenuhi kebutuhannya.
- Modifiable. Perubahan sebaiknya gampang dilakukan dan efek dari perubahan ini terhadap bagian-bagian lain sebaiknya minimal.
- Understandable. Semua stakeholder sebaiknya sanggup mengerti requirement menyerupai ditetapkan di dalam dokumen.
- Testable. Semua requirement sebaiknya cukup kuantitatif untuk dipakai sebagai titik tolak pengujian sistem.
- Traceable. Harus dimungkinkan adanya pengacuan (reference) antar banyak sekali bab di dokumen requirement ataupun ke bagian-bagian lain dari proses pembuatan perangkat lunak.
Validation & Verification
Dalam tahap ini, dokumen dari tahap sebelumnya diperiksa semoga 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 persoalan requirement yang terungkap pada tahap validasi antara lain [Koto98]:
- Kurang/tidak cocok dengan bakuan-bakuan kualitas.
- Kata-kata yang dipakai 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.
SUMBER;