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

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

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

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)