(ACC) SKPL - SIMDORA Kel.6 (Perbaikan Konsistensi)

REKAYASA PERANGKAT LUNAK | KELAS INFORMATIKA-F
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
SISTEM INFORMASI MANAJEMEN

DONASI DI RESTORAN (SIMDORA)
BERBASIS DEKSTOP
Kelompok 6
M. Birky Auliya Akbar 165150209111008
Dian Pratama 165150209111006
Defanto Hanif Yoranda 145150200111139
Yoshua Aditya Kurnia 145150201111044
Ika Oktaviandita 135150201111006
Asisten : Alfiani Fitri

Winda Cahyaningrum
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
dapat dilakukan oleh pengguna, berikut merupakan tabel

karakteristik pengguna tersebut:
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
DAFTAR HALAMAN PERUBAHAN
Halaman Revisi Halaman Revisi

1 Perbaikan numberingnya 13 Perbaikan pada use
dibuat agak menjorok ke case dan penjelasannya
kanan (segaris dengan Banyaknya use case
paragraph awal) sama dengan jumlah
4 Penambahan arsitektur kebutuhan fungsional
SIMDORA beserta Semua use case dibuat
15 use case scenarionya
narasi/keterangannya
Menambahkan kalimat Menambahkan kalimat
"Secara umum Arsitektur Pada tabel 3,
SIMDORA ditunjukkan menjelaskan
oleh Gambar berikut ini:" karakteristik pengguna
Penambahan latar sistem yakni kegiatan
5 fungsional apa saja yang
belakang masalah yang
dapat dilakukan oleh
diangkat
pengguna, berikut
Perbaikan definisi fungsi- merupakan tabel
fungsi utama perangkat karakteristik pengguna
lunak yang dapat tersebut:
digunakan oleh pengguna Penyesuaian nama use
untuk menyelesaikan 23 case dengan nama
problem domain serta fungsi di kebutuhan
penambahan bullet fungsional
Penambahan keterangan Pemberian kode
6
diatas tabel. Serta kebutuhan pada use
penjelasan tabel dibawah case scenario
34
ini tabel apa dan Perbaikan pada class
perbaikan format agar diagram
51
mudah diupdate di Perbaikan class
DAFTAR TABEL diagram, sesuai dengan
Perbaikan pengguna yang sequence diagram
7
dapat menggunakan
aplikasi ini
8-10 Perbaikan pada kata yang
typo serta perbaikan
pada penjelasan fitur-
fitur yang ada
9 Perubahan pada fitur-
fitur yang ada di tiap
aktor
10-11 Perbaikan kebutuhan
fungsional dengan
menyebutkan apa saja
kebutuhan fungsionalnya
iii
DAFTAR ISI
DAFTAR PERUBAHAN ................................................................................................i

DAFTAR HALAMAN PERUBAHAN ............................................................................ iii
DAFTAR ISI ............................................................................................................... iv
DAFTAR TABEL ......................................................................................................... vi
DAFTAR DIAGRAM.................................................................................................. vii
DAFTAR GAMBAR .................................................................................................. viii
BAB 1 PENDAHULUAN............................................................................................. 1
1.1 Deskripsi Umum Dokumen .................................................................... 1
1.2 Tujuan Penulisan Dokumen ................................................................... 1
1.3 Lingkup Masalah .................................................................................... 1
1.4 Definisi, Istilah, dan Singkatan ............................................................... 2
1.5 Aturan Penomoran ................................................................................ 3
1.6 Referensi ................................................................................................ 4
BAB 2 DESKRIPSI SISTEM ......................................................................................... 5
2.1 Deskripsi Umum Sistem ......................................................................... 5
2.2 Deskripsi Umum Perangkat Lunak ......................................................... 5
2.3 Fungsi Produk/Perangkat Lunak ............................................................ 6
2.4 Karakteristik Pengguna .......................................................................... 7
2.5 Batasan................................................................................................... 8
2.6 Lingkungan Operasi ............................................................................... 8
BAB 3 DESKRIPSI KEBUTUHAN PERANGKAT LUNAK ............................................... 9
3.1 Identifikasi Kebutuhan PL ...................................................................... 9
3.2 Kebutuhan Fungsional dan Non Fungsional ........................................ 12
3.2.1 Kebutuhan Fungsional................................................................. 12
3.2.2 Kebutuhan Non Fungsional ......................................................... 14
3.3 Kebutuhan Antarmuka Eksternal ......................................................... 14
3.3.1 Antarmuka Pengguna .................................................................. 14
3.3.2 Antarmuka Perangkat Keras ....................................................... 15
3.3.3 Antarmuka Perangkat Lunak ....................................................... 15
3.3.4 Antarmuka Komunikasi ............................................................... 15
iv
3.4 Pemodelan Kebutuhan ........................................................................ 16

3.4.1 Use Case ...................................................................................... 16
3.4.2 Use Case Scenario ....................................................................... 17
3.4.3 Sequence Diagram ...................................................................... 30
3.4.4 Class Diagram .............................................................................. 45
v
DAFTAR TABEL
Tabel 1. Definisi Istilah dan Singkatan .................................................................... 2

