Deskripsi Rinci Kebutuhan

1.1 Kebutuhan antarmuka eksternal

1.1.1 Antarmuka pemakai

Pemakai berinteraksi dengan aplikasi tiket.com menggunakan web browser
dengan tampilan standar aplikasi web-based yang disusun dengan tag-tag html.
Aplikasi Web ini dapat menampilkan menu-menu dan gambar-gambar kepada
pemakai melalui monitor secara langsung. Tiket.com menerima masukan dari
pemakai melalui tombol pada keyboard untuk input data.

1.1.2 Antarmuka perangkat keras

Perangkat keras ini tidak memiliki antarmuka perangkat keras khusus. Namun
hanya menggunakan perangkat keras yang umum untuk digunakan sesuai
kebutuhan aplikasi tiket.com yakni PC, Keyboard, Mouse, Hardisk, Memory.
Dimana Sistem ini juga terhubung dengan jaringan computer dengan
menggunakan desktop

1.1.3 Antarmuka perangkat lunak

Aplikasi ini dapat dijalankan pada lingkungan system operasi Microsoft
windowsXp/Vista/7, Lunox, dan Mac OS. Untuk Mengakses Tiket.com dapat
menggunakan segala jenis browser seperti Internet Explorer, Mozila Firefox,
Google Chrome, dll.
 Tampilan Tiket.com

1.1.4 Antarmuka komunikasi

Tiket.com mnerupakan aplikasi yang dapat diakses dengan jaringan global.

Sehingga pelanggan bisa dilayani oleh lebih dari satu pegawai dengan
menggunakan database yang sama. Dan pihak yang bertugas(admin,menejer) bisa
memonitor system lewat jaringan komputer. Dengan demikian aliran informasi
menjadi lebih lancar.

1.2 Perancangan Rinci

1.2.1 Use Case

Use Case Diagram mendeskripsikan interaksi antara satu atau lebih actor dengan
system informasi. Yang dibuat berikut adalah usecase diagram dari system
informasi tiket.com. Sistem informasi tiket.com terdiri dari dari 2 aktor yaitu
peanggan dan admin.

Jurusan Teknik Elektro UM SKPL-OO Halaman 2 dari 8

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Elektro-UM dan bersifat rahasia.
Dilarang untuk mereproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Elektro UM
 Gambar 1.Use Case Diagram

1.2.1.1 Activity Diagram

Gambarkan activity diagram. Awali dengan Context diagram dan sedikit penjelasan berupa
narasi jika perlu. Perhatikan kaidah perancangan :
- Activity diagram mendeskripsikan aktivitas sistem, activity diagram mendeskripsikan satu
atau gabungan dari beberapa use case diagram

1.2.1.2 Swimlane Diagram

Jurusan Teknik Elektro UM SKPL-OO Halaman 3 dari 8

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Elektro-UM dan bersifat rahasia.
Dilarang untuk mereproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Elektro UM
1.2.2 Deskripsi Use Case

1.2.2.1 Definisi Aktor dan dan Use Cse

Tabel Defenisi Aktor
No Aktor Deskripsi
A1 Pelanggan Pengguna yang berinteraksi dengan sistem informasi
tiket.com untuk melakukakan pembelian tiket, yang
dimulai dari tampilan awal, registrasi akun, dan
login untuk dapat mengakses system informasi
tiket.com
A2 Admin Pengguna yang berinteraksi dengan sistem informasi
tiket.com untuk melakukan verifikasi data dimulai
dari pembuatan akun, mengatur data, laporan data,
sampai penetakan tiket.

Tabel Defenisi Use Case

No Use Case Deskripsi
U1 Pesan Pesawat
U2 Pesan Hotel
U3 Pesan Kereta Api
U4 Sewa Mobil
U5 Pesan Hiburan
U6

1.2.2.2 Skenario Use Case

Tabel Skenario 1
No.Use Case
Nama Use Case
Tujuan
Deskripsi
Aktor Yang Terlibat
Aksi Aktor Reaksi Sistem
Skenario Normal

Tabel Skenario 1

Tabel Skenario 2
No.Use Case
Nama Use Case
Tujuan
Deskripsi
Aktor Yang Terlibat

Jurusan Teknik Elektro UM SKPL-OO Halaman 4 dari 8

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Elektro-UM dan bersifat rahasia.
Dilarang untuk mereproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Elektro UM
 Aksi Aktor Reaksi Sistem
