Analisis K ebutuhan dan Spesifikasi Perangkat Lunak

1. Analisis Kebutuhan dan Spesifikasi Perangkat Lunak

2. Latar Belakang • Masalah skala merupakan isu kunci untuk PL • Untuk skala kecil, sangat mudah untuk memahami dan menentukan kebutuhan • Untuk skala besar - sangat sulit, mungkin merupakan yang paling sulit, paling bermasalah dan rawan. • Masukan: kebutuhan pengguna dalam pikiran orang lain. • Keluaran: Pernyataan yang tepat dari sistem yang diinginkan dan dibutuhkan.

3. Latar Belakang .. • Mengidentifikasi dan menetapkan kebutuhan (requirement) selalu melibatkan interaksi orang • Tidak bisa otomatis • Kebutuhan (IEEE) = Sebuah kondisi atau kemampuan yang harus dimiliki oleh sistem • Fase kebutuhanberakhir dengan dokumen spesifikasi kebutuhan perangkat lunak (SRS) • SRS menentukan apa yang harusdilakukansistem yang diusulkan

4. Latar Belakang .. • Sulitnya memahami kebutuhan • Visualisasi sistem yang akandibangunadalah sulit • Kemampuan dari sistem yang akandibanguntidak jelas, maka kebutuhan tidak jelas • kebutuhan berubah sewaktu-waktu • ... • Penting untuk melakukan analisis danspesifikasi kebutuhan yang tepat

5. PerlunyaSRS • SRS menetapkan dasar kesepakatan antara pengguna dan pemasok • Pengguna harus puas, tapi pengguna tidak dapat memahami perangkat lunak • Pengembang akan mengembangkan sistem, tetapi mungkin tidak tahu tentang masalah ranah • SRS adalah media untuk menjembatani kesenjangan tersebut. dan menentukan kebutuhan pengguna dengan cara yang baik dan bisa mengerti

6. PerlunyaSRS ... • Membantu pengguna memahami keperluannya. • pengguna tidak selalu tahu keperluan mereka • harus menganalisisdan memahami potensi • tujuannya adalah tidak hanya untuk mengotomatisasi sistem manual, tetapi juga untuk menambahkan nilai melalui TI • Proses kebutuhanmembantu memperjelas keperluan • SRS menyediakan referensi untuk validasi dari produk akhir • Pemahaman yang jelastentang apa yang diharapkan. • Validasi - “PL memenuhi SRS"

7. PerlunyaSRS... • SRS yang bermututinggi penting untuk PL yang bermututinggi • Kesalahan kebutuhan akandiwujudkan dalam PL akhir • untuk memenuhi tujuan mutu, harus dimulai dengan SRS bermutu tinggi • Cacat kebutuhan tidak sedikit • 25% dari semua cacat dalam satu kasus; 54% dari semua cacat yang ditemukan setelah pengujian unit • 80 cacat dalam A7 yang mengakibatkan permintaan perubahan • 500 / 250 cacat dalam SRS yang sebelumnya disetujui.

8. PerlunyaSRS ... • SRS yang baik mengurangi biaya pengembangan • Kesalahan SRS mahal untuk diperbaiki kemudian • Perubahan kebutuhanmemerlukanbiaya besar(hingga 40%) • SRS yang baik dapat meminimalkan perubahan dan kesalahan • Penghematan substansial; upaya ekstra yang dihabiskan selama fasekebutuhan menghemat upaya beberapa kali lipat • Contoh • Biaya untuk memperbaiki kesalahan dalam kebutuhan,perancangan, pemrograman, pengujian penyerahan dan operasi adalah 2, 5, 15, 50, 150 orang-bulan

9. PerlunyaSRS... • Contoh ... • Setelah fase kebutuhan65% kesalahankebutuhan terdeteksi dalam perancangan, 2% dalam pemrograman, 30% dalam pengujian penerimaan, 3% selama operasi • Jika 50 kesalahan kebutuhan tidak dihilangkan dalam fasekebutuhan, total biaya 32,5 * 5 + 1 * 15 + 15 * 50 + 1,5 * 150 = 1152 jam • Jika 100 orang-jam tambahan diinvestasikan dalamfasekebutuhanuntuk menangkap 50 cacatini, maka biaya pembangunan bisa dikurangi dengan 1152 orang-jam • Pengurangan bersih dalam biaya adalah 1052 orang-jam

10. Proses Kebutuhan • Urutan langkah-langkah yang perlu dilakukan untuk mengubah keperluanpengguna menjadiSRS • Proses iniharusmenggalikeperluandan kebutuhan dan menetapkannyadenganjelas • KegiatanDasar • analisis masalah atau kebutuhan • spesifikasi kebutuhan • validasi • Analisis melibatkan elisitasi/penggalian dan yang paling sulit

