Analisis Kebutuhan dan Spesifikasi Perangkat Lunak

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.

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 kebutuhan berakhir dengan dokumen spesifikasi kebutuhan perangkat lunak (SRS) SRS menentukan apa yang harus dilakukan sistem yang diusulkan

Latar Belakang .. Sulitnya memahami kebutuhan Visualisasi sistem yang akan dibangun adalah sulit Kemampuan dari sistem yang akan dibangun tidak jelas, maka kebutuhan tidak jelas kebutuhan berubah sewaktu-waktu ... Penting untuk melakukan analisis dan spesifikasi kebutuhan yang tepat

Perlunya SRS 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

Perlunya SRS ... Membantu pengguna memahami keperluannya. pengguna tidak selalu tahu keperluan mereka harus menganalisis dan memahami potensi tujuannya adalah tidak hanya untuk mengotomatisasi sistem manual, tetapi juga untuk menambahkan nilai melalui TI Proses kebutuhan membantu memperjelas keperluan SRS menyediakan referensi untuk validasi dari produk akhir Pemahaman yang jelas tentang apa yang diharapkan. Validasi - “PL memenuhi SRS"

Perlunya SRS... SRS yang bermutu tinggi penting untuk PL yang bermutu tinggi Kesalahan kebutuhan akan diwujudkan 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.

Perlunya SRS ... SRS yang baik mengurangi biaya pengembangan Contoh Kesalahan SRS mahal untuk diperbaiki kemudian Perubahan kebutuhan memerlukan biaya besar (hingga 40%) SRS yang baik dapat meminimalkan perubahan dan kesalahan Penghematan substansial; upaya ekstra yang dihabiskan selama fase kebutuhan 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

Perlunya SRS... Contoh ... Setelah fase kebutuhan 65% kesalahan kebutuhan terdeteksi dalam perancangan, 2% dalam pemrograman, 30% dalam pengujian penerimaan, 3% selama operasi Jika 50 kesalahan kebutuhan tidak dihilangkan dalam fase kebutuhan, total biaya 32,5 * 5 + 1 * 15 + 15 * 50 + 1,5 * 150 = 1152 jam Jika 100 orang-jam tambahan diinvestasikan dalam fase kebutuhan untuk menangkap 50 cacat ini, maka biaya pembangunan bisa dikurangi dengan 1152 orang-jam Pengurangan bersih dalam biaya adalah 1052 orang-jam

Proses Kebutuhan Urutan langkah-langkah yang perlu dilakukan untuk mengubah keperluan pengguna menjadi SRS Proses ini harus menggali keperluan dan kebutuhan dan menetapkannya dengan jelas Kegiatan Dasar analisis masalah atau kebutuhan spesifikasi kebutuhan validasi Analisis melibatkan elisitasi/penggalian dan yang paling sulit

Proses Kebutuhan.. needs Analysis Specification Validation Requirements

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

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

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

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

Analisis Masalah ... Beberapa masalah Memperoleh informasi yang diperlukan Brainstorming: berinteraksi dengan klien untuk membahas sifat sistem yang diinginkan Pengaturan informasi, karena banyak informasi akan dikumpulkan Memastikan kelengkapan Memastikan konsistensi Menghindari rancangan internal

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

Karakteristik dari SRS Apa yang harus menjadi karakteristik SRS yang baik? Beberapa karakteristik utama Lengkap Tidak ambigu Konsisten Dapat diverifikasi Diberi peringkat untuk kepentingan dan/atau stabilitas

Karakteristik Kebenaran Kelengkapan Cukup jelas Setiap kebutuhan secara akurat mewakili beberapa fitur yang diinginkan dalam sistem akhir Kelengkapan Semua fitur yang diinginkan/karakteristik ditetapkan Paling sulit untuk dipenuhi Kelengkapan dan kebenaran sangat terkait Cukup jelas Setiap kebutuhan memiliki tepat satu arti Tanpa hal ini akan timbul banyak kesalahan Penting karena bahasa alami sering digunakan

Karakteristik Dapat diverifikasi Konsisten 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 prioritasi dalam konstruksi Untuk mengurangi risiko akibat perubahan kebutuhan

Komponen SRS Apa yang harus terdapat dalam SRS? Menjelaskan ini akan membantu memastikan kelengkapan Sebuah SRS harus menentukan kebutuhan Fungsi Kinerja Kendala rancangan Antarmuka eksternal

Kebutuhan Fungsional Inti dokumen SRS; ini membentuk sebagian dari spesifikasi Menetapkan semua fungsionalitas yang sistem harus dukung Keluaran atas masukan yang diberikan dan hubungan antara mereka Semua operasi yang akan dilakukan sistem Harus menetapkan perilaku untuk masukan yang tidak valid juga

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 (bisa diverifikasi) Misalnya waktu respon harus xx 90% dari waktu keseluruhan

