Professional Documents
Culture Documents
Nomor
Halaman
Dokumen
SEL01-S06 1/52
REVISI Tanggal :
KE 3 15/11/2016
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
DAFTAR PERUBAHAN
Revisi Deskripsi
Bab 1
Perbaikan pada sub bab 1.2 Tujuan Penulisan Dokumen,
numbering dibuat lebih menjorok ke kanan
Bab 2
Sub bab 2.1 Deskripsi Umum Sistem ditambah gambar
arsitektur SIMDORA beserta narasi/keterangannya
Sub bab 2.2 Deskripsi Umum Perangkat Lunak ditambahkan
latar belakang masalah yang diangkat
Sub bab 2.3 Fungsi Produk/Perangkat Lunak berisi definisi
fungsi-fungsi utama perangkat lunak yang dapat digunakan
oleh pengguna untuk menyelesaikan problem domain serta
penambahan bullet
Sub bab 2.4 Karakteristik Pengguna disesuaikan dan
A ditambahkan keterangan diatas tabel dan format diatur agar
mudah diupdate di DAFTAR TABEL
Perbaikan isi pada sub bab 2.5 Batasan
Bab 3
Perbaikan pada kata yang typo
Sub bab 3.1 Identifikasi Kebutuhan PL diperbaiki dan
disesuaikan
Sub bab 3.2.1 Kebutuhan Fungsional diperbaiki dengan
menyebutkan apa saja kebutuhan fungsionalnya
Perbaikan format pada sub bab 3.2.2 Kebutuhan Non
Fungsional serta penomoran fungsi
Perubahan pada sub bab 3.4.1 Use Case Diagram dan
penjelasannya
Bab 2
Pada sub bab 2.1 Deskripsi Umum Sistem menambahkan
kalimat "Secara umum arsitektur SIMDORA ditunjukkan oleh
gambar berikut ini:"
Bab 3
Sub Bab 3.1 Identifikasi Kebutuhan PL dilakukan perubahan
B
pada fitur-fitur yang ada di tiap aktor
Perbaikan pada sub bab 3.4.1 Use Case yang banyaknya use
case sama dengan jumlah kebutuhan fungsional
Perbaikan pada sub bab 3.4.2 Use Case Scenario dimana
semua use case dibuat use case scenarionya
Perbaikan pada class diagram sub bab 3.4.4 Class Diagram
Bab 2
C Penambahan kalimat Pada tabel 3, menjelaskan karakteristik
pengguna sistem yakni kegiatan fungsional apa saja yang
i
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
Bab 3
Perbaikan pada sub bab 3.4.1 Use Case, pemberian kode
kebutuhan pada use case scenario
Bab 3
Perbaikan pada nama use case, sesuai dengan nama fungsi di
D kebutuhan fungsional
Perbaikan pada class diagram, sesuai dengan sequence
diagram
INDEX A B C D
TGL 16/10/2016 11/11/2016 15/11/2016 19/11/2016
Ditulis
Kelompok 6 Kelompok 6 Kelompok 6 Kelompok 6
Oleh
Diperiksa
Asprak Asprak Asprak Asprak
Oleh
Disetujui
Oleh
ii
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
iii
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
DAFTAR ISI
iv
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
v
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
DAFTAR TABEL
vi
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
DAFTAR DIAGRAM
vii
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : 3
DAFTAR GAMBAR
viii
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
BAB 1
PENDAHULUAN
1
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
2
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
1.6 Referensi
Dokumen-dokumen yang digunakan sebagai referensi dalam pembuatan SKPL
ini adalah sebagai berikut :
IEEE Std 830-1993, IEEE Recommended Parctice for Software Requirement
Specifications.
Nugroho, Adi.2010. Rekayasa Perangkat Lunak Berorientasi Objek dengan
Metode USDP. Yogyakarta : Penerbit Andi
Nyura, Yusni. 2010. Pembuatan Aplikasi Pembelajaran Bahasa Inggris Pada
Handphone dengan J2ME. Jurnal Teknologi : Politeknik Negeri Samarinda.
Vol 5 No. 3 September 2010
Software Engineering, Aparctitioners Approach 5th edition, Roger S
Pressman, Mc Graw Hill, 2001.
Simarmata, Janner. 2009. Rekayasa Perangkat Lunak.Yogyakarta : Penerbit
Andi
4
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
BAB 2
DESKRIPSI SISTEM
Pembeli
Database Pemilik
Server Tampilan SIMDORA Restoran
Admin
5
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
Dalam sistem informasi berbasis desktop ini, pembeli dapat melakukan proses
pemesanan menu pada restoran dengan kebijakan setiap pemesanan terdapat
poin tertentu sesuai dengan harga tiap menu yang dipesan, sehingga nantinya
pembeli dapat menukar dengan poin beramal pada suatu yayasan. Yayasan disini
merupakan yayasan yang berkerjasama dengan restoran pengguna sistem ini, dan
tiap restoran dapat bekerjasama dengan lebih dari satu yayasan sehingga
pengunjung atau pembeli pada tingkat konsumen dapat menentukan kepada
yayasan mana poin yang mereka miliki akan didonasikan.
Untuk event jika pengunjung tidak memilih yayasan tujuan penerima poin
mereka, maka sistem akan menentukan sendiri kepada yayasan mana poin ini
akan diberikan, dengan memilih yayasan mana yang memiliki poin tersedikit, atau
dengan opsi lain yakni dilakukan pemilihan secara acak yayasan mana yang akan
menerima point tersebut, evet ini akan terjadi jika terdapat banyak yayasan yang
memiliki poin sedikit.
Selain itu pembeli juga akan mendapatkan report point yang telah dikurskan
menjadi poin amal, sehingga pembeli dapat mengetahui poin merka akan di
donasikan pada yayasan yang mana, selain iru report perblan juga dapat dilihat
oleh pembeli, yang akan di infokan di restorang yang menggunakan sistem ini.
Pada sistem ini bahasa pemrograman yang digunakan adalah Java dengan basis
Object Oriented Programming (OOP) dengan dengan basis data MySQL.
6
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
7
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
2.5 Batasan
Batasan yang digunakan pada pengembangan perangkat lunak ini adalah:
System ini hanya dijalankan pada Personal Computer dengan platform
Windows.
Aplikasi ini dapat digunakan oleh pembeli, admin, dan pemilik restoran.
8
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
BAB 3
DESKRIPSI KEBUTUHAN PERANGKAT LUNAK
9
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
Kemudian pada sisi admin kami menyediakan fitur fitur yang dapat di
akses dan dikelola oleh admin itu sendiri, berikut merupakan daftar fitur
yang dapat di akses oleh admin, yakni :
1. Daftarkan Yayasan
Merupakan fitur yang admin gunakan untuk mengatur daftar yayasan yang
akan menerima donasi.
2. Daftrakan Restoran
Merupakan fitur yang digunakan untuk menambahkan atau mendaftarkan
restoran baru.
3. Hapus Yayasan
Merupakan fitur yang admin gunakan untuk menghapus yayasan yang
dapat menerima donasi.
4. Hapus Restoran
Merupakan fitur yang digunakan admin untuk menghapus restoran.
5. Perbarui Akun
Merupakan fitur untuk memperbarui akun admin
6. Keluar
Merupakan fitur untuk keluar dari sistem dari halaman admin
Dan pada sisi pembeli juga memiliki fitur fitur tesendiri yang meliputi:
1. Lihat Menu
Merupakan fitur yang dapat digunakan oleh pembeli untuk melihat menu
yang dipesan.
2. Menambah Jumlah Pesanan
Merupakan fitur yang digunakan jika pembeli ingin menambah pesanan
mereka.
3. Hapus Pesanan
Merupakan fitur yang digunakan jika pembeli ingin menghapus pesanan
yang sebelumnya sudah mereka pesan.
4. Mengurani Jumlah Pesanan
Merupakan fitur yang digunakan oleh pembeli untuk mengurangi jumlah
pesanan yang sebelumnya sudah mereka pesan.
5. Memantau Status Donasi
10
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
Merupakan fitur yang digunakan jika pembeli ingin melihat status donasi
mereka.
6. Tambah Jenis Makanan
Merupakan fitur yang digunakan jika pembeli ingin menambah makanan
yang sebelumnya belum mereka pesan.
7. Checkout
Merupakan fitur yang dapat digunakan untuk memastikan pesanan dan
pilihan yayasan yang di berikan donasi, sehingga dapat segera diproses
oleh pihak restoran.
8. Melihat Bill
Merupakan fitur yang digunakan untuk melihat detail pesanan dan poin
yang didonasikan tiap pemesan menu
11
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
13
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
14
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
15
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
16
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
17
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.2 SIMDORA_1_002
Tabel 10. Use Case Scenario Pemilik Restoran Lihat Daftar Menu
Use Case Pemilik Restoran Lihat Daftar Menu
Tujuan Memungkinkan aktor untuk melihat daftar menu
Aktor Pemilik Restoran
Pre-kondisi Menekan tombol atur menu
Main Flow 1. Pemilik restoran masuk ke halaman daftar menu
2. Pemilik restoran menentukan data yang ingin dilihat
3. Pemilik restoran, dihadapkan pada pilihan untuk
mengelola daftar menu
Alternative Flow -
Post-kondisi Sistem menampilkan jenis pengelolaan daftar menu
kepada pemilik restoran
3.4.2.3 SIMDORA_1_003
Tabel 11. Use Case Scenario Pemilik Restoran Tambah Daftar Menu
Use Case Pemilik Restoran Tambah Daftar Menu
Tujuan Memungkinkan aktor untuk menambah isi daftar menu
Aktor Pemilik Restoran
Pre-kondisi Melihat daftar menu
Main flow 1. Pemilik restoran masuk ke halaman daftar menu
2. Pemilik restoran menekan icon + atau tombol tambah
daftar menu untuk menambah isi daftar menu
3. Sistem menampilkan pop-up form untuk
mendaftarkan menu baru
18
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.4 SIMDORA_1_004
Tabel 12. Use Case Scenario Pemilik Restoran Perbarui Daftar Menu
Use Case Pemilik Restoran Perbarui Daftar Menu
Tujuan Memungkinkan aktor untuk mengubah isi daftar menu
Aktor Pemilik Restoran
Pre-kondisi Melihat daftar menu
Main flow 1. Pemilik restoran masuk ke halaman daftar menu
2. Pemilik restoran menekan icon pensil atau tombol
ubah pada salah satu item di daftar menu untuk untuk
mengubah isi daftar menu
3. Sistem menampilkan pop-up form ubah data menu
4. Pemilik restoran mengisi form data menu lalu
menekan tombol save
5. Sistem menampilkan pesan bahwa data berhasil
diubah
6. Sistem kembali ke halaman daftar menu
Alternative flow -
Post-kondisi Sistem menampilkan halaman daftar menu kepada pemilik
restoran
19
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.5 SIMDORA_1_005
Tabel 13. Use Case Scenario Pemilik Restoran Hapus Daftar Menu
3.4.2.6 SIMDORA_1_006
Tabel 14. Use Case Scenario Pemilik Restoran Perbarui Akun
Use Case Perbarui Akun
Tujuan Memungkinkan aktor untuk merubah username dan
password
Aktor Pemilik Restoran
Pre-kondisi Halaman Laporan Donasi
Main Flow 1. Pemilik restoran masuk ke menu perbarui akun
2. Sistem menampilkan form dengan tampilan data yang
lama
3. Pemilik restoran memperbarui data dengan
memasukkan data yang baru pada form
4. Pemilik restoran menekan tombol Save
5. Sistem memberikan notifikasi kepada pemilik restoran
Alternative Flow 1. Sudah terdapat username yang sama dalam database
20
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.7 SIMDORA_1_007
Tabel 15. Use Case Scenario Pemilik Restoran Keluar
Use Case Keluar
Tujuan Memungkinkan aktor untuk keluar dari sistem
Aktor Pemilik Restoran
Pre-kondisi Setelah masuk di halaman pemilik restoran
Main Flow 1. Pemilik restoran memilih menu logout (keluar sistem)
2. Sistem menampilkan halaman masuk
Alternative Flow -
Post-kondisi Pemilik restoran kembali ke halaman masuk
3.4.2.8 SIMDORA_1_008
Tabel 16. Use Case Scenario Pembeli Melihat Menu
Use Case Pembeli Melihat Menu
Tujuan Memungkinkan aktor untuk melihat menu
Aktor Pembeli
Pre-kondisi Pembeli berada di halaman utama
Main flow 1. Sistem menampilkan pop-up daftar menu
2. Pembeli memilih daftar menu
3. Sistem menampilkan menu kepada pembeli
4. Pembeli memilih menu yang diinginkan lalu menekan
tombol pesan menu
5. Sistem menampilkan pesan Pesanan diterima
6. Sistem kembali ke halaman daftar menu
Alternative flow 1. Tidak ada kesediaan menu dalam database
21
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.9 SIMDORA_1_009
Tabel 17. Use Case Scenario Pembeli Menambah Jumlah Pesanan
Use Case Pembeli Menambah Jumlah Pesanan
Tujuan Memungkinkan aktor untuk menambah jumlah pesanan
Aktor Pembeli
Pre-kondisi Pembeli sudah memesan menu
Main flow 1. Sistem menampilkan menu kepada pembeli dan
menu yang dipesan
2. Pembeli memilih menu tambahan yang diinginkan lalu
menekan tombol tambah jumlah pesanan
3. Sistem menampilkan pesan Pesanan tambahan
diterima
4. Sistem kembali ke halaman daftar menu
Alternative flow 1. Tidak ada kesediaan menu dalam database
3.4.2.10 SIMDORA_1_010
Tabel 18. Use Case Scenario Pembeli Mengurangi Jumah Pesanan
Use Case Pembeli Mengurangi Jumlahh Pesanan
Tujuan Memungkinkan aktor untuk menambah pesanan baru
Aktor Pembeli
Pre-kondisi Pembeli sudah memesan menu
22
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.11 SIMDORA_1_011
Tabel 19. Use Case Scenario Pembeli Hapus Pesanan
Use Case Pembeli Hapus Pesanan
Tujuan Memungkinkan aktor untuk menghapus pesanan
sebelumnya
Aktor Pembeli
Pre-kondisi Pembeli sudah memesan menu
Main flow 1. Sistem menampilkan halaman menu kepada pembeli
dan menu yang dipesan
2. Pembeli menghapus menu yang sudah dipilih dengan
menekan tombol hapus pesanan
3. Sistem menampilkan pesan Pesanan berhasil
dihapus
4. Sistem kembali ke halaman daftar menu
Alternative flow -
Post-kondisi Sistem kembali ke halaman daftar menu, serta
menampilkan daftar menu yang dipesan, dengan tombol
pesan menu dimatikan, dan mengaktifkan tombol tambah
pesanan, hapus pesanan, dan selesai pesan kepada
pembeli
3.4.2.12 SIMDORA_1_012
Tabel 20. Use Case Scenario Pembeli Tambah Jenis Makanan
Use Case Pembeli Tambah Jenis Makanan
Tujuan Memungkinkan aktor untuk menambah pesanan baru
23
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
Aktor Pembeli
Pre-kondisi Pembeli sudah memesan menu
Main flow 1. Sistem menampilkan menu kepada pembeli dan
menu yang dipesan
2. Pembeli memilih menu tambahan yang diinginkan lalu
menekan tombol tambah pesanan
3. Sistem menampilkan pesan Pesanan tambahan
diterima
4. Sistem kembali ke halaman daftar menu
Alternative flow 1. Tidak ada kesediaan menu dalam database
3.4.2.13 SIMDORA_1_013
Tabel 21. Use Case Scenario Pembeli Memantau Status Donasi
Use Case Pembeli Memantau Status Donasi
Tujuan Memungkinkan pembeli untuk memantau status donasi
yang sedang dalam proses
Aktor Pembeli
Pre-kondisi Masuk ke halaman detail poin donasi
Main flow 1. Sistem menampilkan halaman detail poin donasi,
dengan menu pilihan pantau status donasi, dan lihat
kurs poin donasi.
2. Pembeli menekan tombol pantau status donasi
3. Sistem menampilkan halaman status donasi, dengan
keterangan status, detail lokasi yayasan, dan kontak
yayasan yang dapat dihubungi
Alternative flow -
Post-kondisi Sistem menampilkan halaman status donasi kepada
pembeli
24
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.14 SIMDORA_1_014
Tabel 22. Use Case Scenario Pembeli Check out
Use Case Check out
Tujuan Memungkinkan aktor untuk mereset seluruh pesanan serta
total pembayaran
Aktor Pembeli
Pre-kondisi Pembeli sudah memesan menu
Main Flow 1. Pembeli memilih menu check out
2. Sistem mereset seluruh pesanan serta total
pembayaran
Alternative Flow -
Post-kondisi Sistem halaman daftar menu
3.4.2.15 SIMDORA_1_015
Tabel 23. Use Case Scenario Pembeli Bill
Use Case Bill
Tujuan Memungkinkan aktor untuk melihat total yang harus
dibayarkan
Aktor Pembeli
Pre-kondisi Pembeli sudah memesan menu
Main Flow 1. Pembeli memesan menu
2. Sistem secara otomatis menampilkan total harga dari
pesanan pembeli
Alternative Flow -
Post-kondisi Sistem menampilkan halaman daftar menu
3.4.2.16 SIMDORA_1_016
Tabel 24. Use Case Scenario Admin Data Klien
Use Case Admin Data Klien
Tujuan Memungkinkan aktor untuk memilih klien yang akan
dikelola
Aktor Admin
25
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.17 SIMDORA_1_017
Tabel 25. Use Case Scenario Admin Daftarkan Yayasan
Use Case Admin Daftarkan Yayasan
Tujuan Memungkinkan aktor untuk menambah yayasan baru ke
daftar yayasan
Aktor Admin
Pre-kondisi Masuk ke halaman utama admin
Main flow 1. Admin menekan tombol data yayasan
2. Sistem menampilkan halaman daftar yayasan
3. Admin memilih untuk menambahkan yayasan
4. Sistem menampilkan pop-up form pendaftaran
5. Admin mengisi form pendaftaran yayasan lalu
menekan tombol save
6. Sistem menampilkan pesan bahwa Data berhasil
disimpan
7. Sistem kembali ke halaman daftar yayasan kepada
admin
Alternative flow 1. Nama yayasan suadah ada dalam database
3.4.2.18 SIMDORA_1_018
Tabel 26. Use Case Scenario Admin Hapus Yayasan
Use Case Admin Hapus Yayasan
26
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.19 SIMDORA_1_019
Tabel 27. Use Case Scenario Admin Daftarkan Restoran
Use Case Admin Daftarkan Restoran
Tujuan Memungkinkan aktor untuk menambah restoran baru ke
daftar restoran
Aktor Admin
Pre-kondisi Masuk ke halaman utama admin
Main flow 1. Admin menekan tombol data restoran
2. Sistem menampilkan halaman daftar restoran
3. Admin memilih untuk menambahkan restoran
4. Sistem menampilkan pop-up form pendaftaran
5. Admin mengisi form pendaftaran restoran lalu
menekan tombol save
6. Sistem menampilkan pesan bahwa Data berhasil
disimpan
7. Sistem kembali ke halaman daftar restoran kepada
admin
Alternative flow 1. Nama restoran suadah ada dalam database
3.4.2.20 SIMDORA_1_020
Tabel 28. Use Case Scenario Admin Hapus Restoran
Use Case Admin Hapus Restoran
Tujuan Memungkinkan aktor untuk menghapus restoran yang ada
pada daftar restoran
Aktor Admin
Pre-kondisi Masuk ke halaman daftar restoran
Main flow 1. Sistem menampilkan halaman daftar restoran
2. Admin memilih nama restoran yang tersedia untuk
dihapus lalu menekan tombol hapus
3. Sistem menampilkan pesan bahwa Data berhasil
dihapus
4. Sistem kembali ke halaman daftar restoran kepada
admin
Alternative flow -
Post-kondisi Sistem kembali ke halaman daftar restoran
3.4.2.21 SIMDORA_1_021
Tabel 29. Use Case Scenario Admin Perbarui Akun
Use Case Perbarui Akun
Tujuan Memungkinkan aktor untuk merunah username dan
password
Aktor Admin
Pre-kondisi Halaman Laporan Donasi
Main Flow 1. Admin masuk ke menu perbarui akun
2. Sistem menampilkan form dengan tampilan data yang
lama
3. Admin memperbarui data dengan memasukkan data
yang baru pada form
4. Admin menekan tombol Save
5. Sistem memberikan notifikasi kepada pemilik restoran
28
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
3.4.2.22 SIMDORA_1_022
Tabel 30. Use Case Scenario Admin Keluar
Use Case Keluar
Tujuan Memungkinkan aktor untuk keluar dari sistem
Aktor Admin
Pre-kondisi Setelah masuk di halaman admin
Main Flow 1. Admin memilih menu logout (keluar sistem)
2. Sistem menampilkan halaman masuk
Alternative Flow -
Post-kondisi Pemilik restoran kembali ke halaman masuk
29
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
30
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
31
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
32
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
6. Perbarui Akun
7. Keluar
33
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
8. Lihat Menu
34
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
35
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
36
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
37
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
38
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
15. Checkout
39
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
40
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
41
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
42
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
43
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
22. Keluar
44
SPESIFIKASI KEBUTUHAN Nomor Dokumen
PERANGKAT LUNAK Revisi : x
45