REQUIREMENT MODELING SCENARIO & INTRODUCING TO USE CASE Acknowledgement

This presentation is revised by Hazlinda A., STMIK, 2013

REQUIREMENT MODELING SCENARIO

& INTRODUCING TO USE CASE

Mata Kuliah Testing & Implementasi Sistem

Program Studi Sistem Informasi 2013/2014

STMIK Dumai

-- Pertemuan 4 --

Acknowledgement2

Main materials:

[Pressman, 2010] Pressman, Roger S. Software Engineering: A Practitioner’s Approach. New York:McGraw-Hill Higher Education, 2010. Print

Supplements:

[Yud, 2012] Yudhoatmojo, Satrio Baskoro. “Software & SoftwareEngineering” IKI30202 - Rekayasa Perangkat Lunak Term 1 -2011/2012. Faculty of Computer Science University of Indonesia. 2012. Print

[Larman, 2005] Larman, Craig. Applying UML and Patterns: an Introduction to Object-oriented Analysis and Design and IterativDevelopment. Upper Saddle River, NJ: Pearson Education International, 2005. Print

Requirement

Requirement adalah kapabilitas dan kondisidimana sistem dan skup proyek sudah harusdikonfirmasi. [Larman, 2005]

Secara umum, requirement terbagi atas dua tipe:

Fungsional (fungsi sistem)

Non-fungsional (diluar fungsi sistem)

Rincian tipe requirement

3

Tipe Requirement

Requirement Fungsional: Proses-proses yang akan dilakukan oleh sistem Informasi system yang harus ada Mendefinisikan fungsi yang ada pada sistem. Requirement ini

langsung berlanjut ke pembuatan use case, proses model, dandata model.

Requirement Non-fungsional : Operasional Performa Keamanan sistem Kultur, politik, aturan dari pihak luar dll

4

Menetapkan Requirements

Terdapat 3 teknik yang membantu penggunadalam menemukan kebutuhan mereka untuksistem yang akan dibuat:

Business Process Automation (BPA)

Business Process Improvement (BPI)

Business Process Reengineering (BPR)

5

3 Teknik Analisis Requirement

6

1. Business Process Automation

(BPA)

Jangan ubah operasional dasar(basic) dari sistem

Lakukan otomatisasi untukbebrapa fungsi (trigger by sistem)

Goal: efisiensi untukuser/pengguna

7

2. Business Process Improvement

(BPI)

Memperhatikan durasidan harga proyek

Meningkatkan performasistem

Goal: Efisiensi danEfektivitas untukuser/pengguna

8

3. Business Process Reengineering

(BPR)

Merubah secara pokok(fundamental) bagaimanaoperasional sistem untukperusahaan

Goal: Mendisain ulang secaratotal proses bisnis dari sistem

9

Perbandingan Teknik Analisis

Ketiga teknik analisis BPA, BPI, dan BPR dibandingkanberdasarkan:

Nilai bisnis/fungsi (Potential business value)

Harga proyek (Project cost)

Lebar analisis (Breadth of analysis)

Resiko (Risk)

10

Karakteristik Proyek

Business Process Automation (BPA)

Business Process Improvement(BPI)

Business Process Reengineering(BPR)

Nilai bisnis/fungsi Menengah-kebawah

Menengah Tinggi

Harga proyek Rendah Menengah-kebawah

Tinggi

Lebar analisis Sempit Menengah-sempit Sangat luas

Resiko Menengah-kebawah

Menengah-kebawah

Sangat tinggi

11

Requirement Engineering

12

Requirement Engineering

Requirement engineering adalah proses yang membantu timkonsultan untuk lebih mengerti masalah yang akan merekaselesaikan (dalam bentuk produk software).

Proses requirement engineering dilakukan melalui 7 aktivitas:

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Requirement Management

13

1. Inception (permulaan)

Mengajukan pertanyaan yang akan membagun: Pemahaman dasar tentang masalahnya

Pihak-pihak yang menginginkan solusinya

Bentuk solusi yang diinginkan

Keefektivan komunikasi antara tim kustomer dengan tim konsultan.

Identify stakeholders Dengan siapa seharusnya kita melakukan requirement?

Bekerja dengan berkolaborasi (antara tim kustomer dengan tim konsultan)

Pertanyaan awal: Siapa orang dibalik requirement? (Who is behind the request for this work)

Siapa yang akan menggunakan solusi yang diberikan?

