Anda di halaman 1dari 157

PERANCANGAN SISTEM INFORMASI INVENTORI

PADA SALEMBA TOKO BUKU

Diajukan Untuk Memenuhi Syarat Kelulusan

Mata Kuliah Perancangan Sistem Informasi

DisusunOleh :

Aminatul Rosidah NPM 212.1.63.0016

Meli Amelia NPM 212.1.63.0014

AKADEMI MANAJEMEN INFORMATIKA DAN KOMPUTER

AMIK BOGOR

2014
LEMBAR PENGESAHAN

Perancangan Sistem Informasi Inventori

Pada Salemba Toko Buku

Untuk Nilai Akhir Mata Kuliah Perancangan Sistem Informasi

Disetujui oleh:

Pembimbing Mata Kuliah Ketua Program Studi

( Charmiyanti Nurkentjana Aju, S.Kom )

( Zulkarnaen NS, S.Kom)


Penguji I Penguji II

( Zulkarnaen NS, S.Kom) ( Zulkarnaen NS, S.Kom)


KATA PENGANTAR

Segala puji syukur penulis panjatkan kehadirat Allah SWT, karena atas limpahan

rahmat dan hidayah-Nya penulis dapat menyelesaikan Makalah Penelitian yang berjudul

“Perancangan Sistem Informasi Inventori Pada Salemba Toko Buku”. Makalah ini

disusun sebagai menyelesaikan mata kuliah Perancangan Sistem Informasi, jurusan

Manajemen Informatika di AMIK Bogor.

Dalam penyusunan Makalah ini penulis banyak mendapat saran, dorongan,

bimbingan dari berbagai pihak. Oleh karena itu dengan segala hormat dan kerendahan hati

perkenankanlah penulis mengucapkan terima kasih kepada :

1. Ibu Charmiyanti Nurkentjana Aju, S.Kom selaku Dosen Pengajar

sekaligus Dosen Pembimbing.

2. Bapak Zulkarnaen NS, S.Kom selaku ketua Program Studi.

3. Salemba Toko Buku selaku Objek Penelitian.

4. Semua pihak yang telah membantu penyelesaian makalah ini.

Penulis menyadari bahwa makalah yang penulis susun jauh dari kata sempurna,

untuk itu penulis mengharapkan kritik dan saran yang sifatnya membangun, dan tidak lupa

penulis ucapkan terima kasih atas segala perhatian dan penulis berharap semoga makalah ini

dapat bermanfaat bagi semua pihak.

Bogor, Oktober 2014

Penulis
DAFTAR ISI

LEMBAR PENGESAHAN ........................................................................................... i

KATA PENGANTAR ................................................................................................... ii

DAFTAR ISI................................................................................................................... iii

BAB I. PENDAHULUAN

1.1. Latar Belakang ........................................................................................ 1

1.2. Tujuan ..................................................................................................... 2

1.3. Sasaran .................................................................................................... 3

1.4. Manfaat ................................................................................................... 3

1.5. Batasan Masalah...................................................................................... 3

BAB II. LANDASAN TEORI

2.1 Teori Umum ............................................................................................ 5

2.1.1 Sistem Informasi ......................................................................... 5

2.1.2 Basis Data (Database) ................................................................. 7

2.1.2.1 Entity-Relationship Diagram (Diagram ERD) ................... 8

2.1.3 Unified Modeling Language (UML) ........................................... 10

2.1.3.1 Diagram Modeling Language (UML) ................................ 12


1. Usecase Diagram (Diagram Usecase) ................................... 12

2. Class Diagram (Diagram Kelas) ............................................ 17

3. Sequence Diagram (Diagram Aktivitas) ................................ 18

4. Aktivity Diagram ..................................................................... 19

5. Deployment Diagram ............................................................. 20

2.1.4 Feasibility Study (Studi Kelayakan) ............................................ 20

2.1.4.1 Operasional Feasibility (Kelayakan Operasional) ............... 21

2.1.4.2 Kelayakan Teknis ................................................................. 21

2.1.4.3 Kelayakan Jadwal ................................................................. 21

2.1.4.4 Kelayakan Ekonomis ............................................................ 21

2.1.5 ID Card dan Mesin EDC ............................................................... 22

2.1.6 Teknologi Barcode ........................................................................ 24

2.2 Jaringan Komputer ............................................................................. 27

2.2.1 Local Area Network (LAN) ........................................................ 27

2.2.2 Two Tier ...................................................................................... 28

2.3 MySQL .............................................................................................. 28

2.4 Visual Basic 2010 .............................................................................. 29

2.5 Objek Pengembangan ........................................................................ 30

2.6 Kerangka Pemikiran ........................................................................... 31

BAB III. ANALISA SISTEM

3.1 Jadwal Proyek .................................................................................... 32

3.2 Analisa Kelayakan Sistem .................................................................. 32


3.2.1 Kelayakan Ekonomi ................................................................... 32

3.2.2 Kelayakan Teknis ....................................................................... 38

3.2.3 Kelayakan Jadwal ....................................................................... 39

3.2.4 Kelayakan Operasional ............................................................... 40

3.3 Analisa Proses Bisnis yang Berjalan ................................................. 41

3.4 Analisa Proses Bisnis Sistem Baru yang Dikembangkan................... 42

3.5 Konstruksi Sistem yang Dikembangkan ........................................... 43

3.6 Skenario Sistem yang dikembangkan ................................................ 44

BAB IV. PERANCANGAN SISTEM

4.1 Diagram Konteks ............................................................................... 45

4.2 Daftar Istilah Pelaku Bisnis ................................................................ 46

4.3 Identifikasi Use Case ......................................................................... 47

4.4 Use Case Naratif ................................................................................ 48

4.4.1 Persyaratan Bisnis ................................................................. 48

4.4.1.1 Persyaratan Bisnis Login ........................................... 48

4.4.1.2 Persyaratan Bisnis Input Data Barang .......................

4.4.1.3 Persyaratan Bisnis Input Data Penerimaan Barang .... 49

4.4.1.4 Persyaratan Bisnis Penjualan Barang ......................... 49

4.4.1.5 Persyaratan Bisnis Pesanan Barang ........................... 50

4.4.1.6 Persyaratan Bisnis Return Barang .............................. 50

4.4.1.7 Persyaratan Bisnis Cek Harga .................................... 51


4.4.1.8 Persyaratan Bisnis Look Up Data Penerimaan

Barang ........................................................................ 51

4.4.1.9 Persyaratan Bisnis Look Up Data Penjualan Barang .52

4.4.1.10 Persyaratan Bisnis Look Up Data Persediaan

Barang ........................................................................ 52

4.4.1.11 Persyaratan Bisnis Look Up Data Pesanan Barang .. 53

4.4.1.12 Persyaratan Bisnis Look Up Data Return Barang ...... 53

4.4.1.13 Persyaratan Bisnis Update Data Penerimaan Barang. 54

4.4.1.14 Persyaratan Bisnis Update Data Pesanan Barang ...... 54

4.4.1.15 Persyaratan Bisnis Update Data Return Barang......... 55

4.4.1.16 Persyaratan Bisnis Cetak Laporan ............................. 55

4.4.1.17 Persyaratan Bisnis Cetak Struck Pembayaran............ 56

4.4.2 Analisa Sistem........................................................................ 56

4.4.2.1 Analisa Sistem Login ................................................. 56

4.4.2.2 Analisa Sistem Input Data Barang ..............................

4.4.2.3 Analisa Sistem Input Data Penerimaan Barang .......... 57

4.4.2.4 Analisa Sistem Penjualan Barang ............................... 59

4.4.2.5 Analisa Sistem Pesanan Barang ................................. 60

4.4.2.6 Analisa Sistem Return Barang .................................... 61

4.4.2.7 Analisa Sistem Cek Harga ........................................ 63

4.4.2.8 Analisa Sistem Look Up Data Penerimaan Barang .... 64

4.4.2.9 Analisa Sistem Look Up Data Penjualan Barang ...... 65

4.4.2.10 Analisa Sistem Look Up Data Persediaan Barang ..... 66

4.4.2.11 Analisa Sistem Look Up Data Pesanan Barang ......... 67


4.4.2.12 Analisa Sistem Look Up Return Barang .................... 69

4.4.2.13 Analisa Sistem Update Data Penerimaan Barang ....... 70

4.4.2.14 Analisa Sistem Update Data Pesanan Barang ............ 71

4.4.2.15 Analisa Sistem Update Data Return Barang ............... 72

4.4.2.16 Analisa Sistem Cetak Laporan .................................... 73

4.4.2.17 Analisa Sistem Cetak Struk Pembayaran ................... 74

4.4.3 Desain Sistem ......................................................................... 56

4.4.3.1 Desain Sistem Login ...................................................... 56

4.4.3.2 Desain Sistem Input Data Barang ...................................

4.4.3.3 Desain Sistem Input Data Penerimaan Barang ................ 57

4.4.3.4 Desain Sistem Penjualan Barang ..................................... 59

4.4.3.5 Desain Sistem Pesanan Barang ...................................... 60

4.4.3.6 Desain Sistem Return Barang.......................................... 61

4.4.3.7 Desain Sistem Cek Harga .............................................. 63

4.4.3.8 Desain Sistem Look Up Data Penerimaan Barang .......... 64

4.4.3.9 Desain Sistem Look Up Data Penjualan Barang ............ 65

4.4.3.10 Desain Sistem Look Up Data Persediaan Barang .......... 66

4.4.3.11 Desain Sistem Look Up Data Pesanan Barang .............. 67

4.4.3.12 Desain Sistem Look Up Return Barang ......................... 69

4.4.3.13 Desain Sistem Update Data Penerimaan Barang ............ 70

4.4.3.14 Desain Sistem Update Data Pesanan Barang ................. 71

4.4.3.15 Desain Sistem Update Data Return Barang .................... 72

4.4.3.16 Desain Sistem Cetak Laporan ......................................... 73

4.4.3.17 Desain Sistem Cetak Struk Pembayaran ........................ 74


4.5 Diagram Ketergantungan Use Case ................................................... 96

4.5.1 Inheritance ........................................................................ 96

4.5. 2 Extension......................................................................... 96

4.5.2 Depends On ...................................................................... 99

4.6 Use Case Diagram (Diagram Use Case) ............................................ 101

4.7 Rancangan Database .......................................................................... 102

4.7.1 Entity Relationship Diagram (ERD) ..................................... 103

4.7.2 Relasi Antar Tabel ................................................................. 124

4.7.3 Spesifikasi File ....................................................................... 124

4.7.3.1 Tabel Barang ................................................................... 124

4.7.3.2 Tabel Pegawai ................................................................. 124

4.7.3.3 Tabel Penerimaan Barang............................................... 124

4.7.3.4 Tabel Detail Penerimaan Barang.................................... 126

4.7.3.5 Tabel Penjualan Barang ................................................. 126

4.7.3.6 Tabel Detail Penjualan Barang ....................................... 126

4.7.3.7 Tabel Pesanan Barang .................................................... 126

4.7.3.8 Tabel Persediaan Barang ............................................... 127

4.7.3.9 Tabel Return Barang ....................................................... 127

4.7.4 Diagram Kelas ........................................................................ 128

4.8 Activity Diagram (Diagram Aktivitas) ............................................... 129

4.8.1 Activity Login ........................................................................ 129

4.8.2 Activity Barang .......................................................................

4.8.3 Activity Input Data Penerimaan Barang ................................ 129

4.8.4 Activity Penjualan Barang .................................................... 130


4.8.5 Activity Pesanan Barang ....................................................... 130

4.8.6 Activity Return Barang ........................................................... 131

4.8.7 Activity Cek Harga ................................................................. 131

4.8.8 Activity Look Up Data Penerimaan Barang .......................... 133

4.8.9 Activity Look Up Data Penjualan Barang ............................ 134

4.8.10 Activity Look Up Data Persediaan Barang............................ 134

4.8.11 Activity Look Up Data Pesanan Barang ............................... 135

4.8.12 Activity Look Up Data Return Barang ................................... 135

4.8.13 Activity Update Data Penerimaan Barang ............................ 137

4.8.14 Activity Update Data Pesanan Barang .................................. 137

4.8.15 Activity Update Data Return Barang ..................................... 138

4.8.16 Activity Cetak Laporan .......................................................... 139

4.8.17 Activity Cetak Struk Pembayaran ......................................... 140

4.9 Sequence Diagram ............................................................................. 141

4.10 Deployment Diagram ......................................................................... 153

4.11 Rancangan User Interface .................................................................. 154

BAB V. PENUTUP

5.1.Kesimpulan ............................................................................................... 137

5.2.Saran .......................................................................................................... 138

DAFTAR PUSTAKA
BAB I

PENDAHULUAN

1.1 Latar Belakang Masalah

Perkembangan teknologi informasi saat ini sangatlah cepat, hal ini diikuti

dengan perkembangan disegala hal. Dengan adanya perkembangan teknologi, maka

penyebaran informasi sangatlah cepat dan mudah. Untuk memenuhi kebutuhan

informasi, memerlukan pengolahan yang sistematis dengan cara membentuk suatu

sistem informasi. Sistem persediaan barang sangat dibutuhkan oleh perusahaan,

karena dengan sistem tersebut perusahaan dapat mendukung operasional usaha.

Kegiatan pengelolaan barang dari tahun ke tahun terus berlangsung.

Pengelolaan ini bukan hanya melibatkan barang-barang dan aset lama saja tetapi

juga barang-barang dan aset yang baru sehingga dengan demikian dari tahun ke

tahun jumlah barang ini bukannya berkurang bahkan terus bertambah. Dengan

bertambahnya jumlah barang-barang tersebut, tentunya mendatangkan kesulitan

tersendiri dalam pengelolaannya. Agar pelaksanaan penyimpanan barang dalam

gudang dapat terkelola serta tertata dengan baik, maka perlu dikembangkan suatu

aplikasi berupa Sistem Informasi Inventori. Karena bila dengan cara biasa (manual)

seperti sekarang, cukup menyulitkan dalam hal pengarsipan dan penelusuran data

barang.
Sistem Informasi Inventori ini akan menampung semua data dan informasi

tentang barang-barang tersebut. Data dan informasi ini nantinya akan terakumulasi

dan tersimpan (diarsipkan) secara terpusat pada suatu database. Dengan terpusatnya

data dan informasi ini, maka jelas akan mempermudah pengelolaan barang.

Pencarian data dan status barang akan lebih cepat, mudah, dan efisien.

Sistem inventori Barang pada Salemba Toko Buku masih menggunakan

manual, menggunakan kertas formulir stock barang. Dengan proses

pengolahan data yang masih manual ini seringkali terjadi penumpukan data

(redundancy), sehingga informasi akhir stock/persediaan barang yang dihasilkan

terkadang tidak sesuai dengan stock fisik yang ada digudang. Dari permasalahan

tersebut peneliti mengambil judul ”Perancangan Sistem Informasi Inventori

Pada Salemba Toko Buku”

1.2 Tujuan

Tujuan dari Perancangan Sistem Informasi ini adalah untuk

membangun atau merancang sistem informasi inventori dengan alur bisnis

yang dibutuhkan.

1.3 Sasaran

Ada pun sasaran yang akan dicapai pada pengembangan ini adalah

terbentuknya rancangan sistem informasi Inventori pada Salemba Toko Buku.


1.4 Manfaat

1. Mahasiswa mampu memahami dan menganalisis faktor-faktor yang

mempengaruhi suatu sistem informasi.

2. Menerapkan ilmu-ilmu yang diperoleh selama kuliah.

3. Membandingkan teori-teori yang didapatkan di perkuliahan dengan

masalah yang sebenarnya di lapangan.

1.5 Batasan Masalah

Sistem Inventori ini adalah suatu aplikasi yang meliputi input, proses,

output dimana data yang diolah merupakan data seluruh perlengkapan yang

ada di Salemba Toko Buku. Sistem Inventori ini akan memberikan informasi

tentang nama barang, jumlah barang, keadaan barang dan beberapa informasi

yang terkait dengan barang, serta pembuatan laporan, yaitu laporan

peneriman barang, laporan penjualan barang, laporan pesanan barang, laporan

persediaan barang, dan laporan return barang.

Berdasarkan identifikasi dan batasan masalah tersebut, penulis

membatasi permasalahan menjadi :

a . Membahas mengenai stok persediaan barang

b. Membahas mengenai return barang yang rusak

c. Membahas mengenai penjualan barang

d. Membahas mengenai pesanan barang ke pusat


BAB II

LANDASAN TEORI

2.1 Teori Umum

2.1.1 Sistem Informasi

Sistem adalah Sekumpulan objek-objek yang saling berelasi dan

berinteraksi serta hubungan antar objek bisa dilihat sebagai satu kesatuan yang

dirancang untuk mencapai satu tujuan (Hanif Al Fatta, 2007 hal. 3).

Informasi adalah data yang telah diolah menjadi sebuah bentuk yang

berarti bagi penerimanya dan bermanfaat dalam pengambilan keputusan saat

ini atau mendatang (Hanif Al Fatta, 2007 hal. 9).

Sistem Informasi adalah pengaturan orang, data, proses, dan

information technologi (IT)/teknologi informasi yang berinteraksi untuk

mengumpulkan, memproses, menyimpan, dan menyediakan sebagai output

informasi yang diperlukan untuk mendukung sebuah organisasi (Jeffery

L.Whitten, 2004 hal 10).

Kualitas informasi terkadang dipakai untuk menyatakan informasi

yang baik. Kualitas informasi sering kali diukur berdasarkan:


a. Relevansi (kesesuaian);

b. Ketepatan waktu; dan

c. Keakurasian.

Dalam suatu sistem informasi terdapat komponen-komponen seperti:

a. Perangkat keras (hardware) yaitu perangkat keras komponen untuk

melengkapi kegiatan memasukkan data, memproses data, dan keluaran data.

b. Perangkat lunak (software) yaitu program dari instruksi yang

diberikan ke komputer.

c. Database yaitu kumpulan data dan informasi yang diorganisasikan

sedemikian rupa sehingga mudah diakses pengguna sistem informasi .

d. Jaringan komputer dan Komunikasi data yaitu komunikasi yang

menghubungkan antara pengguna dengan sistem komputer secara bersama-

sama ke dalam suatu jaringan kerja yang efektif.

e. Manusia yaitu personel dari sistem informasi, meliputi manager, analis,

programmer, dan operator, serta bertanggung jawab terhadap perawatan

sistem.

f. Prosedur yaitu tatacara yang meliputi strategi, kebijakan, metode, dan

peraturan-peraturan dalam menggunakan sistem informasi berbasis

komputer (Hanif Al Fatta, 2007 hal. 10).


Gambar 2.1. Komponen Sistem Informasi

2.1.2 Basis Data (Database)

Database adalah kumpulan file yang saling terkait. Kata

kuncinya adalah”Saling terkait”. Database tidak hanya kumpulan file.

Record pada setiap file harus memperbolehkan hubungan–hubungan

untuk menyimpan file-file lain (Jeffery L.Whitten, Hal 518).

Untuk mengelola basis data diperlukan perangkat lunak yang

disebut DBMS. DBMS adalah perangkat lunak sistem yang

memungkinkan pemakai membuat, memelihara, mengontrol dan

mengakses basisdata dengan cara yang praktis.

Perangkat lunak yang didesain untuk mengelola database

disebut DBMS (Database Management System). Contoh DBMS yang

ada di pasaran adalah Oracle,Microsoft SQL Server, MYSQL,

Informix, Progress 4GL, Firebird dan FileMaker. DBMS sering

digunakan oleh Database Adminisator (DBA) untuk membuat sistem

