LAPORAN ANALISIS

KEBUTUHAN
[PROJECT NAME]

[PROJECT TEAM:]

FAKULTAS SAINS DAN TEKNOLOGI

PROGRAM STUDI SISTEM INFORMASI

JAMBI

[TAHUN]
HISTORI REVISI
Versi Tanggal Penyusun/Pengubah Deskripsi Perubahan
1.2 25 Februari 2018 Tim Asdos - add activity diagram

2 Universitas Jambi
DAFTAR ISI
HISTORI REVISI 2

DAFTAR ISI 2

DAFTAR GAMBAR 5

DAFTAR TABEL 5

DAFTAR LAMPIRAN 6

KAJIAN LITERATUR 8

Proses Bisnis 8

Proses Bisnis Saat Ini 8

Perubahan Proses Bisnis 8

Sistem Informasi Sejenis 8

DEFINISI KEBUTUHAN 9

Kebutuhan Fungsional 9

Kebutuhan Non-fungsional 9

Kebutuhan Penggunaan 9

Kebutuhan Reliabilitas 9

Kebutuhan Performa 9

Kebutuhan Operasional 9

Kebutuhan Keamanan 9

Kebutuhan Kultural dan Politikal 10

Batasan Perancangan dan Pengembangan 10

MODEL FUNGSIONAL 11

Use Case Diagram 11

Use Case Specification 12

Activity Diagrams 13

MODEL STRUKTURAL 15

Class Diagram 15

MODEL BEHAVIORAL 15

Sequence Diagram 15

3 Universitas Jambi
 Behavioral State Machine 16

DAFTAR PUSTAKA 18

4 Universitas Jambi
DAFTAR GAMBAR
Gambar 1 Use Case Diagram 10

Gambar 2 Activity Diagram 13

Gambar 3 Class Diagram 14

Gambar 4 Entity Relationship Diagram 15

5 Universitas Jambi
DAFTAR TABEL
Tabel 1 Penjelasan Aktor 11

Tabel 2 Penjelasan Use Case 12

Tabel 3 CRUD Analysis 16

6 Universitas Jambi
DAFTAR LAMPIRAN
No table of figures entries found.

7 Universitas Jambi
A. KAJIAN LITERATUR
PENGEMBANGAN SISTEM INFORMASI
Pengembangan sistem informasi adalah proses pencarian solusi atau
pemecahan dari suatu masalah baik secara terstruktur, maupun berorientasi objek.
Pengembangan secara terstruktur biasanya lebih menekankan pembuatan sistem
berdasarkan proses kerja/prosedur yang telah ditetapkan. Sedangkan
pengembangan sistem berorientasi objek lebih menekankan pembuatan sistem
terhadap peranan objek yang terlibat dalam sistem tersebut.Pengembangan sistem
informasisecara terstruktur terdiri dari beberapa kegiatan / tahapan (phased), yaitu
tahap analisis sistem (analysist), konstruksi sistem (construction), pengkodean
(coding), uji sistem (testing), dan tahap pemeliharaan sistem
(maintenance).Sedangkan pengembangan sistem informasi berorientasi objek
terdiri dari tahap analysis (Inception), design (elaboration), konstruksi
(construction) dan penggantian sistem (Transition). Pada bagian ini terdapat dua isu
yang harus dianalisis dengan baik yaitu proses bisnis dan kajian sistem informasi sejenis
yang dapat dijadikan acuan untuk pengembangan sistem

1. Proses Bisnis
1.1 Proses Bisnis Saat Ini
Bagian ini menjelaskan mengenai proses bisnis yang digunakan klien pada saat ini.
Gunakan diagram swimlane untuk menggambarkan proses bisnis dan disertai paragraf
penjelasan pada masing-masing proses bisnis secara mendetail.

1.2 Perubahan Proses Bisnis

1.2.1 Teori Pendukung
Bagian ini menjelaskan mengenai teori dan tinjauan pustaka yang terkait dengan
bagian bisnis yang akan di-improve. Contoh: Untuk sistem rekrutmen, maka dapat
mengkaji human resources management terkait recruitment.

1.2.2 Proses Bisnis yang diajukan

Bagian ini menjelaskan mengenai proses bisnis yang baru yang diusulkan kepada klien.
Gunakan diagram swimlane untuk menggambarkan proses bisnis dan disertai paragraf
penjelasan pada masing-masing proses bisnis. Sertakan juga justifikasi dan referensi

