BAB III

ANALISIS KEBUTUHAN

3.1 Sejarah Singkat SMK Negeri 1 Cipunagara

Sekolah Menengah Kejuruan (SMK) Negeri 1 Cipunagara Kabupaten Subang

berdiri pada tahun 2004, yaitu melalui tahapan-tahapan perencanaan yang

didahului penjajagan, studi kelayakan dan pembuatan proposal, rapat koordinasi

gabungan, serta penerbitan Surat Keputusan Bupati Subang, dan Penugasan Kepala

Sekolah sebagai Pelaksana Harian. Selanjutnya dilakukan rapat pimpinan sekolah

dengan para guru, yang bertugas untuk mempersiapkan pendaftaran siswa baru,

yaitu pada bulan Juni 2004.

Sejak saat itu dibuat tim kecil yang menangani penerimaan siswa baru

untuk mengatur strategi dan pendekatan di berbagai sekolah SMP/MTs untuk

dapat meraih siswa. Diantaranya dengan memasang spanduk, menyebarkan brosur

ke tiap sekolah, ke desa-desa dan masyarakat di Kecamatan Cipunagara, Kecamatan

Compreng, dan Kecamatan Pagaden, tidak lupa juga menyebarkan ke wilayah

Kabupaten Indramayu (Haurgeulis) karena lokasinya dekat dengan Cipunagara.

3.1.1 Visi dan Misi SMK Negeri 1 Cipunagara

 Visi SMK Negeri 1 Cipunagara

“Terwujudnya sekolah yang Unggul Dalam Iman Dan Taqwa (IMTAQ),

Ilmu dan Pengetahuan Dan Teknologi (IPTEK), Nyaman dan Berbudaya

pada tahun 2020.”

III-27
  Misi SMK Negeri 1 Cipunagara

1. Menciptakan kehidupan sekolah yang religius.

2. Mengembangkan pembelajaran berbasis SKL, SKKNI, dan Kebutuhan

Dunia Usaha serta Dunia Industri.

3. Mengembangkan pembelajaran aktif, inovatif, kreatif, efektif dan

menyenangkan untuk mengoptimalkan potensi peserta didik.

4. Menerapkan teknologi informasi dan komunikasi sebagai pendukung

keunggulan pembalajaran.

5. Menciptakan produk kreatif berbasis bisnis dan teknologi.

6. Menciptakan lingkungan yang kondusif, bersih, indah dan hijau, serta

nyaman.

7. Mengembangkan kutur sekolah yang disiplin, fisik dan mental yang

kuat, dinamis, harmonis serta kompetitif.

3.1.2 Struktur Organisasi di SMK Negeri 1 Cipunagara

Struktur organisasi di SMKN 1 Cipunagara mempunyai beberapa tugas dan

fungsi sesuai dengan bagiannya. Berikut ini organisasi yang ada di SMKN 1

Cipunagara.

III-28
 Gambar 3.1 Struktur Organisasi Sekolah

3.1.3 Tugas Fokok dan Fungsi

Tugas pokok organisasi di SMKN 1 Cipunagara sebagai berikut.

1. Kepala Sekolah

Merupakan pimpinan disekolah, yang memiliki tugas penanggung jawab

atas semua kegiatan-kegiatan yang menyangkut pendidikan yang dilakukan

oleh bawahannya.

2. Komite Sekolah

Berfungsi dalam peningkatan mutu pelayanan pendidikan di sekolah. Dalam

usaha meningkatkan mutu pendidikan itu, Komite Sekolah bisa melakukan

penggalangan dana melalui upaya kreatif dan inovatif. Namun, tugas

Komite Sekolah bukan hanya menggalang dana.

3. Wakil Kepala Sekolah bidang Kurikulum

Merupakan wakil dari kepala sekolah yang khusus ditugaskan untuk bidang

akademik, bertanggung jawab atas kurikulum akademik dan proses belajar

mengajar.

4. Wakil Kepala Sekolah bidang Kesiswaan

Membantu kepala sekolah dalam memimpin, merencanakan,

mengembangkan, mengkoordinasikan, mengwasi, dan mengendalikan

