• Tidak ada hasil yang ditemukan

ANALISIS DAN PERANCANGAN SISTEM

BATASAN SISTEM

3.4 Requirement Analysis

3.4.3 Use Case Narrative

Use Case Name : Mencatat data transaksi

penjualan Use Case Type

BussinessRequirements :System Analysis : □ System Design :  Use Case ID : 1 Prioritys : Source :

Actors : Pemilik, karyawan

Description : Use case ini menggambarkan tentang pemilik/karyawan melakukan proses pencatatan data penjualan barang kepada konsumen (konsumen membeli barang banyak).

Precondition : Barang yang diinginkan konsumen sudah ada di inventori. Typical Course of

Events : (a)

Actor Action System Response

Langkah 1 : konsumen datang membawa catatan barang yang dibutuhkannya untuk kemudian diberikan kepada karyawan / pemilik. Langkah 2 : setelah barang yang diinginkan ketemu, konsumen datang ke kasir untuk membayar barang tersebut.

Langkah 2 : pemilik melakukan penginputan data barang yang dibeli oleh konsumen.

Langkah 3 : pemilik / karyawan melakukan proses pencatatan data transaksi penjualan ke dalam sistem.

Langkah 4 : confirmasi pencatatan data transaksi penjualan.

Langkah 5 : sistem akan menyediakan fasilitas untuk mencetak data transaksi penjualan yang telah dilakukan.

Alternate Courses : -

Postcondition : Data penjualan sudah tercatat dalam database.

Use Case Name : Mencatat data transaksi

penjualan Use Case Type

BussinessRequirements :

System Analysis : □

Use Case ID : 2 Prioritys :

Source : System Design :  Actors : Pemilik, karyawan

Description : Use case ini menggambarkan tentang pemilik/karyawan melakukan proses pencatatan data penjualan barang kepada konsumen ( konsumen membeli barang hanya sedikit). Precondition : Barang yang diinginkan konsumen sudah ada di inventori. Typical Course of

Events : (b)

Actor Action System Response

Langkah 1 : ketika konsumen banyak, dan ada konsumen datang menanyakan barang yang dicarinya (hanya sedikit barang yang dibeli).

Langkah 2 : pemilik memberikan barang yang dicari.

Langkah 3 : konsumen datang ke kasir untuk membayar barang tersebut.

Langkah 4 :

pemilik/karyawan mencatat data yang dibeli dalam kertas.

Langkah 5 : ketika toko sedang sepi, pemilik / karyawan melakukan proses pencatatan data transaksi penjualan ke dalam sistem.

Langkah 4 : confirmasi pencatatan data transaksi penjualan.

Langkah 5 : sistem akan menyediakan fasilitas untuk mencetak data transaksi penjualan yang telah dilakukan.

Alternate Courses : -

Use Case Name : Mencatat data retur penjualan Use Case Type Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 3 Prioritys : Source :

Actors : Pemilik, karyawan

Description : Use case ini menggambarkan konsumen yang meretur barang yang dibeli akibat kesalahan yang tidak disenggaja. Precondition : Konsumen salah menerima barang.

Typical Course of Events :

(a)

Actor Action System Response

Langkah 1 : konsumen datang ke toko untuk meretur barang.

Langkah 2 : pemilik/karyawan

melakukan proses pencatatan ke dalam sistem retur penjualan.

Langkah 6 : konsumen menerima barang pengganti.

Langkah 3 : konfirmasi pencatatan data retur penjualan.

Langkah 4 : menampilkan informasi data retur (tanggal retur, kode barang, nama barang, dan lain-lain).

Langkah 5 : sistem akan menyediakan fasilitas untuk mencetak data retur penjualan yang telah dilakukan.

Alternate Courses : -

Use Case Name : Menghapus data penjualan Use Case Type Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 4 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik melakukan proses penghapusan data penjualan. Karena kesalahan proses transaksi penjualan.

Precondition : Kesalahan data penjualan yang terlajur diproses masih berada dalam database.

Typical Course of Events :

Actor Action System Response

Langkah 1 : pemilik melakukan pencarian data penjualan yang ingin dihapus.

Langkah 3 : pemilik memberi perintah kepada sistem untuk menghapus data penjualan.

Langkah 2 : sistem menampilkan data yang dicari oleh pemilik.

Langkah 4 : sistem

menkonfirmasikan perintah yang dilakukan pemilik. Alternate Courses : -

