Langsung ke konten utama

Studi Kasus 7 - Rekayasa Kebutuhan (D)

 STUDI KASUS 7 : PEMBUATAN SPESIFIKASI (MOKAPOS)



MokaPOS merupakan sebuah aplikasi yang memiliki sebuah sistem bernama point-of-sale berbasis cloud yang dapat memudahkan penjualan dan proses operasional sebuah usaha penjualan perusahaan. Aplikasi ini ditujukan kepada pengembangan usaha kecil dan menengah. Sebuah sistem yang dipakai MokaPOS disini bernama Point of Sale (POS), merupakan sebuah konsep metode yang dapat menginterasikan hardware (perangkat keras) dan software (perangkat lunak) untuk kebutuhan administrasi pembayaran seperti kasir. Konsep ini hadir unruk memudahkan transaksi secara langsung antara pemilik toko dengan pelanggan lebih mudah. Teknologi ini tersusun atas peralatan kasir umumnya seperti pencetak struk, laci uang, dan kalkulator harga item yang dijual. 

MokaPOS juga mengoptimalkan operasional bisnis dan juga menyediakan sebuah platform penunjungan untuk pelaku usaha dalam melakukan operasi penjualan. MokaPOS juga dapat memungkinkan pelaku usaha untuk melakukan beberapa hal seperti transaksi penjualan dan nominal harga promo yang dapat diperbarui secara real-time, serta beberapa manajemen seperti manajemen stok, manajemen meja, manajemen pesanan dan manajemen pelanggan. Dalam melakukan pembiayaan aplikasi ini juga dapat memungkinkan pelaku usaha untuk menggabungkan usaha dengan beberapa metode-metode pembayaran seperti GoPay, OVO, DANA, serta e-wallet lainnya. Selain itu juga, dalam melakukan penyebaran usahanya pelaku usaha juga dapat menggunakan platform tunjungan secara daring seperti adanya sebuah integrasi Instagram, TikTok, Facebook, dan Google Shooping serta beberapa aplikasi penunjang lainnya. 

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

Dalam pembuatan spesifikasi tentunya perlu memikirkan tentang pembagian prioritas terhadap level yang dapat ditentukan untuk suatu kebutuhan. Metode yang dimaksud yakni menggunakan pada metode MoSCoW, metode ini merupakan sebuah akronim yang dirancang untuk mencerminkan empat kategori yang digunakan dalam metode ini. MoSCoW disini dapat menentukan prioritas yaittu MUST, SHOULD, CAN, WON'T huruf "o" ditambahkan hanya untuk memudahkan akronim untuk diucapkan. Metode MoSCoW  paling efektif yang dapat digunakan untuk memprioritaskan kebutuhan, fungsi atau bagian dalam proyek dengan tenggat waktu tetap atau ketat. Adapun pedomen yang digunakan dalam MoSCoW disini yakni : 


Setelah memikirkan pembagian prioritas dengan menentukan berbagai macam seperti fungsi, kebutuhan, dan bagian proyek, maka selanjutnya tahap selanjutnya pengembangan solusi atau aplikasi dapat dilakukan dengan memfokuskan kepada pembagian usaha, sumber daya, serta waktu pengerjaan proyek.

KEBUTUHAN APLIKASI 

Dalam penentuan spesifikasi kebutuhan aplikasi kita juga perlu memikirkan adanya sebuah kebutuhan penting dalam aplikasi yang akan dibangun. Kebutuhan aplikasi ini merupakan sebuah kebutuhan-kebutuhan yang beberapa diperlukan dalam pembangunan aplikasi. Kebutuhan yang dimaksud yakni: 
  • Menyediakan tutorial penggunaan aplikasi.
  • Menyediakan user guide bagi pengguna aplikasi.
  • Perlunya pembenahan sistem konvensional menjadi sistem yang lebih modern sehingg memudahkan kasir untuk bertransaksi denga pelanggan.
  • Perlunya sistem yang tidak hanya bisa mencetak struk pelanggan, tetapi juga bisa mendata inventori barang, mengetahui detail laporan penjualan dan profit yang bisa diatur baik harian, mingguan, bulanan, maupun tahunan.
  • Perlunya sistem yang memiliki keamanan dalam bertransaksi.

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. 

Komentar

Posting Komentar

Postingan populer dari blog ini

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 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 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