kegiatan sekolah dalam melaksanakan program bidang kesiswaan sesuai

dengan visi, misi, dan program kerja yang telah sitetapkan di SMKN 1

Cipunagara.

III-29
 5. Wakil Kepala Sekolah bidang Sarana dan Prasarana

Bertugas membuat dan menyusun program kerja tahunan kegiatan sekolah

di bidang sarana dan prasarana dan mengkoordinir serta mengawasi

pelaksanaannya.

6. Wakil Kepala Sekolah bidang HKI ( Hubungan Kerja Industri )

Memiliki tugas membantu alumni sekolah untuk bisa bekerja diperusahaan.

7. Wakil Kepala Sekolah bidang Menejemen Mutu

Bertugas menyusun program kerja tahunan dan melaksanakan pembinaan dan

koordinasi pelaksanaan sistem manajemen mutu.

8. Kepala Tata Usaha

Merupakan pegawai sekolah yang mengatur administratif sekolah, siswa-

siswi sarana dan prasarana, dan jadwal kegiatan belajar mengajar.

9. Ketua Kompetensi Keahlian ( K3 )

Menyusun program kerja, mengkoordinir tugas guru dalam pembelajaran,

mengkoordinir pengembangan bahan ajar, dan memerakan kebutuhan

sumber daya untuk pembelajaran guru-guru bidang studi.

3.2 Analisis Kebutuhan Sistem

Sebelum melakukan perancangan sistem, diperlukan adanya analisis

terhadap sistem yang sedang berjalan terlebih dahulu. Tujuan dari analisis sistem

yang sedang berjalan adalah untuk menganalisis sistem pengelolaan data yang

sedang digunakan saat ini untuk mengetahui kekurangan serta untuk

mengembangkan sistem melalui perbaikan sehingga Sistem Informasi Manajemen

Surat Masuk dan Surat Keluar ini dapat menghasilkan suatu sistem dengan

informasi yang akurat, tepat waktu dan relevan. Analisis sistem yang sedang

III-30
 berjalan meliputi Analisis dokumen, Analisis prosedur yang sedang berjalan serta

Evaluasi sistem yang sedang berjalan.

3.2.1 Analisis Dokumen

Pada sub bab ini merupakan analisis dokumen yang akan dijelaskan

mengenai analisis dari dokumen – dokumen yang terlibat dalam prosedur yang

sedang berjalan di bagian Tata Usaha SMK Negeri 1 Cipunagara antara lain sebagai

berikut:

Deskripsi Sumber Aliran Data Elemen

Dokumen surat-surat yang Sumber : Aliran Tanggal

Surat diterima oleh suatu Instansi/ Data : Dari Surat,

Masuk organisasi/ Organisasi Lain. Tujuan Ke Nomor

perusahaan yang Staff TU Surat, Asal

berasal dari dan Surat, Isi

seseorang atau diteruskan Ringkasan,

dari suatu ke atasan. Kode

organisasi. Klasifikasi,

Keterangan

.
Dokumen surat-surat yang Karyawan atau Dari Atasan Tanggal

Surat dikeluarkan/dibuat Atasan. ke Staff TU Surat,

Keluar suatu organisasi/ dan Nomor

perusahaan untuk diteruskan Surat,

dikirimkan kepada ke tujuan. Tujuan

pihak lain, baik Surat, Isi

III-31
 perseorangan Ringkasan,

maupun kelompok. Kode

Klasifikasi,

Keterangan

3.2.2 Deskripsi Prosedur Kerja

Analisis prosedur yang sedang berjalan akan membahas secara

sistematis mengenai aktifitas–aktifitas yang terjadi dalam sistem informasi

yang sedang berjalan saat ini, diantaranya adalah sebagai berikut ini :

SURAT KELUAR

Pimpinan Staff TU Kurir

Mulai

Memberi
Tugas

Membuat
Surat

Mengisi
Menerima
Identitas

Surat
Mengirim
Ke Tujuan

Selesai

Gambar 3.2 Flow Map Surat Keluar

