Anda di halaman 1dari 22

SPECIFICATION REQUIREMENT SYSTEM

MEDIA OF INTERACTIVE ENGLISH LANGUAGE

Disusun Oleh :
ACENG
DINDIN
GINA
RIZKA
VINA
i
DAFTAR ISI

DAFTAR PERUBAHAN...........................................................................................................i

DAFTAR HALAMAN PERUBAHAN.....................................................................................ii

DAFTAR ISI.............................................................................................................................iii

1. Pendahuluan...........................................................................................................................1

1.1. Tujuan..........................................................................................................................1

1.2. Lingkup Masalah.........................................................................................................1

1.3. Definisi, Akronim, dan Singkatan...............................................................................1

1.4. Deskripsi Umum Dokumen.........................................................................................2

2. Kebutuhan Perangkat Lunak..................................................................................................2

2.1. Deskripsi Umum Perangkat Lunak.............................................................................2

2.2. Karakteristik Pengguna...............................................................................................3

2.3. Fitur Utama Perangkat Lunak.....................................................................................4

2.4. Batasan-batasan...........................................................................................................5

2.5. Lingkup Operasi..........................................................................................................5

2.6. Pengembangan Perangkat Lunak................................................................................5

3. Deskripsi Rinci Kebutuhan....................................................................................................7

3.1. Antarmuka Eksternal...................................................................................................7

3.1.1. Antarmuka Pemakai.............................................................................................7

3.1.2. Antarmuka Perangkat Keras................................................................................7

3.1.3. Antarmuka Perangkat Lunak................................................................................8

3.1.4. Antarmuka Komunikasi.......................................................................................8

3.2. Design Kebutuhan Fungsional....................................................................................9

3.2.1. Use Case Akses Mahasiswa Dan Dosen..............................................................9

ii
3.2.1.1. Case Login....................................................................................................9

3.2.1.2. Case Aktifasi Account................................................................................10

3.2.1.3. Case Kelola Data Profil..............................................................................10

3.2.1.4. Case View & Download File......................................................................10

3.2.1.5. Case Daftarkan Mahasiswa.........................................................................10

3.2.1.6. Case Aktifasi Akun Mahasiswa..................................................................11

3.2.2. Use Case Akses Operator Universitas................................................................11

3.2.2.1. Case Daftarkan Dosen Pembimbing...........................................................11

3.2.2.2. Case Aktifasi Akun Dosen..........................................................................12

3.2.2.3. Upload File Karya Ilmiah...........................................................................12

3.2.2.4. Laporan List Upload Karya Ilmiah.............................................................12

3.2.3. Activity Diagram Pendaftaran dan Aktifasi Akun.............................................13

3.2.4. Activity Diagram Upload File Karya Ilmiah.....................................................14

3.2.5. Entity Relationship Diagram (schematic)..........................................................15

4. Template Project..................................................................................................................15

4.1. Form Login................................................................................................................15

4.2. Home.........................................................................................................................16

4.3. Pencarian Data Thesis...............................................................................................16

4.4. List Judul Thesis........................................................................................................17

iii
1. Pendahuluan

1.1. Tujuan

Dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau biasa disebut juga
SRS (Specification Requirement System) merupakan dokumen spesifikasi kebutuhan
perangkat lunak yang akan dikembangkan. Tujuan disusunnya Software Requirement
Specification (SRS) ini ialah untuk menyatakan kebutuhan perangkat lunak yang akan
digunakan dalam sistem sebagai hasil dari proses analisis yang dilakukan dalam tahapan
perancangan perangkat lunak sebuah sistem. Selain itu juga untuk memberikan gambaran
kepada pembaca mengenai spesifikasi software yang akan dikembangkan. Software yang
akan dikembangkan meliputi beberapa fitur penting diantaranya fitur untuk pengisian nama
(login), menu utama yang berisi materi pembelajaran dan soal pretest serta posttest disertai
dengan nilai.

1.2. Lingkup Masalah

Dari banyaknya referensi-referensi media pembelajaran dibidang pendidikan,