database. Secara lebih rinci DBMS merupakan kumpulan software


program yang sangat kompleks untuk mengontrol organisasi data dan

alat penyimpanan data di database. (Bambang Wahyudi, 2008 Hal 188).

2.1.2.1 Entity – RelationshipDiagram (Diagram E-R)

Model entity – Relationship (ER) pada awalnya

disampaikan oleh Peter di tahun 1976 sebagai suatu cara untuk

menyatukan jaringan dan menggambarkan relational database.

Singkatnya, model ER adalah sebuah model konseptual dari data

yang menggambarkan keadaan sebenarnya dari entities dan

relationship (Bambang Wahyudi, 2008 Hal 199).

Notasi-notasi simbolik di dalam Diagram E-R yang

digunakan adalah:

1. Entitas (entity), dilambangkan dengan persegi panjang (rectangle);

2. Relasi (relationship), dilambangkan dengan belah ketupat

(diamonds);

3. Atribut(attribute),dilambangkan dengan elips (ellipses atau ovals);

4. Garis penghubung (line links), dilambangkan dengan gais (lines).

(Bambang Wahyudi, 2008 Hal 199).

Entitas Atribut

Relasi Penghubung

Gambar 2.2 Notasi-notasi Simbolik ERD


Ada beberapa tahapan membuat diagram ERD yaitu :

1. Menentukan entitas Menentukan peran, kejadian/kegiatan,

lokasi, hal abstrak/konsep yang datanya disimpan oleh end-user.

Pembeli Barang

2. Menentukan atribut-atribut key dari masing-masing himpunan

entitas.

No_kwitansi Kd_barang Nama_barang


Kd_distr

Stock

Pembeli Barang
Merek

Harga_satuan

Jenis_barang Satuan

3. Tentukan hubungan antara sepasang entitas menggunakan

relationship matriks.

No_kwitansi Jml_bayar Kd_barang Nama_barang


Kd_distr

Stock

Pembeli Membeli Barang


Merek

Harga_satuan

Tgl_beli Jenis_barang Satuan

4. Tentukan kardinalitas (pemunculan suatu entitas di entitas

lainnya yang berhubungan).


No_kwitansi Jml_bayar Kd_barang Nama_barang
Kd_distr

Stock

M N
Pembeli Membeli Barang
Merek

Harga_satuan

Tgl_beli Jenis_barang Satuan

2.1.3 Unified Modeling Language (UML)

UML adalah satu kumpulan konvensi pemodelan yang digunakan

untuk menunjukkan atau menggambarkan sebuah sistem software yang

terkait dengan objek (Jeffery L.Whitten, 2004 Hal 408).

a. Objek

Objek adalah sesuatu yang ada atau dapat dilihat, disentuh atau

dirasakan dan user menyimpan serta mencatat perilaku mengenai

sesuatu itu. Setiap objek memiliki dua karakteristik yaitu:

1. Atribut

Atribut adalah data yang mewakili karakteristik interest

tentang sebuah objek.

2. Behavior

Behavior adalah kumpulan dari sesuatu yang dapat

dilakukan oleh objek dan terkait dengan fungsi-fungsi yang

bertindak pada data objek (atribut). Pada siklus berorientasi objek,

perilaku objek merujuk kepada metode, operasi, atau fungsi

(Jeffery L.Whitten, 2004 Hal 409).

b. Kelas
Kelas adalah satu set objek yang memiliki atribut dan behavior

yang sama. Kadang-kadang disebut object class (Jeffery L.Whitten, 2004

Hal 410).

c. Generalisasi/Spesialisasi

Adalah sebuah teknik dimana atribut dan behavior yang umum

pada beberapa tipe kelas objek, dikelompokkan (atau diabstraksi)

kedalam kelasnya sendiri, disebut supertype. Atribute dan metode kelas

objek supertype kemudian diwariskan oleh kelas objek tersebut

(subtype).

d. Inheritance

Adalah konsep dimana metode dan atau atribute yang ditentukan

di dalam sebuah objeck class dapat diwariskan atau digunakan lagi oleh

objeck class lainnya(Jeffery L.Whitten, 2004 Hal 411).

UML menyediakan beberapa diagram visual yang menunjukkan

berbagai aspek dalam sistem, ada beberapa diagram yang disediakan

dalam UML, antara lain :

- Use Case Diagram

- Class Diagram

- Sequential Diagram

- Activity Diagram

- Deployment Diagram

2.1.3.1 Diagram Unifield Modeling Language (UML)

1. Use Case Diagram


Use case diagram adalah metode berbasis text untuk

menggambarkan dan mendokumentasikan proses yang kompleks.

Use case menambahkan detail untuk kebutuhan yang telah

dituliskan pada definisi sistem kebutuhan. Use case diagram

dikembangkan oleh analisis sistem bersama-sama dengan

pengguna. Pada tahap selanjutnya, berdasarkan use case ini,

analisis menyusun model data dan model proses (Hanif Al

Fatta,2007 hal.91).

Komponen Pembentuk Use-case Diagram

a. Actor / Pelaku

Actor / pelaku adalah segala sesuatu yang perlu

berinteraksi dengan sistem untuk pertukaran informasi .

Ada 4 tipe macam pelaku :

 Primary business actor(pelaku bisnis utama) yaitu

stakeholder yang terutama mendapatkan keuntungan

dari pelaksanaan use case dengan menerima nilai yang

terukur atau terobservasi.

 Primary system actor(Pelaku sistem utama) yaitu

stakeholder yang secara langsung berhadapan dengan

sistem untuk menginisiasi untuk memicu kegiatan atau

sistem.

 External server actor(Pelaku server eksternal) yaitu

stakeholder yang melayani kebutuhan penggunan use

case.
 Exernal receiving actor(Pelaku penerima teramati)

yaitu stakeholder yang bukan pelaku utama, tapi

menerima nilai yang terukur atau teramati(output) dari

use case(Jeffery L.Whitten, 2004 hal 259).

Gambar 2.3 Simbol actor / pelaku

b. Relationship (Hubungan)

Pada diagram use case, hubungan digambarkan

sebagai sebuah garis antara dua simbol. Pemaknaan

hubungan berbeda – beda tergantung bagaimana garis

tersebut digambarkan dan tipe simbol apa yang

digunakan untuk menghubungkan garis tersebut(Jeffery

L.Whitten, 2004 hal 259). Perbedaan diantara

hubungan – hubungan yang ada pada diagram use case

yaitu :

1. Association (Gabungan)

Association yaitu hubungan antara seorang

pelaku dan satu use case terbentuk kapan pun use

case menggambarkan interaksi antara

keduanya(Jeffery L.Whitten, 2004 hal 259).


Place New Member Order

Club Member
Distribution Center

2. Extension Use Case

Extension Use Case yaitu Use Case yang

terdiri dari langkah yang diekstraksi dari Use Case

yang lebih kompleks untuk menyederhanakan

masalah orisinal dan karena itu memperluas

fungsinya.

Extension Use Case

Generate Calculate order


Worehouse subtotal & Sales
Packing Order Tax

<<extends>>
<<extend>>

Place New Order

3. Depends On

Manager proyek atau developer utama

sangat perlu mengetahui Use Case mana yang

memiliki ketergantungan pada Use Case lain untuk

menetapkan rangkaian Use Case yang perlu

dikembangkan.
Cetak Laporan
persediaan
barang
<<Dependension>>

Data Barang

si
si o n d

en
>
>
en epe

ep >
nd
n>

D on
e
D
<<

<<
Input Data Barang Update data
Masuk barang

4. Abstract Use Case

Use case yang mengurangi redudansi antara

dua atau lebih Use Case lain dengan

menggabungkan langkah-langkah yang biasa

ditemukan pada Use Case tersebut(Jeffery

L.Whitten, 2004 hal 260).

Place New Order Abstract Use case

<<User>>

Revisi Postal Address

<<User>>

Submit Change of
Postal Address

5. Inheritance

Pada saat dua atau lebih pelaku berbagi

kelakuan umum dengan kata lain mereka dapat

menginisiasi Use Case yang sama maka yang paling

baik adalah mengekstrapolasi kelakuan umum dan

menetapkannya ke pelaku abstrak baru untuk


mengurangi komunikasi redundan dengan

sistem(Jeffery L.Whitten, 2004 hal 262).

Login

User

<<Inheritance>>
<<Inheritance>> <<Inheritance>>
<<Inheritance>>

Pimpinan Adm.Gudang Supervisor Kasir

Tipe relasi atau stereotype yang mungkin terjadi pada use-case

diagram:

1. <<include>>, yaitu kelakuan yang harus terpenuhi agar sebuah

event dapat terjadi, dimana pada kondisi ini sebuah use-case

adalah bagian dari use-case lainnya.

2. <<extends>>, kelakuan yang hanya berjalan di bawah kondisi

tertentu seperti menggerakkan alarm.

3. <<communicates>>, mungkin ditambahkan untuk asosiasi yang

menunjukkan asosiasinya adalah communicates association. Ini

merupakan pilihan selama asosiasi hanya tipe relationship yang

dibolehkan antara actor dan use-case.

2. Class Diagram

Class Diagram menggambarkan struktur objek sistem.

Diagram ini menunjukkan kelas objek yang menyusun sistem

dan juga hubungan antara kelas objek tersebut(Jeffery

L.Whitten, 2004 hal 418).


ClsPenerimaanBarang
-NoPenerimaan : Char
-Tglpenerimaanm : Date
-IdPegawai : Char
ClsPegawai
Tambah barang
-IdPegawai : Char Ubah data barang
-NamaPegawai : Varchar
-Harga : Char

Tambah Pegawai

ClsBarang
- KdBarang : Char
- Barcode : Char
- Nama Barang : Varchar
- Harga : Char

Tambah Barang
ClsPenjualanBarang

-NoPenjualan : Char
-Tanggalpenjualan : Date
-IdPegawai : Char

Tambah Transaksi Penjualan

ClsPesanan Barang
Return Barang
-NoPesan : Char
-NoReturn : Char -TglBarangpesan : Date
-TglReturn : Date -KdBarang : Char
-Kdbarang : Char -QTYPesan : Char
-QTYPesan : Char Tambah Pesanan
Ubah Data Pesanan
Tambah Return Barang
Ubah Return Barang

Gambar 2.4 Class Diagram

3. Sequential Diagram (Diagram rangkaian)

Secara grafis menggambarkan bagaimana objek berinteraksi

dengan satu sama lain melalui pesan pada eksekusi sebuah use case

atau operasi. Diagram ini mengilustrasikan bagaimana pesan

terkirim di antara objek dan dalan sekuensi apa.

From Login Login Data User Menu Utama

User

Login

Validasi user

Cek validasi

Masuk ke Halaman Menu Utama

Validasi
[Result]
Gambar 2.5 Contoh Sequential Diagram

4. Activity Diagram (Diagram Aktivitas)

Secara grafis digunakan untuk menggambarkan rangkaian

aliran aktivitas baik proses bisnis atau use case. Diagram ini juga

dapat digunakan untuk memodelkan action yang akan dilakukan

saat sebuah operasi dieksekusi , dan memodelkan hasil dari action

tersebut.

Admin
Sistem
Gudang

Login

Menampilakan pesan eror Login

Menampilakan pesan eror Login Menampilakan hal menu utama

Search data barang

Input tanggal awal dan akhir Lap. kembali

Klik Print Menampilkan informasi lap data barang masuk

Print Laporan

Exit

Gambar 2.6 Contoh Activity Diagram


5. Diagram Deployment (Diagram Penguraian)

Mendeskripsikan arsitektur fisik dalam istilah ”node” untuk

hardware dan software dalam sistem. Diagram ini menggambarkan

konfigurasi komponen-komponen software run-time, prosesor, dan

peralatan yang membentuk arsitektur sistem (Jeffery L.Whitten,

2004 hal 419).

Server

Window
s Server
2008

MySQL
LAN

Jalur Koneksi

Client

Window
s7

Scanner Barcode Printer type


deskjet .
Microsof
t Visual
Studio
2010
Gambar 2.7 Contoh Deployment Diagram

2.1.4 Feasibility Study (Studi Kelayakan)

Kelayakan adalah ukuran akan seberapa menguntungkan atau

seberapa praktis pengembangan sistem informasi terhadapa organisasi.

Kelayakan analysis/analisis kelayakan adalah proses pengukuran

kelayakan(Jeffery L.Whitten, 2004 hal 380).

Ada 4 Pengujian kelayakan :

2.1.4.1 Operational feasibility/kelayakan operasional

Ukuran sebaiknya apa solusi tersebut akan bekerja dalam

organisasi. Juga ukuran pendapat orang tentang sistem/proyek

tersebut. Kriteria kelayakan operasional mengukur tingkat

kepentingan masalah (fase survei dan studi) atau tingkat

penerimaan solusi(fase definisi, pemilihan, akuisisi, dan desain).

(Jeffery L.Whitten, 2004 hal 382).

2.1.4.2 Technical feasibility/kelayakan teknis

Ukuran kepraktisan solusi teknis tertentu dan ketersediaan

sumber dan pakar teknis. Sedikit hal yang secara teknis tidak
mungkin. Akibatnya, kelayakan teknis mengarah pada hal yang

praktis dan masuk akal(Jeffery L.Whitten, 2004 hal 384).

2.1.4.3 Schedule feasibility/kelayakan jadwal

Ukuran seberapa masuk akal daftar waktu pelaksanaan suatu

proyek(Jeffery L. Whitten, 2004, hal.382). Beberapa proyek

diawali dengan tenggat waktu yang spesifik. Sangat perlu untuk

menentukan apakah tenggat waktu itu bersifat perintah(mandatory)

atau keinginan. (Jeffery L. Whitten, 2004, hal.384).

2.1.4.4 Economic feasibility/kelayakan ekonomis

Ukuran efektivitas biaya sebuah proyek atau solusinya.Hal

mendasar dalam banyak proyek adalah kelayakan ekonomis.

Selama fase awala proyek, analisis kelayakan ekonomis hanyalah

menentukan apakah manfaat yang diperoleh dari penyelesaikan

persoalan tersebut cukup berharga(Jeffery L.Whitten, 2004 hal

384).
2.1.5 Teknologi Barcode

Dalam pembuatan sistem informasi ini kami menggunakan alat

teknologi barcode. Scanner barcode adalah piranti keras yang memiliki

fungsi khusus, yakni membaca kode barcode yang tertempel pada barang.

Barcode adalah sebagai kumpulan kode yang berbentuk garis, dimana

masing-masing ketebalan setiap garis berbeda sesuai dengan isi kodenya.

Teknologi Barcode ini memiliki beberapa manfaat diantaranya :

1. Akurasi

2. Kemudahan Pemakaian

3. Keseragaman Pengumpulan Data

4. Feedback yang tepat waktu

5. Keamanan

6. Meningkatkan Produktivitas

7. Meningkatkan Profit

Teknologi yang ada pada barcode diantaranya :

1. Teknologi Laser

Teknologi Laser menggunakan dioda laser berkekuatan 650 ns.

Laser ini sebenarnya setara dengan kekuatan pada pointer presentasi.

Kelemahan barcode scanner ini adalah rentan rusak dan tidak bisa

digunakan untuk membaca barcode 2 Dimensi, barcode jenis ini banyak

digunakan oleh industri manufaktur besar seperti Seagate Hard Disk,

Sony, dan Matsuhita.


2. Teknologi CCD

Teknologi CCD (Charge Coupled Device) menggunakan sinar

infrared, berbeda dengan sinar laser, seperti yang digunakan pada

kamera. Pembacaan dengan scanner CCD juga mensyaratkan supaya

sinar dan objek barcode didekatkan atau ditempelkan pada jarak

maksimal 2 cm. Jenis barcode sinar CCD jauh lebih kuat dan tahan

banting.

3. Teknologi Linear Imager

Teknologi ini menggabungkan kepekaan laser, kekuatan CCD,

ditambah dengan kemampuan untuk membaca barcode 2 dimensi.

Sistem kerja pada barcode merupakan instrumen yang bekerja

berdasarkan asas digital. Pada konsep digital, hanya ada 2 sinyal data

yang dikenal dan bersifat boolean, yaitu 0 atau 1. Ada arus listrik atau

tidak ada listrik (dengan besaran (tresshold) tegangan tertentu, misalnya

5 volt dan 0 volt). Barcode menerapkannya pada batang-batang baris

yang terdiri dari warna hitam dan putih. Warna hitam mewakili bilangan

0 dan warna putih mewakili bilangan 1. Warna hitam akan menyerap

cahaya yang dipancarkan oleh alat pembaca barcode, sedangkan warna

putih akan memantul-balikan cahaya tersebut. Masing-masing batang

barcode memiliki ketebalan yang berbeda. Ketebalan inilah yang akan

diterjemahkan ke dalam suatu nilai.


Gambar 2.8 Anatomy of a Barcode

Keterangan gambar barcode di atas adalah :

1. Number System Character

Angka ini merupakan sebuah sistem bilangan barcode UPC yang

mengkarakteristikkan jenis-jenis khusus pada barcode. Di dalam barcode

UPC, Number System Character ini biasanya terletak di sebelah kiri

barcode.

2. Guard Bars

Ada 3 guard bars yang ditempatkan di awal, tengah dan akhir barcode.

Guard bars bagian awal dan akhir di-encode-kan sebagai ‘space-bar-

space” atau “01010”.

3. Manufacture Code

Kode perusahaan ini ada lima digit bilangan yang secara khusus

menentukan manufaktur suatu produk. Kode perusahaan/manufaktur ini

dilindungi dan ditetapkan oleh Uniform Code Council(UCC).

4. Product Code

Kode produk ini terdiri dari lima digit bilangan yangditetepkan oleh

perusahaan/manufaktur untuk setiap produk yang dihasilkan.


5. Check Digit

Disebut sebagai digit Selft-check. Check digit ini terletak di bagian luar

sebelah kanan barcode. Check digit ini merupaka suatu old

programmer’s trick untuk memvalidasi digit-digit lainnya(number

system cahracter,manufacture code, product code) yang dibaca secara

teliti.

2.2 Jaringan Komputer

Jaringan komputer adalah hubungan dua simpul (umumnya berupa

komputer) atau lebih yang tujuan utamanya adalah untuk melakukan pertukaran

data. Dalam prakteknya, jaringan komputer memungkinkan untuk melakukan

berbagi perngkat lunak, perangkat keras, dan bahkan berbagai kekuatan

pemrosesan (Abdul Kadir, 2003 hal.346).

2.2.1 Local Area Network (LAN)

LAN adalah jaringan komputer yang mencakup area dalam satu ruang,

satu gedung, atau beberapa gedung yang berdekatan. Sebagai contoh,

jaringan dalam satu kampus yang terpadu atau disebuah lokasi perusahaan

tergolong sebagai LAN. LAN umumnya menggunakan media transmisi

berupa kabel. Namun ada juga yang tidak menggunakan kabel dan disebut

sebagai wireless LAN atau LAN tanpa kabel. Kecepatan LAN berkisar dari

10 Mbps sampai 1 Gbps (Abdul Kadir, 2003 hal.348).

2.2.2 Two Tier (2 Tier)

Arsitektur two tier merupakan arsitektur yang disebut client server,

dimana terdapat komputer sebagai client dan server yang berinteraksi

melalui protokol dan media komunikasi tertentu (Budi Sutedjo Dharma

Oetomo, S.Kom, 2006, hal. 99).

2.2.3 Topologi Star


Pada topologi ini terdapat komponen yang bertindak sebagai

pusat pengontrol. Semua simpul yang hendak berkomunikasi selalun

melalui pusat pengontrol tersebut dalam hal ini, pusat pengontrol

