Bab 4: Requirement Analysis Fundamentals

Analisa Kebutuhan

Spesifikasi kebutuhan software yang lengkap menunjang keberhasilan pengembangan

software.

Tugas Analisa Kebutuhan:

– Scope software, mula-mula ditentukan selama system engineering, diperhalus secara
bertahap.
– Berbagai solusi dianalisa dan dialokasikan ke elemen-elemen software
– Developer bertindak sebagai interogator, konsultan dan problem solver.
– Customer mencoba memformulasikan kembali konsep dari fungsi software dan kinerja
secara kongkrit dan rinci.

A. REQUIREMENT ANALYSIS
Analisa Kebutuhan:
– Tugas software engineering yang menjembatani level alokasi software dan desain
informasi.
– Membuat system engineer (analis) menentukan fungsi software, unjuk kerja, interface
dengan elemen-elemen sistem lainnya, menentukan kendala-kendala untuk software.

– Membuat analis memperhalus alokasi software

– Merepresentasikan domain informasi
– Menyediakan (untuk desainer representasi) informasi dan fungsi yang dapat
ditranslasikan ke desain data, arsitektur dan desain prosedur

Tujuan Analisa:
Mengenali elemen-elemen permasalahan seperti yang dipahami oleh customer.

Analis
Karakter Analis:
1. Memiliki kemampuan untuk mengambil konsep-konsep abstrak, mengorganisasikan ke
beberapa divisi secara logika, dan menghasilkan penyelesaian dengan
mempertimbangkan setiap divisi.
2. Memiliki kemampuan untuk menyerap fakta-fakta dari sumber-sumber yang konflik dan
membingungkan.
3. Memiliki kemampuan untuk memahami user/kustomer environment.
4. Memiliki kemampuan untuk mengaplikasikan hardware dan/atau elemen-elemen sistem
ke user/kustomer environment.
5. Memiliki kemampuan berkomunikasi dengan baik secara lisan dan tulisan.

Peran Analis
1. Melakukan atau mengkoordinasikan setiap tugas yang berhubungan dengan analisa
kebutuhan software.
2. Selama pengenalan tugas-tugas, analis berkomunikasi dengan staff user/kustomer
untuk menyakinkan tentang karakteristik dari lingkungan sistem.
3. Selama tahap evaluasi dan sintesa analis memanggil staff pengembangan sehingga
karakteristik software dapat didefinisikan dengan benar.
4. Bertanggung jawab terhadap pengembangan spesifikasi kebutuhan perangkat lunak
(software requirement spesification).

1
 Bab 4: Requirement Analysis Fundamentals

Prinsip-prinsip Analisa
Metode Analisa
1. Domain informasi, domain fungsional dari problem harus direpresentasikan dan
dipahami
2. Problem harus dibagi-bagi
3. Representasi logika dan fisik dari sistem dikembangkan.

Domain Informasi
Software dibangun untuk memproses data, untuk mentransformasikan data dari suatu
bentuk ke bentuk lain, yaitu untuk menerima input, manipulasi data dengan cara tertentu
dan menghasilkan output.

Domain informasi mengandung 3 pandangan tentang data yang diproses oleh program
komputer:
1. Aliran informasi, aliran informasi merepresentasikan cara-cara data berubah
sebagaimana dia bergerak pada sistem. Input ditransformasikan ke intermediate data
dan selanjutnya ditransformasikan ke output. Transformasi yang dilakukan pada data 
fungsi-fungsi atau sub fungsi.
2. Isi informasi, isi informasi mewakili data individu yang mengisi suatu informasi. Misal :
informasi rekord payroll, berisi nomor karyawan, upah dan lain-lain.
3. Susunan informasi;
– Struktur informasi mewakili organisasi logika tentang berbagai data.
– Apakah data diorganisasi dengan tabel n dimensi atau dengan struktur hierarki?
– Data mana yang mempunyai hubungan (relasi) dengan data yang lain.
– Apakah semua informasi berada dalam satu struktur atau banyak struktur?
– Bagaimana informasi dalam satu struktur berhubungan dengan informasi pada
struktur lain?

Tugas Analisa:
Analisa kebutuhan software di bagi 4: Pengenalan Problema, Evaluasi dan Sintesa,
Spesifikasi, dan Tinjauan (review).

1. Pengenalan Problema:
– Mula-mula analis mempelajari spesifikasi sistem (system spesification) dan software
Project Plan.
– Memahami software dalam konteks sistem dan meninjau ruang lingkup software
untuk menentukan rencana perkiraan (planning estimates)
– Berikutnya mendalami problema

Analis harus berkomunikasi dengan staff management dan teknis dari organisasi
pelanggan atau software development organization.

Manajer Proyek berlaku sebagai koordinator, dan memfasilitasi penentuan jalur

