TIB15 - ANALISIS & DESAIN BERORIENTASI OBJEK

1. Pertemuan 2Pengumpulan Persyaratan(disadur dari Slide Software Engineering – Ian Sommerville Ch6 dan Ch7) TIB15 - ANALISIS & DESAIN BERORIENTASI OBJEK

2. Materi yang dibahas • Requirements/Persyaratan • Klasifikasipersyaratan • MenentukanPersyaratan • Requirements Engineering Process • TeknikmemunculkanPersyaratan (ElisitasidanAnalisa) • SumberPersyaratan • Ethnography • Mengelolapersyaratan • Dokumen Requirement • PanduanPenulisan Requirement

3. Requirements/Persyaratan • Requirement mengidentifikasi bagaimana suatu sistem dapat membantu pemakai. • Pengumpulan requirement berhubungan dengan pengumpulan fitur-fitur dan aturan-aturan dalam pengembangan sistem.

4. Klasifikasi Persyaratan • Functional Requirements Menentukan perilaku system beserta batasan-batasannya • Non functional Requirements Menentukan properti-properti nonbehavioral system dan batasan-batasannya

5. Non Functional Requirement Beberapa kategori non functional Requirement: • Usability • Reliability • Performance • Maintainability • Security

6. Functional Requirements • Pernyataan layanan yang harus diberikan sistem • Reaksi sistem terhadap input tertentu • Situasi-situasi tertentu dimana sistem akan berlaku • Pernyataan secara eksplisit mengenai apa yang boleh dilakukan sistem

7. Requirements Engineering Process

8. Feasibility studies • Feasibility study memutuskan apakah sistem yang diusulkan berharga atau tidak • Studi terfokus singkat yang memeriksa • Apakah sistem berkontribusi pada tujuan organisasi • Apakah sistem dapat direkayasa dengan teknologi saat ini dan budget yang ada • Apakah sistem dapat diintegarasikan dengan sistem lain yang digunakan

9. Penerapan Feasibility study • Berdasarkan penilaian informasi (apa yang diperlukan), pengumpulan informasi dan penulisan laporan • Pertanyaan untuk orang-orang pada organisasi • Bagaimana jika sistem tidak diimplementasikan? • Apakah masalah proses yang ada saat ini? • Bagaimana sistem yang diusulkan dapat membantu? • Apakah masalah yang akan terjadi pada integrasinya? • Apakah teknologi baru dibutuhkan? Bagaimana dengan skill nya? • Apakah fasilitas yang harus di dukung dengan usulan sistem?

10. Elisitasi dan Analisa • Seringkalidisebut requirements elicitation atau requirements discovery. • Melibatkanpekerjaan technical staff dengan customer untukmenemukan domain aplikasi, layanan yang harusdisediakansistemdanbatasanoperasionalsistem • Dapatmelibatkanstakeholdersseperti end-users, managers, engineers involved in maintenance, domain experts, trade unions, dsb

11. Viewpoints (sudut pandang) • Viewpoints adalah sebuah cara untuk menata persyaratan untuk merepresentasikan perspektif dari stakeholders yang berbeda. Stakeholders dapat digolongkan dengan sudut pandang yang berbeda.

12. Teknik elisitasi dan analisis persyaratan (berdasarkan VORD – Viewpoint-Oriented Requirements Definition) • Elisitasi berorientasi sudut pandang • Skenario • Etnografi

13. Tahap-tahap sudut pandang • Identifikasisudutpandang • Pencariansudutpandang yang menerimalayanansistemdanpengidentifikasianlayanan-layanankhusus yang diberikanbagisetiapsudutpandang • Penstrukturansudutpandang • Pengelompokansudutpandang yang berhubunganmenjadihierarki. • Dokumentasisudutpandang • Melakukandekripsisudutpandangdanlayanan yang teridentifikasi • Pemetaansistemsudutpandang • Pengidentifikasianobyekpadadesainberorientasiobyekdenganmenggunakaninformasilayanan yang dicakuppadasudutpandang

14. Sudut pandang dapat dianggap sebagai: • Sumberataupuntempatmasuknya data • Sudutpandangbertanggungjawabuntukmenghasilkanataumemakai data • Analisismencakuppengenalansemuasudutpandangsepertiini • Mengidentifikasi data ap yang dihasilkanataupundipalai, sertaprossapasaja yang dikerjakan • Kerangkakerjarepresentasi • Sudutpandangdianggapsebagaijeniskhusus model sistem • Catatan: Dalamhalinisetiappendekatananalisismenemukanhal-hal yang berbedaengenaisistem yang dianalisis • Penerimalayanan • Dalamhalinisudutpandangbersifateksternalterhadapsistemdanmenerimalayanandarisistem • Analisismelibatkanpemeriksaanlayanan yang diterimaolehsudutpandang yang berbeda, pengumpulannyadanpenyelesaiankonflik

