Langsung ke konten utama

Tahapan Rekayasa Kebutuhan (RE)

  

 


Tahapan Rekayasa Kebutuhan

        Dalam bahasan kali ini saya akan membahas mengenai tahapan yang dilakukan seorang developer dalam melakukan Rekayasa Kebutuhan, dalam hal ini saya menggunakan studi kasus Spesifikasi Kebutuhan Perangkat Lunak (SKPL) "Sistem Informasi Survei Kepuasan Pelanggan Its Secara Terpadu". Sistem ini memungkinkan user mengisi survey yang telah dibuat oleh admin yang bertujuan untuk menilai layanan yang dimiliki ITS terhadap para pelanggannya sebagai bahan evaluasi kedepannya. Berikut dokumen SKPL yang saya gunakan. 


Elicitation

Elicitation merupakan salah satu proses yang fokus untuk memahami keperluan dari stakeholder maupun dari user. Berikut hasil analisis kebutuhan Sistem Informasi Survei Pelanggan ITS.

Pengguna

  • Sistem yang dapat menyampaikan penilaian dan pendapatnya terkait layanan yang dimiliki ITS

Admin

  • Sistem yang dapat menerima dan mengumpulkan data dari para pelanggan ITS 
  • Sistem yang dapat menampilkan rangkuman dan grafik perkembangan hasil penilaian survei dari pelanggan ITS
  • Membuat survei baru yang dapat diisi oleh setiap pelanggan ITS. 

Understanding

Berdasar proses Elicitating diperoleh daftar fitur yang perlu ada pada Sistem Survei Pelanggan ITS. 

    Admin

  • Login Admin untuk membatasi user yang bukan admin untuk tidak dapat mengakses hal tersebut.
  • Menambah Data Survei 
  • Mengedit Data Survei
  • Melihat laporan hasil survei

    Pelanggan ITS

  • Mengisi Survei


Specification

Dari hasil analisis atas kebutuhan Sistem Informasi Pelanggan ITS yang akan dibuat, dilakukan pembuatan spesifikasi sebagai berikut.


  • Sistem memungkinkan admin untuk mengakses halaman khusus admin
  • Sistem dapat menampilkan form yang berisi daftar pertanyaan untuk dapat diisi oleh pengguna, dalam hal ini Pelanggan ITS
  • Sistem dapat menambah dan menyimpan pertanyaan yang dimasukan oleh admin
  • Sistem dapat mengganti data yang sudah tersimpan pada database.
  • Sistem dapat menampilkan hasil survei berdasar database terbaru.
    • Hasil survei berupa grafik perkembangan survei dan penilaian pelangggan terhadap layanan ITS


Validation

Tahapan untuk memastikan bahwa sepsifikasi yang diperoleh sudah sesuai dengan kebutuhan yang diinginkan stakeholder.

  • Hasil spesifikasi yang berupa SKPL disampaikan kepada stakeholder untuk memperoleh persetujuan
  • Menguji hasil produk yang dibuat untuk memperoleh persetujuan dari stakeholder
  • Maintanance atau pemeliharaan. Jika produk sudah melalui proses deployment, diperlukan pemeliharaan untuk memastikan sistem selalu berjalan dengan baik.

Output

1. Sistem Perangkat Lunak "Survei Pelanggan ITS"


Sekian Tahapan dalam proses Rekayasa Kebutuhan dalam studi kasus Sistem Informasi Survei Pelanggan ITS.


Nama      : Mohammad Faderik Izzul Haq

Nrp         : 05111940000023

Kelas      : RK-B 2021



Komentar

Posting Komentar

Postingan populer dari blog ini

Rekayasa Kebutuhan - Sistem Informasi Penyewaan Mobil AutoRent

  sumber : https://www.assarent.co.id/upload/image/jasa-sewa-mobil-jogja.jpg Kebutuhan Funsional dan Non Fungsional aplikasi AutoRent Deadline : Selasa, 08 Juni 2022 : 10.00 WIB AutoRent merupakan sebuah perusahaan penyewa mobil di Kota Surabaya. Sistem penyewaan yang berjalan pada AutoRent belum terkomputerisasi. Pada proses yang berjalan terdapat beberapa masalah seperti proses penyewaan mobil dan pembuatan laporan yang tidak terintegrasi, sehingga menyebabkan kesalahan seperti redudansi data pada proses pembuatan laporan. Berdasarkan masalah tersebut AutoRent berencana membuat sistem yang bisa mempermudah proses penyewaan serta memberikan informasi penyewaan secara online. Berdasarkan informasi permasalahan yang ada dapat didefinisikan beberapa kebutuhan fungsional dan non-fungsional dari aplikasi yang akan dibangun sebagai berikut Kebutuhan Fungsional Functional Requirements merupakan kebutuhan yang mendeskripsikan kelakuan sistem yang mendukung tujuan dari sistem. Kebutuhan
Posting Komentar
Baca selengkapnya

Analisis Aplikasi Transaksi Parkir Non Tunai

sumber :  https://inugo.com/wp-content/uploads/2018/03/iso-enter-parking.png Analisis Aplikasi Transaksi Parkir Non Tunai           Pada proses Rekayasa Kebutuhan suatu sistem diperlukan analisis terhadap sistem yang akan dibangun. Berikut merupakan contoh studi kasus mengenai Aplikasi Transaksi Parkir Non Tunai. Berikut beberapa aspek yang akan di analisis. 1. Deskripsikan aplikasi Parkir  2. Identifikasi User dan Stakeholder 3. Tulis/ Gambarkan kebutuhan dari masing-masing user/ stakeholder 4. Tentukan aspek lain yang penting supaya aplikasi berjalan lancar Hasil Analisis : 1. Deskripsi Parkir meupakan hal fundamental yang sering dilakukan dalm kehidupan sehari-hari. Sejak dulu dikena; metode parkir konvensional dengan uang, mulai di pasar yang langsung diserahkan pada bapak-bapak tukang parkir, hingga di mall yang diserahkan kepada petugas jaga portal. Hal ini sudah lama menjadi budaya di Indonesia, namun hal ini memiliki beberapa kelemahan yakni efisiensi proses pembayaran yang kur
Posting Komentar
Baca selengkapnya