1 / 26

BAB 5 SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

BAB 5 SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK. Spesifikasi Perangkat Lunak (Software Requirements Spesification(SRS) adalah sebuah dokumen yg berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak,tanpa menjelaskn bagaimana hal tersebut dikerjakan oleh perangkat lunak.

larissa-keith
Download Presentation

BAB 5 SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BAB 5SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

  2. Spesifikasi Perangkat Lunak (Software Requirements Spesification(SRS) adalah sebuah dokumen yg berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak,tanpa menjelaskn bagaimana hal tersebut dikerjakan oleh perangkat lunak.

  3. Suatu SRS harus mencantumkan tentang deskripsi dgn lingkungannya. • Mencakup antar muka untuk perangkat keras,perangkat lunak,komunikasi dan pemakai. • SRS bisa terdiri dari banyak doku – mentasi yang saling melengkapi.

  4. Suatu SRS harus dapat : 1. Menguraikan definisi masalah 2. Menguraikan masalah dengan tepat dengan cara tepat pula. • Objektif SRS : 1. Persetujuan kerja dengan pelanggan 2. Daftar kebutuhan teknis yang harus dipenuhi perangkat lunak.

  5. Syarat pembentukan SRS: 1. Mudah diidentifikasi 2. Diuraikan dengan jelas,simple, sederhana dan concise (jelas,tidak ambiguous) 3. Bisa divalidasi dan bisa ditest. 4. Mampu untuk ditelusuri kembali.

  6. Hindari hal-hal berikut saat pembentukn SRS : 1. Over spesification (penjelasan berlebih dan berulang-ulang sehinga tidak jelas. 2. Tindakan unconcistency. 3. Ambiguity dalam kata atau kalimat 4. Menuliskan hal yang tidak bisa dilakukan.

  7. Dalam suatu SRS ada 2 aspek yang harus dilihat : 1. Fungsi 2. Non Fungsi • Fungsi  menjelaskan fungsi dari perangkat lunak(digunakan untuk apa keperluan apa),sifat dan datanya.

  8. Non Fungsi • Dependability a. Reliability b. Maintability c. Seccurity d. Integrity • Ergonomic • Performance • Constraint.

  9. Attribut suatu SRS : • Benar (correct)  Spesifikasi yang ditulis benar. • Tepat (precise)  Berpengaruh terhadap hasil perancangan dan pembuatan Software Requirement Design. • Unambiguouity  Setiap permintaan harus punya satu interpretasi atau hanya satu arti dalam satu kalimat.

  10. Lengkap  Jika dilihat dari 2 sudut pandang : a. Dokumen membuat Tabel Isi,nomor halaman,nomor gambar,nomor tabel. b. Tidak ada bagian yang hilang (to be define) dari tulisan.

  11. Bisa diverifikasi (verifiable)  Bisa diperiksa dan dicek kebenarannya. Setiap kebutuhan selalu dimulai dengan dokumen yang bisa diperiksa. • Konsisten  Nilai-nilai kebutuhan harus tetap sama baik dalam karakteristik maupun spesifik.

  12. Understandable  Dapat dimengerti oleh pemogram,analis sistem atau sistem engineer. • Bisa Dimodifikasi (Modifieable)  Bisa diubah-ubah dan pengubahannya sangat sederhana tetapi tetap konsisten dan lengkap.

  13. Dapat Ditelusuri (Traceable)  Jika ditelusuri harus tahu mana bagian yang diubah. • Harus dapat dibedakan bagian What (bagian spesifikasi) dan How (bagian yang menjelaskan What). • Dapat mencakup dan melingkupi seluruh sistem.

  14. Dapat melingkupi semua lingkungan operasional. • Bisa menggambarkan sistem seperti yang dilihat pemakai. • Harus dilokalisasi dengan coupling yaitu hubungan ketergantungan antara dua modul.

  15. Orang yang terlibat dalam SRS • Pemakai (User)  Yang mengoperasikan /menggunakan produk final dari perangkat lunak yang dibuat. • Client  Orang atau perusahaan yang mau membuat sistem (Yang menentukan).

  16. Sistem Analis(Sistem Engineer)  Yang biasa melakukan kontak teknik pertama dengan client. Bertugas menganalisis persoalan,menerima dan menulis requirement. • Software Engineer  Yang bekerja setelah kebutuhan perangkat lunak dibuat.

  17. Programmer  Menerima spesifikasi perancangan perangkat lunak, membuat kode dalam bentuk modul, menguji dan memeriksa modul. • Test Integration Group  Kumpulan orang yang melakukan test dan mengintegrasi modul.

  18. Maintenance Group  Memantau dan merawat performansi sistem perangkat lunak yang dibuat selama pelaksanaan dan pada saat modifikasi muncul. • Technical Support  Orang-orang yang mengelola pengembangan PL. • Staff & Clerical Work  Bertugas mengetik, memasukkan data dan membuat dokumen.

  19. Keberhasilan Pengembangan PL : • Ketelitian dari pembuatnya. • Kualitas dan spesifikasi perangkat lunak yang dihasilkan. • Integritas • Proses pembuatan yang mantap. • Mudah dikembangkan. • Jumlah versi yang tidak banyak.

  20. Ketelitian dari model pengembangan yang digunakan untuk meramal atribut perangkat lunak. • Efektivitas rencana test dan integrasi. • Tingkat persiapan untuk sistem perawatan (mempersiapkan pencarian bugs).

  21. Contoh Layout Doumen SRS • PENDAHULUAN 1.1. Tujuan 1.2. Ruang Lingkup 1.3. Defenisi 1.4. Referensi 1.5. Sistematika

  22. DESKRIPSI UMUM 2.1. Perspektif 2.2. Kegunaan 2.3. Karakteristik Pengguna 2.4. Batasan-batasan 2.5. Asumsi dan Ketergantungan

  23. SPESIFIKASI KEBUTUHAN 3.1. Kebutuhan Fungsional 3.1.1. Pendahuluan 3.1.2. Input 3.1.3. Proses 3.1.4. Output

  24. 3.2. Kebutuhan Antar Muka Eksternal 3.2.1. Antar Muka Pengguna 3.2.2. Antar Muka Perangkat Keras 3.2.3. Antar Muka Perangkat Lunk 3.2.4. Antar Muka Komunikasi 3.3. Kebutuhan Performansi, 3.4. Kendala Desain.

  25. 3.5. Atribut 3.5.1. Keamanan Sistem 3.5.2. Pemeliharaan. 3.6. Kebutuhan Lain 3.6.1. Database 3.6.2. Pengoperasian 3.6.3. Penyesuaian Tempat

  26. Terima Kasih ....

More Related