III-32
 Prosedur Pengelolaan Surat Keluar

 Pimpinan memberi tugas membuat surat

 Staff TU membuat surat dan mencetaknya

 Staff TU mengisi identitas surat yang dibuat di buku Surat Keluar

 Staff TU Membuat Copy/Arsip Suratnya dan disimpan di map arsip

 Surat di berikan ke kurir

 Kurir mengantar surat ke tujuan

SURAT MASUK

Kurir Staff TU Pimpinan

Mulai Surat dan Tanda

Terima

Mengantar
kan Surat
Menyerahkan

Surat dan Tanda

Terima Menerima

Tanda Terima Mengisi

Identitas

Surat
Selesai

Menyerah
Menerima
kan

Surat

Gambar 3.3 Flowmap Surat Masuk

 Prosedur Pengelolaan Surat Masuk

III-33
  Kurir mengantar surat ke staff TU

 Staff TU menerima surat dari kurir

 Staff TU Menyerahkan Tanda Terima ke Kurir

 Staff TU Membaca Surat

 Staff TU Mengisi identitas Surat ke buku Surat Masuk

 Staff TU Mengantarkan Surat ke Tujuan Surat

3.3 Evaluasi Sistem yang Sedang Berjalan

Setelah melewati beberapa tahapan analisa terhadap sistem informasi

yang sedang berjalan, maka dapat diketahui kelemahan-kelemahan yang terjadi

pada sistem tersebut, kelemahan-kelemahan tersebut seperti pada tabel berikut

ini:

No Masalah Rencana Pemecahan

1 Pengarsipan data yang masih Dibuat sistem pengolah data sehingga
menggunakan metode manual. akan lebih mudah dalam pengarsipan
serta pencariannya.
2 Pengisian identitas masih manual di Dibuat sistem pengolah identitas surat
buku surat masuk dan surat keluar. dengan sistem database.
3 Pembuatan laporan mengenai data Dibuatkan sistem pengolah data yang
Surat masuk dan surat Keluar masih dapat memberikan output berupa
di rekap manual. laporan yang dibutuhkan secara
otomatis.
4 Pencarian data dilakukan secara Dibuat sistem pengolah data yang
manual dari berkas-berkas yang mempermudah dalam pencarian data.
ada.
Tabel 3.1 Sistem Yang Sedang Berjalan

III-34
 Dengan pembuatan Sistem Informasi ini diharapkan semua kekurangan

atau kendala yang terjadi dalam mengelola data surat masuk dan keluar di SMK

Negeri 1 Cipunagara dapat dihadapi dengan baik.

III-35
3.3.2 Kebutuhan Informasi

Dalam pembuatan Sistem informasi ini dibutuhkan informasi mengenai surat

menyurat, diantaranya :

No Aktor Informasi yang Dibutuhkan

1 Admin Informasi mengenai surat masuk.
2 Admin Informasi mengenai surat keluar.
3 Admin Informasi mengenai klasifikasi surat
4 Admin Informasi surat yang di disposisikan.
Tabel 3.2 Kebutuhan Informasi

3.4 Kebutuhan Perangkat Lunak

Kebutuhan perangkat lunak merupakan faktor-faktor yang harus

dipenuhi untuk merancang sebuah perangkat lunak (aplikasi) sehingga

perangkat lunak tersebut sesuai dengan maksud dan tujuan perangkat lunak

(aplikasi) tersebut dibuat. Beberapa perangkat lunak pendukung yang harus di

install adalah sebagai berikut :

1. OS Windows 7

2. Notepad ++

3. XAMPP

4. Chrome browser

5. Macromedia Firework

6. Ms. Visio 2007

7. StarUML

3.4.2 Kebutuhan Fungsional

III-36
 Analisis kebutuhan fungsional menggambarkan proses kegiatan yang

akan diterapkan dalam sebuah sistem dan menjelaskan kebutuhan yang

diperlukan sistem agar dapat berjalan dengan baik. Berikut adalah daftar

Kebutuhan fungsional untuk Sistem Informasi Pengelolaan Surat Masuk dan

surat keluar :

No SRS Deskripsi
Admin System
SRS-F-01 Sistem dapat melakukan Login

