SKPL-iRepairApp V 2

Spesifikasi Kebutuhan
Perangkat Lunak
for
iRepair Application
Prepared by:
Franata Ardhi S 18051214033
Elwino Alif R 18051214062
Alfando Vifan S 18051214076
S1 SISTEM INFORMASI
11 DESEMBER 2019
Copyright © 1999 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.
Software Requirements Specification for iRepair App Page ii
Table of Contents
Table of Contents...........................................................................................................................ii
Revision History.............................................................................................................................ii
1. Introduction..............................................................................................................................1
1.1 Purpose...........................................................................................................................................1
1.2 Document Conventions...................................................................................................................1
1.3 Intended Audience and Reading Suggestions.................................................................................1
1.4 Product Scope.................................................................................................................................1
1.5 References......................................................................................................................................1
2. Overall Description..................................................................................................................2
2.1 Product Perspective.........................................................................................................................2
2.2 Product Functions...........................................................................................................................2
2.3 User Classes and Characteristics.....................................................................................................2
2.4 Operating Environment...................................................................................................................2
2.5 Design and Implementation Constraints.........................................................................................2
2.6 User Documentation.......................................................................................................................2
2.7 Assumptions and Dependencies......................................................................................................3
3. External Interface Requirements...........................................................................................3
3.1 User Interfaces................................................................................................................................3
3.2 Hardware Interfaces........................................................................................................................3
3.3 Software Interfaces.........................................................................................................................3
3.4 Communications Interfaces.............................................................................................................3
4. System Features.......................................................................................................................4
4.1 System Feature 1.............................................................................................................................4
4.2 System Feature 2 (and so on)..........................................................................................................4
5. Other Nonfunctional Requirements.......................................................................................4
5.1 Performance Requirements.............................................................................................................4
5.2 Safety Requirements.......................................................................................................................5
5.3 Security Requirements....................................................................................................................5
5.4 Software Quality Attributes............................................................................................................5
5.5 Business Rules................................................................................................................................5
6. Other Requirements................................................................................................................5
Appendix A: Glossary....................................................................................................................5
Appendix B: Analysis Models.......................................................................................................5
Appendix C: To Be Determined List............................................................................................6
Revision History
Name Date Reason For Changes Version
Software Requirements Specification for iRepair Application
Page 1
1. Pendahuluan
1.1 Tujuan Penulisan Dokumen

Dokumen ini menjelaskan tentang spesifikasi dan persyaratan perangkat lunak iRepair Application.
Tujuan dari penulisan dokumen ini adalah untuk memberikan penjelasan mengenai perangkat lunak
yang akan dibuat.
Pengguna dari dokumen ini adalah pengembang perangkat lunak dari iRepair Application. Dokumen ini
akan digunakan sebagai bahan acuan dalam proses pengembangan dan sebagai bahan evaluasi pada saat
proses pengembangan perangkat lunak maupun diakhir pengembangannya. Dengan adanya dokumen ini
diharapkan pengembangan perangkat lunak akan lebih tertata rapi dan lebih lebih terfokus serta tidak
menimbulkan salah makna terutama bagi pengembang perangkat lunak iRepair Application
1.2 Lingkup Masalah
Di era sekarang, banyak sekali pengguna kendaraan baik mobil maupun motor. Tiap tahun
pengguna kendaraan di Indonesia selalu bertambah. Namun, tidak semua pemilik kendaraan
memperhatikan kesehatan kendaraan nya karena faktor individu yang tidak terlalu memperharikan
kendaraanya sendiri dan juga faktor tidak sabar akan sampai ditujuan, oleh karena itu para
pengendara selalu memacu kendaraanya sekencang mungkin agar sampai ditujuan dengan waktu
yang cepat, akbiat dari itulah tidak sedikit pengendara bermotor megalami mogok ditengah
perjalanan & tidak memiliki wawasan tentang mesin.
Terutama saat musim mudik lebaran para perantau banyak pulang ke kampung halamanya tetapi
hal yang paling ditakutkan ialah mogok ditengah perjalanan yang sepi dan tidak ada mengetahui
bengkel terdekat dimana.
Atas dasar inilah kami ingin mengembangkan aplikasi “iRepair Application” untuk memudahkan
masyarakat menyelesaikan masalah kendaraan tanpa repot-repot mencari bengkel, karena
diaplikasi ini montirlah yang akan datang ke tempat anda yang mengalami masalah dan dapat
mengerjakan tugasnya sesuai dengan masalah yang ada di kendaraan anda
1.3 Definisi dan Istilah

