Rekayasa Kebutuhan Sistem

Menemukan kebutuhan sistem

Aturan rekayasa kebutuhan Untuk membangun atau memperluas sebuah bangunan seorang

arsitek harus: Identifikasikan user yang memerlukan pemanguan atau perluasan Temukan user yang potensial Berusaha familiar dengan lingkungan dimana perluasan ingin

dibangun Bertanya kepada kepada user tentang persoalan persoalan yang

muncul dan dengarkan setiap kebutuhan dari perluasan baru tersebut

Waspada dengan permintaan dari orang yang bukan klien, privacy tetangga pada malam hari,cahaya, akses, dan aturan pemerintah tentang bangunan didaerah tersebut.

Hasilkan model inisial untuk perluasanan bangunan, mengandung impresi artistik.

Diskusikan tentang model atau rencana dan modifikasi sampai klien merasa puas dengan model, tepat mengambarkan permintaan klien untuk perluasan bangunan

Aturan rekayasa kebutuhan(lanj’)

Rencanakan untuk meminta surat ijin, dimana modifikasi tersebut harus memenuhi kebutuhan klien dan juga tidak mengganggu teangga dan harus sesuai dengan regulasi pemerintah tentang bangunan.

Setiap proses yang diselesaikan, dimodelkan dan dan sesuai dengan kebutuhan mungkin akan membutuhkan waktu beberapa bulan, tetapi setelah semuanya selesai pembangunan akan dapat dimulai.

Dalam proses pembangunan user dapat berubah pikiran . Seperti perubahan bentuk jendela, tetapi perubahan dari bentuk pokoknya tidak diperkenankan lagi.

Aturan didalam rekayasa kebutuhan (lanj’)

Rekayasa kebutuhan sistem hampir sama dengan aturan seorag arsitek.

Pekerjaan rekayasa kebutuhan lebih sulit dari pada perkejaan arsitek. Rekaya kebutuhan bekerja didalam entiti yang abstrak, tidak dapat

dilihat dirasakan dan didengar( sebuah software sistem), hanya keluaran dari sebuah proses internal.

A extra complication for requirement engineer, when constructing model and requirement, represent a process or a collection of data.

Proses rekayasa kebutuhan

Istilah proses rekayasa kebutuhan berarti sekumpulan tugas mengidentifikasi, mencatat dan memvalidasi kebutuhan dari sistem.

Kebutuhan adalah sebuah pernyataan yang berasal dari klien, user, atau orang orang yang bersinggungan dengan sistem(stake-holder), yang mendefinisikan fitur-fitur yang dibutuhkan didalam sebuah sistem

Kebutuhan sering dilukiskan dengan kata WHAT system will do (apa yang akan lakukan sistem) daripada HOW it will do it (bagaimana sistem bekerja)

Proses rekayasa kebutuhan (lanj’)

Kebutuhan(Requirement): Kebutuhan fungsional Kebutuhan non fungsional

Kebutuhan non fungsional: Usability Performance Reliability Security

Usability

Bagaimana sebuah sistem dapat menarik seorang user, memberikan bantuan dengan level yang tepat, dan sejalan dengan jalan kerja yang user pilih.

Performance

Aspek dari sistem, secepat apa sistem dapat merespon untuk menjaga kenyamanan yang user butuhkan dan seberapa besar transaksi yang dapat dilaksanakan

Reliability

Berelasi dengan kepercayaan yang klien dan harapan user bahwa sistem berjalan sesuai dengan yang diharapkan

Security

Bagaimana mencegah akses yang tidak diijinkan kedalam sistem untuk mengubah data yang rahasia

Tujuan Rekayasa Kebutuhan

Menghasilkan spesifikasi sistem yang disetujui.

Specifikasi harus harus mewakili pengertian dan kebutuhan stake holder.

Spesifikasi sebagai kendaraan komunikasi antara developer, user dan stakeholder.

Spesifikasi adalah kontrak legal antara developer dan klien Spesifikasi adalah dokumen yang memandu programer dalam

mengimplementasikan sistem

Tujuan Rekayasa Kebutuhan(lanj’)

Dari banyak variasi bagaimana rekayasa kebutuhan, pada dasarnya memiliki 3 tahap utama: Pencarian /Mendapatkan kebutuhan (Requirement

elicitation). Spesifikasi kebutuhan (Requirement specification). Validasi kebutuhan (Requirement validation).