Postcondition : Data penjualan sudah dihapus dari database.

Use Case Name : Pencarian data Barang Use Case Type

Bussiness Requirements :

Use Case ID : 5 Prioritys :

Source : System Analysis : □ System Design : 

Actors : Pemilik, karyawan

Description : Use case ini menggambarkan tentang konsumen yang menanyakan informasi barang yang akan dibelinya dan pemilik/karyawan melakukan pencarian informasi data penjualan tersebut.

Precondition : Daftar barang yang dicari sudah tercatat di inventori. Typical Course of

Events :

Actor Action System Response

Langkah 1 : konsumen menanyakan barang yang dibutuhkannya berikut harganya.

Langkah 2 :

pemilik/karyawan

memasukkan kata kunci pencarian barang yang akan dicari.

Langkah 4 : sistem mencari data dalam database.

Langkah 3 : sistem menampilkan informasi data barang yang dicari.

Alternate Courses : -

Postcondition : Konsumen memperoleh informasi barang yang dicari.

Use Case Name : Pemesanan barang Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 6 Prioritys : Source :

Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik melakukan pemesanan barang ke distributor.

Precondition : Barang sudah ada di inventori Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik mengecek stok barang pada sistem.

Langkah 3 : pemilik

memasukkan data

pemesanan barang.

Langkah 5 : pemilik memberikan data pemesanan yang telah dicetak kepada distributor.

Langkah 2 : sistem menampilkan data stok barang.

Langkah 4 : konfirmasi

penyimpanan data

pemesanan dan pencetakkan data pesanan.

Alternate Courses : - Postcondition : -

Use Case Name : Mencatat data retur pembelian Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 7 Prioritys : Source :

Description : Use case ini menggambarkan tentang pemilik/karyawan yang meretur barang ke suplier. Karena barang rusak/sudah kadarluarsa.

Precondition : Barang diinventori mengalami kerusakan atau kadarluarsa. Typical Course of

Events :

Actor Action System Response

Langkah 1 :

pemilik/karyawan

memasukkan data barang yang akan diretur ke distributor ke dalam sistem.

Langkah 2 : konfirmasi pencatatan data retur.

Langkah 3 : menampilkan informasi data retur (kode barang, nama barang, dan lain-lain).

Langkah 4 : sistem menyediakan fasilitas untuk mencetak data retur pembelian.

Alternate Courses : -

Postcondition : Data retur pembelian tercatat dalam database.

Use Case Name : Pencarian data pembelian Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 8 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik/karyawan yang mencari data pembelian barang.

Precondition : Barang sudah bertambah di inventori Typical Course of

Events :

Actor Action System Response

Langkah 1 :

pemilik/karyawan

memasukkan kata kunci pencarian data pembelian ke dalam sistem.

Langkah 2 : sistem akan menampilkan informasi pencarian data pembelian yang dicari.

Alternate Courses : - Postcondition : -

Use Case Name : Mencatat data pembelian Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 9 Prioritys : Source :

Actors : Pemilik, karyawan

Description : Use case ini menggambarkan tentang pemilik/karyawan yang mencatat data pembelian barang dari distributor. Precondition : Barang datang dari distributor

Typical Course of Events :

Actor Action System Response

Langkah 1 : pemilik / karyawan mencatat data dan informasi barang yang dibeli dari distributor ke dalam sistem.

Langkah 2 : sistem menampilkan konfirmasi

pencatatan data pembelian.

Alternate Courses : -

Postcondition : Data pembelian disimpan didalam database.

Use Case Name : Mencatat data distributor Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 10 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang mendata semua distributor yang melakukan transaksi pembelian dengan toko.

Precondition : Semua pemasok barang yang ada diinventori. Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik memasukkan data distributor kedalam sistem.

Langkah 2 : sistem memberikan konfirmasi

penyimpanan data

distributor.

Langkah 3 : data distributor baru ditampilkan pada sistem.

Postcondition : Data distributor tersimpan dalam database.

Use Case Name : Mengubah data distributor Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 11 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang

mengubah data suplier karena terdapat informasi distributor yang berubah

Precondition : Distributor datang memberikan informasi perubahan data distributor.

Typical Course of Events :

Actor Action System Response

Langkah 1 : pemilik melakukan pencarian data distributor yang ingin dirubah.

Langkah 3 : pemilik melakukan perubahan data distributor pada sistem.

Langkah 2 : sistem mengecek dalam database

