Spesifikasi kebutuhan merupakan aktivitas penting dalam pengembangan perangkat lunak untuk memastikan sistem yang dibangun sesuai dengan kebutuhan pengguna. Dokumen menjelaskan proses rekayasa kebutuhan perangkat lunak meliputi mengidentifikasi, mengkomunikasikan, dan mendokumentasikan kebutuhan fungsional dan non-fungsional dari sistem. Aktivitas utama meliputi memahami ranah sistem, mengumpulkan kebutuhan,

1. APA ITU REKAYASA KEBUTUHAN ??
Mungkin sering kita dengar ketika kita dihadapkan pada
pengguna sistem yang kita buat. Kita selalu mengganggap bahwa
pengguna sering terlambat menyadari kebutuhan fungsional
yang mereka butuhkan.
Mereka tidak mengerti bahwa membuat atau mengubah
program itu pekerjaan yang membutuhkan waktu. Dan waktu kita
terbatas. Kita sebagai pengembang sering merasa terganggu oleh
permintaan-permintaan baru yang tidak pernah berhenti dari
pengguna.

2. APA ITU REKAYASA KEBUTUHAN ??
Banyak permasalahan dalam pengembangan perangkat lunak
berakar pada keterbatasan pemahaman pengembang akan
kebutuhan pengguna terhadap perangkat lunak yang dibangun.

3. MENGAPA PERLU REKAYASA KEBUTUHAN ??
Ada beberapa alasan pokok yang menjadi dasar
mengapa rekayasa kebutuhan itu perlu dilakukan
dalam proses pembuatan suatu perangkat lunak, yaitu:
1. Semua perangkat lunak memiliki spesifikasi
Setiap sistem memiliki tujuan tertentu, yang di
dalamnya ada komponen-komponen yang berfungsi
sebagai masukan, proses, atau keluaran. Dengan kata
lain, setiap perangkat lunak, sekecil atau sesederhana
apa pun, pasti memiliki spesifikasi kebutuhan

4. MENGAPA PERLU REKAYASA KEBUTUHAN ??
2. Permasalahan berawal dari spesifikasi kebutuhan
Menurut Davis (1993) dan Leffingwell (1997), 4000 sampai dengan 6000
kesalahan dalam suatu proyek pembangunan perangkat lunak berawal dari
kesalahan yang dilakukan pada tahap spesifikasi kebutuhan.
Brooks (1987) mengatakan bahwa proyek pengembangan perangkat lunak
seringkali over budget, terlambat, dan cacat atau tidak dapat diandalkan.
Jones (1991) juga menjelaskan bahwa penyebab tunggal terbesar dari kegagalan
tersebut adalah adanya defisiensi pada tahapan spesifikasi kebutuhan.
Hofmann dan Lehner (2001) menemukan bahwa titik-titik kesalahan tersebut
tersebar dalam ranah proses, teknologi, dan sumber daya manusianya.

5. MENGAPA PERLU REKAYASA KEBUTUHAN ??
Permasalahannya lebih disebabkan oleh salah asumsi, asumsi yang
tidak dikomunikasikan, spesifikasi kebutuhan yang tidak memadai,
dan perubahan kebutuhan yang terlihat sedere hana tetapi sering
kurang diperhatikan. Kesemuanya ini berujung pada adanya jurang
perbedaan antara apa yang dipikirkan pengembang untuk
seharusnya dibangun dan apa yang dibutuhkan pelanggannya

6. MENGAPA PERLU REKAYASA
KEBUTUHAN ??
Ada beberapa hal yang dapat menjadi penyebab mengapa
kualitas proses penspesifikasian kebutuhan sistem tersebut
menjadi rendah, yaitu:
a. Kepedulian yang rendah.
b. Adanya jurang pemisah.
c. Permintaan kebutuhan yang tak henti.

7. SlAPA YANG BERKEPENTlNGAN
TERHADAP SISTEM?
Berikut ini ada 13pemangku kepentingan
dalam tahapan pembangunan spesifikasi
kebutuhan perangkat lunak:
1. Pelanggan (Customer)
2. Pemilik sistem (Sistem Owner)
3. Pengguna (User)
4. Analis kebutuhan (Requirements Analyst)
5. Pengembang (Developer)
6. Penguji (Tester)
7. Penulis Dokumentasi (Documentation is
Writer)
8. Manajer proyek (Project Manager)
9. Staf hukum (legal)
10. iStaf manufaktur (Manufacturing
personnel)
11. Penjualan (Sales), pemasaran
(Marketing), dan bagian pendukung,
serta pihak-pihak lain
12. Penyelia (Vendor)
13. Regulator

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

9. APA YANG BUKAN MERUPAKAN BAGIAN DARI
KEBUTUHAN?
Spesifikasi kebutuhan sebaiknya tidak mencantumkan hal-hal yang berkaitan dengan
rincian rancangan maupun implementasi dari sistem.
Spesifikasi kebutuhan juga sebaiknya tidak mencantumkan informasi mengenai
perencanaan proyek pengembangan sistem bersangkutan.
Spesifikasi kebutuhan juga sebaiknya tidak mencantumkan informasi yang berkaitan
dengan proses pengujian sistem, yang meliputi jadwal pelaksanaan, sumber daya
manusia, metode pengujian, alat ukur pengujian dan lain-lain, maupun proses-proses
lainnya dalam rekayasa perangkat lunak yang berada di luar dari batasan proses
penspesifikasian kebutuhan perangkat lunak.

