gl01 spec pl - bid me - 5112201905

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

GL01

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 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




Daftar Halaman Perubahan

Halaman Revisi Halaman 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




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

dan Singkatan Keterangan

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




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 Merupakan gambar yang berisi layar aplikasi

1.4 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 Aturan Penomoran/Penamaan

Bab 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

penggunaan

Tiap kasus penggunaan yang ada dinamai dengan UCXX dengan XX adalah nomor urut kasus

penggunaan dalam dokumen.

1.5 Referensi

Dokumen-dokumen yang digunakan sebagai referensi dalam pembuatan SKPL ini adalah sebagai berikut:




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




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. (SKPL-BIDME 1) Mengunggah aplikasi.

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. (SKPL-BIDME 6) berdikusi dalam chatroom.

2.3 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:

Meninjau aplikasi pengembang dan memberikan penilaian.

5. 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.




Karakteristik pengguna dijabarkan dalam tabel berikut ini.

Tabel T03. Karakteristik pengguna

Kategori

Pengguna

Tugas Hak Akses ke aplikasi

Pengembang Membuka pelelangan 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 Memberitahu keuntungan sudah diterima Sistem luar (API PayPal)

2.4 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 DDR1/DDR2/DDR3 512




pengguna aktif dalam waktu

yang sama)

MB

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

-




3.2 Deskripsi Fungsional

3.2.1 Diagram Kasus Penggunaan

Diagram D01. Diagram kasus penggunaan

System

mengunggah aplikasi

melelang aplikasi

meninjau aplikasi

mengunggah informasi

berdiskusi dalam chatroom

pengembang

adminsponsor

peninjau

PayPal

menilai aplikasi

penilai

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




- 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 : -




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

menampilkan form rincian profil

mengisi form rincian profil

menyimpan aplikasi

tidak sesuai

sesuai

lengkap

tidak lengkap

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



Actors : peninjau




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


Business Rule : -

Special

Requirement :

-

Assumption : -





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



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




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 : -




Priority : High


Business Rule : -

Special

Requirement :

-

Assumption : -


3.2.4.2 Diagram Aktivitas Melelang Aplikasi

Diagram D04 diagram aktivitas melelang aplikasi

pengembang sponsor sistem PayPal

memilih pilihan mulai melelang menampilkan persyaratan

mengisi persyaratan

menjalankan kasus penggunaan menilai aplikasi

membuka forum lelangmemilih pilihan penawaran aplikasi

menampilkan form penawaran aplikasimengisi form penawaran aplikasi

menutup forum lelang

mengirim alamat rekening PayPal

memasukkan track record transaksi

mengubah rating

menampilkan status belum memenuhi standar

belum memenuhi standar

sudah memenuhi standar

jangka waktu lelang masih adajangka waktu lelang habis

3.2.5 Kasus Penggunaan Menilai Aplikasi

3.2.5.1 Skenario Menilai Aplikasi

Tabel T08. Skenario menilai aplikasi

Use Case ID UC4




Use Case Name Menilai aplikasi



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


Business Rule : -

Special

Requirement :

-

Assumption : -





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

menampilkan form pengunggahan nilaimemilih menu mengunggah 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



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




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


Business Rule : -

Special

Requirement :

-

Assumption : -





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



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.




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. Aktor mengisi form chatroom.

4. Sistem menampilkan pesan chatroom terbaru dan form balasan pesan.

5. Aktor membalas pesan.

6. Aktor memilih pilihan keluar chatroom.

Alternative flow : 5.1. Aktor menolak ajakan chatroom

1. Sistem menampilkan status aktor menolak bergabung pada chatroom.


Exception : -

Includes : -

Priority : Medium


Business Rule : -

Special

Requirement :

-

Assumption : -





3.2.7.2 Diagram Aktivitas Berdiskusi dalam Chatroom

Diagram D07 diagram aktivitas berdiskusi dalam chatroom

aktor sistem

memilih menu membuat chatroom menampilkan form chatroom

mengisi form chatroom menampilkan pesan chatroom dan form balasan

membalas pesan

menampilkan status penolakan bergabung

memilih keluar chatroom

menolak

melanjutkan diskusi

keluar




3.2.8 Context Diagram

Diagram D08 Context Diagram

act Project Model

peninjau

PayPal

admin

pengembang

penilai

sponsor

melakukan

pelelangan

aplikasi

pengumuman

dokumen nilai

aplikasi

komentar

informasi

pesanprofil aplikasi

track record

informasitawaran

pesan

alamat rekening

laporan rincian belum lengkap

pesan

informasi

aktivasi

rincian aplikasi




3.2.8.1 DFD Level 1

Diagram D09 Data Flow Diagram Level 1

act Project Model

pengembang

PayPal

sponsor

admin

penilai

peninjau

aplikasi

transaksipengguna penawaran

informasi

chatroom

mengunggah

aplikasi

melelang

aplikasi

berdiskusi

dalam

chatroom

meninjau

aplikasi

mengunggah

informasi

menilai

aplikasi

data lelang

rating

profi l aplikasi

profi l aplikasi

profi l aplikasi

komentar

aktivasi

rincian

aplikasi

laporan rincian belum

lengkap

tawaran

aplikasi

nilai

alamat rekening

track record

rating

data transaksi

pengumuman

nilai

