REKAYASA KEBUTUHAN SISTEM Pertemuan 3 Matakuliah : Konsep object-oriented Tahun : 2009 REKAYASA KEBUTUHAN SISTEM Pertemuan 3

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

Place: Sue office 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 Minutes Place: 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 concerns Current security procedures Initial ideas Follow-up actions Document to be brought into interview” Rough plan of building and sites Any 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)

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

Rekayasa Kebutuhan Sistem Menemukan kebutuhan sistem

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

Place: Sue office 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 Minutes Place: 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 concerns Current security procedures Initial ideas Follow-up actions Document to be brought into interview” Rough plan of building and sites Any 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)