Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Requirements1 Analisis Kebutuhan PL dan Spesifikasi PL.

Presentasi serupa


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

1 Requirements1 Analisis Kebutuhan PL dan Spesifikasi PL

2 Requirements2 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

3 Requirements3

4 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

5 Requirements5 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

6 Requirements6 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

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 ?? Requirements7

8 total cost 32.5 *5 + 1* * *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 Requirements8

9 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

10 Requirements10 Proses Requirement needs Analysis Specification Validation

11 Requirements11 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

12 Requirements12 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

13 Requirements13 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

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

15 Requirements15 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

16 Requirements16 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

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

18 Requirements18 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

19 Requirements19 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....

20 Requirements20 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

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

22 Requirements22 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

23 Requirements23 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

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

25 Requirements25 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

26 Requirements26 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

27 Requirements27 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

28 Requirements28 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

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

30 Requirements30 Skenario Utama 1. Pelanggan browse dan memilih item 2. Pelanggan melakukan checkout 3. Pelanggan mengisi informasi pilihan pengiriman 4. Sistem menampikan rincian informasi harga 5. Pelanggan mengisi informasi kartu kredit 6. Sistem mengotorisasi pembelian 7. Sistem mengkonfirmasi penjualan 8. Sistem mengirimkan konfirmasi

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

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

33 Requirements33 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

34 Requirements34 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


Download ppt "Requirements1 Analisis Kebutuhan PL dan Spesifikasi PL."

Presentasi serupa


Iklan oleh Google