Kebutuhan Fungsional dari ATM

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.
APA ITU REKAYASA KEBUTUHAN ??
Banyak permasalahan dalam pengembangan perangkat lunak berakar pada
keterbatasan pemahaman pengembang akan kebutuhan pengguna terhadap
perangkat lunak yang dibangun.
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 komponenkomponen yang berfungsi sebagai masukan, proses, atau keluaran. Dengan kata
lain, setiap perangkat lunak, sekecil atau sesederhana apa pun, pasti memiliki
spesifikasi kebutuhan
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.
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
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.
SlAPA YANG BERKEPENTlNGAN TERHADAP SISTEM?
Berikut ini ada 13pemangku kepentingan dalam 8. Manajer proyek (Project Manager)
tahapan pembangunan spesifikasi kebutuhan 9. Staf hukum (legal)
perangkat lunak:
10. iStaf manufaktur (Manufacturing
personnel)
1. Pelanggan (Customer)
11. Penjualan (Sales), pemasaran (Marketing),
2. Pemilik sistem (Sistem Owner)
dan bagian pendukung, serta pihak-pihak
3. Pengguna (User)
lain
4. Analis kebutuhan (Requirements Analyst) 12. Penyelia (Vendor)
5. Pengembang (Developer)
13. Regulator
6. Penguji (Tester)
7. Penulis Dokumentasi (Documentation is
Writer)
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 informasiinformasi yang berkaitan dengan pengujian sistem.
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 informasiinformasi yang berkaitan dengan pengujian sistem.
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.
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,
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.
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.
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.
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
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.
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 tra: perbankan selama
24 jam.
2. Pengurangan kasir.
3. Perluasan jaringan perbankan dengan cara yang ekonomis