dibutuhkan suatu sistem atau aplikasi multimedia interaktif dalam bentuk mobile learning
khususnya untuk mata pelajaran bahasa inggris pada jenjang SMP, sehingga dengan sistem
ini diharapkan pengguna bisa lebih mudah dan cepat dalam mendapatkan aplikasi media
pembelajaran. Sehingga memudahkan pengguna dalam mengaplikasikan dan mendapatkan
aplikasi tersebut dan bisa diakses langsung pada handphone android.

1.3. Definisi, Akronim, dan Singkatan


 SKPL adalah Spesifikasi Kebutuhan Perangkat Lunak, atau dalam bahasa Inggris-nya
sering juga disebut sebagai Software Requirements Spesification (SRS), dan merupakan
spesifikasi dari perangkat lunak yang akan dikembangkan.
 SRS-AC-XX-YY adalah kode yang digunakan untuk merepresentasikan kebutuhan
(requirement) pada website e-Slib, dengan AC merupakan kode modul, XX adalah kode
urutan sub modul, dan YY adalah digit/nomor kebutuhan (requirement) atau sub modul
kedua.
 ERD adalah Entity Relationship Diagram adalah diagram dan notasi yang digunakan untuk
merepresentasikan struktur data statis pada perangkat lunak.

1
 HTML adalah HyperText Markup Language, bahasa markup yang digunakan untuk
membuat sebuah halaman web dan menampilkan berbagai informasi didalam sebuah
browser internet.
 PHP adalah PHP Hypertext Preprocessor, bahasa pemrograman script yang paling banyak
dipakai saat ini atau dalam kata lain bias diartikan sebuah bahasa pemrograman web yang
bekerja di sisis server (server site scripting) yang dapat melakukan konektivitas pada
database yang dimana hal itu tidak dapat dilakukan hanya dengan menggunakan syntax-
sintax HTML biasa.
 MySQL adalah sebuah perangkat lunak sistem manajemen basis data SQL atau DBMS
yang multithread, multi-user, dengan sekitar 6 juta instalasi di seluruh dunia

1.4. Deskripsi Umum Dokumen

Dokumen SRS ini dibagi menjadi tiga bagian utama. Bagian utama berisi penjelasan
tentang dokumen SRS yang mencakup tujuan pembuatan dokumen ini, lingkup masalah yang
diselesaikan oleh perangkat lunak yang dikembangkan, definisi, dan deskripsi umum. Bagian
kedua berisi penjelasan secara umum mengenai perangkat lunak yang akan dikembangkan
meliputi fungsi dari perangkat lunak, karakteristik pengguna, batasan, dan asumsi yang
diambil dalam pengembangan perangkat lunak. Bagian ketiga berisi uraian kebutuhan
perangkat lunak secara lebih rinci.

2. Kebutuhan Perangkat Lunak

2.1. Deskripsi Umum Perangkat Lunak

e-SLIB adalah sebuah system berbasis Web yang digunakan untuk mengidentifikasi
tulisan-tulisan ilmiah (Skripsi/Thesis/Karya Ilmiah) yang tersebar di berbagai perguruan
tinggi negeri/swasta di Indonesia maupun yang ada di luar negeri. Dari e-SLIB ini, pengguna
dapat melihat berbagai referensi mengenai ide, teknologi, materi dan penulis dari tulisan-
tulisan ilmiah tersebut. Secara umum, informasi dan manfaat yang dapat ditemukan dari e-
SLIB ini antara lain :

1. Pengguna ( khususnya mahasiswa dan dosen ) dapat melihat dan mengunduh referensi
tulisan ilmiah karya orang lain berupa file abstrak dan jurnal dengan format yang di
izinkan, misalkan *.doc atau *.pdf. Dari referensi tersebut dosen pembimbing dapat

2
melakukan analisa isi dari karya ilmiah yang diajukan oleh mahasiswa sebagai
rekomendasi pengembangan lebih lanjut untuk mahasiswa sehingga menghindari plagiat.
2. Referensi tulisan-tulisan ilmiah yang ditampilkan bukan hanya berasal dari dalam
negeri saja, tapi sumber dari server luar negeri yang men-share file tulisan ilmiah
mereka.

2.2. Karakteristik Pengguna

Pengguna dari aplikasi mobile learning berdasarkan hak akses dan perannya adalah
sebagai berikut :