8 Universitas Jambi
yang digunakan apabila Anda menggunakan best practice ataupun common practice
dari jenis proses bisnis yang dikaji. Gunakan teori dan referensi dari bagian sebelumnya.

2. Sistem Informasi Sejenis

Bagian ini menjelaskan mengenai sistem informasi sejenis yang dapat dijadikan bahan
untuk benchmarking dengan sistem informasi yang dikembangkan. Sertakan deskripsi
sistem, fitur yang disediakan, pengguna sistem dan karakteristik dari organisasi yang
menggunakan sistem tersebut. Bagian ini akan menjadi rujukan pada saat pendefinisian
functional ataupun dan non functional requirement.

9 Universitas Jambi
B. DEFINISI KEBUTUHAN
Bagian ini menjelaskan tentang requirements apa saja yang dibutuhkan oleh sistem.
Kebutuhan tersebut terbagi menjadi dua, yaitu functional requirements dan non-
functional requirements.

1. Kebutuhan Fungsional
Functional requirement merupakan kebutuhan yang terkait dengan proses-proses apa
saja yang harus dilakukan oleh sistem (secara garis besar: modular) dan informasi-
informasi apa saja yang harus dimiliki oleh sistem. Pada functional requirement ini juga
akan disebutkan fungsi-fungsi (sudah lebih spesifik dalam bentuk use case: granular)
apa saja yang harus dimiliki oleh sistem, berikut pengguna yang berhak menjalankan
fungsi tersebut, termasuk adanya kebutuhan menyesuaikan right management dari
sistem yang akan dibuat dengan policy right management di client (misalnya, client
menerapkan single sign on). Jelaskan juga tools untuk menjelaskan functional
requirement yang ada (misal: use case diagram, activity diagram). Pastikan selaras
dengan apa yang ditulis dalam laporan Rencana Proyek.

2. Kebutuhan Non-fungsional
2.1 Kebutuhan Penggunaan
Waktu yang digunakan untuk mempelajari sistem adalah 1 hari, interface dibuat
mengedepankan kemudahan sang pengguna.

2.2 Kebutuhan Reliabilitas

Bagian ini menjelaskan kebutuhan akan bahwa sistem dapat dipercaya dalam
penggunaannya. Contoh: Data yang disimpan hanya dapat diakses oleh aktor-aktor
tertentu, komponen pada sistem tidak boleh gagal melebihi 3 kali dalam sebulan.

2.3 Kebutuhan Performa

Bagian ini menjelaskan kebutuhan akan kinerja sistem dalam mengerjakan fungsinya.
Contoh: loading time kurang dari 5 milidetik, response time berkisar 1-3 milidetik.

2.4 Kebutuhan Operasional

Bagian ini menjelaskan mengenai bagaimana cara menjalankan sistem. Contoh: sistem
mampu berjalan pada Windows XP, back-up harus dilakukan setiap hari.

2.5 Kebutuhan Keamanan

Bagian ini menjelaskan kontrol keamanan yang dibutuhkan. Contoh: akses kontrol
terhadap data yang ada.

10 Universitas Jambi
2.6 Kebutuhan Kultural dan Politikal
Bagian ini menjelaskan kebutuhan budaya dan hukum yang telah ditentukan di dalam
perusahaan/organisasi klien. Contoh: sistem menggunakan bahasa Indonesia, mata
uang yang dipakai pada sistem adalah Rupiah.

2.7 Batasan Perancangan dan Pengembangan

Bagian ini menjelaskan batasan-batasan desain dalam pengembangan sistem. Contoh:
Software language yang dipakai adalah PHP dan MySQL database application yang
digunakan untuk mengakses database. Development tools yang dipakai adalah
Notepad++, Microsoft Office, Windows Operating System, dll

11 Universitas Jambi
C. MODEL FUNGSIONAL

1. Use Case Diagram

Use case diagram digunakan untuk mendeskripsikan apa yang seharusnya
dilakukan oleh sistem. Pengguna perangkat lunak ini di sebut actor. Perangkat lunak ini
ditujukan memberikan data dan laporan Pengguna sistem ini terdiri dari SuperAdmin,
Admin, User. Admin merupakan pengguna yang mengelola data pengguna, data
produk, kategori produk, berita. SuperAdmin mempunyai hak akses melakukan
pengelolaan data dan mempunyai hak akses untuk melihat laporan data

Login