15. Contoh: LIBSYS viewpoint hierarchy

16. Wawancara • Pada wawancara formal atau informal interviewing, RE team memberi pertanyaan pada stakeholders mengenai sistem yang pakai dan sistem yang akan dibangun. • Dua tipe interview • Interview tertutup dimana sekumpulan pertanyaan pre-defined dijawab • Open interviews dimana tidak ada agenda pre-defined dan cakupan isu dieksplorasi dengan stakeholders.

17. Praktek Interview • Secara normal, berupa gabungan closed and open-ended interviewing. • Interview baik untuk mendapatkan pengertian secara menyeluruh dari apa yang stakeholders lakukan dan bagaimana mereka berinteraksi dengan sistem. • Interviews tidak baik untuk memahami domain requirements • Requirements engineers tidak dapat memahami terminologi specific domain • Beberapa domain knowledge begitu familiar sehingga sulit untuk dijelaskan ataupun juga mengira tidak perlu dijelaskan

18. Skenario • Skenario adalah contoh nyata bagaimana sistem dapat digunakan. • Termasuk diantaranya • Penjelasan situasi awal • Penjelasan aliran normal dari kejadian • Penjelasan apa yang dapat menjadi kesalahan • Informasi tentang kegiatan yang bersamaan • Penjelasan keadaan ketika skenario berakhir

19. Contoh LIBSYS scenario (1)

20. Contoh LIBSYS scenario (2)

21. Use cases • Use-cases adalah teknik scenario based pada UML yang mengidentifikasi aktor pada sebuah interaksi dan menjelaskan interaksi itu sendiri • Sekumpulan use cases akan menjelaskan semua kemungkinan interaksi dengan sistem • Sequence diagrams dapat digunakan untuk menambahkan detail ke use-cases dengan menunjukkan sequence dari kejadian pemrosesan pada sistem.

22. Contoh Article printing use-case

23. Contoh LIBSYS use cases

24. Contoh Print article sequence

25. Ethnography • IlmuwanSosialmelakukanobservasiuntukmenganalisabagaimanaorangbekerja. • Orangtidakmenjelaskanataupunmengutarakanpekerjaanmereka. • Faktorsosialdan organisational pentinguntukdiamati • Ethnographic studies menunjukkanbahwapekerjaanbiasanyalebihluasdanlebihkompleksdaripada yang ditunjukkanoleh model sistem yang sederhana

26. Scope of ethnography • Requirements yang berasal dari cara orang-orang bekerja bukan cara definisi proses yang disarankan yang merupakan bagaimana cara mereka seharusnya bekerja • Requirements berasal dari kerjasama dan kepedulian dari aktifitas orang lain

27. Ethnography and prototyping

28. Validasi Requirements • Berpusat pada mendemonstrasikan bahwa ketentuan requirement sesuai dengan yang customer inginkan • Harga kesalahan requirements besar, sehingga validasi sangat penting • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error.

29. Panduan Penulisan Requirement • Menciptakan format standar dan menggunakannya untuk semua kebutuhan. • Menggunakan bahasa dengan cara yang konsisten. Gunakan kata ‘harus’ untuk persyaratan yang diharuskan, ‘sebaiknya’ untuk kebutuhan yang diinginkan • Gunakanteks yang mencolokuntukmengidentifikasibagiankunci. • Hindaripemakaianbahasaprokem.

30. Contoh Penulisan Requirement

31. Dokumen requirements • Dokumen requirements adalahpernyataanresmidariapa yang dibutuhkanpadapengembangansistem • Harusberisidefinisi user requirements danspesifikasi system requirements. • BUKAN dokumen design. Sejauh yang diijinkan, sebaiknyaberisisekumpulan APA yang sistemseharusnyadapatlakukandaripada BAGAIMANA sistemmelakukannya.

32. IEEE requirements standard • Defines a generic structure for a requirements document that must be instantiated for each specific system. • Introduction. • General description. • Specific requirements. • Appendices. • Index.

33. Struktur Dokumen Requirement • Preface • Introduction • Glossary • User requirements definition • System architecture • System requirements specification • System models • System evolution • Appendices • Index

34. Referensi • Ian Sommerville, Software Engineering, 7th-ed, 2004, Prentice hall, USA • N. Ashrafi, Object Oriented systems Analysis and Design, Pearson International Edition, 2008, Pearson Education, USA