Berikut adalah daftar istilah dan definisi penting yang digunakan dalam dokumen SKPL ini:
 iRepair : Aplikasi bengkel modern
 SRS : Software Requirements Specification, atau SKPL
 SKPL : Spesifikasi Kebutuhan Perangkat Lunak
Page 2
1.4 Aturan Penamaan dan Penomoran

Penulisan dokumen SKPL ini menggunakan berbagai macam aturan penamaan dan
penomoran yang berbeda-beda untuk beberapa bagian tertentu. Aturan penamaan dan penomoran
yang digunakan berdasarkan hal/bagian tersebut adalah seperti yang tercantum pada Tabel 1 berikut
ini.
Tabel 1 Aturan Penamaan dan Penomoran
Hal/Bagian Aturan Penomoran/Penamaan
Kebutuhan Fungsional SKPL-FXX : Menunjukkan kebutuhan fungsional ke-

XX
Kebutuhan Non SKPL-NFXX : Menunjukkan kebutuhan non

Fungsional fungsional ke-XX
1.5 Referensi
Dokumen dokumen yang digunakan sebagai referensi dalam pembuatan SKPL ini
adalah sebagai berikut:
 https://lms.ipb.ac.id/pluginfile.php/22494/mod_resource/content/0/1213_Genap/03._Contoh_SKP
L_VMS.pdf
 https://hanungnp.staff.telkomuniversity.ac.id/files/2015/04/contoh-SKPL-Sistem-informasi-tugas-
akhir-SISTA.pdf
 https://hanungnp.staff.telkomuniversity.ac.id/files/2017/12/contoh-SKPL-MK-RKPL-2017-1.pdf
1.6 Ikhtisar Dokumen

Dokumen ini secara garis besar terdiri dari 6 bagian dengan perincian sebagai berikut:
 Pendahuluan: merupakan pengantar dokumen SKPL ini yang tujuan penulisan,lingkup masalah,
definisi dan istilah, aturan penamaan, referensi
 Deskripsi umum perangkat lunak: menjelaskan tentang deskripsi umum dari aplikasi iRepair yang
meliputi deskripsi umum sistem, fungsi produk, karakteristik pengguna, batasan, dan lingkup
operasi
 Deskripsi umum kebutuhan: merupakan deskripsi kebutuhan dari aplikasi iRepair yang meliputi
kebutuhan antarmuka eksternal, deskripsi fungsional, deskripsi perancangan data, designe
tampilan antarmuka
 Kebutuhan fungsional: merupakan kebutuhan fungsional atau kebutuhan inti dari aplikasi iRepair
meliputi semua sistem dari iRepair dari mulai sistem pertama sampai akhir
 Kebutuhan non fungsional: merupakan kebutuhan non fungsional atau kebutuhan tambahan dari
iRepair application
Page 3
2. Deskripsi Umum Perangkat Lunak
2.1 Deskripsi Umum Sistem

Aplikasi iRepair ini merupakan trobosan dari kami untuk masyarakat dan juga menjawab keluhan
masyarakat terutama teman teman mahasiswa kami yang selalu mengeluhkan akan tidak adanya
bengkel ditempat tempat terpencil atau jauh dari kota besar dan juga tidak adanya bengkel pada
malam hari ketika mereka pulang kekampung halaman.
Atas dasar itulah aplikasi iRepair ini kami buat dimana pengendara selaku user akan mengirim
data lokasi serta foto kendaraan yang nantinya akan divalidasi oleh admin kebenaranya demi tidak
adanya laporan palsu atau hoax, setelah laporan terbukti asli admin langsung mengarahkan data
tersebut ke mekanik yang selaku orang akan memperbaiki masalah pada kendaraan si
pengendara.
Aplikasi iRepair juga menyediakan layanan bayar cash (langsung bayar mekanik) ataupun melalui
transfer bank, mengenai nominal tergantung mekanik yang bertugas ditempat akan menentukan
serta penilaian kepuasan pelanggan terhadap mekanik yang betugas yang nantinya aka menjadi
bahan evaluasi pula untuk mekanik tersebut
2.2 Fungsi Produk

