Gl01 spec pl - bid me - 5112201905
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Gl01 spec pl - bid me - 5112201905

on

  • 730 views

 

Statistics

Views

Total Views
730
Views on SlideShare
709
Embed Views
21

Actions

Likes
0
Downloads
17
Comments
0

2 Embeds 21

http://neomushlih.wordpress.com 20
https://neomushlih.wordpress.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Gl01 spec pl - bid me - 5112201905 Document Transcript

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