11. ProsesKebutuhan.. needs Analysis Specification Requirements Validation

12. Proses Kebutuhan .. • Proses ini tidak linier, hal ini berulang dan paralel • Tumpang tindih antara fase - beberapa bagian dapat dianalisis dan ditetapkan • Spesifikasi sendiri dapat membantu analisis • Validasi dapat menunjukkan kesenjangan yang dapat menyebabkan analisis lebih lanjut dan spesifikasi

13. Proses kebutuhan ... • Fokus analisis adalah pada pemahaman sistem yang diinginkan sertakebutuhannya • Membagi dan menaklukkan adalah strategi dasarnya • urai menjadi bagian-bagian kecil, fahami setiap bagian serta hubungan antara bagian-bagian • volume informasi yang dihasilkan besar • mengorganisasiinformasi adalah kunci • Teknik seperti diagram aliran data, diagram objek dll yang digunakan dalam analisis

14. kebutuhan Proses .. • Transisi dari analisis kespesifikasi sulit • dalam spesifikasi, perilaku eksternal yang ditentukan • selama analisis, struktur dan ranah dipahami • struktur analisis membantu dalam spesifikasi, namun transisitersebut belum final • metode analisis yang mirip dengan perancangan, tetapi tujuan dan ruang lingkup yang berbeda • analisis berkaitan dengan ranah masalah, sedangkan perancanganberkenaandengan ranah solusi

15. Analisis Permasalahan • Tujuan: untuk memperoleh pemahaman tentang keperluan, kebutuhan, dan batasanpada perangkat lunak • Analisis melibatkan • mewawancarai klien dan pengguna • membaca manual • mempelajari sistem saat ini • membantu klien/pengguna memahamikemungkinan-kemungkinan baru • Seperti menjadi konsultan • Harus memahami kerja dari klien, organisasi dan pengguna

16. Analisis Masalah ... • Beberapa masalah • Memperoleh informasi yang diperlukan • Brainstorming: berinteraksi dengan klien untuk membahassifat sistemyang diinginkan • Pengaturaninformasi, karenabanyak informasiakan dikumpulkan • Memastikan kelengkapan • Memastikan konsistensi • Menghindari rancanganinternal

17. Analisis Masalah ... • Masalah interpersonal penting • Keterampilan komunikasi sangat penting • Prinsip dasar: masalah partisi • Partisi • Objek - analisis berorientasiobjek • Fungsi - analisis struktural • Kejadian di sistem - partisi kejadian • Proyeksi - mendapatkan sudut pandang yang berbeda • Membahas beberapa teknik analisis yang berbeda

18. Karakteristik dari SRS • Apa yang harus menjadi karakteristik SRS yang baik? Beberapa karakteristikutama • Lengkap • Tidakambigu • Konsisten • Dapat diverifikasi • Diberi peringkat untuk kepentingan dan/atau stabilitas

19. Karakteristik • Kebenaran • Setiap kebutuhan secara akurat mewakili beberapa fitur yang diinginkan dalam sistem akhir • Kelengkapan • Semua fitur yang diinginkan/karakteristik ditetapkan • Paling sulituntuk dipenuhi • Kelengkapan dan kebenaran sangat terkait • Cukup jelas • Setiap kebutuhanmemiliki tepat satu arti • Tanpa halini akan timbulbanyakkesalahan • Pentingkarenabahasa alami sering digunakan

20. Karakteristik • Dapat diverifikasi • Harus ada cara yang efektif biaya untuk memeriksa apakah PL memenuhi kebutuhan • Konsisten • dua kebutuhan tidak bertentangan satu sama lain • Peringkat untuk kepentingan / stabilitas • Diperlukan prioritasidalam konstruksi • Untuk mengurangi risiko akibat perubahan kebutuhan

21. Komponen SRS • Apa yang harus terdapatdalamSRS? • Menjelaskan ini akan membantu memastikan kelengkapan • Sebuah SRS harus menentukan kebutuhan • Fungsi • Kinerja • Kendalarancangan • Antarmuka eksternal

22. Kebutuhan Fungsional • Intidokumen SRS; ini membentuk sebagian dari spesifikasi • Menetapkan semua fungsionalitasyang sistem harus dukung • Keluaranatas masukan yang diberikan dan hubungan antara mereka • Semua operasi yang akandilakukansistem • Harus menetapkan perilaku untuk masukanyang tidak valid juga