Tabel 2. Aturan Penomoran .................................................................................... 3
Tabel 3. Tabel Karakteristik Pengguna .................................................................... 7
Tabel 4. Tabel Kebutuhan Fungsional Pengelola .................................................. 12
Tabel 5. Tabel Kebutuhan Fungsional Pemilik Restoran ....................................... 12
Tabel 6. Tabel Kebutuhan Fungsional Pembeli ..................................................... 12
Tabel 7. Tabel Kebutuhan Admin .......................................................................... 13
Tabel 8. Tabel Kebutuhan Non Fungsional ........................................................... 14
Tabel 9. Use Case Scenario Pengelola Masuk ....................................................... 17
Tabel 10. Use Case Scenario Pemilik Restoran Lihat Daftar Menu ....................... 18
Tabel 11. Use Case Scenario Pemilik Restoran Tambah Daftar Menu ................. 18
Tabel 12. Use Case Scenario Pemilik Restoran Perbarui Daftar Menu ................. 19
Tabel 13. Use Case Scenario Pemilik Restoran Hapus Daftar Menu..................... 20
Tabel 14. Use Case Scenario Pemilik Restoran Perbarui Akun ............................. 20
Tabel 15. Use Case Scenario Pemilik Restoran Keluar .......................................... 21
Tabel 16. Use Case Scenario Pembeli Melihat Menu ........................................... 21
Tabel 17. Use Case Scenario Pembeli Menambah Jumlah Pesanan ..................... 22
Tabel 18. Use Case Scenario Pembeli Mengurangi Jumah Pesanan ..................... 22
Tabel 19. Use Case Scenario Pembeli Hapus Pesanan .......................................... 23
Tabel 20. Use Case Scenario Pembeli Tambah Jenis Makanan ............................ 23
Tabel 21. Use Case Scenario Pembeli Memantau Status Donasi.......................... 24
Tabel 22. Use Case Scenario Pembeli Check out .................................................. 25
Tabel 23. Use Case Scenario Pembeli Bill.............................................................. 25
Tabel 24. Use Case Scenario Admin Data Klien .................................................... 25
Tabel 25. Use Case Scenario Admin Daftarkan Yayasan ....................................... 26
Tabel 26. Use Case Scenario Admin Hapus Yayasan ............................................. 26
Tabel 27. Use Case Scenario Admin Daftarkan Restoran ..................................... 27
Tabel 28. Use Case Scenario Admin Hapus Restoran ........................................... 28
Tabel 29. Use Case Scenario Admin Perbarui Akun .............................................. 28
Tabel 30. Use Case Scenario Admin Keluar........................................................... 29
vi
DAFTAR DIAGRAM
Diagram 1. Use Case Diagram ............................................................................... 16

Diagram 2. Sequence Diagram Masuk .................................................................. 30
Diagram 3. Sequence Diagram Atur Daftar Menu ................................................ 30
Diagram 4. Sequence Diagram Tambah Daftar Menu .......................................... 31
Diagram 5. Sequence Diagram Perbarui Daftar Menu ......................................... 32
Diagram 6. Sequence Diagram Hapus Daftar Menu ............................................. 32
Diagram 7. Sequence Diagram Perbarui Akun ...................................................... 33
Diagram 10. Sequence Diagram Keluar ................................................................ 34
Diagram 9. Sequence Diagram Lihat Menu .......................................................... 34
Diagram 10. Sequence Diagram Tambah Jenis Makanan ..................................... 35
Diagram 11. Sequence Diagram Menambah Pesanan .......................................... 36
Diagram 12. Sequence Diagram Hapus Pesanan .................................................. 36
Diagram 13. Sequence Diagram Mengurangi Pesanan......................................... 37
Diagram 14. Sequence Diagram Memantau Status Donasi .................................. 38
Diagram 15. Sequence Diagram Lihat Daftar Menu .Error! Bookmark not defined.
Diagram 16. Sequence Diagram Melihat Bill ........................................................ 39
Diagram 17. Sequence Diagram Checkout............................................................ 40
Diagram 17. Sequence Diagram Data Klien .......................................................... 40
Diagram 18. Sequence Diagram Daftar Yayasan................................................... 41
Diagram 19. Sequence Diagram Hapus Yayasan ................................................... 42
Diagram 20. Sequence Diagram Daftarkan Restoran ........................................... 42
Diagram 21. Sequence Diagram Hapus Restoran ................................................. 43
Diagram 22. Sequence Diagram Perbarui Akun .................................................... 44
Diagram 23. Sequence Diagram Keluar ................................................................ 44
Diagram 24. Class Diagram Aplikasi SIMDORA ..................................................... 45
vii
DAFTAR GAMBAR
Gambar 1. Arsitektur Sistem Informasi Manajemen Donasi di Restoran .............. 5
viii
PERANGKAT LUNAK Revisi : x
BAB 1
PENDAHULUAN
1.1 Deskripsi Umum Dokumen

Dokumen SKPL ini dibagi menjadi tiga bagian utama. Bagian utama berisi
informasi umum yang terdiri dari pendahuluan, tujuan penulisan dokumen,
lingkup masalah, definisi, istilah dan akronim, aturan penomoran, referensi, dan
deskripsi umum dokumen.
Bagian kedua Berisi deskripsi umum perangkat lunak yang akan dikembangkan.
Bagian ini berisi informasi mengenai deskripsi umum sistem, fungsi produk,
karakteristik pengguna, batasan, dan lingkungan operasi pada perangkat lunak
yang akan dikembangkan.
Bagian ketiga berisi informasi mengenai deskripsi umum kebutuhan perangkat
lunak yang akan dikembangkan. Bagian ini meliputi informasi mengenai
kebutuhan antarmuka eksternal, deskripsi fungsional, identifikasi kebutuhan,
batasan perancangan dan rancangan berbagai diagram yang digunakan pada
perangkat lunak yang dibuat.
1.2 Tujuan Penulisan Dokumen

Dokumen ini berisi tentang Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau
Sofware Requirement Spesification (SRS) untuk Sistem Informasi Manajemen
Donasi di Restoran (SIMDORA) berbasis dekstop. Penulisan dokumen ini memiliki
tujuan sebagai berikut:
1. Memberikan penjelasan mengenai perangkat lunak yang akan dibangun
baik gambaran umum maupun gambaran perangkat lunak secara detail.
2. Pendokumentasian spesifikasi perangkat lunak Sistem Informasi
Manajemen Donasi di restoran yang akan dikembangkan menjadi sebuah
perangkat lunak berbasis desktop.
3. Digunakan oleh pengembang perangkat lunak sebagai acuan teknis dalam
membangun perangkat lunak Sistem Informasi Manajemen Donasi di
Restoran ke tahap selanjutnya.
1.3 Lingkup Masalah

Sistem Informasi Manajemen Donasi di Restoran (SIMDORA) berbasis dekstop
adalah perangkat lunak yang dirancang berbasis desktop. Perangkat lunak ini
digunakan untuk membantu menyalurkan donasi dari masyarakat yang membeli
menu di restoran. Dalam sistem ini terdapat 3 pengguna yaitu, Pemilik Restoran,
Admin, Pembeli. Pembeli yang membeli menu akan mendapatkan koin yang dapat
didonasikan untuk yayasan yang bekerja sama dengan restoran tersebut.
1
1.4 Definisi, Istilah, dan Singkatan

Tabel 1. Definisi Istilah dan Singkatan
Istilah dan Singkatan Uraian Penjelasan