SRS-F-02 Sistem dapat menangani kelola surat masuk dengan tambah data,
edit data, hapus data dan cetak data
SRS-F-03 Sistem dapat menangani kelola surat keluar dengan tambah data,
edit data, hapus data dan cetak data
SRS-F-04 Sistem dapat menampilkan laporan data surat masuk berdasar
tanggal.
SRS-F-05 Sistem dapat menampilkan laporan data surat keluar berdasar
tanggal.
SRS-F-06 Sistem dapat membuat klasifikasi surat

SRS-F-07 Sistem dapat menambah, mengedit dan menghapus user

pengguna.
No SRS Deskripsi

Admin System
SRS-F-01 Sistem dapat melakukan Login

SRS-F-02 Sistem dapat menangani kelola surat masuk dengan tambah data,
edit data, hapus data dan cetak data
SRS-F-03 Sistem dapat menangani kelola surat keluar dengan tambah data,
edit data, hapus data dan cetak data
SRS-F-04 Sistem dapat menampilkan laporan data surat masuk berdasar
tanggal.
SRS-F-05 Sistem dapat menampilkan laporan data surat keluar berdasar
tanggal.
SRS-F-06 Sistem dapat membuat klasifikasi surat
III-37

SRS-F-07 Sistem dapat menambah atau menghapus user pengguna.

 Tabel 3.3. Kebutuhan Fungsional

3.4.3 Kebutuhan Non Fungsional

Berikut adalah daftar kebutuhan non fungsional dalam pembuatan system

informasi pengelolaan surat ini :

No SRS Deskripsi
SRS-NF-01 Sistem dibangun dengan tampilan antarmuka yang

sederhana
SRS-NF-02 Sistem dibangun berbasis Website dengan syarat bisa
dijalankan minimal memory 512 MB, minimal Processor
1Ghz, Operating System Windows 7 dan Browser yang
digunakan untuk mengaksesnya
SRS-NF-03 Pembangunan sistem menggunakan bahasa
pemrograman PHP dan MySQL sebagai database nya
Tabel 3.4 Kebutuhan Non Fungsional

III-38
3.4.4 Pendefinisian Aktor dan Use Case

1. Definisi Aktor

berikut ini dijelaskan aktor-aktor yang berhubungan langsung dengan sistem

yang akan dibuat :

No Aktor Deskripsi
(1) (2) (3)
1 Super Admin Aktor yang bertindak sebagai administrator yang

mempunyai akses penuh untuk mengatur data

master dan mengolah semua kegiatan pengelolaan

surat.
2 Admin Aktor yang terlibat dengan sistem ini adalah admin

yang bertugas mencatat administrasi surat masuk

dan keluar dan mencetak lembar disposisi.

Tabel 3.5 Definisi Aktor

2. Definisi Use case

Berikut dijelaskan definisi Use case yang berhubungan dengan sistem ini :

No.Use Nama Use Deskripsi

case case
(1) (2) (3)
UC-1 Login Use case yang tugasnya berperan sebagai

Autentifikasi pengguna Sistem

UC-2 Kelola User Use case yang menangani pengolahan

user/pengguna
UC-3 Kelola Use case yang menangani klasifikasi surat.

III-39
 Klasifikasi

Surat
UC-4 Kelola Surat Use case untuk menangani pengolahan

Masuk Data Surat Masuk

UC-5 Kelola Surat Use Case untuk menangani pengolahan

Keluar data Surat keluar

UC-6 Kelola Use case yang menangani pengolahan

Laporan laporan Surat Masuk dan Keluar berdasar

waktu
Tabel 3.6 Definisi Use case

3.4.5 Pemodelan Use case

Analisis yang dilakukan dimodelkan dengan menggunakan UML

(Unified Modeling Language). Tahap-tahap pemodelan dalam analisis

tersebut antara lain identifikasi aktor, Use case diagram, skenario, activity

diagram. Berdasarkan kebutuhan, Aktor dapat diidentifikasikan sebagai

berikut:

1) Aktor pertama ialah super admin yang mempunyai akses penuh untuk

mengatur data master dan mengolah semua kegiatan pengelolaan surat.

2) Aktor kedua yang terlibat dengan sistem ini adalah admin yang bertugas

mencetak lembar disposisi dan mencatat administrasi surat masuk dan