Kendala Rancangan Faktor-faktor dalam lingkungan klien yang membatasi pilihan Beberapa batasan Standar kepatuhan dan kompatibilitas dengan sistem lain Keterbatasan Perangkat Keras Keandalan, toleransi kegagalan, kebutuhan cadangan. Keamanan

Antarmuka Eksternal Semua interaksi perangkat lunak dengan orang, perangkat keras, dan PL Antarmuka pengguna yang paling penting Ini juga harus bisa diverifikasi

Bahasa Spesifikasi Bahasa harus mendukung karakteristik SRS 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

Struktur dari SRS Pendahuluan Deskripsi keseluruhan Tujuan, sasaran dasar dari sistem Lingkup, apa yang sistem akan lakukan dan tidak lakukan Ikhtisar Deskripsi keseluruhan Perspektif Produk Fungsi Produk Karakteristik Pengguna Asumsi Kendala

Struktur dari SRS Kebutuhan khusus Kriteria Diterima Antarmuka eksternal Kebutuhan fungsional Kebutuhan kinerja Batasan rancangan Kriteria Diterima Sebaiknya ditentukan di depan. Standarisasi SRS ini dibuat oleh IEEE.

Pendekatan Use Case untuk kebutuhan Fungsional Pendekatan tradisional untuk spesifikasi fungsi- menentukan fungsi masing-masing Use case adalah teknik baru untuk menentukan perilaku (fungsi) Yakni hanya 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

Dasar Use Case Sebuah use case menentukan kontrak antara pengguna dan sistem tentang perilaku Pada dasarnya berbentuk tekstual; diagram hanya untuk mendukung Juga berguna dalam elisitasi kebutuhan karena pengguna menyukai dan memahami bentuk cerita dan bereaksi dengan mudah terhadap itu

Dasar Aktor: seseorang atau sebuah sistem yang berinteraksi dengan sistem yang diusulkan 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) Aktor dapat berupa orang atau sistem Aktor Primer: Aktor utama yang memulai UC UC adalah untuk memuaskan sasarannya Eksekusi yang sebenarnya dapat dilakukan oleh sistem atau orang lain atas nama aktor primer

Dasar Skenario: satu set tindakan yang dilakukan untuk mencapai tujuan pada beberapa kondisi Aksi ditentukan sebagai urutan langkah-langkah Langkah adalah tindakan logis yang lengkap dilakukan baik oleh aktor atau sistem Skenario sukses utama – bila sesuatu berjalan normal dan tujuan tercapai Skenario alternatif: Ketika sesuatu salah dan tujuan tidak dapat dicapai

Dasar Sebuah UC adalah kumpulan banyak skenario seperti itu Skenario mungkin menggunakan use case lain dalam langkah Tujuan sub-tujuan UC dapat dilakukan oleh UC lain UC dapat diatur secara hierarkis

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-hal itu memberikan gambaran Deskripsi bergaya cerita yang mudah dipahami oleh pengguna dan analis UC tidak membentuk SRS lengkap, hanya bagian fungsionalitasnya

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

Contoh Skenario Sukses Utama Pengguna memilih untuk membeli saham Sistem mendapatkan nama situs web daripengguna untuk perdagangan Menetapkan Koneksi Pengguna menelusuri dan membeli saham Sistem penyadapan tanggapan dari situs dan portofolio update pengguna Sistem menunjukkan stading pengguna portofolio baru

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, punggung sampai ke langkah sebelumnya. 2-Pengguna keluar atau mencoba lagi 4a: crash Komputer 4b: situs web tidak membeli ack 5a: situs web tidak kembali informasi yang dibutuhkan

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

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

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

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

Contoh - situs lelang Gunakan Case2: Buatlah tawaran Primer Aktor: Pembeli Prekondisi: Pembeli telah login Skenario Utama Sukses: dan memilih beberapa item Pembeli 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

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

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

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

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

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

Mengembangkan Langkah 3: Identifikasi kondisi kegagalan kondisi kegagalan yang mungkin untuk UCS Daftar 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

Pendekatan Analisis Lainnya

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

diagram aliran data Sebuah DFD menunjukkan aliran data melalui sistem Dilihat sistem sebagai transformasi input ke output Transformasi dilakukan melalui transformasi DFD menangkap bagaimana transformasi terjadi dari input ke output sebagai memindahkan data melalui transformasi Tidak terbatas pada perangkat lunak

aliran data diagram DFD Mentransformasi diwakili oleh lingkaran bernama / gelembung Bubbles dihubungkan dengan panah pada yang bernama perjalanan Data Sebuah persegi panjang merupakan sumber atau tenggelam dan pencetus / konsumen data (sering di luar sistem)