SKPL Spesifikasi Perangkat Lunak
Merupakan dokumen hasil
analisis yang berisi spesifikasi
kebutuhan pengguna.
Aplikasi desktop Merupakan suatu aplikasi yang
mampu beroperasi secara offline,
tetapi kita harus menginstalnya
sendiri pada laptop atau
komputer.
SRS Software Requirement
Spesification
Dokumen ini sama dengan SKPL.
Admin Orang yang mengoperasikan
sistem.
Pembeli Orang yang melakukan donasi ke
yayasan.
Pemilik Restoran Orang yang dapat mengelola
menu restoran
SIMDORA Sistem Informasi Manajemen
Donasi di Restoran Berbasis
Dekstop
Sistem yang akan dibuat dan
dikembangkan.
IEEE Institute of Electrical and
Electronics Engineers
Merupakan standar internasional
untuk pengembangan dan
rancangan perangkat lunak.
Usecase Merupakan diagram yang
berfungsi untuk menunjukkan
fungsionalitas suatu sistem dan
bagaimana suatu sistem
berinteraksi dengan dunia luar.
2
Extend Relasi use case tambahan ke

sebuah use case dimana use case
yang ditambahkan dapat berdiri
sendiri walau tanpa use case
tambahan itu.
Include Merupakan Relasi use case
tambahan ke sebuah use case
dimana use case yang
ditambahkan memerlukan use
case ini untuk menjalankan
fungsinya.
Generalisasi Pengelompokan pengklasifikasi
pengklasifikasi seperti kelas
kelas, antarmuka antarmuka,
use case use case, dan
sebagainya.
Java Bahasa pemrograman
berorientasi objek yang dapat
digunakan untuk pengembangan
aplikasi mandiri, aplikasi berbasis
internet maupun intranet serta
aplikasi untuk perangkat-
perangkat cerdas yang dapat
berkomunikasi lewat
Intranet/jaringan komunikasi.
MySQL Merupkan basis data atau media
penyimpanan data masukan
yang dimasukkan pada tampilan
aplikasi.
OOP Object Oriented Programing
Jenis pemrograman dengan
metode enkapsulasi dengan
membuat kelas kelas dalam
pendefinisian suatu kasus.
1.5 Aturan Penomoran

Tabel 2. Aturan Penomoran
No. Aturan Penomoran / Penamaan Hal / Bagian

1. SIMDORA_1_XXX Kebutuhan Fungsional
2. SIMDORA_2_XXX Kebutuhan Non Fungsional
3
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
BAB 2
DESKRIPSI SISTEM
2.1 Deskripsi Umum Sistem

Sistem ini dinamakan Sistem Informasi Manajemen Donasi di Restoran, yang
dimana sistem ini akan diaplikasikan pada restoran yang bekerja sama dengan
yayasan tertentu. Sistem ini diharapkan dapat membantu serta mempermudah
pelanggan restoran ataupun pihak yayasan untuk mudah memberi donasi (bagi
pelanggan restoran) serta mempermudah pihak yayasan untuk mencari bantuan
dana. Selain itu sistem ini menyediakan fasilitas seperti dimana pelanggan dapat
mendonasikan uangnya, daftar yayasan berdasarkan jenis dan tempatnya, pesan
menu dan lain sebagainya melalui sistem ini. Rancangan tatap muka perangkat
lunak sistem menggunakan pemrograman Java dengan basis data MySQL. Sistem
dirancang dengan pendekatan Object Oriented Programming (OOP). Secara
umum Arsitektur SIMDORA ditunjukkan oleh Gambar berikut ini:
Pembeli
Database Pemilik
Server Tampilan SIMDORA Restoran
Admin
Gambar 1. Arsitektur Sistem Informasi Manajemen Donasi di Restoran
2.2 Deskripsi Umum Perangkat Lunak

Dewasa ini sering kita temui beberapa permasalahan dalam bidang sosial
ekonomi. Salah satu contoh, masyarakat agak kesulitan dalam melakukan donasi
kepada yayasan yang ada di daerahnya maupun di daerah lain. Selain itu,
meningkatnya pengunjung restoran memberikan kami ide untuk menggabungkan
dua bidang ini. Untuk itu kami ingin mengembangkan sistem informasi yang dapat
membantu menyelesaikan permasalahan tersebut. Sehingga nantinya saat
pembeli di restoran ingin melakukan donasi, mereka tidak perlu pergi ke tempat
yayasan. Mereka cukup melakukan donasi di restoran yang mereka kunjungi.
5
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.
2.3 Fungsi Produk/Perangkat Lunak

Fungsi fungsi yang dapat diakses dalam Sistem Informasi Managemen Donasi
di Restoran berbasis dekstop ini adalah sebagai berikut :
Menyediakan fitur-fitur untuk memudahkan Pemilik Restoran
menggunakan sistem SIMDORA, diantaranya:
o Menyediakan fitur Lihat Daftar Menu. Pemilik restoran juga dapat
menambah, menghapus, ataupun melihat menu di restorannya.
Menyediakan fitur-fitur yang memudahkan Pembeli untuk menggunakan
sistem SIMDORA, yaitu:
o Menyediakan fitur Melihat Menu jika pembeli ingin melihat menu
yang ada di restoran tersebut. Pembeli juga dapat menambah jenis
menu dan menambah, mengurangi, menghapus pesanan
o Menyediakan fitur Memantau Status Donasi jika pembeli ingin
mengetahui detail poin yang akan mereka donasikan serta terdapat
pilihan untuk memantau status donasi kepada yayasan mana donasi
akan diberikan, pembeli dapat melihat daftar yayasan yang akan
menerima donasi, pembeli juga dapat melihat kurs poin yang ada.
o Menyediakan fitur Checkout jika pembeli ingin mengakhiri proses
memesan menu, dimana system akan mereset tampilan layar untuk
pembeli selanjutnya
6
o Menyediakan fitur Melihat Bill supaya pembeli dapat mengetahui total

harga dari pesanan pembeli
Menyediakan fitur-fitur yang dapat memudahkan Admin dalam
menggunakan sitem SIMDORA, yaitu:
o Menyediakan fitur Data klien, dimana admin dapat mendaftarkan
yayasan dan menghapus yayasan yang akan menerima donasi, serta
menambah dan menghapus restoran/pemilik restoran yang ada pada
sistem.
2.4 Karakteristik Pengguna