berupa Hub atau swicth (Abdul Kadir, 2003.hal 354).

2.3 MySQL

MySQL adalah sebuah program database server yang mampu menerima dan

mengirimkan datanya dengan sangat cepat, multi user, serta menggunakan perintah

standard SQL (Structured Query Language). MySQL memiliki dua bentuk lisensi,

yaitu FreeSoftware dan Shareware. (Bunafit Nugroho, 2005 hal 3). Selain itu

database ini memliki banyak kelebihan dibanding database lain, di antaranya

adalah :

1. MySQL sebagai Database Management System (DBMS)

2. MySQL sebagai Relation Database Management System (RDBMS)

3. Merupakan software database yang OpenSource

4. MySQL dapat menjadi database Client dan dapat juga menjadi Server.

5. Multi-Threading yaitu mampu menerima query yang bertumpuk dalam

satu permintaan.

6. Mampu menyimpan data berkapasitas sangat besar.

7. Multi User, artinya database dapat dugunakan oleh banyak pengguna.

8. MySQL memliki kecepatan dalam pembuatan dan update tabel.

2.4 Visual Basic 2010

Visual Basic 2010 merupakan salah satu bagian dari produk pemrograman

terbaru yang dikeluarkan oleh Microsoft, yaitu Microsoft Visual Studio 2010.

Sebagai produk lingkungan pemrograman terintegrasi atau IDE andalan yang

dikeluarkan oleh Microsoft, Visual Studio 2010 menambahkan perbaikan –


perbaikan fitur dan fitur baru yang lebih lengkap dibandingkan versi Studio

pendahulunya, yaitu Microsoft Visual Studio 2008.

Visual Studio merupakan produk pemrgraman andalan dari Microsoft

Corporation, yang didalamnya berisi beberapa jenis IDE pemrograman seperti

Visual Basic, Visual C++, Visual Web Developer, Visual C#, dan Visual F#.

Semua IDE pemrograman tersebut sudah mendukung penuh implementasi .Net

Framework terbaru, yaitu Net Framework 4.0 yang merupakan pengembangan dari

.Net Framework 3.5(Penerbit Andi, 2010, hal 2).

2.5 Objek Pengembangan (Sejarah Salemba Toko Buku)

Salemba Toko Buku yang beralamat di Jl.Merdeka Ruko PGB Blok A No

2-3 Bogor adalah cabang perusahaan di Bogor yang bergerak di bidang penjualan

Buku dan ATK. Salemba ini berdiri sekitar 10-15 tahun yang lalu. Dulu Salemba

Toko Buku ini tidak hanya menjual buku dan ATK saja, tetapi ada sebuah

swalayan yang berada di lantai 3. Tetapi karena jumlah pembeli minim jadi

Salemba hanya menjual buku-buku dan ATK saja . Salemba Toko Buku sekarang

sudah mempunyai 54 cabang, disetiap kota di Indonesia ada, dan salah satunya ada

di Bogor. Salemba Toko Buku yang berada di Bogor ini menjual buku-buku dan

ATK, tetapi lebih memfokuskan penjualan ATK.

2.5.1 Visi dan Misi Salemba Toko Buku

a. Visi

Sebagai Toko penjualan terlengkap dan memenuhi

kebutuhan konsumen dalam bidang buku dan ATK.

b. Misi
Membuat pelayanan yang berkualitas sebagai tanggung

jawab setiap orang. Memenuhi kebutuhan konsumen.

2.6 Kerangka Pemikiran

Dari hasil analisa masalah yang ada, maka dirancanglah sistem dimana dari

segi pendataan barang dibuat seefisien mungkin. Rancangan sistem informasi ini

meliputi pembuatan aplikasi yang sesuai dengan kebutuhan user dan pembaharuan

sistem yang ada. Perancangan sistem informasi inventori yang akan dikembangkan

pada tahap implementasi menggunakan Database Management System (DBMS)

MySQL sebagai konektor. Sistem ini akan memberi kemudahan dalam proses

persediaan barang.

Proses persediaan yaitu persediaan barang, penerimaan barang, penjualan

barang, pesanan barang dan return barang. Sehingga menghasilkan laporan

persediaan barang, laporan penerimaan barang, laporan penjualan barang, laporan

pesanan barang dan laporan return barang.

Dalam membangun Sistem Informasi ini penulis menggunakan perangkat

lunak Microsoft Visual Basic 2010 (VB.Net 2010) sebagai bahasa pemrograman

dan MySQL sebagai perangkat lunak pengelola database, server menggunakan

sistem operasi Windows Server 2008 sedangkan untuk client menggunakan sistem

operasi Windows7, dan untuk mencetak laporan digunakan printer type deskjet.
BAB III

ANALISA SISTEM

3.1 Jadwal Proyek

Jadwal proyek merupakan acuan agar pelaksanaan Perancangan Sistem

Informasi Inventori di Salemba Toko Buku ini berjalan sesuai dengan yang

diharapkan dan selesai tepat pada waktunya.

Tabel 3.1 Penjadwalan Proyek menggunakan Microsoft Project

3.2 Analisa Kelayakan Sistem

3.2.1 Kelayakan Ekonomi (Analisa biaya dan manfaat)


Kelayakan Ekonomi hal mendasar dalam banyak proyek, analisis

kelayakan ekonomis hanyalah menentulan apakah manfaat yang diperoleh

dari menyelesaikan persoalan tersebut cukup berharga. Biaya secara praktis

tidak mungkin diperkirakan pada tahap itu, karena persyaratan pengguna

akhir dan solusi teknis alternatif belum diidentifikasi. Akan tetapi, segara

setelah persyaratan dan solusi spesifikasi diidentifikasi, analis dapat

diperkirakan biaya dan keuntungan tiap alternatif tersebut. Ini disebut analisis

cost-benefit (Jeffery L. Whitten, 2004, hal. 384).

Analisis dan perancangan biaya pada perancangan sistem ini adalah

sebagai berikut:

NO Deskripsi TAHUN 0 TAHUN 1 TAHUN 2 TAHUN 3 TAHUN 4

Rincian Biaya

Biaya
1. Pengadaan

- Biaya Pembelian
Rp.7.200.000
H/W

-Jaringan Rp.250.000

Sub Total Rp.7.450.000


Biaya
Pengadaan

Biaya
2. Persiapan Operasi

- Biaya pembelian
Rp.4.000.000
S/W

- Biaya Biaya Personil


Rp.900.000
Sub Total Rp.4.900.000
Biaya
Persiapan Operasi

Biaya
3. proyek

a. Tahap Analisis
Sistem

- Biaya pengumpulan
Rp. 250.000
data

- Biaya ATK Rp. 50.000

- Biaya manajemen
Rp. 2.700.000
dan
staf

- Biaya rapat Rp. 250.000

-Biaya programer Rp.9.000.000

- Biaya konsultan analis


Rp.3.500.000

Sub Total BiayaRp.15.500.000


Tahap
Analisis

Total Keseluruhan
Rp.27.850.000

Biaya
4. Operasional &
Perawatan

- Biaya overhead
Rp.500.000 Rp. 600.000 Rp.700.000 Rp.800.000

-Biaya Perwatan H/W


Rp. 650.000
Rp. 700.000 Rp. 780.000 Rp. 850.000

-Biaya Perawatan S/W


Rp. 550.000 Rp. 600.000 Rp. 650.000 Rp. 700.000

-Biaya Kontrak
Rp 4.000.000 Rp. 4.500.000 Rp. 5.000.000 Rp. 5.500.000

Sub Total Biaya


Operasional dan Rp.5.700.000 Rp.6.400.000 Rp.7.130.000 Rp.7.850.000
Perawatan
Total Biaya Rp.27.850.000
Rp.5.700.000 Rp.6.400.000 Rp.7.130.000 Rp.7.850.000
Tabel 3.2 Analisa Biaya dan Manfaat
Tabel Analisa Manfaat

No Deskripsi TAHUN 1 TAHUN 2 TAHUN 3 TAHUN 4


Keuntungan
1. Berwujud
a.
Mengurangi Rp. 1.500.000 Rp.2.000.000 Rp.3.000.000 Rp.5.000.000
kesalahan
b. Peningkatan
Penjualan Rp. 3.500.000 Rp.4.000.000 Rp.5000.000 Rp.5.500.000
c. Mempermudah
Mendeteksi & Rp.5.000.000 Rp.5.300.000 Rp.5.500.000 Rp.6.000.0000
Mengawasi
Total Rp.10.000.000 Rp.11.300.000 Rp.13.500.000 Rp.16.000.000
KeuntunganTak
2. berwujud
a. Peningkatan
Rp.6.500.000 Rp.6.500.000 Rp.6.700.000 Rp.7.000.000
Manajement
b. Efisiensi waktu Rp.6.000.000 Rp.7.000.000 Rp.8.000.000 Rp.9.000.000
Total
Rp.12.500.000 Rp.13.500.000 Rp.14.700.000 Rp.16.800.000

Investasi Awal : Rp. 27.850.000


Total Manfaat Total Biaya Proceed
Tahun 1 Rp 22.500.000 Rp. 6.700.000 Rp. 15.800.000
Tahun 2 Rp. 24.800.000 Rp. 7.600.000 Rp. 17.280.000
Tahun 3 Rp. 28.200.000 Rp. 8.530.000 Rp. 19.670.000
Tahun 4 Rp. 32.800.000 Rp. 9.350.000 Rp. 23.450.000
Total Rp. 108.000.000
Rp. 32.108.000

Tabel 3.3 Proceed

a. Payback Period (PP)

Nilai investasi : Rp. 27.850.000

Proceed tahun ke-1 = Rp. 15.800.000

Sisa (tahun ke-2) :

PP = 1 tahun + [(Rp. 27.850.000– Rp. 15.800.000) x 12 bulan]

Rp. 17.280.000

= 1 tahun + (Rp. 12050000) x 12 bulan


Rp. 17.280.000

= 1 tahun 8,36 bulan

Jadi, Payback Periodnya adalah 1 tahun 8 bulan 18 hari.

b. Return of Investment (ROI)

𝟏08.000.000−59.958.000
𝑅𝑂𝐼 = [ ] 𝑥 100%
59.958.000

48.042.000
𝑅𝑂𝐼 = [ ] 𝑥 100%
59.958.000

𝑅𝑂𝐼 = [0,801]𝑥 100%

𝑅𝑂𝐼 = 80,1%

ROI bernilai positif, maka sistem layak dikembangkan.

c. Net Present Value (NPV)

𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛1 𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛2 𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛3 𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛4


𝑁𝑃𝑉 = −𝑁𝑖𝑙𝑎𝑖 𝑃𝑟𝑜𝑦𝑒𝑘 + + + +
(1 + 𝑖)1 (1 + 𝑖)2 (1 + 𝑖)3 (1 + 𝑖)4

15.800.000 17.200.000 19.670.000 23.450.000


𝑁𝑃𝑉 = −27.850.000 + (1+0,25)1
+ (1+0,25)2
+ (1+0,25)3
+ (1+0,25)4
𝑁𝑃𝑉 =

−27.850.000 + 12.640.000 + 11.008.000 + 10.071.000 + 9.610.657

𝑁𝑃𝑉 = −27.850.000 + 43.329.657

𝑁𝑃𝑉 = 𝑅𝑝. 15.479.657(NPV Positif)

NPV bernilai positif, maka sistem layak dikembangkan.


Untuk menghitung IRR, harus menemukan nilai NPV=0 dengan cara mencari NPV positif

dan NPV negatif dengan cara trial and eror.

𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛1 𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛2 𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛3 𝑃𝑟𝑜𝑐𝑒𝑒𝑑 𝑡ℎ𝑛4


𝑁𝑃𝑉 = −𝑁𝑖𝑙𝑎𝑖 𝑃𝑟𝑜𝑦𝑒𝑘 + + + +
(1 + 𝑖)1 (1 + 𝑖)2 (1 + 𝑖)3 (1 + 𝑖)4

15.800.000 17.200.000 19.670.000 23.450.0000


𝑁𝑃𝑉 = −27.850.000 + + + +
(1 + 0,55)1 (1 + 0,55)2 (1 + 0,55)3 (1 + 0,55)4

𝑁𝑃𝑉 = −27.850.000 + 10.193.543 + 7.151.767 + 5.283.373 + 4.064.124

𝑁𝑃𝑉 = −27.850.000 + 26.692.807

𝑁𝑃𝑉 = −𝑅𝑝. 115.719(NPV Negatif)

Nilai IRR terletak pada rate of return 25% (Positif) dan 55% (Negatif)

d. Internal Rate of Return (IRR)

Diketahui : i1 = Rate of Return (NPV Positif) = 25%

i2 = Rate of Return (NPV Negatif) = 55%

NPV 1 = NPV Positif = Rp. 15.479.657

NPV 2 = NPV Negatif = Rp. -115.719

(𝑖2 − 𝑖1)𝑥 𝑁𝑃𝑉1


𝐼𝑅𝑅 = [𝑖1 + ]%
𝑁𝑃𝑉1 − 𝑁𝑃𝑉2

(55 − 25) 𝑥 15.479.657


𝐼𝑅𝑅 = [25 + ]%
15.479.657 − (−115.719)
30 𝑥 15.479.657
𝐼𝑅𝑅 = [25 + ]%
15595376

464389710
𝐼𝑅𝑅 = [25 + ]%
15595376

𝐼𝑅𝑅 = [25 + 29,77]%

𝐼𝑅𝑅 = 54,77%

3.2.2 Kelayakan Teknis

Kelayakan teknis adalah ukuran kepraktisan solusi teknis

tertentu dan ketersediaan sumber dan pakar teknis (Jeffery L.

Whitten, 2004, hal. 382). Sangat sedikit hal yang secara teknis

tidak mungkin. Akibatnya, kelayakan teknis mengarah pada hal

praktis dan masuk akal (Jeffery L. Whitten, 2004, hal.384).

a. Perangkat keras (hardware) dan perangkat lunak (software)

pada komputer server

PerangkatKeras(hardware) Perangkatlunak(software
)
- Processor intel core i3 Windows Server 2008
-Mainboard
-Harddisk 80Gb MySQL
- Keyboard + Mouse
Komputer server
-Casing ATX 450w + 2 FAN
CPU
-LCD Monitor
- DVD-RW

b. Perangkat keras (hardware) dan perangkat lunak

(software) pada komputer client


PerangkatLunak
PerangkatKeras (hardware)
(software)
- Processor intel core i3 Windows 7
Microsoft Visual Studio
-Mainboard
2010
Komputer client
-Harddisk 160 Gb
-Keyboard + Mouse
-Casing ATX 450w + 2FAN CPU
-LCD Monitor

c. Jaringan

1. Kabel UTP
Jaringan 2. Switch Dlink 10/100

d. Alat Bantu

Alat bantu 1. Scanner Barcode


2. ID Card RFID

3.2.3 Kelayakan Jadwal

Kelayakan jadwal adalah ukuran kelayakan daftar pelaksanaan

proyek tersebut (Jeffery L. Whitten, 2004, hal.382). Beberapa proyek

diawali dengan tenggat waktu yang spesifik. Sangat perlu untuk

menentukan apakah tenggat waktu itu bersifat perintah (mandatory)

atau keinginan.(Jeffery L. Whitten, 2004, hal.384).


3.2.4 Kelayakan Operasional

Kelayakan operasional adalah ukuran sebaik apa solusi tersebut

akan bekerja dalam organisasi. Juga ukuran pendapat orang tentang

sistem / proyek tersebut. Kriteria kelayakan operasional mengukur

tingkat kepentingan masalah(fase survei dan studi) atau tingkat

penerimaan solusi(fase definisi, pemilihan, akuisisi, dan desain)

(Jeffery L. Whitten, 2004, hal. 382).


3.3 Analisa Proses Sistem yang Berjalan

Supervisor Pusat Admin gudang Customer Kasir Pimpinan


Membuat
Surat Mengirim Penerimaan Cek barang
permintaan barang Barang Belanja Barang
dengan barcode
barang

Membuat
data return
barang

Kembali ke Barang Struck


pusat
Y Rusak ? pembayaran Struk pembayaran
Membuat
laporan
T

Lap. Persediaan
barang
Input barang
Lap. Pembelian masuk
barang
Lap.Persediaan
Lap.Penjualan barang
Barang
Lap.Penerimaan
Lap.Pesanan barang
barang Lap.Penjualan
barang
Lap.Return barang
Lap.Pesanan barang

Lap.Return barang

Laporan Persediaan
C barang

Lap.Penerimaan
barang
C
Lap.Penjualan Tanda
Barang tangan
C lap
Lap.Pesanan
barang
C
Lap.Return
barang
C

Gambar 3.10 Analisa Proses Sistem yang Berjalan


3.4 Analisa Proses Sistem Baru yang dikembangkan

Supervisor Admin Customer


Login Pusat Barcode Kasir Pimpinan
Gudang

Surat Pesanan
Mengirim barang Menerima barang
Barang
Cek harga
Mesin
Membayar dengan barcode
Marcode
dan pembayaran

Barang
Data Pesanan Rusak ?
Barang
Data
Kembali Y Penjualan
kan ke Barang
pusat

Login Database
T Struck Struck
Input data Pembayaran Pembayaran
penerimaan
barang

Melihat
Semua
Lap.barang
Data Penerimaan
Return Barang barang

Data Return Lap. Persediaan


Barang barang

Lap.Penerimaan
barang

Lap. Persediaan Lap.Penjualan


barang barang

Lap.Penerimaan Lap.Pesanan
barang barang

Lap.Penjualan Lap.Retutn
Barang Barang
Lap.Pesanan
barang

Lap.Return barang

Tanda
tangan

Lap. Persediaan
C barang

Lap.Penerimaan
C barang

Lap.Penjualan Lap. Persediaan


C barang barang
Lap.Penerimaan
Lap.Pesanan barang
C barang Lap.Penjualan
barang
Lap.Retutn Lap.Retutn
C Barang Barang

Lap.Pesanan
barang

Gambar 3.11 Analisa Proses Sistem yang Dikembangkan


3.5 Kontruksi Sistem yang dikembangkan

Barcode Kasir
scanner

Swicth

Barang Pimpinan

Database

Server

Gambar 3.12 Kontruksi Sistem yang dikembangkan


3.6 Skenario Sistem yang dikembangkan

Semua aktor yang akan masuk ke sistem harus login terlebih dahulu

dengan ID Card.

Supervisor membuat surat pesanan barang ke Pusat, Pusat

mengirimkan barang ke cabang Salemba Toko Buku di Bogor. Barang

diterima dan di cek oleh admin gudang, jika ada kerusakan barang maka

admin gudang mengembalikan barang tersebut ke Pusat. Jika barang tidak

rusak, maka Admin gudang akan menginputkan penerimaan barang ke sistem,

Barang yang diinputkan oleh admin gudang tersebut akan masuk ke sistem

sehingga pimpinan dan supervisor bisa mengontrol penerimaan barang

tersebut.

Pembeli bisa mengecek harga barang dengan menyodorkan barang ke

barcode.

Pembeli membeli barang dan dibayar dikasir, kasir mengecek barang

tersebut dengan scanner barcode. Maka dengan mengecek barang

menggunakan scanner barcode, barang yang keluar bisa terlihat dari sistem

ini.
Supervisor membuat dan mencetak laporan persediaan barang,

penerimaan barang, penjualan barang, pesanan barang dan retun barang.

Laporan tersebut kemudian diserahkan kepada pimpinan untuk di tanda

tangan kemudian di arsipkan.


BAB IV

PERANCANGAN SISTEM

4.1 DiagramKonteks

Data Pesanan barang

Data Return barang


