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 4 - Elisitasi Kebutuhan (D)

  STUDI KASUS 4 : ELISITASI KEBUTUHAN.  MENTA merupakan sebuah aplikasi berbasis web yang bertujuan untuk  memberikan pelayanan dalam hal Kesehatan mental berupa konseling online.  Selain konseling online, aplikasi ini juga dapat membantu dengan menyuguhkan  artikel dan bacaan yang berhubungan dengan Kesehatan mental dan atau  penyembuhannya. Hal tersebut akan sangat membantu proses perawatan dan  penyembuhan gangguan mental lebih mudah untuk digapai semua masyarakat.  Pihak-pihak yang terlibat dalam aplikasi ini adalah terapis (psikolog), dan  pasien. Terapis dan pasien dapat bergabung dengan cara melakukan registrasi  secara online pada system. Sistem ini dibuat sebagai dukunhan terhadap penderita  Kesehatan mental maupun masyarakat awam untuk bisa mengambil Tindakan yang  preventif dan represif.  ABOUT ELISITASI KEBUTUHAN  Elisitasi kebutuhan adalah sekumpulan aktivitas yang ditujukan untuk menemukan kebutuhan suat...
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

Studi Kasus 5 - Business Requirement Airbnb (D)

  STUDI KASUS 5 : BUSINESS REQUIREMENT AIRBNB Airbnb merupakan bisnis yang mengusung konsep   sharing economy , yang menggunakan properti sebagai sarana. Bisa dibilang, konsep Airbnb tak jauh beda dengan Gojek. Bedanya, jikalau Gojek menggunakan kendaraan, Airbnb menggunakan properti yang bisa berbentuk ruang tamu, kamar, tempat kost, dan lain-lain, yang bisa disewa. Tidak hanya itu, bentuk bisnisnya juga tak jauh beda dengan aplikasi Gpjek, Grab, dan lain hal sebagainya. Umpama kita punya rumah kosong, dan ingin bergabung dengan bisnis Airbnb, kita bisa mendaftarkan rumah tersebut pada Airbnb. Setelah disetujui, sistem Airbnb akan menawarkan rumah kita pada orang-orang yang mungkin ingin menginap. Jika ada orang yang menginap di rumah yang kita sediakan, kita mendapatkan bayaran (ongkos sewa). Selanjutnya, jika Uber, Grab, maupun Go-Jek mendisrupsi sistem transportasi konvensional, Airbnb mendisrupsi sistem akomodasi yang ditopang oleh hotel atau penginapan konvensional....
Posting Komentar
Baca selengkapnya