BAB III
ANALISIS KEBUTUHAN SISTEM
3.1. Deskripsi Singkat Kedai Soenda Kopi
Soenda Kopi berdiri pada 01 Maret 2017, Soenda Kopi ini menjadi kedai kopi pertama dikota Subang yang menjual macam-macam kopi berkualitas tinggi yang bertempat di Jalan Pejuang 45 No.65, kelurahan Karanganyar, kecamatan Subang, Kabupaten Subang, Provinsi Jawa Barat. Konsep kedai kopi yang bertemakan klasik dengan ornamen-ornamen berbahan dasar kayu, dan lampu bohlam berwarna kuning.
Selain itu Soenda Kopi memiliki dua konsep tempat makan, yang pertama dengan konsep di dalam ruangan, dan yang kedua berkonsep di luar ruangan dengan pemandangan pohon hias suasana alam.
3.1.1. Visi dan Misi Kedai Soenda Kopi 1. Visi
Menjadikan Soenda Kopi sebagai kedai kopi yang banyak digemari masyarakat dengan mengutamakan kopi dengan kualitas premium.
2. Misi
Mengembangkan inovasi-inovasi terbaru baik dari pelayanan maupun produk kopi itu sendiri dan tetap melestarikan petani kopi Indonesia dengan menjual produk kopi dalam negeri.
3.1.2. Struktur Organisasi Kedai Soenda Kopi
Tugas dan Fungsi Jabatan
1. Owner
Owner memiliki tugas untuk menetapkan kebijakan perusahaan. Owner mempunyai fungsi:
1) Sebagai orang yang memajukan perusahaan sekaligus pemilik kedai.
2) Mengembangkan sumber pendapatan.
3) Bertanggung jawab kepada seluruh karyawan.
4) Bertanggung jawab untuk memenuhi segala keperluan peralatan outlet.
5) Bertanggung jawab atas jam operasional outlet.
2. Pelayan
Tugas pokok pelayan yaitu melayanin kebutuhan pelanggan. Pelayanan memiliki fungsi:
1) Bekerja untuk mengantarkan pesanan.
2) Membersihkan tempat setelah konsumen selesai makan.
3) Bertanggung jawab atas kebersihan peralatan makan.
3. Barista
Barista memiliki tugas pokok yaitu mengelola dapur yang menjadi tanggung jawabnya.
1) Membuat permintaan pesanan oleh pelanggan.
2) Memasak makanan dan meracik minuman seperti kopi.
3) Melakukan pengadaan kebutuhan barang.
4. Kasir
Kasir memiliki tugas pokok yaitu mengantarkan pesanan jadi kepada konsumen.
1) Melaksanakan tata pembukuan, pengeluaran, dan pembayaran.
2) Mengelola pesanan dari pelanggan.
3.2. Analisis Sistem Lama
Proses analisis sistem lama perlu dilakukan dengan tujuan mengidentifikasi masalah dan hambatan yang terjadi disaat proses pemesanan di kedai kopi yang dilakukan masih dengan sistem manual, serta memberi solusi dengan cara menggunakan aplikasi berbasis mobile Android sehingga proses pemesanan di kedai kopi bisa mempermudah dalam pemesanan dan pengelolaan pesanan itu sendiri.
3.2.1. Prosedur yang Berjalan di Kedai Soenda Kopi Subang
Dalam melakukan pemesanan pelanggan harus antre di kasir, selanjutnya memilih menu di papan menu yang ada hanya menampilkan nama produk dan harganya saja, kemudian melakukan pembayaran di kasir, berikut gambaran flowmap sistemnya.
Gambar 3.1 Flow Map Sistem Lama
3.3. Analisis Kebutuhan Sistem
Analisis kebutuhan pada sistem ini akan menjelaskan kondisi atau kemampuan yang harus dipenuhi oleh sistem sesuai dengan spesifikasi yang diinginkan, meliputi kebutuhan informasi, dan kebutuhan aplikasi atau proses pengolahan data untuk menghasilkan informasi tersebut.
3.3.1. Kebutuhan Informasi
Kebutuhan informasi menjelaskan tentang kebutuhan informasi sesuai dengan apa yang diinginkan oleh pengguna atau user.
Tabel 3.1 Kebutuhan Informasi No Informasi yang
dibutuhkan
Tujuan Frekuensi 1 Detail Menu berupa foto
produk, deskripsi, harga, total pembayaran.
Pelanggan Setiap kali melakukan pemesanan 2 Detail transaksi masuk
pelanggan, produk, laporan transaksi.
Kasir Setiap ada transaksi masuk.
3 Detail transaksi masuk pelanggan, produk, laporan transaksi.
Owner Setiap saat, dan dimana saja.
3.3.2. Kebutuhan Perangkat Lunak
Kebutuhan perangkat lunak mendeskripsikan sistem secara umum dan menjelaskan kebutuhan-kebutuhan dari sistem infomasi yang akan dibangun.
1. Kebutuhan perangkat lunak untuk user.
Tabel 3.2 Kebutuhan Perangkat Lunak User
Kebutuhan Keterangan
Android, minimal versi 5.0 Lollipop Sistem operasi yang digunakan untuk menjalankan sistem
2. Kebutuhan perangkat lunak untuk programmer.
Tabel 3.3 Kebutuhan Perangkat Lunak Programmer
Kebutuhan Keterangan
Microsoft Windows 10 Digunakan untuk sistem oprasi
Visual Studio Code Digunakan sebagai text editor untuk merancang aplikasi
Flutter Digunakan untuk material Android
Android Studio Virtual Device Digunakan untuk menjalankan aplikasi
3. Kebutuhan perangkat lunak untuk server.
Tabel 3.4 Kebutuhan Perangkat Lunak Server
Kebutuhan Keterangan
Firebase Database
API Key Digunakan untuk menghubungkan sistem
yang dibangung dengan firebase
3.3.3. Kebutuhan Perangkat Keras
Kebutuhan perangkat keras merupakan komponen fisik yang memiliki spesifik atau kriteria tertentu agar dapat menjalankan sistem dengan baik. Kebutuhan perangkat keras yang dibutuhkan untuk menjalankan sistem sebagai berikut.
1. Kebutuhan perangkat keras untuk user.
Tabel 3.5 Kebutuhan Perangkat Keras Untuk User
Kebutuhan Spesifikasi Keterangan
Smartphone Android
Processor Snapdragon 480 Octa
Core up to 2.0GHz
RAM Minimal 2 GB
Penyimpanan Internal Minimal 8 GB
Versi Andorid Minimal versi 5.0 Lollipop
1. Kebutuhan perangkat keras untuk programmer.
Tabel 3.6 Kebutuhan Perangkat Keras Untuk Programmer
Kebutuhan Spesifikasi Keterangan
Smartphone Android
Processor Snapdragon 480 Octa
Core up to 2.0GHz
RAM Minimal 2 GB
Penyimpanan Internal Minimal 8 GB
Versi Andorid Minimal versi 5.0 Lollipop Laptop
Processor Intel i5-3470
RAM 8 GB DDR 4
Penyimpanan SSD 512 GB
3.4. Kebutuhan Fungsional
Kebutuhan fungsional merupakan kebutuhan yang dilihat dari fungsi perangkat lunak yang akan dibangun seperti yang terlihat pada tabel 3.4 sebagai berikut.
Tabel 3.7 Kebutuhan Fungsional
Nomor SRS Deskripsi
Aktor: Kasir, dan Owner
SRS-F-1 Sistem dapat menampilkan menu dashboard administrator.
SRS-F-2 Sistem dapat kelola produk dengan melakukan tambah data produk, melihat data produk, edit data produk, dan hapus data produk.
SRS-F-3 Sistem dapat kelola transaksi dengan melakukan edit data transaksi masuk, melihat data transaksi masuk, dan hapus data transaksi masuk.
SRS-F-4 Sistem dapat melihat data laporan transaksi, dan cetak data laporan transaksi.
SRS-F-5 Sistem dapat melakukan cetak struk Aktor: Pelanggan SRS-F-6 Sistem dapa melakukan SignUP.
SRS-F-7 Sistem dapat menampilkan daftar produk yang tersedia di kedai.
SRS-F-8 Sistem dapat menampilkan detail produk.
SRS-F-9 Sistem dapat melakukan pemesanan produk.
SRS-F-10 Sistem dapat menampilkan pilihan metode pembayaran dan meja yang tersedia di kedai.
Aktor: Pelanggan, Kasir, Owner SRS-F-11 Sistem dapat melakukan login.
SRS-F-12 Sistem dapat melakukan logout.
SRS-F-13 Sistem dapat menampilkan halaman tentang aplikasi kedai.
3.5. Kebutuhan Non Fungsional
Kebutuhan non fungsional adalah kebutuhan yang menitikberatkan pada properti perilaku yang dimiliki oleh sistem seperti yang terlihat pada tabel berikut.
Tabel 3.8 Kebutuhan Non Fungsional
Nomor SRS Deskripsi
SRS-NF-1 Sistem dibuat menggunakan framework Flutter SRS-NF-2 Sistem dibuat menggunakan Firebase
SRS-NF-3 Sistem dibuat menggunakan keamanan Password pada login SRS-NF-4 Tampilan sistem dirancang mempermudah user/pengguna
3.6. Aktor dan Use Case Diagram 3.6.1. Definisi Aktor
Berikut adalah table definisi aktor.
Tabel 3.9 Definisi Aktor
No. Aktor Deskripsi
1 Pelanggan Pelanggan merupakan aktor yang mempunyai tugas utama untuk melakukan pemesanan.
2 Kasir Kasir merupakan aktor yang mempunyai tugas utama untuk memvalidasi pembayaran, mengelola produk, dan mengelola orderan.
3 Owner Owner sebagai pemilik kedai yang berperan untuk bisa melakukan kelola produk, kelola transaksi dan pengecekan semua transaksi yang ada di kedai kopi.
3.6.2. Definisi Use Case
Gambar 3.2 Use Case Diagram
Tabel 3.10 Definisi Use Case Nomer Use Case Nama Use
Case
Deskripsi Aktor
UC-100 Login Use case menggambarkan
kegiatan memasukan username dan password
Owner, Kasir, Pelanggan UC-200 Kelola Produk Use case menggambarkan daftar
produk, edit produk dan hapus produk
Kasir, Owner UC-300 Kelola Transaksi Use case menggambarkan
kegiatan memproses pemesanan yang sudah dipesan oleh
pelanggan
Kasir, Owner
UC-400 Laporan
Transaksi
Use case menggambarkan kegiatan untuk menampilkan seluruh data transaksi yang sudah sukses.
Kaisr, Owner
UC-500 Pembayaran Use case menggambarkan kegiatan pembayaran yang dilakukan oleh pelanggan kepada kasir
Pelanggan
UC-600 Pembayaran Use case menggambarkan kegiatan penerimaan
pembayaran yang dilakukan oleh pelanggan
Kasir
UC-700 Menapilkan
Produk
Use case menggambarkan kegiatan menampilkan seluruh produk yang tersedia di kedai
Pelanggan
UC-800 Transaksi Use case menggambarkan kegiatan transaksi pemesanan makanan/minuman di kedai yang dilakukan oleh pelanggan
Owner, Kasir
3.7. Skenario
Skernario adalah jalur jalannya proses use case dari sisi aktor dan sistem.
3.7.1. Use Case Skenario Login
Gambar 3.3 Use Case Skenario Login
Tabel 3.11 Tabel Use Case Skenario Login
Aktor Kasir, Owner, Pelanggan
Prekondisi Aktor telah membuka halaman login aplikasi Hasil yang diharapkan Aktor masuk ke dalam sistem dan masuk sesuai
jenis aktornya Skenario Utama Login
Aksi Aktor Reaksi Sistem
1. Memasukan Username dan Password
2. Validasi username, password, dan hak akses aktor
3. Menunggu Validasi
Username, Password yang sudah diisi
4. Jika username dan password benar maka sistem menampilkan halaman sesuai hak akses Alternatif: Username dan Password salah
4. Jika username dan password salah maka sistem akan kembali menampilkan halaman login dan muncul pesan “Username atau Password salah”
5. Lengkapi data hinga lengkap 6. Kembali ke nomer 4 skenario Alternatif: Username atau email belum terdaftar
4. Jika username atau email belum ada di database maka sistem menampilkan pesan
“Username atau email belum terdaftar silahkan melakuakn SignUp terlebih dahulu”
Tabel 3.12 Tabel Usecase Skenario SignUp
Aktor Kasir, Owner, Pelanggan
Prekondisi Aktor telah membuka halaman login aplikasi dan pengguna belum pernah melakukan registrasi Hasil yang diharapkan Aktor masuk ke dalam sistem dengan melakukan
signup dan masuk sesuai jenis aktornya Skenario Utama Sign Up
Aksi Aktor Reaksi Sistem
1. Tap Button SignUp 2. Menampilkan halaman SignUp 3. Isi data username, email,
password
4. Tap SignUp 5. Validasi username, email, password 6. Menunggu validasi
username, Password yang sudah diisi
Jika username, email dan password sudah di isi dan benar maka sistem menampilkan halaman sesuai hak akses
Alternatif: Username atau email belum di isi
5. Jika username, email dan password belum di isi maka sistem akan kembali menampilkan halaman SignUp dan muncul pesan “Username atau email belum di isi”
Tabel 3.13 Tabel Usecase Skenario Logout
Aktor Kasir, Owner, Pelanggan
Prekondisi Aktor telah berada di halaman home kedai
kopi
Hasil yang diharapkan Aktor dapat keluar dari sistem kedai kopi
Aksi Aktor Reaksi Sistem
1. Tap logout di halaman About app 2. Menampilkan Halaman Login
3.7.2. Use Case Skenario Kelola Produk
Gambar 3.4 Use Case Kelola Produk
Tabel 3.14 Use Case Skenario Kelola Produk
Aktor Kasir, Owner
Prekondisi Aktor telah melakukan login dan berada di halaman utama administrator
Hasil yang diharapkan Aktor dapat mengelola data produk.
Skenarion utama menampilkan kelola produk Aksi Aktor Kasir, dan Owner Reaksi Sistem
1. Tap kelola produk 2. Sistem akan menampilkan halaman kelola produk dan menampilkan data produk yang ada Skenarion tamabah data produk
3. Tap tambah produk 4. Sistem akan menampilkan halaman tambah data produk
5. Isi form data produk dan tap simpan data produk
6. Jika data sudah lengkap maka data akan masuk ke database, sistem menampilkan pesan “data produk berhasil ditambahkan” dan kembali ke halaman kelola produk
Alternatif: jika form data produk masih ada yang kosong
6. Jika data yang di input masih kosong makan akan menampilkan pesan “data masih kosong”
7. Lengkapi data hingga lengkap 8. Kembali ke nomer 6 skenario tambah data produk Skenarion edit data produk
3. Tap data poduk yang akan di edit
4. Sistem akan menampilkan halaman edit data produk, dan form data produk yang akan di edit.
5. Edit data produk dan tap simpan data produk
6. Jika data sudah lengkap maka data akan masuk ke database, sistem menampilkan pesan “data produk berhasil diubah” dan kembali ke halaman kelola produk
Alternatif: jika form edit data produk masih ada yang kosong
6. Jika data yang di input masih kosong makan akan menampilkan pesan “data produk masih kosong”
7. Lengkapi data hingga lengkap 8. Kembali ke nomer 6 skenario edit data produk Skenario hapus data produk
3. Pilih data produk yang akan
di hapus, dan tap icon hapus 4. Menampilkan pesan “ingin hapus produk?”
5. Tap Oke 6. Muncul pesan “Produk berhasil di hapus” dan data terhapus di database
3.7.3. Use Case Skenario Kelola Transaksi
Gambar 3.5 Use Case Skenario Kelola Teransaksi
Tabel 3.15 Use Case Skenario Kelola Transaksi
Aktor Kasir, Owner
Prekondisi Aktor telah melakukan login dan berada dihalaman utama administrator kedai
Hasil yang diharapkan Aktor dapat mengelola data transaksi.
Skenarion utama menampilkan lihat data transaksi Aksi Aktor Kasir, dan Owner Reaksi Sistem
1. Tap kelola transaksi 2. Sistem akan menampilkan halaman kelola transaksi dan menampilkan data produk yang ada
Skenarion edit data transaksi 3. Tap data transaksi yang akan
di edit
4. Sistem akan menampilkan halaman edit data transaksi, dan list data transaksi yang akan di edit.
5. Edit data transaksi dan tap simpan data produk
6. Jika data sudah lengkap maka data akan masuk ke database, sistem menampilkan pesan “data
transaksi berhasil diubah” dan kembali ke halaman kelola transaksi
Alternatif: jika form edit data transaksi masih ada yang kosong
6. Jika data yang di input masih kosong makan akan menampilkan pesan “data transaksi masih kosong”
7. Lengkapi data hingga lengkap 8. Kembali ke nomer 6 skenario edit data produk Skenarion proses data transaksi
3. Pilih data transaksi dan tap icon print struk.
4. Sistem akan menampilkan file bentuk pdf
5. Tap cetak Struk 6. Sistem akan melakukan print struk dan kembali ke halaman kelola transaksi dan data transaksi statusnya berubah menjadi “sukses” dan datanya masuk ke halaman laporan transaksi Skenario hapus data transaksi
3. Pilih data transaksi yang akan
di hapus, dan tap icon hapus 4. Menampilkan pesan “ingin hapus transaksi?”
5. Tap Oke 6. Muncul pesan “Transaksi berhasil di hapus” dan data terhapus di database
3.7.4. Use Case Skenario Transaksi
Gambar 3.6 Use Case Skenario Transaksi
Tabel 3.16 Use Case Skenario Transaksi
Aktor Pelanggan
Prekondisi Aktor telah membuka halaman utama
Hasil yang diharapkan Aktor memilih produk, dan melakukan transaksi Skenario Utama Transaksi
Aksi Aktor Pelanggan Reaksi Sistem
1. Masuk halaman utama 2. Sistem menampilkan seluruh data produk dengan stok produk yang tersedia
3. Tap menu yang dipilih 4. Sistem akan menampilkan detail dari produk yang dipilih, seperti detail gambar, Deskripsi produk, harga, dan informasi lainnya.
5. Tap tambah pesanan 6. Sistem akan menampilkan pop up berupa produk sudah berhasil ditambahkan ke keranjang.
7. Tap lihat pesanan 8. Sistem akan mengarahkan ke halaman
keranjang, dan akan menampilkan seluruh data produk yang sudah ditambahkan sebelumnya.
9. Sesuaikan produk, quantity, dan total produk yang akan di pesan
Alternatif: jika ingin menambah quantity produk 10. Tap icon tambah yang ada
pada produk yang ingin di tamabah
11. Quantity produk akan menambah sesuai yang ditambahkan
Alternatif: jika ingin mengurangi quantity produk 10. Tap icon minus yang ada
pada produk yang ingin di tamabah
11. Quantity produk akan mengurangi sesuai yang ditambahkan
Alternatif: jika ingin menghapus produk yang telah dipilih 10. Tap icon tambah yang ada
pada produk yang ingin di tamabah
11. Quantity produk akan menambah sesuai yang ditambahkan
Skenario Daftar pesanan 12. Cek kembali list produk yang
akan di pesan dan tap checkout
13. Sistem akan menampilkan halama checkout detail yang menampilkan informasi list produk, dan form detail pesanan yang harus di isi oleh pelanggan.
Skenario Nama Pelanggan 14. Tap form nama pelanggan
dan Isi nama pelangga
Skenario Catatan 15. Tap form catatan dan Isi
nama pelangga
Skenario Nomer Meja
16. Tap dropdown nomer meja 17. Sistem akan menampilkan pilihan seluruh meja yang tersedia di kedai
Skenario Metode Pembayaran 18. Tap dropdown metode
pembayaran
19. Sistem akan menampilkan pilihan seluruh metode pembayaran yang tersedia di kedai 20. Tap pesan sekarang 21. Sistem akan menampilkan pesan “pesanan
berhasil di pesan” dan mengirimkan data ke database.
3.8. Activity Diagram
Activity Diagram adalah diagram yang memperlihatkan aliran dari suatu aktivitas lainnya dalam suatu sistem. Berikut gambar dibawah ini:
3.8.1. Activity Diagram Login Pengguna
Gambar 3.7 Activity Diagram Login Pengguna
3.8.2. Activity Diagram Kelola Produk 1. Tambah data produk
Gambar 3.8 Activity Diagram Tambah Data Produk
2. Edit data produk
Gambar 3.9 Activity Diagram update data produk 3. Hapus data produk
Gambar 3.10 Activity Diagram Hapus Data Produk
3.8.3. Activity Diagram Kelola Transaksi 1. Proses data transaksi
Gambar 3.11 Activity Diagram Proses Data Transaksi
2. Edit data transaksi
Gambar 3.12 Activity Diagram Edit Data Transaksi
3. Hapus data transaksi
Gambar 3.13 Activity Diagram Hapus Data Transaksi
3.8.4. Activity Diagram Pemesanan
Gambar 3.14 Activity Diagram Pemesanan
3.8.5. Activity Diagram Laporan
Gambar 3.15 Activity Diagram Laporan
3.9. Robustness Diagram
Gambar 3.16 Robustness Diagram
