Spesifikasi Perangkat Lunak

for

E-Tourism Application
Prepared by:
Amanda Daenara 19051214107
Putri Febriana S. 19051214070
Arifah Mutia Andini 19051214100

S1 SISTEM INFORMASI

1 DESEMBER 2020
DAFTAR ISI

1. Pendahuluan.............................................................................................................................
1.1 Tujuan....................................................................................................................................2
1.2 Lingkup Masalah...................................................................................................................2
1.3 Definisi dan Istilah.................................................................................................................2
1.4 Aturan Penamaan dan Penomoran.........................................................................................2
1.5 Referensi................................................................................................................................3
1.6 Ikhtisar Dokumen..................................................................................................................3
2. Deskripsi Umum Perangkat Lunak.......................................................................................
2.1 Deskripsi Umum Sistem........................................................................................................4
2.2 Fungsi Produk........................................................................................................................4
2.3 Karakteristik Pengguna..........................................................................................................4
2.4 Batasan..................................................................................................................................5
2.5 Lingkungan Operasi...............................................................................................................5
3. Deskripsi Umum Kebutuhan..................................................................................................
3.1 Kebutuhan antarmuka eksternal.............................................................................................6
3.1.1 Antarmuka Pengguna.......................................................................................................6
3.1.2 Antarmuka Perangkat Keras.............................................................................................6
3.1.3 Antarmuka Perangkat Lunak............................................................................................6
3.1.4 Antarmuka Komunikasi...................................................................................................6
3.2 Deskripsi Fungsional.............................................................................................................7
3.2.1 Use Case Diagram............................................................................................................7
3.2.2 Fungsi 1: Start..................................................................................................................7
3.2.3 Fungsi 2: Daftar atau Login Pengguna.............................................................................8
3.2.4 Fungsi 3 : Search Destination.........................................................................................10
3.2.5 Fungsi 4 : Select Destination..........................................................................................12
3.1.2 Fungsi 5 : Book Ticket...................................................................................................14
3.1.2 Fungsi 6: Payment..........................................................................................................16
3.1.3 Fungsi 7 : Start...............................................................................................................18
3.1.4 Fungsi 8: Maintain tourism information.........................................................................19
3.1.5 Fungsi 9: View daily reports..........................................................................................20
3.1.6 Fungsi 10 : Payment Validation.....................................................................................21
3.2 Deskripsi Perancangan Data................................................................................................23
3.2.1 Diagram ERD E-Tourism...............................................................................................23
3.2.2 CDM E-Tourism............................................................................................................23
3.2.3 PDM E-Tourism.............................................................................................................23
3.3 Desain Tampilan Antarmuka Sistem....................................................................................24
3.3.1 UI Halaman Awal..........................................................................................................24
3.3.2 3.4.2. UI Halaman Login................................................................................................24
3.3.3 UI Halaman Sign Up......................................................................................................25
3.3.4 UI Halaman Forgot Password........................................................................................25
3.3.5 UI Halaman Reset Password..........................................................................................26
3.3.6 UI Halaman Home.........................................................................................................26
3.3.7 UI Halaman Top Visit....................................................................................................27
3.3.8 UI Halaman Promo........................................................................................................27
3.3.9 UI Halaman Nearby.......................................................................................................28
3.3.10 UI Halaman Profile........................................................................................................28
3.3.11 UI Halaman Edit Profile.................................................................................................29
3.3.12 UI Halaman Change Photo.............................................................................................29
3.3.13 UI Halaman Like............................................................................................................30
3.3.14 UI Halaman Review.......................................................................................................31
3.3.15 UI Halaman Destinasi dan Booking Ticket....................................................................31
3.3.16 UI Halaman Select Date.................................................................................................31
3.3.17 UI Halaman Checkout and Payment..............................................................................32
3.3.18 UI Halaman Ticket.........................................................................................................33
4. Kebutuhan Fungsional..........................................................................................................

2
5. Kebutuhan Non Fungsional..................................................................................................
6. Other Requirements..............................................................................................................

3
1. Pendahuluan

Dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement

Specification (SRS) untuk aplikasi E-Tourism.

1.1 Tujuan

