Spesifikasi Kebutuhan Perangkat Lunak

Slides:



Advertisements
Presentasi serupa
PERANCANGAN PERANGKAT LUNAK (SOFTWARE DESIGN)
Advertisements

Analisis Kebutuhan Perangkat Lunak (software requirement analysis)
Proses-proses Perangkat Lunak
Rekayasa Perangkat Lunak dan Proses Software
Bab 6 PERANCANGAN PERANGKAT LUNAK
BAB 8 PENGUJIAN PERANGKAT LUNAK
Functional Requirements (FR) dan Non-Functional Requirements (NFR)
Implementation & Testing Eri Prasetyo Bahan Kuliah MM Sistem Informasi Sources : -Juha Roning, Marko Laakso, Ari takanen, Oulu university,
Software Requirement Specification
REKAYASA PERANGKAT LUNAK
Sasaran Menjelaskan apa yang dimaksud model proses
PENGANTAR REKAYASA PERANGKAT LUNAK I
Pengembangan PL Ahmat Adil.
Software Requirements Spefication (SRS)
SKPL Spesifikasi Kebutuhan Perangkat Lunak STMIK AMIKOM PURWOKERTO.
Penjelasan Tugas Kelompok Proyek Perangkat Lunak
Perencanaan Sistem.
BAB 5 SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
6 Managing Software Requirement Perancangan
PERANCANGAN PERANGKAT LUNAK
Pengembangan dan Perancangan Perangkat Lunak
Konsep & Prinsip Analisis
Perancangan Perangkat Lunak
Aktifitas Pengembangan Sistem
PEMODELAN PERANCANGAn
THE REQUIREMENTS ANALYSIS PHASE
Software Testing Pertemuan III.
REKAYASA PERANGKAT LUNAK
TEKNIK TESTING DAN STRATEGI TESTING
Managing Software Requirement 1
A NALISIS K EBUTUHAN DAN S PESIFIKASI P ERANGKAT L UNAK.
Pemodelan Analisis (Part 1) Pertemuan 5 Rekayasa Perangkat Lunak
Pemeliharaan Perangkat Lunak
PEMAHAMAN REKAYASA PERANGKAT LUNAK
Analisis Kebutuhan Software
REKAYASA PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
KONSEP & DEFINISI KEBUTUHAN PL
Spesifikasi Perangkat Lunak
DOKUMEN MUTU ISO 9001:2008.
BAB 1 PENGUJIAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Pengenalan Rekayasa Perangkat Lunak
PERANCANGAN PERANGKAT LUNAK ( PL )
Rekayasa Perangkat Lunak
STRATEGI PENGUJIAN SISTEM PERANGKAT LUNAK
TESTING DAN IMPLEMENTASI SISTEM
Software Requirement Specifications (SRS)
4 Managing Software Requirement Analisis Kebutuhan
Persyaratan Perangkat Lunak
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Testing dan Implementasi
REKAYASA PERANGKAT LUNAK
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Rekayasa Kebutuhan Software
Rekayasa Kebutuhan bagian 2 Pertemuan 4
Analisis Kebutuhan.
7. Realisasi produk 7.4 Pembelian Proses pembelian
ANALISIS KEBUTUHAN PERANGKAT LUNAK
Rekayasa Perangkat Lunak
Struktur dan fungsi pengolahan data
Testing dan Implementasi SI220A
REKAYASA PERANGKAT LUNAK
Model Waterfall dan Dokumen SKPL
ANALISIS KEBUTUHAN PERANGKAT LUNAK
Perancangan Sistem Informasi. Pengantar Sistem adalah sekumpulan elemen yang saling berkaitan dan saling mempengaruhi dalam melakukan kegiatan bersama.
Proses Rekayasa Kebutuhan
MODEL PROSES PERANGKAT LUNAK
Transcript presentasi:

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.

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.

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.

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.

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.

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.

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

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.

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.

Bisa diverifikasi (verifiable)  Bisa diperiksa dan dicek kebenarannya 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.

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.

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.

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

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).

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.

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.

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.

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.

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