Struck Pembayaran
Look Up Persediaan
Supervisor
Lap.Persediaan barang
Pembeli Lap.Penerimaan barang
Lap.Penjualan barang
Lap.Return barang
Lap.Pesanan barang

Data Barang
Informasi Buku
Data Penerimaan barang Admin Gudang
Sistem Informasi Inventori
Barcode Cek Harga Salemba Toko Buku

Data Barang

Lap.Persediaan barang
Lap.Penerimaan barang
Lap.Penjualan barang
Pimpinan
Kasir Data Penjualan barang Lap.Pesanan barang
Lap.Return barang

Gambar 4.13 Diagram Konteks

4.2 Daftar Istilah Pelaku Bisinis

Daftar istilah pelaku bisnis mendeskripsikan aktor beserta peran.

Istilah Deskripsi
Pimpinan Bertanggung jawab atas semua kegiatan yang terjadi pada Salemba Toko
Buku dan berhak mengambil keputusan serta menerima laporan.
Supevisor Bertanggung jawab membuat surat pesanan barang, mengelola
persediaan barang, penerimaan barang, penjualan barang, dan return
barang , dan membuat laporan.
Admin Gudang Menginput data barang dan input penerimaan barang masuk.
Kasir Bertanggung jawab dalam penjualan barang menggunakan scanner
barcode.
Pembeli Membeli, Pencarian barang, membayar dan menerima struck
pembayaran.
4.3 Identifikasi Use Case

Pelaku yang
Istilah Deskripsi
Berpartisipasi
- Supervisor

- Admin Gudang
Use case ini mendeskripsikan kejadian pada saat user pertama
Login
masuk kedalam sistem.
- Kasir

- Pimpinan
Use case ini mendeskripsikan proses penginputan barang baru
Input Barang -Admin Gudang
yang dilakukan oleh Admin gudang ke sistem
Usecase ini mendeskripsikan proses penginputan data
Input Penerimaan Barang
penerimaan barang yang dilakukan oleh Admin Gudang - Adminke Gudang
dalam sistem.
Usecase ini mendeskripsikan proses penjualan barang
Penjualan Barang menggunakan scanner barcode yang dilakukan oleh -kasir Kasirke
dalam sistem.
Usecase ini mendeskripsikan proses penginputan pesanan barang
Pesanan Barang - Supervisor
yang dilakukan oleh Supervisor ke dalam sistem.
Usecase ini mendeskripsikan proses return barang yang
Return Barang - Supervisor
dilakukan oleh Supervisor ke dalam sistem.
Usecase ini mendeskipsikan proses pencarian barang yang
Pencarian Barang -Pembeli
dilakukan oleh pembeli ke dalam sistem.
- Supervisor
Look up data Penerimaan
Usecase ini mendeskripsikan proses look up data penerimaan
Barang barang berdasarkan tglpenerimaan dalam sistem.
- Pimpinan
- Supervisor
Look up data Penjualan
Usecase ini mendeskripsikan proses look up data penjualan
Barang barang berdasarkan tglpenjualan dalam sistem.
- Pimpinan
- Supervisor
Look up data Persediaan
Usecase ini mendeskripsikan proses look up data persediaan
Barang. barang berdasarkan stock barang dalam sistem.
- Pimpinan
- Supervisor
Look up data UsecasePesanan ini mendeskripsikan proses look up data pesanan
Barang. barang berdasarkan tglpesan dalam sistem.
- Pimpinan
- Supervisor
Look up data Usecase Returnini mendeskripsikan proses look up data Return barang
Barang. berdasarkan tglreturn dalam sistem.
- Pimpinan
Usecase ini mendeskripsikan proses update data yang terjadi
Update data Penerimaan
pada data penerimaan barang yang telah diinput sebelumnya
- Admin Gudang
Barang
oleh Admin gudang kedalam sistem.
Usecase ini mendeskripsikanproses update data yang terjadi
Update data Pesananpada
Barang
data pesanan barang yang telah diinput sebelumnya
- Supervisor
oleh
Supervisor kedalam sistem.
Usecase ini mendeskripsikan proses update data yang terjadi
Update data Return pada
Barang
data return barang yang telah diinput sebelumnya- Supervisor
oleh
Supervisor kedalam sistem.
- Supervisor
Usecase ini mendeskripsikan pencetakan laporan yang telah
Cetak Laporan
dikelola sebelumnya dalam sistem.
Usecase ini mendeskripsikan pencetakan Struck Pembayaran
Cetak Struck Pembayaran - Kasir
yang telah dikelola sebelumnya dalam sistem.

4.4 Use Case Naratif

4.4.1 Persyaratan Bisnis

Untuk mendeskripsikan use case dengan singkat dan tepat dan

mengetahui bagaimana user berinteraksi dengan sistem baik langsung

maupun tidak langsung digambarkan dengan use case persyaratan

bisnis seperti dibawah ini.

No ID Usecase Nama Usecase

1 1.1 Login

2 1.2 Input Barang

3 1.3 Input Penerimaan Barang

4 1.4 Penjualan Barang

5 1.5 Pesanan Barang

6 1.6 R Return Barang

7 1.7 Pencarian Barang

8 1.8 Look up data Penerimaan Barang

9 1.9 Look up data Penjualan Barang

10 1.10 Look up data Persediaan barang

11 1.11 Look up data Pesanan barang

12 1.12 Look up data Return barang

13 1.13 Update data Penerimaan Barang

14 1.14 Update data Pesanan Barang

15 1.15 Update data Return Barang

16 1.16 Cetak laporan


17 1.17 Cetak Struck Pembayaran

4.4.1.1 Persyaratan Bisnis Login

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Login Tipe Use Case

ID Use Case : 1.1

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor, Admin Gudang, Pimpinan, Kasir.

Pelaku Partisipan Lain : -

Stake holder yang berminat lain


- :

Use case ini mendeskripsikan kejadian pada saat user


Deskripsi :
pertama masuk kedalam sistem.

4.4.1.2 Persyaratan Bisnis Input Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Input Barang Tipe Use Case

ID Use Case : 1.2

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Admin Gudang

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses penginputan data
Deskripsi : barang baru yang dilakukan oleh Admin Gudang ke
dalam sistem.

4.1.1.3 Persyaratan Bisnis Input Penerimaan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Input Penerimaan Barang


Tipe Use Case

ID Use Case : 1.3

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Admin Gudang

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses penginputan data
Deskripsi : penerimaan barang yang dilakukan oleh Admin
Gudang ke dalam sistem.

4.1.1.4 Persyaratan Bisnis Penjualan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Penjualan Barang Tipe Use Case

ID Use Case : 1.4

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Kasir

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses penjualan barang
Deskripsi : menggunakan barcode yang dilakukan oleh kasir ke
dalam sistem.
4.1.1.5 Persyaratan Bisnis Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Pesanan Barang Tipe Use Case

ID Use Case : 1.5

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses penginputan
Deskripsi : pesanan barang yang dilakukan oleh Supervisor ke
dalam sistem.

4.4.1.6 Persyaratan Bisnis Return Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Return Barang Tipe Use Case

ID Use Case : 1.6

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Use case ini mendeskripsikan return barang yang
Deskripsi :
dilakukan oleh Supervisor ke dalam sistem.

4.4.1.7 Persyaratan Bisnis Pencarian Barang


Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Pencarian barang Tipe Use Case

ID Use Case : 1.7

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Pembeli

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Use case ini mendeskipsikan proses pencarian barang
Deskripsi :
yang dilakukan oleh pembeli ke dalam sistem.

4.4.1.8 Persyaratan Bisnis Look up Data Penerimaan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Look up Data Penerimaan


Nama Use Case : Tipe Use Case
Barang
ID Use Case : 1.8

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor, Pimpinan

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses look up data
Deskripsi : penerimaan barang berdasarkan tglpenerimaan dalam
sistem.

4.4.1.9 Persyaratan Bisnis Look up Data Penjualan Barang


Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Look up Data Penjualan


Nama Use Case : Tipe Use Case
Barang
ID Use Case : 1.9

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor, Pimpinan

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses look up data
Deskripsi : penjualan barang berdasarkan tglpenjualan dalam
sistem.

4.4.1.10 Persyaratan Bisnis Look up Data Persediaan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Look up Data Persediaan


Nama Use Case : Tipe Use Case
Barang
ID Use Case : 1.10

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor, Pimpinan

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses look up data
Deskripsi : persediaan barang berdasarkan stock barang dalam
sistem
4.4.1.11 Persyaratan Bisnis Look up Data Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Look up Data Pesanan


Nama Use Case : Tipe Use Case
Barang
ID Use Case : 1.11

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor, Pimpinan

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses look up data
Deskripsi :
pesanan barang berdasarkan tglpesan dalam sistem.

4.4.1.12 Persyaratan Bisnis Look up Data Return Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up Data Return Tipe


Barang
Use Case

ID Use Case : 1.12

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor, Pimpinan

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses look up data return
Deskripsi :
barang berdasarkan tgtlreturn dalam sistem
4.4.1.13 Persyaratan Bisnis Update Data Penerimaan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Update Data Penerimaan


Nama Use Case : Tipe Use Case
Barang
ID Use Case : 1.13

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Admin Gudang

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses update data yang
Deskripsi : terjadi pada data penerimaan barang yang telah diinput
sebelumnya oleh Admin gudang kedalam sistem.

4.4.1.14 Persyaratan Bisnis Update Data Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Update Data PesananTipe


Barang
Use Case

ID Use Case : 1.14

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses update data yang
Deskripsi : terjadi pada data pesanan barang yang telah diinput
sebelumnya oleh Supervisor kedalam sistem.
4.4.1.15 Persyaratan Bisnis Update Data Return Barang

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Update Data Return Barang


Tipe Use Case

ID Use Case : 1.15

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan proses update data yang
Deskripsi : terjadi pada data return barang yang telah diinput
sebelumnya oleh Supervisor kedalam sistem.

4.4.1.16 Persyaratan Bisnis Cetak laporan

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Cetak laporan Tipe Use Case

ID Use Case : 1.16

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Supervisor

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase inimendeskripsikan pencetakan laporan yang
Deskripsi :
telah dikelola sebelumnya dalam sistem.
4.4.1.17 Persyaratan Bisnis Cetak Struck Pembayaran

Pengarang : 1. Meli Amelia Tanggal : 16 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Cetak Struck Pembayaran


Tipe Use Case

ID Use Case : 1.17

Prioritas : Tinggi Persyaratan Bisnis : 

Sumber : -

Pelaku Bisnis Utama : Kasir

Pelaku Partisipan Lain : -

Stakeholder yang berminat lain- :


Usecase ini mendeskripsikan pencetakan Struck
Deskripsi : Pembayaran yang telah dikelola sebelumnya dalam
sistem.

4.4.2 Analisis Sistem

4.4.2.1 Analisis Sistem Login

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014


2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Login Tipe Use Case


ID Use Case : 1.1 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor, Admin Gudang, Pimpinan, Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian pada saat user
Deskripsi :
pertama masuk kedalam sistem.
User telah memiliki user name dan passwordnya masing-
Prakondisi :
masing yang sudah secara otomatis sudah ada di ID Card.
Use case ini dilakukan untuk memastikan bahwa sistem
Pemicu : hanya digunakan oleh user yang telah diberi hak akses
berdasarkan kepentingannya.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User mengscankan IDCard


Sistem
yang akan memproses dan
sudah ada username menampilkan
dan menu utama yaitu
password yang bertipeMenu
barcodeTransaksi, Transaksi dan
pada barcode Scanner. menu Laporan .

jika validasi IDCard dimasukkan


adalah valid.
BidangKhasSuatu Event : Langkah 3 :

Apabila pilihan user mengklik


tombol Cancel. Langkah 4 :

Sistem akan menghentikan proses


Login.

Alternatif Langkah 2:
2.1 Sistem akan menampilkan pesan kesalahan jika
Bidang Alternatif : kombinasi IDCard tidak valid, dan meminta pengguna
untuk mengscankan barcode yang ada pada IDCard
dengan benar.
Use-case ini menyimpulkan bagaimana langkah awal user
Kesimpulan :
hendak menggunakan sistem sesuai hak aksesnya.
User masuk dan menggunakan sistem sesuai hak akses
Postkondisi :
pelaku.
Aturan Bisnis : IDCard harus dimasukkan dengan data yang valid.
Batasan Dan Spesifikasi
Hanya user yang mempunyai hak akses saja yang bisa
Implementasi : masuk kedalam sistem.
Asumsi : User telah memiliki IDCard.
Masalah Terbuka : User lupa/hilang IDCard .

4.4.2.2 Analisis Sistem Input Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014


2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Input Barang Tipe Use Case


ID Use Case : 1.2 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
menambah/input data barang baru.
User telah memiliki data barang baru yang akan
Prakondisi :
diinputkan.
Use case ini dimulai saat user menyeleksi pilihan input
Pemicu :
data barang untuk menambah/input data barang baru .
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Pilih menu Master


Sistemdan merespon dengan
kliksub menu barang. menampilkan form inputan
barang.

Langkah 3:
Langkah 4 :
User Masukkan data barang
baru kedalam field yang
Sistem
sudah merespon dengan
disediakan dengan benar.
menyimpan data barang baru yang
telah diinputkan tersebut kedalam
database sistem dan menampilkan
BidangKhasSuatu Event : kembali informasi yang telah
Langkah 5 : terupdate kedalam Display
Informasi data.
Cek semua data barang yang
sudah dimasukkan, bila tidak ada
perubahan maka user
melanjutkan denganLangkahklik6:
tombol[Simpan].
Sistem merespon dengan
menutup From Barang dan
menampilkan Form utama.
Alternatif Langkah 4:
Bidang Alternatif : 4.1 Jika sistem merespon bahwa penyimpanan gagal data
tidak lengkap maka user harus melengkapi data yang
diperlukan dan kembali ke langkah 3.
Usecase ini menyimpulkan bagaimana langkah input
Kesimpulan :
barang oleh admin gudang.
Data barang telah disimpan dan telah terupdate, dan sistem
Postkondisi :
menampilkan kembali Form Utama.
Aturan Bisnis : User sudah menyiapkan data barang yang valid.
Batasan Dan Spesifikasi
Admin Gudang hanya menginput barang.
Implementasi :
Hanya Admin gudang yang dapat melakukan penginputan
Asumsi :
barang.
Masalah Terbuka : -

4.4.2.3 Analisis Sistem Input Penerimaan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014


2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Input Penerimaan Barang


Tipe Use Case
ID Use Case : 1.3 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
menambah/input data penerimaan barang.
User telah memiliki data penerimaan barang yang akan
Prakondisi :
diinputkan.
Use case ini dimulai saat user menyeleksi pilihan input
Pemicu : data barang untuk menambah/input data penerimaan
barang .
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Pilih menu Transaksi


Sistemdan merespon dengan
kliksub menu penerimaan
menampilkan form inputan
barang. penerimaan barang.

Langkah 3: Langkah 4 :

User Masukkan Sistem


data merespon dengan
penerimaan barang menyimpan
kedalam data penerimaan
field yang sudah disediakan
barang yang telah diinputkan
BidangKhasSuatu Event : dengan benar. tersebut kedalam database sistem
dan menampilkan kembali
informasi yang telah terupdate
kedalam Display Informasi data.
Langkah 5 :

Cek semua data barang masuk


Langkah
yang sudah dimasukkan, bila6:
tidak ada perubahan maka user
melanjutkan denganSistem
klik merespon dengan
tombol[Simpan]. menutup From Penerimaan
Barang dan menampilkan Form
utama.
Alternatif Langkah 4:
Bidang Alternatif : 4.1 Jika sistem merespon bahwa penyimpanan gagal data
tidak lengkap maka user harus melengkapi data yang
diperlukan dan kembali ke langkah 3.
Usecase ini menyimpulkan bagaimana langkah input
Kesimpulan :
penerimaan barang oleh admin gudang.
Data barang telah disimpan dan telah terupdate, dan sistem
Postkondisi :
menampilkan kembali Form Utama.
User sudah menyiapkan data penerimaan barang yang
Aturan Bisnis :
valid.
Batasan Dan Spesifikasi
Admin Gudang hanya menginput penerimaan barang.
Implementasi :
Hanya Admin gudang yang dapat melakukan penginputan
Asumsi :
penerimaan barang.
Masalah Terbuka : -

4.4.2.4 Analisis Sistem Penjualan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014


2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Penjualan Barang Tipe Use Case


ID Use Case : 1.4 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi : menambah data penjualan barang dengan mengescan
barcode barang.
User telah memiliki data penjualan barang yang akan
Prakondisi :
diinputkan menggunakan scanner barcode.
Use case ini dimulai saat user menyeleksi pilihan input
Pemicu :
data penerimaan barang untuk menambah data penjualan
barang.

Kegiatan Pelaku Respons Sistem


Langkah 1 : Langkah 2:

Pilih menu Transaksi Sistem


dan klik merespon dengan
sub menu penjualan barang.
menampilkan form inputan
penjualan barang.

Langkah 3: Masukkan data


barang keluar Langkah
dengan5 :
mengescankan barcode barang
menggunakan alat Sistem
scanner merespon dengan
barcode ke dalam field yang struck pembayaran.
mencetak
sudah disediakan dengan benar.
BidangKhasSuatu Event :

Langkah 6 :
Langkah 4 :
Setelah sistem mencetakstruck
Cek semua data penjualan
pembayaran maka Sistem akan
barang yang sudah dimasukkan,
menyimpan data penjualan barang
bila tidak ada perubahan
yangmakatelah diinputkan dengan
user melanjutkan dengan klikbarcode tersebut kedalam
scanner
tombol[Bayar]. database sistem dan menampilkan
kembali informasi yang telah
terupdate kedalam Display
Informasi data.

Alternatif Langkah 5:

5.1 Jika Sistem tidak bisa membaca barcode barang ,


karena ketidakjelasan barcode, maka user harus
Bidang Alternatif : menginputkan kodebarcode barang kedalam field yang
sudah disediakan.

Use-case ini menyimpulkan bagaimana langkah input data


Kesimpulan :
penjualan barang oleh Kasir.
Data barang telah dibayar dan disimpan dan telah
Postkondisi : terupdate, dan sistem menampilkan kembali Form Input
Penjualan barang.
User sudah menyiapkan alat scanner barcode untuk
Aturan Bisnis :
menscanbarcode yang valid.
Kasir hanya menginput data penjualan barang dengan
Batasan Dan Spesifikasi
mengscanbarcode pada kodebarcode barang untuk
Implementasi :
transaksi penjualan barang.
Hanya Kasir yang dapat melakukan penginputan data
Asumsi :
transaksi penjualan barang.
Masalah Terbuka : -
4.4.2.5 Analisis Sistem Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014


2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Pesanan Barang Tipe Use Case


ID Use Case : 1.5 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
mengPesanan Barang .
User Telah memiliki data pesanan barang yang akan
Prakondisi :
diinputkan.
Use case ini dimulai saat user meyeleksi pilihan input data
Pemicu :
pesanan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Pilih menu Transaksi


Sistemdan merespon dengan
kliksub menu input datamenampilkan
pesanan form input data
barang. pesanan barang.

Langkah 3: Langkah 4 :

User Masukkan data Sistem


pesanan merespon dengan
barang kedalam field
menyimpan
yang data pesanan barang
BidangKhasSuatu Event :
sudah disediakan dengan
yang
benar.
telah diinputkan tersebut
kedalam database sistem dan
menampilkan kembali informasi
yang telah terupdate kedalam
Display Informasi data.
Langkah 5 :

Cek semua data barang pesanan