Perangkat Lunak iRepair ini mempunyai beberapa fungsi utama, antara lain:
 (SKPL-F1) Halaman Login pengguna (user)

 (SKPL-F2) Halaman Login Admin
 (SKPL-F3) Halaman Login Mekanik
 (SKPL-F4) Halaman untuk melaporkan masalah pengguna
 (SKPL-F5) Halaman admin untuk memvalidasi data dari pengguna
 (SKPL-F6) Halaman mekanik menerima orderan dari admin
 (SKPL-F7) Halaman pembayaran oleh pengguna
 (SKPL-F8) Halaman penilaian untuk mekanik
2.3 Karakteristik Pengguna

Karakteristik pengguna dari iRepair dijabarkan dalam tabel berikut ini.
Kategori Tugas Hak Akses ke Kemampuan yang

Pengguna aplikasi harus dimiliki
Admin  Mengechek  Mengelola data  Menguasai

semua data pengguna sistem basis
pada sistem  Mengelola data data
iRepair meknaik
 Memvalidasi  Mengelola data
Page 4
data laporan keuangan yang

 Mencari masuk ataupun
mekanik yang keluar
mampu  Memvalidasi
bertugas data laporan
masalah
 Menghapus
laporan palsu
Mekanik  Memperbaiki  Menerima  Berpengala

kendaraan orderan dari man di dunia
 Memberikan admin automotive
masukan pada  Melihat hasil  Menguasai
pengendara penilaian bidang
(user)  Melihat data kendaraan
laporan ringan
User  Melaporkan  Membuat data  jujur

masalah laporan
 Memberi  Melihat daftar
penilaian mekanik yang
 Membayar bertugas
 Melihat riwayat
transaksi
2.4 Batasan
Pengembangan iRepair ini memiliki keterbatasan-keterbatasan yaitu sebagai berikut :
1. iRepair hanya dapat digunakan menggunakan akses paket data atau wifi
2. iRepair hanya bisa diakses menggunakan aplikasi (tidak ada web)
3. Keterbatasan dari sisi perangkat keras yang digunakan, contohnya kapasitas memori yang terbatas,
kapasitas storage yang terbatas, dan input hanya berupa text dan angka, serta beberapa character.
Page 5
2.5 Lingungan Operasi
 Lingkup operasi dari iRepair hanya pada lingkup keberadan beberapa mekanik terdekat, diluar
batas area jangkauan mekanik orderan tidak bisa dilayani
3. Deskripsi Umum Kebutuhan
3.1 Kebutuhan antarmuka eksternal
3.1.1 Antarmuka pengguna
Perangkat lunak yang akan dikembangkan membutuhkan interaksi dengan pemakai aplikasi
perangkat lunak. Dalam melakukan interaksi dengan pemakai perangkat lunak ini
membutuhkan perangkat untuk melakukan proses transformasi input dan output dari dan ke
pemakai. Perangkat tersebut adalah sebagai berikut:
 Perangkat Jaringan
Perangkat Jaringan wifi / paket dataJaringan adalah perangkat utama untuk para pengguna
agar bisa mengakses aplikasi ini tanpa adanya jaringan wifi atau paket data pengguna tidak
akan menggunakan aplikasi ini, perangkat ini yang nantinya akan mengirim data data
kerusakan dan lokasi pengguna.
 Smartphone
Tentunya perangkat ini juga tak kalah penting karena nantinya akan digunankan oleh pengguna
untuk proses melapor, membayar atau memberikan penilaian kepada mekanik yang bertugas
melalui aplikasi dan juga sebagai sarana untuk menampilkan semua antarmuka yang berada pada
sistem.
 Perangkat GPS