Pengguna Sistem Informasi Managemen Donasi di Restoran berbasis Dekstop
(SIMDORA) adalah Pemilik Restoran, Pembeli, dan Admin. Pada tabel 3,
menejelaskan karakteristik pengguna sistem yakni kegiatan fungsional apa saja
yang dapat dilakukan oleh pengguna, berikut merupakan tabel karakteristik
pengguna tersebut :
Tabel 3. Tabel Karakteristik Pengguna
No Identifikasi Pengguna Karakteristik
1. Pemilik Restoran Masuk Ke Sistem
Memperbarui Akun
Melihat daftar menu
Menambah daftar menu
Merubah Daftar Menu
Menghapus daftar menu
Keluar Dari Sistem
2. Pembeli Tambah jenis makanan
Melihat menu
Menambah jumlah pesanan
Mengurangi jumlah pesanan
Menghapus pesanan
Checkout
Melihat Bill
Memantau status donasi
3. Admin Masuk Ke Sistem
Memperbarui Akun
Data klien
Daftarkan yayasan
Hapus yayasan
Daftarkan restoran
Hapus restoran
Keluar Dari Sistem
7
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.
2.6 Lingkungan Operasi

Aplikasi ini bisa diakses/ digunakan pada pengembangan perangkat lunak ini
adalah:
Sistem Operasi menggunakan Microsoft Windows XP(minimal)
Aplikasi ini dibangun dengan bahasa Pemrograman Java
Database yang digunakan adalah MySql.
8
BAB 3
DESKRIPSI KEBUTUHAN PERANGKAT LUNAK
3.1 Identifikasi Kebutuhan PL

Banyaknya kesadaran akan beramal dari masyarakat dari tingkat menengah
keatas sangat tinggi di Indonesia, yang dikenal sebagai masyarakat yang
dermawan, akan tetapi asumsi dari masyarakat yang mengira bahwa beramal
harus sekalian dengan jumlah nominal yang cukup tinggi membuat tingkat
beramal masyarakat menjadi rendah, selain itu diperlukan inovasi baru dalam
menampung donasi yang ingin mereka donasikan pada yayasan yang
membutuhkan.
Untuk itu kami berinisiatif untuk mengembangkan Sistem Informasi
Managemen Donasi di Restoran (SIMDORA) berbasis dekstop, yaitu suatu aplikasi
berbasis desktop yang bertujuan untuk menampung donasi dari masyarakat baik
dengan jumlah kecil ataupun besar dengan inovasi yang unik, yakni dengan
memberikan poin donasi berdasarkan menu yang mereka pesan.
Kemudian pada sistem ini kami membuat fitur fitur sebagai solusi dari
permasalahan diatas, dalam fitur yang ada terdapat satu fitur yang digeneralisasi
yakni fitur masuk yang dapat diakses oleh pengelola, pengelola sendiri disini
merupahakan hasil generalisasi dari pemilik restoran dan admin, jadi dalam fitur
ini pengelola dapat masuk pada sistem, dan sistem akan memberikan hak akses
pada masing masing user yang tergeneralisasi,
Adapun penjelasan fitur secara khusus yang dapat di akses oleh pemilik
restoran adalah:
1. Lihat Daftar Menu
Merupakan fitur yang digunakan untuk melihat daftar menu di restoran
tersebut.
2. Tambah Daftar Menu
Merupakan fitur untuk menambahkan daftar menu baru.
3. Perbarui Daftar Menu
Merupakan fitur untuk memperbarui daftar dan harga menu tersebut.
4. Hapus Daftar Menu
Merupakan fitur untuk menghapus daftar menu yang sudah ada.
5. Perbarui Akun
Merupakan fitur untuk memperbarui akun pemilik restoran
6. Keluar
Merupakan fitur untuk keluar dari sistem dari halaman pemilik restoran
9
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
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
3.2 Kebutuhan Fungsional dan Non Fungsional

3.2.1.1 Kebutuhan Fungsional
Tabel 4. Tabel Kebutuhan Fungsional Pengelola
No Kode Fungsi Nama Fungsi Deskripsi
1 SIMDORA_1_001 Masuk Sistem harus mampu
menyediakan sarana untuk
Masuk atau masuk ke sistem
dengan hak akses masing
masing.
Tabel 5. Tabel Kebutuhan Fungsional Pemilik Restoran

1 SIMDORA_1_002 Lihat Daftar Sistem harus mampu
Menu menyediakan sarana untuk
mlihat daftar menu restoran
2 SIMDORA_1_003 Tambah Daftar Sistem harus mampu
menambah menu di restoran
3 SIMDORA_1_004 Perbarui Daftar Sistem harus mampu
detail menu yang telah ada
4 SIMDORA_1_005 Hapus Daftar Sistem harus mampu
menghapus daftar menu yang
ada di restoran
5 SIMDORA_1_006 Perbarui Akun Sistem harus mampu
memperbarui data akun yang
telah tersedia
6 SIMDORA_1_007 Keluar Sitem harus mampu
keluar dari sistem
Tabel 6. Tabel Kebutuhan Fungsional Pembeli

1 SIMDORA_1_008 Melihat Menu Sistem harus mampu
menyediakan sarana melihat
menu restoran
2 SIMDORA_1_009 Menambah Sistem harus mampu
Jumlah Pesanan menyediakan sarana
menambah jumlah pesanan
pembeli
12
3 SIMDORA_1_010 Mengurangi Sistem harus mampu

Jumlah Pesanan menyediakan sarana untuk
mengurangi jumlah pesanan
pembeli
4 SIMDORA_1_011 Hapus Pesanan Sistem harus mampu
menyediakan sarana
menghapus menu yang tidak
jadi dibeli oleh pembeli
5 SIMDORA_1_012 Tambah Jenis Sistem harus mampu
Makanan menyediakan sarana
menambah jenis makanan
yang ingin dipesan pembeli
6 SIMDORA_1_013 Memantau Status Sistem harus mampu
Donasi menyediakan sarana
memantau status donasi untuk
pembeli
7 SIMDORA_1_014 Check Out Sistem harus mampu
menyediakan sarana check out
bagi pembeli yang akan
melakukan pembayaran dan
memilih yayasan
8 SIMDORA_1_015 Melihat Bill Sistem harus mampu
menyediakan sarana dapatkan
bill untuk melihat total yang
harus mereka bayar
Tabel 7. Tabel Kebutuhan Admin

