Rekayasa Ke butuhan ?

Ialah bagian yang tidak terpisahkan dari kegiatan rekaya perangkat lunak. Rekayasa kebutuhan
mempunyai peran yang cukup penting bahkan akan menentukan keberhasilan dari suatu produk
rekayasa perangkat lunak. Dibagi menjadi 4 fase yaitu :

 Requirements Engineering kebutuhan sistem

 Software requirements kebutuhan software
 Software Engineering
 User
 Customer

Teori yang mendukung rekayasa kebutuhan ?

1. Hukum glass ( Robert Glass ), kekurangan kebutuhan requirements deficiences adalah

sumber utama dari kegagalan proyek. Kekurangan kebutuhan menimbulkan masalah
dibanyak proyek. Kebutuhan yang ditentukan mungkin salah atau tidak cukup perhatian
yang diberikan pada definisi kebutuhan.
2. Hukum Boehm pertama, kesalahan yang paling sering selama menentukan kebutuhan
requirenments adalah kegiatan design yang lebih mahal.
3. Hukum Boehm kedua, secara signifikan mengurangi kebutuhan dan kesalahan design,
terutama untuk user interface.

Kegiatan rekayasa kebutuhan ?

Kegiatan dalam rekayasa kebutuhan memiliki aspek penting dalam menunjang kesuksesan
proyek rekayasa perangkat lunak. Kegiatannya adalah sebagai berikut :

 Studi kelayakan atau analisis resiko, untuk sistem yang lebih besar, studi kelayakan perlu
dilakukan sebelum kebutuhan secara resmi diterima. Dalam proses ini, untuk
mendapatkan jawaban
 Pengungkapan kebutuhan dan prioritas ( Equirenments elicitation and prioritization ),
kebutuhan harus dikumpulkan dari sumber yang dapat berkontribusi terutama dari calon
pelanggan dan pengguna
 Requirenments spesification, menentukan kebutuhan fungsional dan non fungsional

1. Kebutuhan fungsional, adalah suatu kebutuhan yang menyatakan prilaku yang harus ada
pada sistem
2. Kebutuhan non fungsional, sebenarnya batasan yabg harus ada pada sistem dan
bagaimana dalam membentuk sistem tersebut

 Performance konstraint, batasan ini menunjukkan spesifikasi bagaimana sistem bekerja

ketika kebutuhan fungsional telah bekerja
 Devolop ment constraint, batasan ini menunjukkan sebagai pelengkap dari performance
constraint. Batasan ini lebih cenderung pada batasan pada level menegement proyek.
Secara prinsip harus legkap dan konsisten.
Spesifikasi kebutuhan ?

Ditinjau dari sisi pemakai dokumentasi requirenments dapat dipisahkan menjadi 2 bagian :

1. User requirenment lebih ke bahasa formal dan non teknis. Diperuntukkan untuk
kepentingan pelanggan dan end user
2. System requirenment lebih ke bahasa formal teknis. Diperuntukkan untuk kepentingan
perancangan dan perekayasa sistem

 Penerimaan validasi dan persetujuan kebutuhan, Cara terbaik untuk mencapai kebutuhan
pelanggan adalah melalui partisipasi pengguna.

Dokumentasi kebutuhan ( Documentation of Requirenments )

Penulisan dokumentasi kebutuhan merupakan aspek yang “critical” sehingga memungkinkan

suatu iterasi yang melibatkan seluruh ‘stakeholders’ sangat mungkin terjadi :

 Digunakan sebagai dasar validasi jika terjadi konflik antar stakeholders

 Sebagai kontrak antara customer dan developer
 Dasar dari sistem bagi perancang
 Ukuran bagi manager proyek dalam pematauan jalannya proyek
 Sumber daya untuk menejemen kebutuhan dan kelayakan kebutuhan
 Sumber untuk mengformasikan test plan untuk QA dan pengujian tim
 Dasar untuk pengembangan perputaran proyek

Rekayasa Kebutuhan ?

Ialah bagian yang tidak terpisahkan dari kegiatan rekaya perangkat lunak. Rekayasa kebutuhan
mempunyai peran yang cukup penting bahkan akan menentukan keberhasilan dari suatu produk
rekayasa perangkat lunak. Dibagi menjadi 4 fase yaitu :

 Requirements Engineering kebutuhan sistem

 Software requirements kebutuhan software
 Software Engineering
 User
 Customer

Teori yang mendukung rekayasa kebutuhan ?

1. Hukum glass ( Robert Glass ), kekurangan kebutuhan requirements deficiences adalah

sumber utama dari kegagalan proyek. Kekurangan kebutuhan menimbulkan masalah
dibanyak proyek. Kebutuhan yang ditentukan mungkin salah atau tidak cukup perhatian
yang diberikan pada definisi kebutuhan.
2. Hukum Boehm pertama, kesalahan yang paling sering selama menentukan kebutuhan
requirenments adalah kegiatan design yang lebih mahal.
 3. Hukum Boehm kedua, secara signifikan mengurangi kebutuhan dan kesalahan design,
terutama untuk user interface.

Kegiatan rekayasa kebutuhan ?

Kegiatan dalam rekayasa kebutuhan memiliki aspek penting dalam menunjang kesuksesan
proyek rekayasa perangkat lunak. Kegiatannya adalah sebagai berikut :

 Studi kelayakan atau analisis resiko, untuk sistem yang lebih besar, studi kelayakan perlu
dilakukan sebelum kebutuhan secara resmi diterima. Dalam proses ini, untuk
mendapatkan jawaban
 Pengungkapan kebutuhan dan prioritas ( Equirenments elicitation and prioritization ),