Login akun

Masuk kedalam sistem

User
Super Admin
Menjalankan sistem

Log out akun

Gambar 1. Use Case Diagram Diagram

Pendaftaran

Pendaftaran akun

12 Universitas Jambi
Login Akun
 Verifikasi Akun user

Login Infaqku

Pendaftaran user

Verifikasi akun user

User Admin

Menampilkan Dashboard
User

View Dashboard Pendaftaran

dan verifikasi akun user

Log out Akun

13 Universitas Jambi
Gambar 3. Use Case Diagram Verifikasi Akun user

Laporan

Login Akun

View Dashboard Laporan

View Data Verifikasi

Admin

Log out akun

Gambar 4. Use Case Diagram Laporan data user

14 Universitas Jambi
 Add berita

Login Akun

View DashboardArtikel

Create New Artikel

Public Admin

Upload Artikel

View Artikel

Log out akun

15 Universitas Jambi
Gambar 5. Use Case Diagram Add berita

Add keuangan

Login Infaqku

View Dashboard Laporan

keuangan

Add keuangan

Admin

Log out akun

Gambar 6. Use Case Diagram Add keuangan

16 Universitas Jambi
 Transaksi

Login Akun

View Dashboard Program

infaq

Menginput nominal

Admin

User

Verifikasi Transaksi

View Dashboard Verifikasi

transaksi

Log out akun

Gambar 7. Use Case Diagram Transaksi

17 Universitas Jambi
 Data login user

Login Infaqku

View Dashboard Data

login User

Log out akun

Super Admin

Gambar 8. Use Case Diagram Data login user

18 Universitas Jambi
19 Universitas Jambi
 Data user

Login Infaqku

View Dashboard Data User

Super Admin

Mengelola data
user(menghapus,mengedit,
menambah)
Log out Akun

Gambar 9. Use Case Diagram Data user

20 Universitas Jambi
Contoh tabel peran aktor:
Tabel 1 Penjelasan Aktor
No Nama Aktor Deskripsi
.
1 User User adalah semua orang yang dapat menggunakan sistem
2 Super Admin Super Admin merupakan aktor yang bertanggung jawab
untuk menambah,merubah dan menghapus
3 Admin merupakan actor yang bertanggung jawab untuk verifikasi,
keuangan, transaksi dan mengelola data login log out
5 Pengunjung Pengunjung merupakan actor yang dapat melakukan
pendaftaran,melihat pengumanan dan berita

Contoh tabel keterkaitan aktor dan use case:

Tabel 2 Penjelasan Use Case
Kode Use Nama Use Nomor dan Nama Use Deskripsi Primary
Case Case Case Actor
UC-01 CRUD 1.Login Melakukan Super
Login autentifikasi user Admin,Ad
sebagai pengguna min,User
atau admin.
UC-02 CRUD 2.Mendaftar Melakukan Super
Pendaftaran pendaftaran Admin,Ad
sebagai calon min,User
anggota baru.
UC-03 CRUD 3.Verifikasi Melakukan Super
Verifikasi akun verifikasi akun user Admin,Ad
user sebagai calon min
anggota baru
UC-04 CRUD 4.Laporan Melihat laporan Super
Laporan data data use,Laporan Admin,Ad
user dapat dilihat oleh min
super admin dan
Admin.
UC-05 CRUD 5.Create Mengelola data Admin
Add berita berita, seperti
megubah,
menghapus dan
menambah
berita/artikel
UC-06 CRUD 6.Create Mengelola/ Admin
Add keuangan menambahkan
Data keuangan
yang hanya
dilakukan oleh
Admin

21 Universitas Jambi
 UC-07 CRUD 7.Transaksi Merupakan proses Super
Transaksi transaksi Donasi Admin,Ad
yang dilakukan oleh min.User
Donatur sesuai
dengan program
yang dipilih. Proses
ini dianggap sah
apabila terjadi
kesepakatan antara
kedua belah pihak.
UC-08 CRUD 8.Pengelolaan Merupakan proses Super
Data Login pengelolaan data Admin
User login
(username,id,last
login,level,IP addres
dan User Agent)
yang digunakan
oleh user untuk
login.
UC-09 CRUD 9.Pengelolaan Merupakan proses Super
Data User pengelolaan data Admin
User seperti
menambahkan,men
ghapus,dan
mengedit.

2. Use Case Specification

