DPPL-rpl BO

SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

DOKUMEN PEMBANGUNAN PERANGKAT LUNAK

SISTEM PEMBANTU PENYEBARAN INFORMASI MENGGUNAKAN SMS GATEWAYuntuk:

Dipersiapkan oleh:

Mikael Yudhi Priamuda 085314022

Fidelis Adi Wicaksono 095314002

Jeanot Nahasan Nida 095314019

Yoseph Dian Sahadewa 095314068

Program Studi Teknik Informatika Universitas Sanata DharmaYogyakarta

Program Studi

Teknik Informatika USDNomor DokumenHalaman

DPPL-DOC-20111/26

Revisi4Tgl: 22-11-2011

DAFTAR PERUBAHAN

RevisiDeskripsi

A

B

C

D

E

F

G

INDEX

TGL-ABCDEFG

Ditulis oleh

Diperiksa oleh

Disetujui oleh

Daftar Halaman Perubahan

HalamanRevisiHalamanRevisi

Daftar Isi51Pendahuluan

51.1Tujuan Penulisan Dokumen

51.2Lingkup Masalah

51.3Aturan Penomoran

51.4Referensi

51.5Deskripsi Umum Dokumen (Ikhtisar)

52Kebutuhan Perangkat Lunak

52.1Deskripsi Umum Sistem

52.2Fitur Utama Perangkat Lunak

52.2.1Kebutuhan Fungsional

62.2.2Kebutuhan Non Fungsional

62.3Spesifikasi Tambahan

72.4Glossary

73Model Use Case

73.1Diagram Use Case

73.2Definisi Actor

73.3Definisi Use Case

83.4Skenario Use Case

104Model Analisis

104.1Realisasi Use Case Tahap Analisis

104.2Diagram Kelas Keseluruhan

154.3Kelas Analisis

154.4Paket Analisis

164.4.1Identifikasi Paket Analisis

164.4.2Identifikasi Kelas Analisis tiap Paket

174.5Deskripsi Arsitektur

185Model Perancangan

185.1Realisasi Use Case Tahap Perancangan

185.2Diagram Kelas Keseluruhan

185.3Kelas Perancangan

195.3.1Operasi dan Atribut

205.3.2Algoritma/Query

205.3.3Diagram Statechart

205.4Perancangan Basis Data

205.5Perancangan Antarmuka

215.6Coding Standard dan Naming Convention

215.7Deployment Diagram

226Implementasi

226.1Implementasi Kelas

226.2Implementasi Basis Data

226.3Implementasi Antarmuka

247Pengujian

247.1Rencana dan Prosedur Pengujian

247.1.1Rencana Pengujian

247.1.2Prosedur Pengujian

247.2Kasus Uji

257.2.1Pengujian Use Case

257.3Defect dan Status Perbaikan

257.4Evaluasi Pengujian

268Lampiran

1 Pendahuluan1.1 Tujuan Penulisan Dokumen

Dokumen ini ditujukan kepada perusahaan software house yang akan membangun software ini sesuai dengan apa yang diperlukan. Tujuan dokumen ini untuk memberikan gambaran secara lebih detil kepada para stakeholder tentang apa dan bagaimana software pembantu penyebaran informasi.

1.2 Lingkup Masalah

Lingkup masalah yang akan diselesaikan oleh sistem yang akan dibuat meliputi penyebaran informasi dengan cepat dan akurat.

1.3 Aturan Penomoran

Bagian ini diisi dengan aturan penomoran yang digunakan dalam dokumen.1.4 Referensi

Project Charter dan Spesifikasi Kebutuhan Perangkat Lunak - Sistem Pembantu Penyeberan Informasi Menggunakan SMS Gateway

1.5 Deskripsi Umum Dokumen (Ikhtisar)

Dokumen berisi deskripsi umum dari sistem yang akan dibuat. Dokumen ditujukan kepada perusahaan software house yang akan membangun sistem ini. Diberikan juga detail dari sistem yang akan dibuat.

