Anda di halaman 1dari 27

ANALISIS KEBUTUHAN

Muhammad Riza Hilmi, ST.


http://learn.rizahilmi.com saya@rizahilmi.com

Analisis Kebutuhan

Analisa kebutuhan adalah sebuah proses untuk mendapatkan informasi, model, spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Kebutuhan analisis menyediakan penyajian informasi, fungsi, dan perilaku untuk software designer kemudian dapat diterjemahkan ke interface, dan komponen-tingkat desain. Tahap requirement analysis adalah tahap interaksi intensif antara analis sistem dengan pemakai sistem (end-user), dimana team pengembangan sistem menunjukkan keahliannya untuk mendapatkan tanggapan dan kepercayaan pemakai, sehingga mendapat partisipasi yang baik.

Analisis Kebutuhan Cont.

Tahap awal dalam requirement system adalah melakukan survey terhadap keinginan pemakai dan menjelaskan sistem informasi yang ideal.

Kebutuhan analisis adalah tugas rekayasa perangkat lunak yang menjembatani jarak antara level sistem engineer dan pihak desainer perangkat lunak.

Proses Analisis
Requir ements definition and specification

Requirements validation Domain understanding

Prioritization

Process entry

Requirements collection

Conflict resolution

Classification

Analisis Kebutuhan Cont.

Perlu pemilihan metode pengumpulan data yang tepat selama melakukan requirement system. Metode tersebut adalah :

interviews, questionnaires, observation, procedure analysis, document survey.

Tanya jawab (Interviews)

Bagaimana metode itu digunakan.


Pemilihan potential interviewees. Membuat perjanjian terhadap potential interview Menyiapkan struktur pertanyaan yang lengkap dan jelas. Memilih person yang di interview secara pribadi dan merekamnya. Pewawancara dapat mengukur respon melalui pertanyaan dan menyesuaikannya sesuai situasi yang terjadi. Menunjukkan kesan interviewer secara pribadi. Memunculkan respons yang tinggi sejak penyusunan pertemuan.

Keuntungan metode.

Tanya jawab (Interviews) cont.

Kerugian metode.

Membutuhkan waktu dan biaya yang tidak sedikit. Membutuhkan pelatihan dan pengalaman khusus dari pewawancara. Sulit membandingkan laporan wawancara karena subyektivitas alamiah. Mendapatkan penjelasan atau pandangan dari personel utama. Test kredibilitas dari interviewes. Mencari interview yang unsureness atau contradictions. Memantapkan kredibilitas team.

Kapan metode tersebut baik digunakan.


Beberapa faktor penting dalam interview yang baik, yaitu objektives, audience, format, weighting dan combining responses, and documentation.

Kuesioner (Questionnaires)

Bagaimana metode itu digunakan.


Mendesain dengan menggunakan standar kuesioner. Kuesioner dikirimkan ke lingkungan kerja end-users. Struktur respon diringkas dalam statistik distribusi. Murah dan cepat dari pada interviews. Tidak membutuhkan investigator yang terlatih (hanya satu ahli yang dibutuhkan untuk mendesain kuesioner untuk end-user yang terpilih). Mudah untuk menprediksi hasil sejak pembuatan kuesioner. Dengan mudah dapat meminimalkan biaya untuk semua enduser.

Keuntungan metode.

Kuesioner (Questionnaires) cont.

Kerugian metode.

Tidak dapat membuat pertanyaan yang spesifik bagi end-user. Analis tidak dapat melihat pribadi end-user. Tanggapan yang rendah karena tidak adanya dorongan yang kuat untuk mengembalikan kuesioner. Tidak dapat menyesuaikan pertanyaan ke end-user secara spesifik. Pertanyaannya sederhana, dan tidak memiliki arti mendua. Membutuhkan wawasan yang luas dari end-user. Bila memiliki sedikit waktu dan biaya.

Kapan metode tersebut baik digunakan.


Observasi (Observation)

Bagaimana metode itu digunakan.


Secara pribadi seorang analis mengunjungi lokasi pengamatan. Analis merekam kejadian dalam lokasi pengamatan, termasuk volume dan pengolahan lembar kerja. Mendapatkan fakta records daripada pendapat (opinion). Tidak membutuhkan konstruksi pertanyaan. Tidak menganggu atau menyembunyikan sesuatu (end-users tidak mengetahui bahwa mereka sedang diamati). Analis tidak bergantung pada penjelasan lisan dari end-users.

