Analisis Kebutuhan PL dan Spesifikasi PL

Presentasi berjudul: "Analisis Kebutuhan PL dan Spesifikasi PL"— Transcript presentasi:

1 Analisis Kebutuhan PL dan Spesifikasi PL
Requirements

2 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

3 Requirements

4 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

5 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

6 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

7 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

8 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

9 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

10 Proses Requirement needs Analysis Specification Validation
Requirements

11 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

12 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

13 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

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

15 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

16 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

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

18 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

19 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 % dari .... Requirements

20 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

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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

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

30 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 Requirements

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

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

33 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

34 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