2 Kebutuhan Perangkat Lunak2.1 Deskripsi Umum Sistem

Software ini bergantung pada jaringan internet dan server dari provider seluler, dimana nantinya operator seluler ini yang akan meneruskan mengirim pesan ke nomor seluler member. Contoh kasus yang mirip adalah pengiriman sms pengiriman info polis dari Prudential. Penyebaran informasi hanya terbatas kepada member yang sudah terdaftar di dalam sistem.

2.2 Fitur Utama Perangkat Lunak- Mengelola data member

- Menyebarkan informasi via SMS Gateway/email

- Membuat kegiatan- Menetapkan peserta dari sebuah kegiatan2.2.1 Kebutuhan Fungsional2.2.1.1 SekretarisKodeKebutuhan Fungsional

SRS-F-1-001Mengelolah data member (menambah, mengedit dan menghapus)

SRS-F-1-002mengirimkan informasi

SRS-F-1-003cek konfirmasi

2.2.1.2 MemberKodeKebutuhan Fungsional

SRS-F-2-001Menerima informasi

SRS-F-2-002mengirim konfirmasi terkait informasi yang diterima

2.2.2 Kebutuhan Non FungsionalKodeKebutuhan Non-Fungsional

SRS-NF-001Melakukan lock screen saat standby

SRS-NF-002Sistem membutuhkan jaringan internet untuk mengirim data ke provider

2.3 Spesifikasi Tambahan

Pada fase Inception:

Bagian ini diisi dengan informasi tambahan mengenai setiap atau seluruh use case utama, terutama mengenai kebutuhan non fungsional.Pada fase Elaboration:

Bagian ini diisi dengan informasi tambahan mengenai setiap atau seluruh use case, terutama mengenai kebutuhan non fungsional. Apabila pada fase ini masih ada perbaikan, daftar perubahan harus dilengkapi.

Pada fase Construction:

Bagian ini diisi dengan informasi tambahan versi final mengenai setiap atau seluruh use case, terutama mengenai kebutuhan non fungsional. Apabila pada fase ini masih ada perbaikan, daftar perubahan harus dilengkapi.

2.4 Glossary


Bagian ini diisi dengan daftar istilah yang digunakan, terutama istilah yang spesifik terhadap domain problem.

Pada fase Elaboration:

Bagian ini diisi dengan daftar istilah yang digunakan, terutama istilah yang spesifik terhadap domain problem. Apabila pada fase ini masih ada perbaikan, daftar perubahan harus dilengkapi.


Bagian ini diisi dengan daftar istilah yang digunakan, terutama istilah yang spesifik terhadap domain problem. Apabila pada fase ini masih ada perbaikan, daftar perubahan harus dilengkapi.

3 Model Use Case

3.1 Diagram Use Case

3.2 Definisi Actor

Nama AktorDeskripsi Tugas

User (Sekretaris)Mengelolah data member (menambah, mengedit dan menghapus), cek konfirmasi dan mengirimkan informasi

MemberMenerima informasi, mengirim konfirmasi terkait informasi yang diterima

3.3 Definisi Use CaseNoUse CaseDeskripsi

1Mengelola data member(menambah,edit,hapus)Menambahkan daftar member yang bisa menerima pesan lewat sistem (sebagai resipien)

2Mengirimkan informasiMembuat dan mengirim pesan kepada member

3Cek konfirmasiMengecek member yang melakukan konfirmasi kehadiran terkait pesan

3.4 Skenario Use Case

1. Mengelola data member (menambah, mengedit dan menghapus)

Aktor

: User (sekretaris)

Pra Kondisi: sudah menjalankan aplikasi (masuk ke sistem)

Kondisi Akhir: data pada sistem berubah

Basic flow: (1) Membuka form home

(2) user Pilih menu Member pada form Home lalu membuka formTambahMember

(3) sistem menampilkan form tambahmember

(4) user Input data member yang baru pada formTambahMember

(5)simpan data

Alternatif Flow: (2) a. User memilih menu Member pada form Home untuk membuka formDaftarMember

