Anda di halaman 1dari 5

Requirement Elicitation

 
A. Problem Definition
Beberapa masalah yang kami temukan pada case-1 antara lain :
1. Sistem pemesanan bus masih menggunakan cara konvensional, yakni
menggunakan telepon atau datang langsung ke tempat.
2. Di beberapa keadaan, ketika user sudah memesan bus. Kadangkala staf
administrasi harus menunggu konfirmasi dari sopir terlebih dahulu, apakah siap
mengantar atau tidak. Hal ini dinilai tidak efisien, karena user harus menunggu
terlebih dahulu.
3. Sistem pencatatan penggunaan bus, yang meliputi harga serta riwayat
perjalanan bus, masih dicatat di buku, kemudian baru diinputkan di excel yang
nantinya akan digunakan sebagai laporan.
4. Informasi mengenai pemeliharaan setiap bus, seperti pengecekan kondisi unit
bus, pembayaran pajak, dan pengeluaran untuk perawatan bus, dll masih
dicatat secara manual di buku.
 
B. Application-based Solution
Solusi yang dapat kami tawarkan untuk permasalahan yang ada adalah :
1. Kami menawarkan untuk membuat sistem pemesanan bus dengan
menggunakan aplikasi berbasis website. Selain untuk pemesanan bus, aplikasi
ini juga dapat mengelola informasi mengenai penggunaan dan membuat
catatan seputar maintenance setiap unit bus. 
2. Sedangkan untuk menangani kendala kesiapan sopir, sampai saat ini kami
hanya berencana untuk menuliskan status sopir (ready or not) pada tabel
informasi bus. Jadi, sopir harus mengupdate setiap hari status kesiapannya pada
aplikasi. Bila status sopir ‘siap’, maka pemesanan/booking bus dari user akan
divalidasi. Jika sopir tidak siap, maka pemesanan/booking tidak dapat
dilakukan, dan user harus mencari jadwal atau tanggal yang sesuai. 

 
Batasan operasional (constraint) pada aplikasi ini adalah :
1. Secara umum, pada aplikasi ini hanya menampilkan seputar informasi tentang
pengelolaan bus, yang meliputi pemeliharaan aset dan penggunaaan bus, serta
cara user untuk melakukan pemesanan bus.
2. Untuk output pada aplikasi ini, diharapkan dapat menghasilkan report/laporan
dalam bentuk excel. Hal ini cukup membantu, karena sebelumnya masih
dicatat di buku, yang dinilai tidak efisien dan tidak efektif.
3. Penyewa dapat memesan bus dan melihat maupun mencetak invoice.
4. Sopir dapat memberikan status (siap/tidak) dalam mengantar penumpang.
5. Staf administrasi dapat melakukan maintenance bus, berdasarkan informasi
valid yang ada pada table pemeliharaan aset unit bus.

C. User Identification
1. Admin : Staf Administrasi (Pak Saman). 
2. Pihak yang akan menyewa/booking.
3. Sopir bus.

D. User Requirements
User Requirement
No User Reqs Admin Penyewa Sopir Bus
UR 01 Pengguna membuka aplikasi melalui browser P P P
UR 02 Pengguna membutuhkan login ke aplikasi P P P
UR 03 Admin membutuhkan CRUD akun sopir P O O
UR 04 Pengguna membutuhkan informasi mengenai sopir P P P
UR 05 Admin dapat CRUD jadwal penggunaan bus P O O
UR 06 Pengguna dapat melihat jadwal penggunaan bus P P P
UR 07 Admin dapat membuat status bus dalam keadaan siap/tidak P O O
UR 08 Admin CRUD data kondisi aset bus P O O
UR 09 Pengguna membutuhkan riwayat penggunaan bus P P P
UR 10 Admin mengirimkan pesan (booking) bus ke sopir sebelum keberangkatan P O O
UR 11 Admin mencetak laporan penggunaan dan pemeliharaan aset bus P O O
UR 12 Admin membutuhkan CRUD akun penyewa P O O
UR 13 Admin membutuhkan CRUD informasi/biodata penyewa P O O
UR 14 Penyewa membutuhkan register sebelum login O P O
UR 15 Penyewa dapat membayar pemesanan bus O P O
UR 16 Admin dapat melihat status pembayaran penyewaan bus P O O
UR 17 Pengguna dapat melihat dan mencetak invoice atau bukti pembayaran P P O
UR 18 Pengguna dapat mengubah profile atau password P P P
UR 19 Sopir dapat melihat pesanan yang masuk sesuai tanggal dan tujuan bus O O P
UR 20 Sopir dapat memberikan status kesiapan (siap/tidak) O O P
E. Software Requirements 
Software Requirement
No Functional Reqs User Reqs terkait
FR 01 Aplikasi harus memiliki fitur untuk login UR 01, UR 02, UR14
FR 02 Aplikasi harus memiliki fitur untuk CRUD akun UR 03, UR 12, UR 18
FR 03 Aplikasi harus memiliki fitur CRUD data mengenai bus, seperti daftar ketersediaan dan tarif harga bus, dll UR 05, UR 06, UR 07, UR 08, UR 09, UR 19
FR 04 Aplikasi sebaiknya memiliki fitur untuk membuat jadwal penggunaan bus UR 05
FR 05 Aplikasi sebaiknya memiliki fitur untuk mengirimkan pesan (booking) bus ke sopir UR 10
Aplikasi harus memiliki fitur untuk mencetak laporan. Seperti, pendapatan dari penyewaan bus,
FR 06 UR 11, UR 16
pengeluaran dari setiap unit bus, serta daftar penyewa bus
FR 07 Aplikasi harus memiliki fitur untuk register sebelum login UR 14
FR 08 Aplikasi harus memiliki fitur untuk menampilkan jadwal ketersediaan bus UR 04, UR 05, UR 06
FR 09 Aplikasi sebaiknya memiliki fitur untuk menerima input biodata penyewa bus UR 13
FR 10 Aplikasi hendaknya memiliki fitur untuk melihat dan mencetak invoice UR 17
FR 11 Aplikasi harus memiliki fitur untuk melakukan pembayaran UR 15
FR 12 Aplikasi harus memiliki fitur untuk memberikan status kesiapan (siap/tidak) dalam mengantar penumpang UR 07, UR 20