1 SIMDORA_1_016 Data Klien Sistem harus mampu
menyediakan sarana
menampilkan data klien,
sehingga dapat menentukan
data yang ingin dikelola
2 SIMDORA_1_017 Daftarkan Sistem harus mampu
Yayasan menyediakan sarana
mendaftarkan yayasan baru
3 SIMDORA_1_018 Hapus Yayasan Sistem harus mampu
menyediakan sarana
menghapus yayasan yang
sudah ada
4 SIMDORA_1_019 Daftarkan Sistem harus mampu
Restoran menyediakan sarana
mendaftarkan restoran baru
13
5 SIMDORA_1_020 Hapus Restoran Sistem harus mampu

menyediakan sarana
menghapus restoran yang
sudah ada
6 SIMDORA_1_021 Perbarui Akun Sistem harus mampu
memperbarui data akun yang
telah tersedia
7 SIMDORA_1_022 Keluar Sitem harus mampu
keluar dari sistem
3.2.2 Kebutuhan Non Fungsional

Tabel 8. Tabel Kebutuhan Non Fungsional
1. SIMDORA_2_001 Availability Sistem dapat digunakan selama
jam kerja
2 SIMDORA_2_002 Security Sistem dan database dilengkapi
dengan password dengan
menggunakan enkripsi MD5
3 SIMDORA_2_003 User Friendly Sistem dirancang dengan
tampilan yang interaktif dan
mudah dipahami oleh user
3.3 Kebutuhan Antarmuka Eksternal

3.3.1 Antarmuka Pengguna
Pengguna berinteraksi dengan SIMDORA diatas sistem operasi windows
dengan basis desktop. Aplikasi ini menerima masukan dari pemakai melalui
perintah perangkat inputan sesuai katakuci atau memilih pada fungsi yang
diinginkan. Selanjutnya keluaran dari aplikasi dapat dilijhat pemakai dengan
menggunakan monitor secara langsung berdasarkan hak akses yang dimiliki.
14
3.3.2 Antarmuka Perangkat Keras

Kebutuhan perangkat keras (Hardware) minimum yang dapat digunakan oleh
SIMDORA adalah :
Dua (2) buah PC
Keyboard
Mouse
3.3.3 Antarmuka Perangkat Lunak

Sistem Informasi Manajemen Donasi di Restoran ini menggunakan bahasa
pemrograman Java. Sedangkan untuk database digunakan MySql dan webserver
Apache.
3.3.4 Antarmuka Komunikasi

Yang dibutuhkan hanya sebuah komputer server dan satu atau beberapa
komputer client yang dapat digunaka oleh admin dan pembeli, yang terhubung
dengan database MySQL.
15
3.4 Pemodelan Kebutuhan

3.4.1 Use Case
Diagram 1. Use Case Diagram
16
Penjelasan Use Case:

1. Terdapat Empat aktor yaitu pengelola, pemilik restoran, pembeli, dan
admin. Namun pengelola merupakan generalisasi dari aktor pemilik
restoran dan admin.
2. Untuk pengelola yang merupakan generalisasi memiliki use case Masuk
3. Untuk pemilik restoran, terdapat use case Lihat Daftar Menu, Tambah
Daftar Menu, Perbarui Daftar Menu, Hapus Daftar Menu, Perbarui Akun,
dan Keluar. Saat menjalankan Atur Daftar Menu terdapat extend Tambah
Daftar Menu untuk menambah suatu menu baru ke daftar, Perbarui Daftar
Menu untuk memperbarui datamenu, dan Hapus Daftar Menu untuk
menghapus suatu menu pada daftar.
4. Untuk Pembeli, terdapat use case Lihat Menu, Melihat Bill, Checkout,
Memantau Status Donasi, Menambah Jenis Pesanan, Menambah Jumlah
Pesanan, Mengurangi Jumlah Pesanan, dan Hapus Pesanan. Saat
menjalankan Melihat Menu terdapat extend Menambah Jenis pesanan
untuk melakukan pesanan, Menambah jumlah pesanan untuk menambah
jumlah salahsatu menu yang dipilih, Mengurangi jumlah pesanan untuk
mengurangi jumlah salahsatu menu yang dipilih, dan Hapus pesanan untuk
membatalkan suatu pesanan.
5. Untuk admin, terdapat use case Data Klien, Daftarkan Yayasan, Hapus
Yayasan, Daftarkan Restoran, Hapus Restoran, Perbarui Akun, dan Keluar.
Saat menjalankan Atur Daftar Yayasan akan include Melihat Daftar Yayasan
supaya admin mengetahui isi daftar yayasan, terdapat extend Daftarkan
Yayasan untuk menambah suatu yayasan ke daftar dan Hapus Yayasan
untuk menghapus suatu yayasan pada daftar.
3.4.2 Use Case Scenario

3.4.2.1 SIMDORA_1_001
Tabel 9. Use Case Scenario Pengelola Masuk
Use Case Masuk
Tujuan Memungkinkan aktor untuk masuk ke sistem
Aktor Pengelola
Pre-kondisi -
Main Flow 1. Sistem menampilkan halaman masuk (masuk ke
sistem)
2. Pemilik restoran memasukkan username dan
password
3. Pengelola menekan tombol masuk
17
Alternative Flow 1. Username dan atau password yang dimasukkan

salah (tidak terdata dalam database)
Jika username dan atau password tidak tersedia dalam
database, sistem akan menampilkan pesan error
Username dan atau password anda salah kepada pengelola
Post-kondisi Pengelola diizikan masuk ke sistem sesuai dengan hak
aksesnya
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
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
4. Pemilik restoran mengisi form menu lalu menekan

tombol save
5. Sistem menampilkan pesan bahwa data berhasil
disimpan
6. Sistem kembali ke halaman daftar menu
Alternative flow 1. Nama menu sudah ada dalam database
Jika sudah ada nama menu dalam database, sistem akan
menampilkan pesan error Menu yang ditambahkan sudah
tersedia kepada pemilik restoran
Post-kondisi Sistem menampilkan halaman daftar menu kepada pemilik
restoran
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
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
diubah
Alternative flow -
restoran
19
3.4.2.5 SIMDORA_1_005
Tabel 13. Use Case Scenario Pemilik Restoran Hapus Daftar Menu
Use Case Pemilik Restoran Hapus Daftar Menu