Keuntungan metode.

Observasi (Observation) cont.

Kerugian metode

Jika terlihat, analis mungkin mengubah operasi (end-user merasa diamati). Dalam jangka panjang, fakta yang diperoleh dalam satu observasi mungkin tidak tepat (representative) dalam kondisi harian atau mingguan. Membutuhkan pengalaman dan keahlian khusus dari analis. Membutuhkan gambaran kuantitatif seperti waktu, volume dan sebagainya. Kecurigaan bahwa end-user mengatakan suatu kejadian yang sebenarnya tidak terjadi (dibuat-buat).

Kapan metode tersebut baik digunakan.

Observasi (Observation) cont.

Tips praktis dalam melakukan observasi :

Jangan mengamati dalam waktu yang lama.Terdapat dua alasan, yaitu : dengan waktu yang lama akan mengacau operasi yang sedang diamati, dan akan membiaskan permasalahan yang sebenarnya. Buat catatan yang ringkas. Sebelum observasi, beritahukan kepada supervisor dan pemakai yang terlibat tentang apa yang akan dikerjakan dan mengapa dikerjakan, sehingga akan mengurangi gangguan. Gunakan checklist yang singkat tentang informasi yang dibutuhkan bersama. Jangan melakukan observasi tanpa rencana.

PROSEDUR ANALISIS (PROCEDURE ANALYSIS)

Bagaimana metode itu digunakan.

Dengan prosedur operasi dapat mempelajari dan mengidentifikasikan aliran dokumen utama melalui sistem informasi, yaitu dengan data flow diagram (DFD). Setiap aliran dokumen utama menjelaskan prosedur operasi sistem. Melalui observasi, analis mempelajari kenyataan daripada mendeskripsikan volume distribusi (tinggi, rendah, sedang) dan apa yang selanjutnya dikerjakan terhadap salinan dari dokumen aslinya. Evaluasi prosedur dapat dikerjakan dengan campur tangan (interferences) yang minimal dan tidak mempengaruhi operasi pemakai. Prosedur aliran dapat dapat menjadi sebuah struktur checklist untuk melakukan observasi.

Keuntungan metode.

PROSEDUR ANALISIS (PROCEDURE ANALYSIS) Cont.

Kerugian metode.

Prosedure mungkin tidak lengkap dan tidak up-to-date lagi. Mempelajari bagan aliran dokumen membutuhkan waktu dan keahlian analis. Memutuskan apakah masalah kegagalan sistem dapat membantu perancangan yang baik. Tim analis tidak secara total familiar dengan aliran dokumen. Mendeskripsikan aliran dokumen yang menganggu kerjanya fungsi.

Kapan metode tersebut baik digunakan.

PENGAMATAN DOKUMEN (DOCUMENT SURVEY)

Bagaimana metode itu digunakan

Mengidentifikasikan dokumen utama dan laporan (physical data flow diagram). Mengumpulkan salinan dokumen aktual dan laporan. Setiap dokumen atau laporan, digunakan untuk record data, meliputi field (ukuran dan tipe), frekuensi penggunaan dan struktur kodingnya (coding structure). Meminimalkan interupsi dari fungsi operasionalnya. Permulaan elemen kamus data. Seringkali, dapat mempertimbangkan modifikasi major procedural.

Keuntungan metode.

PENGAMATAN DOKUMEN (DOCUMENT SURVEY) Cont.

Kerugian metode

Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami kebanjiran dokumen dan laporan). Harus dikerjakan jika sebuah sistem akan didesain (selama kegiatan analisis, dalam memperjelas desain sistem yang baru dan analisis dokumen dapat membantu untuk menentukan tugas perancangan selanjutnya).

Kapan metode tersebut baik digunakan.

Dokumen Analisis Kebutuhan

Arahan (conduct) analisis


Menganalisa records, forms dan laporan Pengamatan proses. Menganalisa metode yang digunakan. Hubungan dengan pemakai akhir (end user) Permasalahan dalam pengumpulan data. Kebutuhan laporan (jenis dan frekuensinya). Kebutuhan pelatihan. Apa yang menjadi kebutuhan sebenarnya. Pengaruh sistem baru.

Kebutuhan pemakai.

Dokumen Analisis Kebutuhan Cont.