Dokumen SKPL merupakan dokumen spesifikasi kebutuhan perangkat lunak yang akan
dikembangkan. Dokumen ini akan digunakan oleh pengembang perangkat lunak sebagai
acuan teknis pengembangan perangkat lunak pada tahap selanjutnya.

1.2 Lingkup Masalah

E-Tourism adalah aplikasi atau perangkat lunak yang dibuat bertujuan untuk memfasilitasi
pengguna/pengunjung yang hendak berwisata di Kota Batu tanpa harus melakukan
antrian panjang untuk pembelian tiket dan juga memfasilitasi pengguna/pengunjung
dalam mendapatkan informasi mengenai destinasi objek pariwisata di Kota Batu.

1.3 Definisi dan Istilah

 SKPL adalah Spesifikasi Kebutuhan Perangkat Lunak, atau dalam bahasa Inggrisnya
sering juga disebut sebagai Software Requirements Spesification (SRS), dan
merupakan spesifikasi dari perangkat lunak yang akan dikembangkan.
 ERD adalah Entity Relationship Diagram, diagram dan notasi yang digunakan untuk
merepresentasikan struktur data statis pada perangkat lunak.

1.4 Aturan Penamaan dan Penomoran

Penulisan dokumen SKPL ini menggunakan berbagai macam aturan penamaan dan
penomoran yang berbeda-beda untuk beberapa bagian tertentu. Aturan penamaan dan
penomoran yang digunakan berdasarkan hal/bagian tersebut adalah seperti yang tercantum
pada table 1 berikut.
Tabel 1 Aturan Penamaan dan Penomoran

Hal/Bagian Aturan Penomoran/Penamaan

Kebutuhan Fungsional SKPL-FXX : Menunjukkan kebutuhan fungsional ke-XX

Kebutuhan Non Fungsional SKPL-NFXX : Menunjukkan kebutuhan non fungsional ke-

XX

1.5 Referensi

Data yang digunakan sebagai referensi dalam pembuatan SKPL ini adalah sebagai berikut:

4
 http://staff.unedelja.ac.id/blog/artikel/Pengertian-Aplikasi.html
https://www.dewaweb.com/blog/pengertian-website/
https://www.kompasiana.com/meyputri/5db819bfd541df171a770632/kemajuan-
sektor-pariwisata-kota-batu

1.6 Ikhtisar Dokumen

Dokumen ini secara garis besar terdiri dari 6 bagian dengan perincian sebagai berikut:
 Pendahuluan merupakan pengantar dari dokumen SKPL ini yang berini tentang
tujuan penulisan, lingkup masalah, definisi dan istilah, aturan penamaan dan
referensi
 Deskripsi umum perangkat lunak menjelaskan tentang deskripsi umum dari aplikasi
E-Tourism yang meliputi deskripsi umum system, fungsi produk, karakteristik
pengguna, Batasan, dan lingkup operasi.
 Deskripsi Umum Kebutuhan merupakan deskripsi kebutuhan dari aplikasi E-Tourism
yang meliputi kebutuhan antarmuka eksternal, deskripsi fungsional, deskripsi
perancangan data, design tampilan antarmuka.
 Kebutuhan fungsional merupakan kebutuhan fungsional atau kebutuhan inti dari
aplikasi E-Tourism meliputi semua system dari E-Tourism dari mulai system pertama
sampai akhir.
 Kebutuhan non fungsional merupakan kebutuhan non fungsional atau kebutuhan
tambahan dari aplikasi E-Tourism.

5
2. Deskripsi Umum Perangkat Lunak
2.1 Deskripsi Umum Sistem

