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

REQUIREMENT

& INTRODUCING TO USE CASE

Mata Kuliah Testing & Implementasi Sistem

Program Studi Sistem Informasi 2014/2015

STMIK Dumai

-- Materi 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

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.

12

Produk Hasil Requirement 13

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.

14

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.

15

Analisis = Jembatan16

Elemen dari Analisis Requirement17

Mengenal USE CASE

18

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]

19

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.

20

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?

21

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.

22

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.

23

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

24

Full Dressed Format25

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”.

26

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

27

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”

28

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.

29

Bagaimana Menemukan Use Case

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?

30

Bagaimana Menemukan Use Case

Dari pihak admin sistem…

Siapa yang mengevaluasi log kerja sistem?

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

31

Bagaimana Menemukan Use Case

Ciri Bahasa Use Case:

Singkat, jelas

Hapus kata-kata yang “mengganggu”

Mulai nama use case dengan menggunakan katakerja

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

32

Bagaimana Menemukan Use Case

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.

33

Contoh Daftar Aktor dan Tujuannya34

Bagaimana Menemukan Use Case

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

35

Bagaimana Menemukan Use Case

Step 4: Define Use Cases

Ingat, mulai nama use case dengan menggunakan katakerja.

36

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

37

Contoh Use Case Diagram … (next slide)

38

Materi ke-5…

Use Case Diagram

39