Perangkat ini yang nantinya akan mengirim lokasi akurat kepada admin agar dapat mengirim
mekanik ke tujuan pengguna.
3.1.2 Antarmuka perangkat keras
iRepair ini berhubungan dengan smartphone sebagai alat utama dengan sistem operasi Android
yang nantinya akan dijalankan mengunakan aplikasi sehingga dapat memudahkan pengguna
3.1.3 Antarmuka perangkat lunak

Page 6
iRepair merupakan progam yang akan dikembangkan melalui android studio dan sistem ini
berhubungan dengan aplikasi yang memanfaatkan server , database ,API serta menggunakan bahasa
pemrogaman Javascript, PHP dan MySQL.
3.1.4 Antarmuka komunikasi
iRepair merupakan sistem yang berbasis Aplikasi. Server yang digunakan adalah server local,
sehingga hanya bisa diakses dengan cara terhubung dengan jaringan paket data atau wifi.
3.2 Deskripsi Fungsional
3.2.1 Use Case Diagram

Page 7
Gambar 1 Use Case Diagram
3.2.2 Fungsi 1 : Daftar atau Login Pengguna
3.2.2.1 Skenario Fungsi 1: Daftar atau Login Pengguna
Kode Use UC-001

Case
Nama Use Daftar atau Login Pengguna
Case
Aktor Pengguna
Deskripsi Pengguna daftar dengan mengisi data yang nantinya akan mengirim
ke sistem dan nantinya akan diteruskan ke menu Log in
Relasi (sesuai relasi yg ada di Usecase Diagram)
Kondisi Awal Pengguna belom bisa masuk ke menu utama karena datanya belom
terdaftar di database
Kondisi Akhir Pengguna mempunyai akun dan bisa masuk kemenu utama aplikasi
Alur Kejadian Aktor Sistem
Normal 1. Membuka halaman utama
2. Sistem menampilkan
tampilan login dan daftar
3. Penguna baru harus masuk ke
menu daftar terlebih dahulu agar
mendapatkan akun
3. Sistem menampilkan menu
daftar
4. Pengguna menggisi data yang
sudah tertera dimenu daftar
5 Sistem menyimpan data yang
sudah diisi dan langsung
mengarah ke menu login
sebagai pertanda pendaftaran
berhasil
Page 8
6 Pengguna langsung mengarah ke

halaman login dan mengisi
username dan password yang tadi
sudah dibuat
7 Sistem mencocokan data yang
tadi sudah dibuat
Alur kejadian
alternatif Aktor Sistem
1. Memasukkan username dan password
2. Memeriksa valid tidaknya data
masukandenganmemeriksakeDatab
ase
3. Menampilkanpesan login tidak
valid
yang valid
masukandengan memeriksake
Database
6. Masuk ke menu utama aplikasi
3.2.2.2
Diagram
aktivitas
: Daftar
atau
Login
Pengguna
Page 9
3.2.2.3 Diagram Squensial : Daftar atau Login Pengguna

Page 10
3.2.2.4 Diagram Kolaborasi: Daftar atau Login Pengguna
3.2.3 Fungsi 2 : Log in Mekanik
3.2.3.1 Skenario Fungsi 2: Log in Mekanik
U
C
-
0
0
2
L
o
g
i
n
M
e
k
a
n
i
k
M
e
k
a
n
i
k
M
e
k
a
n
i
k
y
Page 11
ang sudah terdafar sebagai pegawai akan masuk menggunakan id

yang sudah diberikan admin
Kondisi Awal Mekanik belom masuk ke menu utama karena belom memasukan id
untuk Login
Kondisi Akhir Mekanik masuk kemenu utama mekanik menuggu orderan masuk
tampilan login , daftar , Login
mekanik
3. Mekanik masuk ke menu login
mekanik
4. Masuk halaman login
mekanik
5 Mekanik masuk menggunakan id
dan pasword yang sudah dimiliki
6 sistem mencocokan dengan
data yang ada didatabase
7 setelah berhasil sistem akan
langsung mengarahkan ke menu
mekanik
Alur kejadian
1. Mekanik memasukkan username dan
password
masukan dengan memeriksa ke
Database
valid
yang valid
Database
6. Masuk ke menu utama mekanik
tanda login berhasil
Page 12
3.2.3.2 Diagram Activitas: Login Mekanik
3.2.3.3 Diagram Squensial: Login Mekanik