yang sudah dimasukkan, bila
Langkah
tidak ada perubahan maka user6:
melanjutkan dengan klik
tombol[Simpan]. Sistem merespon dengan
menutup From input pesanan Data
Barang dan menampilkan Form
utama.
Alternatif Langkah 4 :
Bidang Alternatif :
4.1 Jika sistem merespon bahwa penyimpanan gagal data
tidak lengkap maka user harus melengkapi data yang
diperlukan dan kembali ke langkah 3.

Use-case ini menyimpulkan bagaimana langkah Pesanan


Kesimpulan :
Barang oleh Supervisor.
Data barang yang sudah diinputkan akan disimpan dan
Postkondisi : akan terupdate,dan sistem menampilkan kembali Form
Input Pesanan Barang.
User harus memiliki IDCard yang sudah secara otomatis
terdapat username dan password untuk login.
Aturan Bisnis :

Batasan Dan Spesifikasi


Supervisor hanya menginput data Pesanan Barang.
Implementasi :
Hanya Supervisor yang dapat melakukan penginputan
Asumsi :
dataPesanan barang .
Masalah Terbuka : -

4.4.2.6 Analisis Sistem Return Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014


2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Return Barang Tipe Use Case


ID Use Case : 1.6 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
Return Barang.
User telah memiliki data return barang yang akan
Prakondisi :
diinputkan.
Use case ini dimulai saat user menyeleksi pilihan input
Pemicu : data return barang untuk menambah, merubah, dan
menghapus data barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :
BidangKhasSuatu Event :
User Pilih menu Transaksi
Sistemdan merespon dengan
kliksub menu input data
menampilkan
return form input data
barang. return barang.

Langkah 3: Langkah 4 :

User Masukkan data Sistem return merespon dengan


barang kedalam field
menyimpan
yang data return barang
sudah disediakan denganyang
benar.telah diinputkan tersebut
kedalam database sistem dan
menampilkan kembali informasi
yang telah terupdate kedalam
Display Informasi data.
Langkah 5 :

Cek semua data return barang


yang sudah dimasukkan, bila
Langkah
tidak ada perubahan maka user6:
melanjutkan dengan klik
tombol[Simpan]. Sistem merespon dengan
menutup From input Data return
Barang dan menampilkan Form
utama.
Alternatif Langkah 4:
Bidang Alternatif : 4.1 Jika sistem merespon bahwa penyimpanan gagal data
tidak lengkap maka user harus melengkapi data yang
diperlukan dan kembali ke langkah 3.
Usecase ini menyimpulkan bagaimana langkah input data
Kesimpulan :
return barang oleh Supervisor.
Data barang telah disimpan dan telah terupdate, dan sistem
Postkondisi :
menampilkan kembali Form Utama.
Aturan Bisnis : User sudah menyiapkan data return barang yang valid.
Batasan Dan Spesifikasi
Supervisor hanya menginput data return barang.
Implementasi :
Hanya Supervisor yang dapat melakukan penginputan data
Asumsi :
return barang.
Masalah Terbuka : -

4.4.2.7 Analisis Sistem Pencarian Baranng

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Pencarian barang Tipe Use Case


ID Use Case : 1.7 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Pembeli
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
untuk pencarian barang .
Prakondisi : -
Pemicu : Use case ini dimulai saat user mencari barang
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User menginputkan data


Sistem
barang merespon dengan
yang akan dicari menampilkan informasi barang
BidangKhasSuatu Event : yang dicari user

Alternatif Langkah 2 :

2.1 Jika sistem tidak merespon maka pencarian barang


gagal karena barang yang dicari tidak tersedia dan
Bidang Alternatif : kembali ke langkah 1.

Use-case ini menyimpulkan bagaimana langkah pencarian


Kesimpulan :
barang oleh Pembeli.
Pencarian barang sudah dicari maka sistem akan
menampilkan kembali form pencarian barang
Postkondisi :

Aturan Bisnis : -
pembeli hanya menginputkan data barang yang akan
dicari.
Batasan Dan Spesifikasi
Implementasi :

Pembeli yang dapat pencarian barang.


Asumsi :

Masalah Terbuka : -
4.4.2.8 Analisis Sistem Look up Data Penerimaan barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up data barang masuk


Tipe Use Case
ID Use Case : 1.8 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 

Sumber :

Pelaku Bisnis Utama : Supervisor, Pimpinan

Pelaku Partisipan Lain :

Stakeholder yang berminat lain :

Usecase ini mendeskripsikan proses look up data


Deskripsi : penerimaan barang berdasarkan tglpenerimaan dalam
sistem.
Memastikan apakah data penerimaan barang yang akan di
Prakondisi :
look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up penerimaan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Pilih menu View Sistem


dan klik merespon dengan
submenu data penerimaan
menampilkan form data barang
barang masuk.

BidangKhasSuatu Event :

Langkah 3: Langkah 4 :

User memasukan tglpenerimaan


Sistem akan secara otomatis
. mencari data penerimaan barang
yang telah tersimpan.
Langkah 5 : Langkah 6:

User mengklik data barang


Sistem
yangakan menampilkan data
dicari. barang masuk yang di cari.

Alternatif langkah 3 :

3.1 jika tglpenerimaan yang dimasukan tidak sesuai


Bidang Alternatif : dengan yang ada di database, maka sistem akan muncul
informasi bahwa tglpenerimaan yang dimasukan tidak ada
dalam database dan tidak dapat ditampilkan.

Usecase ini menyimpulkan tentang kegiatan look up data


Kesimpulan :
penerimaan barang.
Postkondisi : Data penerimaan barang yang dicari akan ditampilkan.
Tglpenerimaan yang dimasukan harus sesuai dengan
Aturan Bisnis :
format yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data penerimaan barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data penerimaan barang.
Masalah Terbuka : -

4.4.2.9 Analisis Sistem Look up Data Penjualan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up data penjualanTipe


barang
Use Case
ID Use Case : 1.9 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data
Deskripsi :
penjualan barang berdasarkan tglpenjualan dalam sistem.
Memastikan apakah data penjualan barang yang akan di
Prakondisi :
look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up penjualan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Pilih menu ViewSistem


barang merespon dengan
dan kliksubmenu data Penjualan
menampilkan form data barang
barang. keluar.

Langkah 3: Langkah 4 :
BidangKhasSuatu Event :
User memasukan tglpenjualan.
Sistem akan secara otomatis
mencari data penjualan barang
yang telah tersimpan.

Langkah 5 :

Langkah 6:
User mengklik data penjualan
barang yang dicari.
Sistem akan menampilkan data
penjualan barang yang di cari.
Alternatif langkah 3 :

3.1 jika tglpenjualan yang dimasukan tidak sesuai dengan


Bidang Alternatif : yang ada di database, maka sistem akan muncul informasi
bahwa tglpenjualan yang dimasukan tidak ada dalam
database dan tidak dapat ditampilkan.

Usecase ini menyimpulkan tentang kegiatan look up data


Kesimpulan :
penjualan barang.
Postkondisi : Data penjualan barang yang dicari akan ditampilkan.
tglpenjualan yang dimasukan harus sesuai dengan format
Aturan Bisnis :
yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data penjualan barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data penjualan barang.
Masalah Terbuka : -
4.4.2.10 Analisis Sistem Look up Data Persediaan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up Persediaan barang


Tipe Use Case
ID Use Case : 1.10 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data barang
Deskripsi :
Persediaan barang berdasarkan stockbarang dalam sistem.
Memastikan apakah data persediaan barang yang akan di
Prakondisi :
look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look persediaan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Pilih menu ViewSistem


barang merespon dengan
dan kliksub menumenampilkan
data form data
PersediaanBarang . Persediaan barang .

Langkah 3: Langkah 4 :
BidangKhasSuatu Event :
User memasukan stock Sistem
minimal akan secara otomatis
barang . mencari data stock minimal
barang yang telah yang tersimpan.

Langkah 5 :
Langkah 6:
User mengklik data stock
persediaan barang . Sistem akan menampilkan data
stock persediaan barang .

Alternatif langkah 3 :
Bidang Alternatif :
3.1 jika stockbarang yang dimasukan tidak sesuai dengan
yang ada di database, maka akan muncul informasi bahwa
stock barang yang dimasukan tidak ada dalam database
dan tidak dapat ditampilkan.

Usecase ini menyimpulkan tentang kegiatan look up data


Kesimpulan :
persediaan barang.
Postkondisi : Data persediaan barang yang dicari akan ditampilkan.
Stock barang yang dimasukan harus sesuai dengan format
Aturan Bisnis :
yang telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data persediaan barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data barang persediaan barang.
Masalah Terbuka : -

4.4.2.11 Analisis Sistem Look up Data Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up Pesanan barang


Tipe Use Case
ID Use Case : 1.11 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data Pesanan
Deskripsi :
barang berdasarkan tglpesan dalam sistem.
Memastikan apakah data Pesanan barang yang akan di
Prakondisi :
look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up Pesanan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

BidangKhasSuatu Event : User Pilih menu ViewSistem


barang merespon dengan
dan kliksub menu datamenampilkan
Pesanan form data Pesanan
barang . barang .
Langkah 3: Langkah 4 :

User memasukan tglpesan


Sistem
. akan secara otomatis
mencari data Pesanan barang yang
telah yang tersimpan.

Langkah 5 :

User mengklik data Langkah


Pesanan6:
Barang.
Sistem akan menampilkan data
pesanan barang .
Alternatif langkah 3 :

3.1 jika tglpesan yang dimasukan tidak sesuai dengan


Bidang Alternatif : yang ada di database, maka akan muncul informasi bahwa
tglpesan yang dimasukan tidak ada dalam database dan
tidak dapat ditampilkan.
Usecase ini menyimpulkan tentang kegiatan look up data
Kesimpulan :
Pesanan barang.
Postkondisi : Data Pesanan barang yang dicari akan ditampilkan.
tglpesan yang dimasukan harus sesuai dengan format yang
Aturan Bisnis :
telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data Pesanan barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data barang Pesanan barang.
Masalah Terbuka : -

4.4.2.12 Analisis Sistem Look up Data Return Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up return barangTipe Use Case


ID Use Case : 1.12 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data barang
Deskripsi :
return barang berdasarkan tglreturn dalam sistem.
Memastikan apakah data return barang yang akan di look
Prakondisi :
up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up return barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Pilih menu ViewSistem


barang merespon dengan
dan kliksub menu data
menampilkan
return form data return
Barang. barang.

Langkah 3: Langkah 4 :
BidangKhasSuatu Event :
User memasukan tglreturn.
Sistem akan secara otomatis
mencari data return barang yang
telah tersimpan.

Langkah 5 :

User mengklik dataLangkah


return6:
barang yang dicari.
Sistem akan menampilkan data
return barang yang di cari.
Alternatif langkah 3 :

3.1 jika tglreturn yang dimasukan tidak sesuai dengan


Bidang Alternatif :
yang ada di database, maka akan muncul informasi bahwa
tglreturn yang dimasukan tidak ada dalam database dan
tidak dapat ditampilkan.
Usecase ini menyimpulkan tentang kegiatan look up data
Kesimpulan :
return barang.
Postkondisi : Data return barang yang dicari akan ditampilkan.
tglreturn yang dimasukan harus sesuai dengan format yang
Aturan Bisnis :
telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data return barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data return barang.
Masalah Terbuka : -
4.4.2.13 Analisis Sistem Update data Penerimaan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Update penerimaan barang


Tipe Use Case
ID Use Case : 1.13 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses update data penerimaan
Deskripsi : barang yang terjadi pada data penerimaan barang yang
telah diinput.
Memastikan Admin Gudang telah terhubung dengan data
Prakondisi : penerimaan barang yang akan di edit/update yang telah
diinput sebelumnya kedalam sistem.
Usecase ini diinisiasi saat Admin Gudang akan melakukan
Pemicu : proses update edit/ data barang masuk yang telah diinput
sebelumnya kedalam sistem.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :

User Pilih menu Transaksi


Sistemdan merespon dengan
kliksub menu penerimaan
menampilkan form data penerimaan
barang. barang

BidangKhasSuatu Event : Langkah 4 : Langkah 6:

User mengubah dataData


barang
penerimaan barang yang
yang akan diubah. datanya telah di ubah akan tersimpan
kembali kedalam database.

Langkah 5 :

User mengklik tombol update.


Alternatif langkah 5 :

Bidang Alternatif : 5.1 jika data barang yang di update/edit tidak sesuai, maka
akan muncul pesan pemberitahuan untuk memasukan data
barang masuk yang benar.
Usecase ini menyimpulkan tentang kegiatan update/edit
Kesimpulan : data barang masuk yang dilakukan oleh oleh Admin
Gudang.
Hasil proses update data barang masuk akan dimasukan
Postkondisi :
kedalam database.
 Data yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi.
Batasan Dan Spesifikasi
Admin Gudang hanya mengubah databarang masuk.
Implementasi :
Hanya admin gudang yang dapat melakukan update/edit
Asumsi :
data barang masuk.
Masalah Terbuka : -

4.4.2.14 Analisis Sistem Update data Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Update Pesanan barang


Tipe Use Case
ID Use Case : 1.14 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses update data pesanan
Deskripsi : barang yang terjadi pada data barang pesanan yang telah
diinput.
Memastikan Supervisor telah terhubung dengan data
Prakondisi : pesanan barang yang akan di edit/update yang telah diinput
sebelumnya kedalam sistem.
Usecase ini diinisiasi saat Supervisor akan melakukan
Pemicu : proses update edit/ data pesanan barang yang telah diinput
sebelumnya kedalam sistem.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :
BidangKhasSuatu Event :
User Pilih menu Transaksi
Sistem merespon dengan
barang dan kliksub menu data
pesanan barang. menampilkan form pesanan barang.

Langkah 4 : Langkah 6:

User mengubah data Data


pesanan
pesanan barang yang datanya
barang yang akan diubah.
telah di ubah akan tersimpan kembali
kedalam database.

Langkah 5 :

User mengklik tombol update.


Alternatif langkah 5 :

5.1 jika data pesanan barang yang di update/edit tidak


Bidang Alternatif : sesuai, maka akan muncul pesan pemberitahuan untuk
memasukan data pesanan barang yang benar.

Usecase ini menyimpulkan tentang kegiatan update/edit


Kesimpulan :
data pesanan barang yang dilakukan oleh Supervisor.
Hasil proses update data pesanan barang akan dimasukan
Postkondisi :
kedalam database.
 Data yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi.
Batasan Dan Spesifikasi
Supervisor hanya mengubah data pesanan barang.
Implementasi :
Hanya Supervisor yang dapat melakukan update/edit data
Asumsi :
pesanan barang.
Masalah Terbuka : -

4.4.2.15 Analisis Sistem Update data Return Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Update Return barang


Tipe Use Case
ID Use Case : 1.15 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses update data return
Deskripsi : barang yang terjadi pada data barang return yang telah
diinput.
Memastikan Supervisor telah terhubung dengan data return
Prakondisi : barang yang akan di edit/update yang telah diinput
sebelumnya kedalam sistem.
Usecase ini diinisiasi saat Supervisor akan melakukan
Pemicu : proses update edit/ data return barang yang telah diinput
sebelumnya kedalam sistem.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :

User Pilih menu Transaksi


Sistem merespon dengan
barang dan kliksub menu
menampilkan
data form return barang.
return barang.

Langkah 6:
Langkah 4 :
BidangKhasSuatu Event : Data return barang yang datanya
User mengubah datatelah return
di ubah akan tersimpan kembali
barang yang akan diubah.
kedalam database.

Langkah 5 :

User mengklik

tombol update.
Alternatif langkah 5 :

Bidang Alternatif : 5.1 jika data return barang yang di update/edit tidak sesuai,
maka akan muncul pesan pemberitahuan untuk memasukan
data return barang yang benar.
Usecase ini menyimpulkan tentang kegiatan update/edit
Kesimpulan :
data return barang yang dilakukan oleh Supervisor.
Hasil proses update data return barang akan dimasukan
Postkondisi :
kedalam database.
 Data yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi.
Batasan Dan Spesifikasi
Supervisor hanya mengubah data return barang.
Implementasi :
Hanya Supervisor yang dapat melakukan update/edit data
Asumsi :
return barang.
Masalah Terbuka : -
4.4.2.16 Analisis Sistem Cetak laporan

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Cetak laporan Tipe Use Case


ID Use Case : 1.16 Persyaratan Bisnis : □
Prioritas : Tinggi Analisis Sistem : 
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan pencetakan laporan yang
Deskripsi :
telah dikelola sebelumnya dalam sistem.
Prakondisi : Data atau laporan yang akan dicetak harus tersedia.
Pemicu : Usecase ini diinisiasi saat proses pencetakan laporan.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :

User mengklik menu laporan


Sistemdan merespon dengan
pilih dan klik jenis laporan
menampilakan
yang form laporan yang
dipilih. dipilih.

BidangKhasSuatu Event :

Langkah 3: Langkah 7 :

User mengatur tanggalSistem


laporanakan merespon perintah
yang akan di cetak. dan printer akan mencetak
laporan.
Langkah 6 :

User mengklik tombol view.

Langkah 8 :

User mengklik tombol


cetak/print.
Alternatif langkah 3 :
Bidang Alternatif :
3.1 Jika data atau laporan yang dipilih tidak tersedia maka
sistem akan memberikan pemberitahuan.
Usecase ini menyimpulkan tentang kegiatan pencetakan
Kesimpulan :
laporan.
Laporan yang telah dicetak akan diserahkan kepada
Postkondisi :
Pimpinan.
Data atau laporan yang akan dicetak harus ada pada
Aturan Bisnis :
database.
Batasan Dan Spesifikasi
Supervisor hanya mencetak laporan.
Implementasi :
Asumsi : Hanya Supervisor yang dapat mencetak laporan.
Masalah Terbuka : -

4.4.2.17 Analisis Sistem Cetak Struck Pembayaran

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Cetak Struk Pembayaran


Tipe Use Case
ID Use Case : 1.17 Persyaratan Bisnis : □
Prioritas : Sedang Analisis Sistem : 
Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase inimendeskripsikan pencetakan struk biaya yang
Deskripsi :
telah dikelola sebelumnya dalam sistem.
Prakondisi : Pembeli membayar kepada Kasir.
Pemicu : Usecase ini diinisiasi saat proses pencetakan struk biaya.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2:

User mengklik tombol view.


Sistem akan secara otomatis
menampilkan data transaksi
pembayaran.
BidangKhasSuatu Event :
Langkah 3 :

User mengklik Langkah


tombol4 :
cetak/print.
Sistem akan merespon perintah
dan printer akan mencetak struk
Pembayaran.
Alternatif langkah 2 :
Bidang Alternatif :
2.1 Jika data transaksi pembayaran yang dipilih tidak
tersedia maka sistem akan memberikan pemberitahuan.
Usecase ini menyimpulkan tentang proses pencetakan
Kesimpulan :
struk pembayaran.
Postkondisi : Struk pembayaran pembeli.
Aturan Bisnis : Pembeli harus terlebih dahulu membayar kepada kasir.
Batasan Dan Spesifikasi
Kasir hanya mencetak struk pembayaran.
Implementasi :
Asumsi : Hanya kasir yang dapat mencetak struk pembayaran.
Masalah Terbuka : -

4.4.3 Desain Sistem

4.4.3.1 Desain Sistem Login

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Login Tipe Use Case


