1 / 34

Analisis Kebutuhan PL dan Spe sifikasi PL

Analisis Kebutuhan PL dan Spe sifikasi PL. Latar Belakang. Identifi kasi d an penentuan kebutuhan perlu melibatkan interaksi dengan user(orang) Requirement (IEEE)= k ondi si atau kemampuan yang harus dimiliki oleh s i stem

lona
Download Presentation

Analisis Kebutuhan PL dan Spe sifikasi PL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Analisis Kebutuhan PL dan Spesifikasi PL Requirements

  2. Latar Belakang • Identifikasi dan penentuan kebutuhan perlu melibatkan interaksi dengan user(orang) • Requirement (IEEE)= kondisiataukemampuan 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. Kebutuhanakan SRS • SRS menghasilkan persetujuanantara 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 requirementmembantu menjelaskan kebutuhan yang ada • SRS menyediakan reference untuk validasi produk akhir Requirements

  6. Kebutuhan akan SRS • SRS yang baikmengurangu 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 untukperbaikan error pada req. , design , coding , acceptance testing and operation adalah 5 , 15 , 50 , 150 person-months • Setelahfase req. 65% req errs terdeteksipada design , 2% pada coding, 30% pada Acceptance testing, 3% pada operation • Jika 50 requirement error tidakdihilangkanpadafase 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 diinginkandan requirement-nya • Membagi strategi dasar • Decomposisi menjadibagian 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, danconstraints pada software • Analisis meliputi • wawancaraklien danuser • 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 • 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 • 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 sistemsoftware • Umumnya berupa response time , throughput, dll=> dinamis • Kapasitas requirement => statis • Menggunakan hal yang dapat diukur (verifiability) • contoh resp time ... 90% dari .... Requirements

  20. Design Constraints • Faktor-faktor dalam lingkunga client yang membatasi pilihan • Beberapan batasan • Pemenuhan kebutuhan Standard dan kompatibilitasdengan 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 dapatdiverifikasi 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 khususatau pada sistem yang sangat kritikal Requirements

  23. Struktur SRS • Pendahuluan • 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 • 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 kontrakantara user dan sistem tentang perilaku • Pada dasarnya berbentuk tekstual; diagram hanya sebagaipendukung • Berguna juga mendapat requirement yang baru yang user inginkan Requirements

  27. 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, sehinggaaktor receiver dan sender berbeda (bahkan jika orang yang sama) • Aktordapat berupa orang atau sistem • Aktor Primer:Aktor utama yang menginisiasi UC • UC untuk memenuhi kebutuhanyan • Eksukusi dapat dilakukan oleh sistem atau orang lain atas namaAktor 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. SkenarioUtama • Pelanggan browse danmemilih item • Pelangganmelakukan checkout • Pelangganmengisiinformasipilihanpengiriman • Sistemmenampikanrincianinformasiharga • Pelangganmengisiinformasikartukredit • Sistemmengotorisasipembelian • Sistemmengkonfirmasipenjualan • Sistemmengirimkankonfirmasi email Requirements

  31. Alternatif • 6a: Otorisasikartukreditgagal • Membolehkanpelangganmemasukkankembali data Requirements

  32. Requirement dengan Use Cases • UCs menentukanfunctional requirement • Req yang lain diidentifikasiterpisah • SRS yang lengkapmemuatuse cases dan requirement yang lain Requirements

  33. MembuatUse Case • Langkah1: Tentukanaktordantujuan • Hal iniakanmenentukanruanglingkupsistem • Langkah 2: TentukanSkenarioUtama • Hal iniakanmenyediakanperilakunormal darisistem • Dapatdi-reviewed untukmemastikankepentinganseluruh stakeholder dandaktorterpenuhi Requirements

  34. Langkah3: Tentukankondisigagal • Tentukankondisigagal yang mungkinterjadidi UC-nya • Untuktiaptahap, identifikasibagaimanahasltersebutbisaterjadi • Step 4: Tentukanpenangananuntukkegagalan • Tentukanperilakusistemuntukkondisigagal Requirements

More Related