Page 13
3.2.3.4
D
i
a
g
r
a
m
Kolaborasi: Login Mekanik

Page 14
3.2.4 Fungsi 3 : Login Admin
3.2.4.1 Skenario: Login Admin
Kode Use UC-003

Case
Nama Use Log in Admin
Case
Aktor Admin
Deskripsi Admin yang bertugas sesuai dengan tugasnya
Kondisi Awal Admin belom masuk ke menu admin
Kondisi Akhir Admin sudah berada di menu admin dan akan menjalankan tugasnya
tampilan login , daftar , Login
mekanik, Login admin
3. Admin masuk ke menu login
Admin
4. Masuk halaman login admin
5 Admin masuk menggunakan id

yang sudah dimiliki
6 sistem mencocokan dengan
data yang ada didatabase
7 setelah berhasil sistem akan
langsung mengarahkan ke menu
Admin
Alur kejadian
1. Mekanik memasukkan username dan
password
masukan dengan memeriksa ke
Database
valid
Page 15

yang valid
Database
6. Masuk ke menu utama Admin
tanda login berhasil
3.2.4.2Di
agram
Aktivitas:
Login
Admin
3.2.4.3Di
agram
Squensial: Login Admin

Page 16
3.2.4.4 Diagram Kolaborasi: Login Mekanik
3.2.5
Fungsi 4: Melaporkan Masalah Pelanggan

Page 17
3.2.5.1 Skenario: Melaporkan Masalah Pelanggan
Kode Use UC-004

Case
Nama Use Melaporkan Masalah Pelanggan
Case
Aktor Pengguna
Deskripsi Pengguna ingin melaporkan masalah kendaraanya dengan mengirim
foto dan lokasi yang akurat
Kondisi Awal Pengguna masuk menu utama aplikasi dan ingin melaporkan
masalah pada kendaraanya
Kondisi Akhir Pengguna mengirim foto dan lokasi akurat ke sistem
Normal 1. Membuka halaman menu utama
aplikasi
tampilan ,menu laporan, riwayat
transaksi dll,
3. Pengguna masuk ke menu
laporkan masalah
4. Masuk halaman Laporankan
masalah
5 penguna mengisi data data
laporan dan juga menentukan lokasi
akurat
6 sistem menyimpan data ke
data base
7 sistem akan loading menandakan
data menunggu validasi dari admin
Alur kejadian
Page 18
3.2.5.2 Diagram Aktifitas: Melaporkan Masalah Pelanggan

Page 19
3.2.5.3 Diagram Squensial: Melaporkan Masalah Pelanggan
3.2.5.4 Diagram Kolaborasi: Melaporkan Masalah Pelanggan

Page 20
3.2.6
Fun
gsi
5:
Validasi Data
3.2.6.1 Skenario: Validasi Data
Kode Use UC-005

Case
Nama Use Validasi data
Case
Aktor Admin
Deskripsi Admin yang bertugas akan menerima data yang sudah dikirim oleh
penguna dan akan dilakukanya validasi sebelum mengirim mekanik
kelokasi pengguna
Kondisi Awal Admin menerima data melalui database yang telah dikirim oleh
pengguna
Kondisi Akhir Proses validasi oleh admin sudah selesai dan akan mengirim
Page 21
mekanik ke lokasi penguuna

Normal 1. Membuka halaman admin
tampilan data yang ada
didatabase yang sudah dikirim
oleh pengguna
3. Admin melihat data data yang
sudah dikirim dan dilakukan validasi
ke semua data yang telah dikirim
pengguna
4. Sistem menampilkan semua
data yang sudah dikirm
pengguna
5 ketika data sudah dicek data
tersebut akan divalidasi dengan
memencet tombol validasi
6 sistem mengirim notifikasi ke
menu laporan(pengguna)
bahwa data sudah tervalidasi
7 Admin memilih mekanik yang siap
bertugas
8 sistem membuka data base
mekanik yang aktif (sudah login)
yang nantinya akan menerima
orderan
Alur kejadian
1. . Mengisi data alamat, dan foto
kerusakan
2. Memerima pesanan pelanggan
3. Memvalidasi data foto
kerusakan (Tidak valid)
4 Menampilkan pesan suntuk
mengirim ulang data pesanan
5 Mengisi data alamat, dan foto
kerusakan dengan benar
6. Validasi ulang data, (jika data
yang sudah dikirim masih
dinyatakan tidak valid maka sistem
akan terus mengirim ulang sampai
data itu dinyatakan valid oleh
Page 22
admin)
3.2.6.2 Diagram Aktivitas: Validasi Data

