Docstoc

1. Pendahuluan - Google Code

Document Sample
1. Pendahuluan - Google Code Powered By Docstoc
					                         GL01


SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK


                            MBS
            (Mobile Ticketing System)


                            untuk:
                 Penumpang Kereta Api




                      Dipersiapkan oleh:
                        Kelompok 06

         Farhan Nurfadeli                  105060801111004
         Gian Rofi Ferdyanto               105060807111043

         Ach. Ghozainul Alfa               105060807111103

               Jurusan Teknik Informatika

                       Fakultas Teknik

                  Universitas Brawijaya




                             Nomor Dokumen              Halaman
 Jurusan
 Teknik Informatika                                       1/20
 UB
                              GL01-G06
                         Revisi      <nomor revisi>   Tgl: 29/11/2011
                        DAFTAR PERUBAHAN
      Revisi                       Deskripsi
           A


           B


           C


           D


            E


            F


           G




 INDEX          -   A     B    C       D       E   F   G
  TGL

 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 ................................................................................................................................... 5
   1.5     Referensi .................................................................................................................................................. 5
   1.6     Deskripsi umum Dokumen (Ikhtisar) ...................................................................................................... 5
2     Deskripsi Umum Perangkat Lunak .................................................................................................................. 6
   2.1     Deskripsi Umum Sistem .......................................................................................................................... 6
   2.2     Fungsi Produk .......................................................................................................................................... 6
   2.3     Karakteristik Pengguna............................................................................................................................ 6
   2.4     Batasan .................................................................................................................................................... 7
   2.5     Lingkungan Operasi ................................................................................................................................ 7
3     Deskripsi Umum Kebutuhan ........................................................................................................................... 7
   3.1     Kebutuhan antarmuka eksternal .............................................................................................................. 7
      3.1.1     Antarmuka pemakai ......................................................................................................................... 7
      3.1.2     Antarmuka perangkat keras ............................................................................................................. 7
      3.1.3     Antarmuka perangkat lunak ............................................................................................................. 7
      3.1.4     Antarmuka komunikasi .................................................................................................................... 7
   3.2     Deskripsi Fungsional ............................................................................................................................... 7
      3.2.1     Context Diagram.............................................................................................................................. 7
        3.2.1.1       DFD Level 1 ............................................................................................................................ 7
   3.3     Data Requirement ................................................................................................................................... 8
      3.3.1     E-R diagram..................................................................................................................................... 8
   3.4     Non Functional Requirement ................................................................................................................... 8
   3.5     Batasan Perancangan ............................................................................................................................... 9
   3.6     Kerunutan (traceability) ........................................................................................................................... 9
      3.6.1     Data Store vs E-R ............................................................................................................................ 9
   3.7     Ringkasan Kebutuhan .............................................................................................................................. 9
      3.7.1     Functional Requirement Summary .................................................................................................. 9
      3.7.2     Non Functional Requirement Summary .......................................................................................... 9
      Flow map/Prosedur ........................................................................................................................................ 11
      SW Function Point ........................................................................................................................................ 11
      Lampiran lain yang dianggap perlu ............................................................................................................... 11

Setelah Daftar Isi Boleh ada Daftar Tabel dan atau Daftar Gambar
1. Pendahuluan
      Dokumen ini akan berisi Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau Software
Requirement Spesification (SRS) untuk MBS (Mobile Ticketing System) untuk pengguna
kereta api. Untuk penamaan dokumen ini selanjutnya akan digunakan istilah SPKL. Isi dari
dokumen ini sebagian besar adalah terjemahan dari dokumen IEEE Std 830-1993.

1.1   Tujuan Penulisan Dokumen
      Dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL) merupakan dokumen
spesifikasi kebutuhan perangkat lunak yang akan dikembangkan. Dokumen ini digunakan
oleh pengembang perangkat lunak sebagai acuan teknis pengembangan perangkat lunak pada
tahap selanjutnya.

1.2   Lingkup Masalah
      MBS (Mobile Ticketing System) adalah perangkat lunak dimana dalam sistem ini
