SKPL-W-xx

SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

<Mathing Time>

untuk:

< Masyarakat umum >

Dipersiapkan oleh:

Mahez Pradana 2015061070

M. Aldi Kurniawan 2015061071

Renata Adisti Pratiwi 2015061025

Ivan Simangunsong 2015061061

Program Studi Teknik Informatika

FT Universitas Lampung
Jl. S. Brojonegoro No. 1 Bandar Lampung

Nomor Dokumen Halaman

Program Studi
Teknik Informatika
FT - UNILA SKPL-W-xx <xx:no grp> <#>/<jml #
Revisi <nomor revisi> Tgl: <isi tanggal>
 Control Revisi Dokumen

Seluruh revisi yang telah dilakukan pada dokumen ini, dapat diikuti sebagaimana tabel berikut.

Nomer Diperiksa
Tanggal Keterangan singkat perbaikan
Revisi oleh

Program Studi Teknik Informatika Unila SKPL-W-xx Halaman 2/ dari 14

halaman
Sistem Penomoran
Ada beberapa hal/bagian dalam dokumen ini yang perlu diberi nomor. Maksud
penomoran ini untuk mempermudah audience dalam pengidentifikasian. Adapun
aturan penomorannya sebagaimana tabel berikut:

Hal/Bagian Aturan Penomoran

Tabel/Data Store Nomor berbentuk TD99, dimana 99 adalah nomor urut tabel atau data store
Contoh: TD11, TD12, TD29, TD31 dan sebagainya
Kebutuhan Fungsional Nomor berbentuk KF999.x, dimana 999 adalah nomor urut struktur butir-
butir pada kebutuhan fungsional. Sedangkan x adalah nomor berupa abjad
dan sifatnya sebagai tambahan jika kebutuhan fungsional tersebut memiliki
item turunannya.
Contoh: KF101, KF120, KF120.a, KF120.b dan sebagainya
Kebutuhan Non Nomor berbentuk KnF99.x, dimana 99 adalah nomor urut struktur butir-butir
Fungsional pada kebutuhan non fungsional. Sedangkan x adalah nomor berupa abjad
dan sifatnya sebagai tambahan jika kebutuhan non fungsional tersebut
memiliki item turunannya.
Contoh: KnF11, KnF12, KnF12.a, KnF12.b dan sebagainya

Referensi
Berikut adalah daftar acuan yang digunakan dalam pendokumentasian
spesifikasi kebutuhan perangkat lunak ini.

 IEEE Std. 1233, 1998 Edition IEEE Guide for Developing System
Requirements Specifications
 IEEE, Software Requirements Engineering, Second Edition, IEEE
Computer Society Press, 2002.
 Bray, Ian K. An Introduction to Requirement Engineering, 1 st
published, Addison-Wesley, 2002
 Kotonya, Gerald and Sommerville, Ian. Requirement Engineering:
Processes and Techniques, John Wiley & Sons Ltd, 1998
 Holil, Achmad. Template: Spesifikasi Kebutuhan Perangkat Lunak,
Jurusan Sistem Informasi ITS, 2006..
 Bourque, Pierre., and Fairley, Richard E. 2014. SWEBOK V3.0 : Guide to the
Software Engineering Body of Knowledge. New Jersey: IEEE

Program Studi Teknik Informatika Unila SKPL-W-xx Halaman 3/ dari 14

halaman
 Daftar Isi

Contents
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK..............................................................................................1
Control Revisi Dokumen................................................................................................................................................2
1. Pendahuluan...................................................................................................................................................5
1.1 Tujuan Penulisan Dokumen...................................................................................................................5
1.2 Lingkup Masalah....................................................................................................................................5
1.3 Definisi, Istilah dan Singkatan...............................................................................................................5
1.4 Aturan Penomoran..................................................................................................................................5
1.5 Referensi.................................................................................................................................................5
1.6 Deskripsi umum Dokumen (Ikhtisar).....................................................................................................6
2 Deskripsi Umum Perangkat Lunak................................................................................................................7
2.1 Deskripsi Umum Sistem.........................................................................................................................7
2.2 Karakteristik Pengguna..........................................................................................................................8
2.3 Batasan...................................................................................................................................................8
2.4 Lingkungan Operasi...............................................................................................................................8
3 Deskripsi Kebutuhan......................................................................................................................................9
3.1.1 Antarmuka pemakai...............................................................................................................................9
3.1.2 Antarmuka Perangkat Keras...................................................................................................................9
3.1.3 Antarmuka Perangkat Lunak..................................................................................................................9
3.1.4 Antarmuka Komunikasi.........................................................................................................................9
3.3.1 Diagram Use Case................................................................................................................................10
3.3.2 Definisi Actor.......................................................................................................................................10
3.3.3 Definisi Use Case.................................................................................................................................11
3.3.4 Skenario Use Case................................................................................................................................11
3.6.1 Kebutuhan Fungsional vs Use Case.....................................................................................................12
3.7.1 Kebutuhan Fungsional..........................................................................................................................13
3.7.2 Kebutuhan Non Fungsional..................................................................................................................13