Page 23
3.2.6.3 Diagram Squensial: Validasi Data
3.2.6.4 Diagram Kolaborasi: Validasi Data

Page 24
3.2.7 Fungsi 6 : Mekanik Menerima Orderan
3.2.7.1 Skenario : Mekanik Menerima Orderan
Kode Use UC-006

Case
Nama Use Mekanik Menerima Orderan
Case
Aktor Mekanik
Deskripsi Mekanik yang sudah login menandakan mereka sudah siap untuk
bertugas dan akan menerima orderan dari admin yang bertugas
Kondisi Awal Mekanik yang sudah login menunggu orderan dari admin yang
bertugas
Kondisi Akhir Mekanik yang sudah login mendapatkan orderan dari admin ynag
bertugas dan nantinya meknaik akan menuju kelokasi pengguna
Normal 1. Masuk halaman Menu mekanik
2. Mekanik menerima orderan dari

admin berupa data yang sudah
tervalidasi
notifikasi ke pelanggan bahwa
sudah mendapatkan mekanik
4 Sistem menampilkan data yang
telah divalidasi admin
5 Mekanik menuju kelokasi
pelanggan
Alur kejadian
1. . Masuk halaman menu mekanik
2. Menampilkan notifikasi bahwa
mekanik menerima orderan
3 Mekanik menolak orderan karna
ada masalah
4 Menampilkan ke menu admin
bahwa mekanik sedang sibuk
Page 25
5 admin akan melemparkan ke

mekanik lain yang siap bertugas
3.2.7.2 Diagram Aktivitas: Mekanik Menerima Orderan

Page 26
3.2.7.3 Diagram Squensial: Mekanik Menerima Orderan
3.2.7.4
D
i
a
g
r
a
m
Kolaborasi: Mekanik Menerima Pesanan

Page 27
3.2.8
Fung
si 7 :
Pembayaran
3.2.8.1 Skenario: Pembayaran
Kode Use UC-007

Case
Nama Use Pembayaran
Case
Aktor Pengguna
Deskripsi Pengguna yang sudah diperbaiki kendaraanya oleh mekanik
melakukan pembayaran melalui transfer bank
Page 28
Kondisi Awal Pengguna belom tau nominal yang akan dibayar

Kondisi Akhir Pengguna sudah mengetahui nominal yang akan dibayar melalui
mekanik dan melakukan pembayaran melalui transfer bank
Normal 1. Masuk menu pembayaran
2. sistem akan menunjukan

daftar bank yang nantinya bisa
distransfer
3 Pengguna akan memilih daftar
bank dan memasukan nominal yang
akan dibayar
4 admin mengecek bahwa
nominal sudah masuk
kerekening
5 Sistem akan menampilkan bahwa
pembayaran sukses
Alur kejadian
1. . Masuk menu pembayaran
2. sistem akan menunjukan
daftar bank yang nantinya bisa
distransfer
3 Pengguna tidak jadi bayar lewat
transfer bank tapi membayar
langsung kemekanik
3 sistem memberi info kalau
pelanggan bayar langsung ke
mekanik
Page 29
3.2.8.2 Diagram Aktifitas: Pembayaran

Page 30
3.2.8.3 Diagram Squensial: Pembayaran
3.2.8.4
Di
ag
ra
m
Kolaborasi: Pmebayaran
Page 31
3.2.9 Fungsi 8 : Rating
3.2.9.1 Skenario: Rating
Kode Use UC-008