Mendapatkan kebutuhan

Mendapatkan kebutuhan adalah tugas untuk menemukan semaksimal mungkin tentang organisasi klien, masalah klien sekarang ini dan apa yang ingin sistem yang baru lakukan untuk mereka

Kemampuan komunikasi baik tulisan maupun lisan saja dibutuhkan untuk mendapatkan kebutuhan, sejak. Sukses tidak nya sebuah metode tergantung kepada kemampuan komunikasi dengan user dan klien

Metode untuk menemukan kebutuhan

Wawancara(Interviews) Kuisioner(Questionnaires) Pertemuan strukutral(Structured meeting) Skenario(Scenarios) Prototipe(Prototyping) Mencari semua sumber kebutuhan

Wawancara(Interviews)

Wawancara adalah cara mendapatkan kebutuhan informasi tentang klien atau mengecek pengertian kebutuhan yang spesifik.

Digunakan untuk menjelaskan detil dari sistem yang baru dan untuk mendapatkan feedbacknya.

Adalah sangat penting antara pewawancara dengan yang diwawancara jelas tentang apa yang dibicarakan dan apa yang ingin didapatkan dari interview tersebut

D&B System – Interview Plan

System:Just A Line Project Reference:JaL/MB/00

Participant: Sue Preston (Just a line)

Harry Preston (Just a line)

Mark Barnes (D&B)

Date:

10/4/2002

Time:

14:00

Duration:

45 MinutesPlace:

Sue office

Purpose of Interview:

Preliminary meeting to identify problems and requirements regarding security at the Just A Line

Agenda:Problem with security and any other concernsCurrent security proceduresInitial ideasFollow-up actions

Document to be brought into interview”Rough plan of building and sitesAny documents relating to current security procedures

Interviews(lanj’)

Pencari kebutuhan bertugas ,membuat detail yang relevan tentang orang yang akan di interview seperti halnya masa lalunya, posisi, lama bekerja, spesial skill yang dimiliki seperti keahlian komputer.

Kemampuan untuk mendengarkan secara baik dan mengidentifikasikan apa yang penting adalah keahlian yang penting dalam rekayasa kebutuhan.

Interviews(lanj’)

Sebuah interview yang berguna akan menghasilkan sejumlah informasi untuk rekayasa kebutuhan yang berbeda-berbeda seperti : Informasi yang sudah ada dalam struktured list , form,

guidelines, dan perarturan. Informasi tentang prosedur perusahaan Ukuran seberapa banyak pelanggan dan rata-rata

ukuran order; Problem klien yang teridentifikasi dari sistem yang

sekarang Kebutuhan awal yang diinginkan dalam sistem yang

baru. Informasi tidak langsung yang berhubungan dengan

sistem.

Interviews(lanj’)

Memilih orang yang tepat untuk di interview adalah hal yang penting untuk mendapatkan kebutuhan yang sesungguhnya dari sistem yang baru.

Kuisioner(Questionnaires)

Sebuah bentuk interview terhadap klien dan user, form yang berguna untuk mendapatkan informasi

Sangat efektif jika berukuran kecil dan didefinisikan dengan benar, digunakan untuk mendapatkan informasi dari sekelompok besar user

Seperti halnya sebuah interview, adalah sangat penting untuk mempersiapkan kuisioner dengan benar, testing kepada sejumlah orang dan melihat hasillnya apakah sudah menghasilkan informasi yang berguna..

Adalah tugas pencari kebutuhan untuk meyakinkan user bahwa ini sangat berguna dan jawabannya akan digunakan.

Kuisioner(lanj’)

Macam-macam pertanyaan dalam kuisioner: Pilihan Ganda Jawaban Singkat, dan Jawaban panjang

Yakinkan bahwa pertanyaan sangat jelas dan menuju langsung ke permasalahan jika mungkin.

The Pertanyaan harus mempunyai informasi yang cukup untuk mengisinya.

Lihat kuisioner pada halaman 54 buku britton, Bab 4

Pertemuan Struktural

Suksesnya pencarian kebutuhan seringkali didapatkan dengan pertemuan struktural dengan stakeholder, siapa saja yang mungkin ikut tidak hanya klien dan user tetapi juga manager, marketing staff dan juga trainner.

Pertemuan seperti ini mengambil waktu dari banyak orang dan oleh karena itu harus dengan hati-hati direncanakan dan dengan agenda yang jelas.