terdapat satu misi untuk mempermudah dan memberikan kenyamanan kepada calon
penumpang kereta api dalam hal reservation ticket. Resevation ticket nantinya dapat diakses
dan dipesan via mobile melalui karakter yang dikirim dalam bentuk pesan singkat.
      Dari identifikasi software, dapat dilihat bahwa terdapat efisiensi waktu dan tenaga
dalam pemesanan tiket kereta api. Selain itu calon penumpang tidak perlu mengantri panjang
di loket- loket stasiun.

1.3    Definisi, Istilah dan Singkatan
       SPKL adalah Spesifikasi Kebutuhan Perangkat Lunak, atau dalam bahasa Inggris-nya
        sering juga disebut sebagai Software Requirements Spesification (SRS), dan
        merupakan spesifikasi dari perangkat lunak yang akan dikembangkan.
       DFD adalah Data Flow Diagram,diagram dan notasi yang digunakan untuk
        menunjukkan aliran data pada perangkat lunak.

1.4 Aturan Penomoran
Belum memiliki aturan penomoran.

1.5 Referensi
Referensi yang digunakan pada perangkat lunak ini adalah :
    Bayu Hendradjaya. Panduan Penulisan Spesifikasi Perangkat Lunak (SKPL). Jurusan
       Teknik Informatika ITB.
   

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

Jurusan Teknik Informatika                  SKPL – MBS                             Halaman 5 dari 20
Dokumen ini dan informasi yang dimilikinya adalah milik jurusan Teknik Informatika UB dan bersifat
rahasia. Dilarang untuk memperoduksi dokumen ini tanpa diketahui oleh Jurusan Teknik Informatika UB.
2 Deskripsi Umum Perangkat Lunak
2.1   Deskripsi Umum Sistem
      MBS (Mobile Ticketing System) adalah perangkat lunak dimana dalam sistem ini
terdapat satu misi untuk mempermudah dan memberikan kenyamanan kepada calon
penumpang kereta api dalam hal reservation ticket. Resevation ticket nantinya dapat diakses
dan dipesan via mobile melalui karakter yang dikirim dalam bentuk pesan singkat.
      Nantinya perangkat lunak ini dijalankan oleh sistem operasi server yang telah dimiliki.
Sekilas jalannya system ini adalah ketika calon penumpang mengetikkan karakter yang sesuai
dengan aturan yang ada pada database sistem maka system akan mengakses data dan mencari
sesuai dengan format sms yang dikirim calon penumpang. Setelah system menemukan
database yang diinginkan oleh calon penumpang maka system akan menyiman sementara data
yang ditemukan dalam memori system. Setelah itu data sementara yang tersimpan di dalam
memori akan dikirim balik ke nomor yang dikirim calon penumpang. Sehingga calon
penumpang bisa mengetahui data dan respon dari system.
      Gambar hubungan antar subsistem pada MBS adalah sebagai berikut :

            USER                                       SISTEM




                                                     DATABASE                   MEMORI


2.2   Fungsi Produk
      Bagian ini akan memberitahukan fungsi- fungsi yang dapat diakses oleh pemakai
perangkat lunak MBS, tetapi tidak dijelaskan secara spesifik. Untuk detail selengkapnya akan
dijelaskan pada bab 3. Adapun fungsi- fungsi yang dimiliki oleh perangkat lunak ini adalah :
     Melakukan pemesanan secara mobile dengan transaksi dan karakter tertentu[SKPL-
        MBS.K-001].
     Menampilkan informasi mengenai jadwal kereta api yang akan dipesan [SKPL-
        MBS.K-002].
     Menampilkan informasi mengenai ketersediaan kursi kosong dalam kereta api[SKPL-
        MBS.K-003].
     Menampilkan harga tiket kereta api yang akan dipesan [SKPL-MBS.K-004].

2.3   Karakteristik Pengguna
      Pengguna perangkat lunak ini adalah para calon penumpang kereta api yang ingin
melakukan pemesanan tiket kereta api via mobile.
      Pengguna disini hanya melakukan pemesanan dan menerima informasi mengenai
jadwal, harga dan ketersedian kursi kosong pada kereta api. Sedangkan administrator
mempunyai wewenang menampilkan informasi mengenai jadwal, harga dan ketersediaan
kursi kosong
     Kategori Pengguna                    Tugas             Hak Akses ke aplikasi
            User
