P. 1
analisis-kebutuhan

analisis-kebutuhan

|Views: 74|Likes:
Dipublikasikan oleh Chika Yunindra

More info:

Published by: Chika Yunindra on Mar 11, 2011
Hak Cipta:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

01/06/2013

pdf

text

original

Analisis Kebutuhan Merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan. Terdiri dari lima langkah pokok: 1.

Identifikasi Masalah 2. Evaluasi dan sintesis 3. Pemodelan 4. Spesifikasi 5. Review Dalam menemukan Area permasalahan, perlu adanya komunikasi yang intensif dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi Pertanyaan pertama memfokuskan pada pengertian dasar permasalahan: 1. Menemukan yang membutuhkan software tersebut: a. Siapa yang membutuhkan sistem (serta personal di belakangnya) ? b. Siapa yang akan menggunakan solusi c. Apa yang akan menjadi keuntungan ekonomis dari solusi yang baik d. Adakan sumber lain dari solusi yang dibutuhkan 2. Bentuk solusi yang diinginkan a. Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan dihasilkan oleh solusi yang benar b. Masalah-masalah apa yang akan dicarikan solusinya? c. Lingkungan solusi yang akan digunakan d. Adakah isu atau kendala khusus yang berdampak kepada solusi 3. Efektifitas a. Mendapatkan person yang benar/berhak atas jawaban pertanyaan, b. Apakah pertanyaan yang diajukan relevan dengan permasalahan c. Adakah personal lain yang dapat menambah informasi d. Adakah hal lain yang perlu ditambahkan? Jenis Kebutuhan: 1. Kebutuhan Fungsional Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem dilihat dari kacamata pengguna)
1

Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O. Kebutuhan Non-Fungsional Kendala pada pelayanan atau fungsi sistem seperti kendala waktu. spesifikasi Kebutuhan harus: 1. representasi sistem dll.2. Konsisten: Tidak adanya konflik dan kontradiksi Tipe Non-Fungsional Non-functional requirements Product requirements Organizational requirements External requirements Efficiency requirements Reliability requirements Portability requirements Interoperability requirements Ethical requirements Usability requirements Delivery requirements Implementation requirements Standards requirements Legislative requirements Performance requirements Space requirements Privacy requirements Safety requirements 2 . kendala proses pengembangan. waktu respon dan kebutuhan storage. dll. Lengkap: Mendeskripsikan semua fasilitas yang diinginkan 2. standard. Contoh: kehandalan. Domain Kebutuhan Kebutuhan yang berasal dari domain aplikasi sistem dan merefleksikan karakteristik domain Secara Prinsip.

Proses Rekayasa Kebutuhan Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation Feasibility report System models User and system requirements Requirements document Studi Kelayakan Studi Kelayakan memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek permasalahan Melakukan studi untuk menguji apakah sistem: • sudah sesuai dengan tujuan organisasi • dapat dikembangkan dengan teknologi terkini dan dana yang tersedia • dapat diintegrasikan dengan sistem lain yang sudah digunakan Implementasi Studi Kelayakan Berbasikan pada penilaian informasi (apa yg dibutuhkan). pengumpulan informasi dan penulisan laporan Pertanyaan ke personal di organisasi: • Apa yang akan terjadi apabila sistem tidak diimplementasikan? • Masalah proses apa yang ada ? • Apa yang dapat dibantu oleh sistem ? • Masalah apa yang akan muncul pada proses Integrasi ? • Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ? • Fasilitas apa yang harus didukung oleh sistem ? 3 .

Permasalahan pada Analisis Kebutuhan • 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. 4 . Analisis Multi perspektif adalah penting jika tidak terdapat suatu cara yang benar untuk menganalisa kebutuhan sistem. dll Pemodelan tersebut dapat pula direpresentasikan sebagai formaliasi sudut pandang pengguna (viewpoint-oriented) Viewpoint-oriented elicitation Stakeholder merepresentatikan sudut pandang suatu masalah dalam beberapa cara. seperti model structural. state chart. Proses Analisis Kebutuhan Requirements definition and specification Requirements validation Domain understanding Prioritization Process entry Requirements collection Conflict resolution Classification Pemodelan Sistem Dapat dilakukan dalam beberapa cara. state machine.

Contoh: Sistem ATM Bank Sistem ATM dapat menyediakan pelayanan bank secara otomatis Pelayanan tersebut mencakup: penarikan tunai. pengiriman pesan untuk permintaan layanan. Autoteller viewpoint • Bank customers • Representatives of other banks • Hardware and software maintenance engineers • Marketing department • Bank managers and counter staff • Database administrators and security staff • Communications engineers • Personnel department Viewpoint identification Viewpoint structuring Viewpoint documentation Viewpoint system mapping Identifikasi Viewpoint: • Menemukan viewpoint sebagai penerima layanan sistem dan mengidentifikasikan layanan yang disediakan untuk masing-masing viewpoint • 5 . pemensanan. dan transfer.

