Langsung ke konten utama

Studi Kasus 8 - Rekayasa Kebutuhan (D)


STUDI KASUS 8 : ANALISIS DESAIN PEMBUATAN SPESIFIKASI APLIKASI MOKAPOS



MokaPOS merupakan  aplikasi dengan sistem point of sale berbasis cloud yang dapat mendukung proses penjualan dan  operasional bisnis perusahaan. Aplikasi ini ditujukan untuk pengembangan usaha kecil dan menengah. Sistem yang digunakan oleh MokaPOS disini disebut Point of Sale (POS), yaitu suatu metode konseptual yang dapat mengintegrasikan perangkat keras (hardware) dan perangkat lunak (software) untuk melayani kebutuhan administrasi pembayaran seperti penagihan dan pembayaran. 

MokaPOS memungkinkan bisnis untuk melakukan beberapa hal, seperti harga promosi dan penjualan  yang diperbarui secara real-time, manajemen inventaris, manajemen meja, manajemen pesanan, dan manajemen pelanggan. MokaPOS juga memungkinkan bisnis untuk menghubungkan bisnis dengan metode pembayaran seperti GoPay, OVO, DANA, dll. Selain itu, MokaPOS juga memungkinkan pelaku bisnis menggunakan platform online tunjungan  untuk mengembangkan bisnisnya, dengan  integrasi Instagram, Facebook, dan Google Shopping.

METODE MoSCoW : Must, Should, Could, Won't


Selama pengembangan spesifikasi, tentu saja perlu memikirkan alokasi prioritas yang dapat ditentukan untuk suatu kebutuhan. Metode yang dimaksud dengan menggunakan metode MoSCow, yang merupakan sebuah akronim yang dirancang untuk mencerminkan empat jenis yang digunakan dalam metode ini. MoSCoW disini dapat menentukan beberapa prioritas, yakni berdasarkan Must, Should, Could and Won;t. Metodologi ini dapat dikatakan paling efektif dapat digunakan untuk memprioritaskan kebutuhan, fungsi, atau bagian dalam proyek dengan tenggat waktu yang tetap atau ketat. 

FUNCTIONAL REQUIREMENT 

Kebutuhan Fungsional merupakan sebuah aksi atau fitur yang harus terdapat pada sistem yang sedang dibangun untuk memenuhi kebutuhan bisnis dari aplikasi terkait. Kebutuhan fungsional juga harus meliputi informasi-informasi yang akan dihasilkan oleh sistem sehingga dapat diterima oleh pengguna sistem. Beberapa kebutuhan fungsional pada aplikasi ini di antara lain:
  • (SKPL-F01) Sistem harus menyediakan fitur login untuk penjual 
  • (SKPL-F02) Sistem harus menyediakan fitur registrasi untuk penjual 
  • (SKPL-F03) Sistem harus memungkinkan penjual mengelola manajemen stok. 
  • (SKPL-F04) Sistem harus memungkinkan penjual mengelola manajemen pelanggan. 
  • (SKPL-F05) Sistem harus memungkinkan penjual mengelola manajemen meja pada outlet. 
  • (SKPL-F06) Sistem harus memungkinkan penjual mengelola manajemen karyawan. 
  • (SKPL-F07) Sistem harus memungkinkan penjual untuk menggunakan sistem point-of-sale/kasir pada outlet. 
  • (SKPL-F08) Sistem harus dapat menampilkan laporan penjualan dan investaris untuk penjual.  
  • (SKPL-F09) Sistem dapat memungkinan penjual untuk mengelola outlet-outlet yang dimiliki
  • (SKPL-F10) Sistem dapat memungkinkan penjual untuk mengaktivasi E-Wallet
  • (SKPL-F11) Sistem dapat memungkinkan penjual untuk melakukan integrasi terhadap akun Instagram, Facebook, maupun Google. 
  • (SKPL-F12) Sistem dapat memungkinkan penjual untuk melakukan kustomisasi sistem pembayaran
  • (SKPL-F13) Sistem harus dapat melakukan update pada manajemen-manajemen milik usaha secara real time
  • (SKPL-F14) Sistem menyediakan fitur untuk penjual mengelola shift 
  • (SKPL-F15) Sistem harus memungkinkan penjual untuk melakukan split bill sesuai permintaan pelanggan. 
  • (SKPL-F16) Sistem harus memungkinkan penjual untuk mengirimkan/mencetak bill untuk pelanggan
  • (SKPL-F17) Sistem harus memungkinkan penjual untuk melakukan refund
  • (SKPL-F18) Sistem harus memungkinkan penjual untuk mengelola promo
  • (SKPL-F19) Sistem dapat memungkinkan pembeli untuk melakukan pembayaran dengan E-Wallet

NON-FUNCTIONAL REQUIREMENT 

