Skip to main content

Studi Kasus 7 | Rekayasa Kebutuhan (B)

 Pembuatan Spesifikasi

Pada kesempatan kali ini akan dibahas tentang pembuatan spesifikasi pada studi kasus point-of-sales (PoS) MokaPos.

Deskripsi Sistem

PoS merupakan tempat sistem untuk memudahkan proses pembayaran para pelanggan di suatu toko ketika membeli suatu produk ataupun layanan. Sistem ini biasanya menggunakan tablet, smartphone, atau mesin EDC sebagai antarmuka kasir. PoS dapat menghitung secara cepat, menyetak struk, menghitung laba, menyimpan data pelanggan, merekap data penjualan, dan dapat terkoneksi dengan internet.


MokaPos secara spesifik merupakan PoS berbasis perangkat bergerak dengan fokus pada pelaku usaha mikro, kecil, dan menengah. Sistem ini menyediakan fitur yang mencakupi hal-hal umum yang diharapkan pada sistem PoS ditambah dengan pengelolaan karyawan, manajemen data, dan menerima tanggapan dari konsumen. Selain itu, MokaPos memungkinkan integrasi dengan pihak bank dan penyedia pembayaran lainnya serta mengelola diskon.

Metode

Pembuatan spesifikasi ini didasari pada metode MoSCoW (Must, Should, Could, Won't).

Sebelum menerapkan metode ini, sebuah tim harus telah setuju dengan tujuan dari proyek dan segala pertentangan telah teratasi. 

Metode ini digunakan untuk menentukan

Kebutuhan

Terdapat beberapa kebutuhan yang harus dipenuhi oleh sistem Mokapos, yakni
  1. Sistem dapat memperbolehkan pengguna untuk masuk (login) dengan role kasir
  2. Sistem dapat mengirimkan undangan akun melalui email kepada pengguna
  3. Sistem dapat mengakomodasi beberapa jenis usaha yang dapat dipilih oleh kasir
  4. Sistem dapat menampilkan menu favorit pada usaha toko
  5. Sistem dapat melakukan perubahan pada menu favorit sesuai masukan dari kasir
  6. Sistem dapat menampilkan semua menu yang terdaftar di toko
  7. Sistem dapat menyimpan menu baru sesuai masukan dari kasir
  8. Sistem dapat membuat struk transaksi oleh kasir
  9. Sistem dapat mengakomodasi pengadaan diskon
  10. Sistem dapat memperbolehkan penambahan menu custom ketika pembuatan struk
  11. Sistem dapat memulai sesi shift sebagai kasir
  12. Sistem dapat menyimpan jumlah cash di awal sesi shift oleh kasir
  13. Sistem dapat menampilkan statistik kinerja toko selama satu sesi shift
  14. Sistem dapat mengakhiri sesi shift sebagai kasir
  15. Sistem dapat menambahkan menu ke transaksi yang sedang berlangsung
  16. Sistem dapat mengaitkan menu dengan salah satu diskon saat penambahan menu ke transaksi
  17. Sistem dapat memfasilitasi transaksi yang langsung dibayar oleh pelanggan di kasir
  18. Sistem dapat menyimpan menu dengan quantity lebih dari satu ke transaksi
  19. Sistem dapat memfasilitasi proses bisnis take away/dine-in
  20. Sistem dapat menambahkan pelanggan baru ke database
  21. Sistem dapat menampilkan pelanggan yang sudah terdaftar
  22. Sistem dapat menampilkan metode pembayaran yang tersedia
  23. Sistem dapat menampilkan daftar open bills
  24. Sistem dapat mencetak struk
  25. Sistem dapat mengirimkan struk melalui email
  26. Sistem dapat mengirimkan struk melalui sms
  27. Sistem dapat melakukan pengurangan menu yang ada di transaksi
  28. Sistem dapat melakukan penjagaan pada pengurangan menu dengan membutuhkan pin
  29. Sistem dapat menampilkan historis transaksi
  30. Sistem dapat menyimpan transaksi
  31. Sistem dapat mengakomodasi proses split bill



Labels

Labels:

Comments

Post a Comment

Popular posts from this blog

EAS | Rekayasa Kebutuhan (B)

 Studi Kasus AutoRent Deskripsi AutoRent  adalah perusahaan yang menyediakan sewa mobil di kota Surabaya. Sayangnya, proses bisnisnya belum terkomputerisasi sehingga menyebabkan inkonsistensi data, memperlambat proses penyewaan, dan mengurangi kenyamanan pelanggan. Saat ini, perusahaan membutuhkan sistem informasi yang dapat membantu mengatasi masalah yang ada. Sistem informasi yang akan dibangun merupakan sistem informasi bagi staf (admin) AutoRent untuk melakukan input data perusahaan dan melayani pelanggan yang datang langsung ke lokasi. Stakeholder Terdapat beberapa pihak yang terlibat pada proses bisnis di AutoRent, yakni: Pemilik perusahaan, Staf (admin), dan Pelanggan. Kebutuhan Terdapat dua jenis kebutuhan yang perlu dieksplorasi pada studi kasus ini, yakni kebutuhan fungsional dan kebutuhan non-fungsional. Kebutuhan Fungsional Sistem dapat menyediakan fitur login untuk admin, Sistem dapat mengelola data mobil yang dimiliki perusahaan, Sistem dapat mengelola data jenis...
Post a Comment
Read more

Studi Kasus 4 | Rekayasa Kebutuhan (B)

  Hello! Pada kesempatan ini, saya ditemani oleh Bayu Adjie Sidharta (05111940000172) untuk membahas tentang " Requirement Elicitation". Tugas ini dikerjakan berdasarkan dokumen SKPL berjudul "SI Evaluasi Kegiatan Sekretariat ITS" yang dapat dilihat di bawah ini. Penyelenggara Aplikasi Aplikasi ini diselenggarakan oleh ITS. ITS atau Institut Teknologi Sepuluh Nopember Surabaya adalah sebuah perguruan tinggi negeri di surabaya. ITS yang didirikan pada 10 Nopember 1957 adalah salah satu perguruan tinggi terbaik di Indonesia. Deskripsi Aplikasi Kegiatan yang dilaksanakan dalam naungan ITS beragam-ragam, dari kegiatan umum, mahasiswa, tenaga pendidik, dan serta staff ITS. Sebagai perguruan tinggi yang baik, ITS selalu ingin berkembang dan meningkatkan kualitas kegiatannya melalui pengadaan survei untuk mengetahui masukan atau evaluasi dari peserta. Harapannya, melalui survei tersebut, dapat diidentifikasi apakah tujuan kegiatan telah tercapai dan bagaimana cara meningka...
Post a Comment
Read more

Tugas 8 | Pemrograman Berbasis Kerangka Kerja (A)

 CodeIgniter 4 Tugas di minggu ini adalah untuk mencoba CodeIgniter, sebuah kerangka kerja yang menggunakan PHP untuk pengembangan web dinamis. Hal yang perlu dicoba adalah membuat dua halaman baru, yakni "about" dan "contact". Tampilan Pengerjaan tugas dapat diakses melalui link ini .
Post a Comment
Read more