APA ITU REKAYASA KEBUTUHAN ??

Presentasi berjudul: "APA ITU REKAYASA KEBUTUHAN ??"— Transcript presentasi:

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: 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: Kepedulian yang rendah. Adanya jurang pemisah. Permintaan kebutuhan yang tak henti.

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

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

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

11 IEEE 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: Membangun suatu standar spesifikasi kebutuhan perangkat lunak X (SKPL) atau Software Requirements Specification (SRS) Menentukan format dan isi dari spesifikasi kebutuhan perangkat lunak yang hendak dibangun Membangun item-item pendukung lokal tambahan,

12 JENIS KEBUTUHAN PERANGKAT LUNAK
Secara umum kebutuhan perangkat lunak dapat dibagi ke dalam dua jenis, yaitu : Kebutuhan fungsional (Functional Requirements) Mendeskripsikan layanan, fitur, atau fungsi yang disediakan atau diberikan oleh sistem bagi penggunanya 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.

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

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

15 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

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

17 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