Berikut fungsi utama sistem BidMe:
1. Layanan pelelangan aplikasi mobile phone
- Mengunggah aplikasi untuk dilelang
- Meninjau aplikasi yang dilelang
- Melakukan tawar menawar harga aplikasi
- Memilih pemenang lelang
2. Layanan informasi dan tutorial
- Mengunggah tutorial pengembangan aplikasi
- Mengunggah informasi terkait industri aplikasi mobile
3. Layanan forum diskusi
- Membuat thread diskusi baru
1. GL01
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
E-Bidding System BidMe
untuk:
PT. Cipta Guna Manfaat
Dipersiapkan oleh:
Agus Budi Raharjo - 5112201905
Jurusan Teknik Informatika - Institut Teknologi Sepuluh Nopember
Jl. Raya ITS Surabaya 60111
Jurusan
Teknik Informatika
ITS
Nomor Dokumen
Halaman
GL01-G03
<1>/<34>
Revisi
0
Tgl: 16/06/2013
3. Daftar Halaman Perubahan
Halaman
Revisi
Jurusan Teknik Informatika ITS
Halaman
SKPL-G03
Revisi
Halaman 3 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
4. Daftar Isi
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 ................................................................................................................................... 6
1.5
Referensi .................................................................................................................................................. 6
1.6
Deskripsi umum Dokumen (Ikhtisar) ....................................................................................................... 7
2
Deskripsi Umum Perangkat Lunak .................................................................................................................. 7
2.1
Deskripsi Umum Sistem .......................................................................................................................... 7
2.2
Fungsi Produk .......................................................................................................................................... 8
2.3
Karakteristik Pengguna ............................................................................................................................ 8
2.4
Batasan .................................................................................................................................................... 9
2.5
Lingkungan Operasi ................................................................................................................................. 9
3
Deskripsi Umum Kebutuhan.......................................................................................................................... 10
3.1
Kebutuhan antarmuka eksternal ............................................................................................................. 10
3.1.1
Antarmuka pemakai ....................................................................................................................... 10
3.1.2
Antarmuka perangkat keras ........................................................................................................... 10
3.1.3
Antarmuka perangkat lunak ........................................................................................................... 10
3.1.4
Antarmuka komunikasi .................................................................................................................. 10
3.2
Deskripsi Fungsional ............................................................................................................................. 11
3.2.1
Diagram Kasus Penggunaan .......................................................................................................... 11
3.2.2
Kasus Penggunaan Mengunggah Aplikasi ..................................................................................... 11
3.2.2.1 Skenario Mengunggah Aplikasi ................................................................................................. 11
3.2.2.2 Diagram Aktivitas Mengunggah Aplikasi .................................................................................. 13
3.2.3
Kasus Penggunaan Meninjau Aplikasi ........................................................................................... 13
3.2.3.1 Skenario Meninjau Aplikasi ...................................................................................................... 13
3.2.3.2 Diagram Aktivitas meninjau aplikasi ......................................................................................... 15
3.2.4
Kasus Penggunaan Melelang Aplikasi ........................................................................................... 15
3.2.4.1 Skenario Melelang Aplikasi ....................................................................................................... 15
3.2.4.2 Diagram Aktivitas Melelang Aplikasi........................................................................................ 17
3.2.5
Kasus Penggunaan Menilai Aplikasi ............................................................................................. 17
3.2.5.1 Skenario Menilai Aplikasi ......................................................................................................... 17
3.2.5.2 Diagram Aktivitas Menilai Aplikasi .......................................................................................... 19
3.2.6
Kasus Penggunaan Mengunggah Informasi ................................................................................... 19
3.2.6.1 Skenario Mengunggah Informasi ............................................................................................... 19
3.2.6.2 Diagram Aktivitas Mengunggah Informasi ................................................................................ 21
3.2.7
Kasus Penggunaan Berdiskusi dalam Chatroom ........................................................................... 21
3.2.7.1 Skenario Berdiskusi dalam Chatroom ....................................................................................... 21
3.2.7.2 Diagram Aktivitas Berdiskusi dalam Chatroom ........................................................................ 23
3.2.8
Context Diagram ............................................................................................................................ 24
3.2.8.1 DFD Level 1 .............................................................................................................................. 25
3.3
Data Requirement ................................................................................................................................. 26
3.3.1
E-R diagram ................................................................................................................................... 26
3.4
Non Functional Requirement ................................................................................................................. 27
3.5
Batasan Perancangan ............................................................................................................................. 28
3.6
Kerunutan (traceability) ......................................................................................................................... 29
3.6.1
Data Store vs E-R .......................................................................................................................... 29
3.7
Ringkasan Kebutuhan ............................................................................................................................ 29
3.7.1
Functional Requirement Summary................................................................................................. 29
3.7.2
Non Functional Requirement Summary ......................................................................................... 30
Skenario pelelangan aplikasi ......................................................................................................................... 31
Metode Elisitasi ............................................................................................................................................. 33
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 4 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
5. 1. Pendahuluan
1.1
Tujuan Penulisan Dokumen
Dokumen ini berisi Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software Requirement
Spesification (SRS) untuk sistem BidMe (E-Bidding System for Mobile Application). Tujuan dari penulisan
dokumen ini adalah untuk memberikan penjelasan mengenai perangkat lunak yang akan dibangun baik berupa
gambaran umum maupun penjelasan detil dan menyeluruh.
Pengguna dari dokumen ini adalah pengembang perangkat lunak sistem BidMe dan pengguna (user) dari
perangkat lunak atau personil-personil yang terlibat dalam sistem. Dokumen ini akan digunakan sebagai bahan
acuan dalam proses pengembangan dan sebagai bahan evaluasi pada saat proses pengembangan perangkat lunak
maupun di akhir pengembangannya. Dengan adanya dokumen SKPL ini diharapkan pengembangan perangkat
lunak akan lebih terarah dan lebih terfokus serta tidak menimbulkan ambiguitas terutama bagi pengembang
perangkat lunak sistem BidMe.
1.2
Lingkup Masalah
Perangkat lunak yang akan dikembangkan adalah perangkat lunak BidMe, yaitu merupakan perangkat
lunak berbasis web yang berfungsi sebagai mediator antara pengembang aplikasi mobile phone dengan sponsor.
BidMe memiliki tiga layanan, yaitu pelelangan aplikasi, penyediaan informasi dan tutorial terkait pengembangan
aplikasi mobile phone, dan forum diskusi antar pengguna. Layanan pelelangan aplikasi mobile phone pada sistem
ini hanya dibatasi pada proses pelelangan dan tidak menyediakan fasilitas transaksi. Dengan adanya BidMe ini
diharapkan, pengembang aplikasi dapat terhubung dan berinteraksi dengan sponsor dalam skala internasional
melalui proses pelelangan elektronik.
1.3
Definisi, Istilah dan Singkatan
Tabel T01. Definisi dan istilah
Istilah, Akronim
Keterangan
dan Singkatan
SKPL
Spesifikasi Kebutuhan Perangkat Lunak
Merupakan dokumen hasil analisis yang berisi spesifikasi kebutuhan user.
IEEE
Institute of Electrrical and Electronics Engineers
Merupakan standar internasional untuk pengembangan dan rancangan
perangkat lunak
SRS
Software Requirement Spesification
Dokumen ini sama dengan SKPL
BidMe
E-Bidding System for Mobile Application
Merupakan sistem yang menangani pelelangan aplikasi mobile secara online.
DCD
Data Context Diagram
Merupakan diagram yang menggambarkan hubungan sistem dengan
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 5 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
6. lingkungannya
DFD
Data Flow Diagram
Diagram yang menggambarkan aliran data dan proses yang terjadi di dalam
sistem
Admin
Administrator
Merupakan seseorang yang bertanggungjawab mengelola operasional
BidMe.
API
Application Programming Interface
Merupakan layanan yang disediakan oleh sistem lain agar bisa berinteraksi
dengan BidMe
MoA
Memorandum of Agreement
Merupakan surat perjanjian antara BidMe dengan pengguna dan berisi
rincian perjanjian.
Chatroom
Merupakan layanan pertukaran pesan antar dua pengguna atau lebih dalam
satu forum kecil yang dibuat khusus.
Screenshoot
1.4
Merupakan gambar yang berisi layar aplikasi
Aturan 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 T02 berikut ini.
Tabel T02. Aturan penamaan dan penomoran.
Hal/Bagian
Bab
Aturan Penomoran/Penamaan
Tiap bab diberi nomor sesuai dengan urutannya dalam dokumen. Bila satu bab dibagi menjadi
beberapa sub bab maka sub bab diberi nomor urut sesuai dengan urutannya pada bab tersebut.
Antara nomor bab dan sub bab dipisahkan dengan tanda titik.
Tabel
Tiap tabel yang ada dinamai dengan TXX dengan XX adalah nomor urut tabel dalam dokumen.
Diagram
Tiap diagram yang ada dinamai dengan DXX dengan XX adalah nomor urut diagram dalam
dokumen
Kasus
Tiap kasus penggunaan yang ada dinamai dengan UCXX dengan XX adalah nomor urut kasus
penggunaan
penggunaan dalam dokumen.
1.5
Referensi
Dokumen-dokumen yang digunakan sebagai referensi dalam pembuatan SKPL ini adalah sebagai berikut:
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 6 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
7. 1.
Applying collaborative process design to user requirements elicitation:A case study, Azadegan
A., Papamichail N., Sampaio P., Computers in Industry, pp 1-15, 2013.
2.
IEEE Std 830-1993, IEEE Recommended Practice for Software Requirement Specifications.
3.
Software Engineering, Aparctitioner’s Approach 5th edition, Roger S Pressman, Mc Graw Hill,
2001.
1.6
Deskripsi umum Dokumen (Ikhtisar)
Dokumen ini secara garis besar terdiri dari tiga bab dengan perincian sebagai berikut:
1.
Bab 1 terkait pendahuluan, merupakan pengantar dokumen SKPL yang berisi tujuan penulisan
dokumen, lingkup masalah pengembangan perangkat lunak, juga memuat definisi, akronim dan
istilah yang digunakan serta deskripsi umum dokumen yang merupakan ikhtisar dokumen SKPL.
2.
Bab 2 tentang deskripsi global perangkat lunak, mendefinisikan perspektif produk perangkat
lunak serta asumsi dan ketergantungan yang digunakan dalam pengembangan BidMe.
3.
Bab 3 terkait deskripsi umum kebutuhan, mendeskripsikan kebutuhan khusus bagi BidMe, yang
meliputi kebutuhan antarmuka eksternal, kebutuhan fungsionalitas, kebutuhan performansi,
batasan perancangan, atribut sistem perangkat lunak dan kebutuhan lain dari sistem BidMe.
2 Deskripsi Umum Perangkat Lunak
2.1
Deskripsi Umum Sistem
BidMe adalah perangkat lunak yang dibangun untuk memberikan fasilitas pelelangan aplikasi mobile
phone secara online. BidMe dibangun berdasarkan konsep komputasi awan yang bisa diakses di berbagai
tempat,berbagai waktu, dan menggunakan beberapa perangkat teknologi. BidMe memiliki tiga kelompok
layanan, yaitu pelelangan aplikasi, penyediaan informasi dan tutorial terkait pengembangan aplikasi mobile
phone, dan forum diskusi antar pengguna. Layanan pelelangan aplikasi merupakan proses bisnis utama dalam
BidMe dan layanan yang lain dibuat untuk menarik partisipasi pengguna dalam memanfaatkan BidMe. Proses
bisnis pelelangan pada BidMe memiliki perbedaan dengan pelelangan barang pada umumnya. Pemilik aplikasi
mobile phone yang bertindak sebagai auctioneer bisa memilih sponsor pemenang yang berperan sebagai bidder
dan tidak berdasarkan sponsor yang menawarkan harga tertinggi. Hal ini dilakukan untuk melindungi hak
auctioneer karena proses pelelangan berada pada dunia maya. BidMe tidak menyediakan fasilitas transaksi
keuangan online, namun menggunakan API PayPal untuk mencatat transaksi keuangan sehingga dapat
meminimalisir resiko. Setiap aktivitas yang berkaitan dengan keuangan akan ada Memorandum of Agreement
yang disediakan pemilik BidMe dan harus disetujui pengguna sebelum memanfaatkan layanan BidMe.
Pelelangan aplikasi mobile phone dipilih karena perkembangannya yang pesat dan memenuhi kebutuhan
pengembang aplikasi mobile phone awal untuk memperbesar usahanya. Dengan adanya BidMe, diharapkan
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 7 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
8. pemilik dapat memberikan layanan yang menghubungkan pengembang aplikasi mobile phone dan sponsor untuk
mengembangkan usaha mandirinya.
2.2
Fungsi Produk
Sistem BidMe ini memiliki beberapa fungsi utama:
1.
2.
(SKPL-BIDME 2) Melakukan pelelangan aplikasi.
3.
(SKPL-BIDME 3) Mengunggah informasi.
4.
(SKPL-BIDME 4) Menilai aplikasi.
5.
(SKPL-BIDME 5) Meninjau aplikasi.
6.
2.3
(SKPL-BIDME 1) Mengunggah aplikasi.
(SKPL-BIDME 6) berdikusi dalam chatroom.
Karakteristik Pengguna
Perangkat lunak BidMe ini berkaitan dengan beberapa entitas luar, yaitu admin, pengembang, sponsor,
peninjau, penilai, dan PayPal. Hal – hal yang dapat dilakukan oleh entitas – entitas tersebut adalah:
1.
Pengembang:
Mengunggah aplikasi.
Membuka pelelangan.
Meninjau aplikasi pengembang lain dan memberikan pendapat.
Mengunggah informasi.
Berdiskusi dengan pengguna lain.
2.
Sponsor:
Menawarkan harga lelang kepada pengembang.
Meninjau aplikasi pengembang dan memberikan pendapat.
Mengunggah informasi.
Berdiskusi dengan pengguna lain.
3.
Peninjau:
Meninjau aplikasi pengembang dan memberikan pendapat.
Mengunggah informasi.
Berdiskusi dengan pengguna lain.
4.
Penilai:
5.
Meninjau aplikasi pengembang dan memberikan penilaian.
Administrator :
Mengelola informasi dan forum diskusi.
Melakukan pengawasan dan tindakan terhadap seluruh sistem
Memelihara sistem.
6.
PayPal :
Memberi tahu bahwa keuntungan telah diterima di rekening.
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 8 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
9. Karakteristik pengguna dijabarkan dalam tabel berikut ini.
Tabel T03. Karakteristik pengguna
Kategori
Tugas
Hak Akses ke aplikasi
Pengguna
Pengembang
Pengembang
Sponsor
Menawarkan harga lelang
Sponsor
Tamu
Meninjau aplikasi dan memberikan pendapat
peninjau
Penilai
Memberi penilaian aplikasi yang dilelang
penilai
Administrator
Memantau dan memelihara sistem.
Admin
PayPal
2.4
Membuka pelelangan
Memberitahu keuntungan sudah diterima
Sistem luar (API PayPal)
Batasan
Pengembangan sistem BidMe ini memiliki beberapa batasan agar dapat berjalan optimal, diantaranya
sebagai berikut :
1.
Pada layanan pelelangan aplikasi BidMe tidak menyediakan fasilitas transaksi pelelangan dan hanya
menyediakan fasilitas lelang dan penawaran.
2.
Pengubahan status track record pengguna memerlukan integrasi dengan API PayPal agar dapat mencatat
keuntungan layanan pelelangan aplikasi.
3.
Aplikasi mobile yang bisa diunggah ke dalam BidMe harus berekstensi .sdp, .apk, .html , atau .jar.
4.
BidMe dapat dijalankan di sistem secara online pada semua web browser.
5.
BidMe dibangun dengan ukuran tampilan desktop (1024 pixel x 768 pixel).
6.
Sistem BidMe akan dibangun hanya menggunakan bahasa pemrograman Java dengan kerangka kerja
Spring dan menggunakan database MySQL.
2.5
Lingkungan Operasi
BidMe adalah aplikasi berbasis web yang memerlukan kebutuhan khusus pada sisi client dan servernya.
Spesifikasi yang diperlukan agar BidMe berjalan dengan baik dijelaskan pada tabel T04 di bawah ini.
Tabel T04. Lingkungan operasi BidMe
Spesifikasi
Server
Client
Harddisk
50 GB (per 1000 pengguna atau
-
per 1000 aplikasi atau per 1
tahun)
Memory (RAM)
Jurusan Teknik Informatika ITS
DDR3 32 GB (per 1000
SKPL-G03
DDR1/DDR2/DDR3 512
Halaman 9 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
10. pengguna aktif dalam waktu
MB
yang sama)
Sistem Operasi
Windows/Linux
Semua sistem operasi
DBMS
MySQL
-
Bahasa Pemrograman
Java (Spring framework)
-
Web Server
Apache Tomcat versi > 7.0
-
Perangkat lunak lain
Netbeans versi > 7.3, internet
Web browser, internet
Processor
> 10 GHz
> 1 GHz
Sistem lain
API Paypal
-
3 Deskripsi Umum Kebutuhan
3.1
Kebutuhan antarmuka eksternal
3.1.1 Antarmuka pemakai
System BidMe ini menggunakan antar muka berbasis web browser dan pengguna menggunakan
keyboard dan mouse.
3.1.2 Antarmuka perangkat keras
-
3.1.3 Antarmuka perangkat lunak
BidMe menggunakan API PayPal untuk berkomunikasi dengan Sistem PayPal yang bertujuan untuk
pemberitahuan pemasukan pada rekening.
3.1.4 Antarmuka komunikasi
-
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 10 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
11. 3.2
Deskripsi Fungsional
3.2.1 Diagram Kasus Penggunaan
Diagram D01. Diagram kasus penggunaan
System
mengunggah aplikasi
PayPal
pengembang
melelang aplikasi
berdiskusi dalam chatroom
admin
sponsor
meninjau aplikasi
menilai aplikasi
peninjau
penilai
mengunggah informasi
3.2.2 Kasus Penggunaan Mengunggah Aplikasi
3.2.2.1 Skenario Mengunggah Aplikasi
Tabel T05. Skenario mengunggah aplikasi
Use Case ID
UC1
Use Case Name
Mengunggah aplikasi
Created by
Last updated by
Date created
05-06-2013
Date last updated
05-06-2013
Actors :
Pengembang
Description :
Kasus penggunaan ini berfungsi untuk melakukan pengunggahan aplikasi sebelum
dilelang. Aplikasi yang diunggah disarankan dalam versi trial dan ada
pemberitahuan informasinya pada form pengunggahan. Aplikasi yang telah
diunggah dapat diperbarui dan diubah statusnya.
Trigger :
aktor membuka form pengunggahan aplikasi
Preconditions :
Aplikasi belum diunggah
Postcondition :
Aplikasi diunggah dan profil aplikasi terisi
Normal flow
1. Aktor membuka form pengunggahan aplikasi
2. Sistem menampilkan pilihan platform aplikasi yang terdiri dari:
-
Windows phone
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 11 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
12. -
Android
-
Html 5
-
Nokia S40
3. Aktor memilih platform aplikasi.
4. Sistem menampilkan form pengunggahan aplikasi
5. Aktor mengunggah aplikasi.
6. Sistem menampilkan form rincian profil aplikasi berupa:
-
Nama aplikasi
-
deskripsi aplikasi
-
screenshoot aplikasi
-
harga awal aplikasi
-
URL video aplikasi
-
kategori aplikasi
-
status aplikasi
7. aktor mengisi form rincian profil.
8. Sistem menyimpan aplikasi dan menampilkan profilnya.
Alternative flow :
5.1. Aplikasi yang diunggah tidak sesuai dengan platform aplikasi yang dipilih
1. Sistem menampilkan status ketidaksesuaian aplikasi yang diunggah dengan
platform aplikasi yang dipilih.
2. Kasus penggunaan kembali ke langkah 2.
7.1. Pengisian form rincian belum lengkap
1. Sistem menampilkan atribut form rincian profil yang belum terisi lengkap.
2. Kasus penggunaan kembali ke langkah 6.
7.2. Aktor membatalkan proses pengunggahan aplikasi
1. Sistem menampilkan status draft pengunggahan tersimpan.
2. Kasus penggunaan berakhir.
Exception :
-
Includes :
-
Priority :
High
Frequency of use
High
Business Rule :
-
Special
-
Requirement :
Assumption :
-
Notes and Issues :
-
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 12 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
13. 3.2.2.2 Diagram Aktivitas Mengunggah Aplikasi
Diagram D02 diagram aktivitas mengunggah aplikasi
pengembang
sistem
membuka form pengunggahan aplikasi
menampilkan pilihan platform
memilih platform
menampilkan form pengunggahan
mengunggah aplikasi
tidak sesuai
sesuai
menampilkan form rincian profil
mengisi form rincian profil
tidak lengkap
lengkap
menyimpan aplikasi
membatalkan
3.2.3 Kasus Penggunaan Meninjau Aplikasi
3.2.3.1 Skenario Meninjau Aplikasi
Tabel T06. Skenario Meninjau aplikasi
Use Case ID
UC2
Use Case Name
Meninjau aplikasi
Created by
Last updated by
Date created
06-06-2013
Actors :
peninjau
Jurusan Teknik Informatika ITS
Date last updated
SKPL-G03
06-06-2013
Halaman 13 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
14. Description :
Kasus penggunaan ini berfungsi untuk melakukan peninjauan aplikasi setelah
aplikasi diunggah. Pemilik aplikasi berhak menentukan karakteristik aktor yang
bisa meninjau aplikasinya. Dalam peninjauan, aktor bisa memainkan aplikasi dan
memberikan pendapat. Selain itu aktor juga bisa memberi rating dalam bentuk
bintang (bintang 1 s.d. bintang 5).
Trigger :
aktor membuka tautan rincian aplikasi pada halaman daftar aplikasi
Preconditions :
Aplikasi sudah diunggah
Postcondition :
Aplikasi mendapatkan masukan atau rating
Normal flow
1.
Aktor membuka tautan rincian aplikasi
2. Sistem menampilkan rincian aplikasi yang terdiri dari:
-
Kode aplikasi
-
Nama aplikasi
-
deskripsi aplikasi
-
screenshoot aplikasi
-
harga awal aplikasi
-
URL video aplikasi
-
kategori aplikasi
-
status aplikasi
-
rating terbaru
-
aplikasi versi trial
-
form pendapat aplikasi
3. aktor menjalankan aplikasi versi trial.
4. Aktor memberikan pendapat.
5. Aktor memilih keluar.
6. Sistem menampilkan form dialog pemberian rating.
7. Aktor memberikan rating aplikasi.
8. Sistem menyimpan pendapat dan rating terbaru.
Alternative flow :
4.1. Aktor tidak memberikan pendapat
1. Kasus penggunaan menuju ke langkah 5.
Exception :
-
Includes :
-
Priority :
High
Frequency of use
High
Business Rule :
-
Special
-
Requirement :
Assumption :
-
Notes and Issues :
-
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 14 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
15. 3.2.3.2 Diagram Aktivitas meninjau aplikasi
Diagram D03. Diagram aktivitas meninjau aplikasi
aktor
sistem
memilih tautan rincian aplikasi
menampilkan rincian aplikasi
menjalankan aplikasi
memberikan pendapat
memilih keluar
menampilkan daftar rating
memberi rating
menyimpan pendapat dan rating
3.2.4 Kasus Penggunaan Melelang Aplikasi
3.2.4.1 Skenario Melelang Aplikasi
Tabel T07. Skenario melelang aplikasi
Use Case ID
UC3
Use Case Name
Melelang aplikasi
Created by
Last updated by
Date created
06-06-2013
Date last updated
06-06-2013
Actors :
pengembang, sponsor, PayPal
Description :
Kasus penggunaan ini berfungsi sebagai media pelelangan aplikasi yang telah
diunggah. Proses pelelangan dibatasi oleh waktu yang ditentukan di awal oleh
pengembang dan harga awal. Pengembang diwajibkan untuk mengunggah aplikasi
full version agar dapat dinilai oleh penilai dan tidak untuk dipublikasikan ke
halaman rincian aplikasi. Pemenang lelang adalah sponsor yang dipilih
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 15 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
16. pengembang dan belum tentu sponsor yang melakukan penawaran paling tinggi
karena menjaga hak pengembang agar terhindar dari sponsor yang memiliki track
record buruk. Proses transaksi lelang tidak ditangani oleh BidMe, namun
keuntungan yang diperoleh BidMe akan terbarukan secara otomatis ketika
pengembang atau sponsor terpilih mengirimkan uang ke rekening PayPal BidMe.
Pada setiap transaksi ada track record
perubahan rating pengembang dan
sponsor.
Trigger :
Aktor (pengembang) memilih pilihan memulai pelelangan
Preconditions :
Aplikasi sudah diunggah
Postcondition :
Aplikasi berhasil dilelang dan status track record transaksi masing-masing aktor
berubah
Normal flow
1.
Aktor(pengembang) memilih pilihan memulai pelelangan.
2. Sistem menampilkan rincian persyaratan pelelangan yang terdiri dari:
-
tombol pengunggahan aplikasi full version.
-
Batas waktu pelelangan
-
Dokumen MoA
-
Rating minimal sponsor yang bisa menawarkan
3. Aktor (pengembang) mengisi rincian persyaratan pelelangan.
4. Sistem menjalankan kasus penggunaan menilai aplikasi.
5. Sistem membuka forum lelang aplikasi.
6. Aktor(sponsor) memilih pilihan penawaran aplikasi.
7. Sistem menampilkan form penawaran yang terdiri dari:
-
Harga penawaran
-
Keterangan tambahan
8. Aktor (sponsor) mengisi form penawaran aplikasi.
9. Jika sudah mencapai batas waktu lelang, sistem menutup forum lelang
aplikasi.
10. Sistem mengirim alamat rekening PayPal ke aktor (pengembang).
11. Aktor (PayPal) memasukkan track record transaksi.
12. Sistem mengubah rating aktor (pengembang/sponsor).
Alternative flow :
4.1. Aplikasi belum memenuhi standar kualitas.
1. Sistem menampilkan status aplikasi belum memenuhi standar kualitas dan
keterangan kekurangannya.
2. Kasus penggunaan menuju ke langkah 2.
12.1. kode transaksi tidak ada dalam rekening.
1. Kasus penggunaan menuju ke langkah 11.
Exception :
-
Includes :
-
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 16 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
17. Priority :
High
Frequency of use
High
Business Rule :
-
Special
-
Requirement :
Assumption :
-
Notes and Issues :
-
3.2.4.2 Diagram Aktivitas Melelang Aplikasi
Diagram D04 diagram aktivitas melelang aplikasi
pengembang
sponsor
memilih pilihan mulai melelang
sistem
PayPal
menampilkan persyaratan
mengisi persyaratan
menjalankan kasus penggunaan menilai aplikasi
sudah memenuhi standar
belum memenuhi standar
menampilkan status belum memenuhi standar
memilih pilihan penawaran aplikasi
mengisi form penawaran aplikasi
membuka forum lelang
menampilkan form penawaran aplikasi
jangka waktu lelang habis
jangka waktu lelang masih ada
menutup forum lelang
mengirim alamat rekening PayPal
memasukkan track record transaksi
mengubah rating
3.2.5 Kasus Penggunaan Menilai Aplikasi
3.2.5.1 Skenario Menilai Aplikasi
Tabel T08. Skenario menilai aplikasi
Use Case ID
UC4
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 17 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
18. Use Case Name
Menilai aplikasi
Created by
Last updated by
Date created
06-06-2013
Date last updated
06-06-2013
Actors :
Penilai
Description :
Kasus penggunaan ini berfungsi untuk menyeleksi aplikasi mobile phone yang
lolos standar kualitas sesuai dengan standar pasar masing-masing jenis. Proses
penilaian dilakukan tim penilai dibantu sistem lain yang independen dan memiliki
pengalaman membangun aplikasi mobile phone sesuai bidangnya. Proses ini
mirip dengan proses penilaian yang ada pada ovi store/ android market/dsb.
Waktu penilaian tergantung dari jumlah penilai, namun waktu penilaian maksimal
adalah 1 minggu (5 hari kerja). Hasil dari penilaian berupa rekomendasi dan
pemberitahuan kesalahan pembuatan.
Trigger :
pengembang mendaftarkan aplikasi ke pelelangan dan ditampilkan oleh sistem
dalam bentuk daftar aplikasi yang akan dinilai
Preconditions :
Aplikasi full version sudah diunggah
Postcondition :
Hasil penilaian dan rekomendasi dalam format .pdf serta keputusan lolos atau
tidaknya aplikasi yang dinilai
Normal flow
1. Aktor membuka menu daftar aplikasi yang akan dinilai.
2. Sistem menampilkan daftar aplikasi yang akan dinilai sesuai urutan waktu.
3. Aktor men-download aplikasi.
4. Aktor memilih menu mengunggah hasil penilaian.
5. Sistem menampilkan form pengunggahan penilaian yang terdiri dari:
-
Tombol unggah dokumen dalam format .pdf
-
Tombol pilihan diterima atau tidak
6. Aktor mengisi form pengunggahan penilaian.
7. Sistem mengirim hasil penilaian pada kasus penggunaan melelang aplikasi.
Alternative flow :
-
Exception :
-
Includes :
-
Priority :
High
Frequency of use
High
Business Rule :
-
Special
-
Requirement :
Assumption :
-
Notes and Issues :
-
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 18 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
19. 3.2.5.2 Diagram Aktivitas Menilai Aplikasi
Diagram D05 diagram aktivitas menilai aplikasi
penilai
sistem
membuka menu daftar aplikasi yang dinilai
menampilkan daftar aplikasi
download aplikasi
memilih menu mengunggah nilai
menampilkan form pengunggahan nilai
mengisi form pengunggahan nilai
mengirim hasil pada kasus penggunaan melelang aplikasi
3.2.6 Kasus Penggunaan Mengunggah Informasi
3.2.6.1 Skenario Mengunggah Informasi
Tabel T09. Skenario mengunggah informasi
Use Case ID
UC5
Use Case Name
Mengunggah informasi
Created by
Last updated by
Date created
06-06-2013
Date last updated
06-06-2013
Actors :
Admin, pengembang, sponsor, peninjau
Description :
Kasus penggunaan ini adalah layanan tambahan pada BidMe. Meskipun
demikian, kasus penggunaan mengunggah informasi termasuk ke dalam
kebutuhan fungsional karena setiap ada pembukaan lelang, admin mengunggah
pengumuman forum lelang yang menjadi portal link yang bisa diakses publik. Hal
ini digunakan untuk mengetahui pengguna yang mengakses forum (untuk alasan
kemudahan identifikasi transaksi). Selain itu layanan ini disediakan agar dapat
menyediakan sarana berbagi ilmu antar pengguna. Bentuk informasi yang
diunggah adalah thread di dalam forum dan dilengkapi dengan form komentar.
Informasi dapat berupa tutorial, pertanyaan, maupun pengumuman. Oleh karena
itu jika pengembang menemukan kesulitan dalam membangun aplikasi maka ia
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 19 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
20. bisa menjadikan kasus penggunaan ini sebagai tempat berdiskusi. Thread yang
diunggah ke forum akan ditampikan dalam urutan tertentu, diantaranya,
berdasarkan waktu, berdasarkan kepadatan aktivitasnya(jumlah komentar, jumlah
yang setuju/tidak setuju terhadap informasi, rating informasi), tingkat
kepentingan(informasi yang dikunci pada urutan teratas, hanya bisa dilakukan
oleh admin), kategori informasi, atau sesuai track record pengunggah.
Trigger :
Aktor masuk ke dalam forum diskusi
Preconditions :
Informasi belum diunggah
Postcondition :
Informasi menjadi thread baru dalam forum
Normal flow
1.
Aktor memilih menu mengunggah informasi.
2.
Sistem menampilkan form pengunggahan informasi yang terdiri dari:
- Isi informasi
- Daftar pengguna yang dipanggil (summoned)
- Kategori informasi
3.
Aktor mengisi form pengunggahan informasi.
4.
Sistem menampilkan daftar informasi terbaru.
Alternative flow :
-
Exception :
-
Includes :
-
Priority :
Medium
Frequency of use
High
Business Rule :
-
Special
-
Requirement :
Assumption :
-
Notes and Issues :
-
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 20 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
21. 3.2.6.2 Diagram Aktivitas Mengunggah Informasi
Diagram D06 diagram aktivitas mengunggah informasi
aktor
sistem
memilih menu mengunggah informasi
menampilkan form pengunggahan informasi
mengisi form pengunggahan informasi
menampilkan daftar informasi terbaru
3.2.7 Kasus Penggunaan Berdiskusi dalam Chatroom
3.2.7.1 Skenario Berdiskusi dalam Chatroom
Tabel T10. Skenario berdiskusi dalam chatroom
Use Case ID
UC6
Use Case Name
Berdiskusi dalam chatroom
Created by
Last updated by
Date created
06-06-2013
Date last updated
06-06-2013
Actors :
pengembang, sponsor, peninjau
Description :
Kasus penggunaan ini adalah layanan tambahan pada BidMe. Layanan ini masuk
menjadi kebutuhan fungsional karena setiap proses penawaran lelang secara
otomatis sistem akan menduplikasi penawaran dalam bentuk pesan di dalam
chatroom dan mengirim ke pengembang. Hal ini bertujuan untuk memudahkan
pengembang untuk mengetahui sponsor yang menawarkan harga lelang. Selain itu
layanan ini disediakan agar aktor dapat berdiskusi terkait hal yang lebih
privat(transaksi, tutorial pribadi, penawaran harga) pada aktor lain. Kasus
penggunaan ini merupakan bentuk lain dari layanan pengiriman surat elektronik
yang disediakan BidMe. Pesan chatroom akan terhapus secara otomatis ketika
semua anggota memilih keluar chatroom.
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 21 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
22. Trigger :
Aktor memilih menu membuat chatroom.
Preconditions :
Chatroom belum terbentuk
Postcondition :
Adanya diskusi dalam chatroom baru
Normal flow
1.
Aktor memilih menu membuat chatroom.
2.
Sistem menampilkan form chatroom yang terdiri dari:
- Daftar pengguna yang dipanggil (summon)
- Isi pesan
3.
4.
Sistem menampilkan pesan chatroom terbaru dan form balasan pesan.
5.
Aktor membalas pesan.
6.
Alternative flow :
Aktor mengisi form chatroom.
Aktor memilih pilihan keluar chatroom.
5.1. Aktor menolak ajakan chatroom
1. Sistem menampilkan status aktor menolak bergabung pada chatroom.
2. Kasus penggunaan menuju ke langkah 6.
Exception :
-
Includes :
-
Priority :
Medium
Frequency of use
High
Business Rule :
-
Special
-
Requirement :
Assumption :
-
Notes and Issues :
-
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 22 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
23. 3.2.7.2 Diagram Aktivitas Berdiskusi dalam Chatroom
Diagram D07 diagram aktivitas berdiskusi dalam chatroom
aktor
sistem
memilih menu membuat chatroom
mengisi form chatroom
menolak
keluar
menampilkan form chatroom
menampilkan pesan chatroom dan form balasan
menampilkan status penolakan bergabung
melanjutkan diskusi
membalas pesan
memilih keluar chatroom
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 23 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
24. 3.2.8 Context Diagram
Diagram D08 Context Diagram
act Proj ect Model
laporan rincian belum lengkap
alamat rekening
informasi
peninjau
pengembang
komentar
pesan
profil aplikasi
rincian aplikasi
aktivasi
informasi
melakukan
pelelangan
aplikasi
pengumuman
admin
pesan
dokumen nilai
track record
aplikasi
pesan informasitawaran
penilai
sponsor
Jurusan Teknik Informatika ITS
PayPal
SKPL-G03
Halaman 24 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
25. 3.2.8.1 DFD Level 1
Diagram D09 Data Flow Diagram Level 1
act Proj ect Model
aplikasi
rating
pesan
meninjau
aplikasi
profil aplikasi
profil aplikasi
informasi
peninjau
informasi
informasi
laporan rincian belum
lengkap
admin
mengunggah
informasi
profil aplikasi
komentar
pengumuman
nilai
mengunggah
aplikasi
rincian
aplikasi
pengembang
informasi
aktivasi
alamat rekening
informasi
pesan
sponsor
berdiskusi
dalam
chatroom
pesan
pesan
tawaran
PayPal
track record
penilai
melelang
aplikasi
data transaksi
nilai
dokumen nilai
aplikasi
chatroom
rating
data lelang
aplikasi
menilai
aplikasi
pengguna
Jurusan Teknik Informatika ITS
SKPL-G03
penawaran
transaksi
Halaman 25 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
26. 3.3
Data Requirement
3.3.1 E-R diagram
Diagram D06 ER-Diagram
transaksi
role
id_transaksi
<pi> Integer
<M>
alamatPayPal_transaksi
Variable characters (100)
tanggal_transaksi
Date & Time
harga_transaksi
Money
potongan_transaksi
Money
id_role
<pi> Integer
<M>
nama_role
Variable characters (100)
Identifier_1 <pi>
terdiri dari
user_role
Identifier_1 <pi>
memiliki
membeli
pengguna
id_pengguna
<pi> Integer
<M>
nama_pengguna
Variable characters (100)
alamat_pengguna
Text (200)
email_pengguna
Variable characters (100)
password_pengguna
Variable characters (50)
username_pengguna
Variable characters (50)
rating_pengguna
Integer
menjual
chatroom
penerima
pengirim
Identifier_1 <pi>
id_pesan
<pi> Integer
<M>
isi_pesan
Text (500)
tanggal_pesan
Date & Time
Identifier_1 <pi>
menawarkan
mengunggah
aplikasi
id_aplikasi
<pi> Integer
<M>
nama_aplikasi
Variable characters (100)
deskripsi_aplikasi
Text (500)
screenshoot_aplikasi
Image
hargaAwal_aplikasi
Money
urlVideo_aplikasi
Variable characters (100)
status_aplikasi
Integer
rating_aplikasi
Integer
source_aplikasi
Variable multibyte (51200000)
batasRating_aplikasi
Integer
informasi
id_informasi
<pi> Integer
<M>
isi_informasi
Text (5000)
tanggal_informasi
Date & Time
Identifier_1 <pi>
memberikan
memiliki
Identifier_1 <pi>
komentar
id_komentar
<pi> Integer
<M>
isi_komentar
Text (500)
tanggal_komentar
Date & Time
menawar_harga
memberikan
Identifier_1 <pi>
penawaran
track_record
id_catatan
<pi> Integer
<M>
isi_catatan
Text (500)
tanggal_catatan
Date & Time
memiliki
id_penawaran
<pi> Integer
<M>
harga_penawaran
Money
catatan_penawaran
Text (500)
tanggal_penawaran
Date & Time
termasuk
Identifier_1 <pi>
Identifier_1 <pi>
platform
id_platform
<pi> Integer
<M>
nama_platform
Variable characters (100)
sdk_platform
Variable characters (100)
kategori
id_kategori
<pi> Integer
<M>
nama_kategori
Variable characters (100)
Identifier_1 <pi>
Identifier_1 <pi>
menggunakan
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 26 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
27. 3.4
Non Functional Requirement
Tabel T11. Kebutuhan non fungsional
SRS-Id
SRS-NF01
Parameter
Availability
Requirement
Jumlah ketersediaan akses aplikasi adalah 98% dalam waktu 360
hari.
SRS-NF02
Reliability
-
Kegagalan maksimal yang ditoleransi adalah 3% dari seluruh
kegiatan operasional.
-
Khusus untuk kasus penggunaan lelang aplikasi, toleransi
kesalahan maksimal adalah 1%.
SRS-NF03
Ergonomy
-
Memiliki warna dominan dan tidak termasuk warna yang
menyala (dalam satuan RGB) yang meliputi (255,255,0),
(255,0,0), (0,255,0), (0,0,255), (255,0,255), (0,255,255).
-
Menggunakan font yang tidak berkaki dan formal (Arial,
Calibri, Franklin, Verdana,Ttahoma, Microsoft Sans Serif).
-
Tata letak menu, isi halaman, rincian fungsi halaman, dan
widget harus konsisten pada semua halaman.
-
Rancangan tampilan komponen BidMe (tombol, text field,
link,warna, dsb) harus konsisten pada semua halaman.
SRS-NF04
Portability
Aplikasi ini harus dapat diakses skala internasional (toleransi
diberikan jika ada kebijakan suatu negara yang melarang akses
BidMe) dan perangkat teknologi yang memenuhi tabel T04 dengan
tipe:
-
Tablet
Memory
Komputer jinjing
SRS-NF05
Komputer
Telepon genggam
Memory yang dialokasikan untuk BidMe adalah tipe DDR3 dengan
ukuran 32 GB per 1000 orang aktif dalam waktu yang sama.
Pembagian memory khusus untuk komputasi basis data minimal 40%
kapasitas memory dan penambahan memory harus dilakukan jika
rata-rata penggunaan memory di atas 75%.
SRS-NF06
Response time
Response time maksimal yang ditoleransi tiap 1000 pengguna aktif
untuk kecepatan internet 384 KBps adalah 3 detik.
SRS-NF07
Security
-
Pada kasus penggunaan diskusi dalam chatroom, isi pesan harus
terenkripsi.
-
Login pengguna juga harus terenkripsi oleh aplikasi di sisi klien
dan server.
-
Jurusan Teknik Informatika ITS
Proses pengaksesan PayPal harus menggunakan Secure Socket
SKPL-G03
Halaman 27 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
28. SRS-Id
Parameter
Requirement
Layer (SSL) pada kasus penggunaan melelang aplikasi.
-
Harus menggunakan enkripsi AES-256.
-
Aplikasi full version hanya bisa diakses oleh penilai dan
pengembang yang mengunggah dan ada MoA hak paten untuk
melindungi pengembang.
SRS-NF08
-
Ada halaman FAQ terkait BidMe.
-
Ada informasi operasional manual BidMe.
-
Ada video contoh operasional alur kasus penggunaan.
Bahasa
-
Bahasa aplikasi yang digunakan adalah bahasa inggris.
komunikasi
-
Bahasa resmi aplikasi adalah bahasa inggris.
-
SRS-NF09
Understandability
BidMe menyediakan translator bahasa menggunakan API
Google Translate.
SRS-NF10
Identitas
Setiap layar harus mengandung logo BidMe
SRS-NF11
Modularity
Pembangunan BidMe harus dipecah minimal menjadi dua modul,
yaitu layanan pelelangan ( meliputi kasus penggunaan mengunggah
aplikasi, meninjau aplikasi, melelang aplikasi dan menilai aplikasi)
dan komunikasi (meliputi kasus penggunaan mengunggah informasi
dan diskusi dalam chatroom).
SRS-NF12
Separation of
BidMe harus dibangun dengan konsep MVC.
concern
3.5
Batasan Perancangan
BidMe memiliki beberapa keterbatasan sebagai berikut:
1.
Kecepatan akses BidMe dibatasi oleh kemampuan server dan layanan internet di sisi klien.
Kemampuan server dapat dimaksimalkan oleh penggunaan perangkat keras sesuai lingkungan
operasi yang didefinisikan Tabel T04. Untuk layanan internet di sisi klien disarankan menggunakan
layanan dengan kecepatan minimal 384 KBPS.
2.
Spesifikasi perangkat teknologi klien harus mengacu pada standar minimal Tabel T04.
3.
Tipe data aplikasi yang dapat dibaca terlampir pada kasus penggunaan.
4.
Rancangan tampilan dipengaruhi oleh browser yang digunakan di sisi klien. Untuk mengatasi
keterbatasan rancangan disarankan menggunakan versi browser minimal di antaranya Google
Chrome 25, Mozilla Firefox 19, Internet Explorer 10, dan Safari 6.
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 28 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
29. 3.6
Kerunutan (traceability)
3.6.1 Data Store vs E-R
Tabel T12. Tabel relasional Entitas
Data Store
Entity
Relasi
User_role
One to many
Komentar
One to many
Informasi
One to many
Aplikasi
One to many
Penawaran
One to many
Chatroom
One to many
Transaksi
One to many
Track_record
One to many
Komentar
One to many
Pengguna
Many to one
Chatroom
Pengguna
Many to one
Transaksi
Pengguna
Many to one
Pengguna
Many to one
Aplikasi
Many to one
Pengguna
Many to one
Kategori
Many to one
Platform
Many to one
Penawaran
One to many
Pengguna
Informasi
Penawaran
Aplikasi
3.7
Ringkasan Kebutuhan
3.7.1 Functional Requirement Summary
Tabel T13. Tabel ringkasan kebutuhan fungsional
SRS-Id
Description
SKPL-BIDME 1
Kebutuhan untuk mengunggah aplikasi sesuai dengan aturan yang disediakan
SKPL-BIDME 2
Kebutuhan untuk melakukan proses pelelangan aplikasi mulai dari pembukaan hingga
transaksi selesai dilakukan
SKPL-BIDME 3
Kebutuhan untuk mengunggah informasi forum lelang yang menjadi portal link
sehingga dapat diketahui publik
SKPL-BIDME 4
Sistem dapat memberikan fasilitas penilaian aplikasi sebelum diunggah untuk diuji
kelayakannya
SKPL-BIDME 5
Kebutuhan untuk meninjau aplikasi yang belum jadi guna mendapatkan masukan dari
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 29 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
30. SRS-Id
Description
pengguna
SKPL-BIDME 6
Kebutuhan untuk berkomunikasi secara private dan pengiriman pesan penawaran
harga lelang.
3.7.2 Non Functional Requirement Summary
Tabel T14. Tabel ringkasan kebutuhan non fungsional
SRS-Id
Description
SRS-NF01
Aplikasi harus bias diakses setiap saat.
SRS-NF02
Komputasi aplikasi tidak boleh keliru dalam mengelola.
SRS-NF03
Aplikasi harus nyaman dipandang dan menarik.
SRS-NF04
Aplikasi harus bisa diakses menggunakan smartphone, komputer, dan dapat diakses
dimanapun.
SRS-NF05
aplikasi harus bisa menampung banyak pengguna.
SRS-NF06
Aplikasi tidak boleh loading terlalu lama.
SRS-NF07
Aplikasi harus aman dari serangan hacker.
SRS-NF08
Aplikasi harus mudah dioperasikan dan dipahami, serta dilengkapi dengan petunjuk
penggunaan.
SRS-NF09
Bahasa yang digunakan pada aplikasi harus bisa dibaca oleh pengguna internasional
SRS-NF10
Harus ada logo BidMe yang selalu muncul untuk memperjelas identitas aplikasi.
SRS-NF11
Jika ada kerusakan satu layanan, layanan aplikasi lain harus tetap jalan.
SRS-NF12
Kode program aplikasi harus bias dipahami dengan cepat jika ada pengembangan
lebih lanjut.
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 30 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
31. LAMPIRAN
Skenario pelelangan aplikasi
Tabel T15. Tabel skenario pelelangan aplikasi
No
Gambar Ilustrasi
Deskripsi
1
Agus baru saja selesai membuat aplikasi
mobilephone. Namun dia bingung untuk
menjualnya karena daya beli masyarakat
Indonesia rendah dan mudah untuk dibajak.
Oleh karena itu Agus memutuskan untuk
melelang aplikasinya agar dibeli oleh sponsor
sehingga ia mendapatkan keuntungan yang lebih
besar.
2
Akhirnya Agus membuka website e-bidding
www.BidME.com. setelah login sebagai
pengembang, ia mengunggah aplikasinya ke
dalam forum lelang digital dan memposisikan
dirinya sebagai auctioneer. Dia menentukan
harga awal, batas penutupan lelang, deskripsi
lengkap aplikasi, screenshoot aplikasi, dan
menyetujui MoA (Memorandum of Agreement)
dengan penyedia layanan lelang sebagai pihak
ketiga dengan keuntungan 1% dari hasil lelang.
3
Setelah beberapa hari, banyak sponsor
BidMe.com tertarik dan melelang aplikasi
Agus. Untuk bisa melelang, sponsor cukup
menggunakan akun sponsor dan memposisikan
diri sebagai bidder. Bidder melelang dengan
harga yang diinginkan dan menambahkan
persyaratan jika diperlukan. Setiap ada bidder
yang melelang, situs akan memperbarui
halaman peringkat lelang secara otomatis tanpa
menunggu bidder memindah halaman sehingga
bidder tahu harga tertinggi saat ini.
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 31 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
32. 4
Pada BidMe.com, pada awal pengaturan lelang
Agus wajib menentukan batas catatan track
record negatif bidder yang diperbolehkan ikut
dalam proses lelang untuk kenyamanan
auctioneer. Meskipun demikian, auctioneer
tidak bisa mengubah tanggal penutupan lelang.
5
Setelah masa lelang ditutup, Agus menghubungi
bidder pemenang. Bidder pemenang ditentukan
oleh auctioneer sesuai kesepakatan kedua belah
pihak dan syarat-syarat yang ada. Komunikasi
dapat dilakukan melalui chatroom di
BidMe.com dengan mengirim pesan ke akun
bidder, atau menghubungi langsung melalui
telepon.
Penyedia
layanan
BidMe.com
memberikan alamat PayPal pada pengembang
untuk mengirimkan bagi hasilnya. Setelah uang
diterima, maka status aplikasi akan diperbarui.
6
Jika Agus melanggar salah satu aturan yang
disepakati, maka secara otomatis BidMe.com
akan menambah track record negatif pada akun
agus dan sebaliknya juga untuk bidder yang
tidak menaati kesepakatan. Proses pengiriman
aplikasi di luar tanggung jawab BidMe.com
karena dilakukan atas kesepakatan auctioneer
dan bidder. Namun melalui pihak ketiga,
BidMe.com memfasilitasi transaksi kedua belah
pihak dan memperbarui status barang setiap ada
perubahan sehingga dapat meminimalisir
kecurangan.
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 32 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
33. Metode Elisitasi
1.
Metode yang digunakan adalah wawancara,pengamatan sistem lain yang mirip, pembuatan prototipe untuk
beberapa kebutuhan dalam rangka pemberian gambaran yang jelas pada objek wawancara. Tabel T16
menjelaskan tentang hubungan metode elisitasi yang digunakan dengan metode ilmiah yang diajukan sesuai
pada bab referensi nomor 1.
Tabel T16. Aktivitas elisitasi.
No
1
2
3
4
5
6
2.
3.
tujuan aktivitas
mengidentifikasi kebutuhan pengguna yang relevan
diimplementasikan
menganalisis fitur yang ada pada tiap kelompok pengguna
dan mengelompokkan kebutuhan pengguna
mengidentifikasi kebutuhan pengguna tiap kelompok
berdiskusi dengan pemangku kepentingan untuk memastikan
kebenaran kelompok
memilih prioritas kebutuhan pengguna
berdiskusi untuk melakukan konfirmasi persetujuan semua
kebutuhan dan pengelompokan
Objek wawancara dipilih berdasarkan kriteria Human Factors Experts di HUSAT Research Centre,
Loughborough University, UK yang dijelaskan berikut:
a. pengguna primer: orang yang sering menggunakan sistem dan proses bisnisnya tergantung pada
sistem,
b. pengguna sekunder: orang yang menggunakan sistem namun intensitasnya menengah dan tidak
memiliki ketergantungan tinggi pada sistem,
c. pengguna tersier: orang yang tidak bersentuhan langsung dengan sistem namun mendapatkan efek
sistem.
Berdasarkan pengelompokan objek wawancara tersebut, tabel T17 menjelaskan profil masing-masing objek
wawancara yang menggunakan aplikasi sejenis.
Tabel T17. Objek wawancara.
Kriteria
Primer
Nama
Aldy Ahsandin
Sekunder
Maulidan Bagus
Tersier
4.
Aktivitas
- Wawancara
- Pengamatan sistem lain
- Prototyping bagian yang belum
ada pada sistem sejenis
- Wawancara
- Wawancara dalam bentuk
konfirmasi fitur
- Wawancara
- Wawancara
Sukma Arbianto
Profil
Founder CV Floogame Indonesia.
Pekerjaan yang dilakukan adalah melelang aplikasi
game yang dibuat. Pemasukan didapatkan dari
forum lelang tersebut sehingga intensitas
penggunaan tinggi.
Founder Maulidan.com.
Pekerjaan yang dilakukan saat ini adalah menerima
pemesanan pembuatan game. Sebelumnya, objek
wawancara cukup intensif pada forum pelelangan
game, namun karena jaringan dengan sponsor
semakin besar, maka kebutuhan utama lebih
dialihkan pada pemesanan pembuatan game
sponsor yang dikenalnya sebagian di forum lelang
game dan mengurangi porsi di forum lelang game.
Programmer CV Floogame Indonesia.
Tidak bersentuhan langsung dengan proses
pelelangan namun menerima efek dari proses
pelelangan online.
Daftar pertanyaan yang diajukan sebagai berikut:
a. Dari pengalaman Anda, bisa minta tolong dijelaskan peran anda dalam online ebidding system?
b. Apa definisi online ebidding system yang ada di dunia saat ini?
c. Proses bisnis yang ada pada online ebidding system untuk aplikasi seperti apa yang anda inginkan?
d. Objek yang dilelang pada online ebidding system contohnya apa saja?
e. Fitur-fitur/layanan yang disediakan pada online ebidding system?
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 33 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.
34. 5.
f. Kelebihan dan kekurangan online ebidding system yang saat ini ada itu apa saja?
g. Sebutkan kendala yang pernah Anda alami dalam melakukan proses bisnis pada online ebidding system!
h. Untuk pembuatan online ebidding system ke depan, masukan sistem ideal dan mampu direalisasikan itu
seperti apa?
Gambar 01 menjelaskan prototipe yang dibuat untuk kasus penggunaan mengunggah aplikasi. Prototyping
tidak dilakukan pada semua kasus penggunaan karena metode ini hanya bersifat menjelaskan fasilitas yang
tidak ada pada sistem pelelangan lain yang sejenis dan memudahkan visualisasi objek wawancara untuk
mengevaluasi.
(a)
(b)
(c)
(d)
Gambar 01. Prototipe kasus penggunaan mengunggah aplikasi
Jurusan Teknik Informatika ITS
SKPL-G03
Halaman 34 dari 34 halaman
Template dokumen ini dan informasi yang dimilikinya adalah milik Laboratorium Rekayasa Perangkat Lunak Jurusan Teknik
Informatika-ITS dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh Laboratorium Rekayasa
Perangkat Lunak Jurusan Teknik Informatika ITS.