SKPL Kel3

TI-UMI-UP-DOC-2022
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

RESTO
Versi: <Draft-tgl/Final>
untuk:
Universitas Methodist Indonesia
Dipersiapkan oleh:
WINDA AGUSTINA SEMBIRING 220510090
ANASTASIA RUMAPEA 220510081
RATMOS M TAMPUBOLON 220511***
NANDO SAROHA 220511***
WILBERT HALAWA 2205100**
JOSEP PILIP PANJAITAN 2205100**
BERRY PURBA 2205100**
Jurusan Teknik Informatika – Universitas Methodist Indonesia

Jl. Hang Tuah No 8, Medan
Program Studi Halaman
Teknik Nomor Dokumen
Informatika UMI
PP TI- UMI-UP-DOC-2021 1/40
Revisi 0 Tgl: 12 Juli 2022
DAFTAR PERUBAHAN
Revisi Deskripsi
A
B
C
D
E
F
G
INDEX - A B C D E F G
TGL
Ditulis
Oleh
Diperiksa
Oleh
Disetujui
Oleh
Jurusan Teknik Informatika UMI SKPL Halaman 2 dari 30

Dokumen ini dan informasi yang dimilikinya adalah milik Jurusan Teknik Informatika UMI dan
bersifat rahasia. Dilarang untuk me-reproduksi dokumen ini tanpa diketahui oleh Jurusan Teknik
Informatika UMI
Daftar Halaman Perubahan
Halaman Revisi Halaman Revisi

Informatika UMI
Daftar Isi
1 Pendahuluan 6
1.1 Tujuan Penulisan Dokumen 6
1.2 Lingkup Masalah 6
1.3 Aturan Penomoran 6
1.4 Referensi 6
1.5 Deskripsi Umum Dokumen (Ikhtisar) 6
2 Kebutuhan Perangkat Lunak 7
2.1 Deskripsi Umum Sistem 7
2.2 Fitur Utama Perangkat Lunak 7
2.2.1 Kebutuhan Fungsional 7
2.2.2 Kebutuhan Non Fungsional 7
2.3 Model Use Case 7
2.3.1 Diagram Use Case 7
2.3.2 Definisi Actor 7
2.3.3 Definisi Use Case 8
2.3.4 Skenario Use Case 8
2.4 Spesifikasi Tambahan 8
2.5 Glossary 8
3 Model Analisis 9
3.1 Realisasi Use Case Tahap Analisis 9
3.2 Diagram Kelas Keseluruhan 9
3.3 Kelas Analisis 9
3.4 Paket Analisis 9

Informatika UMI
3.4.1 Identifikasi Paket Analisis 9
3.4.2 Identifikasi Kelas Analisis tiap Paket 10
3.5 Deskripsi Arsitektur 10
3.6 Pedoman Perancangan 10
4 Model Perancangan 11
4.1 Realisasi Use Case Tahap Perancangan 11
4.1.1 Use Case <nama use case > 11
4.1.1.1 Identifikasi Elemen WAE - Logical View 11
4.1.1.2 Identifikasi Kelas Perancangan 11
4.1.1.3 Sequence Diagram 11
4.1.1.4 Diagram Kelas Perancangan 11
4.1.2 Use Case <nama use case 2> 11
4.1.3 Use Case <nama use case 3> 12
4.2 Perancangan Detil Elemen Logical View 13
4.2.1 Stereotyped Class <nama elemen logical view> 13
4.2.2 Stereotyped Class <nama elemen logical view> 14
4.3 Perancangan Detil Kelas 14
4.3.1 Kelas <nama kelas> 14

Informatika UMI
4.3.2 Kelas <nama kelas> 15
4.4 Diagram Kelas Keseluruhan 15
4.5 Algoritma/Query 15
4.6 Diagram Statechart 15
4.7 Perancangan Antarmuka 16
4.8 Perancangan Representasi Persistensi Kelas 16
4.9 Coding Standard dan Naming Convention 16
4.10 Deployment Diagram 16
5 Implementasi 17
5.1 Lingkungan Implementasi 17
5.2 Implementasi Kelas 17
5.3 Implementasi Elemen WAE (Component View) 17
5.4 Implementasi Antarmuka 17
5.5 File Lain 17
6 Pengujian 18
6.1 Rencana dan Prosedur Pengujian 18
6.1.1 Rencana Pengujian 18
6.1.2 Prosedur Pengujian 18
6.2 Kasus Uji 18
6.2.1 Pengujian Use Case <nama use case> 18
6.3 Defect dan Status Perbaikan 18
6.4 Evaluasi Pengujian 18
7 Lampiran 19