Setelah Daftar Isi Boleh ada Daftar Tabel dan Daftar Gambar

Program Studi Teknik Informatika Unila SKPL-W-xx Halaman 4/ dari 14

halaman
1. Pendahuluan

1.1 Tujuan Penulisan Dokumen

Tujuan pembuatan dokumen ini adalah untuk menjelaskan mengenai spesifikasi
kebutuhan perangkat lunak yang akan dibuat atau dikembangkan baik berupa gambaran
umum maupun penjelasan secara detail atau menyeluruh.
Dan pada dokumen ini, perangkat lunak yang dibuat adalah aplikasi Game Edukasi.
Kami membuat ini guna meningkatkan pemahaman dan kemampuan kami di bidang
rekayasa perangkat lunak sekaligus ingin membuat game yang tidak hanya membuat
pemain senang namun diharapkan dapat meningkatkan edukasi pemain. Target kami pada
proyek ini cukup luas mulai dari anak-anak, remaja hingga orang dewasa dikarenakan
pertanyaan pertanyaannya bersifat cukup umum sehingga siapa saja memiliki kesempatan
untuk menjawabnya.

1.2 Lingkup Masalah

Aplikasi yang akan kami buat adalah Game Edukasi “Mathing Time”. Game ini dibuat
dengan tujuan sebagai alat pendidikan yang berbentuk kuis, dimana game ini memberikan soal
yang harus dijawab oleh user dan hasil akhirnya merupakan skor yang didapatkan oleh user.
Tidak hanya untuk kesenangan, melalui game ini user juga dapat mengukur tingkat
pemahamannya.

1.3 Definisi, Istilah dan Singkatan

 Admin adalah pemilik yang merupakan seseorang yang bertanggungjawab

untuk perawatan sistem dan serta bertanggungjawab terhadap operasional
sistem.
 User adalah karyawan yang merupakan seseorang yang bertanggungjawab
terhadap pelayanan pemesanan.
 JavaScript adalah bahasa pemrograman tingkat tinggi dan dinamis.
JavaScript populer di internet dan dapat bekerja di sebagian besar penjelajah
web. Kode JavaScript dapat disisipkan dalam halaman web menggunakan tag
script.
 Maintanance adalah kegiatan untuk memelihara atau menjaga suatu sistem
dan mengadakan perbaikan atau penggantian yang diperlukan agar terdapat
suatu keadaan operasi yang memuaskan sesuai dengan apa yang
direncanakan.

1.4 Aturan Penomoran

Tuliskan jika anda memakai aturan penomoran

1.5 Referensi

 IEEE Std 830-1998. 1998. IEEE Recommended Practice for Software

Requirements Specifications. New York: IEEE.
 Sommerville, Ian. 2011. Software Engineering (Nineth Edition). Boston:
Pearson.
 Bourque, Pierre., and Fairley, Richard E. 2014. SWEBOK V3.0 : Guide to the
Software Engineering Body of Knowledge. New Jersey: IEEE.
1.6 Deskripsi umum Dokumen (Ikhtisar)

Dokumen SKPL ini dibagi menjadi tiga bagian utama, yaitu :