Aplikasi e-tourism ini merupakan trobosan dari kami untuk masyarakat dan juga menjawab
keluhan masyarakat terutama para wisatawan yang selalu mengeluhkan tentang antrean
panjang saat melakukan pembelian tiket apalagi ketika memasuki musim liburan maka
antrean pembelian tiket akan semakin panjang dan juga untuk masyarakat yang kurang
memiliki waktu luang.
Atas dasar itulah aplikasi e-tourism ini kami buat dimana para wisatawan atau pengunjung
wisata selaku pelanggan dapat melakukan pemesanan dan pembookingan tiket secara online
yang nantinya proses pemesanan serta pembayaran akan divalidasi oleh admin kebenarannya
demi tidak adanya laporan palsu/hoax, setelah laporan terbukti asli maka admin langsung
mengarahkan data tersebut ke tempat wisata yang ingin dipesan oleh pelanggan, sehingga
pelanggan akan menerima barcode tiket melalui aplikasi e-tourism yang kemudian barcode
digunakan saat pelanggan ingin mengunjungi ke tempat wisata maka barcode akan di scan di
lobi masuk oleh pegawai wisata tersebut.
Aplikasi e-tourism juga bisa melakukan pembookingan tiket untuk jumlah pengunjung wisata
yang banyak sehingga pelanggan dapat memesankan tiket untuk teman atau keluaganya
melalui satu akun saja dengan data yang tentunya valid agar dapat dilanjutkan pembookingan
tiket tersebut oleh admin.

2.2 Fungsi Produk

Perangkat Lunak e-tourism ini mempunyai beberapa fungsi utama, antara lain:
 (SKPL-F1) Halaman Awal (Tampilan awal)
 (SKPL-F2) Halaman Login dan Sign Up Pelanggan
 (SKPL-F3) Halaman Home
 (SKPL-F4) Halaman Profile Pelanggan
 (SKPL-F5) Halaman Destinasi dan Pembookingan E-ticket
 (SKPL-F6) Halaman Select Date
 (SKPL-F7) Halaman Check Out dan Payment
 (SKPL-F8) Halaman Ticket

2.3 Karakteristik Pengguna

Karakteristik pengguna dari e-tourism dijabarkan dalam tabel berikut ini.

Kategori Tugas Hak Akses ke aplikasi Kemampuan yang
Pengguna harus dimiliki
Admin  Mengechek  Mengelola  Menguasai

6
 semua data pada data sistem basis
sistem e-tourism pengguna data
 Memvalidasi data  Mengelola
laporan data wisata
 Mencari dan  Mengelola
menghubungkan data
dengan tempat pembayaran
wisata  Memvalidasi
data profile
 Menghapus
laporan palsu

Pelanggan  Memesan dan  Membuat data  Jujur

membooking tiket profile
 Memberi penilaian  Melihat daftar
 Membayar tempat wisata
 Melihat
riwayat
transaksi
.

2.4 Batasan

Pengembangan e-tourism ini memiliki keterbatasan-keterbatasan yaitu sebagai berikut :

1. E-tourism hanya dapat digunakan menggunakan akses paket data atau wifi.
2. E-tourism hanya bisa diakses menggunakan aplikasi (tidak ada web).
3. E-tourism hanya bisa digunakan di tempat-tempat wisata Kota Batu yang telah
terdaftar.
4. Keterbatasan dari sisi perangkat keras yang digunakan, contohnya kapasitas memori
yang terbatas, kapasitas storage yang terbatas, dan input hanya berupa text dan
angka, serta beberapa character.

2.5 Lingkungan Operasi

 Lingkup operasi dari e-tourism hanya pada lingkup wisata Kota Batu yang terdaftar,
diluar batas area wisata Kota Batu tidak bisa dilayani.

7
3. Deskripsi Umum Kebutuhan
3.1 Kebutuhan antarmuka eksternal
3.1.1 Antarmuka Pengguna

Perangkat lunak yang akan dikembangkan membutuhkan interaksi dengan pemakai

aplikasi perangkat lunak. Dalam melakukan interaksi dengan pemakai perangkat lunak
ini membutuhkan perangkat untuk melakukan proses transformasi input dan output dari
dan ke pemakai. Perangkat tersebut adalah sebagai berikut:
 Perangkat Jaringan
Perangkat Jaringan wifi / paket data jaringan adalah perangkat utama untuk para pengguna
agar bisa mengakses aplikasi ini. Tanpa adanya jaringan wifi atau paket data pengguna tidak
akan menggunakan aplikasi ini, perangkat ini yang nantinya akan mengirim data-data profile,
pemesanan tiket, dan lokasi wisata.

 Smartphone