Use case description menyediakan sarana yang lebih untuk mendokumentasikan
berbagai aspek dari masing-masing use case. Use case description didasarkan pada
identifikasi kebutuhan, use case diagram, activity diagram yang mendeskripsikan proses
bisnis. Use case description berisi semua informasi yang diperlukan untuk
mendokumentasikan fungsionalitas dari proses bisni

1. Use case Login (InfaqKu)

Tabel 1.1 Tabel Login infaqKu

Use Case Name: Login ID: Tabel 1.1 Priority: Tinggi

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: User

22 Universitas Jambi
Secondary Actor: Super admin

Brief Description: Merupakan proses login InfaqKu kedalam sistem informasi infaq online
sebagai User.User adalah pengguna yang mempunyai akses untuk login dalam sistem

Relationship:
● Included use case: Memasukkan Username dan Password
● Extention use case: Proses Login Gagal
● Base use case : User membuka program kemudian masuk ke menu login

Precondition: User memasuki halaman login

Normal Flow of Events:

Aktor Sistem
1.User membuka program
2. Menampilkan halaman menu login.
3. Menginput form login (username,
password)
4. Mengecek data login dengan data di
database.
5. Menampilkan menu utama sesuai hak
akses user.

Subflows: -

Alternate Flows:
1a: Jika nama user dan kata sandi salah aplikasi akan menampilkan pesan kesalahan
2a1: Jika nama User dan kata sandi belum terdaftar dalam aplikasi maka akan muncul
pesan kesalahan
3a:jika nama user dan kata sandi benar maka user akan masuk kedala sistem

23 Universitas Jambi
 2. Use case Pendaftaran (InfaqKu)

Tabel 1.2 Tabel Pendaftaran infaqKu

Use Case Name: ID: Tabel 1.2 Priority: Tinggi

Pendaftaran

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: User

Secondary Actor: User

Brief Description: Merupakan proses pendaftaran akun InfaqKu kedalam sistem informasi
infaq online sebagai Anggota baru.

Relationship:
● Included use case: Memasukkan Data diri di form pendaftaran
● Extention use case: Pendaftaran gagal
● Base use case : User mendaftarkan akun kemudian masuk ke sistem

Precondition: User membuka website Infaqku

Normal Flow of Events:

Aktor Sistem
1.Calon anggota memilih menu daftar
2. Sistem menampilkan form pendaftaran.
3. Calon anggota mengisi form
pendaftaran.
4. Sistem memvalidasi data form
pendaftaran, kemudian menambahkan
data kedalam database.
Subflows: -

Alternate Flows:
1a: Jika field dalam form kosong maka akan muncul pesan kesalahan/gagal melakukan
pendaftaran
2a:jika field dalam form terisi dengan benar maka aplikasi menvalidasi berhasil kepada
user

24 Universitas Jambi
 3. Use case Verifikasi akun (InfaqKu)

Tabel 1.3 Tabel Verifikasi akun infaqKu

Use Case Name: Verifikasi ID: Tabel 1.3 Priority: Tinggi

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: Admin

Secondary Actor: User

Brief Description: Merupakan proses pengecekan akun setelah melakukan

pendaftaran,proses pengecekan ini dilakukan oleh admin

Relationship:
● Included use case: Admin menverifikasi akun
● Extention use case: Verifikasi akun gagal
● Base use case : Admin kemudian menverifikasi akun user

Precondition: Admin menvalidasi data user

Normal Flow of Events:

Aktor Sistem
1.Admin memilih menu Verifikasi
2. Sistem menampilkan menu Verifikasi.
3. Admin mengklik menverifikasi akun
pengguna
4.Sistem menampilkan konfirmasi,
kemudian menambahkan akun pengguna
dalam database.

Subflows: -

Alternate Flows:
1a: Jika akun pengguna berhasil diverifikasi aplikasi akan menampilkan pesan bahwa
verifikasi berhasil
2a1: Jika akun pengguna belum terdaftar dalam aplikasi maka akan muncul pesan
kesalahan verifikasi
3a: Jika berhasil akan menampilkan halaman inbox

4. Use case Laporan verifikasi (InfaqKu)

25 Universitas Jambi
 Tabel 1.4 Tabel Laporan verifikasi infaqKu

Use Case Name: Laporan ID: Tabel 1.4 Priority: Tinggi

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: SuperAdmin

Secondary Actor: Admin

Brief Description: Merupakan proses menampilkan halaman laporan verifikasi