Informatika UMI
Pendahuluan
1.1 Tujuan Penulisan Dokumen
Tujuan dari pembuatan SKPL adalah untuk memudahkan user maupun admin dalam
memesan makanan ataupun minuman dengan via online melalui web, jadi tidak perlu
waiters mondar-mandir.
Aplikasi dilengkapi dengan menu login admin, menu katalog, fitur daftar pesanan menu
dan banyak lainnya seperti daftar transaksi dan print pembayaran dengan menggunakan
pemrograman PHP database MYSQL dengan bantuan Framework.
SKPL ini dibuat untuk memenuhi persyaratan kelulusan dan penilaian Kuliah Rekayasa
Perangkat Lunak serta guna meningkatkan kemampuan mahasiswa dalam merancang
suatu perangkat lunak.
1.2 Lingkup Masalah

Membangun Perangkat lunak Resto guna mempermudah proses pemesanan dan transaksi
karena jika secara manual akan ada konsumen yang lama mendapat pelayanan akibat
ramainya pengunjung serta harus antri untuk melakukan transaksi. Dan tak lepas dari
kesalahan pada resto, sering terjadi kesalahan pemesanan akibat miskomunikasi,
kesalahan penulisan atau tidak terbaca, salah nomor meja dan lain sebagainya.
Kecuranganpun dapat terjadi dengan memanipulasi data pengeluaran dan pemasukan,
begitupun jikalau terjadi perubahan menu dan harga.
oleh sebab itulah kelompok kami membangun Aplikasi berbasis web dengan
pemrograman PHP database MYSQL dengan bantuan Framework agar design web resto
yang kita miliki menarik dan konsumen juga puas dengan step by step sederhana pada
web resto ini serta tak perlu mengantri untuk pemesanan maupun transaksi dan
meminimaliskan manipulasi data.
1.3 Aturan Penomoran

Bagian ini diisi dengan aturan penomoran yang digunakan dalam dokumen.