1. Pendahuluan yang berisi penjelasan tentang dokumen SKPL yang mencakup
tujuan pembuatan dokuman, ruang lingkup masalah yang diselesaikan oleh
perangkat lunak yang dikembangkan, definisi, referensi, dan sistematika.
2. Deskripsi umum yang berisi penjelasan secara umum mengenai perangkat
lunak yang akan dikembangkan meliputi perspektif dari perangkat lunak,
fungsi dari perangkat lunak, karakteristik pengguna, batasan, dan asumsi
yang diambil dalam pengembangan perangkat lunak.
3. Rincian kebutuhan yang berisi uraian kebutuhan perangkat lunak secara lebih
rinci.
 2 Deskripsi Umum Perangkat Lunak

2.1 Deskripsi Umum Sistem

Mathing Time adalah sebuah aplikasi kuis matematika yang berbasis mobile yang dapat berjalan pada
platform Android. Dalam aplikasi ini pengguna akan mengerjakan beberapa soal dengan cara
memilih jawaban yang tersedia, kemudian dijawab dalam waktu yang sudah ditentukan.
Menyelesaikan setiap soal akan mendapatkan poin, apabila pengguna mendapat kesulitan saat
menyelesaikan soalnya maka pengguna dapat menggunakan poin tersebut untuk mendapatkan
petunjuk penyelesaian ataupun jawaban.

Dalam menu utama aplikasi ini terdapat level – level yang dapat dipilih oleh pengguna untuk mainkan.
Level -level tersebut akan memiliki tingkat kesulitan yang berbeda, dari segi soal maupun waktu
pengerjaannya. Setiap level yang diselesaikan akan menampilkan total poin yang diperoleh dan akan
membuka level baru. Seluruh poin pada setiap level akan diakumulasikan sebagai total poin dan
highscore.

Aplikasi ini dapat dimainkan secara langsung. Dan untuk menghindari kehilangan data, aplikasi ini
menyediakan fitur mentautkan akun google sebagai penyimpanan awan dan penyimpanan lokal
secara offline agar pengguna dapat melanjutkan permainan terakhir. Aplikasi ini menyimpan data
save setiap level yang diselesaikan.

Aplikasi ini menggunakan unity sebagai alat pengembang dan menggunakan Javascript sebagai bahasa
pemrograman. Dan juga aplikasi ini akan dilengkapi dengan BGM agar pengguna lebih menikmati
permainan.

Gambar.1 arsitektur perangkat lunak

 2.2 Karakteristik Pengguna
Karakteristik pengguna Mathing Time :

Kategori Pengguna Tugas Hak Akses ke aplikasi

Client Memainkan game Melihat dan memainkan secara
penuh.

Tester Memainkan dan mencari bug Melihat dan memainkan secara

penuh.

pengembang Memperbaiki bug, maintenance, Mengelola (melihat, menambah,

update menghapus, mengubah)

2.3 Batasan
Batasan-batasan dalam pembangunan aplikasi game Mathing Time tersebut, yaitu:
1. Ukuran game tidak lebih dari 100mb
2. Game harus dapat dimainkan diberbagai versi os android
3. Loading menu tidak boleh lebih dari 30 detik
4. Game dapat menyimpan data offline maupun online

2.4 Lingkungan Operasi

Perangkat lunak pada sisi server yang dibutuhkan oleh Mathing Time adalah:
 OS: Microsoft Windows 7/8/10
 Scripting language: javascript
 Engine tool: unity
 DBMS: google
3 Deskripsi Kebutuhan
3.1 Kebutuhan Antarmuka Eksternal

3.1.1 Antarmuka pemakai

Pengguna Aplikasi Mathing Time berinteraksi langsung dengan sistem melalui antarmuka yang
ditampilkan dalam bentuk layout-layout yang akan dibuat semenarik mungkin. Pada menu awal
terdapat pilihan “main”, “petunjuk”, dan “pengaturan”, apabila pengguna sudah pernah memainkan
maka akan muncul “main ulang” dan “lanjutkan”. Pada pengaturan berisikan pengaturan tentang
suara dan vibrasi. Pada petunjuk akan berisi tentang tata cara pengerjaan dan menggunakan aplikasi
ini.

Setelah menekan tombol “main” maka muncul level-level yang dapat dipilih, setelah memilih level
maka akan muncul soal-soal yang harus dijawab dengan menekan pilihan yang ada dan terdapat
keterangan waktu yang berjalan. Di dalam layout pengerjaan soal terdapat ikon “pause” untuk
menghentikan waktu yang berjalan sementara dan ikon “?” untuk mendapatkan bantuan dan
penunjuk level yang dikerjakan serta nomor soalnya. Setelah level selesai akan ditampilkan total
skor yang didapat dan terdapat pilihan “lanjut” untuk melanjut ke level berikutnya, “berhenti” untuk
kembali ke menu utama.