b. sistem menampilkan table daftar member c. Pilih member yang akan diedit datanya kemudian klik tombol edit untuk membuka panel edit data

d. Melakukan pengeditan data

e. simpan data

(2) a. User memilih menu Memberr pada form Home untuk membuka

panelDaftarMember

b. sistem membuka panelEditMember c. Pilih member yang akan dihapus kemudian klik tombol hapus hingga muncul dialog konfirmasi hapus data

d. klik tombol YES

e. selesai

2. Mengirimkan informasi

Aktor

: User (sekretaris)

Pra Kondisi: user sudah masuk ke sistem

Kondisi Akhir: semua member yang ada pada list akan mendapatkan informasi

Basic flow: (1) user memilih menu Pesan pada Home (2) sistem membuka panelkirimPesan

(3) user menuliskan pesan di dalam kolom Pesan pada panelkirimPesan

(4) user memilih menekan tombol Resipien

(5) sistem menampilkan daftar Member (6) user memilih member yang akan menerima pesan

(7) klik tombol OK

(8) sistem kembali ke form kirimPesan

(9) klik tombol SEND pada form kirimPesan untuk mengirim pesan

(10) sistem menyimpan data pesan ke database logPesan

3. Cek Konfirmasi Aktor : User (sekretaris)

Pra Kondisi : Pesan sudah terkirim

Kondisi Akhir : Konfirmasi dari member ke user

Basic flow : (1) user memilih menu Cek Konfirmasi(2) sistem menampilkan panelCekKonfirmasi yang berisi data pesan

(3) sistem mengambil data pesan dari databasePesan

(4) user memilih pesan yang akan di cek konfirmasi kehadiran membernya lalu klik tombol Lihat penerima(5) sistem menampilkan table penerima pesan yang berisi nama member yang telah dikirimi pesan. 4 Model Analisis4.1 Realisasi Use Case Tahap Analisis

4.2 Diagram Kelas Keseluruhan

3. Cek konfirmasi

4.3 Kelas Analisis

NAMA KELASTANGGUNG JAWAB KELASATRIBUT

FORM HOME1. menampilkan menu kirim pesan, tambah member, edit member dan cek konfirmasi1. menu tambahMember2. menu editMember

3. menu kirimPesan4. menu cek konfirmasi

FORM TAMBAH MEMBER1. input data member1. button SAVE2. button CANCEL

3. textField namaMember

4. textField alamatMember

5. textField noHPMember

6. textField emailMember

FORM EDIT MEMBERMenampilkan daftar member1. button EDIT2. button HAPUS

3. buttoN BACK

4. checklist daftarMember

FORM EDIT DATA MEMBERMenampilkan detail data member1. button SAVE2. button CANCEL

FORM KIRIM PESANInput isi pesan1. textArea isiPesan2. textField subject

3. menu daftarResipien

FORM RESIPIENMenampilan daftar member1. button OK2. checkBOX selectAllMember

3. checklist daftarMember

4. namaMember

MEMBER 1. nama_member : string2. alamat_member : string

3. no_hp : string

4. alamat_email : string

5. Id_member : string

HAPUS MEMBERKontroler untuk menghapus member

TAMBAH MEMBERKontroler untuk menambah member baru

EDIT MEMBERKontroler untuk mengedit data member

PESAN

KIRIMKontroler untuk mengirim pesan (sms gateway)

DATABASE HANDLERKontroler untuk koneksi ke database

4.4 Paket Analisis

4.4.1 Identifikasi Paket Analisis


Pada fase ini, bagian ini belum diisi.


Jika perlu, pemaketan dapat dilakukan untuk menyederhanakan persoalan.

Bagian ini dapat diisi dengan daftar paket analisis dengan mengacu pada diagram use case. Satu atau lebih use case dapat digabung kedalam satu paket. Satu use case hanya boleh berada pada satu paket.

Contoh:

NoNama PaketUse Case Terkait

1.Paket Pengelolaan Informasi 1. Pengelolaan Informasi Pelanggan

2. Pengelolaan Informasi Pegawai

