Pengenalan Rekayasa

kebutuhan
Jaroji, M. Kom
Profesi yang berkaitan dengan rekayasa
kebutuhan perangkat lunak
 Software Engineer, kisaran gaji 5jt – 19jt
 System Analist, kisaran gaji 6,5jt – 22,5 jt

Sumber: qerja.com
Outline

 Apa itu rekayasa kebutuhan

 Mengapa rekayasa kebutuhan diperlukan
 Definisi Rekayasa kebutuhan
 Siapa yang berkepentingan terhadap system
 Jenis Kebutuhan Perangkat lunak
 Proses-proses dalam rekayasa kebutuhan perangkat lunak
Apa itu rekayasa kebutuhan?

 Banyak permasalahan dalam pengembangan perangkat

lunak berakar pada keterbatasan pemahaman pengembang
akan kebutuhan pengguna terhadap perangkat lunak yang
dibangun.
 Hal ini disebabkan oleh keterbatasan data dan informasi
yang didapatkan pada waktu proses pengumpulan,
penganalisaan, penspesifikasian, verifikasi dan validasi
kebutuhan dari perangkat lunak yang hendak dibangun.
Mengapa rekayasa kebutuhan
diperlukan?
 Semua perangkat lunak memiliki spesifikasi
 Permasalahan berawal dari spesifikasi kebutuhan.

Mengapa kualitas proses penspesifikasian kebutuhan sistem tersebut menjadi

rendah? yaitu sebabkan:
 Kepedulian yang rendah
 Adanya jurang pemisah
 Permintaan kebutuhan yang tak henti.
Definisi rekayasa kebutuhan

 Rekayasa kebutuhan meliputi aktivitas-aktivitas menyelidiki,

mencari, atau mengidentifikasi spesifikasi kebutuhan sistem,
serta mengomunikasikannya kepada pelanggan maupun
pengembang, baik secara lisan maupun tulisan.
 Akan tetapi, perlu diperhatikan bahwa Rekayasa Kebutuhan
bukanlah rincian rancangan dan implementasi dari sistem,
informasi-informasi yang berkaitan dengan pengelolaan
perencanaan proyek pembangunan sistem, ataupun
informasi-informasi yang berkaitan dengan pengujian sistem.
Siapa yang berkepentingan dengan
system?
 Dikenal dengan istilah stakeholder atau pemangku
kepentingan
 Adalah pihak-pihak yang memiliki kepentingan terhadap
perangkat lunak
 Salah satu penyebab kegagalan proyek pengembangan PL
adalah pada proses rekayasa kebutuhan dan sumbernya
berasal dari pemangku kepentingan.
Klasifikasi pemangku kepentingan (1)

1. Pelanggan (Customer)
 Seseorang / organisasi yang meminta jada pengembang untuk
mengembangkan PL
 Termasuk pemilik modal (investor), pemilik sistem (owner),
pengguna (user)
2. Pemilik sistem (System Owner)
 Seseorang / kelompok orang yang berperan sebagai pemilik dari proses bisnis yang
direpresentasikan dalam sistem yang dibangun.
 Pemilik sistem biasanya biasanya sekaligus penyedia dana / pemilik modal dari
proyek pengembangan PL
Klasifikasi pemangku kepentingan (2)
3. Pengguna (user)
 Setiap orang yang secara langsung menggunakan / mengoperasikan PL
 Pengguna sering disebut operator
4. Regulator
 Seseorang / suatu organisasi yang menetapkan aturan dan batasan baik dalam
pengembangan maupun pengoperasian PL
5. Penyedia (vendor)
 Seseorang / sekelompok orang yang menyediakan teknologi atau jasa yang
digunakan bagi pengembangan atau pengoperasian PL
6. Pengembang (developer)
 Sekelompok orang yang bertanggung jawab mengembangkan PL
 Termasuk didalamnya manajer proyek, pemimpin tim, analis sistem
programmer / implementator dan penguji (tester)
Klasifikasi pemangku kepentingan (3)
7. Analis kebutuhan (requirement analyst)
 Menuliskan
spesifikasi kebutuhan dari suatu PL dan
mengkomunikasikannya kepada komunitas pengembang
8. Penguji (tester)
 Merupakan sub kelas dari pengembang yang