Relationship:
● Included use case: Admin menampilkan laporan verifikasi
● Extention use case: -
● Base use case : Laporan verifikasi berhasil ditampilkan

Precondition: Admin telah melakukan login dan memilih menu laporan verifikasi

Normal Flow of Events:

Aktor Sistem
1.Admin memilih menu laporan
2. Sistem menampilkan menu laporan
verifikasi
3. Admin memilih lihat laporan verifikasi
4. Sistem akan menampilkan laporan
verifikasi

Subflows: -

Alternate Flows:
1a: Jika berhasil akan menampilkan halaman laporan

5. Use case Add berita (InfaqKu)

Tabel 1.5 Tabel Add berita infaqKu

26 Universitas Jambi
Use Case Name: Create ID: Tabel 1.5 Priority: Sedang

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: Admin

Secondary Actor: User

Brief Description: Merupakan proses pembuatan berita/artikel yang akan ditampilkan

diwebsite

Relationship:
● Included use case: Admin menulis berita/artikel
● Extention use case: -
● Base use case : Admih mengupload berita/artikel ke sistem

Precondition: Admin sudah melakukan login.

Normal Flow of Events:

Aktor Sistem
1. Admin menulis(judul,penulis) berita.
2. Sistem menampilkan form berita,
kemudian memvalidasi data berita
3. Admin memilih menu submit data
berita.
4. Sistem menampilkan konfirmasi,
kemudian menyimpannya ke dalam
database dan mengupload artikel ke
sistem.

Subflows: -

Alternate Flows:
1a: Jika field dalam form kosong maka akan muncul pesan kesalahan/gagal
melakukan penguplod an artikel
2a: Jika berhasil akan menampilkan halaman artikel pada website

6. Use case Add Keuangan (InfaqKu)

Tabel 1.6 Tabel Add Keuangan infaqKu

27 Universitas Jambi
Use Case Name: Create ID: Tabel 1.6 Priority: Tinggi

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: Admin

Secondary Actor: -

Brief Description: Merupakan proses penginputan data keuangan

Relationship:
● Included use case: Admin menginput data keuangan
● Extention use case: -
● Base use case : Data keuangan berhasil diinputkan

Precondition: Admin sudah melakukan login.

Normal Flow of Events:

Aktor Sistem
1. Admin memilih menu add keuangan
2.Admin menginputkan data keuangan
3. Sistem menampilkan form penginputan,
kemudian memvalidasi data
3. Admin memilih menu submit.
4. Sistem menampilkan konfirmasi dan
dan menyimpannya ke dalam database.

Subflows: -

Alternate Flows:
1a: Jika field dalam form kosong maka akan muncul pesan kesalahan/gagal
melakukan penginputan data keuangan

2a: Jika penginputan data keuangan sesuai maka aplikasi akan menampilkan pesan
penginputan data keuangan berhasil

7. Use case Transaksi (InfaqKu)

Tabel 1.7 Tabel Transaksi infaqKu

Use Case Name: Transaksi ID: Tabel 1.7 Priority: Tinggi

28 Universitas Jambi
Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: User

Secondary Actor: Admin

Brief Description: Merupakan proses pembayaran donasi yang dilakukan oleh

User(pengguna) dan aplikasi

Relationship:
● Included use case: User memasukan nominal donasi
● Extention use case: Pembayaran gagal
● Base use case : Pembayaran sesuai nominal berhasil

Precondition: User telah melakukan login dan memilih menu pembayaran donasi

Normal Flow of Events:

Aktor Sistem
1. user membuka aplikasi
2. Tampil halaman utama aplikasi
3. Pilih menu masuk
4. Tampil halaman masuk
5. Input jumlah donasi
6. Klik tombol submit 7. Menerima inputan user
8. Menyimpan data donasi ke dalam
database
9. Tampil data donasi

Subflows: -

Alternate Flows:
1a: Jika field dalam form kosong maka aplikasi akan menampilkan pesan kesalahan
2a1: jika uang pembayaran actor tidak mencukupin maka aplikasi akan menampilkan
pesan kesalahan

8. Use case Data login (InfaqKu)

Tabel 1.8 Tabel Data login infaqKu

29 Universitas Jambi
Use Case Name: ID: Tabel 1.8 Priority: Tinggi
Pengelolaan

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya
akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: Super admin

Secondary Actor: -

