Rekayasa Kebutuhan Sistem

Slides:



Advertisements
Presentasi serupa
Pertemuan 4.
Advertisements

ANALISIS SISTEM.
Interaksi Manusia dan Komputer
Pengelolaan Proyek Sistem Informasi
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Pert 1-2. Software Engineering merupakan komputer yang terasosiasi dengan dokumentasi perangkat lunak seperti dokumentasi kebutuhan, model disain, dan.
TIB15 - ANALISIS & DESAIN BERORIENTASI OBJEK
Software Requirements Spefication (SRS)
PERENCANAAN PROSES PERANGKAT LUNAK
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK
Requirement.
Evaluasi IMK.
Konsep & Prinsip Analisis
Analisis Kebutuhan PERANGKAT LUNAK
Pengelolaan Proyek Sistem Informasi
Analisis Sistem Kuliah M-4.
Kelompok 1 Mochammad. Nasir Mochammad. Nasir Isommuddin Isommuddin T. Yusak D
Kelompok 5 : Asdin Ines Lestari Neng Susanti Siti Robiahtul Adawiyah Vena Senja Maba SOFTWARE REQUIREMENTS.
Analisis Kebutuhan PL dan Spesifikasi PL
Pengumpulan dan analisis kebutuhan database dengan metode fact finding
Pengetahuan Auditor untuk Interface & Dialog
Pengetahuan Auditor untuk Interface & Dialog
Memodelkan System - Bagian 1
Mengidentifikasi kebutuhan dan Menetapkan persyaratan
APA ITU REKAYASA KEBUTUHAN ??
Perspektif Pemangku Kepentingan
ANALISIS KEBUTUHAN.
Interaksi Manusia Dan Komputer
PriNciples That Guide Practice
Step 14 : Uji, Uji, dan Uji Ulang
Framework for the Application of System Thinking
REKAYASA PERANGKAT LUNAK
Pengumpulan Kebutuhan dan Dokumentasi
TEKNIK EVALUASI Rima Dias Ramadhani.
Evaluasi IMK.
4 Managing Software Requirement Analisis Kebutuhan
Sampling dan Investigasi Hard Data
Evaluasi IMK.
Prototyping
PROTOTIPE (Berkerja dengan Model Pertama)
Menguji Rancangan Antarmuka Pertemuan 4
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Materi Habis Uts IMK Prototyping
Rekayasa Kebutuhan bagian 2 Pertemuan 4
Analisis Kebutuhan.
ANALISIS SISTEM.
SQA Team.
Interaksi Manusia dan Komputer (Proses Desain)
Mengidentifikasi kebutuhan dan Menetapkan persyaratan
Pengembangan Kebutuhan Bisnis
Evaluasi IMK.
Rekayasa Kebutuhan.
Analisa [Kebutuhan] Sistem
Teknik Mencari Fakta untuk Persyaratan Penemuan
PENGEMBANGAN PERANGKAT LUNAK
MEMODELKAN SISTEM Bagian 1 Pertemuan 13
Pertemuan 8 Rekayasa Kebutuhan
Evaluasi IMK.
REKAYASA WEB Development Process
Dokumentasi Rekomendasi Teknologi
Hanya digunakan di lingkungan Universtias
Evaluasi IMK.
Interaksi Manusia dan Komputer (Proses Desain)
REKAYASA KEBUTUHAN SISTEM Pertemuan 3
Prototyping Deskripsi Desain  Bagaimana kita menyatakan dengan cepat gagasan-gagasan desain ?  Tidak ada koding.
Proses Rekayasa Kebutuhan
Bab 2 metodologi pengembangan sistem akuntansi
Evaluasi IMK.
Analisis dan Desain Sistem
Transcript presentasi:

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)