Case
Nama Use Rating
Case
Aktor Pelanggan
Deskripsi Pelanggan yang sudah membayar nantinya akan memberi penilaian
kerja kepada mekanik yang bertugas
Page 32

Kondisi Awal Pengguna belom memberikan penilaian kepada mekanik
Kondisi Akhir Pengguna sudah mengirim data penilaian sebagai evaluasi atau
penilaian kerja mekanik
Normal 1. Masuk menu From kepuasan
2. Sistem akan menampilkan

form kepuasan kinerja mekanik
3 Pengguna akan mengisi form
kepuasan
4 Sistem akan memasukan form
kepuasan ke data base
5 Sistem akan menampilkan bahwa
mengisi form kepuasan telah
berhasil
Alur kejadian
3.2.9.2
Di
ag
ra
m
Atifitas: Rating
Page 33
3.2.9.3
Di
ag
ra
m
Squensial: Rating
Page 34
3.2.9.4
Dia
gra
m
Kolaborasi: Rating
Page 35
3.3 Deskripsi Perancangan Data

Page 36
3.3.1 Diagram ERD iRepair
3.3.2
C
D
M
iRepair
Page 37
3.3.3 PDM iRepair

Page 38
3.4 Desain
Tampilan
Antarmuka
Sistem
3.4.1 UI Login Pelanggan

Page 39
3.4.2 UI Login
Mekanik
Page 40
3.4.3 UI Login
Admin
Page 41
3.4.4 UI Daftar Pengguna Baru

Page 42
3.4.5 UI Menu utama

Page 43
3.4.6 UI Melaporkan Masalah

Page 44
3.4.7 UI Validasi Data (Admin)

Page 45
3.4.8 UI Data Tervalidasi

Page 46
3.4.9 UI Mekanik Menerima Orderan

Page 47
3.4.10 UI Berhasil Mendapatkan Mekanik

Page 48
3.4.11 UI Pembayaran
Page 49
3.4.12 UI Rating
Page 50
3.4.13 UI Selesai
Page 51
4. Kebutuhan Fungsional
SKPL-Id Nama Fungsi Keterangan
SKPL-F1 Daftar dan Login Pelanggan Merupakan awal dari pengguan menggunakan
aplikasi iRepair dimana pengguna harus
mempunyai akun terlebih dahulu untuk bisa
menggunakan aplikasi ini
SKPL-F2 Login Mekanik Mekanik merupakan aktor yang tugasnya

memperbaiki kendaraan pengguna yang
bermasalah dimana mekanik yang sudah
terdaftar diharuskan untuk login ke menu
mekanik sebagai tanda bahwa mereka siap
untuk menerima orderan
SKPL-F3 Login Admin Admin merupakan aktor yang bertugas untuk

memvalidasi dan memegang semua data yang
berada diaplikasi ini dimana admin juga harus
login untuk memulai tugasnya
SKPL-F4 Melaporkan Masalah Pengguna Menu dimana pengguna dapat melaporkan

masalah yang dialami oleh kendaraanya disini
pengguna selaku aktor diharuskan mengisi
data data yang diperlukan untuk proses laporan
SKPL-F5 Validasi data Data yang telah diisi oleh pengguna tadi akan
langsung masuk kedata base dan menu admin
dimana admin akan melakukan validasi
terhdapat laporan tersebut agar tidak terjadinya
laporan fiktif
SKPL-F6 Mekanik Menerima orderan Disini merupakan mekanik akan menerima

orderan berupa data yang sudah divalidasi
admin kebenaranya dan mekanikpun bergegas
menuju kelokasi pengguna
SKPL-F7 Pembayaran. Menu pembayaran oleh pengguna dimana

terdapat banyak pilihan transfer bank ataupun
langung bayar di mekanik tarif yang ditentukan
ialah sesuai yang dikatakan mekanik
Page 52
SKPL-F8 Rating Menu dimana pengguna mengisi form

kepuasan pelanggan sebagai bentuk penilaian
ke mekanik
5. Kebutuhan Non Fungsional
SKPL-Id Keterangan
SKPL-NF1 Belum bisa dipakai di luar pulau atau jangkuan masih pendek
SKPL-NF Menggunakan user login berbeda-beda pada setiap bagian