3.1.2 Antarmuka Perangkat Keras

Kebutuhan minimum perangkat keras yang dapat digunakan oleh

Mathing Time adalah: Smartphone berbasis Android 3.0.

3.1.3 Antarmuka Perangkat Lunak

Library yang dibutuhkan oleh Aplikasi Matching Time adalah JDBC (Java Data Base
Connectivity) untuk melakukan koneksi basis data dari Java ke basis data My SQL. JDBC
bertugas menyediakan koneksi ke database, sehingga kita bisa mengakses dan mengelola
datanya dari program Java .

3.1.4 Antarmuka Komunikasi

Aplikasi menggunakan Outlet data ( Modular, face plate & outbow ) Diberi label agar
memudahkan untuk maintenance dikemudian hari. Dan menggunakan e-mail sebagai
komunikasi dua arah.
3.2 Kebutuhan Fungsional

ID Kebutuhan Penjelasan
1 Pengguna bisa memilih tingkatan Lv sesuai kemampuan Tinggi
yang dimiliki
2 Sistem dapat menampilkan menu utama Tinggi

Sistem dapat menampilkan petunjuk penggunaan aplikasi Sedang

3
Sistem dapat menampilkan jawaban yang benar bila jawaban Tinggi
4 soal salah

Sistem dapat menampilkan highscore atau poin tertinggi pengguna Sedang

5

Pada subbab berikutnya, buatlah diagram konteks dan DFD level berikutnya.

3.3 Model Use Case

3.3.1 Diagram Use Case

3.3.2 Definisi Actor

No Actor Deskripsi
1 client Actor dengan role ini mempunyai wewenang untuk memainkan
game secara penuh serta menggunakan semua fitur yang ada

2 tester Actor dengan role ini mempunyai wewenang untuk memainkan

game secara penuh serta melakukan pengujian terhadap semua
fitur
3 pengembang Actor dengan role ini mempunyai wewenang untuk memainkan
game secara penuh serta melakukan maintenance/perbaikan
 3.3.3 Definisi Use Case
Use case adalah sebuah Teknik pemodelan yang digunakan untuk menjelaskan apa yang harus
dilakukan sebuah system baru. Model use case dibangun melalui sebuah proses iterasi selama
diskusi antara pengembang system dengan customer atau end user berdasarkan sebuah kebutuhan
khusus yang disetujui semuanya.
No Use Case Deskripsi
1 Menampilkan Menu Sistem menampilkan menu awal
2 Memilih level Permainan User memilih level permainan

3 Melihat Jawaban System menampilkan jawaban dari soal Permainan

Pertanyaan
4 Melihat Peringkat Score User melihat urutan peringkat pada score permainan
Permainan

3.3.4 Skenario Use Case

Nama Use Case: Melihat daftar menu
Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1. Memilih menu
2. Menampilkan daftar menu kelayar

3. Memilih salah satu pilihan menu

4. Me-refresh tampilan layer sesuai menu yang dipilih

Nama Use Case: Memulai Permainan

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1. Memilih Memulai Permainan
2. Menampilkan Daftar urutan Lv Permainan

3. Memulai Permainan dari Awal

4. Menampilkan Soal permainan
5. Menjawab Soal Permainan
6. Jawaban benar, Menampilkan Soal Selanjutnya
Skenario Alternatif
1. Memilih Memulai Permainan
2. Menampilkan Daftar urutan Lv Permainan

3. Memulai Permainan dari Awal

4. Menampilkan Soal permainan
5. Menjawab Soal Permainan
6. Jawaban salah
7. Menampilkan jawaban soal
Skenario Alternatif
1.Memilih Memulai Permainan
2. Menampilkan Daftar urutan Lv Permainan
3. Melanjutkan Lv Permainan dari game sebelumnya
4. Menampilkan Soal permainan

Nama Use Case: Melihat daftar Peringkat

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
 1. Memilih menu
2. Menampilkan daftar menu kelayar

3. Memilih salah satu pilihan menu”Daftar Peringkat”

