Skpl-oo.doc

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 A1 Pelanggan

Deskripsi 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

A2

Admin

tiket.com 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 U1 Pesan Pesawat U2 Pesan Hotel U3 Pesan Kereta Api U4 Sewa Mobil U5 Pesan Hiburan U6

Deskripsi

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 Waktu tanggap Ketersediaan data Waktu pemulihan

Tuntutan Kebutuhan

1.4.2 Atribut Sistem Perangkat Lunak Tabel 4. Atribut sistem perangkat lunak No SKPL

Kebutuhan Error-Handling Message Keamanan Portabilitas

Tuntutan Kebutuhan

1.4.3 Kebutuhan Lain Tabel 5. Kebutuhan Lain No SKPL

1.5

Kebutuhan Tampilan Aplikasi Format menu Warna aplikasi Jenis font

Tuntutan Kebutuhan

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

Jurusan Teknik Elektro UM

Nama Proses

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