3. Pengelolaan Informasi Produk

Gambarkan pula diagram package, serta berikan uraian singkat mengenai diagram tersebut. Diagram package menggambarkan ketergantungan antar package. Lengkapi daftar perubahan jika terjadi perubahan.


Bagian ini diisi dengan daftar dan diagram paket analisis versi final. Daftar perubahan harus dilengkapi jika pada fase ini terjadi perubahan.

4.4.2 Identifikasi Kelas Analisis tiap Paket


Pada fase ini, bagian ini belum diisi.


Bagian ini diisi dengan hasil identifikasi kelas analisis untuk setiap paket analisis dengan mengacu pada skenario setiap use case. Sebuah kelas seharusnya tidak muncul di lebih dari satu paket. Jika sebuah kelas terlibat di dua use case yang berbeda paket, alokasikan kelas di salah satu paket. Hal ini akan menggambarkan ketergantungan antar paket.

Contoh:

NoNama PaketNama Kelas AnalisisJenis Kelas

(Boundary, Control, Entity)

1Paket xxx1.

2.

3.


Bagian ini diisi dengan versi final identifikasi kelas analisis untuk setiap paket analisis. Lengkapi daftar perubahan jika terjadi perubahan.4.5 Deskripsi Arsitektur


Bagian ini belum diisi.


Bagian ini diisi dengan gambaran umum arsitektur perangkat lunak, mis. arsitektur client-server atau arsitektur aplikasi berbasis web.


Bagian ini diisi dengan versi final dari arsitektur perangkat lunak. Lengkapi daftar perubahan jika terjadi perbaikan.

5 Model Perancangan

5.1 Realisasi Use Case Tahap Perancangan1. Mengelola data member

2. Mengirim informasi

3. cek Konfirmasi

Use Case Cek Konfirmasi :

5.2 Diagram Kelas Keseluruhan

5.3 Kelas PerancanganNoNama kelas perancanganNama kelas analisis

1FORM HOMEHome

2FORM TAMBAH MEMBERPanelTambahMember

3FORM EDIT MEMBER

FORM EDIT DATA MEMBERPanelEditMember

4

5FORM KIRIM PESANPanelKirimPesan

6FORM DAFTAR PESAN

FORM DATA CHECK PESANPanelCekKonfirmasi

7FORM RESIPIENResipien

8MEMBERMember

9HAPUS MEMBER

TAMBAH MEMBER

EDIT MEMBERcontrollerMember

11

12

13PESANPesan

14KIRIMcontrollerPesan

15DATABASE HANDLERDatabaseHandler

5.3.1 Operasi dan Atribut

a. Member

Nama OperasiVisibility

(private, public)Keterangan

Set MethodpublicSet method dari atribut yang dimiliki

get methodpublicGet method dari atribut yang dimiliki

isNamaValidpublicUntuk melakukan pengecekan nama, mengembalikan true jika sesuai ketentuan

isEmailMemberValidpublicUntuk melakukan pengecekan email, mengembalikan true jika sesuai ketentuan

isNoHpMemberValidpublicUntuk melakukan pengecekan no hp, mengembalikan true jika sesuai ketentuan

isAlamatMemberValidpublicUntuk melakukan pengecekan alamat, mengembalikan true jika sesuai ketentuan

Nama AtributVisibility

(private, public)Tipe

namaMemberprivateString

noHpprivateString

alamatMemberprivateString

alamatEmailprivateString

Nama OperasiVisibility

(private, public)Keterangan

Set MethodpublicSet method dari atribut yang dimiliki

get methodpublicGet method dari atribut yang dimiliki

Nama AtributVisibility

(private, public)Tipe

judulPesanprivateString

isiPesanprivateString

noPesanprivateInt[]

Pesan

5.3.2 Algoritma/QueryBagian ini hanya diisi untuk kerangka algoritma untuk proses-proses yang dianggap cukup penting. Implementasi skeleton code juga sudah dapat dilakukan untuk kelas-kelas yang terdefinisi pada bahasa pemrograman tertentu