Apakah solusi yang diberikan juga mempertimbangkan sisi ekonomis?

Apakah ada alternatif solusi lain?

14

2. Eliciting Requirements

Elicit = mendapatkan, memperoleh. Memperoleh requirement dari semua pihak (stakeholders).

Rapat dihadiri oleh kedua belah pihak.

Aturan-aturan untuk persiapan sistem ditetapkan.

Menyusun jadwal.

Ada seorang fasilitator (bisa kustomer, konsultan, atau pihak lain) yang mengontrol rapat.

Tujuan yang ingin dicapai: Mengidentifikasi masalah Mengajukan beberapa solusi Menegosiasi jika ada pendekatan solusi lain Menetapkan solusi awal dari requirement

15

Quality Function Deployment (QFD)

QFD adalah teknik untuk menerjemahkan kebutuhankonsumen menjadi requirement teknis.

QFD mengidentifikasi 3 tipe requirement: Normal Requirement Merefleksikan sasaran dan tujuan pengembangan sistem,

sebagaimana dinyatakan oleh konsumen.

Expected Requirement Requirement yang implisit dan fundamental, konsumen tidak

menyebutkannya secara eksplisit. Jika tidak difasilitasi akan menimbulkan ketidakpuasan konsumen yang signifikan.

Misalnya, correctness dan instalasi software yang mudah.

Exciting Requirement Fitur diluar harapan (melebihi ekspektasi) konsumen dan akan

menimbulkan kepuasan bagi konsumen.

16

Eliciting Requirements

17

3. Elaboration

Elaborate = menguraikan, merincikan.

Merincikan hasil requirement, dan

Membuat model analisa yang mengidentifikasikandata, fungsi, dan kebutuhan lainnya.

18

4. Negotiation

Menyetujui gambaran umum sistem yang realistisbagi pihak kustomer maupun pihak konsultan.

Mengidentifikasi pihak-pihak yang menjadi “kunci”

Orang-orang yang akan melakukan deal harga proyek

Negosiasi

Mengukur besarnya kebutuhan sistem danmenghasilkan kesepakatan harga yang sesuai (win-win solition)

19

5. Spesifikasi

Specification — dapat berupa:

Dokumen tertulis (narasi)

Himpunan model

Rumus matematika

Kumpulan dari user scenarios (use-cases)

Prototipe

20

6. Validasi

Validation — mekanisme review untuk melihat:

Konten error atau kesalahan interpretasi

Area/fungsi/wilayah yang butuh klarifikasi

Informasi yang masih salah/kurang jelas

Tidak konsisten (biasanya terjadi di sistem berskalabesar)

Requirement yang konlifk/tidak realistis (tidak dapatdicapai)

21

7. Manajemen

Manajemen Requirement

Mengidentifikasi dan mengatur requirement, termasuk mengatur perubahan terhadap requirement.

22

Produk Hasil Requirement

Use-Case Model – satu set skenario sistem yang dibuat dalambentuk use case.

Supplementary Specification – Spesifikasi lain yang tidak ada dalamuse case (hasil requirement non-functional).

Glossary – Istilah-istilah penting di dalam sistem, termasuk dalamdata yang akan digunakan.

Vision – Menyimpulkan requirement yang sudah dirinci dalam Use-Case Model dan Supplementary Specification, dan mendapatkanvisi/gambaran proyek.

Business Rules – Kebutuhan dan kebijakan lain yang penting bagiproyek.

23

Produk Hasil Requirement 24

Analisis Requirement

Proses analisis lebih menekankan investigasimasalah dan kebutuhan, daripada solusi [Larman, 2005]

Contoh: jika dibutuhkan suatu sistem perdaganganonline, akan bagaimana sistem tersebutdigunakan? apa fungsinya?

Jadi, analisis requirement adalah investigasirequirement.

25

Analisis Requirement

Menentukan karakteristik operasional dari sistem.

Mengindikasikan interface sistem dengan elemen-elemen lain yang ada pada sistem tersebut.

Membangun batasan-batasan yang ada pada sistem.

Analisis requirement mengizinkan software engineer (analis/modeler) untuk:

Merincikan kembali kebutuhan dasar sistem selama masaawal requirement.

Membangun model yang menggambarkan skenario user, aktivitas fungsional, class, dan alur data pada sistem.

26

Analisis = Jembatan27

Elemen dari Analisis Requirement28

Modeling berdasarkan

SKENARIO(Scenario-Based Modeling)