Brief Description: Merupakan proses menampilkan pengelolaan data login yang hanya
bisa dilakukan oleh super admin

Relationship:
● Included use case: Super admin menampilkan data login
● Extention use case: -
● Base use case : data login berhasil ditampilkan

Precondition: Super admin telah melakukan login dan memilih menu data login

Normal Flow of Events:

Aktor Sistem
1. Super admin memilih menu data login
2. Sistem menampilkan menu data login
3.Sistem menampilkan data login (ID,Last
login,Username,Level,IP Addres,User-
Agent)

Subflows: -

Alternate Flows:
1a: Jika berhasil akan menampilkan halaman menu data login

9. Use case Data user (InfaqKu)

Tabel 1.9 Tabel Data user infaqKu

Use Case Name: ID: Tabel 1.9 Priority: Tinggi

Pengelolaan

Author: [anggota kelompok yang menuliskan spesifikasi dari use case ini, yang nantinya

30 Universitas Jambi
 akan bertanggung jawab terhadap use case ini sampai tahapan desain dan implementasi]

Primary Actor: Super admin

Secondary Actor: -

Brief Description: Merupakan proses menampilkan pengelolaan data user yang hanya
bisa dilakukan oleh super admin

Relationship:
● Included use case: Super admin menampilkan data user
● Extention use case: -
● Base use case : data user berhasil ditampilkan

Precondition: Super admin telah melakukan login dan memilih menu data user

Normal Flow of Events:

Aktor Sistem
1. Super admin memilih menu data user
2. Sistem menampilkan menu data user
3.Super admin memilih menu Edit data
User.
4. Sistem menampilkan form edit data
user, kemudian memvalidasi data dan
menyimpannya ke dalam database.
3.Super admin memilih menu Delete data
User.
4. Sistem melakukan delete pada data
user, kemudian memvalidasi data dan
menyimpannya ke dalam database.

Subflows: -

Alternate Flows:
1a: Jika field dalam form kosong maka akan terjadi eror/gagal dalam pengeditan dan
delete
2a: Jika pengeditan dan delete berhasil maka aplikasi akan menvalidasi berhasil

3. Activity Diagrams
Pada sistem ini, activity diagram berfungsi untuk mendeskripsikan suatu alur proses
aktivitas yang terjadi, mulai dari awal sampai akhir. Masing-masing aktivitas yang

31 Universitas Jambi
terjadi akan dijelaskan sebagai berikut.

3.1. Activity Diagram untuk Login <Login>

Input Username dan

Password

Klik Cek Username

Login dan password

validasi
[Gagal login] Cek Username
dan password
[Berhasil login]

Menampilkan
Menu utama

Gambar 1. Activity Diagram Login

Aktifitas ini dilakukan oleh Admin, DKM 1, DKM 2, dan Pengguna yaitu dengan
memasukkan username dan password. Kemudian sistem akan melakukan validasi,
jika salah memasukkan username dan password maka sistem akan menampilkan
pesan kesalahan sedangkan jika benar memasukkan username dan password maka
sistem akan menampilkan menu utama sesuai hak aksesnya masing-masing.

3.2. Activity Diagram untuk Mengelola data pengguna <Mengelola Data>

32 Universitas Jambi
 Memilih menu input Menampilkan form
data pengguna input pengguna

Menginput data
pengguna

validasi [Tidak valid]

Tampilan pesan
Klik Login
kesalahan
[valid]

Simpan ke
dalam database

Klik icon
hapus data
Menampilkan
daftar pengguna
Klik icon
ubah data

Menampilkan form
ubah data pengguna
Mengubah data
pengguna

validasi [Tidak valid]

Tampil pesan
Klik Ubah kesalahan

[valid]

Simpan kedalam
database

Menampilkan detail
data pengguna

Klik hapus

Data terhapus dari

database

Gambar 2. Activity Diagram Mengelola data pengguna

Aktifitas ini dilakukan oleh Admin yang akan mendata data

pengguna. Dimulai dengan Admin memilih menu input data pengguna
kemudian sistem akan menampilkan form input dan Admin menginput data
pengguna. Kemudian sistem melakukan validasi, jika data yang
dimasukkan tidak valid maka sistem akan menampilkan pesan kesalahan
sedangkan jika data yang dimasukkan valid maka data akan tersimpan ke
dalam database dan sistem akan menampilkan daftar pengguna. Jika data
pengguna ingin diubah maka Admin mengklik icon ubah data dan sistem
akan menampilkan form ubah data kemudian Admin mengubah data
pengguna dan apabila data valid maka data akan tersimpan. Serta jika data
pengguna ingin dihapus maka Admin mengklik icon hapus data dan data
pengguna akan terhapus dari database.

