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

In di rect Li brary m anager Finan ce Art icle providers All VPs In t eract or Do main Users Li brary st aff UI st andards Cl assi ficat i on sy st em St uden t s St aff Ex t ernal Sy st em m anagers Cat alo guers

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)

Initial assumption

: The user has logged on to the LIBSYS system and has located the journal containing the copy of the article .

Norm al

: The user selects the article to be copied. He or she is then prompted by the system to ei ther provide subscriber information for the journal or to indicate how they will pay for the article . Alternative payment me thods are by credit card or by quoting an organisational account number.

The user is then asked to fill in a copyright form that ma intains details of the transaction and they then submit this to the LIBSYS system.

The copyright form is c hecked and, if OK, the PDF version of the article is d ownloaded to the LIBSYS working area on the userÕs computer and the user is informed that it is available. The user is asked t o selec t a printer and a copy of the article is printed. If the article has been flagged as Ōprint-onlyÕ it i s deleted from the userÕs system o nce the user has confirmed that printing is complete.

Contoh LIBSYS scenario (2)

What can go wrong

: The user may fail to fill in the copyright form correctly. In this case, the form should be re-presented to the user for correction. If the resubmitted form is s till incorrect then the userÕs request for the article is rejec ted.

The payment ma y be rejected by the system. T he userÕs request for the article is rejected.

The article download may fail. Retry until successful or the user terminates the session.

It may not be possible to print the article. If t he article is not flagged as Ōprint-onlyÕ then it is held in the LIBSYS workspace. Otherwise, the article is d eleted and the userÕs account credited with the cost of the article .

Other activities

: Simultaneous downloads of other article s.

System state on completion

: User is logged on. The downloaded article has been dele ted from LIBSYS workspace if it has been flagged as print-only.

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

Insulin Pump/Control Software/SRS/3.3.2

Function

Compute insulin dose: Safe sugar level

Description

Computes the dose of insulin to be delivered wh en the current measured sugar level is in the safe zone between 3 and 7 units.

Inp uts Source

Current sugar re ading (r2), the previous two readings (r0 and r1) Current sugar re ading from sensor. Other re adings from memory.

Outputs

CompDose Š the dose in insulin to be delivered

Destination

Main control loop

Action:

CompDose is zero if the sugar level is stable or falling or if the level is increasing but the rate of increase is decreasing. If the level is increasing and the rate of increase is increasing, then CompDose is computed by dividing the difference between the current sugar level and the previous level by 4 and rounding the result. If the result, is rounded to zero then CompDose is set to the mi nimum dose that can be delivered.

Requires Pre-condition Post-condi tion Side-effects

Two previous readings so that the rate of change of sugar level can be comp uted.

The insulin reservoir contains at lea st the maximum allowed single dose of insulin..

r0 is replaced by r1 then r1 is replaced by r2 None

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, 7 th ed, 2004, Prentice hall, USA N. Ashrafi, Object Oriented systems Analysis and Design, Pearson International Edition, 2008, Pearson Education, USA