29

Modeling berdasarkan Skenario

“*Use case+ membantu mendefinisikan secarasederhana apa yang ada di luar sistem (actors) dan apayang seharusnya dilakukan oleh sistem (use cases).” Ivar Jacobson

1. Apa yang seharusnya ditulis?

2. Bagaimana membuat skenarionya?

3. Sedetil apa deskripsi yang harus dibuat?

4. Bagaimana mengatur deskripsi yang sudah dibuat?

30

Apa yang ditulis?

Menyediakan informasi yang dibutuhkan untuk dapat menulisuse cases, dengan melakukan:

Requirement gathering meetings, QFD, dan mekanismerequirement lainnya digunakanuntuk:

Mengidentifikasi stakeholders

Medefinisikan skup proyek

Menentukan tujuanoperasional secara umum

Membangun prioritas proyek

Mengurai semua requirement fungsional

Menggambarkan benda (objek) yang berhubungan dengansistem

Untuk memulai pembuatan set of use case, buat daftarfungsi/aktivitas oleh aktortertentu (spesifik).

31

Sebanyak apa ditulis?

Sebagai pembicaraan lanjutan denganstakeholders, tim requirement gathering membuatuse case untuk tiap fungsi yang sudah disepakati.

Secara umum, use case ditulis pertama kali denganbahasa narasi yang informal.

Jika dibutuhkan use case yang lebih formal, makause case yang sama akan ditulis sesuai denganstruktur format use case yang baku.

32

Dari tadi banyak disebut kata “use case”

Ok, sekarang kita mulai berkenalandengan

USE CASE

33

Use Case adalah…

Suatu kumpulan dari hubungan skenario yang sukses dan gagal yang menggambarkan seorangaktor menggunakan sistem untuk mencapai tujuandari sistem tersebut [Larman, 2005].

Sebuah skenario yang menggambarkan suatu“penggunaan” dari sebuah sistem [Pressman, 2010]

34

Use Case adalah…

Skenario adalah suatu urutan aksi (action) yang spesifik dan interaksi antara aktor dengan sistem[Larman, 2005].

Aktor merepresentasikan peran (role) dari orangatau piranti yang akan menggunakan fungsisistem.

Aktor/pengguna dapat memainkan sejumlahperan yang berbeda dari skenario yang ada.

35

Kenapa Use Case?

Use case merupakan cara yang baik untukmenerapkan prinsip KIS, dan memungkinkan parapengguna untuk mengerti deskripsi fungsi sistem (yang sesuai dengan requirement mereka) yang tergambardalam use case.

Use case menekankan pada tujuan dan perspektifpengguna; kita (sebagai analis) bertanya ke mereka:

Siapa yang akan menggunakan sistem?

Tipe skenario apa yang mereka gunakan?

Apa tujuan/goal mereka?

36

Format Use Case - [LARMAN, 2005]

Brief – satu paragraf kesimpulan, berupa skenarioutama dari sistem yang sukses.

Kapan? Selama masa awal requirement, untuk melihatskup/besaran proyek. Pembuatan brief use case inibiasanya tidak membutuhkan waktu yang lama.

Casual- Format paragraf yang informal. Sejumlahparagraf yang mencakupi berbagai skenario.

Kapan? Sama dengan brief UC.

37

Format Use Case - [LARMAN, 2005]

Fully dressed – Semua langkah dari berbagai fungsiditulis dengan detil, dan ada bagian pendukungseperti prekondisi dan jaminan sukses.

Kapan? Setelah use case diidentifikasi dan ditulisdalam format brief, maka selama masa awalrequirement, beberapa use case yang signifikan dalamsistem ditulis dengan lebih detil.

38

Contoh dari UC Format Casual

Handle Returns

Main Success Scenario:

Kustomer kembali ke halaman utama dengan barang yang dipilihsebelumnya.

Kasir menggunakan sistem POS untuk mendata setiap barang yang dipesan.

Alternate Scenarios:

Jika kustomer membayar dengan kredit, dan transaksi reimburse untukkartu kredit tersebut ditolak, maka beri info ke kustomer untukmelakukan pembayaran dengan cash.

Jika kode barang yang dipesan tidak ditemukan, maka beritahu kasiruntuk memasukkan kode barang secara manual.

Jika...

Jika...

39

Full Dressed Format40

Menulis Black-Box Use Cases

Umum digunakan dan direkomendasikan. Tidak mendeskripsikan kerja internal sistem,