aktor seperti admin,mekanik,pengguna
SKPL-NF Sangat bergantung pada kekuatan sinyal di tempat tempat

terpencil
SKPL-NF Biaya yang agak terlalu mahal
SKPL-NF Tidak adanya garansi yang berkala
6. Other Requirements
<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>
Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SRS.>
Page 53
Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams,
state-transition diagrams, or entity-relationship diagrams.>
Appendix C: To Be Determined List

<Collect a numbered list of the TBD (to be determined) references that remain in the SRS so they
can be tracked to closure.>

SKPL-iRepairApp V 2

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SKPL-iRepairApp V 2

Diunggah oleh

Hak Cipta:

Format Tersedia

Spesifikasi Kebutuhan

1.1 Tujuan Penulisan Dokumen

1.2 Lingkup Masalah

1.3 Definisi dan Istilah

1.4 Aturan Penamaan dan Penomoran

Tabel 1 Aturan Penamaan dan Penomoran

Hal/Bagian Aturan Penomoran/Penamaan

Kebutuhan Fungsional SKPL-FXX : Menunjukkan kebutuhan fungsional ke-

Kebutuhan Non SKPL-NFXX : Menunjukkan kebutuhan non

1.6 Ikhtisar Dokumen

2. Deskripsi Umum Perangkat Lunak

2.1 Deskripsi Umum Sistem

2.2 Fungsi Produk

 (SKPL-F1) Halaman Login pengguna (user)

2.3 Karakteristik Pengguna

Kategori Tugas Hak Akses ke Kemampuan yang

Admin  Mengechek  Mengelola data  Menguasai

data laporan keuangan yang

Mekanik  Memperbaiki  Menerima  Berpengala

User  Melaporkan  Membuat data  jujur

2.5 Lingungan Operasi

3. Deskripsi Umum Kebutuhan

3.1 Kebutuhan antarmuka eksternal

3.1.1 Antarmuka pengguna

3.1.2 Antarmuka perangkat keras

3.1.3 Antarmuka perangkat lunak

3.1.4 Antarmuka komunikasi

3.2 Deskripsi Fungsional

3.2.1 Use Case Diagram

Gambar 1 Use Case Diagram

3.2.2 Fungsi 1 : Daftar atau Login Pengguna

3.2.2.1 Skenario Fungsi 1: Daftar atau Login Pengguna

Kode Use UC-001

6 Pengguna langsung mengarah ke

3.2.2.3 Diagram Squensial : Daftar atau Login Pengguna

3.2.2.4 Diagram Kolaborasi: Daftar atau Login Pengguna

3.2.3 Fungsi 2 : Log in Mekanik

3.2.3.1 Skenario Fungsi 2: Log in Mekanik

ang sudah terdafar sebagai pegawai akan masuk menggunakan id

3.2.3.2 Diagram Activitas: Login Mekanik

3.2.3.3 Diagram Squensial: Login Mekanik

Kolaborasi: Login Mekanik

3.2.4 Fungsi 3 : Login Admin

3.2.4.1 Skenario: Login Admin

Kode Use UC-003

5 Admin masuk menggunakan id

4. Memasukkan username dan password

Squensial: Login Admin

3.2.4.4 Diagram Kolaborasi: Login Mekanik

Fungsi 4: Melaporkan Masalah Pelanggan

3.2.5.1 Skenario: Melaporkan Masalah Pelanggan

Kode Use UC-004

3.2.5.2 Diagram Aktifitas: Melaporkan Masalah Pelanggan

3.2.5.3 Diagram Squensial: Melaporkan Masalah Pelanggan

3.2.5.4 Diagram Kolaborasi: Melaporkan Masalah Pelanggan

3.2.6.1 Skenario: Validasi Data

Kode Use UC-005

mekanik ke lokasi penguuna

3.2.6.2 Diagram Aktivitas: Validasi Data

3.2.6.3 Diagram Squensial: Validasi Data

3.2.6.4 Diagram Kolaborasi: Validasi Data

3.2.7 Fungsi 6 : Mekanik Menerima Orderan

3.2.7.1 Skenario : Mekanik Menerima Orderan