5. Requirement Engineering Rekayasa Perangkat Lunak Teknik Informatika S1

  Teknik Informatika S1

Rekayasa Perangkat Lunak

  Requirement Engineering Disusun Oleh: Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS egia@dsn.dinus.ac.id

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

  6. Analysis Modeling (1) + Quiz

  7. Analysis Modeling (2)

  Pembahasan Study Kasus – Model Proses

  

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.

  

Answer

Answer

?

  

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

apabila diterapkan pada kasus tersebut.

  1. Pengertian Requirement?

  2. Pengertian Requirement Engineering?

  3. Kenapa Requirement Engineering dibutuhkan?

  4. Cara mendapatkan kebutuhan

  5. User dan System Engineering

  6. Requirement Classification

  7. Requirement Engineering Process

  8. Requirement Management

  “The hardest single part of building a software system is deciding precisely what to build”- F. Brooks

  Pengertian Requirement Requirement

  ?

Pengertian Requirement

  All project begin with a statement of requirements

• Requirements are descriptions of how a software
• product should perform

  Pengertian Requirement

  “Sesuatu pada produk yang harus dilakukan atau sebuah kualitas yang harus dimiliki produk tersebut”

  (Robertson99) .

  “Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan” (Anton96).

Pengertian Requirement Engineering

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

  

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

  

Requirement Engineering berkaitan dengan menafsirkan dan

memahami tujuan, kebutuhan, dan keyakinan dari pihak yang

berkepentingan

  

Requirement Engineering

Sebuah proses yang kompleks dengan aktifitas yang berbelit-

belit dan banyak aktor yang terlibat Requirement Engineering Process

Sebuah proses yang kompleks dengan aktifitas yang berbelit-

belit dan banyak aktor yang terlibat

  

Kenapa Requirement Engineering

dibutuhkan?

• 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

  Kenapa Requirement Engineering

dibutuhkan?

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

  Kenapa Requirement Engineering dibutuhkan?

• “Kebutuhan yang tidak mencukupi, tidak konsisten, tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut” (Bell&Tayer76)

  Kenapa Requirement Engineering

dibutuhkan?

• • “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)

  

Kenapa Requirement Engineering

dibutuhkan?

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

  

Cara Mendapatkan Kebutuhan

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

  2. Kuesioner Berupa alat komunikasi berupa pertanyaan tertulis yang diberikan kepada customer.

  

Cara Mendapatkan Kebutuhan

  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.

  

Teknik dan Pendekatan

cara mendapatkan kebutuhan

  11. Joint Application Development

  18. Goal Based Approach

  17. Prototyping

  16. Apprenticing

  15. Protocol Analysis

  14. Observation

  13. Ethnography

  12. Requirements Workshops

  10. Brainstorming

  1. Interviews

  9. Group Work

  8. Laddering

  7. Card Sorting

  6. Repertory Grids

  5. Introspection

  4. Domain Analysis

  3. Task Analysis

  2. Questionnaires

  19. Scenarios

  

Requirement Engineering

  

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

  Perbedaan User dan System Requirement

PARAMETER USER SYSTEM

PEMBANDING REQUIREMENT REQUIREMENT

  Tidak terlalu detail Lebih detail Kedetailan Informasi

  Pengguna sistem yang Developer (terkadang Target Pengguna tidak mempunyai customer ingin pengetahuan teknik mengetahui) yang detail Bahasa natural dan Model sistem

  Bentuk Informasi diagram sederhana

  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

  

3. Sistem bisa melayani penghapusan data buku yang tidak sedang

dipinjam atau dikembalikan

  

Requirement Classifiations

Functional versus Non Functional

  Requirement Classifications Functional versus Non Functional 1. Kebutuhan fungsional

   ?

  Requirement Classifications

Functional versus Non Functional

1.

  Kebutuhan fungsional Menunjukkan What the system should do .

  

Menunjukkan fasilitas apa yang dibutuhkan serta

aktivitas apa saja yang terjadi dalam sistem baru.

  Requirement Classifications

Functional versus Non Functional 1. Kebutuhan fungsional

• Fungsi deskripsi kebutuhan
• Laporan baik hardcopy maupun softcopy
• Updating dan query online

• * Penyimpanan data, pencarian kembali dan transfer data

  Requirement Classifications Functional versus Non Functional 1. Kebutuhan fungsional

  Contoh: ?

  Requirement Classifiations

Functional versus Non Functional 1. Kebutuhan fungsional

  Contoh: dalam sistem informasi akademik Mahasiswa dapat melakukan input KRS

  Requirement Classifications Functional versus Non Functional 1. Kebutuhan Non fungsional

  ?

  Requirement Classifications

Functional versus Non Functional 1 . Kebutuhan Non fungsional

• Waktu respon
• Rata-rata waktu untuk kegagalan
• Kebutuhan keamanan
• Akses untuk pengguna yang tidak punya hak

  Requirement Classifiations Functional versus Non Functional 1. Kebutuhan Non fungsional

  Contoh: ?

  Requirement Classifications

Functional versus Non Functional

1.

Kebutuhan Non fungsional

  Contoh:

  Website harus easy to access, easy to use, easy to understand dan menjamin keamanan data member dari orang yang tidak bertanggungjawab.

  

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 e.g. Accuracy, Performance, Security, and Modifiability

  

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

  kebutuhan yang sudah dikumpulkan

  Pengukuran Kebutuhan _Kecepatan PROPERTI _{2. Waktu respon pengguna 1. Transaksi yang diproses per detik} UKURAN _{Ukuran 1. Kbytes}

  3. Waktu refresh layar _{Kemudahan Penggunaan}

  2. Jumlah RAM _{1. Waktu Pelatihan Reliabilitas 1. Rata-rata waktu kegagalan}

  2. Jumlah help yang disediakan _{3. Jumlah kegagalan yang terjadi}

  2. Kemungkinan untuk tidak bisa diakses Robustness _{3. Kemungkinan data hilang ketika terjadi kegagalan 2. Presentase dari kegagalan} ^{1. Waktu restart ketika terjadi kegagalan} Portability ^{1. Persentase dari statement yang berhasil dieksekusi}

  Kapan kita memodelkan kebutuhan?

  

Kapan kita memodelkan kebutuhan?

Traditionally : Fase awal dari siklus pembuatan perangkat lunak Requirements Analysis Design Implementation Inception/ Permulaan

  

Elaboration/

Perluasan Construction/ Pembangunan Transition/ Peralihan RUP , ( Jacobson98 )

  

Dokumen Kebutuhan

Definisi

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

  

Petunjuk Penulisan Dokumen Kebutuhan

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

  Pengguna Dokumen Kebutuhan _Cutomer PENGGUNA KEGUNAAN DOKUMEN _{1. Sarana untuk menspesifkasikankebutuhan sistem dan kebutuhan.} pengecekan apakah sistem yang dibangun sesuai 2. Sarana penyampaian perubahan kebutuhan.

  Manajer Proyek _{2.Dasar perencanaan untuk pembangunansistem} ^{1.Dasar perhitungan penawaran biaya sistem.}

  System Engineer Sarana untuk memahami sistem seperti apa yang akan _dibangun

_{System Maintenance Sarana untuk memahami sistem dan hubungannya antar}

System Test Engineer Dasar untuk melakukanvalidation test pada sistem Engineer bagian-bagiannya