Software Requirement
No NonFunctional Reqs FR terkait
NFR 01 Pesan (booking) yang dikirimkan dari admin ke sopir, pasti akan sampai kurang dari 1 jam. FR 05
NFR 02 Sistem dapat menjamin keamanan informasi penyewa FR 09
Autentifikasi user dengan password dan tersedia tingkatan user dengan kebutuhan fungsi yang berbeda
NFR 03 FR 01, FR 07
setiap usernya (user sopir/user admin).
NFR 04 Sistem dapat menjamin keamanan proses pembayaran penyewa FR 11

Narasumber :
Pak Saman (Wakil atau Admin Kerumahtanggaan) 

Informasi yang didapatkan dari wawancara (12-10-2021) :


1. Sistem penyewaan bus Polnep per hari.
2. Tidak ada perbedaan tarif harga sewa bus antara civitas akademik dan orang luar.
3. Booking bus dapat dilakukan via telepon/wa atau datang langsung ke tempat.
4. Alur pemesanan bus adalah, booking bus sesuai tanggal lalu ada kesepakatan
berupa tanda jadi (surat).
5. Informasi penggunaan bus dicatat di kertas lalu dimasukkan ke Excel untuk
pelaporan.
6. Ada kendala dengan sopir, yakni waktu tunggu. Jadi, jika penyewa sudah booking
bus dan sudah memilih tanggalnya. Maka admin harus menghubungi sopir terlebih
dahulu, apakah dia siap/tidak untuk mengantar penumpang. Dan admin harus
menunggu konfirmasi dari sopir terlebih dahulu, untuk mengvalidasi penyewaan
bus.
7. Sopir bus berasal dari dalam, yakni orang Polnep itu sendiri.
8. Untuk data penggunaan bus, dilaporakan setiap 3 bulan sekali.
9. Di dalam laporan tersebut tidak hanya memuat data penggunaan bus, tetapi ada data
lainnya (seperti penggunaan alat praktek dll).
10. Isi laporannya, untuk menunya terdiri dari, nama, tanggal penggunaan bus, lokasi
tujuan dll.
11. Daftar bus yang tersedia ada 3 unit. Informasi mengenai teknis seperti jumlah kursi
dan kondisi bus belum tersedia, dikarenakan pihak yang diwawancara tertutup
dalam memberikan informasi.
12. Daftar harga secara rinci juga belum tersedia, karena narasumber hanya
memberikan informasi mengenai harga yang berbeda di setiap tujuan.

Catatan :
Kedepannya kami akan mencari informasi yang lebih mengenai pengelolaan aset bus
polnep. Dikarenakan, pihak narasumber yang berwenang tidak berada di tempat dan
sulit untuk ditemui karena sesuatu dan lain hal. Dan yang menjadi narasumber
sementara saat ini adalah wakil atau admin pengurus pengelola bus. Yang kami rasa
belum dapat memberikan informasi yang lebih valid. 

Dokumentasi :

Anda mungkin juga menyukai