Tujuan Memungkinkan aktor untuk menghapus isi daftar menu
Aktor Pemilik restoran
2. Pemilik restoran menekan icon X atau tombol hapus
pada salah satu item di daftar menu untuk menghapus
isi daftar menu
dihapus
Alternative flow -
restoran
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
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
Jika ada username yang sama dalam database, sistem akan

menampilkan pesan error Username telah tersedia
kepada pemilik Restoran
Post-kondisi Sistem menampilkan halaman form perbarui akun dengan
menampilkan data yang baru
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
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
Alternative flow 1. Tidak ada kesediaan menu dalam database
Jika tidak ada kesediaan menu dalam database, sistem akan

menampilkan pesan error Menu sudah habis kepada
pembeli
21
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.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

pembeli
Post-kondisi Sistem kembali ke halaman daftar menu , serta
pembeli
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
22

menu yang dipesan
menekan tombol kurangi jumlah pesanan
3. Sistem menampilkan pesan Perubahan disimpan
Alternative flow -
pesanan, hapus pesanan, dan selesai pesan kepada pembeli
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
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
Alternative flow -
Post-kondisi Sistem kembali ke halaman daftar menu, serta
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
Aktor Pembeli
menu yang dipesan
menekan tombol tambah pesanan
3. Sistem menampilkan pesan Pesanan tambahan
diterima

pembeli
pembeli
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
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
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
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
Pre-kondisi Masuk ke sistem

Main flow 1. Sitem menampilkan halaman utama dari admin
2. Admin dapat memilih untuk mengatur data yang akan
di kelola, yakni Data Yayasan dan Data Restoran
Alternative flow -
Post-kondisi Sistem menampilkan halaman utama admin
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
Jika sudah ada nama yayasan yang sama dalam database,

sistem akan menampilkan pesan error Nama yayasan
sudah terdaftar kepada admin
Post-kondisi Sistem kembali ke halaman daftar yayasan
3.4.2.18 SIMDORA_1_018
Tabel 26. Use Case Scenario Admin Hapus Yayasan
Use Case Admin Hapus Yayasan
26
Tujuan Memungkinkan aktor untuk menghapus yayasan yang ada

pada daftar yayasan
Aktor Admin
Pre-kondisi Masuk ke halaman daftar yayasan
Main flow 1. Sistem menampilkan halaman daftar yayasan
2. Admin memilih nama yayasan yang tersedia untuk
dihapus lalu menekan tombol hapus atau ikon X
dihapus
4. Sistem menampilkan kembali halaman daftar yayasan
kepada admin
Alternative flow -
Post-kondisi Sistem kembali ke halaman daftar yayasan
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
disimpan
7. Sistem kembali ke halaman daftar restoran kepada
admin
Alternative flow 1. Nama restoran suadah ada dalam database
Jika sudah ada nama restoran yang sama dalam database,

sistem akan menampilkan pesan error nama restoran
sudah terdaftar kepada admin
27
Post-kondisi Sistem kembali ke halaman daftar restoran
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
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
Alternative Flow 1. Sudah terdapat username yang sama dalam database
Jika ada username yang sama dalam database, sistem akan

menampilkan pesan error Username telah tersedia
kepada pemilik Restoran
Post-kondisi Sistem menampilkan halaman form perbarui akun dengan
menampilkan data yang baru
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
3.4.3 Sequence Diagram

1. Masuk
Diagram 2. Sequence Diagram Masuk

Penjelasan sequence diagram Masuk :
Aktor pada sequence diagram ini adalah Pengelola, dimana
pada HalamanLogin Pengelola dapat memasukkan data berupa
username dan password, sehingga pengelola bisa masuk ke
sistem dengan status administrator.
2. Lihat Daftar Menu
Diagram 3. Sequence Diagram Atur Daftar Menu

Penjelasan sequence diagram atur daftar menu
Aktor pada sequence diagram ini adalah Pemilik Restoran,
dimana pada HalamanDaftarMenu pemilik restoran dapat
memilih fungsi menu untuk MelihatHalamanDaftarMenu yang
30
menjabarkan data terntang data menu yang ada, pada halaman

ini pemilik restoran dapat melihat berdasarkan data jenis
menu, harga, menggunakan perintah sort by atau langsung
dapat melihat berdasarkan mesin pencarian.
3. Tambah Daftar Menu
Diagram 4. Sequence Diagram Tambah Daftar Menu

Penjelasan sequence diagram tambah daftar menu
memilih fungsi menu untuk TambahDaftarMenu selanjutnya
pemilik restoran akan mendapat notifikasi apakah data
tersebut sudah ada atau data tersimpan. Jika sudah ada maka
pemilik retoran mendapat notifikasi bahwa nama yang
dimasukkan sudah ada kemudian sitem akan kembali ke
HalamanDaftarMenu, namun jika data berhasil ditambahkan
maka pemilik restoran juga tetap menerima notifikasi bahwa
data sudah berhasil ditambahkan, kemudian sitem akan
kembali ke HalamanDaftarMenu.
4. Perbarui Daftar Menu
31
Diagram 5. Sequence Diagram Perbarui Daftar Menu

Penjelasan sequence diagram perbarui daftar menu
memilih fungsi menu untuk MengelolalaDataYangDiperbarui
dengan memlih data yang ingin diperbarui, kemudian sistem
akan memunculkan popup FormUbahData, pada pada ini
pemilik restoran dapat memperbarui data, selanjutnya sistem
akan menampilkan kembali HalamanDaftarMenu.
5. Hapus Daftar Menu
Diagram 6. Sequence Diagram Hapus Daftar Menu

Penjelasan sequence diagram hapus daftar menu
memilih fungsi menu untuk
32
MenghapusMenuYangInginDihapus selanjutnya pemilik

restoran, pada halaman ini pemilik restoran dapat melihat
berdasarkan data restorannya, waktu, menggunakan perintah
sort by atau langsung dapt melihat berdasarkan mesin
pencarian.
6. Perbarui Akun
Diagram 7. Sequence Diagram Perbarui Akun