1. Super Admin, yaitu orang yang diberi wewenang untuk dapat mengakses seluruh fitur
yang terdapat pada aplikasi, hak akses ini digunakan untuk pihak development untuk
proses pengembangan, test dan maintenance.
2. Administrator, yaitu orang yang ditunjuk sebagai pengelola data konten, master dan
account user lainnya, tetapi tidak diizinkan untuk mengakses konten khusus seperti
mengisi soal pretest dan posttest. Administrator juga bertanggung jawab sebagai helpdesk
untuk melayani user lain dan mengelola materi pembelajaran yang ada di dalam aplikasi.
3. Pengguna aplikasi, yaitu orang yang bisa login sekaligus mengakses materi pembelajaran
dan mengisi soal pretest dan posttest untuk mengetahui nilai akhir yang didapatkan
melalui aplikasi mobile.

2.3. Fitur Utama Perangkat Lunak

Fitur aplikasi mobile learning dibagi menjadi 2 bagian berdasarkan fungsionalitasnya


yaitu kebutuhan fungsional dan non-fungsional, penjelasan dari keduanya akan dibahas pada
sub-bab selanjutnya.

2.3.1. Kebutuhan Fungsional

Kebutuhan fungsionalitas merupakan kebutuhan utama yang berkaitan langsung


dengan pelayanan aplikasi mobile learning yang dibagi menjadi beberapa modul seperti yang
tercantum dalam tabel di bawah ini :

3
No ID Deskripsi
1 SRS-AC-01 Mengelola data pribadinya pada member area.
2 SRS-AC-02 Mengganti password dan melakukan pemulihan password.
3 SRS-AC-03 Fitur Auto confirm lewat email untuk pertama kali mengakses, link
confirm berasal dari account email admin yang dikirim dari sistem.
4 SRS-FT-01 Sistem melakukan pengiriman username dan password kepada user
lewat email pada saat universitas selesai mendaftarkan daftar dosen
pembimbing.
5 SRS-FT-02 Triger upload file secara otomatis jika universitas tidak mengupload
data pada jangka waktu yang ditentukan (bulan agustus tahun berjalan)
dan pemberian status sanksi.
6 SRS-FT-03 Sistem men-generate username dengan NIP dosen dan password yang
dirandom oleh sistem. Sedangkan untuk universitas sistem men-
generate username dengan kode universitas dan password dirandom
oleh sistem.
7 SRS-FT-04 Pencarian abstrak dan jurnal berdasarkan judul, topik dan bahasa.
8 SRS-FT-05 Dapat ditampilkan secara multi
Language.
9 SRS-CT-01 Menampilkan file jurnal dan abstrak dengan pilihan membaca online
dan download.
10 SRS-CT-02 Filter view file abstrak dan jurnal dengan mengidentifikasi jenis
penyimpanan yang digunakan untuk menyimpan file, jika di cloude
storage maka pilihan nya hanya download only , dan jika di server
universitas maka bisa view dan download.
11 SRS-AD-01 Register satu account operator untuk satu universitas.
12 SRS-AD-02 Menentukan hak akses (previleges) user terhadap modul, menu dan
function.
13 SRS-AD-03 Mengelola data master yang digunakan sebagai referensi untuk
setiapform pengisian.
14 SRS-AC-04 Dosen dapat mendaftarkan mahasiswa yang melakukan bimbingan
dengan membuatkan akun.
15 SRS-FT-14 Sistem menyediakan fitur pembuatan daftar judul karya ilmiah yang
sudah di upload oleh suatu universitas dengan filter rentang waktu,
judul, tema, dan penulis

4
2.3.2. Kebutuhan Non-Fungsional