keluar.

Use case mendeskripsikan interaksi tipikal antara para pengguna sistem

dengan sistem itu sendiri, dengan memberi sebuah narasi tentang

bagaimana sistem tersebut digunakan. Use case Diagram menampilkan actor

mana yang menggunakan Use case mana, Use case mana yang memasukan

III-40
Use case lain dan hubungan antara actor dan Use case, gambarnya adalah

seperti berikut ini :

Ga
mbar 3.4 Pemodelan Use case

III-41
3.4.6 Skenario Use case

1. Login

Berikut skenario Use case yang telah di jelaskan sebelumnya :

Gambar 3.5 Use case Login

Use case : Login

ID : UC-1
Aktor Admin
Deskrpsi Use case yang tugasnya berperan sebagai

Autentifikasi pengguna Sistem

Pre-Condition Aktor telah berada pada halaman Login

Skenario

Aksi Aktor Reaksi Sistem

Memasukan Username dan

Password
Menekan Tombol “Login” Cek validasi data Masukan dengan data pada

database. Jika data anggota valid, maka

sistem akan menampilkan halaman

selanjutnya

III-42
 Skenario Alternatif
Alur Alternatif no. 4 Jika data masukan tidak valid maka sistem

akan menampilkan pesan “Username dan

Password salah” dan kembali ke form login

PostCondition:

User Telah Login pada sistem

Tabel 3.7 Skenario Use case Login

2. Kelola Pengguna

System

Lihat Pengguna

Tambah Pengguna
«extends»

«extends»
Kelola Pengguna
Edit Pengguna

«extends»
Admin

Hapus Pengguna

Gambar 3.6 Use case Kelola Pengguna

Use case Kelola Pengguna berfungsi untuk mengelola pengguna sistem

berikut ini adalah skenario use case nya:

Use case : Kelola Pengguna

ID : UC-2
Aktor Admin
Deskrpsi Use case yang menangani pengelolaan

III-43
 pengguna
Pre-Condition Aktor telah login dan memilih menu kelola

pengguna/user
Skenario

Aksi Aktor Reaksi Sistem

Menekan Tombol “Tambah Sistem menampilkan form Tambah

Pengguna“
Mengisi data pengguna baru Mengecek Valid tidaknya data Masukan

Menekan Tombol “Simpan” Jika Data Pengguna Valid, Maka data

tersebut disimpan di basis data dan akan

menampilkan pesan “Data Pengguna sudah

di simpan”
Aksi Aktor Reaksi Sistem
Menekan tombol “Edit Pengguna” Tampil Data Pengguna yang dapat di edit
Pilih data pengguna yang akan di Tampil form Data Yang akan di edit

edit

Memperbaharui Data Pengguna Mengecek Valid tidaknya data Masukan

seperti mengubah nama dan Jika Data Pengguna Valid, Maka data

password tersebut disimpan di basis data dan akan

Menekan tombol “Simpan” menampilkan pesan “Data Pengguna sudah

di simpan”
Aksi Aktor Reaksi Sistem
Menekan Tombol “Hapus Tampil daftar data pengguna

Pengguna”
Pilih salahsatu Data pengguna

yang akan di hapus

Menekan tombol “Hapus” Pesan Konfirmasi “Ya” atau “Tidak”
Menekan tombol “Ya” Data di hapus dari database tampil pesan

“Data Pengguna berhasil dihapus”

Menekan tombol “Tidak” Data tidak dihapus dari database tampil

III-44
 pesan “Data tidak di Hapus”
PostCondition:

Konten kelola pengguna telah update

Tabel 3.8 Skenario Kelola Pengguna

III-45
 3. Kelola Klasifikasi

Use case Kelola Aset memodelkan dalam pengelolaan klasifikasi surat

Gambar 3.7 Use case Kelola klasifikasi surat

Use case Klasifikasi Surat berfungsi untuk memisahkan atau

memudahkan dalam pengarsipan sipengguna sistem. Berikut ini adalah

skenario use case nya:

Use case : Kelola Klasifikasi Surat

ID : UC-3
Aktor Admin
Deskrpsi Use case yang menangani pengolahan