Tentunya perangkat ini juga tak kalah penting karena nantinya akan digunakan oleh
pengguna untuk proses memesan, membayar atau memberikan penilaian yaitu like dan
review kepada tempat wisata yang telah dikunjungi melalui aplikasi dan juga sebagai sarana
untuk menampilkan semua antarmuka yang berada pada sistem.

 Perangkat GPS
Perangkat ini yang nantinya akan memberikan lokasi wisata yang ingin dikunjungi ataupun
wisata yang dekat dengan lokasi pengguna.

3.1.2 Antarmuka Perangkat Keras

e-tourism ini berhubungan dengan smartphone sebagai alat utama dengan sistem operasi.
Android yang nantinya akan dijalankan menggunakan aplikasi sehingga dapat
memudahkan pengguna.

3.1.3 Antarmuka Perangkat Lunak

e-tourism merupakan progam yang akan dikembangkan melalui android studio dan
sistem ini berhubungan dengan aplikasi yang memanfaatkan server , database, serta
menggunakan bahasa pemrogaman MySQL.

3.1.4 Antarmuka Komunikasi

e-tourism merupakan sistem yang berbasis Aplikasi. Server yang digunakan adalah
server local, sehingga hanya bisa diakses dengan cara terhubung dengan jaringan paket
data atau wifi.

8
3.2 Deskripsi Fungsional
3.2.1 Use Case Diagram

Gambar 1 Use Case Diagram

3.2.2 Fungsi 1: Start

3.2.2.1 Skenario Fungsi 1: Start

Kode Use Case UC-001

Nama Use Case Start
Aktor Customer
Deskripsi Customer disajikan halaman awal aplikasi.
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Customer belum masuk / log in aplikasi.
Kondisi Akhir Customer dapat mengakses aplikasi.
Alur Kejadian Normal Aktor Sistem
1.Customer membuka
aplikasi
2. Sistem menampilkan halaman
start untuk memulai.
3. Customer menekan
tombol start.
4. sistem menampilkan halaman
daftar / login.

9
3.2.2.2 Diagram aktivitas: Start

Pelanggan System

3.2.3 Fungsi 2: Daftar atau Login Pengguna

3.2.3.1 Skenario Fungsi 2: Daftar atau Login Pengguna

Kode Use Case UC-002

Nama Use Case Daftar atau Login Pengguna
Aktor Customer
Deskripsi Pengguna daftar dengan mengisi data yang nantinya akan
mengirim ke sistem dan nantinya akan diteruskan ke menu Log in
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Pengguna belom bisa masuk ke menu utama karena datanya
belom terdaftar di database
Kondisi Akhir Pengguna mempunyai akun dan bisa masuk kemenu utama
aplikasi
Alur Kejadian Normal Aktor Sistem
1. Membuka halaman utama
2. Sistem menampilkan halaman
awal
3. Pengguna masuk ke menu
login
3. Sistem menampilkan tampilan
login dan sign up
4. Penguna baru harus masuk
ke menu sign up terlebih
dahulu agar mendapatkan
akun
5. Sistem menampilkan menu sign

10
 up
6. Pengguna menggisi data
yang sudah tertera dimenu
sign up
7. Sistem menyimpan data yang
sudah diisi dan menampilkan
halaman sign up succesfully,
selanjutnya pengguna diarahkan
untuk ke halaman login
8. Pengguna langsung
mengarah ke halaman login
dan mengisi pelangganname
dan password yang tadi
sudah dibuat
9. Sistem mencocokan data yang
tadi sudah dibuat
Alur kejadian alternatif
Aktor Sistem
1. Memasukkan
pelangganname dan
password
2. Memeriksa valid tidaknya data
masukan dengan memeriksa ke
Database
3. Menampilkanpesan login tidak
valid
4. Memasukkan
pelangganname dan
password yang valid
5. Memeriksa valid tidaknya data
masukandengan memeriksa ke
Database
6. Masuk ke halaman utama
aplikasi

3.2.3.2 Diagram aktivitas: Daftar atau Login Pengguna

Pelanggan System

11
3.2.4 Fungsi 3 : Search Destination
3.2.4.1 Skenario Fungsi 3 : Search Destination

Kode Use Case UC-003

