Rekayasa Kebutuhan Perangkat Lunak

Asnafi
5 min readAug 13, 2020

--

Halo semuanya, ini adalah tulisan pertama saya di medium, dan semoga menambah insight bagi teman-teman

Kali ini saya ingin menulis tentang RKPL atau Rekayasa Kebutuhan Perangkat Lunak (Software Requirements Engineering).

Apa itu rekayasa kebutuhan?

Sebuah software dibangun dengan melibatkan analisis kebutuhan client yang meliputi lima proses yaitu, pengumpulan informasi, penganalisaan, penspesifikasian, verifikasi, dan validasi.

Banyak permasalahan yang terjadi dalam pengembangan software karena kurangnya data dan informasi yang dibutuhkan dalam lima tahapan diatas.

Hal ini juga terjadi karena kurangnya tingkat pemahaman developer terhadap kebutuhan client, sehingga software yang dibangun tidak sesuai dengan apa yang diharapkan.

Mengapa perlu adanya rekayasa kebutuhan?

Ada dua hal dasar kenapa perlu adanya rekayasa kebutuhan :

  1. Setiap software yang akan dibangun pasti memiliki spesifikasi.
  2. Spesifikasi yang bermasalah akan menyebabkan masalah yang tidak diharapkan.

Mengapa spesifikasi software yang buruk bisa terjadi, karena beberapa hal :

  1. Kepedulian yang rendah baik dari client maupun developer.
  2. Kurangnya interaksi antara client dan developer, adanya jarak membuat diskusi tidak efektif.
  3. Client tidak selalu mengetahui dengan pasti apa yang dibutuhkan. Hal yang diutarakan mungkin bukan apa yang dimaksud.
  4. Permintaan kebutuhan yang selalu bertambah (revisi).

Definisi rekayasa kebutuhan

Rekayasa kebutuhan (software specifications / requirements engineering (RE)) adalah proses memahami dan mendefinisikan spesifikasi kebutuhan sistem/perangkat lunak dengan verifikasi dan validasi yang diharapkan client, baik dalam bentuk lisan maupun tulisan (dokumen).

Rekayasa kebutuhan yang baik akan menjadi pondasi membangun high quality software dan sesuai dengan user expectation (keinginan pengguna).

Siapa yang berkepentingan terhadap sistem?

Lalu siapa saja yang memiliki kepentingan dalam pembangunan sistem? Berikut adalah beberapa stakeholder yang terlibat yaitu:

  1. Pelanggan (customer/client), yang memesan pembangunan software.
  2. Pemilik sistem (system owner) merupakan sub-kelas dari pelanggan yang memiliki sistem dan berkepentingan atas tercapainya tujuan bisnis melalui sistem yang dibangun. Biasanya pemilik sistem juga sekaligus penyandang dana dari proyek terkait. Contoh: perusahaan atau organisasi dari pelanggan.
  3. Pengguna (user) merupakan pengguna layanan/produk (software).
  4. Penganalisa kebutuhan (requirements analyst) yang menuliskan spesifikasi kebutuhan dari suatu software dan mengkomunikasikannya kepada tim pengembang.
  5. Pengembang (developer) yang merancang, mengimplementasikan dan memelihara proyek.
  6. Penguji (tester) merupakan sub-kelas dari pengembang yang menentukan apakah sistem memang sudah berperilaku seperti yang seharusnya.
  7. Penulis dokumentasi (documentary’s writer) merupakan sub-kelas dari pengembang yang membuat user manual, aturan penggunaan, dsb.
  8. Manajer proyek (project manager) merupakan perancang proyek dan bertugas mengarahkan tim pengembang untuk menghasilkan produk dengan sukses.
  9. Staf hukum (legal) dan non-hukum (non-legal) yang memastikan bahwa produk yang dihasilkan patuh / sesuai dengan hukum dan peraturan yang berlaku.
  10. Staf manufaktur (manufacturing personel) merupakan sub-kelas dari pengembang yang harus membangun produk-produk yang membentuk sistem perangkat lunak.
  11. Penjualan (sales), pemasaran (marketing) dan bagian pendukung, serta pihak-pihak lain yang nantinya bekerja menggunakan sistem yang hendak dibangun.
  12. Penyelia (vendor) yang menyediakan teknologi bagi pembangunan sistem.
  13. Regulator yang menetapkan batasan berupa baku mutu, peraturan, panduan atau rambu-rambu lain terkait dengan produk, proses maupun personel dalam proses pengembangan sistem.

Jenis Kebutuhan perangkat lunak

Kebutuhan Perangkat Lunak adalah kondisi, criteria, syarat atau kemampuan yang harus dimiliki oleh perangkat lunak untuk memenuhi apa yang diisyaratkan atau diinginkan pemakai.