menentukan apakah sistem memang sudah berperilaku
seperti yang ditetapkan
9. Penulis Dokumentasi (documentation’s writer)
 Merupakan sub kelas dari pengembang yang
menghasilkan user manual, mining material dan sistem
bantuan
Klasifikasi pemangku kepentingan (4)
10. Manajer Proyek (Project Manager)
 Merupakan sub-kelas dari pengembang yang merencanakan proyek
dan mengarahkan tim pengembang untuk menghasilkan produk
yang sukses.
11. Staf Hukum (Legal) dan non legal
 Yang memastikan bahwa produk yang dihasilkan sesuai dengan
hukum dan peraturan yang berlaku.
12. Staf Manufacture (Manufacturing Personel)
 Merupakan sub-kelas dari pengembang yang harus membangun
produk-produk yang membentuk sistem
13. Penjualan (Sales), Pemasaran (Marketing)
Jenis kebutuhan perangkat lunak

 Kebutuhan Fungsional (Functional Requirement)

mendeskripsikan layanan, fitur atau fungsi yang disediakan
atau diberikan oleh sistem bagi penggunaannya.
 Kebutuhan Non Fungional (Non-Functional
Requirement) mendeskripsikan sekumpulan batasan,
karakteristik dan properti pada sistem, baik dalam
lingkungan pengembangan maupun operasional atau
atribut kualitas yang harus dipenuhi oleh sistem.
Kebutuhan Non Fungsional: IEEE 803:1993
IEEE 803: 1993 mengelompokkan kebutuhan non fungsional kedalam 2
kategori kelompok yaitu:
1. Faktor kualitas eksternal merupakan kategori kualitas yang dapat
diobservasi atau menjadi ketertarikan utama dari pelanggan.
 ketepatan (correctness)
 Ketahanan (Robustness)
 Unjuk kerja (performance)
 ketersediaan dan kualitas antarmuka (interface)
 keandalan (reliability)
 ketersediaan (availability)
Contoh:

Sumber: https://medium.com/@asyrofist/pengenalan-rekayasa-kebutuhan-57e1d0a940b8
Kebutuhan Non Fungsional: IEEE 803:1993
IEEE 803: 1993 mengelompokkan kebutuhan non fungsional kedalam 2
kategori kelompok yaitu:
2. Faktor kualitas internal merupakan kategori kualitas yang dapat
diobservasi atau menjadi ketertarikan utama dari pengembang.
 Kemudahan membaca/ memahami struktur perangkat lunak
(readibility)
 kemampuan untuk dilakukan pengujian (testability)
 ketersediaan dan kualitas dokumentasi (documentation)
 kemudahan pemeliharaan (maintainability)
 adaptasi terhadap lingkungan berbeda (portability)
Proses-proses dalam rekayasa kebutuhan
perangkat lunak
 Proses dalam rekayasa kebutuhan perangkat lunak dapat digambarkan
dalam daur hidup perangkat lunak (software life cycle – SLC).
 Ada dua siklus kehidupan utama dari suatu perangkat lunak yaitu
 daur hidup pengembangan perangkat lunak (software development life
cycle – SDLC)
 daur hidup pengoperasian perangkat lunak (software operational life
cycle – SOLC).
 Kedua siklus perangkat lunak tersebut dihubungkan oleh dua proses yaitu
 proses studi kelayakan (feasibility study) dan
 proses peluncuran (deployment).
 Go Studi Kelayakan Perubahan kebutuhan

Not
Rekayasa Go
Perawatan
kebutuhan
Tidak sesuai
spesifikasi

Perancangan Implementasi Pengoperasian

Daur Hidup
Pengoperasian
Pengujian

Peluncuran
Daur Hidup
Pengembangan
 Sebuah perangkat lunak akan mengalami
pengembangan (update) dikarenakan kebutuhan baru
yang muncul.
 Untuk melakukan pengembangan perangkat lunak perlu
dilakukan studi kelayakan untuk mengetahui kebutuhan
tersebut masih dapat dipenuhi oleh system perangkat
lunak yang ada atau tidak.
 Jika berdasarkan hasil studi kelayakan system yang ada
sudah tidak dapat memenuhi kebutuhan baru tersebut
maka diputuskan untuk mengembangkan system
perangkat lunak yang baru (berdasarkan system
lama/baru).
Q and A