ID Use Case : 1.1 Persyaratan Bisnis : □
Prioritas : Tinggi Desain Sistem : 
Sumber :
Pelaku Bisnis Utama : Supervisor, Admin Gudang, Pimpinan, Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian pada saat user
Deskripsi :
pertama masuk kedalam sistem.
User telah memiliki user name dan passwordnya masing-
Prakondisi :
masing yang sudah secara otomatis sudah ada di Idcard.
Use case ini dilakukan untuk memastikan bahwa sistem
Pemicu : hanya digunakan oleh user yang telah diberi hak akses
berdasarkan kepentingannya.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User Mengscankan barcode


Sistem
yang akan memproses dan
terdapat pada IDCard menampilkan
yang menu utama jika
sudah ada username validasi
dan IDCard dimasukkan
password(Form 1) adalah valid(form2).
BidangKhasSuatu Event :

Langkah 3 : Langkah 4 :

Apabila user membatalkan


Sistem akan menghentikan proses
untuk mengklik Login.
tombol
Cancel(Button).

Alternatif Langkah 2:
Bidang Alternatif : 2.1 Sistem akan menampilkan pesan kesalahan jika
kombinasi IDCard tidak valid, dan meminta pengguna
untuk scankan IDCard yang benar.
Use-case ini menyimpulkan bagaimana langkah awal user
Kesimpulan :
hendak menggunakan sistem sesuai hak aksesnya.
User masuk dan menggunakan sistem sesuai hak akses
Postkondisi :
pelaku.
Aturan Bisnis : IDCard harus dimasukkan dengan data yang valid.
Batasan Dan Spesifikasi
Hanya user yang mempunyai hak akses saja yang bisa
Implementasi : masuk kedalam sistem.
Asumsi : User telah memiliki IDCard.
Masalah Terbuka : User lupa/hilang IDCard .

4.4.3.2 Desain Sistem Input Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Input barang Tipe Use Case


ID Use Case : 1.2 Persyaratan Bisnis : □
Prioritas : Tinggi Desain Sistem : 
Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
menambah/input data barang.
Prakondisi : User telah memiliki data barang yang akan diinputkan
Use case ini dimulai saat user menyeleksi pilihan input data
Pemicu :
barang untuk menambah/input data barang .
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

Pilih menu Master dan klik sub


Sistem
menu merespon dengan
input data barang. menampilkan form inputan
barang (Form 3).

Langkah 3:
Langkah 5 : Sistem merespon
dengan menyimpan data barang
User memasukan Kodebarcode(Text
yangStock
Box), Kategori (Text box), telah diinputkan tersebut
kedalam
(TextBox), dan Harga(TextBox) database sistem dan
menampilkan kembali informasi
BidangKhasSuatu Event : yang telah terupdate kedalam
Display Informasi data
Langkah 4 :
(DataGridView).
Cek semua data barang yang sudah
dimasukkan, bila tidak ada
perubahan maka user melanjutkan
dengan klik tombol[Simpan](Button)

Alternatif langkah 3 :

3.1 KodeBarcode tidak boleh kosong (not null)

3.2 Kategori tidak boleh kosong (not null)


Bidang Alternatif :
3.3 Stock tidak boleh kosong(not null)

3.4 Harga tidak boleh kosong (not null)


Alternatif 5:
5.1 jika data barang yang dimasukan tidak sesuai, maka akan
muncul pesan pemberitahuan untuk memasukan data barang
yang benar.
Use-case ini menyimpulkan bagaimana langkah input data
Kesimpulan :
barang oleh admin gudang.
Data barang telah disimpan dan telah terupdate, dan sistem
Postkondisi :
menampilkan kembali ke Form input barang.
 Kode Barcode yang dimasukan harus
Aturan Bisnis : sesuai dengan format yang telah
ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
Admin Gudang hanya menginput data barang.
Implementasi :
Hanya Admin gudang yang dapat melakukan penginputan
Asumsi :
data barang.
-
Masalah Terbuka :

4.4.3.3 Desain Sistem Input Penerimaan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Input Penerimaan barang Tipe Use Case


ID Use Case : 1.3 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama :Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat
lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
menambah/input data penerimaan barang.
User telah memiliki data penerimaan barang yang akan
Prakondisi :
diinputkan
Use case ini dimulai saat user menyeleksi pilihan input data
Pemicu :
barang untuk menambah/input data penerimaan barang .
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

Pilih menu Transaksi dan klik sub


Sistem
menu merespon dengan
input penerimaan barang. menampilkan form inputan
penerimaan barang (Form 4).

Langkah 3:
Langkah 5 : Sistem merespon
dengan
User mengklik TabControl Penerimaan menyimpan data
dan Detail Perimaan lalu penerimaan barang masuk yang
telah diinputkan tersebut
kedalam database sistem dan
User memasukan
menampilkan kembali
informasi yang telah terupdate
tglpenerimaan(DateTimePicker), kedalam
barcodeDisplay Informasi data
(TextBox),
(DataGridView).
nopenerimaan(Text Box),
nopesan(TextBox),
QTYpenerimaan(TextBox).

Langkah 4 :

Cek semua data penerimaan barang


masuk yang sudah dimasukkan, bila tidak
ada perubahan maka user melanjutkan
dengan klik tombol[Simpan](Button).

Alternatif langkah 3 :

3.1 tglpenerimaan tidak boleh kosong (not null)

3.2 KodeBarcode tidak boleh kosong (not null)

3.3 Nopenerimaan tidak boleh kosong(not null)

3.4 Nopesan tidak boleh kosong (not null)


Bidang Alternatif :

3.5 QTYpenerimaan tidak boleh kosong (not null)

Alternatif 5:
5.1 jika data penerimaan barang masuk yang dimasukan tidak
sesuai, maka akan muncul pesan pemberitahuan untuk
memasukan data penerimaan barang masuk yang benar.
Use-case ini menyimpulkan bagaimana langkah input data
Kesimpulan :
penerimaan barang masuk oleh admin gudang.
Data barang telah disimpan dan telah terupdate, dan sistem
Postkondisi :
menampilkan kembali ke Form input penerimaan barang.
 nopenerimaan yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan oleh
aplikasi.
Batasan Dan Spesifikasi
Admin Gudang hanya menginput penerimaan data barang
Implementasi : masuk.
Hanya Admin gudang yang dapat melakukan penginputan data
Asumsi :
barang masuk.
-
Masalah Terbuka :

4.4.3.4 Desain Sistem Penjualan barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Penjualan barang Tipe Use Case


ID Use Case : 1.4 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi : menambah data penjualan barang dengan men-Scan
barcode barang.
User Telah memiliki data penjualan barang yang akan
Prakondisi :
diinputkan menggunakan scanbarcode.
Use case ini dimulai saat user menyeleksi pilihan input data
Pemicu :
barang untuk menambah data penjualan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2:

Pilih menu Transaksi danSistem


klik sub merespon dengan
menu input data penjualan menampilkan
barang. form inputan
penjualan barang(Form5).

BidangKhasSuatu Event :
Langkah 3:
Langkah 5 :Sistem merespon
Masukkan data barang dengankeluar mencetak struck
dengan mengescankan pembayaran.
barcode
barang menggunakan alat Scanner
Barcode kedalam field yang sudah
disediakan dengan benar. Langkah 6 :

Setelah sistem mencetakstruck


pembayaran maka Sistem akan
Langkah 4 : menyimpan data penjualan
barang yang telah diinputkan
Cek semua data penjualandengan
barang scandbarcode tersebut
yang sudah dimasukkan, bila tidak database sistem dan
kedalam
menampilkan kembali informasi
ada perubahan maka user
yang telah terupdate kedalam
melanjutkan dengan klik
Display Informasi data.(Data
tombol[Bayar](Button).
Grid View).

Alternatif Langkah 5:

5.1 Jika Sistem tidak bisa membaca scanbarcode barang,


karena ketidakjelasan barcode, maka user harus
Bidang Alternatif : menginputkan kodebarcode barang kedalam field yang
sudah disediakan.

Use-case ini menyimpulkan bagaimana langkah input data


Kesimpulan :
penjualan barang oleh Kasir.
Data barang telah dibayar dan disimpan dan telah terupdate,
Postkondisi : dan sistem menampilkan kembali Form Input Penjualan
barang.
 User sudah menyiapkan alat
Aturan Bisnis : scanbarcode untuk menscan barcode
yang valid.
Kasir hanya menginput data penjualan barang dengan
Batasan Dan Spesifikasi
mengscan barcode pada kodebarcode barang untuk input
Implementasi :
penjualan barang.
Hanya Kasir yang dapat melakukan penginputan data
Asumsi :
penjualan barang.
Masalah Terbuka : -

4.4.3.5 Desain Sistem Input Data Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Pesanan Barang Tipe Use Case


ID Use Case : 1.5 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :

Stakeholder yang berminat lain :


Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
mengPesanan Barang .
User Telah memiliki data pesanan barang yang akan
Prakondisi :
diinputkan.
Use case ini dimulai saat user meyeleksi pilihan input data
Pemicu :
pesanan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

Pilih menu Transaksi dan Sistem


kliksub merespon dengan
menu input data Pesanan barang.
menampilkan form inputan
Pesanan barang(Form 6).

Langkah 3:
Langkah 5 :
User memasukkan
Sistem merespon dengan
menyimpan
tglbarang pesan (DateTimePicker), data Pesanan barang
kategori(TextBox) yang telah diinputkan tersebut
kedalam database sistem dan
BidangKhasSuatu Event :
menampilkan kembali informasi
nopesan (Text Box),
yang telah terupdate kedalam
Display Informasi data.
QTYpesan(TextBox).
(DataGridView)

Langkah 4 :

Cek semua data Pesanan barang


yang sudah dimasukkan, bila tidak
ada perubahan maka user
melanjutkan dengan klik
tombol[Simpan](Button).

Alternatif langkah 3 :

3.1 tglbarang pesan tidak boleh kosong (not null),

3.2 kategori tidak boleh kosong (not null),


Bidang Alternatif :
3.3 Nopesan tidak boleh kosong(not null),

3.4 QTYpesan tidak boleh kosong (not null).


Alternatif 5:
5.1 jika data pesanan barang yang dimasukan tidak sesuai,
maka akan muncul pesan pemberitahuan untuk memasukan
data pesanan barang yang benar.
Use-case ini menyimpulkan bagaimana langkah Pesanan
Kesimpulan :
Barang oleh Supervisor.
Data barang yang sudah diinputkan akan disimpan dan akan
Postkondisi : terupdate,dan sistem menampilkan kembali Form Input
Pesanan Barang.
 nopesan yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi
Batasan Dan Spesifikasi
Supervisor hanya menginput data Pesanan Barang.
Implementasi :
Hanya Supervisor yang dapat melakukan penginputan
Asumsi :
dataPesanan barang .
Masalah Terbuka : -

4.4.3.6 Desain Sistem Input Data Return Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014


2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Return Barang Tipe Use Case


ID Use Case : 1.6 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
Return Barang.
User Telah memiliki data return barang yang akan
Prakondisi :
diinputkan.
Use case ini dimulai saat user menyeleksi pilihan input data
Pemicu : return barang untuk menambah ,merubah, dan menghapus
data barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

Pilih menu Transaksi dan Sistem


kliksub merespon dengan
menu input data return barang.
menampilkan form inputan
return barang(Form 7).

Langkah 3:
Langkah 5 : Sistem merespon
dengan
User memasukkan tglbarang returnmenyimpan data barang
(DateTimePicker), return yang telah diinputkan
kategori(TextBox), tersebut kedalam database
sistem dan menampilkan
kembali informasi yang telah
noreturn (Text Box),
terupdate kedalam Display
Informasi data.
QTYreturn(TextBox).
(DataGridView)

Langkah 4 :Cek semua data barang


return yang sudah dimasukkan, bila
tidak ada perubahan maka user
melanjutkan dengan klik
tombol[Simpan](Button).

Alternatif langkah 3 :

3.1 tglbarang return tidak boleh kosong (not null),

3.2 Kategori tidak boleh kosong (not null),

Bidang Alternatif : 3.3 Nopesan tidak boleh kosong(not null),

3.4 QTYreturn tidak boleh kosong (not null).

Alternatif 5:
5.1 jika data return barang yang dimasukan tidak sesuai,
maka akan muncul pesan pemberitahuan untuk memasukan
data return barang yang benar.
Use-case ini menyimpulkan bagaimana langkah input data
Kesimpulan :
return barang oleh Supervisor.
Data barang telah disimpan dan telah terupdate,dan sistem
Postkondisi :
menampilkan kembali Form Utama.
 User sudah menyiapkan data return
Aturan Bisnis :
barang yang valid.
Batasan Dan Spesifikasi
Supervisor hanya menginput data return barang.
Implementasi :
Hanya Supervisor yang dapat melakukan penginputan data
Asumsi :
return barang.
Masalah Terbuka : -
4.4.3.7 Desain Sistem Pencarian Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Pencarian barang Tipe Use Case


ID Use Case : 1.7 Persyaratan Bisnis : □
Prioritas : Tinggi Desain Sistem : 

Sumber :
Pelaku Bisnis Utama : Pembeli
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Use case ini mendeskripsikan kejadian seorang user yaitu
Deskripsi :
untuk pencarian barang .
Prakondisi : -
Pemicu : Use case ini dimulai saat user pencarian barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User menginputkan : Sistem merespon dengan


menampilkan informasi barang
yangnama
Kategori(TextBox), dan dicari(Form 8).
BidangKhasSuatu Event : Barang(TextBox).

Alternatif Langkah 2 :

2.1 Jika sistem tidak merespon maka pencarian barang


Bidang Alternatif : gagal karena barang yang dicari tidak ada dan kembali ke
langkah 1.

Use-case ini menyimpulkan bagaimana langkah pencarian


Kesimpulan :
barang oleh pembeli.
Pencarian barang sudah dicari maka sistem menampilkan
Postkondisi :
kembali form pencarian barang.
Aturan Bisnis : -
Batasan Dan Spesifikasi
pembeli hanya menginputkandata barang pada komputer
Implementasi : yang sudah disediakan
Asumsi : Pembeli yang dapat melakukan Pencarian Barang.
Masalah Terbuka : -
4.4.3.8 Desain Sistem Look Up data Penerimaan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Look up data penerimaan


Nama Use Case : Tipe Use Case
barang
ID Use Case : 1.8 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :

Pelaku Bisnis Utama : Supervisor, Pimpinan

Pelaku Partisipan Lain :

Stakeholder yang berminat lain :

Usecase ini mendeskripsikan proses look up data


Deskripsi : penerimaan barang masuk berdasarkan tglpenerimaan
dalam sistem.
Memastikan apakah penerimaan data barang masuk yang
Prakondisi :
akan di look up sudah ada didalam database atau belum.
Usecase ini di inisiasi saat look up penerimaan barang
Pemicu :
masuk.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User klik data barang masuk.


Sistem merespon dengan
menampilkan form data
penerimaan barang masuk
(form9).
Langkah 3 :
BidangKhasSuatu Event :
User memasukan tglpenerimaan
(DateTimePicker). Langkah 5:

Sistem akan secara otomatis


mencari data penerimaan barang
Langkah 4 : masuk yang telah tersimpan
kemudian menampilkan kedalam
tabel (DataGridView).
User mengklik
tombol[Cari](Button) .
Alternatif langkah 3 :

3.1 jika tglpenerimaan yang dimasukan tidak sesuai


Bidang Alternatif : dengan yang ada di database, maka sistem akan muncul
informasi bahwa tglpenerimaan yang dimasukan tidak ada
dalam database dan tidak dapat ditampilkan.

Usecase ini menyimpulkan tentang kegiatan look up data


Kesimpulan :
penerimaan barang masuk.
Data penerimaanbarang masuk yang dicari akan
Postkondisi :
ditampilkan.
 Tglpenerimaan yang dimasukan
Aturan Bisnis : harus sesuai dengan format yang
telah ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data penerimaan barang masuk.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data penerimaan barang masuk.
Masalah Terbuka : -

4.4.3.9 Desain Sistem Look up Data Penjualan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up data penjualanTipe


barang
Use Case
ID Use Case : 1.9 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data
Deskripsi :
penjualan barang berdasarkan tglpenjualan dalam sistem.
Memastikan apakah data penjualan barang yang akan di
Prakondisi :
look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up penjualan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User klik data penjualanSistem


barang. merespon dengan
menampilkan form data penjualan
barang (form10).

Langkah 3 :

BidangKhasSuatu Event : User Langkah 5:


memasukan
tglpenjualan(DateTimePicker)
Sistem akan secara otomatis
mencari data barang keluar yang
telah tersimpan kemudian
menampilkan kedalam tabel
Langkah 4:
(DataGridView).
User mengklik
tombol[Cari](Button).

Alternatif langkah 3 :

3.1 jika tglpenjualan yang dimasukan tidak sesuai dengan


Bidang Alternatif : yang ada di database, maka sistemn akan muncul
informasi bahwa tglpenjualan yang dimasukan tidak ada
dalam database dan tidak dapat ditampilkan.

Usecase ini menyimpulkan tentang kegiatan look up data


Kesimpulan :
penjualan barang.
Postkondisi : Data penjualan barang yang dicari akan ditampilkan.
 Tglpenjualan yang dimasukan harus
Aturan Bisnis : sesuai dengan format yang telah
ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data penjualan barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data penjualan barang.
Masalah Terbuka : -

4.4.3.10 Desain Sistem Look up Data Persediaan Barang


Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up Persediaan barang


Tipe Use Case
ID Use Case : 1.10 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data barang
Deskripsi :
Persediaan barang berdasarkan stock dalam sistem.
Memastikan apakah data persediaan barang yang akan di
Prakondisi :
look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look persediaan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User klik data Sistem


barang merespon dengan
persediaan. menampilkan form data
persediaan barang (form11).

Langkah 3 :
BidangKhasSuatu Event : Langkah 5:
User memasukan stockbarang
(TextBox). Sistem akan secara otomatis
mencari datapersediaan barang
yang telah tersimpan kemudian
menampilkan kedalam tabel
(DataGridView).
Langkah 4 :

User mengklik
tombol[Cari](Button).
Alternatif langkah 3 :

3.1 jika stockbarang yang dimasukan tidak sesuai dengan


Bidang Alternatif : yang ada di database, maka akan muncul informasi bahwa
stockbarang yang dimasukan tidak ada dalam database dan
tidak dapat ditampilkan.

Usecase ini menyimpulkan tentang kegiatan look up data


Kesimpulan :
persediaan barang.
Postkondisi : Data persediaan barang yang dicari akan ditampilkan.
 stockbarang yang dimasukan harus
Aturan Bisnis : sesuai dengan format yang telah
ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data persediaan barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data barang persediaan barang.
Masalah Terbuka : -

4.4.3.11 Desain Sistem Look up Data Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up Pesanan barang


Tipe Use Case
ID Use Case : 1.11 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data barang
Deskripsi :
Pesanan barang berdasarkan tglpesan dalam sistem.
Memastikan apakah data Pesanan barang yang akan di
Prakondisi :
look up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up Pesanan barang.
Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User klik data pesanan barang.


Sistem merespon dengan
menampilkan form data pesanan
barang (form12).
BidangKhasSuatu Event :
Langkah 3 :

Usermemasukan Langkah 5:
tglpesan(DateTimePicker).
Sistem akan secara otomatis
mencari datapesanan barang
yang telah tersimpan kemudian
Langkah 4 : menampilkan kedalam tabel
(DataGridView).
User mengklik tombol
[Cari](Button).
Alternatif langkah 3 :

3.1 jika tglpesan yang dimasukan tidak sesuai dengan


Bidang Alternatif : yang ada di database, maka akan muncul informasi bahwa
tglpesan yang dimasukan tidak ada dalam database dan
tidak dapat ditampilkan.

Usecase ini menyimpulkan tentang kegiatan look up data