Klasifikasi Surat
Pre-Condition Aktor telah login lalu masuk ke menu

Referensi
Skenario

Aksi Aktor Reaksi Sistem

III-46
Menekan Tombol “referensi” Tampil data klasifikasi surat
Menekan Tombol “Tambah Data“ Sistem menampilkan form Tambah klasifikasi

surat
Mengisi form tambah klasifikasi Mengecek Valid tidaknya data Masukan

surat Jika Data Pengguna Valid, Maka data

Menekan Tombol “Simpan” tersebut disimpan di basis data dan akan

menampilkan pesan “Data sudah di simpan”

Aksi Aktor Reaksi Sistem
Pilih data yang akan di edit Tampil Form Edit Data yang dipilih untuk

diedit
Memperbaharui Data klasifikasi

surat
Menekan tombol “Simpan” Mengecek Valid tidaknya data Masukan

Jika Data Valid, Maka data tersebut disimpan

di basis data dan akan menampilkan pesan

“Data sudah di simpan”

Aksi Aktor Reaksi Sistem
Pilih salah satu Data yang akan di

hapus
Menekan tombol “Hapus” Pesan Konfirmasi “Ya” atau “Tidak”
Menekan tombol “Ya” Data di hapus dari database tampil pesan

“Data berhasil dihapus”

Menekan tombol “Tidak” Data tidak dihapus dari database tampil

pesan “Data tidak di Hapus”

PostCondition:

Konten kelola Data klasifikasi surat telah update

Tabel 3.9 Skenario Use case Kelola klasifikasi surat

4. Kelola Surat Masuk

III-47
 Ga

mbar 3.8 Use case Kelola Surat Masuk

III-48
 Use case Kelola Surat Masuk menggambarkan pemodelan

sistem dalam mengelola surat masuk dan pencetakan disposisi.

Use case : Kelola Surat Masuk

ID : UC-4
Aktor Admin, Petugas Disposisi
Deskrpsi Use case yang menangani pengolahan Surat

masuk dan pencetakan disposisi

Pre-Condition Aktor telah login dan masuk ke menu

transaksi surat masuk

Skenario

Aksi Aktor Reaksi Sistem

Menekan Tombol “Surat Masuk” Tampil data Surat Masuk
Menekan Tombol “Tambah Data” Sistem menampilkan Form tambah surat

masuk
Mengisi data surat masuk

Menekan Tombol “Simpan” Mengecek Valid tidaknya data Masukan

Jika Data Pengguna Valid, Maka data

tersebut disimpan di basis data dan akan

menampilkan pesan “Data sudah di simpan”

Aksi Aktor Reaksi Sistem
Pilih surat masuk yang akan di Tampil Form Edit surat masuk

edit datanya
Memperbaharui Data surat

masuk
Menekan tombol “Simpan” Mengecek Valid tidaknya data Masukan

Jika Data Valid, Maka data tersebut disimpan

di basis data dan akan menampilkan pesan

“Data sudah di simpan”

Aksi Aktor Reaksi Sistem

III-49
Pilih data yang akan di hapus

Menekan tombol “Hapus” Pesan Konfirmasi “Ya” atau “Tidak”

Menekan tombol “Ya” Data di hapus dari database tampil pesan

“Data berhasil dihapus”

Menekan tombol “Tidak” Data tidak dihapus dari database tampil

pesan “Data tidak di Hapus”

Aksi Aktor Reaksi Sistem
Pilih menu disposisi Tampil lembar disposisi
Tekan tpmbol “cetak disposisi” Mengirim perintah mencetak ke printer
PostCondition:

Konten kelola surat masuk telah update

Tabel 3.10 Skenario Use case Kelola Surat Masuk

III-50
 5. Kelola Surat Keluar

Gambar 3.9 Use case Kelola Surat Keluar

Use case Kelola Surat keluar menggambarkan pemodelan sistem

dalam mengelola surat keluar.

Use case : Kelola Surat Keluar

ID : UC-5
Aktor Admin
Deskrpsi Use case yang menangani pengolahan Surat

Keluar dan pencetakan disposisi

Pre-Condition Aktor telah login dan masuk ke menu

transaksi surat Keluar