Contoh DFD

DFD Konvensi Eksternal file ditampilkan sebagai garis lurus berlabel Perlu untuk arus beberapa data dengan proses diwakili oleh * (sarana dan) ATAU hubungan diwakili oleh Semua proses dan anak panah harus dinamai Proses harus mewakili transformasi, panah harus mewakili beberapa data

aliran data diagram Fokus pada apa yang mentransformasikan terjadi, bagaimana mereka dilakukan adalah tidak penting Biasanya input utama / output ditampilkan, kecil diabaikan dalam pemodelan ini Tidak loop, berpikir bersyarat, ... DFD TIDAK peta kendali, tidak ada desain algoritmik / berpikir Sink / Source, eksternal file

Menggambar DFD

Jika terjebak, arah sebaliknya

Jika logika kontrol masuk, stop dan restart setiap panah dan gelembung Label Manfaatkan + & * Cobalah menggambar DFD alternatif Diratakan DFD: DFD dari sistem mungkin sangat besar Dapatkah mengatur itu secara hierarkis Mulailah dengan DFD tingkat atas dengan beberapa gelembung kemudian menarik DFD untuk setiap gelembung Pertahankan I / O saat "meledak"

Menggambar DFD untuk sistem Mengidentifikasi input, output, sumber, sink untuk sistem Cara kerja Anda secara konsisten dari input ke output, dan mengidentifikasi beberapa tingkat tinggi untuk menangkap mengubah transformasi penuh Jika terjebak, arah sebaliknya Ketika tingkat tinggi mengubah ditetapkan, maka masing-masing menyempurnakan mengubah dengan transformasi lebih rinci

Menggambar DFD untuk sistem Jangan pernah menampilkan logika kontrol, jika berpikir dalam hal loop / keputusan, berhenti & me-restart setiap panah dan gelembung; cermat mengidentifikasi input dan output dari masing- masing mengubah Label Manfaatkan + & * Cobalah menggambar DFD alternatif

diratakan DFD DFD dari sistem mungkin sangat besar Dapatkah mengatur itu secara hierarkis Mulailah dengan DFD tingkat atas dengan beberapa gelembung kemudian menarik DFD untuk setiap gelembung Pertahankan I / O saat "meledak" sebuah gelembung sehingga konsistensi diawetkan Membuat gambar diratakan DFD proses penyempurnaan top-down, dan memungkinkan pemodelan sistem yang besar dan kompleks

Kamus Data Dalam DFD panah diberi label dengan item data data kamus mendefinisikan data yang mengalir di DFD Menunjukkan struktur data, struktur menjadi lebih terlihat saat meledak Dapat menggunakan ekspresi reguler untuk mengekspresikan struktur data

Contoh Kamus DataUntuk DFD Timesheet Weekly_timesheet - employee_name + id + [regular_hrs + overtime_hrs] * Pay_rate = [jam | hari | mingguan] + dollar_amt Employee_name = terakhir + pertama + tengah Id = angka + digit + angka + digit

DFD menggambar - kesalahan umum berlabel data mengalir Data Hilang mengalir asing data mengalir Konsistensi tidak dipelihara selama perbaikan proses Hilang Terlalu rinci atau terlalu abstrak Berisi beberapa informasi kontrol

Prototyping Prototyping adalah pendekatan lain untuk analisis masalah Dibahas itu sebelumnya dengan proses - mengarah ke model proses prototyping

Prototyping kebutuhan Validasi Banyak ruang untuk kesalahpahaman memungkinkan Kesalahan Mahal untuk memperbaiki cacat req kemudian Harus mencoba untuk menghapus sebagian kesalahan dalam SRS Paling umum kesalahan Penghapusan - 30% Inkonsistensi - 10-30% - 10-30% Bahkan salah Prototyping Ambiguitas - 5 -20%

kebutuhan Tinjauan SRS terakhir oleh sekelompok orang Kelompok: penulis, klien, pengguna, dev tim rep. Harus termasuk klien dan pengguna Proses - proses pemeriksaan standar Efektivitas - bisa menangkap 40-80% dari req. kesalahan

Ringkasan Memiliki kualitas SRS yang baik sangat penting untuk Q & P req itu. fase memiliki 3 fase sub utama analisis, spesifikasi dan validasi Analisis untuk memahami masalah dan pemodelan Metode yang digunakan: SSAD, OOA, Prototyping Kunci sifat dari suatu SRS: kebenaran, kelengkapan, konsistensi, unambiguousness

Ringkasan Spesifikasi harus berisi fungsionalitas, performa, interface dan kendala desain Sebagian besar bahasa alami yang digunakan Gunakan Kasus adalah metode untuk menentukan fungsi, juga berguna untuk analisis Validasi - melalui review