Layanan umum disediakan pada level yang lebih tinggi dalam hierarki All VPs Services Query balance Withdraw cash Customer Bank staff Services Order cheques Send message Transaction list Order statement Transfer funds Account holder Foreign customer Teller Manager Engineer Dokumentasi Viewpoint • Memperbaiki deskripsi viewpoint dan layanan yang teridentifikasi Viewpoint system mapping • Transformasi analisis ke perancangan berorientasi objek 6 .Query balance Machine supplies Get transactions Manager Customer database Cash withdrawal Card returning Remote software upgrade Bank teller Transaction log Order cheques Invalid user Account information Message log Foreign customer Software size Printe r Hardware maintenance User interface Account holder System cost Stolen card Security Message passing Order statement Update account Card retention Card validation Remote diagnostics Reliability Funds transfer Pembentukan Struktur Viewpoint • Mengelompokkan viewpoint yang saling berhubungan secara hierarki.

They then enter the amount required. if funds allow. VPs: Customer Deliver cash within 1 minute Non-funct. requirements: of amount being confirmed Provider: Filled in later 7 . This is confirmed and. the balance is delivered.Viewpoint Service Information ACCOUNT HOLDER Service list FOREIGN CUSTOMER Service list BANK TELLER Service list Withdraw cash Query balance Order cheques Send message Transaction list Order statement Transfer funds Withdraw cash Query balance Run diagnostics Add cash Add paper Send message Bentuk Standard VORD Viewpoint templete Reference: Customer Attributes: Account number PIN Start transaction Events: Select service Cancel transaction End transaction Services: Sub-VPs: Cash withdrawal Balance enquiry Account holder Foreign customer service templete Reference: Rationale: Cash withdrawal To improve customer service and reduce paperwork Specification: Users choose this service by pressing the cash withdrawal button.

Skenario Penggambaran bagaiman sistem akan digunakan Membantu dalam menemukan kebutuhan dengan mempermudah dalam penggambaran proses dibandingkan pernyataan abstrak kebutuhan sistem Menambahkan detail ke outline deskripsi kebutuhan Deskripsi dalam Skenarion • Sistem State pada awal scenario • Alur Normal kejadian-kejadian di sistem • Apa yang dapat berkembang dan bagaimana menanganinya • Aktifitas-aktifitas yang bersamaan terjadi • System state setelah proses selesai Skenarion Kejadian • Skenario kejadian dapat digunakan untuk menggambarkan bagaimana sistem merespon ke suatu kejadian tertentu seperti awal transaksi • VORD dapat berupa diagram untuk menggambarkan scenario kejadian o Data yang dikirim dan disediakan o Kontrol Informasi o Pengecualiaan Proses o Kejadian berikutnya 8 .

eksepsi adalah: • Timeout: Pelanggan salah memasukkan nomor PIN selama waktu yang diberikan • Invalid Card: Kartu tidak diknal oleh sistem dan dikembalikan • Stolen Card: Kartu sudah diregister sebagai kartu yang sudah dicuri/hilang dan akan diambil oleh sistem (tidak dikembalikan) 9 .Card present Valid card Card Request PIN User OK PIN Timeout Return card Account number PIN Validate user Account number Select service Incorrect PIN Re-enter PIN Invalid card Return card Incorrect PIN Stolen card Retain card Return card Notasi: Elips menyatakan data yang disediakan oleh dan dikirim ke viewpoint Data keluar dari sisi kanan setiap kotak Eksepsi ditunjukkan di bawah maisng-masing box Nama kejadian berikutnya berada di box dengan garis panah tebal Pada contoh di atas.

Apakah sudah sesuai dengan yang diinginkan • Konsistensi.Validasi Kebutuhan • Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai dengan yang diinginkan pengguna • Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan penambahan biaya yang besar o Memperbaiki definisi kebutuhan stelah software dikirim akan menyebabkan peningkatan biaya hingga 100 kali. Adakah konflik dengan kebutuhan lainnya • Lengkap: Apakah sudah termasuk semua fungsi yang dibutuhkan • Realisasi: Dapatkan kebutuhan diimplementasikan ke dana dan teknologi yang tersedia • Dapat diverifikasi: Dapatkah spesifikasi kebutuhan dicek Teknik Validasi Kebutuhan Review: Prototyping Test-Case Generator Analisis Konsistensi Otomatis Requirements in a formal language Requirements problem report Requirements processor Requirements database Requirements analyser Managemen Perubahan Kebutuhan 10 . Pengujian Pendefinisian Kebutuhan • Validasi.

Performa yang dibutuhkan iv. Referensi Sistem b. Pertimbangan-pertimbangan khusus 6. Performance Bound b. Alur Data ii. Appendiks 11 . Respon Software yang diharapkan d. System State b. Deskripsi Kontrol i. Deskripsi Fungsional a. Events dan Aksi 5. Support diagram c. Deskripsi Interface Sistem 3. Pendahuluan a. Perancangan Kendala 4. Kriteria Validasi a. Deskripsi Informasi a. Kendala Projek Pengembangan Software 2. Deskripsi Fungsional i. Daftar Kepustakaan 7.Identified problem Problem analysis and change specification Change analysis and costing Change implementation Revised requirements Outline Spesifikasi Kebutuhan Software 1. Deskripsi Umum Sistem c. Alur Kontrol b. Keterbatasan Sistem iii. Spesifikasi Kontrol ii. Representasi Isi Informasi c. Deskripsi Lingkungan a. Informasi representasi Alur i. Deskripsi proses secara naratif ii. Kelas Test c. Perancangan kendala v. Partisi Fungsional b.

You're Reading a Free Preview

Mengunduh
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->