Analisis Kebutuhan PL dan Spesifikasi PL Requirements

Latar Belakang Identifikasi dan penentuan kebutuhan perlu melibatkan interaksi dengan user(orang) Requirement (IEEE)= kondisi atau kemampuan yang harus dimiliki oleh sistem Fase Requirement menghasilkan dokumen software requirements specification (SRS) SRS menentukan apa yang harus dilakukan oleh sistem yang diusulkan Requirements

Requirements

Kebutuhan akan SRS SRS menghasilkan persetujuan antara user dan supplier. Kebutuhan User harus dipenuhi, tetapi seringkali user tidak mengerti tentang software Developer akan membuat sistem, tetapi seringkali tidak mengetahui mengenai problem domain SRS digunakan sebagai media untuk menjembatani gap komunikasi dan menentukan kebutuhan user dengan cara yang dapat dimengerti Requirements

Kebutuhan akan SRS Membantu user memahami kebutuhannya User tidak selalu mengetahui kebutuhannya Harus menganalisa dan mengerti hal-hal yang potensial Tujuan yang akan dicapai tidak hanya untuk otomasi sistem manual, tetapi juga menambahkan nilai melalui IT Proses requirement membantu menjelaskan kebutuhan yang ada SRS menyediakan reference untuk validasi produk akhir Requirements

SRS yang baik mengurangu biaya pengembangan Kebutuhan akan SRS SRS yang baik mengurangu biaya pengembangan SRS errors membutuhkan biaya yg mahal untuk perbaikan berikutnya Perubahan Req. Membutuhkan biaya banyak (sampai 40%) SRS yang baik dapat meminimalisir perubahan dan error Penghematan yang subtansial; usaha keras sepanjang penentuan req. Menghemat usaha bebepa kali lipat Requirements

Contoh Cost untuk perbaikan error pada req. , design , coding , acceptance testing and operation adalah 5 , 15 , 50 , 150 person-months Setelah fase req. 65% req errs terdeteksi pada design , 2% pada coding, 30% pada Acceptance testing, 3% pada operation Jika 50 requirement error tidak dihilangkan pada fase req. Hitunglah total cost ?? Requirements

total cost 32.5 *5 + 1*15 + 15*50 + 1.5*150 = 1152 hrs Jika 100 person-hours digunakan untuk memperbaiki 50 error tersebut, maka biaya pengembangan dapat dikurangi 1152 person-hours. Pengurangan biaya adalah 1052 person-hours Requirements

Proses Requirements Urutan langkah yang dilakukan untuk meng-konversi kebutuhan user ke SRS Proses harus mendapatkan kebutuhan dan requirement dan secara jelas menentukannnya Aktivitas dasar Analisis masalah atau requirement Spesifikasi requirement validasi Requirements

Proses Requirement needs Analysis Specification Validation Requirements

Proses Requirement Proses tidak linear, namun berualng dan parallel Overlap antara fase – beberapa bagian dianalisa dan ditentukan Validasi dapat menunjukkan gap yang dapat digunakan untuk analisis lebih lanjut Requirements

Proses Requirement… Fokus pada analisi mengenai pemahaman mengenai sistem yang diinginkan dan requirement-nya Membagi strategi dasar Decomposisi menjadi bagian kecil, pahami tiap bagian dan relasikan antara bagian-bagian Menghasilkan informasi dalam jumlah yang banyak Teknik seperti data flow diagram, object diagrams dll digunakan dalam analisis Requirements

Analisis Masalah Tujuan: mendapatkan pemahaman tentang kebutuhan, requirement, dan constraints pada software Analisis meliputi wawancara klien dan user Mempelajari sistem yang berjalan Membantu client/user memahami kemungkinan fitur Requirements

Karakteristik SRS Karakteristik SRS yang baik Lengkap Tidak ambigu Konsisten Dapat diverifikasi Dapat diRangking Requirements

Lengkap Tidak Ambigu Semua fitur yang diinginkan dispesifikasikan Setiap reqiuirement direpresentasikan menjadi fitur yang sesuai Tidak Ambigu Tiap req punya 1 makna Jika tidak maka error yang ada bisa menjalar Requirements

Dapat diverifikasi Konsisten Dapat diRanking Harus ada cara yang paling efektif untuk pengecekan apakah software-nya memenuhi requirement Konsisten 2 requirements tidak kontradiktif dengan yang lain Dapat diRanking Kebutuhan untuk pemprioritasan dalam pembuatan Untuk mengurangi risiko selama perubahan requirement Requirements

Komponen SRS SRS harus menspesifikasikan requirement pada Fungsionalitas Performansi Design constraints Interface Eksternal Requirements

Functional Requirements Jantungya dokumen SRS ; FR membentuk sejumlah besar spesifikasi Menentukan seluruh fungsionalitas yang sistem harus dukung Memberikan Output untuk input dan relasi diantaranya Seluruh operasi yang dilakukan sistem Menspesifikasikan perilaku dari input yang tidak valid Requirements