Penjelasan sequence diagram perbarui akun
dimana pada HalamanPerbaruiAkun pemilik restoran dapat
merubah data akun, baik username maupun password dengan
menginputkan username dan password yang baru, kemudian
sistem akan melakukan verifikasi terkait inputan dari user, jika
berhasil pemilik restoran akan menerima notifikasi.
7. Keluar
33
Diagram 8. Sequence Diagram Keluar

Penjelasan sequence diagram Keluar
dimana pada HalamanPemilikRestoran pemilik restoran dapat
memilih menu keluar (Logout) untuk keluar dari sistem,
kemudian pemilik restoran akan kembali kehalaman awal
masuk (login).
8. Lihat Menu
Diagram 9. Sequence Diagram Lihat Menu
34
Penjelasan sequence diagram Tambah Jenis makanan

Aktor pada sequence diagram ini adalah Pembeli, dimana
pada sequence diagram ini pembeli dapat melihat dan
memesan daftar makanan yang ada
9. Tambah Jenis Makanan
Diagram 10. Sequence Diagram Tambah Jenis Makanan

Penjelasan sequence diagram Tambah Jenis makanan
Aktor pada sequence diagram ini adalah Pembeli, dimana pada
HalamanMenu, sehingga jika pengunjung ingin memesan
makanan, pada halaman ini pembeli dapat memesan menu
makanan, dengan memilih dari daftar menu makanan, jika
makanan masih tersedia sistem akan memunculkan
pemberitahuan bahwa pesanan diterima, namun jika menu
tidak tersedia atau telah habis maka sistem akan memunculkan
pesan kepada pembeli bahwa menu sudah habis, kemudian
sistem kembali ke halaman daftar menu kepada pembeli, serta
menampilkan daftar menu yang dipesan, dengan tombol pesan
menu dimatikan, dan mengaktifkan tombol tambah pesanan,
hapus pesanan, dan selesai pesan.
10. Menambah Pesanan
35
Diagram 11. Sequence Diagram Menambah Pesanan

Penjelasan sequence diagram menambah pesanan
HalamanMenu pembeli dapat memilih fungsi menu untuk
menambah jumlah pesanan, setelah pembeli memesan menu,
kemudian sistem akan mencek menu yang dipesan apakah
masih tersedia, jika masih, maka pembeli akan menerima pesan
pesanan tambah diterima, namun jika menu tidak ada atau
habis maka sistem akan memunculkan pesan menu sudah
habiis , kemudian sistem kembali ke halaman daftar menu
kepada pembeli, serta menampilkan daftar menu yang dipesan,
dengan tombol pesan menu dimatikan, dan mengaktifkan
tombol tambah pesanan, hapus pesanan, dan selesai pesan.
11. Hapus Pesanan
Diagram 12. Sequence Diagram Hapus Pesanan
36
Penjelasan sequence diagram hapus pesanan

HalamanMenu pembeli dapat memilih fungsi menu untuk
KurangiDataMenu, yakni dengan menekan tombol silang atau
hapus menu pada daftar menu yang telah dipesan sebelumnya,
setelah berhasil sistem akan memunculkan pesan Pesanan
Berhasil Dihapus, kemudian sistem kembali ke halaman daftar
menu kepada pembeli, serta menampilkan daftar menu yang
dipesan, dengan tombol pesan menu dimatikan, dan
mengaktifkan tombol tambah pesanan, hapus pesanan, dan
selesai pesan.
12. Mengurangi Pesanan
Diagram 13. Sequence Diagram Mengurangi Pesanan

Penjelasan sequence diagram mengurangi pesanan
HalamanMenu pembeli mengurangi jumlah pesanan yang
dianggap terlalu banyak
13. Memantau Status Donasi
37
Diagram 14. Sequence Diagram Memantau Status Donasi

Penjelasan sequence diagram memantau status donasi
HalamanDetailPoinDonasi akan menampilkan halaman detail
poin donasi dengan menu pilihan untuk pantau status donasi
dan lihat kurs poin donasi, kemudian pembeli dapat memilih
fitur untuk memantau status donasi, sehingga sistem akan
menampilkan halaman status donasi, dengan status , detail
lokasi yayasan, dan kontak yaysan.
14. Melihat Bill
38
Diagram 15. Sequence Diagram Melihat Bill

Penjelasan sequence diagram Melihat Bill
Aktor pada sequence diagram ini adalah customer, dimana
pada customerGUI setiap kali customer menambah item,
harga yang tercantum pada bill akan berubah
menyesuaikan dengan total menu yang dipesan
15. Checkout
39
Diagram 16. Sequence Diagram Checkout

Penjelasan sequence diagram checkout
Aktor pada sequence diagram ini adalah customer, dimana
pada customerGUI customer menekan tombol checkout
untuk mengakhiri proses memesan pada GUI, total bill akan
disimpan di database
16. Data Klien
Diagram 17. Sequence Diagram Data Klien

Penjelasan sequence diagram Data Klien
Aktor pada sequence diagram ini adalah Admin, dimana untuk
melihat halaman data yang ingin dikelola, pada halaman admin,
admin harus masuk (Login) terlebih dahulu.
17. Daftarkan Yayasan
40
Diagram 18. Sequence Diagram Daftar Yayasan

Penjelasan sequence diagram daftarkan yayasan
Aktor pada sequence diagram ini adalah Admin, dimana pada
HalamanDaftarYaysan admin dapat memilih fitur untuk tambah
yayasan, kemudian muncul popup form untuk daftar yayasan,
jika pendaftaran berhasil maka akan terdapat notifikasi Data
Berhasil Disimpan, sedangkan jika gagal maka akan muncul
notifikasi Nama Yayasan Sudah Terdaftar. Kemudia sistem
akan kembali ke halaman daftar yayasan.
41
18. Hapus Yayasan
Diagram 19. Sequence Diagram Hapus Yayasan

Penjelasan sequence diagram hapus yayasan
HalamanDaftarYaysan admin dapat memilih fitur untuk hapus
yayasan yang sudah ada, dengan melakukan seleksi pada data
yang ingin dihapus, kemudian admin dapat memilih tombol
atau menu silang X atau hapus, kemudia sistem akan
memberikan notifokasi bahwa Data Berhasil Dihapus,
selanjutkan sistem akan kembali ke halaman daftar yayasan.
19. Daftarkan Restoran
Diagram 20. Sequence Diagram Daftarkan Restoran