No ID Deskripsi
1 SRS-DB-01 Username dan password di enkripsi dengan md5.
2 SRS-DB-03 Validasi format username tanpa spasi dan maximal 10 karakter.
3 SRS-DB-03 Validasi format alamat email dan keberadaan alamat email tersebut dalam
database, alamat email hanya dapat digunakan satu kali oleh satu user, tidak
boleh ada duplikat email.
4 SRS-FT-06 Security anti query injection.
5 SRS-FT-07 Authentication dan Otorization user berdasarkan username, password dan
previleges user.
6 SRS-FT-08 Menentukan waktu idle pengaksesan.
7 SRS-FT-09 Tersedia 24 jam sehari, 7 hari seminggu
8 SRS-FT-10 Tidak pernah gagal dalam menampilkan, menginput atau mengubah
informasi.
9 SRS-FT-11 Kemudahan pemakaian pada sistem yang sesuai.
10 SRS-FT-12 Interface menggunakan Bahasa Indonesia.
11 SRS-FT-13 Selalu muncul pesan kesalahan jika terjadi error.

2.4. Batasan-batasan

Batasan-batasan yang ditentukan dalam mengembangkan perangkat lunak ini adalah :

1. Informasi dan sumber karya ilmiah yang di tampilkan berasal dari file-file jurnal dan
abstrak karya ilmiah yang di upload dari setiap universitas yang terdaftar dalam
database.
2. Hak akses terbatas pada dosen pembimbing dan mahasiswa yang didaftarkan ke
sistem.

2.5. Lingkup Operasi

Perangkat lunak yang dibutuhkan oleh user maupun administrator adalah:


 Sistem Operasi : Microsoft® Windows XP/Vista/7
 Aplikasi : MySQL

5
2.6. Pengembangan Perangkat Lunak

Sesuai dengan referensi dari buku Software Engineering karya Ian Sommerville tahun
2004 tentang software process, kami menggunakan model evolutionary process dimana
perangkat lunak kami dikembangkan secara berkala dan dalam setiap tahapnya kami
memberikan feedback dari proses pengembangan perangkat lunak kami kepada customer dan
meminta feedback dari customer, apakah pengembangan perangkat lunak kami sudah sesuai
dengan permintaan dari customer. Kami berharap bahwa pengembangan perangkat lunak
kami akan benar-benar sesuai dengan permintaan customer, meskipun memakan waktu lebih
lama, dan pengerjaan perangkat lunak menjadi tidak terstruktur.

Sekilas tentang evolutionary process

Concurr ent
activities

Initia
Specifica tion version
l

Outline Inter media te


Development versions
description

Final
Valida tion version

Gambar 2. 1 evolutionary process

Dengan menggunakan evolutionary process ini, project plan kami akan selesai paling cepat
dalam waktu 3 bulan dengan rincian awal sebagai berikut :

6
Tabel 2. 1 Project Plan Schedule

M1 M1 M1
NO PROSES M1 M2 M3 M4 M5 M6 M7 M8 M9
0 1 2

1 Interface program
2. Pengaplikasian
interface ke dalam
pemograman php
3. Mengaplikasikan
program dan
menghubungkanny
a dengan MySQL
4. Validasi
program( memperb
aiki bug-bug dalam
program)
5. Finishing program

3. Deskripsi Rinci Kebutuhan

3.1. Antarmuka Eksternal

Kebutuhan antarmuka eksternal pada Website Himpunan Teknik Informatika


mencakup kebutuhan antarmuka pemakai, antarmuka perangkat keras dan antarmuka
perangkat lunak.

3.1.1. Antarmuka Pemakai

Antarmuka pemakai akan dikembangkan dengan menggunakan modus grafik yang


dibangun menggunakan HTML yang dirancang untuk memudahkan pemakai dalam
penggunaan Website e-Slib ini. Website ini dapat diakses dengan menggunakan komputer
CPU, komputer jingjing dan smartphone.

7
3.1.2. Antarmuka Perangkat Keras

Adapun spesifikasi komputer CPU dan komputer jingjing untuk klien berdasarkan
kebutuhan mininal adalah sebagai berikut :

 Intel® Pentium III atau AMD seri Sempron ,


 Standar Memory 256 MB DDR ,
 Storage HD 40 Gbyte,
 Mouse dan KeyBoard,
 Monitor 14 inches.
 Akses Internet by modem, wifii dll.

Sedangkan untuk specification smartphone harus memiliki aplikasi web browser khusus
mobile seperti opera dan google chrome atau browser bawaan smartphone.

Untuk spesifikasi komputer server sebagai berikut:

 Intel® Core™ i3-2120 Processor (3.30 GHz, 3M Cache) ,


 Standar Memory 2 GB DDR3 PC-10600 ,
 Storage HD 160 Gbyte,
 Mouse dan KeyBoard,
 Monitor 14 inches.

