Gl01 spec pl - bid me - 5112201905

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

DAFTAR PERUBAHAN
Revisi

Deskripsi

A
B
C
D
E
F
G

INDEX
TGL

-

A

B

C

D

E

F

G

Ditulis
oleh
Diperiksa
oleh
Disetujui
oleh

Jurusan Teknik Informatika ITS

SKPL-G03

Halaman 2 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.

Daftar Halaman Perubahan
Halaman

Revisi


Halaman

SKPL-G03

Revisi



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


SKPL-G03



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


SKPL-G03



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:


SKPL-G03



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


SKPL-G03



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.







3.

Peninjau:


Meninjau aplikasi pengembang dan memberikan pendapat.







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.


SKPL-G03



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)


DDR3 32 GB (per 1000

SKPL-G03

DDR1/DDR2/DDR3 512


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
-


SKPL-G03



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


SKPL-G03



-

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 :

-


SKPL-G03



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


Date last updated

SKPL-G03

06-06-2013



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 :

-


SKPL-G03



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


SKPL-G03



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.
12.1. kode transaksi tidak ada dalam rekening.

Exception :

-

Includes :

-


SKPL-G03



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


SKPL-G03



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 :

-


SKPL-G03



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


SKPL-G03



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 :

-


SKPL-G03



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.


SKPL-G03



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.

Exception :

-

Includes :

-

Priority :

Medium

Frequency of use

High

Business Rule :

-

Special

-

Requirement :
Assumption :

-

Notes and Issues :

-


SKPL-G03



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


SKPL-G03



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


PayPal

SKPL-G03



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


SKPL-G03

penawaran

transaksi



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
Identifier_1 <pi>
terdiri dari

user_role

Identifier_1 <pi>
memiliki

membeli

pengguna
id_pengguna
<pi> Integer
<M>
nama_pengguna
alamat_pengguna
Text (200)
email_pengguna
password_pengguna
username_pengguna
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
deskripsi_aplikasi
Text (500)
screenshoot_aplikasi
Image
hargaAwal_aplikasi
Money
urlVideo_aplikasi
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
sdk_platform

kategori
id_kategori
<pi> Integer
<M>
nama_kategori
Identifier_1 <pi>

Identifier_1 <pi>
menggunakan


SKPL-G03



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.

-


Proses pengaksesan PayPal harus menggunakan Secure Socket

SKPL-G03



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.


SKPL-G03



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


SKPL-G03



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.


SKPL-G03



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.


SKPL-G03



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.


SKPL-G03



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?


SKPL-G03



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


SKPL-G03



Gl01 spec pl - bid me - 5112201905

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

Similar to Gl01 spec pl - bid me - 5112201905

Similar to Gl01 spec pl - bid me - 5112201905 (20)

More from Budi Raharjo

More from Budi Raharjo (13)

Gl01 spec pl - bid me - 5112201905