Kesimpulan :
Pesanan barang.
Postkondisi : Data Pesanan barang yang dicari akan ditampilkan.
 tglpesan yang dimasukan harus
Aturan Bisnis : sesuai dengan format yang telah
ditentukan oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data Pesanan barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan
Asumsi :
look up data barang Pesanan barang.
Masalah Terbuka : -

4.4.3.12 Desain Sistem Look up Data Return Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Look up return barang Tipe Use Case


ID Use Case : 1.12 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Supervisor, Pimpinan
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses look up data barang
Deskripsi :
return barang berdasarkan tglreturn dalam sistem.
Memastikan apakah data return barang yang akan di look
Prakondisi :
up sudah ada didalam database atau belum.
Pemicu : Usecase ini diinisiasi saat look up return barang.
BidangKhasSuatu Event : Kegiatan Pelaku Respons Sistem
Langkah 1 : Langkah 2 :

User klik data Return barang.


Sistem merespon dengan
menampilkan form data return
barang (form13).

Langkah 3 :

Usermemasukan Langkah 4:
tglreturn(DateTimePicker) .
Sistem akan secara otomatis
mencari data return barang yang
telah tersimpan kemudian
menampilkan kedalam tabel
Langkah 5 :
(DataGridView).
User mengklik
tombol[Cari](Button).

Alternatif langkah 3 :

3.1 jika tglreturn yang dimasukan tidak sesuai dengan yang


Bidang Alternatif : ada di database, maka akan muncul informasi bahwa
tglreturn yang dimasukan tidak ada dalam database dan
tidak dapat ditampilkan.
Usecase ini menyimpulkan tentang kegiatan look up data
Kesimpulan :
return barang.
Postkondisi : Data return barang yang dicari akan ditampilkan.
 tglreturn yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi.
Batasan Dan Spesifikasi
User hanya look up data return barang.
Implementasi :
Hanya Supervisor dan Pimpinan yang dapat melakukan look
Asumsi :
up data return barang.
Masalah Terbuka : -

4.4.3.13 Desain Sistem Update Data Penerimaan barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Update data Penerimaan


Nama Use Case : Tipe Use Case
barang
ID Use Case : 1.13 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Admin Gudang
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses update data penerimaan
Deskripsi : barang masuk yang terjadi pada data barang masuk yang
telah diinput.
Memastikan Admin Gudang telah terhubung dengan data
Prakondisi : penerimaan barang masuk yang akan di edit/update yang
telah diinput sebelumnya kedalam sistem.
Usecase ini diinisiasi saat Admin Gudang akan melakukan
Pemicu : proses update edit/ data penerimaan barang masuk yang
telah diinput sebelumnya kedalam sistem.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :

User Pilih menu Transaksi


Sistem merespon dengan
barang dan kliksub menu
menampilkan
input form inputan
penerimaan barang. penerimaanbarang masuk(Form 4).

Langkah 3 : Langkah 4 :

User mengklik dan mengubah


Sistem merespon dengan
data penerimaan barang
menampilkan
masuk penerimaan data
BidangKhasSuatu Event : yang akan diubah. barang masuk.

Langkah 5 : Langkah 6:

User mengubah penerimaan


Data penerimaan barang masuk
barang mengklik yang
tombol
datanya telah di ubah akan
[Update](Button). tersimpan kembali kedalam
database(Data gridView)

Alternatif langkah 5 :

5.1 jika data penerimaan barang masuk yang di update/edit


Bidang Alternatif : tidak sesuai, maka akan muncul pesan pemberitahuan untuk
memasukan data penerimaan barang masuk yang benar.

Usecase ini menyimpulkan tentang kegiatan update/edit


Kesimpulan :
data penerimaan barang masuk yang dilakukan oleh oleh
Admin Gudang.
Hasil proses update data penerimaan barang masuk akan
Postkondisi :
dimasukan kedalam database.
 Data yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi.
Batasan Dan Spesifikasi
Admin Gudang hanya mengubah penerimaan databarang
Implementasi : masuk.
Hanya admin gudang yang dapat melakukan update/edit
Asumsi :
data penerimaan barang masuk.
Masalah Terbuka : -

4.4.3.14 Desain Sistem Update data Pesanan Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Update data Pesanan Tipe


barang
Use Case
ID Use Case : 1.14 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses update data pesanan
Deskripsi : barang yang terjadi pada data barang pesanan yang telah
diinput.
Memastikan Supervisor telah terhubung dengan data
Prakondisi : pesanan barang yang akan di edit/update yang telah diinput
sebelumnya kedalam sistem.
Usecase ini diinisiasi saat Supervisor akan melakukan
Pemicu : proses update edit/ data pesanan barang yang telah diinput
sebelumnya kedalam sistem.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :

BidangKhasSuatu Event : User Pilih menu Transaksi


Sistem merespon dengan
barang dan kliksub menu
menampilkan
data form inputan pesanan
pesanan barang. barang(Form6).
Langkah 4 : Langkah 6:

User mengklik dan mengubah


Data pesanan barang yang datanya
data pesanan barang yang
telahakan
di ubah akan tersimpan kembali
diubah. kedalam database(Data Grid View).

Langkah 5 :

User mengubah barang


mengklik tombol
[Update](Button).
Alternatif langkah 5 :

5.1 jika data pesanan barang yang di update/edit tidak


Bidang Alternatif : sesuai, maka akan muncul pesan pemberitahuan untuk
memasukan data pesanan barang yang benar.

Usecase ini menyimpulkan tentang kegiatan update/edit


Kesimpulan :
data pesanan barang yang dilakukan oleh Supervisor.
Hasil proses update data pesanan barang akan dimasukan
Postkondisi :
kedalam database.
 Data yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi.
Batasan Dan Spesifikasi
Supervisor hanya mengubah data pesanan barang.
Implementasi :
Hanya Supervisor yang dapat melakukan update/edit data
Asumsi :
pesanan barang.
Masalah Terbuka : -

4.4.3.15 Desain Sistem Update Data Return Barang

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Update data Return barang


Tipe Use Case
ID Use Case : 1.15 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi
Sumber :
Pelaku Bisnis Utama : Supervisor
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan proses update data return
Deskripsi : barang yang terjadi pada data barang return yang telah
diinput.
Memastikan Supervisor telah terhubung dengan data return
Prakondisi : barang yang akan di edit/update yang telah diinput
sebelumnya kedalam sistem.
Usecase ini diinisiasi saat Supervisor akan melakukan
Pemicu : proses update edit/ data return barang yang telah diinput
sebelumnya kedalam sistem.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :

User Pilih menu Transaksi


Sistem merespon dengan
barang dan kliksub menu
menampilkan
data form inputan return
return barang. barang(Form 7).

Langkah 3 : Langkah 6:
BidangKhasSuatu Event :
User mengklik dan mengubah
Data return barang yang datanya
data return barang yang
telahakan
di ubah akan tersimpan kembali
diubah. kedalam database(Data Grid View).

Langkah 5 :

User mengklik

tombol update(Button).
Alternatif langkah 5 :

Bidang Alternatif : 5.1 jika data return barang yang di update/edit tidak sesuai,
maka akan muncul pesan pemberitahuan untuk memasukan
data return barang yang benar.
Usecase ini menyimpulkan tentang kegiatan update/edit
Kesimpulan :
data return barang yang dilakukan oleh Supervisor.
Hasil proses update data return barang akan dimasukan
Postkondisi :
kedalam database.
 Data yang dimasukan harus sesuai
Aturan Bisnis : dengan format yang telah ditentukan
oleh aplikasi.
Batasan Dan Spesifikasi
Supervisor hanya mengubah data return barang.
Implementasi :
Hanya Supervisor yang dapat melakukan update/edit data
Asumsi :
return barang.
Masalah Terbuka : -

4.4.3.16 Desain Sistem Cetak laporan

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Cetak laporan Tipe Use Case


ID Use Case : 1.16 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Tinggi

Pelaku Bisnis Utama : Supervisor


Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan pencetakan laporan yang
Deskripsi :
telah dikelola sebelumnya dalam sistem.
Prakondisi : Data atau laporan yang akan dicetak harus tersedia.
Pemicu : Usecase ini diinisiasi saat proses pencetakan laporan.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2 :

User mengklik menu laporan


Sistemdan merespon dengan
pilih dan klik jenis laporan
menampilkan
yang form laporan yang
dipilih. dipilih(Form 14).

BidangKhasSuatu Event :

Langkah 7 :

Langkah 3: Sistem akan merespon perintah


dan printer akan mencetak
User memilih jenis laporan.
laporan
(Combo Box) dan mengatur
tanggal laporan yang akan di
cetak(DateTimePicker).
Langkah 6 :

User mengklik tombol


view(Button).

Langkah 8 :

User mengklik tombol


cetak/print(Button).
Alternatif langkah 3 :
Bidang Alternatif :
3.1 Jika data atau laporan yang dipilih tidak tersedia maka
sistem akan memberikan pemberitahuan.
Usecase ini menyimpulkan tentang kegiatan pencetakan
Kesimpulan :
laporan.
Laporan yang telah dicetak akan diserahkan kepada
Postkondisi :
Pimpinan.
Data atau laporan yang akan dicetak harus ada pada
Aturan Bisnis :
database.
Batasan Dan Spesifikasi
Supervisor hanya mencetak laporan.
Implementasi :
Asumsi : Hanya Supervisor yang dapat mencetak laporan.
Masalah Terbuka : -

4.4.3.17 Desain Sistem Cetak Struck Pembayaran

Pengarang : 1. Meli Amelia Tanggal : 17 September 2014

2. Aminatul Rosidah Versi : 1.0

Nama Use Case : Cetak Struk Pembayaran


Tipe Use Case
ID Use Case : 1.17 Persyaratan Bisnis : □
Desain Sistem : 
Prioritas : Sedang

Sumber :
Pelaku Bisnis Utama : Kasir
Pelaku Partisipan Lain :
Stakeholder yang berminat lain :
Usecase ini mendeskripsikan pencetakan struk biaya yang
Deskripsi :
telah dikelola sebelumnya dalam sistem.
Prakondisi : Pembeli membayar kepada Kasir.
Pemicu : Usecase ini diinisiasi saat proses pencetakan struk biaya.
Kegiatan Pelaku Respons Sistem
Langkah 1: Langkah 2:

User mengklik Sistem


tombol akan secara otomatis
view(Button) menampilkan data transaksi
pembayaran(Form18).
BidangKhasSuatu Event :

Langkah 3 :
Langkah 4 :
User mengklik tombol
cetak/print(Button). Sistem akan merespon perintah
dan printer akan mencetak struk
Pembayaran.
Alternatif langkah 2 :
Bidang Alternatif :
2.1 Jika data transaksi pembayaran yang dipilih tidak
tersedia maka sistem akan memberikan pemberitahuan.
Usecase ini menyimpulkan tentang proses pencetakan
Kesimpulan :
struk pembayaran.
Postkondisi : Struk pembayaran pembeli.
Aturan Bisnis : pembeli harus terlebih dahulu membayar kepada kasir.
Batasan Dan Spesifikasi
Kasir hanya mencetak struk pembayaran.
Implementasi :
Asumsi : Hanya kasir yang dapat mencetak struk pembayaran.
Masalah Terbuka : -

4.5 Diagram Ketergantungan Use Case

4.5.1 Inheritance
Login

User

<<Inheritance>>
<<Inheritance>> <<Inheritance>>
<<Inheritance>>

Pimpinan Adm.Gudang Supervisor Kasir

Gambar 4.14 Inheritance

4.5.2 Extension

Update Penerimaan
Input data Pesanan barang
barang

>
<<

s>
E

nd
xte
nd xte
s>
E
>
<<

Look up data
Penerimaan barang

Gambar 4.15 Extension Penerimaan Masuk

Update data
penjualan barang
<<Extends>>

Look up data penjualan


barang

Gambar 4.16 Extension Penjualan barang


Data Persediaan Update Data Pesanan
Barang barang
<< >
Ex s>
te d
n ds en
>> E xt
<<

Look Up Data Pesanan

Gambar 4.17 Extension Pesanan Barang

Data Persediaan Update Data Return


Barang barang
<<
Ex >
te s>
n nd
ds
>> E xte
<<

Look Up Data Return


Barang

Gambar 4.18 Extension Return Barang

Pencarian Barang
<<Extends>>

Look Informasi
Barang

Gambar 4.19 Extension Pencarian Barang


Input Penerimaan
barang
Input Pejualan barang

<<Extends>>
Input data return
<< barang
E xte
nd
s> >>
>
n ds
E xte
<<
Look Up Persediaan
barang

Gambar 4.20 Extension Persediaan Barang

Cetak Laporan

> >>
s> ds
>

>>
>>

d n
n d s>

Supervisior en xte Pimpinan


ds

xt
ds

E
n

E <<
ten

xte

<<
te

E
Ex

<<Ex

<<
<<

Laporan Laporan Return


penerimaan Barang
barang
Laporan Pesanan Laporan penjualan Laporan
Barang barang Persediaan barang

Gambar 4.21 Extension Laporan Barang

Struck
Cetak Struck <<Extendes>>
Pembayaran

Kasir

Gambar 4.22 Extension Cetak Struck Pembayaran


4.5.3 Depends On

Data Persediaan
Barang

>>

>
n>
On

n>>
O
s

ds
nd

nds O
pe

en
De

ep
<<

D
<<

pe
<<De
Input data Input Return
penerimaan Barang
barang

Penjualan barang

Gambar 4.23 Depends On Persediaan Barang

Data Penerimaan
barang
> ds

>> ds
n> n
O epe

On pen
De
D
<<

<<

Update Data
Input Data Penerimaan barang
Penerimaan barang

Gambar 4.24 Depends On Penerimaan Masuk


Cetak Struck
Pembayaran

>
n>
O
ds
en
ep
D
<<
Data Penjualan
barang

>>
On
ds
en
ep
D
<<
Penjualan barang

Gambar 4.25 Depends On Penjualan barang

Data Pesanan
Barang
> ds

> ds
n> n

n > en
O epe

O ep
D

D
<<

<<

Update Pesanan
Input Pesanan Barang
Barang

Gambar 4.26 Depends On Pesanan Barang


Data Return Barang

> ds
> ds

n> n
n> n

O epe
O epe

D
<<
D
<<

Input Return Input Return


Barang Barang

Gambar 4.27 Depends On Return Barang

4.6 Use Case Diagram


Input data
Pesanan Barang

Input data Return


Barang

Input barang

Input Penerimaan

Penjualan barang

Login

Supervisior Admin Gudang


Look up Data
Pesanan Barang

Look up data
Return barang

Look up penerimaan
barang

Look up
penjualan barang
Kasir
Look up data
Pesanan Barang

Update Data
Pesanan barang

Update data
Return Barang

Update data
penerimaan
barang

Cetak Laporan

Pembeli
Cetak Struck
Pembayaran

Pencarian barang

Gambar 4.28 Use Case

4.7 Rancangan Database

4.7.1 Entity Relation Diagram (ERD)


Nama Jabatan
Tglbararangpesan
NoPesan

KdPegawai Alamat KdPegawai

1 M
Pegawai Melakukan Pesanan
1
1 1
M

Melakukan Return
Memiliki

NoReturn
M 1 NoDPesan Barcode
KdPegawai
Penerimaan Tglreturnbarang M
NoPesan

NoPenerimaan
1 Detail Pesanan
Harga
KdPegawai Memiliki Barang

Tglbararangterima 1
QTYpesan

M
Memiliki NoDReturn Detail Return NoReturn
Barang
Barcode
Harga
1
M
NoPenerimaan
Detail Penerimaan QTYreturn
Barang
NoPesan
Harga
1
NoDPenerimaan
QTYterima

Barcode NoPenerimaan

Punya

NoTransaksi M M
M 1
Membeli Barang Punya
Barcode

KdPegawai Barcode
Stock barang

NoCust
1 NamaBarang Harga
KdKategori
NoCust Customer

1
NamaCust QTYbeli KdKategori Kategori NamaKategori

Tglbeli
NoTransaksi

Gambar 4.29 Entity Relation Diagram (ERD)


4.7.2 Relasi Antar Tabel

Tabel Pegawai Tabel Penjualan

PK KodePegawai PK Notransaksi

Nama Barcode
Alamat KdPegawai
Tanggal
Jabatan
QTY

Tabel Barang

PK Barcode
Tabel Detail
KdKategori Penerimaan
Tabel Detail Pesanan NamaBarang
Stock PK NoDPenerimaan
PK NoDPesan Harga FK Barcode
FK Barcode NoReturn
NoPesan Nopesan
Harga Harga
QTYpesan QTYterima

Tabel Pesanan Tabel Detail Return


Tabel Kategori
PK NoPesan PK NoDReturn
Tglbarangpesan FK Barcode PK KdKategori
KdPegawai NoReturn NamaKategori
NoPenerimaan
Harga
Tabel Penerimaan QTYreturn
Tabel Return
PK NoPenerimaan
PK NoReturn
Tglbarangterima Tabel Customer
Tglbarangreturn
KdPegawai PK NoCust KdPegawai
NamaCust
Tglbeli
Kode Pegawai
QTYbeli
NoTransaksi

Gambar 4.30 Relasi Antar Tabel

4.7.3 Spesifikasi File

Spesifikasi file merupakan penjabaran dari perancangan database

termasuk field-filed pada beberapa tabel, yaitu :

4.7.3.1 TabelBarang
Field Tipe Data Length Ket

1 Barcode Char 20 Primary Key /


Not Null

2 KdKategori Char 10

3 NamaBarang Varchar 35

4 Harga Currency

5 Stock Barang Char 10

4.7.3.2 TabelPegawai

Field Tipe Data Length Ket

1 KdPegawai Char 10 Primary Key /


Not Null

2 NamaPegawai Varchar 25

3 Alamat Varchar 35

4 Jabatan Varchar 20

4.7.3.3 TabelPenerimaanBarang

Field Tipe Data Length Ket

1 NoPenerimaan Char 10 Primary Key /


Not Null

2 KdPegawai Char 10

3 TglPenerimaan Date -

4.7.3.4 Tabel Detail PenerimaanBarang

Field Tipe Data Length Ket

1 NoDpenerimaan Char 10 Primary Key /


Not Null

2 NoPenerimaan Char 10

3 Nopesan Char 10

4 Barcode Char 20

5 QTYpesan Char 10
6 Harga Currency -

4.7.3.5 TabelCustomer

Field Tipe Data Length Ket

1 NoCustomer Char 10 Primary Key /


Not Null

2 NoTransaksi Char 10

3 KdPegawai Char 10

4 NamaCustomer Varchar 25

5 QTYbeli Char 10

6 Tglbeli Date -

4.7.3.6 TabelPesanan Barang

Field Tipe Data Length Ket

1 Nopesan Char 10 Primary Key /


Not Null

2 Kdpegawai Char 10

3 Tglpesan Date -

4.7.3.7 TabelDetailPesananBarang

Field Tipe Data Length Ket

1 NoDPesanan Char 10 Primary Key /


Not Null

2 Nopesan Char 10

3 Barcode Char 20

4 QTYpesan Char 10

5 Harga Currency -

4.7.3.8 TabelReturnBarang

Field Tipe Length Ket


Data
1 NoReturn Char 10 Primary Key /
Not Null

2 Kdpegawai Char 10
3 Date Date -

4.7.3.9 TabelDetailReturnBarang

Field Tipe Data Length Ket

1 NoDReturn Char 10 Primary Key /


Not Null

2 NoReturn Char 10

3 NoPenerimaan Char 10

4 Barcode Char 20

5 Harga Currency -

6 QTYReturn Char 10

4.7.3.10 TabelKategori