33 Universitas Jambi
3.3. Activity Diagram untuk Mengelola data donatur <Mengelola Data>

Gambar 3. Activity Diagram Mengelola data donatur

Aktifitas ini dilakukan oleh DKM yang akan mendata donatur yang ingin
memberikan donasi. Dimulai dengan DKM memilih menu input data
donatur kemudian sistem akan menampilkan form input dan DKM
menginput data donatur. Kemudian sistem melakukan validasi, jika data
yang dimasukkan tidak valid maka sistem akan menampilkan pesan
kesalahan sedangkan jika data yang dimasukkan valid maka data akan
tersimpan ke dalam database dan sistem akan menampilkan daftar donatur.
Jika data donatur ingin diubah maka DKM mengklik icon ubah data dan
sistem akan menampilkan form ubah data kemudian DKM mengubah data

34 Universitas Jambi
donatur dan apabila data valid maka data akan tersimpan. Serta jika data
donatur ingin dihapus maka DKM mengklik icon hapus data dan data
donatur akan terhapus dari database.

3.4. Activity Diagram untuk Menginput data donasi <Input data>

Memilih menu input Menampilkan

data donatur laporan data
donatur

Klik icon
input donasi

Menampilkan
form input donasi

Menginput data
donasi

validasi [Tidak valid] Tampilkan

Klik simpan
pesan kesalahan
[valid]

Tampilkan
pesan kesalahan

Gambar 4. Activity Diagram Menginput data donasi

Aktifitas ini dilakukan oleh DKM untuk menginput donasi dari donatur.
DKM memilih menu daftar donatur dan sistem akan menampilkan laporan
data donatur kemudian DKM memilih nama donatur yang memberikan
donasi dan mengklik icon input donasi. Kemudian sistem menampilkan
form input donasi dan DKM menginput data donasi. Sistem melakukan
validasi, jika data yang dimasukkan valid maka data tersimpan ke dalam
database sedangkan jika data tidak valid maka sistem menampilkan pesan
kesalahan.

35 Universitas Jambi
3.5. Activity Diagram untuk Mencetak bukti donasi <Cetak>

Menginput
data donasi

Klik Menampilkan
Simpan bukti donasi

Klik cetak

Cetak bukti
donasi

Gambar 5. Activity Diagram Mencetak bukti donasi

Aktifitas ini dilakukan oleh DKM ataupun pengguna yang akan mencetak
bukti donasi. Setelah sebelumnya data donasi sudah di input ke dalam
sistem kemudian sistem menampilkan bukti donasi kemudian DKM
ataupun pengguna mengklik button cetak dan sistem akan mencetak bukti
donasi tersebut.

36 Universitas Jambi
3.6. Activity Diagram untuk Verifikasii <Verifikasi>

Memilih menu Menampilkan

daftar verifikasi daftar verifikasi

Pilih id donasi

Menampilkan data
yang akan diverifikasi

Melakukan
Verifikasi

Klik Simpan ke dalam

submit database

Gambar 6. Activity Diagram Verifikasi

Aktifitas ini dilakukan oleh Admin yang akan melakukan verifikasi data
donasi. Dimulai dengan Admin memilih menu daftar verifikasi kemudian
sistem akan menampilkan daftar verifikasi. Admin memilih id donasi yang
akan di verifikasi kemudian sistem menampilkan data donasi yang akan di
verifikasi. Admin melakukan verifikasi kemudian mengklik submit dan data
akan tersimpan ke dalam database.

37 Universitas Jambi
3.7. Activity Diagram untuk Melihat Laporan History donasi pribadi <View Laporant>

Memilih menu Menampilkan laporan

laporan donasi donasi pribadi

Klik download
laporan

Mendownload laporan

Gambar 7. Activity Diagram Melihat Laporan History donasi pribadi

Aktifitas ini dilakukan oleh Pengguna yang ingin melihat laporan donasi
yang telah dilakukannya. Dimulai dengan pengguna login terlebih dahulu.
Kemudian Donatur Tetap memilih menu laporan donasi dan sistem akan
menampilkan laporan donasi pribadinya. Donatur Tetap mengklik button
download laporan kemudian sistem akan mendownload laporan donasi
tersebut.