Performance Requirements Seluruh batasan performance pada sistem software Umumnya berupa response time , throughput, dll=> dinamis Kapasitas requirement => statis Menggunakan hal yang dapat diukur (verifiability) contoh resp time ... 90% dari .... Requirements

Design Constraints Faktor-faktor dalam lingkunga client yang membatasi pilihan Beberapan batasan Pemenuhan kebutuhan Standard dan kompatibilitas dengan sistem lain Batasan Hardware Reliabilitas, fault tolerance, backup req. Security Requirements

External Interface Seluruh interaksi software dengan orang, hardware, dand sw Pentingnya User interface Harus dapat diverifikasi Requirements

Bahasa Specifikasi Bahasa harus mendukung karakter yang diinginkan dari SRS Bahasa Formal yang tepat dan tidak ambigu Bahasa Natural paling banyak digunakan, dengan beberapa struktur untuk dokumen Bahsa Formal digunakan untuk fitur khusus atau pada sistem yang sangat kritikal Requirements

Struktur SRS Pendahuluan Deskripsi keseluruhan Tujuan , tujuan dasar sistem Ruang lingkup sistem yang dapat lakukan, dan yang tidak dapat lakukan Overview Deskripsi keseluruhan Perspektif Produk Fungsi Produk Karakteristik User Assumsi Constraint Requirements

Structure SRS Requirement khusus Kriteria yang dapat diterima External interfaces Functional requirements Performance requirements Design constraints Kriteria yang dapat diterima Standarisasi SRS dilakukan IEEE. Requirements

Pendekatan Use Cases untuk Functional Requirement fokus pada spesifikasi fungsional Walaupun utamanya untuk specifikasi, dapat juga digunakan dalam analisis Dapat digunakan untuk menspesifikasikan perilaku bisnis atau organisasi, walaupun kita akan fokus pada sw Sangat sesuai untuk sistem yang interaktif Requirements

Dasar-Dasar Use Cases use case menyepakati suatu kontrak antara user dan sistem tentang perilaku Pada dasarnya berbentuk tekstual; diagram hanya sebagai pendukung Berguna juga mendapat requirement yang baru yang user inginkan Requirements

Aktor dapat berupa orang atau sistem Aktor: orang atau sistem yang berinteraksi dengan sistem yang diusulkan untuk mencapai suatu tujuan Misal. User dari ATM (tujuan: mengambil uang); operator entri data; (tujuan: melakukan transaksi) Aktor adalah entitas logik, sehingga aktor receiver dan sender berbeda (bahkan jika orang yang sama) Aktor dapat berupa orang atau sistem Aktor Primer : Aktor utama yang menginisiasi UC UC untuk memenuhi kebutuhanyan Eksukusi dapat dilakukan oleh sistem atau orang lain atas nama Aktor Primer Requirements

Skenario: rangkaian aksi yang dilakukan untuk mencapai tujuan dengan beberapa kondisi Aksi menentukan urutan langkah Skenario utama – ketika sesuatu berjalan secara normal dan tujuan tercapai Skenario Alternatif: ketika sesuatu berjalan tidak sebagaimana mestinya dan tujuan tidak tercapai Requirements

Contoh Use Case : Membeli Barang Aktor Primer: pembeli/pelanggan Tujuan: membeli beberapa barang Precondition: Pelanggan sudah login Requirements

Skenario Utama Pelanggan browse dan memilih item Pelanggan melakukan checkout Pelanggan mengisi informasi pilihan pengiriman Sistem menampikan rincian informasi harga Pelanggan mengisi informasi kartu kredit Sistem mengotorisasi pembelian Sistem mengkonfirmasi penjualan Sistem mengirimkan konfirmasi email Requirements

Alternatif 6a: Otorisasi kartu kredit gagal Membolehkan pelanggan memasukkan kembali data Requirements

Requirement dengan Use Cases UCs menentukan functional requirement Req yang lain diidentifikasi terpisah SRS yang lengkap memuat use cases dan requirement yang lain Requirements

Membuat Use Case Langkah 1: Tentukan aktor dan tujuan Hal ini akan menentukan ruang lingkup sistem Langkah 2: Tentukan Skenario Utama Hal ini akan menyediakan perilaku normal dari sistem Dapat di-reviewed untuk memastikan kepentingan seluruh stakeholder dand aktor terpenuhi Requirements

Langkah 3: Tentukan kondisi gagal Tentukan kondisi gagal yang mungkin terjadi di UC-nya Untuk tiap tahap, identifikasi bagaimana hasl tersebut bisa terjadi Step 4: Tentukan penanganan untuk kegagalan Tentukan perilaku sistem untuk kondisi gagal Requirements