Nama Use Case Search Destination
Aktor Customer
Deskripsi Customer yang telah berhasil login akan diarahkan ke halaman
utama sehingga dapat melakukan search destination yang akan
dituju
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Customer sudah masuk ke halaman beranda dan belom melakukan
search destination
Kondisi Akhir Customer masuk ke halaman beranda dan dapat melakukan search
destination yang ingin dituju
Alur Kejadian Normal Aktor Sistem
1. Customer membuka
halaman beranda
2. Sistem menampilkan tampilan
search destination dan terdapat
rekomendasi Top visit, Promo dan
Nearby
3. Customer masuk ke menu
search destination
4. Masuk ke menu search

12
 destination
5. Customer dapat
memasukkan destination yang
ingin dicari
6. Sistem menampilkan destination
yang dicari
Alur kejadian alternatif
Aktor Sistem
1. Customer membuka
halaman beranda
2. Sistem menampilkan tampilan
search destination dan terdapat
rekomendasi Top visit, Promo dan
Nearby

3. Customer dapat
memilih menu rekomendasi
Top visit, Promo dan Nearby

4. Sistem menampilkan menu Top

visit, Promo dan Nearby yang
dipilih customer

3.1.1.1 Diagram aktivitas: Search Destination

Pelanggan System

13
3.1.2 Fungsi 4: Select Destination
3.1.2.1 Skenario Fungsi 4: Select Destination

Kode Use Case UC-004

Nama Use Case Select Destination
Aktor Customer
Deskripsi Customer yang telah berhasil login akan diarahkan ke halaman
utama sehingga dapat melakukan select destination yang akan
dituju
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Customer sudah masuk ke halaman beranda dan belom melakukan
select destination
Kondisi Akhir Customer masuk ke halaman beranda dan dapat melakukan select
destination yang ingin dituju
Alur Kejadian Normal Aktor Sistem
1. Customer membuka halaman
beranda
2. Sistem menampilkan tampilan
select destination
3. Customer dapat select
destination
4 Sistem menampilkan
destination yang dicari

14
Alur kejadian alternatif
Aktor Sistem
1. Customer membuka halaman
beranda
2. Sistem menampilkan tampilan
select destination yang
direkomendasi Top visit, Promo
dan Nearby

3. Customer dapat memilih

menu rekomendasi Top visit,
Promo dan Nearby

4. Sistem menampilkan menu Top

visit, Promo dan Nearby yang
dipilih customer

3.1.1.1 Diagram aktivitas: Select Destination

Pelanggan System

3.1.2 Fungsi 5 : Book Ticket

3.1.2.1 Skenario Fungsi 5 : Book Ticket

15
Kode Use Case UC-005
Nama Use Case Book Ticket
Aktor Customer
Deskripsi Customer yang telah memilih destination dapat melakukan booking
ticket yang diinginkan
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Customer sudah memilih destination yang diinginkan
Kondisi Akhir Customer melakukan book ticket destination yang ingin dibeli secara
online
Alur Kejadian Normal Aktor Sistem
1. Customer membuka halaman
book ticket
2. Sistem menampilkan tampilan
book ticket
3. Sistem menampilkan kalender
untuk melakukan booking ticket
dan jumlah banyaknya tiket yang
akan dibeli
4. Customer dapat memilih
tanggal booking ticket yang
diinginkan serta menambah
berapa banyak tiket yang akan
dibeli

4. Sistem menampilkan jumlah

sub total harga yang akan dibayar
customer juga menampilkan
tombol checkout.

5. Customer melakukan
pengecekan tiket yang akan
dibeli,kemudian checkout
dengan menekan tombol
checkout.
Alur kejadian alternatif
Aktor Sistem
1. Customer membuka halaman
ticket
2. Sistem menampilkan halaman
tiket.

16
 3. Customer memilih menu
wishlist.

4. Sistem menampilkan menu

wishlist customer.

5.Customer memilih destinasi

wishlist yang ingin dibeli .
6.sistem menampilkan halaman
checkout.
7. Customer melakukan
pengecekan tiket yang akan
dibeli,kemudian checkout
dengan menekan tombol
checkout.

3.1.1.1 Diagram aktivitas: Book Ticket

Pelanggan System

3.1.2 Fungsi 6: Payment

17
3.1.2.1 Skenario Fungsi 6 : Payment / Pembayaran

