RANCANGAN SISTEM DAN PROGRAM USULAN
4.1. Analisis Kebutuhan Perangkat Lunak
Menurut (Rosa A & Shalahuddin, 2016:29) mengatakan bahwa ”Proses pengumpulan kebutuhan dilakukan secara intensif untuk menspesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh
user”.
Pada tahap ini akan menjelaskan tentang tahapan analisis, use case diagram dan activity diagram.
4.1. 1 Tahapan Analisis
Sistem informasi akademik bimbingan belajar STAN D2STARS adalah sebuah
website informasi yang dapat diakses secara online oleh pengunjung, pendaftar yang
dapat mendaftar dan konfirmasi pembayaran secara online tanpa harus datang ke tempat bimbingan belajar, sedangkan untuk siswa dapat melihat jadwal belajar yang
update tanpa harus bertanya ke pihak bimbingan belajar.
Berikut ini spesifikasi kebutuhan (system requirement) dari sistem informasi bimbingan belajar STAN D2STARS:
A. Halaman Pengunjung
A. 1. Pengunjung dapat melihat halaman awal beranda A. 2. Pengunjung dapat melihat profil
A. 3. Pengunjung dapat melihat galeri A. 4. Pengunjung dapat melihat kontak A. 5. Pengunjung dapat melihat artikel
A. 6. Pengunjung dapat melihat berita B. Halaman Registrasi Pendaftar
B.1. Pendaftar dapat melihat informasi registrasi B.2. Pendaftar dapat melakuan registrasi
C. Halaman Konfirmasi Pembayaran Pendaftar Dan Siswa
C.1. Pendaftar dan siswa dapat login dan logout konfirmasi pembayaran C.2. Pendaftar dan siswa dapat mengelola konfirmasi pembayaran D. Halaman Siswa
D. 1. Siswa dapat login dan logout
D. 2. Siswa dapat melihat beranda D. 3. Siswa dapat melihat data pribadi D. 4. Siswa dapat mengubah data pribadi
D. 5. Siswa dapat mengubah password
D. 6. Siswa dapat mengubah pilihan waktu belajar D. 7. Siswa dapat melihat tentor
D. 8. Siswa dapat mencari tentor
D. 9. Siswa dapat melihat jadwal bimbingan belajar D. 10. Siswa dapat mencetak jadwal bimbingan belajar E. Halaman Admin
E. 1. Admin dapat login dan logout
E. 2. Admin dapat melihat beranda dan mengubah profil akun E. 3. Admin dapat mengelola data kategori
E. 4. Admin dapat mengelola data informasi E. 5. Admin dapat mengelola data admin E. 6. Admin dapat mengelola data pendaftar
E. 7. Admin dapat mengelola data siswa E. 8. Admin dapat mengelola data tentor
E. 9. Admin dapat mengelola data program bimbel E. 10. Admin dapat mengelola data jadwal
E. 11. Admin dapat mengelola data konfirmasi pembayaran E. 12. Admin dapat mencetak dan melihat laporan
4.1. 2 Use Case Diagram
Menurut (Rosa A & Shalahuddin, 2016:155) mengatakan bahwa ”Use case atau diagram use case merupakan pemodelan untuk kelakuan (behavior) sistem informasi yang akan dibuat”.
A. Use Case Diagram Halaman Pengunjung
Gambar IV.1.
Deskripsi Use Case Diagram Halaman Pengunjung Tabel IV.1.
Deskripsi Use Case Diagram Halaman Pengunjung
Use Case Name Halaman Pengunjung
Requirements A1-A6
Goal Pengunjung dapat melihat menu-menu utama pada awal
halaman pengunjung.
Pre-conditions Pengunjung telah mengunjungi website
Post-conditions Sistem menampilkan menu-menu
Failed end condition Pengunjung membatalkan kunjungan website
Primary Actors Pengunjung
Main Flow/Basic Path 1. Pengunjung dapat melihat halaman awal beranda
2. Pengunjung dapat melihat profil 3. Pengunjung dapat melihat galeri 4. Pengunjung dapat melihat kontak 5. Pengunjung dapat melihat artikel 6. Pengunjung dapat melihat berita
B. Use Case Diagram Halaman Registrasi Pendaftar
Gambar IV.2.
Use Case Diagram Halaman Registrasi Pendaftar
Deskripsi Use Case Diagram Halaman Registrasi Pendaftar Tabel IV.2.
Deskripsi Use Case Diagram Halaman Registrasi Pendaftar
Use Case Name Halaman Registrasi Pendaftar
Requirements B1, B2
Goal Pendaftar bisa melihat informasi registrasi dan
melakukan registrasi secara online di website.
Pre-conditions Pendaftar telah melihat informasi registrasi.
Post-conditions Data registrasi berhasil disimpan.
Failed end condition Data registrasi gagal disimpan.
Main Flow/Basic Path 1. Pendaftar memilih menu “Registrasi”. 2. Sistem menampilkan halaman awal registrasi. 3. Pendaftar memilih tombol “Informasi Registrasi”. 4. Sistem menampilkan informasi registrasi.
Alternative Flow /Invariant A
1. Pendaftar memilih menu ”Registrasi”. 2. Sistem menampilkan halaman awal registrasi. 3. Pendaftar memilih tombol “Formulir Registrasi”. 4. Sistem menampilkan formulir registrasi.
5. Pendaftar mengisi formulir registrasi. 6. Pendaftar memilih tombol “Simpan”. 7. Sistem akan menyimpan data.
C. Package Diagram dan Use Case Diagram Halaman Konfirmasi Pembayaran
Pendaftar Dan Siswa
1. Package Diagram Halaman Konfirmasi Pembayaran Pendaftar Dan Siswa
Gambar IV.3.
Package Diagram Halaman Konfirmasi Pembayaran Pendaftar Dan
Siswa
2. Use Case Diagram Otentifikasi Halaman Konfirmasi Pembayaran Pendaftar Dan Siswa
Gambar IV.4.
Use Case Diagram Otentifikasi Halaman Konfirmasi Pembayaran
Deskripsi Use Case Diagram Otentifikasi Halaman Konfirmasi Pembayaran Pendaftar Dan Siswa
Tabel IV.3.
Deskripsi Use Case Diagram Otentifikasi Halaman Konfirmasi Pembayaran Pendaftar Dan Siswa
Use Case Name Otentifikasi Halaman Konfirmasi Pembayaran
Pendaftar Dan Siswa
Requirements C1
Goal Pendaftar dan siswa dapat login serta logout.
Pre-conditions Pendaftar dan siswa telah melakukan login.
Post-conditions Pendaftar dan siswa berhasil login.
Failed end condition Pendaftar dan siswa gagal login.
Primary Actors Pendaftar dan siswa
Main Flow/Basic Path 1. Pendaftar dan siswa telah melakukan login.
2. Sistem melakukan otentifikasi. 3. Pendaftar dan siswa berhasil login.
Alternative Flow /Invariant 1
1. Pendaftar dan siswa melakukan logout. 2. Sistem melakukan otentifikasi.
3. Pendaftar dan siswa berhasil logout.
3. Use Case Diagram Pendaftar Dan Siswa Mengelola Konfirmasi Pembayaran
Gambar IV.5.
Use Case Diagram Pendaftar Dan Siswa Mengelola Konfirmasi
Deskripsi Use Case Diagram Pendaftar Dan Siswa Mengelola Konfirmasi Pembayaran
Tabel IV.4.
Deskripsi Use Case Diagram Pendaftar Dan Siswa Mengelola Konfirmasi Pembayaran
Use Case Name Mengelola Konfirmasi Pembayaran
Requirements C2
Goal Pendaftar dan siswa dapat tambah, edit, simpan dan
cetak.
Pre-conditions Pendaftar dan siswa telah melakukan login.
Post-conditions Konfirmasi pembayaran berhasil disimpan, diperbarui
dan struk pembayaran yang berhasil di cetak per transaksi.
Failed end condition Konfirmasi pembayaran gagal disimpan serta
diperbarui dan struk pembayaran gagal di cetak per transaksi.
Primary Actors Pendaftar dan siswa
Main Flow/Basic Path 1. Pendaftar dan siswa melihat konfirmasi
pemabayaran
2. Pendaftar dan siswa mengisi konfirmasi pembayaran pada form konfirmasi pembayaran.
3. Pendaftar dan siswa memilih tombol “Simpan”. 4. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Pendaftar dan siswa melihat konfirmasi pembayaran.
2. Pendaftar dan siswa memilih konfirmasi pembayaran yang ingin diedit, kemudian pilih tombol “Edit”.
3. Sistem menampilkan form konfirmasi pembayaran. 4. Pendaftar dan siswa mengedit konfirmasi
pembayaran.
5. Pendaftar dan siswa memilih tombol “Simpan”. 6. Sistem menyimpan data.
Invariant 2 1. Pendaftar dan siswa melihat konfirmasi
pembayaran.
2. Pendaftar dan siswa memilih konfirmasi pembayaran yang ingin dicetak struk
pembayarannya, kemudian pilih tombol “Cetak”. 3. Sistem menampilkan cetak struk konfirmasi
D. Package Diagram dan Use Case Diagram Halaman Siswa
1. Package Diagram Halaman Siswa
Gambar IV.6.
Package Diagram Halaman Siswa
2. Use Case Diagram Otentifikasi Halaman Siswa
Gambar IV.7.
Use Case Diagram Otentifikasi Halaman Siswa
Deskripsi Use Case Diagram Otentifikasi Halaman Siswa Tabel IV.5.
Deskripsi Use Case Diagram Otentifikasi Halaman Siswa
Use Case Name Otentifikasi Halaman Siswa
Requirements D1
Goal Siswa dapat login dan logout.
Pre-conditions Siswa telah melakukan login.
Post-conditions Siswa berhasil login.
Failed end condition Siswa gagal login.
Main Flow/Basic Path 1. Pendaftar telah melakukan login. 2. Sistem melakukan otentifikasi. 3. Pendaftar berhasil login.
Alternative Flow /Invariant 1
1. Pendaftar melakukan logout. 2. Sistem melakukan otentifikasi. 3. Pendaftar berhasil logout.
3. Use Case Diagram Melihat Beranda Halaman Siswa
Gambar IV.8.
Use Case Diagram Melihat Beranda Halaman Siswa
Deskripsi Use Case Diagram Melihat Beranda Halaman Siswa Tabel IV.6.
Deskripsi Use Case Diagram Melihat Beranda Halaman Siswa
Use Case Name Melihat Beranda Halaman Siswa
Requirements D2
Goal Siswa dapat melihat beranda.
Pre-conditions Siswa telah melakukan login.
Post-conditions Beranda berisi nama siswa berhasil tampil.
Failed end condition Beranda berisi nama siswa gagal tampil.
Primary Actors Siswa
Main Flow/Basic Path 1. Siswa melihat beranda.
4. Use Case Diagram Melihat Dan Mengubah Data Pribadi Halaman Siswa
Gambar IV.9.
Use Case Diagram Melihat Dan Mengubah Data Pribadi Halaman Siswa
Deskripsi Use Case Diagram Melihat Dan Mengubah Data Pribadi Halaman Siswa
Tabel IV.7.
Deskripsi Use Case Diagram Melihat Dan Mengubah Data Pribadi Halaman Siswa
Use Case Name Melihat Dan Mengubah Data Pribadi Halaman
Siswa
Requirements D3-D6
Goal Siswa dapat edit data pribadi.
Pre-conditions Siswa telah melakukan login.
Post-conditions Data pribadi berhasil diperbarui.
Failed end condition Data pribadi gagal diperbarui.
Main Flow/Basic Path 1. Siswa melihat data pribadi. 2. Siswa mengedit data pribadi. 3. Siswa memilih tombol simpan. 4. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Siswa melihat data pribadi.
2. Siswa memilih tombol “Ubah” pada password. 3. Sistem menampilkan form data pribadi. 4. Siswa memasukkan password baru. 5. Siswa memilih tombol simpan. 6. Sistem menyimpan data.
Alternative Flow /Invariant 2
1. Siswa melihat data pribadi.
2. Siswa memilih tombol “Pilih” pada pilihan waktu. 3. Sistem menampilkan form data pribadi.
4. Siswa mencentang pilihan waktu. 5. Siswa memilih tombol simpan. 6. Sistem menyimpan data.
5. Use Case Diagram Melihat Dan Mencari Tentor Halaman Siswa
Gambar IV.10.
Use Case Diagram Melihat Dan Mencari Tentor Halaman Siswa
Deskripsi Use Case Diagram Melihat Dan Mencari Tentor Halaman Siswa Tabel IV.8.
Deskripsi Use Case Diagram Melihat Dan Mencari Tentor Halaman Siswa
Use Case Name Melihat Dan Mencari Tentor Halaman Siswa
Requirements D7, D8
Goal Siswa dapat cari.
Pre-conditions Siswa telah melakukan login.
Post-conditions Tentor berhasil ditemukan.
Failed end condition Tentor yang dicari tidak ada.
Main Flow/Basic Path 1. Siswa melihat tentor
2. Siswa mengisi kode tentor pada form cari. 3. Siswa memilih tombol “Cari”.
4. Sistem menampilkan tentor yang dicari.
6. Use Case Diagram Melihat Dan Mencetak Jadwal Bimbingan Belajar Halaman Siswa
Gambar IV.11.
Use Case Diagram Melihat Dan Mencetak Jadwal Bimbingan Belajar
Halaman Siswa
Deskripsi Use Case Diagram Melihat Dan Mencetak Jadwal Bimbingan Belajar Halaman Siswa
Tabel IV.9.
Deskripsi Use Case Diagram Melihat Dan Mencetak Jadwal Bimbingan Belajar Halaman Siswa
Use Case Name Melihat Dan Mencetak Jadwal Bimbingan Belajar
Halaman Siswa
Requirements D9, D10
Goal Siswa dapat cetak.
Pre-conditions Siswa telah melakukan login.
Post-conditions Jadwal bimbingan belajar berhasil dicetak.
Failed end condition Jadwal bimbingan belajar gagal dicetak.
Primary Actors Siswa
Main Flow/Basic Path 1. Siswa melihat jadwal bimbingan belajar.
2. Siswa memilih tombol “Cetak”.
3. Sistem menampilkan cetak jadwal bimbingan belajar.
E. Package Diagram dan Use Case Diagram Halaman Admin
1. Package Diagram Halaman Admin
Gambar IV.12.
Package Diagram Halaman Admin
2. Use Case Diagram Otentifikasi Halaman Admin
Gambar IV.13.
Use Case Diagram Otentifikasi Halaman Admin
Deskripsi Use Case Diagram Otentifikasi Admin Tabel IV.10.
Deskripsi Use Case Diagram Otentifikasi Halaman Admin
Use Case Name Otentifikasi Admin
Requirements E1
Goal Admin dapat login dan logout.
Post-conditions Admin berhasil login.
Failed end condition Admin gagal login.
Primary Actors Admin
Main Flow/Basic Path 1. Admin telah melakukan login.
2. Sistem melakukan otentifikasi. 3. Admin berhasil login.
Alternative Flow /Invariant 1
1. Admin melakukan logout. 2. Sistem melakukan otentifikasi. 3. Admin berhasil logout.
3. Use Case Diagram Melihat Beranda Dan Mengubah Profil Akun Halaman Admin
Gambar IV.14.
Use Case Diagram Melihat Beranda Dan Mengubah Profil Akun
Halaman Admin
Deskripsi Use Case Diagram Melihat Beranda Dan Mengubah Profil Akun Halaman Admin
Tabel IV.11.
Deskripsi Use Case Diagram Melihat Beranda Dan Mengubah Profil Akun Halaman Admin
Use Case Name Melihat Beranda Dan Mengubah Profil Akun
Halaman Admin
Requirements E2
Goal Admin dapat melihat beranda yang berisi profil admin
Pre-conditions Admin telah melakukan login.
Post-conditions Data admin yang login berhasil diperbarui.
Failed end condition Data admin yang login gagal diperbarui.
Primary Actors Admin
Main Flow/Basic Path 1. Admin melihat profil admin di beranda.
2. Admin memilih tombol “Edit Profil”. 3. Sistem menampilkan form profil. 4. Admin mengedit profil.
5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Admin melihat profil admin di beranda. 2. Admin memilih tombol “Ubah Password”. 3. Sistem menampilkan form profil.
4. Admin mengubah password. 5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
4. Use Case Diagram Mengelola Data Kategori Halaman Admin
Gambar IV.15.
Use Case Diagram Mengelola Data Kategori Halaman Admin
Deskripsi Use Case Diagram Mengelola Data Kategori Halaman Admin Tabel IV.12.
Deskripsi Use Case Diagram Mengelola Data Kategori Halaman Admin
Use Case Name Mengelola Data Kategori Halaman Admin
Requirements E3
Goal Admin dapat tambah, edit, hapus dan simpan.
Pre-conditions Admin telah melakukan login.
Post-conditions Data kategori berhasil disimpan, diperbarui dan
Failed end condition Data kategori gagal disimpan, diperbarui dan dihapus.
Primary Actors Admin
Main Flow/Basic Path 1. Admin melihat data kategori.
2. Admin memilih tombol “Tambah Data”. 3. Sistem menampilkan form data kategori. 4. Admin memasukkan data kategori. 5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Admin melihat data kategori.
2. Admin memilih data kategori yang ingin diedit, kemudian pilih tombol “Edit Data”.
3. Sistem menampilkan form data kategori. 4. Admin mengedit data kategori.
5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 2
1. Admin melihat data kategori.
2. Admin memilih data kategori yang ingin dihapus, kemudian pilih tombol “Hapus Data”.
3. Sistem menghapus data.
5. Use Case Diagram Mengelola Data Informasi Halaman Admin
Gambar IV.16.
Deskripsi Use Case Diagram Mengelola Data Informasi Halaman Admin Tabel IV.13.
Deskripsi Use Case Diagram Mengelola Data Informasi Halaman Admin
Use Case Name Mengelola Data Informasi Halaman Admin
Requirements E4
Goal Admin dapat tambah, edit, hapus dan simpan.
Pre-conditions Admin telah melakukan login.
Post-conditions Data informasi berhasil disimpan, diperbarui dan
dihapus.
Failed end condition Data informasi gagal disimpan, diperbarui dan
dihapus.
Primary Actors Admin
Main Flow/Basic Path 1. Admin melihat data informasi.
2. Admin memilih tombol “Tambah Data”. 3. Sistem menampilkan form data informasi. 4. Admin memasukkan data informasi. 5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Admin melihat data informasi.
2. Admin mengisi nama informasi di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data informasi yang dicari. 5. Admin memilih data informasi yang ingin diedit,
kemudian pilih tombol “Edit Data”. 6. Sistem menampilkan form data informasi. 7. Admin mengedit data informasi.
8. Admin memilih tombol “Simpan”. 9. Sistem menyimpan data.
Alternative Flow /Invariant 2
1. Admin melihat data informasi.
2. Admin mengisi nama informasi di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data informasi yang dicari. 5. Admin memilih data informasi yang ingin dihapus,
kemudian pilih tombol “Hapus Data”. 6. Sistem menghapus data.
6. Use Case Diagram Mengelola Data Admin Halaman Admin
Gambar IV.17.
Use Case Diagram Mengelola Data Admin Halaman Admin
Deskripsi Use Case Diagram Mengelola Data Admin Halaman Admin Tabel IV.14.
Deskripsi Use Case Diagram Mengelola Data Admin Halaman Admin
Use Case Name Mengelola Data Admin Halaman Admin
Requirements E5
Goal Admin dapat tambah, edit, hapus dan simpan.
Pre-conditions Admin telah melakukan login.
Post-conditions Data admin berhasil disimpan dan dihapus.
Failed end condition Data admin gagal disimpan dan dihapus.
Primary Actors Admin
Main Flow/Basic Path 1. Admin melihat data admin.
2. Admin memilih tombol “Tambah Data”. 3. Sistem menampilkan form data admin. 4. Admin memasukkan data admin. 5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Admin melihat data admin.
2. Admin memilih data admin yang ingin dihapus, kemudian pilih tombol “Hapus Data”.
7. Use Case Diagram Mengelola Data Pendaftar Halaman Admin
Gambar IV.18.
Use Case Diagram Mengelola Data Pendaftar Halaman Admin
Deskripsi Use Case Diagram Mengelola Data Pendaftar Halaman Admin Tabel IV.15.
Deskripsi Use Case Diagram Mengelola Data Pendaftar Halaman Admin
Use Case Name Mengelola Data Pendaftar Halaman Admin
Requirements E6
Goal Admin dapat melihat detail dan hapus.
Pre-conditions Admin telah melakukan login.
Post-conditions Data pendaftar berhasil dilihat detailnya dan dihapus.
Failed end condition Data pendaftar gagal dilihat detailnya dan dihapus.
Primary Actors Admin
Main Flow/Basic Path 1. Admin melihat data pendaftar.
2. Admin mengisi nama pendaftar di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data pendaftar yang dicari. 5. Admin memilih data pendaftar yang ingin dilihat
detailnya, kemudian pilih tombol “Detail”. 6. Sistem menampilkan form detail.
Alternative Flow /Invariant 1
1. Admin melihat data pendaftar.
2. Admin mengisi nama pendaftar di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data pendaftar yang dicari. 5. Admin memilih data pendaftar yang ingin dihapus,
kemudian pilih tombol “Hapus Data”. 6. Sistem menghapus data.
8. Use Case Diagram Mengelola Data Siswa Halaman Admin
Gambar IV.19.
Use Case Diagram Mengelola Data Siswa Halaman Admin
Deskripsi Use Case Diagram Mengelola Data Siswa Halaman Admin Tabel IV.16.
Deskripsi Use Case Diagram Mengelola Data Siswa Halaman Admin
Use Case Name Mengelola Data Siswa Halaman Admin
Requirements E7
Goal Admin dapat tambah, edit, hapus dan simpan.
Pre-conditions Admin telah melakukan login.
Post-conditions Data siswa berhasil disimpan, diperbarui dan dihapus.
Failed end condition Data siswa gagal disimpan, diperbarui dan dihapus.
Primary Actors Admin
Main Flow/Basic Path 1. Admin melihat data siswa.
2. Admin memilih tombol “Tambah Data”. 3. Sistem menampilkan form data siswa. 4. Admin memasukkan data siswa. 5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Admin melihat data siswa.
2. Admin mengisi no.formulir di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data siswa yang dicari. 5. Admin memilih data siswa yang ingin diedit,
kemudian pilih tombol “Edit Data”. 6. Sistem menampilkan form data siswa. 7. Admin mengedit data siswa.
8. Admin memilih tombol “Simpan”. 9. Sistem menyimpan data.
Alternative Flow /Invariant 2
1. Admin melihat data siswa.
2. Admin mengisi no.formulir di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data siswa yang dicari. 5. Admin memilih data siswa yang ingin dihapus,
kemudian pilih tombol “Hapus Data”. 6. Sistem menghapus data.
9. Use Case Diagram Mengelola Data Tentor Halaman Admin
Gambar IV.20.
Deskripsi Use Case Diagram Mengelola Data Tentor Halaman Admin Tabel IV.17.
Deskripsi Use Case Diagram Mengelola Data Tentor Halaman Admin
Use Case Name Mengelola Data Tentor Halaman Admin
Requirements E8
Goal Admin dapat tambah, edit, hapus dan simpan.
Pre-conditions Admin telah melakukan login.
Post-conditions Data tentor berhasil disimpan, diperbarui dan dihapus.
Failed end condition Data tentor gagal disimpan, diperbarui dan dihapus.
Primary Actors Admin
Main Flow/Basic Path 1. Admin melihat data tentor.
2. Admin memilih tombol “Tambah Data”. 3. Sistem menampilkan form data tentor. 4. Admin memasukkan data tentor. 5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Admin melihat data tentor.
2. Admin mengisi nama tentor di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data tentor yang dicari. 5. Admin memilih data tentor yang ingin diedit,
kemudian pilih tombol “Edit Data”. 6. Sistem menampilkan form data tentor. 7. Admin mengedit data tentor.
8. Admin memilih tombol “Simpan”. 9. Sistem menyimpan data.
Alternative Flow /Invariant 2
1. Admin melihat data tentor.
2. Admin mengisi nama tentor di form pencarian. 3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data tentor yang dicari. 5. Admin memilih data tentor yang ingin dihapus,
kemudian pilih tombol “Hapus Data”. 6. Sistem menghapus data.
10. Use Case Diagram Mengelola Data Program Bimbel Halaman Admin
Gambar IV.21.
Use Case Diagram Mengelola Data Program Bimbel Halaman Admin
Deskripsi Use Case Diagram Mengelola Data Program Bimbel Halaman Admin
Tabel IV.18.
Deskripsi Use Case Diagram Mengelola Data Program Bimbel Halaman Admin
Use Case Name Mengelola Data Program Bimbel Halaman Admin
Requirements E9
Goal Admin dapat tambah, edit, hapus dan simpan.
Pre-conditions Admin telah melakukan login.
Post-conditions Data program bimbel berhasil disimpan, diperbarui dan
dihapus.
Failed end condition Data program bimbel gagal disimpan, diperbarui dan
Main Flow/Basic Path 1. Admin melihat data program bimbel. 2. Admin memilih tombol “Tambah Data”. 3. Sistem menampilkan form data program bimbel. 4. Admin memasukkan data program bimbel. 5. Admin memilih tombol “Simpan”. 6. Sistem menyimpan data.
Alternative Flow /Invariant 1
1. Admin melihat data program bimbel.
2. Admin mengisi jenis program bimbel di form pencarian.
3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data program bimbel yang dicari.
5. Admin memilih data program bimbel yang ingin diedit, kemudian pilih tombol “Edit Data”. 6. Sistem menampilkan form data program bimbel. 7. Admin mengedit data program bimbel.
8. Admin memilih tombol “Simpan”. 9. Sistem menyimpan data.
Alternative Flow /Invariant 2
1. Admin melihat data program bimbel.
2. Admin mengisi jenis program bimbel di form pencarian.
3. Admin memilih tombol “Cari”.
4. Sistem menampilkan data program bimbel yang dicari.
5. Admin memilih data program bimbel yang ingin