Sejumlah atribut kualitas yang dimiliki oleh sebuah sistem untuk mendukung sistem tersebut untuk mencapai kebutuhan dari stakeholder. Kebutuhan non-Fungsional menempatkan batasan pada produk yang sedang dikembangkan, proses pengembangannya dan menentukan batasan-batasan eksternal yang harus dipenuhi oleh produk tersebut. Beberapa kebutuhan non-Fungsional menurut aplikasi MokaPOS yakni :
  • (SKPL-NF01) Sistem dapat diakses selama 24 jam setiap harinya.
  • (SKPL-NF02) Sistem dapat diakses sesuai dengan role pengguna.
  • (SKPL-NF03) Sistem dapat diakses dari browser manapun serta aplikasi. 
  • (SKPL-NF04) Sistem dapat menjamin keamanan data pelanggan dan penjual.
  • (SKPL-NF05) Apabila sistem error maka harus dapat diselesaikan dalam waktu kurang dari 30 detik.
  • (SKPL-NF06) Sistem harus dapat menangani permintaan secara bersamaan. 
  • (SKPL-NF07) Sistem harus memiliki latensi rendah. 
  • (SKPL-NF08) Sistem harus dapat menjamin keamanan transaksi penjualan. 

SPESIFIKASI KEBUTUHAN : BASED ON VIDEO YOUTUBE



Dengan menggunakan metode-metode di atas, dapat digali lebih dalam lagi dan dibuat lagi spesifikasi kebutuhan dari aplikasi yaitu sebagai berikut:
  1. Sistem harus dapat menyediakan penjual melakukan registrasi ke dalam sistem dapat ditunjukkan pada menit (00:56)

  2. Pada menit (01:03) terdapat 3 kebutuhan sepesifikasi, yakni pertama sistem harus dapat menyediakan penjual melakukan login, sistem harus menyediakan penjual memanajemen login sebagai kasir ke dalam sistem dan sebagai pengguna juga diharuskan dapat membuat password baru jika lupa akses password lama. Oleh karena itu sistem harus dapat melakanan 3 kebutuhan spesifikasi.

  3. Sistem harus menyediakan penjual memilih outlet untuk dapat menyesuaikan bisnis yang dimiliki. Kebutuhan fungsi ini dapat ditemukan pada menit (01:34)

  4. Pada menit (01:48) dapat ditemukan satu spesifikasi kebutuhan yakni, sistem dapat menyediakan penjual tampilan menu makanan ataupun minuman favorit yang dijual di dalam sistem.

  5. Sistem dapat menyediakan penjual tampilan keseluruhan menu mekanan ataupun minuman yang dijual di dalam sistem pada menit (02:03)

  6. Selanjutnya, apabila menu belum tercatat di dalam sisstem, sistem harus dapat menyediakan penjual menambahkan data menu secara kustom. Hal ini dapat ditemukan pada menit (02:11).

  7. Sistem dapat menyediakan penjual membuat shift sebagai data harian penjualan dengan awalan jumlah kas dalam kasir (02:29).

  8. Pada menit (02:42) juga dapat ditemukan sebuah spesifikasi kebutuhan, yakni sistem harus dapat menyediakan penjual mengetahui statistik terkini penjualan.

  9. Selanjutnya, pada menit (03:10) dapat ditemukan 3 spesifikasi kebutuhan antara lain: 

    • Sistem dapat menyediakan penjual menambah kuantitas pesanan
    • Sistem dapat menyediakan penjual memberikan diskon terhadap pesanan
    • Sistem dapat menyediakan juga penjual memilih tipe pesanan, apakah makanan di tempat (dine-in), take away Go-Food, ataupun Grab 
  10. (03:22) Sistem dapat menyediakan penjual melakukan pembayaran setelah menambahkan menu ke dalam pesanan 

  11. Sistem dapat menyediakan penjual menyimpan data konsumen yang melakukan pemesanan menu pada menit (03:27).

  12. Apabila customer ingin membayar menggunakan cash, sistem harus dapat memproses pembayaran tunai sesuai dengan input yang diberikan. (03:39)

    • Selain itu, sistem juga dapat menyediakan penjual menerima pembayaran dengan sistem e-wallet. 
    • Sistem dapat menyediakan penjual menerima pembayaran dengan kartu kredit ataupun debit 
    • Selanjutnya, sistem dapat menyediakan penjual menerima pembayaran yang tercatat di dalam Go-Food 
  13. Pada menit (05:00), terdapat 2 spesifikasi kebutuhan yakni:

    • Apabila pelanggan ingin struk dikirim melalui email ataupun nomor, maka sistem harus dapat mengirimkan struk tersebut dikirim secara digital. 
    • Selanjutnya, apabila custome ingin mencetak struk kertas, sistem dapat mencetak bill dengan menggunakan printer. 
     
  14. Sistem dapat menyediakan penjual menyimpan tagihan sementara agar dapat dibayar saat akhir. Spesifikasi kebutuhan ini dapat ditemukan pada menit. Dalam hal ini sistem juga dapat memungkinkan pengguna menyimpan nama bill untuk dibuka kembali (05:42)

  15. (06:12) Apabila pengguna ingin melihat riwayat pembayaran, sistem dapat menampilkan beberapa riwayat secara detail sesuai dengan shift. 

  16. Selanjutnya apabila pelanggan ingin melakuakn pembayaran dilakukan secara bertahap, maka sistem harus dapat melakukan split bill. 

  17. Sistem dapat menyediakan penjual melakukan otorisasi kasir apabila ingin melakukan perubahan ataupun penghapus item menu (06:35)

  18. Apabila pelanggan membatakan pesanan yang dipesan, maka kasir harus dapat menghapus item menu yang dimaksud. Oleh karena itu, sistem harus dapat menyediakan hal tersebut (06:39)

  19. Pada menit (07:07) terdapat 2 spesifikasi kebutuhan yakni antara lain: 

    • Sistem dapat menyediakan penjual melihat catatan aktivitas penjualan harian 
    • Sistem dapat menyediakan penjual melakukan pengiusan pengembalian dana
  20. Selanjutnya terdapat sebuah kondisi dimana apabila pengguna ingin mengakhiri shift, sistem harus dapat menampilkan laporan aktivitas saat shift sesuai dengan yang telah dilalui oleh pengguna (09:23)

  21. Selain itu juga, sistem pula harus dapat melakukan manajem shift berupa opsi shift, shift sekaranag, dan riwayat shift (09:23)
  22. Apabila pengguna telah menginputkan nilai tunai akhir, sistem harus dapat mengakhiri shift pengguna dengan menyimpan data tersebut (09:26)

  23. Apabila pengguna ingin keluar dari aplikasi, sistem harus dapat memungkinkan pengguna untuk log out  dari akun. 

                   