Secara kategoris, ada tiga buah jenis kebutuhan perangkat lunak [IEE93]:

  1. Kebutuhan Fungsional (functional requirement)
    Kebutuhan yang berkaitan dengan fungsi atau proses transformasi yang harus mampu dikerjakan oleh perangkat lunak.
    Contoh :
    * Perangkat lunak harus dapat menyimpan semua rincian data pesanan pelanggan.
    * Perangkat lunak harus mampu mencetak laporan penjualan sesuai periode yang diinputkan.
    * Perangkat lunak harus mampu menyajikan informasi jalur pengiriman terpendek
  2. Kebutuhan Antarmuka (interface requirement)
    Kebutuhan antarmuka yang menghubungkan perangkat lunak dengan elemen perangkat keras, perangkat lunak, atau basis data.
    Contoh:
    * Akses ke basis data menggunakan ODBC (Open Data Base Connectivity).
    * Perangkat untuk memasukkan data menggunakan keyboard, mouse, dan scanner.
  3. Kebutuhan Unjuk Kerja (performance requirement)
    Kebutuhan yang menetapkan karakteristik unjuk kerja yang harus dimiliki oleh perangkat lunak, seperti kecepatan, ketepatan, atau frekuensi.
    Contoh:
    * Waktu tanggap penyajian informasi maksimal selama satu menit.
    * Perangkat lunak harus mampu mengolah data sampai 1 juta record untuk setiap transaksi.
    * Perangkat lunak harus dapat digunakan secara multi usersesuai otoritas yang diberikan kepada masing-masing pemakai

Proses-proses dalam rekayasa kebutuhan perangkat lunak

Gambar 1. Proses aktivitas rekayasa kebutuhan
Gambar 1. Proses aktivitas rekayasa kebutuhan

Ada tiga faktor yang harus dipenuhi ketika melakukan analisis kebutuhan ini, yaitu lengkap, detail, dan benar.

  • Lengkap artinya semua yang diharapkan oleh klien telah didapatkan oleh pihak yang melakukan analisis.
  • Detail maksudnya adalah berhasil mengumpulkan informasi yang terperinci.
  • Semua data dari analisis kebutuhan ini haruslah benar, sesuai apa yang dimaksud oleh klien, bukan benar menurut apa yangdipikirkan oleh pihak analisis.

Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan menghasilkan spesifikasi perangkat lunak tersebut. Analisa kebutuhan ini terdiri dari lima langkah pokok:

  1. Mempelajari dan memahami persoalan.
    Hasil pemahaman masalah tersebut selanjutnya digambarkan dalam bentuk model-model tertentu sesuai dengan jenis masalahnya. Sebagai contoh, untuk masalah bisnis dapat menggunakan flow-map atau business use case, sementara untuk masalah matematika dapat mengunakan, misalnya, graf.
  2. Mengidentifikasi kebutuhan pengguna.
    Sebenarnya, tahap identifikasi kebutuhan pemakai (user requirement) ini pada prakteknya dilaksanakan bersamaan dengan pemahaman masalah.
    Untuk dapat menangkap kebutuhan pemakai dengan baik, utamanya kesamaan persepsi, dibutuhkan:
    * Komunikasi dan brainstorming yang intensif
    * Prototype perangkat lunak, atau screen snapshot
    * Data atau dokumen yang lengkap
  3. Mendefinisikan kebutuhan perangkat lunak.
    Saat mengidentifikasi kebutuhan pemakai, informasi yang diperoleh belum terstruktur. Pemakai akan mengungkapkan apa yang dibutuhkannya dengan bahasa sehari-hari yang biasa digunakan pemakai. Pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka, dan unjuk kerja perangkat lunak. Sebagai gambaran, kebutuhan “data yang dimasukkan oleh Bagian Penjualan dapat langsung dijurnal” setelah dianalisis, diklasifikasikan, dan diterjemahkan.
  4. Membuat dokumen spesifikasi kebutuhan.
    Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan dokumentasinya, yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirements Specification(SRS). SKPL yang dibuat harus dapat menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunak, termasuk deskripsi lengkap dari semua antarmuka yang digunakan. SKPL bisa terdiri dari banyak dokumentasi yang saling melengkapi.
  5. Mengkaji ulang (review) kebutuhan.
    Proses untuk memeriksa (validasi) SKPL apakah sudah konsisten, lengkap, dan sesuai dengan apa yang diinginkan pemakai. Proses ini mungkin dilakukan lebih dari satu kali. Dan sering kali muncul kebutuhan-kebutuhan baru dari pemakai. Untuk itu, diperlukan negosiasi antara pihak pengembang dengan pemakai sesuai prinsip “win-win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak.
Gambar 2. Daur Hidup Perangkat Lunak

Sekian dari saya, semoga teman-teman dapat lebih memahami siklus dalam pengembangan perangkat lunak tidak hanya dalam pengkodean tapi juga dalam pendokumentasian serta memahami pentingnya paham terhadap kebutuhan client.

Salam dari saya, tunggu artikel selanjutnya ya ~

--

--

Asnafi
Asnafi

Written by Asnafi

Software Engineer | OSS Enthusiast

Responses (1)