Skenario

Aksi Aktor Reaksi Sistem

Menekan Tombol “Surat Keluar” Tampil data Surat Keluar
Menekan Tombol “Tambah Data” Sistem menampilkan Form tambah surat

Keluar

III-51
Mengisi data surat Keluar

Menekan Tombol “Simpan” Mengecek Valid tidaknya data Masukan

Jika Data Pengguna Valid, Maka data

tersebut disimpan di basis data dan akan

menampilkan pesan “Data sudah di simpan”

Aksi Aktor Reaksi Sistem
Pilih surat keluaryang akan di edit Tampil Form Edit surat keluar

datanya
Memperbaharui Data surat

keluar
Menekan tombol “Simpan” Mengecek Valid tidaknya data Masukan

Jika Data Valid, Maka data tersebut disimpan

di basis data dan akan menampilkan pesan

“Data sudah di simpan”

Aksi Aktor Reaksi Sistem
Pilih data yang akan di hapus

Menekan tombol “Hapus” Pesan Konfirmasi “Ya” atau “Tidak”

Menekan tombol “Ya” Data di hapus dari database tampil pesan

“Data berhasil dihapus”

Menekan tombol “Tidak” Data tidak dihapus dari database tampil

pesan “Data tidak di Hapus”

PostCondition:

Konten kelola surat keluar telah update

Tabel 3.11 Skenario Use case Kelola Surat Keluar

6. Laporan/Agenda Surat

III-52
 Gambar 3.10 Use case Laporan/Agenda Surat

Use case Laporan menggambarkan pemodelan mengenai pelaporan

sistem.

III-53
Use case : Kelola Laporan Surat

ID : UC-5
Aktor Admin
Deskrpsi Use case yang menangani Kelola Laporan
Pre-Condition Aktor telah login dan masuk ke menu Kelola

Laporan Agenda
Skenario

Aksi Aktor Reaksi Sistem

Menekan Tombol “Agenda” Tampil Sub menu agenda
Menekan Tombol “surat masuk“ Tampil pemilihan jangka waktu yang ingin di

tampilkan
Memilih tanggal awal dan tanggal Sistem menampilkan laporan surat masuk

akhir sesuai periode yang diminta.

Menekan tombol cetak Sistem menjalankan perintah untuk

mencetak laporan surat masuk

Aksi Aktor Reaksi Sistem
Menekan Tombol “Agenda” Tampil Sub menu agenda
Menekan Tombol “surat keluar“ Tampil pemilihan jangka waktu yang ingin di

tampilkan
Memilih tanggal awal dan tanggal Sistem menampilkan laporan surat keluar

akhir sesuai periode yang diminta.

Menekan tombol “cetak” Sistem menjalankan perintah untuk

mencetak laporan surat keluar

PostCondition:

Konten kelola Laporan telah dicetak

Tabel 3.12 Skenario Use case Laporan/Agenda Surat

7. Activity Diagram

Activity Diagram adalah diagram yang memperlihatkan aliran dari suatu

aktivitas lainnya dalam suatu sistem. Bagaimana aktivitas itu dimulai

III-54
decision yang mungkin terjadi dan bagaimana aktivitas itu berakhir. Gambar

dibawah ini memperlihatkan Activity Diagram dari setiap Use case.

III-55
 Acivity Diagram Login

Gambar 3.11 Activity Diagram Login

III-56
 Activity Diagram Kelola Pengguna

Kelola Pengguna

Klik Kelola Pengguna Tampil Halaman Kelola Pengguna

Pilih Aksi

Tambah Pengguna Edit Pengguna Hapus Pengguna

Tampil Data Pengguna Tampil Data Penguna

Tampil Form Tambah

Pilih Data yang akan di edit pilih data yang akan dihapus

Input Data
No
No

Tampil Form Edit Klik Hapus

Klik Simpan

Yes

Yes Edit Data

No Hapus dari database

Simpan ke database

Klik Update

Yes

Simpan ke database

Gambar3.12 Activity Diagram Kelola Pengguna

III-57
 Activity Diagram Kelola Laporan

Gambar 3.13 Activity Diagram Kelola Laporan

III-58