4. Me-refresh tampilan layar Ke daftar Peringkat
4. Memilih salah satu pilihan menu”Daftar Peringkat”
5.Menampilkan Daftar Peringkat

Nama Use Case: Melihat Jawaban soal

Skenario:
Aksi Actor Reaksi Sistem
Skenario Normal
1. Memulai Permainan
2. Me-refresh tampilan layar Ke soal sesuai level

3. Memilih “Tampilkan Jawaban Soal”

4. Menampilkan Jawaban Soal Permainan
Skenario Alternatif
1. Memulai permaian
2. Me-refresh tampilan layar Ke soal sesuai level
3. Menilih jawaban
4. Jawaban yang dipilih salah
5. Menekan tombol navigasi (next)
6. Me-refresh tampilan layar Ke Jawaban Soal
Permainan

3.4 Kebutuhan Non Fungsional

Kebutuhan Kinerja

Waktu perpindahan soal kesoal lain tidak lebih dari 2 detik. Tampilan pada menu utama dibuat simple dan menarik
agar tidak membuat bingung.

Kebutuhan Keamanan

Sistem memiliki fungsi login dengan gmail untuk menjamin keamaman data sistem.

Kebutuhan Perlindungan Keamanan

Sistem memiliki sistem keamanan yang membatasi pengembang dengan user,agar pengembang tidak
mengetahui data pribadi dari user atau pengguna.

Atribut Kualitas Perangkat Lunak

Performance Sistem dapat menerima data login lebih dari 100.

Interface Menu tersedia dalam bahasa indonesia dan inggris.
Security Memiliki kemanan yang dapat mengamankan data dari user.
Portability Sistem dibuat sebagai Aplikasi Android.

ID Parameter Kebutuhan
Availability Beroprasi minimal 1 hari perminggu
Reliability N/A
 Ergonomy Tampilan yang simple dan mudah digunakan serta di buat
akan tidak terkesan membosankan
Portability N/A
Memory Maksimal 100 mb
Response time Aplikasi harus mampu menampilkan tampilan pada layar
dengan jeda maksimal 30 detik
Safety N/A
Security Memiliki fungsi login dengan gmail

Others 1: Bahasa Pertanyaan dan tampilan tersedia dalam bahasa Indonesia

komunikasi dan bahasa inggris

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:
“Aaplikasi harus mampu menampilkan hasil dalam 4 detik”, atau “ATM harus menarik kembali kartu
yang tidak diambil dalam waktu 3 menit”
Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem kontrol di
pabrik Security : aspek keamanan yang harus dipenuhi.

3.5 Batasan Perancangan

Software hanya dapat dijalankan pada sistem android 3 atau lebih.

3.6 Kerunutan (traceability)

Diisi dengan tabel yang berisi traceability dari hasil analisis. Gunanya untuk menilai apakah hasil
analisis “runut” dan lojik. Untuik sementara, baru didefinisikan Data-store versus E-R.

3.6.1 Kebutuhan Fungsional vs Use Case

Mapping kebutuhan fungsional dengan use case terkait

ID Kebutuhan ID Use Case Terkait

Fungsional

3.7 Ringkasan Kebutuhan

Kebutuhan dalam rangcangan software ini adalah dapat menampilkan menu utama, soal ,jawaban benar ,
serta high score pengguna, tampilan yang simple yang menarik, loading yang tidak lama,.

3.7.1 Kebutuhan Fungsional

ID Deskripsi
Sistem dapat menampilkan menu utama
Sistem dapat menampilkan petunjuk penggunaan
aplikasi

Sistem dapat menampilkan soal berdasarkan level

Sistem dapat menampilkan jawaban yang benar
bila jawaban soal salah
Sistem dapat menampilkan poin dari jawaban semua
soal

Sistem dapat menampilkan highscore atau poin tertinggi

pengguna
Memiliki bahasa indonesia dan inggris
Terdapat fungsi login gmail
Waktu pergantian tiap level tidak lebih dari 2 detik
Memerluka library JDBC

3.7.2 Kebutuhan Non Fungsional

ID Deskripsi
Sistem android minimal android 3
Memory maksimal ynag dihabiskan adala 100 Mb
Terkonfigirasi dengan akun gmail
Tampilan menarik dan tidak membosankan