Informatika UMI
1.4 Referensi
1. Diagram ERD (https://www.slideshare.net/RistaMeytasari/diagram-erd-restaurant)
2. Desain (https://netwareio.blogspot.com/2021/01/desain-topik-integrasi-e-
commerce.html)
3. Desain Sistem (https://library.stmikgici.ac.id/tugas_akhir/21000556.pdf)
4. Use Case Diagram (https://www.researchgate.net/figure/Use-Case-Diagram-for-
the-Restaurant-Ordering-System_fig3_323230406)
5. Pertemuan 9 Desain Arsitektur
(https://classroom.google.com/u/0/c/NDgyNTA1NTEyNjY3/m/NDk1MjAwNzAxODE5/
details)
6. Coding (https://www.w3schools.com/), (https://www.colorhexa.com/3085d6),
(https://stokcoding.com/),
(https://www.w3schools.com/bootstrap/bootstrap_ver.asp)
7. Laravel Restaurant (https://github.com/G4brym/Laravel-Restaurant-POS)
8. Jurnal Sistem dan Teknologi Informasi
(https://jurnal.untan.ac.id/index.php/justin/article/view/16444)
9. Black Box and White Box (https://www.neliti.com/publications/293464/sistem-
manajemen-cafe-dan-resto-berbasis-web-dengan-framework-codeigniter-dan-my) ,
(https://docplayer.info/71107070-Rancang-bangun-aplikasi-pemesanan-menu-di-restoran-
berbasis-web.html).
1.5 Deskripsi Umum Dokumen (Ikhtisar)

Makalah ini terdiri dari 6 Bab. Antara satu bab dengan bab lain merupakan satu kesatuan
rangkaian pembahasan yang utuh.
Bab 1 membahas tentang makalah ini sacara menyeluruh. Beberapa informasi
dalam bab 1 ini akan membuat pembaca mengerti tujuan dari penulisan makalah ini.
Bab 2 membicarakan tentang kebutuhan perangkat lunak yang mencakup deskripsi
umum sistem, Fitur utama dari perangkat lunak yang dibangun baik fungsional maupun
non-fungsional, Model Use Case, Spesifikasi Tambahan dan Glossary.

Informatika UMI
Bab 3 menjelaskan tentang Model Analisis. Materi yang dibahas meliputi
Realisasi Use Case tahap analisis, Diagram Kelas Keseluruhan, Kelas analisis, Paket
analissi (Identifikasi paket analisis dan identifikasi kelas analisis tiap paket), Deskripsi
arsitektur dan Pedoman Perancangan.
Bab 4 tentang Model Perancangan yang diawalli realisasi Use Case tahap
perancangan ( use case admin, use case kasir, use case pembeli ), Perancangan detail
elemen logical view dan perancangan detail kelas.
Bab 5 membahas implementasi perangkat lunak resto yang mencakup lingkungan,
kelas, elemen WAE, implementasi antar muka dan file lain.
Bab 6 mendiskusikan tentang pengujian mulai dari rencana dan prosedur, kasus
uji, defect dan status perbaikan serta pengujian.

Informatika UMI
Kebutuhan Perangkat Lunak
2.1 Deskripsi Umum Sistem
Sistem Pemesanan Makanan Resto berbasis web merupakan sistem yang dapat
mendukung kegiatan/pekerjaan di sebuah resto, dimana sistem dapat menerima pesanan
dari pembeli dalam bentuk digital sehingga tidak perlu repot mengantri dan menghindari
kesalahan penulisan serta meminimaiskan manipulasi data transaksi.
Ketika mengadakan promo resto tak perlu ribet cetak ulang menu resto, karena dengan
berbasis web kita bisa meng-update menu dan harga.
Pembeli pun dapat memesan dari meja yang mereka pilih tanpa harus mengantri atau
menunggu waiters membawa menu resto. Pemesanan yang dilakukan pun mudah, ketika
kita masuk ke laman web , akan tampil home dengan 3 kategori makanan yaitu snack,
food and drink. Pembeli tinggal memilih pesanan dan akan mendapatkan pesnan sukses
order menu berhasil lalu click cart order. Di cart order kita akan jumpai 3 tahap.
2.2 Fitur Utama Perangkat Lunak

Bagian ini diisi dengan fitur utama perangkat lunak, yang terdiri dari kebutuhan
fungsional dan kebutuhan non fungsional. Deskripsi fitur harus dinyatakan dengan jelas
dalam kalimat yang lengkap (jelas subyek, predikat, dan objek-nya). Setiap fitur diberi
kode dengan aturan penomoran yang telah dijelaskan sebelumnya.
2.2.1 Kebutuhan Fungsional
Contoh:
SRS-F-001 Sistem menyediakan fasilitas bagi pengguna untuk memilih tema tampilan.
2.2.2 Kebutuhan Non Fungsional

Contoh:
SRS-NF-001 Sistem memberikan respon terhadap aksi pengguna dalam waktu kurang
dari 5 detik.

Informatika UMI
2.3 Model Use Case
2.3.1 Diagram Use Case

Informatika UMI
2.3.2 Definisi Actor
Bagian ini diisi dengan daftar actor dan deskripsi role untuk actor tersebut. Deskripsi role
harus menjelaskan wewenang pada role tersebut dalam perangkat lunak. Bisa dibuat
dalam bentuk tabel berikut:
NO. ACTOR DESCRIPTIVE
1. Admin 1. Melaksanakan tugas administrasi sistem informasisesuai
denga arahan divisi sistem informasi.
2. Membantu divisi sistem informasi membuat laporan secara
periodik.
2. Kasir 1. Pencatatan transaksi Penjualan dan retur penjualan toko, dan
mencetak struk / faktur penjualan.
2. Pencatatan transaksi pelanggan.
3. Pembeli 1. Melakukan pemesanan.
2. Melakukan update pada pemesanan.
2.3.3 Definisi Use Case

Bagian ini diisi dengan daftar use case dan deskripsi singkat mengenai use case tersebut.
Bisa dibuat dalam bentuk tabel berikut:
NO. USE CASE DESCRIPTIVE
1. Admin Melakukan login dan mengkonfirmasi pesanan pebeli.
2. Kasir Melakukan login dan pencetakan faktur serta melakukan
konfirmasi untuk pemesanan.
3. Pembeli Melakukan pemesanan pada menu yang tertera.
2.3.4 Skenario Use Case

Bagian ini diisi dengan skenario (flow of event) untuk beberapa use case utama, yang
menggambarkan urutan interaksi actor dengan use case tersebut, dari awal sampai akhir.
Contoh:
Nama Use Case: Melihat daftar produk
Skenario:
AKSI PEMBELI REAKSI SISTEM
Skenario Normal
1. Tampilan Home
2. Menampilkan tampilan dari web resto.

Informatika UMI
3. Menampilkan menu yang ada pada resto.
4. Melihat menu.
5. Memilih menu(Melakukan Pemesanan)
6. Konfirmasi Pesanan
AKSI ADMIN REAKSI SISTEM

Skenario Normal
1. Login Admin
2. Menampilkan form login dari web resto.
3. Memferifikasi login admin.
4. Menampilkan dasbord admin.
5. Melihat menu transaksi.
6. Menampilkan menu transakasi.
AKSI KASIR REAKSI SISTEM

Skenario Normal
1. Login kasir
2. Menampilkan form login dari web resto.
3. Memferifikasi login kasir.
4. Menampilkan dasbord kasir.
5. Memferifikasi pesanan pembeli.
6. Menampilkan notifikasi “order ini akan di
konfirmasi” serta buton “yes” dan “batal”.
7. Mengkik “yes”
8. Menampilkan form order yang dikonfirmasi
9. Melakukan cetak nota
10. Melakukan cetak nota.
2.4 Spesifikasi Tambahan

Bagian ini diisi dengan informasi tambahan mengenai setiap atau seluruh use case utama,
terutama mengenai kebutuhan non fungsional.
1. Admin dapat melakuakan cetak nota,mengkonfirmasi pesanan pembeli serta
mengupdate menu yang ada pada WEB RESTO.
2. Pembeli dapat mengupdate pesanan.

Informatika UMI
2.5 Glossary
Monitoring  proses rutin pengumpulan data dan pemgukuran kemajuan atas objektif
program, memantau perubahan yang fokus pada proses dan keluaran.
Dashboard  aplikasi atau bagian sistem informasi yang menjajikan informasi mengenai
indikator utama dari aktifitas organisasi secara sekilas dalam layar tunggal.
Additional  tambahan sitem yang ada pada WEB RESTO seperti sosial media.

Informatika UMI
Model Analisis
3.1 Realisasi Use Case Tahap Analisis
Bagian ini dibuat subbab per use case. Setiap subbab diisi dengan diagram kelas analisis
dan sequence diagram yang menggambarkan interaksi setiap objek dari kelas analisis
yang terlibat di dalam use case tersebut. Lengkapi dengan kalimat pengantar (jangan
hanya diisi diagram saja).
3.2 Diagram Kelas Keseluruhan

Pada fase ini, bagian ini diisi dengan diagram kelas keseluruhan. Lengkapi dengan
kalimat pengantar.
3.3 Kelas Analisis

Bagian ini diisi dengan daftar seluruh kelas kelas analisis dalam tabel berikut:
No. Nama Kelas Jenis
Untuk setiap kelas analisis, lakukan (dengan melengkapi subbab-subbab berikutnya):

 identifikasi tanggung-jawab (responsibility)
 identifikasi atribut
Nama Kelas Daftar Tanggung-Jawab Daftar Atribut
Kelas xxxx 1. 1.
2. 2.
3. 3.

Informatika UMI
3.4 Paket Analisis
3.4.1 Identifikasi Paket Analisis
Jika perlu, pemaketan dapat dilakukan untuk menyederhanakan persoalan. Bagian ini
dapat diisi dengan daftar paket analisis dengan mengacu pada diagram use case. Satu atau
lebih use case dapat digabung kedalam satu paket. Satu use case hanya boleh berada pada
satu paket.
Contoh :
No. Nama Paket Use Case Terkait
1. Paket Pengelolaan Informasi 1. Pengelolaan Informasi Pelanggan
2. Pengelolaan Informasi Pegawai
3. Pengelolaan Informasi Produk
Gambarkan pula diagram package, serta berikan uraian singkat mengenai diagram
tersebut. Diagram package menggambarkan ketergantungan antar package. Lengkapi
daftar perubahan jika terjadi perubahan.
3.4.2 Identifikasi Kelas Analisis tiap Paket

Bagian ini diisi dengan hasil identifikasi kelas analisis untuk setiap paket analisis dengan
mengacu pada skenario setiap use case. Sebuah kelas seharusnya tidak muncul di lebih
dari satu paket. Jika sebuah kelas terlibat di dua use case yang berbeda paket, alokasikan
kelas di salah satu paket. Hal ini akan menggambarkan ketergantungan antar paket.
Contoh :
No. Nama Paket Nama Kelas Analisis Jenis Kelas
(Boundary, Control, Entity)
1. Paket xxx 1.
2.
3.
3.5 Deskripsi Arsitektur

Bagian ini diisi dengan gambaran umum arsitektur perangkat lunak, mis. arsitektur client-
server atau arsitektur aplikasi berbasis web.

Informatika UMI
3.6 Pedoman Perancangan
Bagian ini diisi dengan uraian mengenai framework atau arsitektur khusus yang
digunakan pada saat perancangan dan implementasi. Jika tidak ada, hilangkan subbab ini

Informatika UMI
Model Perancangan
4.1 Realisasi Use Case Tahap Perancangan
4.1.1 Use Case <nama use case 1>
Jika use case ini akan direalisasikan dalam bentuk aplikasi berbasis web, maka subbab
yang terkait dengan perancangan elemen aplikasi berbasis web harus diisi.
4.1.1.1 Identifikasi Elemen WAE - Logical View

Bagian ini diisi dengan hasil identifikasi elemen WAE-Logical View yang merealisasikan
use case:
- server page
- client page
- html form
No. Nama Elemen Lojik WAE Stereotype

Server Page
Server Page
Client Page
4.1.1.2 Identifikasi Kelas Perancangan

Buat daftar kelas analisis yang merealisasikan use case dalam tabel berikut:
No. Nama Kelas Perancangan Nama Kelas Analisis Terkait
4.1.1.3 Sequence Diagram

Buatlah diagram sequence untuksetiap skenario use case.

Informatika UMI
4.1.1.4 Diagram Kelas Perancangan
Buatlah diagram kelas perancangan lengkap dengan Elemen WAE-Logical View (jika
berbasis web).


use case:
- server page
- client page
- html form

Server Page
Server Page
Client Page



Informatika UMI
berbasis web).


use
case:
- server page
- client page
- html form

Server Page
Server Page
Client Page



Informatika UMI
berbasis web).
4.2 Perancangan Detil Elemen Logical View

Server Page
Server Page
Client Page
Untuk setiap elemen:

 identifikasi atribut
 identifikasi operasi
4.2.1 Stereotyped Class <nama elemen logical view>

Nama Kelas : ……..
Jenis : Server Page / Client Page / HTML Form
Nama Operasi Visibility Keterangan
(private, public)
Diisi dengan signature operasi
Nama Atribut Visibility Tipe

(private, public)
Diisi dengan nama atribut Tuliskan tipenya sesuai dengan
yang dikenal pada bahasa
pemrograman yang digunakan

Informatika UMI
4.2.2 Stereotyped Class <nama elemen logical view>
Jenis : Server Page / Client Page / HTML Form
(private, public)

(private, public)
4.3 Perancangan Detil Kelas

Bagian ini diisi dengan daftar kelas perancangan dalam tabel berikut:
Untuk setiap kelas:

 identifikasi operasi (mengacu pada tanggung-jawab kelas), termasuk visibility-nya
 identifikasi atribut, termasuk visibility-nya
4.3.1 Kelas <nama kelas>

Bagian ini diisi dengan daftar operasi dan atribut Buat untuk setiap kelas.
(private, public)

Informatika UMI
(private, public)
4.3.2 Kelas <nama kelas>

Bagian ini diisi dengan daftar operasi dan atribut Buat untuk setiap kelas.
(private, public)

(private, public)
4.4 Diagram Kelas Keseluruhan

Bagian ini diisi dengan diagram kelas keseluruhan.
4.5 Algoritma/Query
Bagian ini hanya diisi untuk kerangka algoritma untuk proses-proses yang dianggap
cukup penting. Implementasi skeleton code juga sudah dapat dilakukan untuk kelas-kelas
yang terdefinisi pada bahasa pemrograman tertentu. Boleh dibuat subbab per kelas.
Contoh:
Nama Kelas :
Nama Operasi :
Algoritma : (Algo-xxx)

Informatika UMI
{Jika mengacu query tertentu, lengkapi tabel query di bawah}
Query
No Query Query Keterangan
Q-xxx Tuliskan fungsi dari querynya
4.6 Diagram Statechart

Bagian ini hanya diisi jika ada kelas yang kompleks. Perubahan status kelas tersebut harus
digambarkan dalam bentuk diagram statechart. Boleh dibuat subba per kelas.
4.7 Perancangan Antarmuka

Pada fase Inception:
Bagian ini diisi dengan versi awal prototipe antarmuka.
Pada fase Elaboration:
Bagian ini diisi dengan perbaikan rancangan antarmuka. Lengkapi daftar perubahan jika
terjadi perbaikan. Selanjutnya, untuk setiap antarmuka/layar, tuliskan spesifikasi detilnya,
misalnya seperti di bawah ini:
Antarmuka : {diisi dengan no. layar atau no gambar rancangan antarmuka}
Id_Objek Jenis Nama Keterangan
Diisi dengan string yg Diisi dengan penjelasan reaksi sistem, misalnya
tampil pd layar membuka layar apa, link kemana. Jika
menyangkut suatu kode yang cukup rumit, acu
algoritma yang telah diuraikan di atas.
Button1 Button OK Jika diklik, akan mengaktifkan Proses
AlgoXXX.
RTF1 RTF Box Isi Teks yang disimpan pada File xxx

Informatika UMI
Jika objek dikaitkan ke File lain (misalnya file gambar, file teks), berikan nama file terkait
dan deskripsi ringkas dalam kolom keterangan.
Pada fase Construction:
Bagian ini diisi dengan versi final dari rancangan antarmuka. Lengkapi daftar perubahan
jika terjadi perbaikan.
4.8 Perancangan Representasi Persistensi Kelas

Bagian ini diisi dengan rancangan skema basisdata dan traceability-nya terhadap kelas
entity.
4.9 Coding Standard dan Naming Convention
Pada fase Inception:
Bagian ini belum diisi.
Pada fase Elaboration:
Bagian ini diisi dengan coding standard dan naming convention yang akan digunakan.
Pada fase Construction:
Bagian ini diisi dengan versi final dari coding standard dan naming convention. Lengkapi
daftar perubahan jika terjadi perbaikan.
4.10 Deployment Diagram

Bagian ini diisi dengan deployment diagram yang menggambarkan alokasi proses pada
node.
5 Implementasi
analisa dan perancangan menjelaskan perancangan sistem yang akan dibangun. Setelah dirancang
maka dilakukan coding untuk menerapkan code-code kedalam sistem yang akan dibangun.
Selanjutnya dilakukan implementasi dan pengujian pada sistem yang dibangun. Tahapan
implementasi merupakan tahapan dimana sistem informasi yang telah dirancang, dianalisa, dan
dibangun, lalu diuji kelayakannya untuk selanjutnya dioperasikan sebagaimana mestinya sesuai

Informatika UMI
dengan fungsi dan kelayakannya. Berikut ini akan dijelaskan tentang pengimplementasian dari
analisis dan perancangan yang telah dilakukan terhadap aplikasi resto
5.2 Implementasi Kelas
No. Nama Kelas Nama File Fisik Nama File Executable

1. Acoount menu aplikasi web Java class
5.3 Implementasi Elemen WAE (Component View)

Berikut dijelaskan elemen implementasi aplikasi resto:
a. Aplikasi berada pada server utama yang terhubung dengan WIFI.
b. Terdapat beberapa akun, untuk menggunakan aplikasi resto.
Yaitu : klien, Admin, kasir dan kitchen (dapur) .
 Penyajian informasi mengenai menu makanan dari restoran, berupa nama makanan, deskripsi,
harga, dan gambar.
 Aplikasi mengunakan sistem Passkey. V-2
 Pelanggan dapat membatalkan pesanan jika belum dimasak
 Terdapat sebuah catatan pemesanan pada aplikasi client
 Pemesanan memiliki batas waktu.
c. Aplikasi untuk administrator hanya dapat diakses melalui web. Secara umum aplikasi ini
memiliki fitur-fitur sebagai berikut.
 Administrator dapat menginput data makanan dan minuman, harga .
 Mengelola kategori menu
 Mengelola artikel yang ditampilkan pada aplikasi Client.
 Mengelola outlet yang ditampilkan pada aplikasi Client
 Mengelola interface header dan footer Restoran.
 Melihat report penjualan Per-hari

Informatika UMI
d. Untuk akun resepsionis digunakan oleh resepsionis sendiri, berikut fitur yang bisa digunakan.
 Generate Passkey
 Mencetak Passkey
 Validasi pembayaran tagihan
 Cetak struk.
 Monitor Pemesanan.
5.4 Implementasi Antarmuka

Bagian ini diisi dengan daftar implementasi antarmuka. Misalnya dalam bentuk tabel
berikut:
No. Nama Kelas Nama File Fisik Nama File Executable
Login web
Admin
kasir
5.5 File Lain

Bagian ini diisi dengan file-file lain yang dibuat, selain file kelas dan antarmuka, misalnya
file utility yang digunakan.
No. Nama File Keterangan
1 Informasi resto
Informatika UMI
6 Pengujian
6.1 Rencana dan Prosedur Pengujian
6.1.1 Rencana Pengujian
Bagian ini diisi dengan rencana pengujian, misalnya dalam bentuk tabel berikut:
No. Use Case Pengujian Jenis Pengujian Identifikasi
1. xxx 1. Skenario normal 1. Black box dan White U-1-xxx
2. Skenario xxx (acu Box U-1-xxx
no.skenario) 2. Black Box U-1-xxx
3. Skenario yyy 3.
U-2-xxx

Informatika UMI
6.1.2 Prosedur Pengujian
Bagian ini diisi dengan prosedur pengujian, misalnya persiapan pengujian, urutan
pengujian yang harus dilakukan, dll. Bagian ini diisi dengan prosedur pengujian versi
final. Lengkapi daftar perubahan.
6.2 Kasus Uji
Bagian ini diisi dengan kasus uji untuk setiap use case (dibuat subbab untuk setiap use
case).
Contohnya adalah sebagai berikut:
6.2.1 Pengujian Use Case <nama use case>
Identifikasi Deskripsi Prosedur Masukan Keluaran Kriteria Hasil Kesimpulan
Pengujian yang Evaluasi yang
Diharapkan Hasil Didapat
U-1-01 Pengujian o Buka File data Kode 01<tgl_lahir> 01<tgl_ 01<tgl_ Ditolak
hasil pelanggan modus 001 Lahir> Lahir><n
pemasuka o Cari rekord pemasuka 01<tgl_lahir> <nomor o_
n dengan data n 002 Terurut> loncat
data modus operator 01<tgl_lahir>
pelanggan pemasukan (01) 003
oleh yang diinginkan dst
operator o Lihat tanggal
U-1-02 Pengujian lahir pelanggan Kode 02<tgl_lahir> 02<tgl_ 02<tgl_ Diterima
hasil o Lihat kode modus 001 Lahir> Lahir><n
pemasuka pelanggan pemasuka 02<tgl_lahir> <nomor o_
n o Bandingkan n 002 Terurut> Terurut>
data dengan rumus on-line 02<tgl_lahir>
pelanggan pembangkitan (02) 003
oleh kode pelanggan dst
pelanggan
secara on-
line
6.3 Defect dan Status Perbaikan

Bagian ini diisi dengan defect yang ditemukan setelah melakukan pengujian dan status
perbaikannya

Informatika UMI
6.4 Evaluasi Pengujian
Bagian ini diisi dengan uraian evaluasi hasil pengujian.
Lampiran
Bagian lampiran diisi dengan
- pembagian tugas,
- rencana iterasi,
- notulen koordinasi
- user manual,
- contoh brosur promosi produk perangkat lunak.,
- tabel traceability (contoh lihat halaman berikutnya).
Tracebility Use Case

Informatika UMI
Analisis Perancangan Penguji
SRS-ID Use Skenario Sequence Diagra Sequence Diagram Antar Kasus Uji
Case ID Diagram m Kelas Diagram Kelas Muka
SRS-F-01 UC-01 SC-01-01 SQ-A-01-01 CL-A-01 SQ-D-01-01 CL-D-01 INT-01 U-01
SC-01-02 SQ-A-01-02 SQ-D-01-02 INT-02 U-02
UC-02 SC-02-01 SQ-A-02-01 CL-A-02 SQ-D-02-01 CL-D-02 INT-01 U-03
SC-02-02 SQ-A-02-02 SQ-D-02-02 INT-03 U-04
SC-02-03 SQ-A-02-03 SQ-D-02-03 INT-04 U-05
Catatan: Setiap kolom diisi dengan nomor/ID

Informatika UMI

SKPL Kel3

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 Kel3

Diunggah oleh

Hak Cipta:

Format Tersedia

TI-UMI-UP-DOC-2022

SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

Jurusan Teknik Informatika – Universitas Methodist Indonesia

Jurusan Teknik Informatika UMI SKPL Halaman 2 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 3 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 4 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 5 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 6 dari 30

1.2 Lingkup Masalah

1.3 Aturan Penomoran

Jurusan Teknik Informatika UMI SKPL Halaman 7 dari 30

1.5 Deskripsi Umum Dokumen (Ikhtisar)

Jurusan Teknik Informatika UMI SKPL Halaman 8 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 9 dari 30

2.2 Fitur Utama Perangkat Lunak

2.2.2 Kebutuhan Non Fungsional

Jurusan Teknik Informatika UMI SKPL Halaman 10 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 11 dari 30

2.3.3 Definisi Use Case

2.3.4 Skenario Use Case

Jurusan Teknik Informatika UMI SKPL Halaman 12 dari 30

AKSI ADMIN REAKSI SISTEM

AKSI KASIR REAKSI SISTEM

2.4 Spesifikasi Tambahan

Jurusan Teknik Informatika UMI SKPL Halaman 13 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 14 dari 30

3.2 Diagram Kelas Keseluruhan

3.3 Kelas Analisis

No. Nama Kelas Jenis

Untuk setiap kelas analisis, lakukan (dengan melengkapi subbab-subbab berikutnya):

Jurusan Teknik Informatika UMI SKPL Halaman 15 dari 30

3.4.2 Identifikasi Kelas Analisis tiap Paket

3.5 Deskripsi Arsitektur

Jurusan Teknik Informatika UMI SKPL Halaman 16 dari 30

Jurusan Teknik Informatika UMI SKPL Halaman 17 dari 30

4.1.1.1 Identifikasi Elemen WAE - Logical View

No. Nama Elemen Lojik WAE Stereotype

4.1.1.2 Identifikasi Kelas Perancangan

No. Nama Kelas Perancangan Nama Kelas Analisis Terkait

4.1.1.3 Sequence Diagram

Jurusan Teknik Informatika UMI SKPL Halaman 18 dari 30

4.1.2 Use Case <nama use case 2>

4.1.2.1 Identifikasi Elemen WAE - Logical View

No. Nama Elemen Lojik WAE Stereotype

4.1.2.2 Identifikasi Kelas Perancangan

No. Nama Kelas Perancangan Nama Kelas Analisis Terkait

4.1.2.3 Sequence Diagram

Jurusan Teknik Informatika UMI SKPL Halaman 19 dari 30

4.1.3 Use Case <nama use case 3>

4.1.3.1 Identifikasi Elemen WAE - Logical View

No. Nama Elemen Lojik WAE Stereotype

4.1.3.2 Identifikasi Kelas Perancangan

No. Nama Kelas Perancangan Nama Kelas Analisis Terkait

4.1.3.3 Sequence Diagram

Jurusan Teknik Informatika UMI SKPL Halaman 20 dari 30

4.2 Perancangan Detil Elemen Logical View

No. Nama Elemen Lojik WAE Stereotype

Untuk setiap elemen:

4.2.1 Stereotyped Class <nama elemen logical view>

Nama Atribut Visibility Tipe

Jurusan Teknik Informatika UMI SKPL Halaman 21 dari 30

Nama Atribut Visibility Tipe

4.3 Perancangan Detil Kelas