Managemen yang efektif selama pertemuan sangat penting untuk mencegah konflik yang tidak perlu dalam mencapai tujuan utama.

Skenario

Skenario adalah sebuah deskripsi dengan bahasa sehari-hari yang mengambarkan urutan interaksi antara user dengan sistem.

Prototyping

Prototyping sangat baik digunakan pada user yang kurang yakin dengan apa yang mereka butuhkan

Ide awal dapat ditampilkan dengan skeleton prototipe.

Lebih mudah memberikan komentar kepada sesuatu yang nyata.

Mencari segala sumber informasi

Sumber lain seperti: Literatur tentang problem doomain seperti koran dan

market survey Informasi dari web (WWW)

Spesifikisi kebutuhan

Spesifikasi kebutuhan adalah ekspansi pengetahuan developer tentang problem domain dan keinginan klien.

Spesifikasi kebutuhan berisi informasi tentang isue yang relevan, informasi yang didapat dalam pencarian kebutuhan, analisa, interpretasi dan tercatat dalam form yang sesuai

Bahasa Formal Specifikasi

Spesifikasi menjelaskan dengan menggunakan bahasa formal dan berdasarkan logik.

Spesifikasi formal membawa keuntungan bagi pembangunan sistem.

Prototyping

Salah sati cara untuk mencatat kebutuhan adalah dengan menggunakan prototyping, dimana developer membangun sebuah versi sederhana dari sebagian sistem.

Model komunikasi, pada saat yang sama user dapat merasakan bagaimana sistem akan bekerja dan bagaimana tampilannya.

Spesifikiasi Kebutuhan

Berisi: Nomor permintan Sumber permintaan Versi Deskripsi permintaan Prioritas (E)ssential, (D)esirable, (O)ptional. Daftar permintaan yang berhubungan. Alternatif permintaan jika ada. Dokumen yang berhubungan, diagram atau tabel. Perubahan dari permintaan sebelumnya

No. Source Date Description

Priority Related Reqs.

Alternative Reqs.

Related

Docs.

Change Detail

4.4 Meeting with Sue and Harry Preston

10/4/2003

Ensure that only staff and visitor are able to use the car park.

E 2.9

4.6

List of staf cars no.

Specification of requirement from the Just A Line system

Spesifikasi kebutuhan

IEEE Standar 830-1993: Correct: Spesifikasi kebutuhan harus memiliki statement

yang benar. Consistent: tidak berisi statement yang bertolak belakang Unambiguous: hanya memiliki satu pengertian Traceable: terlihat jelas dari sumber asli sampai kepada

sistem final. Verifiable: dapat dicek apakah sistem sesuai dengan

kebutuhan. Understandable: dapat dimengerti oleh orang yang tidak

mengerti komputer Modifiable: mudah untuk mencari alternatif lain Comprehensive: tidak menberikan perbedaan didalam

spesifikasi

Validasi kebutuhan

Kegunaan: untuk menjadikan kebutuhan sesuai dengan kebutuhan stakeholder

Untuk menyakinkan bahwa spesifikasi kebutuhan itu akurat, konsisten dan relevan untuk mengambarkan kebutuhan stakeholder dan apa yang diinginkan didalam sistem yang ingin dibuat.

Metode validasi

Interview Mengkombinasikan metode yang sama

dalam pencarian kebutuhan Fagan inspections Prototyping

Fagan Inspections

Fagan Inspection bertujuan untuk menemukan kesalahan yang tidak tercover didalam setiap tahap pembuatan sistem

Sebuah langkah sistematik dan terstuktur untuk mengecek dokumen yang dihasilkan seperti spesifikasi kebutuan.

Berkonsentrasi pada komponen-komponen kecil dalam dokumentasi

Tahap-tahap Fagan Inspection

Perencanaan Gambaran , ketika dokumen dihasilkan Persiapan, ketika setiap komponen dipelajari

secara individual Pertemenuan, membahas komponen secara

bersama-sama Pengerjaan ulang Inspeksi ulang

Kesulitan dalam rekayasa kebutuhan

Klien memiliki sedikit sekali pengetahuan dan kemampuan sistem komputer.

User memiliki pengertian terbatas tentang problemnya sendiri dan kebutuhannya

User bingung dan tidak konsisten dan berulang ulang berubah pendapat

Menunjukkan konflik dengan stakeholder yang lain

Kebutunan dinamik dan berubah-ubah selama rekayasa kebutuhan.