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

Materi yang dibahas Requirements/Persyaratan Klasifikasi persyaratan Menentukan Persyaratan Requirements Engineering Process Teknik memunculkan Persyaratan (Elisitasi dan Analisa) Sumber Persyaratan Ethnography Mengelola persyaratan Dokumen Requirement Panduan Penulisan Requirement

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

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

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

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

Requirements Engineering Process

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

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?

Elisitasi dan Analisa Seringkali disebut requirements elicitation atau requirements discovery. Melibatkan pekerjaan technical staff dengan customer untuk menemukan domain aplikasi, layanan yang harus disediakan sistem dan batasan operasional sistem Dapat melibatkan stakeholders seperti end-users, managers, engineers involved in maintenance, domain experts, trade unions, dsb

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.

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

Tahap-tahap sudut pandang Identifikasi sudut pandang Pencarian sudut pandang yang menerima layanan sistem dan pengidentifikasian layanan-layanan khusus yang diberikan bagi setiap sudut pandang Penstrukturan sudut pandang Pengelompokan sudut pandang yang berhubungan menjadi hierarki. Dokumentasi sudut pandang Melakukan dekripsi sudut pandang dan layanan yang teridentifikasi Pemetaan sistem sudut pandang Pengidentifikasian obyek pada desain berorientasi obyek dengan menggunakan informasi layanan yang dicakup pada sudut pandang

Sudut pandang dapat dianggap sebagai: Sumber ataupun tempat masuknya data Sudut pandang bertanggung jawab untuk menghasilkan atau memakai data Analisis mencakup pengenalan semua sudut pandang seperti ini Mengidentifikasi data ap yang dihasilkan ataupun dipalai, serta pross apa saja yang dikerjakan Kerangka kerja representasi Sudut pandang dianggap sebagai jenis khusus model sistem Catatan: Dalam hal ini setiap pendekatan analisis menemukan hal-hal yang berbeda engenai sistem yang dianalisis Penerima layanan Dalam hal ini sudut pandang bersifat eksternal terhadap sistem dan menerima layanan dari sistem Analisis melibatkan pemeriksaan layanan yang diterima oleh sudut pandang yang berbeda, pengumpulannya dan penyelesaian konflik

Contoh: LIBSYS viewpoint hierarchy

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.

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

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

Contoh LIBSYS scenario (1)

Contoh LIBSYS scenario (2)

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.

Contoh Article printing use-case

Contoh LIBSYS use cases

Contoh Print article sequence

Ethnography Ilmuwan Sosial melakukan observasi untuk menganalisa bagaimana orang bekerja. Orang tidak menjelaskan ataupun mengutarakan pekerjaan mereka. Faktor sosial dan organisational penting untuk diamati Ethnographic studies menunjukkan bahwa pekerjaan biasanya lebih luas dan lebih kompleks daripada yang ditunjukkan oleh model sistem yang sederhana

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

Ethnography and prototyping

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.

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 Gunakan teks yang mencolok untuk mengidentifikasi bagian kunci. Hindari pemakaian bahasa prokem.

Contoh Penulisan Requirement

Dokumen requirements Dokumen requirements adalah pernyataan resmi dari apa yang dibutuhkan pada pengembangan sistem Harus berisi definisi user requirements dan spesifikasi system requirements. BUKAN dokumen design. Sejauh yang diijinkan, sebaiknya berisi sekumpulan APA yang sistem seharusnya dapat lakukan daripada BAGAIMANA sistem melakukannya.

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.

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

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