• Tidak ada hasil yang ditemukan

5. Requirement Engineering Rekayasa Perangkat Lunak Teknik Informatika S1

N/A
N/A
Protected

Academic year: 2019

Membagikan "5. Requirement Engineering Rekayasa Perangkat Lunak Teknik Informatika S1"

Copied!
45
0
0

Teks penuh

(1)

Teknik Informatika S1

Disusun Oleh:

Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS

[email protected] +6285640392988

Requirement Engineering

(2)

SILABUS MATA KULIAH

8. Pembahasan UTS + Tugas SKPL 9. Presentasi SKPL

10. Design Engineering + Tugas DPPL

11. Presentasi DPPL

12. Software Testing + Quiz 13. Present Tugas Besar

14. Present Tugas Besar 1. Pendahuluan

2. Pengenalan RPL

3. Software Process (1) 4. Software Process (2)

5. Requirement Engineering

(3)
(4)

Latihan

Latihan

Chelsea Outlet merupakan outlet yang bergerak di bidang penjualan jersey khusus Chelsea. Seiring perkembangan outlet yang semakin maju diikuti persaingan dengan outlet lain. Pengolahan data penjualan di Chelsea outlet masih kurang efektif karena transaksi belum terkomputerisasi. Chelsea outlet memerlukan sebuah perangkat lunak untuk mengolah data penjualan dan laporannya. Perangkat yang dibuat harus sesuai dengan sarana komputer yang ada di Chelsea outlet.

(5)

Answer

Answer

(6)

Answer

Answer

Model proses yang akan saya terapkan adalah Model Spiral.

Penelitian ini termasuk jenis development system karena akan meneliti dan

mengembangkan suatu rekayasa perangkat lunak aplikasi penjualan yang sesuai dengan kebutuhan tempat studi kasus yaitu Chelsea outlet.

Model yang digunakan dalam proses pengembangan untuk membangun

sistem aplikasi ini yaitu metode Spiral. Model spiral dibagi menjadi sejumlah

aktiftas kerangka kerja, disebut juga wilayah tugas. Model spiral yang berisi

tujuh wilayah tugas : Komunikasi pelanggan, Perancangan, Analisis Masalah,

Rekayasa, Coding, Pengujian dan Evaluasi Pelanggan akan sangat cocok

(7)

REQUIREMENT ENGINEERING

1. Pengertian Requirement?

2. Pengertian Requirement Engineering?

3. Kenapa Requirement Engineering dibutuhkan? 4. Cara mendapatkan kebutuhan

5. User dan System Engineering 6. Requirement Classification

(8)
(9)

Pengertian Requirement

(10)

Pengertian Requirement

• All project begin with a statement of requirements

• Requirements are descriptions of how a software

(11)

Pengertian Requirement

“Sesuatu pada produk yang harus dilakukan atau sebuah kualitas yang harus dimiliki produk tersebut” (Robertson99).

(12)

Pengertian Requirement Engineering

Requirement Engineering adalah Proses dimana

(13)

Pengertian Requirement Engineering

Requirement Engineering adalah Proses dimana persyaratan untuk produk perangkat lunak dikumpulkan, dianalisis, didokumentasikan, dan dikelola di seluruh siklus hidup rekayasa perangkat lunak”.

(14)

Requirement Engineering

(15)

Requirement Engineering Process

(16)

• Requirements yang lemah/ tidak lengkap adalah

sumber utama dari kegagalan (Standish95) 8000 projects, 350 US companies:

1/3 dari projek tidak pernah selesai dan 50% berhasil hanya sebagian

(17)

• Requirements yang lemah/ tidak lengkap adalah sumber utama

dari kegagalan (Standish95)

8000 projects, 350 US companies:

1/3 dari projek tidak pernah selesai dan 50% berhasil hanya sebagian

• Banyaknya masalah yang dirasakan terkait dengan spesifikasi

kebutuhan (>50%) – (ESI96)

3800 organisasi di 17 negara eropa

(18)

• “Kebutuhan yang tidak mencukupi, tidak konsisten,

tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut” (Bell&Tayer76)

(19)

• “Kebutuhan yang tidak mencukupi, tidak konsisten, tidak

lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut” (Bell&Tayer76)

• “Keterlambatan koreksi dari kesalahan meningkatkan biaya

sampai 200 kali lebih banyak selama proses requirement engineering” (Boehm81)

(20)

“Jika customer tidak senang dengan perangkat lunak yang dibangun maka software developer membangun perangkat lunak yang salah”.

Kenapa Requirement Engineering

dibutuhkan?

(21)

1. Wawancara

Berupa komunikasi verbal untuk mendapatkan informasi langsung dari satu atau sekelompok orang.

2. Kuesioner

Berupa alat komunikasi berupa pertanyaan tertulis yang diberikan kepada customer.

(22)

3. Observasi

Peninjauan langsung tim requirement engineer ke tempat customer untuk merasakan atau memperhatikan prosedur manual secara langsung dalam rangka mendapatkan kebutuhan.

4. Pencarian Dokumen (Data Sekunder)

Pencarian terhadap dokumen-dokumen manual yang berhubungan dengan kebutuhan pembangunan perangkat lunak.

(23)

Teknik dan Pendekatan

cara mendapatkan kebutuhan

1. Interviews

2. Questionnaires 3. Task Analysis 4. Domain Analysis 5. Introspection 6. Repertory Grids 7. Card Sorting

8. Laddering 9. Group Work 10. Brainstorming

11. Joint Application Development 12. Requirements Workshops

13. Ethnography 14. Observation

15. Protocol Analysis 16. Apprenticing

17. Prototyping

18. Goal Based Approach 19. Scenarios

(24)

1. User Requirement

Pernyataan dalam bentuk bahasa natural ditambah diagram dari layanan sistem dan batasannya. Dibuat untuk customer.

2. System Requirement

Dokumen terstruktur yang mengatur detail deskripsi dari layanan sistem. Dibuat sebagai kontrak antara customer dan software developer.

3. Software Spesification

Deskripsi perangkat lunak yang detail yang menyajikan informasi untuk perancangan atau implementasi sistem. Dibuat untuk software developer.

(25)

Perbedaan User dan System Requirement

Kedetailan Informasi Tidak terlalu detail Lebih detail

Target Pengguna Pengguna sistem yang tidak mempunyai

pengetahuan teknik yang detail

Developer (terkadang customer ingin

mengetahui)

Bentuk Informasi Bahasa natural dan diagram sederhana tentang layanan sistem

(26)

Contoh User dan System Requirement

User Requirement

Sistem bisa melakukan operasi dasar pengolahan data buku yang ada di perpustakaan

System Requirement

1. Sistem bisa melayani proses penambahan data buku yang diinput oleh pengguna

2. Sistem bisa melayani pengeditan data buku yang sudah tersimpan dalam basis data

(27)

Requirement Classifiations

(28)

Requirement Classifications

Functional

versus

Non Functional

1.

Kebutuhan fungsional

?

(29)

Requirement Classifications

Functional

versus

Non Functional

1.

Kebutuhan fungsional

Menunjukkan

What

the system should do

.

(30)

Requirement Classifications

Functional

versus

Non Functional

1. Kebutuhan fungsional

Kebutuhan fungsional mencakup:

* Fungsi deskripsi kebutuhan

* Laporan baik hardcopy maupun softcopy * Updating dan query online

(31)

Requirement Classifications

Functional

versus

Non Functional

1.

Kebutuhan fungsional

(32)

Requirement Classifiations

Functional

versus

Non Functional

1.

Kebutuhan fungsional

Contoh: dalam sistem informasi akademik

(33)

Requirement Classifications

Functional

versus

Non Functional

1.

Kebutuhan Non fungsional

(34)

Requirement Classifications

Functional

versus

Non Functional

1.

Kebutuhan Non fungsional

Kebutuhan yang mencakup:

* Waktu respon

* Rata-rata waktu untuk kegagalan * Kebutuhan keamanan

(35)

Requirement Classifiations