komponennya, atau disainnya. Namun, mendeskripsikan apa yang menjadi tanggung

jawab sistem (responsibilities).

Dengan mendefinisikan tanggung jawabnya, kita bisamenspesifikasikan apa yang harus dilakukan sistem(fungsi atau tingkah lakunya) sebelum menentukanbagaimana sistem akan melakukannya.

“Analisis” vs “Disain” terkadang disimpulkan sebagai“Apa” vs “Bagaimana”.

41

Menulis Black-Box Use Cases

Black-box Style Not

Sistem merekam data penjualan Sistem menulis data penjualanke database..

Atau…

Sistem men-generate statement SQL INSERT untuk data penjualan..

42

Contoh:

Temukan Aktor dan Tujuannya

Sebelum menentukan use case…

Observasi nilai hasil dari setiap aktor selamarequirement dengan melakukan hal berikut:

Tulis requirement dengan berfokus ke aktor/user darisistem, pastikan tujuannya dan tipe situasinya(perannya)

Fokus kepada “Apa pertimbangan aktor dan apa nilaihasilnya pada sistem”

43

Bagaimana Menemukan Use Case

Step 1: Tentukan batasan sistem (the System Boundary) Klarifikasi dengan menentukan siapa aktor utama sistem

dan siapa aktor pendukung (contoh: pihak pemerintah, pajak).

Jika aktor sudah diidentifikasi, batasan sistem akan menjadikelihatan.

Step 2 dan 3: Tentukan aktor utama dan tujuannya Penentuan aktor utama dilakukan untuk mengidentifikasi

apa tujuan/perannya terhadap sistem untuk kemudiandicarikan solusinya.

44


Siapa yang membuka danmenutup sistem ?

Siapa pengguna danmanajemen sekuritinya?

Siapa yang melakukan sistemadministrasinya?

Bagaimana ketersediaan“waktu” aktor pada saatsistem membutuhkan waktuuntuk respon yang lebihbanyak untuk kasus tertentu?

Adakah yang memonitoriproses restart sistem saatsistem bermasalah?

Bagaimana menangani update software?

Adakah software external atausistem robotik yang jugamenggunakan layanan sistem?

Siapa yang akan mengevaluasiaktivitas atau performasistem?

Apa saja pertanyaan untuk menemukan aktor dan tujuannya?

45


Dari pihak admin sistem…

Siapa yang mengevaluasi log kerja sistem?

Siapa pihak yang harus segera tahu apabila sistemmengelami error atau gagal berfungsi?

46


Ciri Bahasa Use Case:

Singkat, jelas

Hapus kata-kata yang “mengganggu”

Mulai nama use case dengan menggunakan katakerja

Contoh: “Batalkan pemesanan”, bukan “Sistemmembatalkan pemesanan…”

47


Untuk mengatur aktor dan tujuannya, paling tidakada 2 pendekatan:

Setelah menemukan aktor dan tujuannya, gambaraktor di use case diagram sebagai aktornya, dantujuan sebagai use case-nya.

atau…

Tulis tujuan aktor terlebih dahulu, review dan perbaikijika perlu, gunakan “bahasa use case”, kemudiangambar use case diagram-nya.

48

Contoh Daftar Aktor dan Tujuannya49


Setelah mengetahui gambaran besar tentang sistem...

Mengapa bertanya tentang “aktor-dan-tujuannya” lebihbaik daripada langsung membuat use case?

Karena visi dari membuat use case adalah untukmenemukan aktor dan tujuannya, kemudian membuatsolusi yang menjadi nilai dari hasil sistem.

Daripada bertanya “Apa tugas yang dilakukan sistem?”, lebih baik bertanya “Siapa yang akan menggunakansistem dan apa tujuan mereka?”

50


Step 4: Define Use Cases

Ingat, mulai nama use case dengan menggunakan katakerja.

51

(Mulai) Membangun Use Case

Untuk mendapatkan “tujuan aktor”, analis memastikan:

Apa tugas/fungsi utama yang akan dilakukan olehaktor?

Informasi apa yang bisa didapat, dibuat, atau diubaholeh aktor didalam sistem?

Informasi apa yang aktor inginkan ada di dalamsistem?

52

Contoh Use Case Diagram … (next slide)

53

Pertemuan ke-5…

Use Case Diagram

54

Documents

REQUIREMENT MODELING SCENARIO & INTRODUCING TO USE CASE Acknowledgement