4.3.1 Use-case Narrative Design
Use-case narrative design adalah sebuah narasi tentang kegiatan yang
dilakukan oleh pengguna dalam sistem serta respon yang diberikan oleh sistem sesuai dengan yang terjadi pada perangkat lunak sistem informasi pencatatan
keuangan PATTIRO.
Tabel 4.17 Use-case Narrative Design Login
USE CASE NAME: Login
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Kasir • Manajer Keuangan
• Direktur Eksekutif
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses login yang dilakukan
oleh Kasir, Manajer Keuangan dan Direktur Eksekutif untuk melakukan pekerjaan yang bersangkutan.
PRE-CONDITION: Pengguna belum masuk ke dalam sistem.
TRIGGER: Pengguna ingin melakukan pekerjaan yang bersangkutan
dengan penerimaan dan pengeluaran kas.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Pengguna mengisi username
dan password pada textbox
yang tersedia.
Step 2: Sistem merespon dengan menampilkan
alert login berhasil dan
menampilkan halaman home
.
Step 3: Pengguna dapat melakukan kegiatan yang
bersangkutan dengan penerimaan dan pengeluaran kas.
ALTERNATE COURSES:
Alt-Step 2: Jika pengguna salah dalam memasukkan username dan atau password. Sistem akan menampilkan halaman login
kembali dengan pemberitahuan bahwa login tidak berhasil dan memberitahukan kesalahan pengguna.
CONCLUSION: Use-case
ini selesai saat pengguna tersebut masuk ke dalam
sistem
POST-CONDITION: User
dapat melakukan operasi yang berhubungan dengan penerimaan dan pengeluaran kas
BUSINESS RULES •
Hanya Kasir, Manajer Keuangan, dan Direktur Eksekutif yang dapat masuk ke sistem.
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS -
ASSUMPTIONS: -
OPEN ISSUES: -
Tabel 4.18 Use-case Narrative Design Input Penerimaan Kas
USE CASE NAME: Input Penerimaan Kas
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Kasir
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses input penerimaan kas
yang dilakukan oleh Kasir.
PRE-CONDITION:
• Kasir telah masuk ke dalam sistem. • Kasir menerima sumbangan dana dari penyumbang
TRIGGER: Kasir menerima sumbangan dana dari penyumbang.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Kasir memilih menu Tambah Penerimaan Kas.
Step 2: Sistem memberikan respon
dengan menampilkan form
tambah penerimaan kas.
Step 3: Kasir memasukkan data penerimaan kas melalui keyboard
kemudian meng-klik tombol simpan.
Step 4: Sistem merespon dengan menyimpan data
dalam database kemudian menampilkan semua
penerimaan kas yang ada dalam database.
ALTERNATE COURSES:
Alt-Step 2: Kasir dapat melakukan pencarian data penerimaan kas dengan memasukkan kata kunci dan meng-klik tombol
cari. Alt-Step 3: Sistem akan merespon dengan menampilkan data
sesuai kata kunci yang dimasukkan kasir atau informasi bahwa data tidak ditemukan.
CONCLUSION: Use-case
ini selesai saat Kasir telah memasukkan data penerimaan kas.
POST-CONDITION: -
BUSINESS RULES -
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS ASSUMPTIONS:
- OPEN ISSUES:
-
Tabel 4.19 Use-case Narrative Design Input Pengeluaran Kas
USE CASE NAME: Input Pengeluaran Kas
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Kasir
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses input pengeluaran kas
yang dilakukan oleh Kasir.
PRE-CONDITION:
• Kasir telah masuk ke dalam sistem. • Kasir mendapatkan permintaan pengeluaran dana
TRIGGER: Kasir mendapatkan permintaan pengeluaran dana
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Kasir memilih menu Tambah Pengeluaran Kas.
Step 2: Sistem memberikan respon
dengan menampilkan form
tambah pengeluaran kas.
Step 3: Kasir memasukkan data pengeluaran kas melalui keyboard
kemudian meng-klik tombol simpan.
Step 4: Sistem merespon dengan menyimpan data
dalam database kemudian menampilkan semua
pengeluaran kas yang ada dalam database.
ALTERNATE COURSES:
Alt-Step 2: Kasir dapat melakukan pencarian data pengeluaran kas dengan memasukkan kata kunci dan meng-klik tombol
cari. Alt-Step 3: Sistem akan merespon dengan menampilkan data
sesuai kata kunci yang dimasukkan kasir atau informasi bahwa data tidak ditemukan.
CONCLUSION: Use-case
ini selesai saat Kasir telah memasukkan data pengeluaran kas.
POST-CONDITION: -
BUSINESS RULES -
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS ASSUMPTIONS:
- OPEN ISSUES:
-
Tabel 4.20 Use-case Narrative Design Persetujuan Penerimaan Kas
USE CASE NAME: Persetujuan Penerimaan Kas
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Manajer Keuangan
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses persetujuan data
penerimaan kas yang sebelumnya telah di-input oleh kasir.
PRE-CONDITION:
• Manajer Keuangan telah masuk ke dalam sistem. • Kasir telah memasukkan data penerimaan kas.
TRIGGER: Kasir ingin mencetak bukti penerimaan kas.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Manajer Keuangan memilih menu Penerimaan Kas.
Step 2: Sistem memberikan respon
dengan menampilkan semua data penerimaan
kas.
Step 3: Manajer Keuangan meng- klik icon penerimaan kas baru di
slah satu data penerimaan kas. Step 4: Sistem merespon
dengan menampilkan form
persetujuan penerimaan kas.
Step 5: Manajer Keuangan memilih radio button antara
diterima, revisi, atau ditolak. Dan memberi keterangan pada
masing-masing pilihan. Step 5: Sistem merespon
dengan menampilkan kembali semua data
penerimaan kas dengan perubahan pada icon-nya.
ALTERNATE COURSES:
Alt-Step 2: Jika manajer keuangan memilih revisi pada radio button
. Maka kasir akan merivisi penerimaan kas dan manajer
keuangan kembali melakukan persetujuan.
CONCLUSION: Use-case
ini selesai saat Manajer Keuangan telah memilih status persetujuan data penerimaan kas.
POST-CONDITION: -
BUSINESS RULES -
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS ASSUMPTIONS:
- OPEN ISSUES:
-
Tabel 4.21 Use-case Narrative Design Persetujuan Pengeluaran Kas
USE CASE NAME: Persetujuan Pengeluaran Kas
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Manajer Keuangan • Direktur Eksekutif
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses persetujuan data
pengeluaran kas yang sebelumnya telah di-input oleh kasir.
PRE-CONDITION:
• Manajer Keuangan dan Direktur Eksekutif telah masuk ke dalam sistem.
• Kasir telah memasukkan data pengeluaran kas.
TRIGGER: Kasir ingin mencetak bukti penerimaan kas.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Manajer Keuangan dan Direktur Eksekutif memilih menu
Pengeluaran Kas. Step 2: Sistem
memberikan respon dengan menampilkan
semua data pengeluaran kas.
Step 3: Manajer Keuangan dan Direktur Eksekutif meng-klik
icon pengeluaran kas baru di
salah satu data pengeluaran kas.
Step 4: Sistem merespon dengan menampilkan
form persetujuan
pengeluaran kas.
Step 5: Manajer Keuangan dan Direktur Eksekutif memilih radio
button antara diterima, revisi, atau
ditolak. Dan memberi keterangan pada masing-masing pilihan.
Step 5: Sistem merespon dengan menampilkan
kembali semua data pengeluaran kas dengan
perubahan pada icon-nya.
ALTERNATE COURSES:
Alt-Step 2: Jika manajer keuangan dan atau Direktur Eksekutif memilih revisi pada radio button. Maka kasir akan merivisi
penerimaan kas dan manajer keuangan dan direktur eksekutif kembali melakukan persetujuan.
CONCLUSION: Use-case
ini selesai saat Manajer Keuangan telah memilih status persetujuan data penerimaan kas.
POST-CONDITION: -
BUSINESS RULES - Direktur Eksekutif tidak dapat melakukan persetujuan
sebelum manajer keuangan.
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS ASSUMPTIONS:
- OPEN ISSUES:
-
Tabel 4.22 Use-case Narrative Design Cetak Penerimaan Kas
USE CASE NAME: Cetak Penerimaan Kas
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Kasir
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses yang dilakukan oleh
Kasir dalam mencetak bukti penerimaan kas yang sebelumnya telah disetujui oleh Manajer Keuangan
PRE-CONDITION:
• Kasir telah login ke dalam sistem. • Manajer Keuangan telah menyetujui data penerimaan kas
yang sebelumnya dimasukkan oleh kasir.
TRIGGER: Kasir ingin melakukan pencetakan bukti pengeluaran kas.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Kasir memilih menu penerimaan kas.
Step 2: Sistem menampilkan semua data
penerimaan kas.
Step 3: Kasir memilih icon cetak penerimaan kas.
Step 4: Sistem menampilkan format bukti
penerimaan kas yang akan dicetak.
Step 5: Kasir memilih icon untuk mencetak.
Step 6: Sistem merespon dengan mencetak bukti
penerimaan kas.
ALTERNATE COURSES:
-
CONCLUSION: Use-case
ini selesai saat Kasir telah mencetak bukti
penerimaan kas.
POST-CONDITION: Bukti penerimaan kas telah dicetak.
BUSINESS RULES -
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS -
ASSUMPTIONS: •
Pemasukkan data penerimaan kas merupakan bagian terpisah dari use-case ini.
OPEN ISSUES: -
Tabel 4.23 Use-case Narrative Design Cetak Pengeluaran Kas
USE CASE NAME: Cetak Pengeluaran Kas
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Kasir
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses yang dilakukan oleh
Kasir dalam mencetak bukti pengeluaran kas yang sebelumnya telah disetujui oleh Manajer Keuangan
PRE-CONDITION:
• Kasir telah login ke dalam sistem. • Manajer Keuangan telah menyetujui data pengeluaran kas
yang sebelumnya dimasukkan oleh kasir.
TRIGGER: Kasir ingin melakukan pencetakan bukti pengeluaran kas.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Kasir memilih menu pengeluaran kas.
Step 2: Sistem menampilkan semua data
pengeluaran kas.
Step 3: Kasir memilih icon cetak pengeluaran kas.
Step 4: Sistem menampilkan format bukti
pengeluaran kas yang akan dicetak.
Step 5: Kasir memilih icon untuk mencetak.
Step 6: Sistem merespon dengan mencetak bukti
pengeluaran kas.
ALTERNATE COURSES:
-
CONCLUSION: Use-case
ini selesai saat Kasir telah mencetak bukti pengeluaran kas.
POST-CONDITION: Bukti pengeluaran kas telah dicetak.
BUSINESS RULES -
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS -
ASSUMPTIONS: •
Pemasukkan data pengeluaran kas merupakan bagian terpisah dari use-case ini.
OPEN ISSUES: -
Tabel 4.24 Use-case Narrative Design Lihat Laporan Keuangan
USE CASE NAME: Lihat Laporan Keuangan
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Manajer Keuangan
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses yang dilakukan oleh
Manajer Keuangan untuk melihat Laporan Keuangan yang telah dibuat oleh sistem
PRE-CONDITION:
• Manajer Keuangan telah masuk ke dalam sistem. • Kasir telah memasukkan data penerimaan dan pengeluaran
kas dengan periode tertentu.
TRIGGER:
Manajer Keuangan ingin melihat Laporan Keuangan dengan periode tertentu.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Manajer Keuangan memilih menu laporan keuangan
dan klasifikasi laporan yang diinginkan [laporan penerimaan
kas, laporan pengeluaran kas, laporan aktivitas kas, laporan
dana, Grafik perbandingan penerimaan dan pengeluaran].
Laporan dapat dilihat per waktu yang diinginkan.
Step 2: Sistem menampilkan laporan
keuangan yang diinginkan Manajer keuangan
berdasarkan pilihan.
ALTERNATE COURSES:
Alt-Step 2: Jika Kasir belum memasukkan data sesuai periode yang diinginkan. Sistem akan menampilkan informasi bahwa
data yang diinginkan tidak tersedia.
CONCLUSION: Use-case
ini selesai saat Manajer Keuangan telah mendapatkan laporan keuangan yang diinginkan.
POST-CONDITION:
Manajer Keuangan telah melihat laporan keuangan yang diinginkan.
BUSINESS RULES •
Laporan keuangan yang akan dijadikan pedoman bagi Manajer Keuangan untuk membuat keputusan keuangan
seperti menyetujui atau tidak penerimaan dan pengeluaran kas.
IMPLEMENTATION CONTRAINTS AND
SPECIFICATIONS •
Laporan Keuangan dapat dicetak langsung oleh sistem.
ASSUMPTIONS: -
OPEN ISSUES: -
Tabel 4.25 Use-case Narrative Design Lihat Laporan Saldo Sisa
USE CASE NAME: Lihat Laporan Saldo Sisa
USE CASE TYPE USE CASE ID:
System Design :
PRIORITY: SOURCE:
PRIMARY BUSINESS ACTOR:
• Direktur Eksekutif
OTHER PARTICIPATING
ACTORS: OTHER INTERESTED
STAKEHOLDERS: DESCRIPTION:
Use-case ini menjelaskan tentang proses yang dilakukan oleh
Direktur Eksekutif untuk melihat Laporan Saldo Sisa yang telah dibuat oleh sistem
PRE-CONDITION:
• Direktur Eksekutif telah masuk ke dalam sistem. • Kasir telah memasukkan data penerimaan dan pengeluaran
kas dengan periode tertentu.
TRIGGER: Direktur Eksekutif ingin melihat Laporan Saldo Sisa.
TYPICAL COURSE Actor Action
System Response OF EVENTS:
Step 1: Direktur Eksekutif memilih menu Laporan Saldo
Sisa Step 2: Sistem
menampilkan jumlah saldo secara keseluruhan.
ALTERNATE COURSES:
Alt-Step 2: Jika Direktur Eksekutif belum login. Sistem akan meminta Direktur Eksekutif untuk melakukan login terlebih
dahulu.
CONCLUSION: Use-case
ini selesai saat Direktur Eksekutif telah mendapatkan laporan keuangan yang diinginkan.
POST-CONDITION: Direktur Eksekutif telah melihat Laporan Saldo Sisa yang
diinginkan.
BUSINESS RULES •
Laporan Saldo Sisa yang akan dijadikan pedoman bagi Direktur Eksekutif untuk membuat keputusan keuangan
seperti menyetujui atau tidak penerimaan dan pengeluaran kas.
IMPLEMENTATION •
Laporan Saldo Sisa dapat dicetak langsung oleh sistem.
CONTRAINTS AND SPECIFICATIONS
ASSUMPTIONS: -
OPEN ISSUES: -
4.3.2 Sequence Diagram
Kategori