38 Universitas Jambi
3.8. Activity Diagram untuk Melihar laporan data donaturi <View Laporani>

Memilih Menu laporan

data donatur

Grafik Menampilkan form

Tabel
input tanggal

Menginput
tanggal

[Tidak valid]
Klik
validasi Tampil pesan
submit kesalahan
[valid]

Klik download Menampilkan laporan

laporan data donator bentuk label

Mendownload
Laporan

Melampirkan
form input
tanggal

Menginput
tanggal

validasi [Tidak valid]

Tampil pesan
Klik submit kesalahan
[valid]

Menampilkan
laporan data
donator bentuk
grafik

Gambar 8. Activity Diagram Melihat history laporan donasi pribadi

Aktifitas ini dilakukan oleh Admin dan DKM untuk view laporan data
donatur. Aktifitas ini dimulai dengan User memilih menu laporan data
donatur, jika ingin melihat laporan dalam bentuk tabel maka memilih menu
table kemudian sistem akan menampilkan form input tanggal dan sistem
akan menampilkan laporan dalam bentuk tabel berdasarkan tanggal
tersebut. Untuk mendownload laporan maka User mengklik button
download. Sedangkan jika ingin melihat laporan dalam bentuk grafik maka
memilih menu grafik kemudian sistem akan menampilkan form input

39 Universitas Jambi
tanggal dan sistem akan menampilkan laporan dalam bentuk grafik
berdasarkan tanggal tersebut.

3.9. Activity Diagram untuk Edit Profile <Edit>

Memilih Menampilkan
menu user
form ubah profile
profile

Mengubah
data profil

[Tidak valid]
validasi
Klik ubah Tampil pesan
kesalahan
[valid]

Simpan ke dalam
database

Gambar 9. Activity Diagram Edit profile

Aktifitas ini dilakukan oleh User yang terdiri dari Pengguna, DKM yang
ingin mengubah data pribadinya. Dimulai dengan User login terlebih
dahulu. Kemudian User memilih menu user profile dan sistem
menampilkan form ubah profil. User mengubah data pribadinya dan
mengklik button ubah. Sistem melakukan validasi, jika data valid maka data
tersimpan ke dalam database, sedangkan jika data tidak valid maka akan
kembali ke form ubah profil.

40 Universitas Jambi
3.10. Activity Diagram untuk Log out <Log out>

Memilih Menampilkan
menu user
form ubah profile
profile

Mengubah
data profil

[Tidak valid]
validasi
Klik ubah Tampil pesan
kesalahan
[valid]

Simpan ke dalam
database

Gambar 10. Activity Diagram Log out

Aktifitas ini dilakukan oleh User yang terdiri dari Admin, Pengguna, DKM.
Aktifitas ini dimulai dengan User memilih menu logout kemudian sistem
akan keluar dan menampilkan halaman login.

41 Universitas Jambi
D. MODEL BEHAVIORAL

1. Sequence Diagram
Sequence Diagram merupakan salah satu dari diagram UML (Unified Modelling
Language) dan diagram ini menggambarkan mengenai hubungan/interaksi yang
dilakukan antar obyek yang ada serta komunikasi yang dilakukan antar obyek tersebut.
Melalui sequence diagram, alur interaksi dan komunikasi yang dilakukan antar obyek
dalam rancang bangun sistem informasi

1.Sequence Diagram Login

42 Universitas Jambi
2.Sequence Diagram Pendaftaran

3.Sequence Diagram Laporan

43 Universitas Jambi
4.Sequence Diagram Add berita

44 Universitas Jambi
5.Sequence Diagram add keuangan

45 Universitas Jambi
6.Sequence Diagram Transaksi

7.Sequence Diagram Login User

46 Universitas Jambi
8.Sequence Diagaram Data User

2. Behavioral State Machine

Bagian ini menggambarkan dan menjelaskan communication diagram dari masing-
masing kebutuhan fungsional system informasi yang dibangun. Buatlah behavioral state
machine diagram untuk memodelkan behavior/methode (lifecycle) sebuah kelas atau
object yang kompleks.

47 Universitas Jambi
Gambar 3. Behavioral State Machine

48 Universitas Jambi
DAFTAR PUSTAKA
Saya, N. (2016). Judul Bab. Dalam Judul Buku (hal. 1-10). Gramed.

49 Universitas Jambi