Download - 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
Pada fase Inception:
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.
Pada fase Construction:
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 Inception:
Pada fase ini, bagian ini belum diisi.
Pada fase Elaboration:
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.
Pada fase Construction:
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 Inception:
Pada fase ini, bagian ini belum diisi.
Pada fase Elaboration:
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.
Pada fase Construction:
Bagian ini diisi dengan versi final identifikasi kelas analisis untuk setiap paket analisis. Lengkapi daftar perubahan jika terjadi perubahan.4.5 Deskripsi Arsitektur
Pada fase Inception:
Bagian ini belum diisi.
Pada fase Elaboration:
Bagian ini diisi dengan gambaran umum arsitektur perangkat lunak, mis. arsitektur client-server atau arsitektur aplikasi berbasis web.
Pada fase Construction:
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
Pada fase Elaboration:
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
Pada fase Elaboration:
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
Pada fase Inception:
Bagian ini belum diisi.
Pada fase Elaboration:
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
Pada fase Inception:
Bagian ini belum diisi.
Pada fase Elaboration:
Bagian ini belum diisi.
Pada fase Construction:
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
Pada fase Inception:
Bagian ini belum diisi.
Pada fase Elaboration:
Bagian ini belum diisi.
Pada fase Construction:
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
Pada fase Inception:
Bagian ini belum diisi.
Pada fase Elaboration:
Pada fase Construction:
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