Kode Use Case UC-006

Nama Use Case Payment
Aktor Customer
Deskripsi Customer melakukan payment e-ticket yang ingin dibeli.
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Customer ingin melakukan pembayaran atas tiket yang dibeli.
Kondisi Akhir Customer mendapatkan e-ticket dan barcode destinasi wisata yang
dituju.
Alur Kejadian Normal Aktor Sistem
1. Customer membuka halaman
checkout.
2. Sistem menampilkan halaman
checkout dan select payment.
3. Customer memilih metode
pembayaran yang sesuai.dan
mengikuti instruksi atas metode
pembayaran yang dipilihnya.
4. Sistem menampilkan halaman
your ticket dan barcode ticket
yang dibeli.
5.Customer menekan tombol
done pada halaman your ticket.
6.sistem menampilkan halaman
booking ticket successfully.
7. Sistem menyimpan data tiket
yang sudah dibeli. Selanjutnya,
customer diarahkan halaman
beranda.
8. Customer dapat menunjukkan
barcode e-ticket yang telah dibeli.

3.1.2.2 Diagram aktivitas: Payment

Pelanggan System

18
3.1.3 Fungsi 7 : Start

3.1.3.1 Skenario Fungsi 7: Start

Kode Use Case UC-007

Nama Use Case Start
Aktor Admin
Deskripsi Admin yang bertugas sesuai dengan tugasnya
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Admin membuka web for admin e-tourism.
Kondisi Akhir Admin menuju halaman awal
Alur Kejadian Normal Aktor Sistem
1.Admin membuka aplikasi
2. Sistem menampilkan halaman
start untuk memulai.
3. Admin menekan tombol
start.for admin.
4. sistem menampilkan halaman
utama for admin.

19
3.1.3.2 Diagram aktivitas: Start

Pelanggan System

3.1.4 Fungsi 8: Maintain tourism information

3.1.4.1 Skenario Fungsi 8 : Maintain tourism information

Kode Use Case UC-008

Nama Use Case Maintain tourism information
Aktor Admin
Deskripsi Admin memberikan informasi mengenai destinasi wisata.
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Admin masuk pada web for admin.
Kondisi Akhir Admin menambahkan / mengedit informasi destinasi wisata.
Alur Kejadian Normal Aktor Sistem
1.Admin membuka web for admin.
2. Sistem menampilkan halaman
utama web for admin.
3. Admin dapat menambahkan /
mengedit informasi mengenai

20
 destinasi wisata.
4. sistem menampilkan informasi
yang telah ditambahkan oleh admin.

3.1.4.2 Diagram Aktivitas: Maintain tourism information

Pelanggan System

3.1.5 Fungsi 9: View daily reports

3.1.5.1 Skenario Fungsi 9: View daily reports

Kode Use Case UC-009

Nama Use Case View daily reports
Aktor Admin
Deskripsi Admin melihat laporan aktivitas penggunaan aplikasi.
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Admin masuk pada halaman utama web for admin.
Kondisi Akhir Admin dapat melihat laporan aktivitas penggunaan aplikasi e-tourism.

21
 Alur Kejadian Normal Aktor Sistem
1.Admin membuka halaman utama
web for admin.
2. Sistem menampilkan halaman
utama web for admin.
3. Admin memilih view daily reports
4. sistem menampilkan informasi daily
reports yang telah terdata oleh sistem.

3.1.5.2 Diagram Aktivitas: View daily reports

Pelanggan System

3.1.6 Fungsi 10 : Payment Validation

3.1.6.1 Skenario Fungsi 10: Payment Validation

Kode Use Case UC-010

Nama Use Case Payment Validation
Aktor Bank
Deskripsi Bank memproses pembayaran tiket secara otomatis.
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Customer melakukan pembayaran yang dipilih
Kondisi Akhir Bank berhasil memvalidasi dan menerima transaksi pembayaran.
Alur Kejadian Normal Aktor Sistem
1.Bank mendapatkan info
pembayaran dari customer
2. Sistem menampilkan halaman
pembayaran.

22
 3. Bank melakukan validasi data
yang tersangkut.
4. sistem memverifikasi data dan
memproses validasi, kemudian
pembayaran sukses dilakukan.