kebutuhan harus dikumpulkan dari sumber yang dapat berkontribusi terutama dari calon
pelanggan dan pengguna
 Requirenments spesification, menentukan kebutuhan fungsional dan non fungsional

1. Kebutuhan fungsional, adalah suatu kebutuhan yang menyatakan prilaku yang harus ada
pada sistem
2. Kebutuhan non fungsional, sebenarnya batasan yabg harus ada pada sistem dan
bagaimana dalam membentuk sistem tersebut

 Performance konstraint, batasan ini menunjukkan spesifikasi bagaimana sistem bekerja

ketika kebutuhan fungsional telah bekerja
 Devolopment constraint, batasan ini menunjukkan sebagai pelengkap dari performance
constraint. Batasan ini lebih cenderung pada batasan pada level menegement proyek.
Secar a prinsip harus legkap dan konsisten.

Spesifikasi kebutuhan ?

Ditinjau dari sisi pemakai dokumentasi requirenments dapat dipisahkan menjadi 2 bagian :

1. User requirenment lebih ke bahasa formal dan non teknis. Diperuntukkan untuk
kepentingan pelanggan dan end user
2. System requirenment lebih ke bahasa formal teknis. Diperuntukkan untuk kepentingan
perancangan dan perekayasa sistem

 Penerimaan validasi dan persetujuan kebutuhan, Cara terbaik untuk mencapai kebutuhan
pelanggan adalah melalui partisipasi pengguna.

Dokumentasi kebutuhan ( Documentation of Requirenments )

Penulisan dokumentasi kebutuhan merupakan aspek yang “critical” sehingga memungkinkan

suatu iterasi yang melibatkan seluruh ‘stakeholders’ sangat mungkin terjadi :

 Digunakan sebagai dasar validasi jika terjadi konflik antar stakeholders

 Sebagai kontrak antara customer dan developer
  Dasar dari sistem bagi perancang
 Ukuran bagi manager proyek dalam pematauan jalannya proyek
 Sumber daya untuk menejemen kebutuhan dan kelayakan kebutuhan
 Sumber untuk mengformasikan test plan untuk QA dan pengujian tim
 Dasar untuk pengembangan perputaran proyek

Requirement Enginering berfungsi untuk membantu pengembang mengerti masalah yang akan
dibuatkan solusinya dalam bentuk perangkat lunak. Tahapan ini adalah bagian dari proses
komunikasi yang berlanjut pada pemodelan.
Rekayasa Kebutuhan merupakan proses membentuk layanan yang dibutuhkan pelanggan dari
suatu sistem dan juga batasan sistem yang akan beroperasi dan dikembangkan. Kebutuhan adalah
deskripsi dari layanan sistem dan batasan (constraint) sistem yang dihasilkan selama proses
rekayasa kebutuhan.

Bentuk pernyataan kebutuhan

 Kalimat abstrak yang cenderung terdengar ‘high level’ yang masih di awangawang, tidak
rinci
 Kalimat yang lengkap dan rinci, tapi mungkin justru tidak memberikan gambaran yang
jelas secara keseluruhan
 Bentuk fungsi matematika

Pernyataan kebutuhan ini memiliki dua manfaat

 Dasar untuk membuka/mengikuti tender pekerjaan

- Pengembang perangkat lunak biasanya mengikuti ‘tender’ untuk mendapatkan suatu
pekerjaan
- Sifat pernyataan untuk kebutuhan ini ‘open to interpretation’
 Dasar untuk pembuatan kontrak pekerjaan
- Kontrak memiliki kekuatan hukum, pengembang harus mengikuti panduan yang ada di
kontrak dan sekaligus merupakan jaminan bagi pelanggan/pengguna untuk mendapatkan
perangkat lunak sesuai keinginannya

Jenis Kebutuhan PL

 Kebutuhan Pengguna (User Requirement)

- Menggunakan bahasa seharihari
- Ungkapan pernyataan dalam bahasa ‘manusia’, kadang bisa disertai dengan gambar.
- Pernyataan ini bisa berisi harapan apa yang dapat diberikan oleh sistem, juga kadang
batasan-batasan operasional
- Kebutuhan ini akan dituliskan untuk di yakinkan kembali ke pengguna (atau
pelanggan).
Contoh : Pimpinan perpustakaan ingin ada laporan bulanan yang menampilkan data
jumlah buku yang dipinjam dan jumlah peminjam
  Kebutuhan Sistem (System Requirement)
- Menggunakan bahasa teknis
– Berisi pernyataan dalam dokumen yang terstruktur yang berisi deskripsi rinci dari
fungsi, layanan dan batasan operasional dari suatu sistem
– Mendefinisikan apa yang harus diimplementasikan, hingga kemungkinan menjadi
bagian dari kontrak antara ‘client’ dan kontraktor.
– Dokumentasi System Requirement
Contoh : Sistem akan menyiapkan laporan akhir bulan setiap tanggal akhir bulan.

User Requirement sifatnya lebih umum (high level). Sedangkan spesifikasi kebutuhan sistem
sifatnya sudah lebih rinci/detil.
Kebutuhan Fungsional dan NonFungsional (NF)

 Kebutuhan Fungsional
– Pernyataan tentang layanan yang harus diberikan oleh sistem
– Bagaimana sistem harus memberikan respon terhadap suatu masukan
– Kadangkadang termasuk juga “apa yang tidak perlu dilakukan sistem”
 Kebutuhan NonFungsional (NF)
Berisi pernyataan tentang batasan (constraint) dari layanan/fungsi yang ditawarkan oleh
sistem Contohnya: Timing constraint, Development constraint, Standard constraint