komunikasi

2. Evaluasi dan Sintesa

– Analis mengevaluasi aliran dan struktur informasi
– Memperhalus semua fungsi-fungsi software secara detil
– Menentukan karakteristiks-karakteristik interface sistem
– Menentukan kendala desain

2
 Bab 4: Requirement Analysis Fundamentals

– Setiap tugas tersebut menerangkan problem sehingga keseluruhan pendekatan

(approach) atau solusi bisa disintesa (dipadukan).

Misalkan: sistem pengontrol inventory diperlukan oleh supplier.

Analis menemukan problem:

– Ketidakmampuan menentukan status komponen secara cepat
– Perlu 2-3 hari untuk mengupdate card file
– Multiple re-order untuk vendor yang sama

Analis menentukan informasi apa yang dihasilkan oleh sistem baru dan data apa yang
diperlukan. Misalnya: customer memerlukan laporan harian yang menunjukkan barang
apa yang diambil dari inventory dan sisanya.

Kustomer menunjukkan bahwa setiap klerk (pelayan) mempunyai nomor identitas.

Pada waktu mengevaluasi problem dan info yang diperlukan, analis mulai melakukan
sintesa pada satu atau lebih solusi. Misalnya on-line terminal based system akan
mampu menyelesaikan satu set problema, tetapi apakah jatuh pada scope seperti pada
software plan, DBMS kelihatannya dibutuhkan tetapi diperlukan pemikiran lebih lanjut.

Proses evaluasi dan sintesa dilanjutkan sampai customer merasa yakin bahwa software
dapat dispesifikasi untuk pengembangan.

3. Spesifikasi
Tugas-tugas yang berhubungan dengan analisa dan spesifikasi untuk representasi
software sehingga dapat ditinjau dan disetujui oleh customer  software requirement
spesification.

Setelah fungsi-fungsi dasar, unjuk kerja, interface dan informasi diterangkan, kriteria
validasi dispesifikasikan untuk mendemonstrasikan pemahanan tentang implementasi
software.

Kriteria tersebut sebagai basis untuk testing selama pengembangan software.

Spesifikasi kebutuhan secara formal ditulis untuk mendefiniskan karakteristik dan atribut
dari software  Preliminary User’s Manual

Dokumen analisa kebutuhan (spesification and user’s manual) berfungsi sebagai basis
untuk meninjau ulang (review) yang dilakukan oleh customer dan developer.

B. AREA PROBLEM
Analisa kebutuhan memerlukan komunikasi yang intensif. Ketika terjadi komunikasi, noise
pada komunikasi (seperti salah interpretasi, kelalaian) menyebabkan kesulitan bagi analis
dan kustomer.

Problem yang ada selama analisa kebutuhan :

– Kesulitan yang berhubungan dengan perolehan informasi
– Penanganan kompleksitas problem
– Penyesuaian terhadap perubahan-perubahan yang terjadi selama dan sesudah analisa.

Problem pengenalan, analisa dan sintesa  ditaksir pada pengumpulan informasi yang
baik.

3
 Bab 4: Requirement Analysis Fundamentals

Konflik sering terjadi:

– Info yang diberikan oleh kustomer mengalami konflik dengan kebutuhan yang
dikemukakan oleh orang lain.
– Fungsi dan unjuk kerja konflik dengan konstrain-konstrain yang ditetapkan untuk elemen
sistem yang lain.
– Pemahaman tentang tujuan dari sistem berubah dengan waktu.

Informasi apa yang perlu dikumpulkan dan bagaimana merepresentasikannya?

Siapa yang memberikan berbagai informasi?
Tools dan technique apa yang tersedia untuk melakukan pengumpulan informasi?

Ukuran problem bertambah  kompleksitas tugas analis semakin bertambah.

Setiap informasi baru: akan berpengaruh pada elemen yang lain pada software
Bagaimana kita mengeliminasi inkonsistensi?
Apakah mungkin mendeteksi tidak dicantumkannya sesuatu (omission)?
Dapatkah problem besar dibagi secara efektif, sehingga lebih mudah dikelola
(diselesaikan)?

First Law of System Engineering

No matter where you are in the system life cycle, the system will change, and the
desire to change it will persist throughout the life cycle. The changes alluded to
this statemen….

Problem analisa kebutuhan disebabkan beberapa hal:

 Kurang komunikasi menyebabkan kesulitan dalam pengumpulan informasi
 Kurangnya alat-alat dan tool sehingga menghasilkan spesifikasi yang tidak akurat dan
tidak lengkap.
 Kecenderungan mengambil jalan pintas untuk tugas analisa kebutuhan, menyebabkan
desain tidak stabil
 Kesalahan dalam mengambil alternatif sebelum spesifikasi software selesai.