Skenario Normal

Tabel Skenario 1

Tabel Skenario 3
No.Use Case
Nama Use Case
Tujuan
Deskripsi
Aktor Yang Terlibat
Aksi Aktor Reaksi Sistem
Skenario Normal

Tabel Skenario 1

Tabel Skenario 4
No.Use Case
Nama Use Case
Tujuan
Deskripsi
Aktor Yang Terlibat
Aksi Aktor Reaksi Sistem
Skenario Normal

Tabel Skenario 1

Tabel Skenario 5
No.Use Case
Nama Use Case
Tujuan
Deskripsi
Aktor Yang Terlibat
Aksi Aktor Reaksi Sistem
Skenario Normal

Jurusan Teknik Elektro UM SKPL-OO Halaman 5 dari 8

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Elektro-UM dan bersifat rahasia.
Dilarang untuk mereproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Elektro UM
 Tabel Skenario 1

1.3 Realisasi Use Cse

Uraikan dengan ringkas, tentang realisasi use case diagram anda

1.3.1 Identifikasi Paket dan Kelas

Deskripsikan paket dan kelas pada use case:

- Paket analisis
- Kelas analisis

1.3.2 Diagram Realisasi Use Case

1.3.3 Class Diagram

1.3.4 Sequence Diagram

1.4 Deskripsi Kebutuhan Non Fungsional

Uraikan dengan ringkas kebutuhan non fungsional dalam tabel sebagai berikut. Isilah Kolom
Requirement dengan kalimat yang jelas dan kelak dapat ditest untuk dipenuhi. SRS-Id adalah
nomor requirement yang harus ditelusuri pada saat test. Tuliskan N/A bila Not Applicable..

Catatan:
Availability: ketersediaan aplikasi, misalnya harus terus menerus beroperasi 7 hari perminggu,
24 jam per haritanpa gagal
Reliability: keandalan, misalnya tidak pernah boleh gagal(atau kegagalan yang ditolerir adalah
…%) sehingga harus dipikirkan fault tolerant architecture. Biasanya hanya perlu untuk Critical
Application yang jika gagal akan berakibat fatal.
Ergonomy: kenyamanan pakai bagi pengguna
Portability: kemudahan untuk dibawa dan dioperasikan ke mesin/sistem operasi/platform yang
lain
Memory: jika perhitungan kapasitas memori internal kritis (misalnya untuk SW yang harus
dijadikan CHIPS dan ukurannya harus kecil
Response time: Batasan waktu yang harus dipenuhi. Sangat penting untuk aplikasi Real Time.
Contoh: “Aplikasi harus mampu menampilkan hasil dalam 4 detik”, atau “ATM harus menarik
kembali kartu yang tidak diambil dalam waktu 30 detik”
Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem
kontrol di pabrik
Security: aspek keamanan yang harus dipenuhi.

Jurusan Teknik Elektro UM SKPL-OO Halaman 6 dari 8

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Elektro-UM dan bersifat rahasia.
Dilarang untuk mereproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Elektro UM
1.4.1 Performansi

Tabel 3. Kebutuhan Performansi

No SKPL Kebutuhan Tuntutan Kebutuhan
Waktu tanggap
Ketersediaan data
Waktu pemulihan

1.4.2 Atribut Sistem Perangkat Lunak

Tabel 4. Atribut sistem perangkat lunak

No SKPL Kebutuhan Tuntutan Kebutuhan

Error-Handling
Message
Keamanan
Portabilitas

1.4.3 Kebutuhan Lain

Tabel 5. Kebutuhan Lain
No SKPL Kebutuhan Tuntutan Kebutuhan
Tampilan Aplikasi
Format menu
Warna aplikasi
Jenis font

1.5 Atribut Kualitas Perangkat Lunak

1.5.1 Kehandalan

1.5.2 Keremawatan (maintability)

1.6 Batasan Perancangan

1.7 Matriks Keterunutan

Tabel 6. Matriks keterunutan

Jurusan Teknik Elektro UM SKPL-OO Halaman 7 dari 8

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Elektro-UM dan bersifat rahasia.
Dilarang untuk mereproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Elektro UM
 No SKPL Nama Proses

Jurusan Teknik Elektro UM SKPL-OO Halaman 8 dari 8

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Elektro-UM dan bersifat rahasia.
Dilarang untuk mereproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Elektro UM