Field Tipe Data Length Ket

1 KdKategori Char 10 Primary Key /


Not Null

2 NamaKategori Char 10

4.7.3.11 Tabel Penjualan

Field Tipe Data Length Ket

1 NoTransaksi Char 10 Primary Key /


Not Null

2 KdPegawai Char 10

3 Barcode Char 20
4.7.4 Diagram Kelas (Classs Diagram)

ClsPenerimaanBarang
-NoPenerimaan : Char
-Tglpenerimaanm : Date
-IdPegawai : Char
ClsPegawai
Tambah barang
-IdPegawai : Char Ubah data barang
-NamaPegawai : Varchar
-Harga : Char

Tambah Pegawai

ClsBarang
- KdBarang : Char
- Barcode : Char
- Nama Barang : Varchar
- Harga : Char

Tambah Barang
ClsPenjualanBarang

-NoPenjualan : Char
-Tanggalpenjualan : Date
-IdPegawai : Char

Tambah Transaksi Penjualan

ClsPesanan Barang
Return Barang
-NoPesan : Char
-NoReturn : Char -TglBarangpesan : Date
-TglReturn : Date -KdBarang : Char
-Kdbarang : Char -QTYPesan : Char
-QTYPesan : Char Tambah Pesanan
Ubah Data Pesanan
Tambah Return Barang
Ubah Return Barang

Gambar 4.31 Diagram Kelas


4.8 Diagram Aktivitas (Activity Diagram)

4.8.1 Diagram Aktivitas Login

User Sistem

Login

Scanbarcode untuk login

Validasi
Username & Password

Validasi User salah Validasi User


atau tidak valid benar atau valid

Menampilkan
menu utama

Gambar 4.32 Diagram Aktivitas Login

4.8.2 Diagram Aktivitas Input Barang


Admin Gudang Sistem

Klik menu Master pilih Aplikasi


sub menu barang

Menampilkan form
inputan barang

Input data barang

Save

Input barang

Menampilkan informasi
Exit
data barang

Gambar 4.33 Diagram Aktivitas input barang


4.8.3 Diagram Aktivitas Input Penerimaan Barang

Admin Gudang Sistem

Klik sub
menuTransaksi input Aplikasi
Penerimaan barang

Menampilkan form
inputan Penerimaan
barang

Input data
Penerimaan
barang

Save

Input data
Penerimaan
barang
Menampilkan informasi
Exit data Penerimaan
barang

Gambar 4.34 Input penerimaan barang

4.8.4 Diagram Aktivitas Penjualan Barang


Kasir Sistem

Klik sub
menuTransaksi Aplikasi
Penjualan barang

Menampilkan form
Penjualan Barang

Input data
Penjualan barang
dengan SCAND
BARCODE

Bayar

Input data
Penjualan
kembali

Menampilkan informasi data


Exit Penjualan dan mencetak
struck pembayaran

Gambar 4.35 Diagram Aktivitas Penjualan barang

4.8.5 Diagram Aktivitas Pesanan Barang

Supervisor Sistem

Klik sub menu


transaksi pesanan Aplikasi
barang

Menampilkan form
inputan pesanan
barang

Input data
pesanan barang

Simpan

Input data
pesanan barang

Menampilkan informasi data


Exit
pesanan barang

Gambar 4.36 Diagram Aktivitas Pesanan Barang

4.8.6 Diagram Aktivitas Return Barang


Supervisor Sistem

Klik sub menu


Transaksi return Aplikasi
barang

Menampilkan form
inputanreturn barang

Input data return


barang

Simpan

Input data return


barang

Menampilkan informasi data


Exit
return barang

Gambar 4.37 Diagram Aktivitas Return Barang

4.8.7 Diagram Aktivitas Pencarian Barang

Pembeli Sistem

menginputkan data barang


Aplikasi
yang akan dicari

menampilkan informasi
barang yang dicari user

Gambar 4.33 Diagram Aktivitas Pencarian Barang

4.8.8 Diagram Aktivitas Look Up Data Penerimaan barang


Supervisor /
Sistem
Pimpinan

Data Penerimaan barang Aplikasi

Input tglpenerimaan Cari data Penerimaan barang yang sudah tersimpan

[Data tidak ditemukan]

[Data ditemukan]

Menampilkan data Penerimaan barang yang dicari

Gambar 4.34 Look Up Data Penerimaan Barang

4.8.9 Diagram Aktivitas Look Up Data Penjualan Barang


Supervisor /
Sistem
Pimpinan

Data Penjualan barang Aplikasi

Input tglpenjualan Cari data Penjualan barang yang sudah tersimpan

[Data tidak ditemukan]

[Data ditemukan]

Menampilkan data Penjualan

Gambar 4.35 Look Up Data Penjualan Barang

4.8.10 Diagram Aktivitas Look Up Data Persediaan Barang


Supervisor /
Sistem
Pimpinan

Data Persediaan Aplikasi

Input stock Cari data Persediaan barang yang sudah tersimpan

[Data tidak ditemukan]

[Data ditemukan]

Menampilkan data Persediaan

Gambar 4.36 Look Up Data Persediaan Barang

4.8.11 Diagram Aktivitas Look Up Data Pesanan Barang

Supervisor /
Sistem
Pimpinan

Data pesanan Aplikasi

Input tglpesan yang dicari Cari data pesanan barang yang sudah tersimpan

[Data tidak ditemukan]

[Data ditemukan]

Menampilkan data Pesanan

Gambar 4.37 Look Up Data Pesanan Barang


4.8.12 Diagram Aktivitas Look Up Data Return Barang
Supervisor /
Sistem
Pimpinan

Data Return Barang Aplikasi

Input tglreturn yang dicari Cari data Return barang yang sudah tersimpan

[Data tidak ditemukan]

[Data ditemukan]

Menampilkan data Return barang yang dicari

Gambar 4.38 Look Up Data Return barang

4.8.13 Diagram Aktivitas Update Data Penerimaan Barang

Admin
Sistem
Gudang

Data Penerimaan barang Aplikasi

Update Penerimaan barang

[Data tidak sesuai]

[Data sesuai]

Menampilkan update Penerimaan barang

Gambar 4.39 Update Data Penerimaan Barang


4.8.14 Diagram Aktivitas Update Pesanan barang

Supervisor Sistem

Data Pesanan barang Aplikasi

Update pesanan barang

[Data tidak sesuai]

[Data sesuai]

Menampilkan Update pesanan barang

Gambar 4.40 Update Pesanan barang

4.8.15 Diagram Aktivitas Update Data Return Barang

Supervisor Sistem

Data Return Barang Aplikasi

Upate Return barang

[Data tidak sesuai]

[Data sesuai]

Menampilkan Upadeta return barang

Gambar 4.41 Update Data Return barang


4.8.16 Diagram Aktivitas Cetak Laporan

Supervisor Sistem

Klik Laporan dan pilih jenis laporan aplikasi

Menampilkan Form laporan

Input tanggal

Cari data barang

[Data tidak sesuai]

[Data Sesuai]

Print Menampilkan laporan data barang

Gambar 4.42 Cetak Laporan

4.8.17 Diagram Aktivitas Cetak Struck Pembayaran

Administrasi Sistem

Data barang keluar aplikasi

Menampilkan data transaksi pembayaran

Cetak

Gambar 4.43 Cetak Struk Pembayaran


4.9 Sequence Diagram

4.9.1 Sequence Diagram Login

From Login Login Data User Menu Utama

User

Login

Validasi user

Cek validasi

Masuk ke Halaman Menu Utama

Validasi
[Result]

Gambar 4.44 Sequence Diagram Login

4.9.2 Sequence Diagram Input Barang

From Master Input Data Tabel Barang


Barang Barang
Admin Gudang

Masuk Halaman Master Input data Barang

Tampilkan Form input data barang

Input kan data barang


Validasi
Simpan data

Validasi
[result]

Gambar 4.45 Sequence Diagram Input Barang

4.9.3 Sequence Diagram Penerimaan Barang


From Transaksi Input Data Tabel
Penerimaan Penerimaan Penerimaan
barang barang
Admin Gudang

Masuk Halaman Transaksi Input Penerimaan barang

Menampilkan Form Inputan Penerimaan barang

Input Data Penerimaan Barang

Validasi
Simpan data

Validasi
[result]

Gambar 4.46 Sequence Diagram Penerimaan Barang

4.9.4 Sequence Diagram Penjualan Barang

From Transaksi
Penjualan Tabel Penjualan
Penerimaan
Kasir

Masuk Halaman Transaksi Penjualan barang

Menampilkan Form Penjualan

Input Transksi Penjualan


Validasi
Simpan data

Validasi
[result]
Gambar 4.47 Sequence Diagram Penjualan Barang

4.9.5 Sequence Diagram Pesanan Barang

From Pesanan Input Pesanan Tabel Pesanan

Supervisor

Masuk Halaman Transaksi Pesanan barang

Menampilkan Form Pesanan barang

Input data Pesanan Barang

Validasi
Simpan data

Validasi
[result]

Gambar 4.48 Sequence Diagram Pesanan Barang

4.9.6 Sequence Diagram Return Barang

From Transsaksi
Return Input Return Tabel Return

Supervisor

Masuk halaman Transaksi Return

Menampilkan Form Inputan Return Barang

Input data Return Barang

Validasi
Simpan data

Validasi
[result]
Gambar 4.49 Sequence Diagram Return Barang

4.9.7 Sequence Diagram Pencarian Barang

Form Pencarian Tabel Pencarian


Barang Barang

Pembeli

Menginputkan data barang yang dicari

Menampilkan Informasi barang

Validasi

[result]

Gambar 4.50 Sequence Diagram Pencarian Barang

4.9.8 Sequence Diagram Look Up Data Penerimaan Barang


Form Look Up Look Up Data Tabel
Penerimaan Penerimaan Penerimaan
Supervisor

Masuk Halaman View Data Penerimaan barang

Masukkan tglperimaan

cari data

Tampilkan data

validasi

Validasi

[result]

Gambar 4.51 Sequence Diagram Look Up Data Penerimaan Barang

4.9.9 Sequence Diagram Look Up Data Penjualan Barang

Form Look Up Look Up data


Tabel Penjualan
Penjualan Penjualan

Supervisor

Masuk Halaman View Data Penjualan Barang

Masukkan tglpenjualan

cari data

Tampilkan data

validasi

Validasi

[result]

Gambar 4.52 Sequence Diagram Look Up Data Penjualan Barang

4.9.10 Sequence Diagram Look Up Data Persediaan Barang


Look Up Form Look Up Tabel
Persediaan Penjualan Persediaan

Supervisor

Masuk Halaman View Persediaan

Masukkan Stock
cari data

Tampilkan data

validasi

Validasi

[result]

Gambar 4.53 Sequence Diagram Look Up Data Persediaan

4.9.11 Sequence Diagram Look Up Data Pesanan Barang

Form Look up Look Up


Tabel Pesanan
Pesanan Barang Pesanan Barang
Supervisor

Masuk halaman View data Pesanan

Masukkan Tglpesan cari data

Tampilkan data

validasi

Validasi

[result]

Gambar 4.54 Sequence Diagram Look Up Data Pesanan Barang

4.9.12 Sequence Diagram Look Up Data Return Barang


Form Look up Look Up data
Tabel Return
Return Barang Return Barang

Supervisor

Masuk Halaman View Return Barang

Masukkan tgl return cari data

Tampilkan data

validasi

Validasi

[result]

Gambar 4.55 Sequence Diagram Look Up Data Return Barang

4.9.13 Sequence Diagram Update Data Penerimaan Barang

Form Transaksi Look Up data Update data Tabel


Penerimaan Penerimaan Penerimaan Penerimaan
Barang Barang barang Barang
Admin Gudang

Masuk Halaman Transaksi Penerimaan

Update data Penerimaan barang

validasi

Validasi
[result]

Gambar 4.56 Sequence Diagram Update Data Penerimaan

4.9.14 Sequence Diagram Update Data Pesanan Barang


Form Transaksi Look Up Update Pesanan Tabel Pesanan
Pesanan Barang Pesanan Barang Barang Barang
Supervisor

Masuk Halaman transaksi Pesanan

Update Data Pesanan Barang

validasi

Validasi
[result]

Gambar 4.57 Sequence Diagram Update Data Pesanan

4.9.15 Sequence Diagram Update Data Return Barang

Form Transaksi
Transaksi Look Up Data Update data Tabel Return
Barang Return barang Return barang barang

Supervisor

Masuk halaman Transksi Return

Update Return Barang

validasi

Validasi
[result]

Gambar 4.58 Sequence Diagram Update Return Barang


4.9.16 Sequence Diagram Cetak Laporan

Form data
Form Laporan Cetak Laporan Cetak laporan
Laporan

Supervisor

Masuk Halaman Laporan

Pilih jenis laporan

Masukkan Tanggal

Tampilkan Laporan

cetak laporan
validasi

Validasi
[result]

Gambar 4.59 Sequence Diagram Cetak Laporan

4.9.17 Sequence Diagram Struck Pembayaran

Form Transaksi Cetak Struk Cetak struk


biaya
Penjualan Biaya
Kasir

Masuk halaman Transksi Penjualan

Menampilkan Transaksi Penjualan

Cetak Struck

Gambar 4.60 Sequence Diagram Struck Pembayaran


4.10 Deployment Diagram

Server

Window
s Server
2008

MySQL

LAN
Jalur Koneksi

Client

Window
s7

Scanner Barcode Printer type


deskjet .
Microsof
t Visual
Studio
2010

Gambar 4.61 Deployment Diagram

4.11 User Interface

4.11.1 User Interface Login

Scan Barcode Untuk Login

Cancel
Gambar 4.62 User Interface Login (Form 1)

4.11.2 User Interface Menu Utama

Tampilan Utama

Master Transaksi View Laporan

Gambar 4.63 User Interface Menu Utama (Form 2)

4.11.3 User Interface Input Barang


Master Barang

Barcode

NamaBarang

KdKategori

Harga

Stock Barang

* Barcode NamaBarang KdKategori HargaStock Barang

Tambah Simpan Batal

Gambar 4.64 User Interface Input Barang (Form 3)

4.11.4 User Interface Input Penerimaan Barang

Transaksi Penerimaan barang

No Penerimaan

Tgl Barang Terima

KdPegawai

* NoDPenerimaan NoPenerimaan NoPesan Barcode QTYTerima Harga

Tambah Simpan Update


Gambar 4.65 User Interface Penerimaan Barang (Form 4)

4.11.5 User Interface Penjualan Barang

Transaksi Penjualan Barang

NoTransaksi Tanggal KdPegawai

Barcode NamaBarang Harga QTY Total Harga


*

Total
Bayar
Dibayar

Kembali

Gambar 4.66 User Interface Penjualan Barang (Form 5)

4.11.6 User Interface Pesanan Barang

Transaksi Pesanan Barang

NoPesan

TanggalBarangPesan

KdPegawai

* NoDPesan NoPesan Barcode QTY Pesan

Tambah Simpan Update


Gambar 4.67 User Interface Pesanan Barang (Form 6)

4.11.7 User Interface Return Barang

Transaksi Pesanan Barang

NoPesan

TanggalBarangPesan

KdPegawai

* NoDPesan NoPesan Barcode QTY Pesan

Tambah Simpan Update

Gambar 4.68 User Interface Return Barang (Form 7)

4.11.8 User Interface Pencarian Barang


Pencarian Buku

NamaKategori

Nama Barang

* Nama Barang Harga Stock Rak

Batal

Gambar 4.67 User Interface Pencarian Barang (Form 8)

4.11.9 User Interface Look Up Data Penerimaan Barang

Data Penerimaan barang

Tanggal Penerimaan Cari

Gambar 4.68 User Interface Look Up Penerimaan Barang (Form 9)

4.11.10 User Interface Look Up Data Penjualan Barang


Data Penjualan barang

Tanggal Penjualan Cari

Gambar 4.69 User Interface Look Up Penjualan (Form 10)

4.11.11 User Interface Look Up Data Persediaan Barang

Data Persediaan barang

Stock Cari

Gambar 4.70 User Interface Look Up Persediaan (Form 11)


4.11.12 User Interface Look Up Pesanan Barang

Data Pesanan barang

Tanggal Pesan Cari

Gambar 4.71 User Interface Look UpPesanan (Form 12)

4.11.13 User Interface Look Up Data Return Barang

Data Retu barrnang

Tanggal Return Cari

Gambar 4.72 User Interface Return (Form 13)


4.11.14 User Interface Laporan

Laporan

Jenis Laporan Tanggal Laporan

Nama Laporan Label

Gambar 4.75 User Interface Laporan (Form 14)

4.11.15 User Interface Pegawai


Master Pegawai

KdPegawai

Nama

Alamat

Jabatan

* KdPegawai Nama Alamat Jabatan

Tambah Simpan Update Batal

Gambar 4.76 User Interface Pegawai (Form 15)

4.11.16User Interface Kategori

Kategori

KdKategori

Nama Kategori

* KdKategori Nama Kategori

Tambah Simpan Update Batal

Gambar 4.77 User Interface Kategori(Form 16)

4.11.17 User Interface Customer


Customer

NoCustomer

Notranskasi

KdPegawai

NamaCustomer

TanggalBeli

QTYBeli

* NoCustomer Notranskasi KdPegawai NamaCustomer Tgl QTY

Tambah Simpan Update Batal

Gambar 4.78 User Interface Customer(Form 17)


BAB V

PENUTUP

5.1 Kesimpulan

Setelah melakukan observasi pada SALEMBA Toko Buku, maka

dapat diperoleh simpulan sebagai berikut :

1. Salemba Toko Buku merupakan perusahaan yang bergerak dalam

bidang Penjualan Buku dan ATK.

2. Sistem baru yang dikembangkan dapat menghindari kesulitan dalam

pencarian data barang, data persediaan, serta meningkatkan

produktivitas pekerjaan dan efisiensi waktu.

3. Dengan menggunakan program aplikasi yang dirancang didapat

keuntungan sebagai berikut:

a. Pencatatan data barang dan persediaan dapat lebih akurat.

b. Mudah menyajikan informasi

4. Dengan menggunakan sistem baru, memudahkan dalam pembuatan

laporan.

5. Perancangan sistem informasi ini menggunakan Unified Modelling

Language (UML), yang merupakan sebuah “bahasa” yang telah

menjadi standar instansi untuk visualisasi, merancang dan

mendokumentasikan suatu sistem.


5.2 Saran

Adapun saran-saran sehubungan dengan sistem baru yang dirancang adalah:

1. Dalam penerapan sistem baru ini, perlu dilakukan pelatihan terhadap

karyawan untuk menghindari terjadinya kesulitan dan kesalahan-

kesalahan dalam pengoperasian sistem.

2. Ketelitian dan kecermatan di bidang komputer harus diperhatikan

dengan sungguh-sungguh dan diperlukan tenaga ahli yang terampil

baik dalam pengoperasian maupun pengontrolan hardware.


DAFTAR PUSTAKA

Whitten. Jeffry L., Lonnie D. Bentley., Kevin C Ditman. 2004 Metode Desain dan

Analisis Sistem edisi 6. Yogyakarta: PenerbitAndidanMcGraw Hail Education

Kadir, Abdul. 2003. Pengenalan Sistem Informasi. Yogyakarta : Andi

Wahyudi, Bambang. 2008. Konsep Sistem Informasi. Yogyakarta : Andi

Nugroho, Bunafit.2005. Database Relasional dengan MYSQL. Yogyakarta: Andi

Th Arie Prabawati.2010. Belajar Pemrograman Visual Basic 2010. Yogyakarta: Andi

Anda mungkin juga menyukai