Functional

versus

Non Functional

1.

Kebutuhan Non fungsional

(36)

Requirement Classifications

Functional

versus

Non Functional

1.

Kebutuhan Non fungsional

Contoh:

(37)

Requirement Classifications

Functional versus Non Functional

Functional Requirements  What the system should do

Non functional Requirements  Constraints on the types of

solutions that will meet the functional requirements

(38)

Requirement Engineering Process

Requirements engineering melibatkan semua siklus hiduo aktivitas yang berhubungan dengan kebutuhan.

Meliputi:

Gathering  Mengumpulkan data kebutuhan

Documenting  Dokumentasi

Managing requirements  Mengatur/ memanage

(39)

Pengukuran Kebutuhan

PROPERTI UKURAN

Kecepatan 1. Transaksi yang diproses per detik 2. Waktu respon pengguna

3. Waktu refresh layar

Ukuran 1. Kbytes

2. Jumlah RAM

Kemudahan Penggunaan 1. Waktu Pelatihan

2. Jumlah help yang disediakan

Reliabilitas 1. Rata-rata waktu kegagalan

2. Kemungkinan untuk tidak bisa diakses 3. Jumlah kegagalan yang terjadi

Robustness 1. Waktu restart ketika terjadi kegagalan 2. Presentase dari kegagalan

3. Kemungkinan data hilang ketika terjadi kegagalan

(40)
(41)

Kapan kita memodelkan kebutuhan?

Traditionally : Fase awal dari siklus pembuatan perangkat lunak Requirements

Permulaan Elaboration/ Perluasan Construction/ Pembangunan Transition/ Peralihan

RUP,

(Jacobson98)

Life Cycle Objectives

Life Cycle Architecture

Initial Operational Capability

(42)

Definisi

“Pernyataan resmi dari apa yang dibutuhkan oleh developer sistem untuk membangun sistem dan berisi penggabungan antara definisidan spesifikasi kebutuhan”

(43)

1. Menggunakan format standar untuk semua kebutuhan. 2. Menggunakan bahasa yang konsisten

3. Bagian-bagian penting dari seluruh kebutuhan harus ditandai.

4. Jangan menggunakan bahasa jargon. 5. Complete but not Complicated

(44)

Pengguna Dokumen Kebutuhan

PENGGUNA KEGUNAAN DOKUMEN

Cutomer 1. Sarana untuk menspesifkasikankebutuhan sistem dan pengecekan apakah sistem yang dibangun sesuai

kebutuhan.

2. Sarana penyampaian perubahan kebutuhan.

Manajer Proyek 1.Dasar perhitungan penawaran biaya sistem. 2.Dasar perencanaan untuk pembangunansistem

System Engineer Sarana untuk memahami sistem seperti apa yang akan dibangun

System Test Engineer Dasar untuk melakukanvalidation test pada sistem

System Maintenance Engineer

(45)

Referensi

Dokumen terkait

Abdul kadir, pemograman Database MySQL Untuk Pemula, 2013.. Rekayasa Perangkat

 Proses yang digunakan untuk rekayasa kebutuhan sangat bervariasi tergantung pada domain aplikasi, orang yang terlibat dan organisasi yang.

Rekayasa perangkat lunak tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga mencakup kegiatan manajemen proyek perangkat lunak

Tujuan dari rekayasa perangkat lunak adalah untuk mengembangkan sistem berbasis software yang dapat digunakan pengguna mencapai tujuan bisnis mereka.. Seorang

Model proses yang menekankan pada fast delivery dari setiap poin aktivitas dalam rangka memperpendek jangka waktu proyek pembangunan perangkat lunak... AGILE METHOD

Rekayasa perangkat lunak tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga mencakup kegiatan manajemen proyek perangkat lunak

• Mampu menjelaskan dan membandingkan model proses rekayasa perangkat lunak Ceramah / penjelasan materi perkuliahan Tanya jawab 2 x 50” Model Proses Rekayasa Perangkat Lunak •

Dokumen ini berisi tentang model pengembangan rekayasa perangkat