3.1.3. Antarmuka Perangkat Lunak

Perangkat lunak yang harus terpasang pada komputer CPU atau komputer jingjing untuk
klien berdasarkan kebutuhan minimal yaitu :

 Sistem Operasi Windows XP, Linux


 Web Browser IE versi 6 ke atas, Mozilla FireFox, Opera, dll.
 Untuk specification smartphone harus memiliki aplikasi web browser khusus mobile
seperti opera dan google chrome atau browser bawaan smartphone.

Sedangkan perangkat lunak yang harus terpasang pada komputer server berdasarkan
kebutuhan minimal yaitu :

 Sistem Operasi Windows Server 2000, Linux (khusus server).

8
 DBMS MySql.

3.1.4. Antarmuka Komunikasi

Antamuka komunikasi yang dibutuhkan hanya sebuah komputer server sebagai penyedia
layanan data dan interface, dan satu atau beberapa komputer klien yang terhubung dalam
jaringan internet sehingga dapat mengakses website ini melalui web browser dari komputer
klien.

3.2. Design Kebutuhan Fungsional

3.2.1. Use Case Akses Mahasiswa Dan Dosen

Authentication

«uses»

«uses» Otorization

Login
* *

Aktifasi Account
* *

*
**
Kelola Data Profil * **
* *
*

*
* * Dosen
Mahasiswa
View & Download
* File *

*
Daftarkan Mahasiswa

*
Aktifasi Akun
Mahasiswa

Gambar 3. 1 Diagram Use Case Mahasiswa dan Dosen

9
3.2.1.1. Case Login

 Tujuan : Menampilkan halaman login


 Actor : Mahasiswa dan Dosen Pembimbing
 Use Case : Sistem akan menampilkan halaman login dan melakukan dan fitur
authentikasi dan otorisasi username dan password terhadap hak akses yang dimiliki
user. [SRS-DB-01 dan SRS-DB-03].

3.2.1.2. Case Aktifasi Account

 Tujuan : Melakukan aktifasi melalui link yang dikirim admin ke email user.
 Actor : Mahasiswa dan Dosen Pembimbing
 Use Case : Link aktifasi yang dikirimkan operator untuk dosen atau mahasiswa jika di
klik otomatis akun akan aktif dan berstatus valid, kemudian user akan diarahkan ke
halaman member area. [SRS-AC-03].

3.2.1.3. Case Kelola Data Profil

 Tujuan : Mengelola data profil user di member area.


 Actor : Mahasiswa dan Dosen Pembimbing
 Use Case : Dalam member area user di sediakan fitur profil yang dapat di kelola
sendiri oleh user yang bersangkutan. [SRS-AC-01].

3.2.1.4. Case View & Download File

 Tujuan : Melihat dan mengunduh file jurnal dan abstrak .


 Actor : Mahasiswa dan Dosen Pembimbing
 Use Case : User dapat melihat secara online dan mengunduh file jurnal dan abstrak
yang tersedia di server, namun jika file ditempatkan pada cloude storage maka tidak
bisa dilihat secara langsung, melainkan harus di unduh (download) .[SRS-CT-02].

3.2.1.5. Case Daftarkan Mahasiswa

10
 Tujuan : Mendaftarkan mahasiswa yang menempuh bimbingan.
 Actor : Dosen Pembimbing
 Use Case : Dosen pembimbing mendaftarkan user mahasiswa yang mengajukan
bimbingan skripsi kepadanya dengan memberikan akun yang kemudian diaktifasi
secaraotomatis link aktifasi dikirimkan ke email mahasiswa untuk validasi akun. [SRS-
AC-04].

3.2.1.6. Case Aktifasi Akun Mahasiswa

 Tujuan : Mengaktifkan akun mahasiswa yang lewat link email.


 Actor : Dosen Pembimbing
 Use Case : Link aktifasi otomatis terkirim setelah akun dibuatkan oleh dosen. [SRS-
AC-04].

3.2.2. Use Case Akses Operator Universitas

Generate Random
«uses»
Daftarkan Dosen Password
Pembimbing
* «uses»