Penjelasan sequence diagram daftarkan restoran
42

HalamanDaftarRestoran admin dapat memilih fitur untuk
tambah restoran, kemudian muncul popup form untuk daftar
restoran, jika pendaftaran berhasil maka akan terdapat
notifikasi Data Berhasil Disimpan, sedangkan jika gagal maka
akan muncul notifikasi Nama Restoran Sudah Terdaftar.
Kemudia sistem akan kembali ke halaman daftar restoran.
20. Hapus Restoran
Diagram 21. Sequence Diagram Hapus Restoran

Penjelasan sequence diagram hapus restoran
HalamanDaftarRestoran admin dapat memilih fitur untuk
hapus restoran yang sudah ada, dengan melakukan seleksi pada
data yang ingin dihapus, kemudian admin dapat memilih
tombol atau menu silang X atau hapus, kemudia sistem akan
memberikan notifokasi bahwa Data Berhasil Dihapus,
selanjutkan sistem akan kembali ke halaman daftar restoran.
43
21. Perbarui Akun
Diagram 22. Sequence Diagram Perbarui Akun

Penjelasan sequence diagram perbarui akun
HalamanPerbaruiAkun admin dapat merubah data akun, baik
username maupun password dengan menginputkan username
dan password yang baru, kemudian sistem akan melakukan
verifikasi terkait inputan dari user, jika berhasil admin akan
menerima notifikasi.
22. Keluar
Diagram 23. Sequence Diagram Keluar

Penjelasan sequence diagram Keluar
44

HalamanAdmin admin dapat memilih menu keluar (Logout)
untuk keluar dari sistem, kemudian admin akan kembali
kehalaman awal masuk (login).
3.4.4 Class Diagram
Diagram 24. Class Diagram Aplikasi SIMDORA
Penjelasan class diagram aplikasi SIMDORA, pada class diagram SIMDORA

merupan pengembangan dari squance diagram, namun pada diagram ini
ditunjukkan hanya alur sistemnya, pada sistem ini terdapat lima data utama, enam
kontroler sebagai pengelola dari sistem, dan hasilnya dapat ditampilkan pada
halaman penampil, pada halaman terdapat beberapa layer, yang artinya yakni alur
untuk mengakses halam tersebut harus melewati halaman halaman sebelumnya
dengan menggunakan data dan kontroler yang sama.
45

(ACC) SKPL - SIMDORA Kel.6 (Perbaikan Konsistensi)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(ACC) SKPL - SIMDORA Kel.6 (Perbaikan Konsistensi)

Uploaded by

Copyright:

Available Formats

REKAYASA PERANGKAT LUNAK | KELAS INFORMATIKA-F

SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

SISTEM INFORMASI MANAJEMEN

Asisten : Alfiani Fitri

dapat dilakukan oleh pengguna, berikut merupakan tabel

DAFTAR HALAMAN PERUBAHAN

Halaman Revisi Halaman Revisi

DAFTAR PERUBAHAN ................................................................................................i

3.4 Pemodelan Kebutuhan ........................................................................ 16

Tabel 1. Definisi Istilah dan Singkatan .................................................................... 2

Diagram 1. Use Case Diagram ............................................................................... 16

Gambar 1. Arsitektur Sistem Informasi Manajemen Donasi di Restoran .............. 5

1.1 Deskripsi Umum Dokumen

1.2 Tujuan Penulisan Dokumen

1.3 Lingkup Masalah

1.4 Definisi, Istilah, dan Singkatan

Istilah dan Singkatan Uraian Penjelasan

Extend Relasi use case tambahan ke

1.5 Aturan Penomoran

No. Aturan Penomoran / Penamaan Hal / Bagian

2.1 Deskripsi Umum Sistem

Gambar 1. Arsitektur Sistem Informasi Manajemen Donasi di Restoran

2.2 Deskripsi Umum Perangkat Lunak

2.3 Fungsi Produk/Perangkat Lunak

o Menyediakan fitur Melihat Bill supaya pembeli dapat mengetahui total

2.4 Karakteristik Pengguna

2.6 Lingkungan Operasi

3.1 Identifikasi Kebutuhan PL

3.2 Kebutuhan Fungsional dan Non Fungsional

Tabel 5. Tabel Kebutuhan Fungsional Pemilik Restoran

Tabel 6. Tabel Kebutuhan Fungsional Pembeli

3 SIMDORA_1_010 Mengurangi Sistem harus mampu

Tabel 7. Tabel Kebutuhan Admin

5 SIMDORA_1_020 Hapus Restoran Sistem harus mampu

3.2.2 Kebutuhan Non Fungsional

3.3 Kebutuhan Antarmuka Eksternal

3.3.2 Antarmuka Perangkat Keras

3.3.3 Antarmuka Perangkat Lunak

3.3.4 Antarmuka Komunikasi

3.4 Pemodelan Kebutuhan

Diagram 1. Use Case Diagram

Penjelasan Use Case:

3.4.2 Use Case Scenario

Alternative Flow 1. Username dan atau password yang dimasukkan

4. Pemilik restoran mengisi form menu lalu menekan

Use Case Pemilik Restoran Hapus Daftar Menu

Jika ada username yang sama dalam database, sistem akan

Jika tidak ada kesediaan menu dalam database, sistem akan

Post-kondisi Sistem kembali ke halaman daftar menu, serta

Jika tidak ada kesediaan menu dalam database, sistem akan

Main flow 1. Sistem menampilkan menu kepada pembeli dan

Jika tidak ada kesediaan menu dalam database, sistem akan

Pre-kondisi Masuk ke sistem

Jika sudah ada nama yayasan yang sama dalam database,

Tujuan Memungkinkan aktor untuk menghapus yayasan yang ada

Jika sudah ada nama restoran yang sama dalam database,

Post-kondisi Sistem kembali ke halaman daftar restoran

Alternative Flow 1. Sudah terdapat username yang sama dalam database

Jika ada username yang sama dalam database, sistem akan

3.4.3 Sequence Diagram

Diagram 2. Sequence Diagram Masuk

2. Lihat Daftar Menu

Diagram 3. Sequence Diagram Atur Daftar Menu