23. Kebutuhan Kinerja • Semua batasan (constraint) kinerja pada sistem perangkat lunak • Secara umum pada waktu respon, throughput, dll => dinamis • Kebutuhan kapasitas => statis • Harus dalam istilah terukur (bisadiverifikasi) • Misalnya waktu responharus xx 90% dari waktukeseluruhan

24. KendalaRancangan • Faktor-faktor dalam lingkungan klien yang membatasi pilihan • Beberapa batasan • Standar kepatuhan dan kompatibilitas dengan sistem lain • Keterbatasan Perangkat Keras • Keandalan, toleransi kegagalan, kebutuhancadangan. • Keamanan

25. Antarmuka Eksternal • Semua interaksi perangkat lunak dengan orang, perangkat keras, dan PL • Antarmuka pengguna yang paling penting • Ini juga harus bisadiverifikasi

26. Bahasa Spesifikasi • Bahasa harus mendukung karakteristikSRS yang diinginkan • Bahasa formal tepat dan jelas tapi sulit • Bahasa alami yang paling banyak digunakan, dengan beberapa struktur untuk dokumen • Bahasa formal digunakan untuk fitur khusus atau dalam sistem yang sangat kritis

27. Struktur dari SRS • Pendahuluan • Tujuan, sasarandasar dari sistem • Lingkup, apa yang sistem akanlakukandantidak lakukan • Ikhtisar • Deskripsi keseluruhan • Perspektif Produk • FungsiProduk • Karakteristik Pengguna • Asumsi • Kendala

28. Struktur dari SRS • Kebutuhan khusus • Antarmuka eksternal • Kebutuhan fungsional • Kebutuhan kinerja • Batasanrancangan • Kriteria Diterima • Sebaiknyaditentukan didepan. • Standarisasi SRS ini dibuatoleh IEEE.

29. Pendekatan Use Caseuntuk kebutuhan Fungsional • Pendekatan tradisional untuk spesifikasi fungsi- menentukan fungsi masing-masing • Use caseadalah teknik baru untuk menentukan perilaku (fungsi) • Yaknihanya berfokus pada spesifikasi fungsional • Meskipun terutama untuk spesifikasi, dapat digunakan dalam analisis dan elisitasi • Dapat digunakan untuk menentukan perilaku bisnis atau organisasi juga, meskipun kita akan fokus pada PL • Cocok untuk sistem interaktif

30. DasarUse Case • Sebuah use casemenentukankontrak antara pengguna dan sistem tentang perilaku • Pada dasarnya berbentuk tekstual; diagram hanya untuk mendukung • Juga berguna dalam elisitasi kebutuhan karenapengguna menyukaidan memahami bentuk cerita dan bereaksi dengan mudah terhadapitu

31. Dasar • Aktor: seseorang atau sebuah sistem yang berinteraksi dengan sistem yangdiusulkan untuk mencapai tujuan • Contoh : Pengguna ATM (tujuan: mendapatkan uang), data operator entri; (tujuan: melakukan transaksi) • Aktor adalah entitas logis, sehingga aktor penerima dan pengirim dibedakan (bahkan jika orangnya sama) • Aktordapat berupaorang atau sistem • AktorPrimer: Aktor utama yang memulai UC • UC adalah untuk memuaskan sasarannya • Eksekusi yang sebenarnya dapat dilakukan oleh sistem atau orang lain atas nama aktor primer

32. Dasar • Skenario: satu set tindakan yang dilakukan untuk mencapai tujuan padabeberapa kondisi • Aksiditentukan sebagai urutan langkah-langkah • Langkah adalah tindakan logis yang lengkap dilakukan baik oleh aktor atau sistem • Skenario suksesutama – bila sesuatu berjalannormal dan tujuan tercapai • Skenario alternatif: Ketika sesuatu salah dan tujuan tidak dapat dicapai

33. Dasar • Sebuah UC adalah kumpulan banyak skenario sepertiitu • Skenario mungkin menggunakanuse caselain dalam langkah • Tujuan sub-tujuan UC dapat dilakukan oleh UClain • UC dapat diatur secara hierarkis

34. Dasar • UC menentukan fungsi dengan menjelaskan interaksi antara aktor dan sistem • Fokus pada perilaku eksternal • UC terutama tekstual • UC diagram menunjukkan UC, aktor, dan ketergantungan • Hal-halitumemberikan gambaran • Deskripsi bergayacerita yang mudah dipahami oleh pengguna dan analis • UC tidak membentuk SRS lengkap, hanya bagian fungsionalitasnya

35. Contoh Use case 1: Beli saham Aktor Utama: Pembeli Tujuan pemangkukepentingan: Pembeli: ingin membeli saham Perusahaan: ingin informasi transaksi penuh Prakondisi: Pengguna sudah memiliki akun