10. IEEE 803-1998
IEEE mengeluarkan suatu dokumen IEEE Standard 830 (1998) yang berisi
rekomendasi praktis bagi spesifikasi kebutuhan perangkat lunak. Dokumen ini
utamanya ditujukan agar dapat membantu:
1. Pengguna perangkat lunak untuk mendeskripsikan secara akurat apa yang
dibutuhkan dari sistem yang hendak dibangun
2. Penyelia perangkat lunak untuk mengerti dengan tepat apa yang diinginkan
pelangggannya
3. Setiap individu untuk mencapai tujuan-tujuan berikut ini:
a) Membangun suatu standar spesifikasi kebutuhan perangkat lunak X (SKPL)
atau Software Requirements Specification (SRS)
b) Menentukan format dan isi dari spesifikasi kebutuhan perangkat lunak yang
hendak dibangun
c) Membangun item-item pendukung lokal tambahan,

11. JENIS KEBUTUHAN PERANGKAT
LUNAK
Secara umum kebutuhan perangkat lunak dapat dibagi ke dalam dua jenis,
yaitu :
1. Kebutuhan fungsional (Functional Requirements)
 Mendeskripsikan layanan, fitur, atau fungsi yang disediakan atau
diberikan oleh sistem bagi penggunanya
2. Kebutuhan non-fungsional (Non-Functional Requirements)
 Mendeskripsikan sekumpulan batasan, karakteristik, dan properti pada
sistem, baik dalam lingkungan pengembangan maupun operasional,
atau atribut kualitas yang harus dipenuhi oleh sistem.

12. CONTOH KEBUTUHAN FUNGSIONAL DAN KEBUTUHAN
NON-FUNGSIONAL
Coba perhatikan sebuah sistem Automatic Teller Machine (ATM) yang sering
kita gunakan sehari-hari.
Kebutuhan Fungsional dari ATM:
1. Mengecek saldo
2. Menarik uang
3. Mentransfer uang
4. Melakukan pembayaran
Kebutuhan Non-Fungsional dari ATM:
1. Pengguna baru membutuhkan waktu belajar maksimal 10 menit untuk dapat
menggunakan fungsi-fungsi utama sistem .
2. Sistem harus tetap berfungsi minimal 10 jam setelah pasokan listrik dari PLN
terhenti.
3. Waktu yang dibutuhkan untuk kembali beroperasi setelah sistem mati
minimal 2 menit.

13. PROSES-PROSES DALAM REKAYASA
KEBUTUHAN
Daur hidup suatu perangkat lunak (software life cycle -SLC) secara umum
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 buah proses, yaitu
proses studi kelayakan (feasibility study) dan proses peluncuran (deployment).
Pengembangan perangkat lunak pada dasarnya muncul karena adanya suatu
kebutuhan baru.

14. Aktivitas utama dalam rekayasa
kebutuhan perangkat lunak
Proses rekayasa kebutuhan ini kita mulai dengan memahami
terlebih dahulu ranah sistem (tujuan, batasan, ruang lingkup,
organisasi, dan sebagainya) yang hendak dibangun.
Kita dapat melihat bahwa setiap aktivitas terkait dan berdampak,
bukan saja dengan aktivitas setelahnya, akan tetapi juga dengan
aktivitas sebelumnya. Setiap aktivitas-aktivitas tersebut memiliki
signifikansi terhadap keberhasilan proses rekayasa kebutuhan
secara keseluruhan

15. RANAH PERMASALAHAN SEBAGAI FOKUS
REKAYASA KEBUTUHAN
Dari sisi pelanggan, kita dapat melihat bahwa dalam pengembangan
perangkat lunak, pelanggan menetapkan suatu tujuan bagi sistem yang
hendak dibangun.
Dari sisi produk, kita dapat melihat bahwa dalam pengembangan
perangkat lunak, pengembang menetapkan entitas atau komponen apa
saja yang membangun produk, dan seperti apa interaksinya. Kemudian
perangkat lunak yang dihasilkan merepresentasikan bagaimana hal
tersebut direalisasikan.
Di sini kita dapat melihat bahwa spesifikasi kebutuhan menjadi
jembatan yang menghubungkan kebutuhan bisnis proses dari pelanggan
dan produk yang hendak dihasilkan pengembang.

16. CONTOH : RANAH PERMASALAHAN SEBAGAI FOKUS REKAYASA
KEBUTUHAN
Perhatikan sekali lagi sistem Automatic Teller Machine (ATM).
Sebutkanlah beberapa hal yang mungkin menjadi tujuan bisnis dari
proyek pembuatan ATM yang menjadi abstraksi solusinya.
Jawab:
Tujuan bisnis dari adanya ATM adalah:
1. Peningkatan kepuasan pelanggan dalam hal melakukan transaksi
perbankan selama 24 jam.
2. Pengurangan kasir.
3. Perluasan jaringan perbankan dengan cara yang ekonomis

17. Tugas eRKa Kelas 6C
(silakan akses google classroom anda)
 Terima Kasih 