Contoh:Nama Kelas:

Nama Operasi:

Algoritma: (Algo-xxx){Jika mengacu query tertentu, lengkapi tabel query di bawah}

Query

:No QueryQueryKeterangan

Q-xxxTuliskan fungsi dari querynya

5.3.3 Diagram Statechart

Bagian ini hanya diisi jika ada kelas yang kompleks. Perubahan status kelas tersebut harus digambarkan dalam bentuk diagram statechart.

5.4 Perancangan Basis Data


Bagian ini diisi ER Diagram dan rencana tabel relasional. Sebagai petunjuk, kelas-kelas entity yang akan diimplementasikan sebagai tabel dibuat ERD-nya.

5.5 Perancangan Antarmuka

* frame Login

* Form Home

* Form kirimPesan

* Form TambahMember

6 Implementasi

6.1 Implementasi KelasNoNama KelasNama File FisikNama File ExecutableProgrammer

1LoginLogin.javaJeanot

2Home UserHome.javaJeanot,Yudi

3Cek KonfirmasiPanelCekKonfirmasi.javaJeanot, Fidi

4Kirim PesanPanelKirimPesan.javaJeanot, Yudi

5Tambah MemberPanelTambahMember.javaJeanot, Yudi

6Timer awalProgressbar.javaFidi

7controller handlercontrollerHandler.javaJeanot

8controller : membercontrollerMember.javaYosi

9controller : pesandatabasePesan.javaYosi

10 Database : memberMember.javaJeanot, Yosi

11Database : pesanPesan.javaFidi, Yudi

6.2 Implementasi Basis Data


Bagian ini diisi dengan daftar tabel yang TELAH diimplementasikan. Misalnya dalam bentuk tabel berikut:

NoNama KelasNama TabeNama File SQLProgrammer

1Database MemberMembermember.sqlYosi, Fidi

2Database Pesan PesanPesan.sqlJeanot, Yudi

6.3 Implementasi Antarmuka




Bagian ini diisi dengan daftar implementasi antarmuka. Misalnya dalam bentuk tabel berikut:NoAntarmukaNama File Fisik Nama File Executable Programmer

7 Pengujian

7.1 Rencana dan Prosedur Pengujian7.1.1 Rencana Pengujian






Bagian ini diisi dengan rencana pengujian, misalnya dalam bentuk tabel berikut:

NoUnit Test/KelasPengujianJenis PengujianIdentifikasi

1Xxx1. Skenario normal

2. Skenario xxx (acu no.skenario)

3. Skenario yyy1. White Box

U-1-1U-1-2U-1-3

U-2-xxx

NoUse CasePengujianJenis PengujianIdentifikasi

1xxx1. Skenario normal

2. Skenario xxx (acu no.skenario)

3. Skenario yyy1. Black box

2. Black Box

3.U-1-xxx

U-1-xxx

U-1-xxx

U-2-xxx

7.1.2 Prosedur Pengujian






Bagian ini diisi dengan prosedur pengujian, misalnya persiapan pengujian, urutan pengujian yang harus dilakukan, dll.

Bagian ini diisi dengan prosedur pengujian versi final. Lengkapi daftar perubahan.7.2 Kasus Uji





Bagian ini diisi dengan kasus uji untuk setiap use case (dibuat subbab untuk setiap use case). Contohnya adalah sebagai berikut:

7.2.1 Pengujian Use Case

Identifikasi DeskripsiProsedur PengujianMasukanKeluaran yang DiharapkanKriteria Evaluasi HasilHasil yang DidapatKesimpulan

U-1-01Pengujian hasil pemasukan data pelanggan oleh operator Buka File data pelanggan

Cari rekord dengan data modus pemasukan yang diinginkan

Lihat tanggal lahir pelanggan

Lihat kode pelanggan

Bandingkan dengan rumus pembangkitan kode pelanggan

Kode modus pemasukan operator (01)01001

01002

01003

dst01 01

DPPL-rpl BO

Documents

Transcript of DPPL-rpl BO