Komentar

Posting Komentar

Postingan populer dari blog ini

Studi Kasus 2 - Rekayasa Kebutuhan (D)

STUDI KASUS 2 : ANALISIS SKPL  EXISTING SYSTEM INFORMATION Berdasarkan kondisi dan perkembangan teknologi pada zaman sekarang, banyak manusia yang sudah tidak asing lagi untuk menggunakan teknologi dalam melakukan pembelian yang dilakukan secara  online.  Tidak hanya itu, efek yang dirasakan oleh pada warga khususnya Indonesia yang merasakan kesulitan dalam secara ekonomi dikarenakan kondisi saat ini. Salah satunya adalah Cokies Dessert, sebuah usaha UMKM milik seorang mahasiswa jurusan Agribisnis Universitas Brawijaya yang membuka usaha di tengah kondisi COVID-19 saat ini. Oleh karena itu, terbentuklah sebuah sistem yang akan membantu pemilik untuk dapat memperluas usaha tersebut yang akan digunakan untuk mempermudah pelanggan dalam melakukan pembelian kue-kue kering tersebut. Selain itu juga dapat digunakan untuk mempermudah dalam pengaturan stok produk ataupun pemantauan transaksi pembelian. Sistem tersebut bernama SICODE atau Sistem Informasi Penjualan Cokies Dessert yang dimana s
Posting Komentar
Baca selengkapnya

STUDI KASUS 9 - Rekayasa Kebutuhan (D)

STUDI KASUS 9 : BUSINESS OBJECT MODEL (BOM) DAN FEATURE TREE LOKET.COM  LOKET.COM  merupakan sebuah platform penjualan tiket dengan menggunakan Ticketing Management System (TMS) teknologi unggul dalam mendukung seluruh penyelenggara event mulai dari distribusi dan manajement tiket, hingga penyediaan laporan analisa event di akhir acara. Berdasarkan website LOKET.COM, aplikasi ini   memiliki beberapa teknologi yang dapat digunakan untuk memfasilatasi penyelenggara event dalam setiap tahap persiapan dan penyelenggaran sebuah event, beberapa teknologi tersebut antara lain:  Sistem pembayaran yang beragam dan aan sehingga memberikan kemudahan kepada calon pembeli, untuk mendapatkan konversi yang lebih tinggi.  Distrubutor tiket terlengkap yang telah bekerja sama dengan LOKET untuk menjual tiket penyelenggara sebuah event. Terdapat sebuah Gate Managemnt yang paling aman dan nyaman untuk akses saat event berlangsung. Sehingga, event dengan jumlah penonton yang besar dapat ditangani dengan m
Posting Komentar
Baca selengkapnya

Studi Kasus 6 - Rekayasa Kebutuhan (D)

STUDI KASUS 6 RK D : BRD AIRBNB BUSINESS REQUIREMENT DOCUMENT (BRD)  DOCUMENT  Dokumen ini dibuat merupakan untuk memenuhi tugas Rekayasa Kebutuhan D yang dibuat oleh:  Julietta Anastasia Robiah Br Panjaitan (05111940000033) Rayhan Daffa Alhafish (05111940000227)  
Posting Komentar
Baca selengkapnya