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. BatasanRancangan • 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

36. Contoh • Skenario SuksesUtama • Pengguna memilih untuk membeli saham • Sistem mendapatkan nama situs web daripengguna untuk melakukanperniagaan • Menetapkan Koneksi • Pengguna menelusuri dan membeli saham • Sistem penyadapan tanggapan dari situs dan memperbaharuiportofolio pengguna • Sistem menunjukkan portofolio pengguna yang baru

37. Contoh Alternatif • 2a: Sistem memberikan pesan kesalahan, meminta saran baru untuk situs, memberikan pilihan untuk membatalkan • 3a: Kegagalan web • 1-Sys laporan kegagalan untuk pengguna, kembalike langkah sebelumnya. • 2-Pengguna keluar atau mencoba lagi • 4a: crash Komputer • 4b: situs web tidak memberi pemberitahuan • 5a: situs web tidak mengembalikaninformasi yang dibutuhkan

38. Contoh 2 • Gunakan Kasus 2: Beli produk • Primer aktor: pembeli / pelanggan • Tujuan: membeli produk • Prekondisi: Pelanggan sudah login

39. Contoh 2 Skenario Utama• Pelanggan menelusuri dan memilih item • Pelanggan pergi ke kasir • Pelanggan mengisi pilihan pengiriman • Sistem menyediakan informasi harga penuh • Pelanggan mengisi informasi kartu kredit • Sistem mengotorisasi pembelian • Sistem menegaskan penjualan • Sistem mengirimkan email konfirmasi

40. Contoh 2 Alternatif • 6a: otorisasi kartu kredit gagal • Memungkinkan pelanggan untuk masuk kembali informasi • 3a: pelanggan Reguler • Sistem menampilkan terakhir 4 digit kartu kredit tidak ada • Meminta pelanggan untuk OK itu atau mengubahnya • Bergerak ke langkah 6

41. Contoh - Sebuah situs lelang • Gunakan Case1: Masukan item untuk lelang • Primer Aktor: Penjual • Prekondisi: Penjual telah login • Skenario Utama Sukses: • Penjual posting item (kategorinya, keterangan, image, dll) untuk lelang • Sistem menunjukkan harga masa lalu barang serupa kepada penjual • Sistem menentukan harga penawaran awal dan tanggal ketika lelang akan menutup • Sistem menerima item dan posting itu • Pengecualian Skenario: - 2 a) Tidak ada item terakhir dari kategori ini * Sistem memberitahu penjual situasi ini

42. Contoh - situs lelang • Gunakan Case2: Buatlah tawaran • Primer Aktor: Pembeli • Prekondisi: Pembeli telah login • Skenario Utama Sukses: • dan memilih beberapa itemPembeli pencarian atau menelusuri • Sistem menunjukkan peringkat penjual, tawaran awal, tawaran saat ini, dan tawaran tertinggi; meminta pembeli untuk melakukan penawaran • Pembeli menentukan harga penawaran, harga max tawaran, dan kenaikan • Sistem menerima tawaran; dana Blok dalam account penawar • Sistem update harga tawaran penawar lain di mana diperlukan, dan update catatan untuk item

43. Pengecualian Skenario: • - 3 a) Harga penawaran lebih rendah dari tertinggi saat ini • * Sistem penawar menginformasikan dan meminta untuk rebid • - 4 a) penawar yang tidak memiliki cukup dana dalam account-nya • * Sistem membatalkan tawaran, meminta user untuk mendapatkan lebih banyak dana

44. Contoh-situs lelang • Gunakan Case3: lelang Lengkap item • Primer Aktor: Sistem Lelang • Prekondisi: Tanggal terakhir untuk penawaran telah tercapai • Skenario Utama Sukses: • penawar tertinggi Pilih; mengirim email kepada penawar yang dipilih dan penjual menginformasikan harga penawaran akhir, mengirim email ke penawar lain juga penawar Debit dan kredit rekening penjual akun • Transfer dari jumlah komisi penjual rekening ke rekening organisasi • blok dana lainnya penawar • Hapus item dari situs; catatan pembaruan • Pengecualian Skenario: Tidak ada

45. Contoh - ringkasan tingkat Use Case • Gunakan Kasus 0: Lelang item • Primer Aktor: Sistem Lelang • Lingkup: Lelang organisasi melakukan • Prekondisi: Tidak ada • Skenario Utama Sukses: • Penjual melakukan menempatkan item untuk lelang • Berbagai bidder melakukan penawaran • Pada tanggal akhir Lengkapi melakukan lelang item • Dapatkan umpan balik dari penjual; mendapatkan umpan balik dari pembeli; memperbarui catatan

46. kebutuhan dengan Gunakan Kasus • UCS menentukan kebutuhan fungsional • req lain yang diidentifikasi secara terpisah • Sebuah SRS lengkap akan berisi kasus penggunaan ditambah kebutuhan lain • Catatan - untuk kebutuhan sistem adalah penting untuk mengidentifikasi UCS yang sistem sendiri mungkin aktor • Mengembangkan Gunakan Kasus • UCS membentuk media yang baik untuk brainstorming dan diskusi • Oleh karena itu dapat digunakan dalam elisitasi dan analisis masalah juga • UCS dapat dikembangkan dalam cara bertahap penyempurnaan • tingkat Banyak mungkin, tapi empat alami muncul

47. Mengembangkan • Langkah 1: Mengidentifikasi aktor dan tujuan Siapkan daftar aktor-tujuan • Memberikan gambaran singkat dari UC • ini mendefinisikan ruang lingkup sistem • Kelengkapan juga dapat dievaluasi • Langkah 2: Tentukan Sukses Skenario utama • Untuk setiap UC, memperluas skenario utama • ini akan memberikan perilaku normal dari sistem • Dapat terakhir untuk memastikan bahwa kepentingan semua pemangku kepentingan dan aktor terpenuhi

48. Mengembangkan • Langkah 3: Identifikasi kondisi kegagalan • kondisi kegagalan yang mungkin untuk UCSDaftar • Untuk setiap langkah, mengidentifikasi bagaimana mungkin gagal • Langkah ini menyingkap situasi khusus • Langkah 4: Tentukan penanganan kegagalan • Mungkin bagian paling sulit • Menentukan perilaku sistem untuk kondisi kegagalan • aturan bisnis baru dan aktor mungkin muncul

49. Pendekatan Analisis Lainnya

50. Data Flow Modeling • Banyak digunakan; berfokus pada fungsi yang dilakukan dalam sistem • Dilihat sistem sebagai jaringan data mengubah data melalui mana mengalir • Menggunakan diagram aliran data (DFD) dan dekomposisi fungsional dalam pemodelan • Metodologi SSAD menggunakan DFD untuk mengatur informasi, dan analisis panduan