Kendala sistem.

Menjelaskan kendala waktu, biaya, keahlian, teknologi dan faktor ekternal. Realistik sistem. Intrumen pengumpulan data (kebutuhan kuesioner, interview). Konsensus statistik. Aliran data secara logikal dan phisik. Element awal dalam kamus data.

Dokumentasi.

Analisiskebutuhan perangkat lunakdapat dibagi menjadi lima: (1) mengetahui masalah, (2) evaluasi, (3)pemodelan, (4)spesifikasi, (5) review

Mengetahui Masalah

Tujuannyaadalah mengetahuielemenmasalah dasarseperti yang dirasakan oleh pelanggan / pengguna. Analis harusmendefinisikan semuaobjek data eksternal yangdiamati, mengevaluasi aliran dan isi informasi, mendefinisikan dan menjabarkansemua fungsi perangkat lunak, memahami perilaku perangkat lunak dalam konteksperistiwa yang mempengaruhi sistem, membangun sistem, karakteristik antarmuka, dan menemukankendala desain tambahan.

Evaluasi

Pemodelan

Selama kegiatan evaluasi dan solusi, analis menciptakan model dari sistem dalam upaya untuk lebih memahami data dan kontrol aliran, pengolahan fungsional, perilaku operasional, dan informasi konten. Dengan dilakukannya pemodelan maka bisa digunakansebagai landasan untuk desain perangkat lunak dansebagai dasaruntuk penciptaan spesifikasi untuk perangkat lunak. Review dilakukan untuk pengecekan ulang daftar spesifikasi perangkat lunak yang akan dikembangkan.

Spesifikasi

Review

Proses Rekayasa Kebutuhan


Feasibility study Requirements elicitation and analysis

Requir ements specification Requirements validation

Feasibility report System models User and system requirements

Requirements document

Jenis Kebutuhan

Kebutuhan Fungsional

Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap input dan apa yang harus dilakukan sistem pada situasi khusus. Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses pengembangan, standard Contoh: kehandalan, waktu respon dan kebutuhan storage. Contoh kendala seperti: keterbatasan kemampuan peralatan I/O, representasi sistem.

Kebutuhan Non-Fungsional

Permasalahan Proses Analisis

Pengguna (stakeholders) tidak mengetahui apa yang mereka butuhkan Pengguna menjelaskan kebutuhan dengan cara mereka sendiri sehingga sulit untuk dipahami Pengguna yang berbeda memiliki konflik kebutuhan Faktor politik dan organisasi yang dapat mempengaruhi kebutuhan sistem Perubahan kebutuhan selama proses analisis. Stakeholder baru mungkin akan merubah lingkungan bisnis.

Prinsip Analisis

Domain informasidari suatu masalah harus direpresentasikan dan dipahami. Fungsibahwa perangkat lunakadalah untuk melakukanharus didefinisikan. Perilakusoftware(sebagai konsekuensi dari peristiwa eksternal) harus diwakili. Modelyang menggambarkan informasi, fungsi,dan perilaku harusdipartisi dengan cara yangmengungkapkandetail dalamcara(atauhierarkis)berlapis. Proses analisisharus bergerak dariinformasi penting yang menuju implementasi detail.

Panduan Analist

Memahamimasalah sebelumAnda mulaimembuatmodel analisis.

Ada kecenderungan untukterburu-buru untuksolusi, bahkansebelum masalahtersebut dipahami.

Mengembangkanprototipeyang memungkinkan pengguna untuk memahami bagaimana interaksimesin/manusiaakan terjadi.

Karenapersepsikualitas perangkat lunak sering berdasarkan persepsidari "keramahan"dari antarmuka, prototipe (danbahwa hasiliterasi)sangat dianjurkan.

Menggunakan pandanganbeberapa untuk suatu kebutuhan.

Tigapandangan software engineer yang berbeda yaitu data, fungsional, dan perilaku model.

Pengujian Pendefinisian Kebutuhan

Validasi.

Apakah sudah sesuai dengan yang diinginkan. Adakah konflik dengan kebutuhan lainnya. Apakah sudah termasuk semua fungsi yang dibutuhkan. Dapatkan kebutuhan diimplementasikan ke dana dan teknologi yang tersedia. Dapatkah spesifikasi kebutuhan dicek.

Konsistensi.

Lengkap.

Realisasi.

Dapat diverifikasi.