2.4    Batasan
Batasan (jika ada), ketergantungan SW terhadap SW/HW sistem lain (misalnya modul Konsolidasi baru dapat
dijalankan ketika rekapitulasidata akuntansi dari Aplikasi AKUNT sudah dijalankan dan datanya dinyatakan
OK oleh petugas
Batasan yang harus dipakai. Misalnya :
 harus memakai file data dari Sistem lain (sebutkan),
 harus memakai format data yang sama dengan sistem lain
 harus berfungsi multi platform (di Windows dan linux)


2.5    Lingkungan Operasi
Operating system, DBMS, ...

Aplikasi Client server ini akan berfungsi dengan spesifikasi:
Server: ???
Client: ????
OS:
DBMS:


3 Deskripsi Umum Kebutuhan
3.1    Kebutuhan antarmuka eksternal
Hanya diisi jika Aplikasi memerlukan fasilitas khusus .

3.1.1 Antarmuka pemakai
User interface untuk mengoperasikan Perangkat Lunak : keyboard, mouse

3.1.2 Antarmuka perangkat keras
Hanya diisi jika perlu perangkat keras khusus, misalnya CARD XXX, CABLE XYZ

3.1.3 Antarmuka perangkat lunak
Hanya diisi jika PL memakai interface (berupa PL), misalnya API Windows.

3.1.4 Antarmuka komunikasi
Hanya diisi jika PL beroperasi di jaringan dan membutuhkan alat komunikasi khusus, misalnya RS232.


3.2    Deskripsi Fungsional
Awali dengan Context diagram dan sedikit penjelasan berupa narasi jika perlu

3.2.1 Context Diagram
Buat dan ceritakan Context diagram

3.2.1.1 DFD Level 1
Chapter- nya dapat dibuat dengan luwes. Awali dengan Context diagram dan sedikit penjelasan berupa narasi
jika perlu. Perhatikan kaidah perancangan :
- Pilih notasi sehingga proses yang didekomposisi atau tidak didekomposisi dapat dibaca dengan mudah
- Nama Bubble harus terdiri dari kata kerja dan kata benda
- Nama yang dipakai untuk Bubble, data store, dataflow harus konsisten (identitas perlu)
- Setiap level harus konsisten aliran datanya dengan level sebelumnya
- Usahakan agar external entity pada setiap level konsisten peletakannya
- Banyaknya bubble yang disarankan pada setiap level tidak melebihi 7 bubble
- Dekomposisi berdasarkan kelompok data lebih disarankan (memudahkan aliran data ke storage yang sama)
- Nama Proses yang umum hanya untuk bubble yang masih akan didekomposisi
- Nama Proses spesifik (Add, Update, Delete,Calculate, Compare, Merge, ..) pada CASE tools harus disertai
     dengan Pspec yang jelas walaupun Pspec tidak diprint di dokumen ini
-     Pada Proses yang sudah tidak didekomposisi, nama Proses dan nama Data harus sudah spesifik
-     Aliran ke storage harus melalui proses, tidak boleh langsung dari external entity
-     Aliran data untuk Proses “Report ..” : harus ada aliran keluar. Akan ada aliran masuk jika perlu
      parameter untuk mengaktifkan report
-     Aliran data yang tidak ada datastorenya harus diteliti, apakah memang tidak mencerminkan persisten entity
      (perlu disimpan dalam file/tabel) , yaitu kelak hanya akan menjadi “variabel” dalam program.

Dst sampai level terendah

3.3     Data Requirement
Uraikan dengan ringkas, data apa saja yang harus dikelola oleh aplikasi, disarikan dari semua kata benda yang
ada pada business process

3.3.1 E-R diagram
Gambar E-R diagram yang benar-benar konseptual, dengan VISIO. Minimal ada nama Entity, Relasi dan Key
(Skema relasi). Sudah dijelaskan apa bedanya E-R konseptual dengan Conceptual Data Model pada Case
Tools, karena E-R diagram ini tidak mungkin digambar dengan Case Tools. Keterbatasan CASE Tools biasanya
adalah:
- tidak mungkin mempunyai relasi dengan atribut non-key
- tidak mungkin mempunyai relasi bukan biner (terner, dan lebih tinggi)
sehingga akibatnya, relasi dijadikan “entity”. Kenapa E-R konseptual disarankan untuk digambar, adalah
karena E-R ini sebenarnya lebih mencerminkan abstraksi perancang


3.4     Non Functional Requirement
Uraikan dengan ringkas kebutuhan non fungsional dalam tabel sebagai berikut. Isilah Kolom Requirement
dengan kalimat yang jelas dan kelak dapat ditest untuk dipenuhi. SRS-Id adalah nomor requirement yang harus
ditelusuri pada saat test. Tuliskan N/A bila Not Applicable..

SRS-Id                Parameter            Requirement
                      Availability
                      Reliability
                      Ergonomy
                      Portability
                      Memory
                      Response time
                      Safety               N/A
                      Security

                      Others 1: Bahasa     Misalnya: semua tanya jawab harus dalam bahasa
                      komunikasi           Indonesia
                                           Setiap layar harus mengandung logo ITS


Catatan:
Availability: ketersediaan aplikasi, misalnya harus terus menerus beroperasi 7 hari perminggu, 24 jam per
haritanpa gagal
Reliability: keandalan, misalnya tidak pernah boleh gagal(atau kegagalan yang ditolerir adalah …%) sehingga
harus dipikirkan fault tolerant architecture. Biasanya hanya perlu untuk Critical Application yang jika gagal
akan berakibat fatal.
Ergonomy: kenyamanan pakai bagi pengguna
Portability: kemudahan untuk dibawa dan dioperasikan ke mesin/sistem operasi/platform yang lain
Memory: jika perhitungan kapasitas memori internal kritis (misalnya untuk SW yang harus dijadikan CHIPS
dan ukurannya harus kecil
Response time: Batasan waktu yang harus dipenuhi. Sangat penting untuk aplikasi Real Time. Contoh: “Aplikasi
harus mampu menampilkan hasil dalam 4 detik”, atau “ATM harus menarik kembali kartu yang tidak diambil
dalam waktu 30 detik”
Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem kontrol di pabrik
Security: aspek keamanan yang harus dipenuhi.
3.5    Batasan Perancangan
Sebutkan batasan design jika ada. Contoh : harus memakai library yang ada, harus memakai sepotong kode
yang sudah pernah dikembangkan, harus memperhatikan hal-hal tertentu


3.6    Kerunutan (traceability)
Diisi dengan tabel yang berisi traceability dari hasil analisis. Gunanya untuk menilai apakah hasil analisis
“runut” dan lojik. Untuik sementara, baru didefinisikan Data-store versus E-R.


3.6.1 Data Store vs E-R
Mapping data store pada DFD dengan Entity - Relasi

      Data Store                 Entity                      Relasi




3.7    Ringkasan Kebutuhan
Bab ini berisi ringkasan semua “Requirement item”. Requirement item ini mencerminkan semua hal yang harus
dipenuhi, dan nantinya akan menjadi arahan untuk tahapan testing, karena pada dasarnya, semua requirement
harus dapat ditest supaya dapat dibuktikan dipenuhi. Dibagi menjadi dua bagian: functional dan non functional


3.7.1 Functional Requirement Summary

      SRS-Id                                   Description




3.7.2 Non Functional Requirement Summary

      SRS-Id                                   Description
SRS-Id   Description
                                            LAMPIRAN
Flow map/Prosedur
Jika PL menyangkut prosedur manual, atau proses-proses manual


SW Function Point
Isilah tabel sebagai berikut, sehingga dari rancangan ini didapatkan gambaran “besarnya” ukuran aplikasi

       Item            Subitem                 Jumlah total                       Keterangan
Function (bubble    Entry/Update
yang tidak
didekomposisi
lagi)
                    Process
                    Delete
Proses              Level 1
                    Level 1.1
                    Level 2

Menu
DataSore            -
E-R                 Entity
                    Realsi




Lampiran lain yang dianggap perlu
Jika ada lampiran lain yang perlu disertakan, dan berhubungan dengan Analisis dan Perancangan

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:3
posted:3/16/2013
language:Unknown
pages:11