3.1.6.2 Diagram aktivitas: Payment Validation

Pelanggan System

3.2 Deskripsi Perancangan Data

3.2.1 Diagram ERD E-Tourism

23
3.2.2 CDM E-Tourism

3.2.3 PDM E-Tourism

24
3.3 Desain Tampilan Antarmuka Sistem

3.3.1 UI Halaman Awal

3.3.2 3.4.2. UI Halaman Login

25
3.3.3 UI Halaman Sign Up

3.3.4 UI Halaman Forgot Password

26
3.3.5 UI Halaman Reset Password

3.3.6 UI Halaman Home

27
3.3.7 UI Halaman Top Visit

3.3.8 UI Halaman Promo

28
3.3.9 UI Halaman Nearby

3.3.10 UI Halaman Profile

29
3.3.11 UI Halaman Edit Profile

3.3.12 UI Halaman Change Photo

30
3.3.13 UI Halaman Like

3.3.14 UI Halaman Review

31
3.3.15 UI Halaman Destinasi dan Booking Ticket

3.3.16 UI Halaman Select Date

32
3.3.17 UI Halaman Checkout and Payment

33
3.3.18 UI Halaman Ticket

4. Kebutuhan Fungsional
SKPL-Id Nama Fungsi Keterangan
SKPL-F1 Halaman Awal Merupakan tampilan awal saat
membuka aplikasi. Pelanggan diarahkan
untuk menekan tombol start untuk
memulai menggunakan aplikasi e-
tourism.
SKPL-F2 Login dan Sign Up Tahapan kedua setelah menekan
tombol start, yaitu sign up apabila
pelanggan belum mendaftar. Pelanggan
di arahkan untuk registrasi dengan
mengisi data yang dibutuhkan. Apabila
pelanggan telah terdaftar , pelanggan
dapat meneruskan login dengan cara
memasukkan email dan password yang
terdaftar.
SKPL-F3 Home Merupakan menu halaman utama pada
aplikasi “E-TOURISM” yang telah dibuat.
Dihalaman ini terdapat ucapan halo
kepada pemilik akun atau pelanggan
yaitu “Hi, Harry (contoh nama
pelanggan) Let’s start your vacation!”

34
 SKPL-F4 Profil Pelanggan Menu optional dimana pelanggan
mengisi identitas dirinya berupa nama,
jenis kelamin,email,asal kota, dan
tanggal lahir.
SKPL-F5 Destinasi dan Booking E-ticket Menampilkan informasi dari destinasi
yang ada dan menampilkan menu
pemesanan yang dibuat sesederhana
mungkin untuk memudahkan
penggunaan. Pelanggan dapat segera
memesan dengan memilih destinasi
kemudian memesan sesuai keinginan
pelanggan.
SKPL-F6 Select Date Pada halaman ini menampilkan
kalender untuk memilih waktu
pembookingan tiket destinasi yang
diinginkan.
SKPL-F7 Check Out dan Payment Menu untuk mengkonfirmasi tiket yang
dibeli kemudian masuk ke menu
pembayaran dan memilih metode
pembayaran sehingga mendapatkan
barcode yang digunakan untuk menukar
e-ticket.
SKPL-F8 Tiket Menu yang memiliki 2 tampilan, wish
list dan my ticket. Pada wish list
berfungsi untuk menampilkan pilihan
destinasi yang ingin dikunjungi,
sedangkan pada my ticket berfungsi
untuk menampilkan tiket yang telah
dibeli dan dapat ditukarkan.

5. Kebutuhan Non Fungsional

SKPL-Id Keterangan
SKPL-NF1 Hanya bisa dipakai untuk wisata kota Batu
SKPL-NF Menggunakan pelanggan login berbeda-beda pada setiap bagian
aktor seperti admin dan pelanggan
SKPL-NF Mebutuhkan akses internet dan jaringan yang stabil
SKPL-NF Biaya yang agak terlalu mahal
SKPL-NF Tidak adanya garansi yang berkala

35
6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the project,
and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations.
You may wish to build a separate glossary that spans multiple projects or the entire organization,
and just include terms specific to a single project in each SRS.>

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>

Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they can
be tracked to closure.>

36