dokumen nilai

aplikasi

informasi

informasi

informasiinformasi

pesan

pesan

pesan

pesan




3.3 Data Requirement

3.3.1 E-R diagram

Diagram D06 ER-Diagram

menawarkan

mengunggah

memberikanmemiliki

penerima

pengirim

memberikan menawar_harga

membeli

terdiri dari

memiliki

menjual

termasuk

menggunakan

memiliki

informasi

id_informasi

isi_informasi

tanggal_informasi

<pi> Integer

Text (5000)

Date & Time

<M>

Identifier_1 <pi>

aplikasi

id_aplikasi

nama_aplikasi

deskripsi_aplikasi

screenshoot_aplikasi

hargaAwal_aplikasi

urlVideo_aplikasi

status_aplikasi

rating_aplikasi

source_aplikasi

batasRating_aplikasi

<pi> Integer

Variable characters (100)

Text (500)

Image

Money


Integer

Integer

Variable multibyte (51200000)

Integer

<M>

Identifier_1 <pi>

chatroom

id_pesan

isi_pesan

tanggal_pesan

<pi> Integer

Text (500)

Date & Time

<M>

Identifier_1 <pi>

pengguna

id_pengguna

nama_pengguna

alamat_pengguna

email_pengguna

password_pengguna

username_pengguna

rating_pengguna

<pi> Integer


Text (200)




Integer

<M>

Identifier_1 <pi>

penawaran

id_penawaran

harga_penawaran

catatan_penawaran

tanggal_penawaran

<pi> Integer

Money

Text (500)

Date & Time

<M>

Identifier_1 <pi>

transaksi

id_transaksi

alamatPayPal_transaksi

tanggal_transaksi

harga_transaksi

potongan_transaksi

<pi> Integer


Date & Time

Money

Money

<M>

Identifier_1 <pi>

komentar

id_komentar

isi_komentar

tanggal_komentar

<pi> Integer

Text (500)

Date & Time

<M>

Identifier_1 <pi>

role

id_role

nama_role

<pi> Integer


<M>

Identifier_1 <pi>

user_role

track_record

id_catatan

isi_catatan

tanggal_catatan

<pi> Integer

Text (500)

Date & Time

<M>

Identifier_1 <pi>

kategori

id_kategori

nama_kategori

<pi> Integer


<M>

Identifier_1 <pi>

platform

id_platform

nama_platform

sdk_platform

<pi> Integer



<M>

Identifier_1 <pi>




3.4 Non Functional Requirement

Tabel T11. Kebutuhan non fungsional

SRS-Id Parameter Requirement

SRS-NF01 Availability 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:

- Komputer

- Komputer jinjing

- Tablet

- Telepon genggam

SRS-NF05 Memory 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




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 Understandability - Ada halaman FAQ terkait BidMe.

- Ada informasi operasional manual BidMe.

- Ada video contoh operasional alur kasus penggunaan.

SRS-NF09 Bahasa

komunikasi

- Bahasa aplikasi yang digunakan adalah bahasa inggris.

- Bahasa resmi aplikasi adalah bahasa inggris.

- 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

concern

BidMe harus dibangun dengan konsep MVC.

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.




3.6 Kerunutan (traceability)

3.6.1 Data Store vs E-R

Tabel T12. Tabel relasional Entitas

Data Store Entity Relasi

Pengguna

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

Informasi Komentar One to many

Pengguna Many to one

Chatroom Pengguna Many to one

Transaksi Pengguna Many to one

Penawaran Pengguna Many to one

Aplikasi Many to one

Aplikasi

Pengguna Many to one

Kategori Many to one

Platform Many to one

Penawaran One to many

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




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.




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.




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.




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 tujuan aktivitas Aktivitas

1 mengidentifikasi kebutuhan pengguna yang relevan

diimplementasikan

- Wawancara

- Pengamatan sistem lain

2 menganalisis fitur yang ada pada tiap kelompok pengguna

dan mengelompokkan kebutuhan pengguna

- Prototyping bagian yang belum

ada pada sistem sejenis

3 mengidentifikasi kebutuhan pengguna tiap kelompok - Wawancara

4 berdiskusi dengan pemangku kepentingan untuk memastikan

kebenaran kelompok

- Wawancara dalam bentuk

konfirmasi fitur

5 memilih prioritas kebutuhan pengguna - Wawancara

6 berdiskusi untuk melakukan konfirmasi persetujuan semua

kebutuhan dan pengelompokan

- Wawancara

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

3. Berdasarkan pengelompokan objek wawancara tersebut, tabel T17 menjelaskan profil masing-masing objek

wawancara yang menggunakan aplikasi sejenis.

Tabel T17. Objek wawancara.

Kriteria Nama Profil

Primer Aldy Ahsandin Founder CV Floogame Indonesia.

Pekerjaan yang dilakukan adalah melelang aplikasi

game yang dibuat. Pemasukan didapatkan dari

forum lelang tersebut sehingga intensitas

penggunaan tinggi.

Sekunder Maulidan Bagus 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.

Tersier Sukma Arbianto Programmer CV Floogame Indonesia.

Tidak bersentuhan langsung dengan proses

pelelangan namun menerima efek dari proses

pelelangan online.

4. 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?




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?

5. 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

gl01 spec pl - bid me - 5112201905

Technology