dan memberikan informasi data distributoryang dicari.

Langkah 2 : sistem memberikan konfirmasi perubahan data distributor. Alternate Courses : -

Postcondition : Data distributor telah dirubah.

Use Case ID : 12 Bussiness Requirements : System Analysis : □ System Design :  Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang mencari data distributor untuk kepentingan pemesanan barang. Precondition : pemilik ingin memesan barang, tapi lupa distributornya. Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik memasukkan kata kunci pencarian data distributor.

Langkah 2 : sistem menampilkan informasi data distributor yang dicari. Alternate Courses : -

Postcondition : -

Use Case Name : Membuat data karyawan baru Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 13 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang membuatkan account kepada karyawan baru agar dapat mengakses sistem.

Typical Course of Events :

Actor Action System Response

Langkah 1 : pemilik menginputkan data-data karyawan baru (nama, alamat, username, passwod, dan lain-lain).

Langkah 2 : konfirmasi pencatatan data karyawan. Langkah 3 : menampilkan informasi data karyawan. Alternate Courses : -

Postcondition : Data karyawan baru tersimpan dalam database.

Use Case Name : Mengubah data karyawan Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 14 Prioritys : Source :

Actors : Pemilik, karyawan

Description : Use case ini menggambarkan tentang pemilik yang mengubah data karyawan karena pindah rumah, ganti telepon, password dan lain-lain.

Precondition : Data karyawan lama masih tersimpan dalam database. Typical Course of

Events :

Actor Action System Response

Langkah 1 :

pemilik/karyawan

menginputkan data karyawan yang ingin diubah.

Langkah 2 : konfirmasi perubahan data karyawan

karyawan.

Langkah 3 : menampilkan informasi perubahan data.

Alternate Courses : -

Postcondition : Data karyawan telah berubah.

Use Case Name : Menghapus data karyawan Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 15 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang menghapus hak akses karyawan karena karyawan yang bersangkutan sudah tidak bekerja lagi di Toko Ijo. Precondition : Data karyawan yang sudah tidak bekerja masih tersimpan

dalam database.

Typical Course of Events :

Actor Action System Response

Langkah 1 : pemilik memilih data karyawan yang ingin dihapus.

Langkah 2 : sistem memberikan konfirmasi penghapusan data karyawan. Alternate Courses : -

Use Case Name : Mengecek data inventori

barang Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 16 Prioritys : Source :

Actors : Pemilik, karyawan

Description : Use case ini menggambarkan tentang pemilik yang mengecek inventori barang.

Precondition : Pemilik ingin mengetahui informasi inventori barang. Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik / karyawan memasukkan kata kunci barang yang akan dicek data inventorinya.

Langkah 2 : sistem menampilkan data inventori yang dicari.

Alternate Courses : - Postcondition : -

Use Case Name : Mencatat data inventori baru Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 17 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang mencatat data barang baru ke dalam inventori.

Precondition : Pemilik ingin mencatat data inventori baru. Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik mencatat data dan informasi barang baru pada inventori.

Langkah 2 : konfirmasi pencatatan data inventori. Langkah 3 : sistem menampilkan informasi data inventori baru.

Alternate Courses : -

Postcondition : Inventori barang bertambah.

Use Case Name : Mengubah data inventori

barang Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 19 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang mengubah data inventori barang .

Precondition : Pemilik ingin mengubah data inventori. Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik memasukan kata kunci pencarian data inventori

yang ingin diubah. Langkah 2 : sistem menampilkan data yang dicari.

Langkah 3 : pemilik mengubah data dan

informasi inventori barang. Langkah 4 : konfirmasi pengubahan data inventori.

Alternate Courses : -

Postcondition : Inventori barang berubah.

Use Case Name : Mengubah password admin Use Case Type

Bussiness Requirements : System Analysis : □ System Design :  Use Case ID : 20 Prioritys : Source : Actors : Pemilik

Description : Use case ini menggambarkan tentang pemilik yang mengubah password-nya .

Precondition : Pemilik ingin mengubah password admin. Typical Course of

Events :

Actor Action System Response

Langkah 1 : pemilik memasukan password lama.

Langkah 3 : pemilik memasukkan data password

baru.

Langkah 2 : sistem menampilkan validasi

password lama.

Langkah 4 : konfirmasi pengubahan data password

admin. Alternate Courses : -

Postcondition : Data password admin berubah.

3.5 Logical design

Dokumen terkait