Validasi Email

** Aktifasi Akun Dosen


* *
*
«uses»
Generate Link
Operator Universitas «uses» Aktifasi

Upload File Karya


* Ilmiah

Kirim Link Aktifasi


«extends»
*
Laporan ListUpload
Karya Ilmiah
Validasi Format
File

Gambar 3. 2 Use Case Akses Operatos Universitas

11
3.2.2.1. Case Daftarkan Dosen Pembimbing
 Tujuan : Mendaftarkan nama-nama dosen pembimbing yang ada di universitas
untuk dibuatkan akun.
 Actor : Operator Universitas
 Use Case : Operator mendaftarkan list nama-nama dosen beserta data yang dibutuhkan
untk dibuatkan akun guna mengakses aplikasi, email setiap dosen akan divalidasi
terlebih dahulu sebelum dibuatkan akun, jika email valid maka informasi dan link
validasi akun akan dikirim ke email dosen secara otomatis.. [SRS-FT-03].

3.2.2.2. Case Aktifasi Akun Dosen


 Tujuan : Aktifasi akun dosen secara otomatis setelah email di validasi..
 Actor : Operator Universitas
 Use Case : Email dosen yang valid akan dikirimkan link aktifasi dan validasi akun
email. [SRS-FT-03].

3.2.2.3. Upload File Karya Ilmiah


 Tujuan : Melakukan upload file karya ilmiah dari karya mahasiswa setiap tahunnya.
 Actor : Operator Universitas
 Use Case : Operator setiap universitas melakukan upload hasil karya ilmihaberupa
jurnal dan abstrak yang dikumpulkan setiap akhir tahun pendidikanyang sudah
ditetapkan, jikatidak melakukan upload pada batas tanggal yang di tentukan, maka
sistem akan mendownload secara otomatis melaui web service yang disediakan oleh
universitas. [SRS-FT-02].

3.2.2.4. Laporan List Upload Karya Ilmiah


 Tujuan : Membuat laporan untuk mengetahui daftar karya ilmiah yang sudah
diupload ke dalam sistem untuk setiap universitas.
 Actor : Operator Universitas

12
 Use Case : Sistem menyediakan fitur pembuatan daftar judul karya ilmiah yang sudah
di upload oleh suatu universitas dengan filter rentang waktu, judul, tema, dan penulis
[SRS-FT-14].

13
3.2.3. Activity Diagram Pendaftaran dan Aktifasi Akun

Operator e-Slib System

Data Dosen Daftarkan Dosen

Validasi Email Generate Random Password

Generate Link Aplikasi

Kirim Link Aplikasi

Gambar 3. 3 Activity Diagram Pendaftaran dan Aktifasi Akun

14
3.2.4. Activity Diagram Upload File Karya Ilmiah

Operator e-Slib System Storage

File Jurnal & Abstrac Path File Upload

Validation Format File

Y
Save File

T
Info gagal upload Konfirmasi Gagal

Gambar 3. 4 Activity Diagram Upload File Karya Ilmiah

15
3.2.5. Entity Relationship Diagram (schematic)

thesis
User PK id
PK userid
no_thesis
author
nama_lengkap
judul
Alamat
tanggal_pembuatan
email
link_download_abstrak
password grup_user link_download_jurnal
grup_userID
PK grupID kampus_id
FK1 grupID
FK2 formatID
FK2 kampusID
nama_grup FK1 kampusID

Previleges
kampus Format_File
PK kampusID PK formatID
grupID
menuID nama_kampus ekstensi_File
allowView Alamat_kampus
allowEdit tgl_berdiri
allowDelete negara
kode_negara
allowUpload FK1 negaraID PK negaraID
allowDownload
nama_negara

Gambar 3. 5 ERD e-Slib

4. Template Project

4.1. Form Login

Gambar 3. 6 Template Form Login

16
4.2. Home

Gambar 3. 7 Template Halaman Home

4.3. Pencarian Data Thesis

Gambar 3. 8 Template Halaman Pencarian Judul Thesis

17
4.4. List Judul Thesis

Gambar 3. 9 Template Halaman List Judul Thesis

18

Anda mungkin juga menyukai