4 Managing Software Requirement Analisis Kebutuhan

Analisis kebutuhan dalam rekayasa perangkat lunak meliputi tugas-tugas yang masuk ke menentukan kebutuhan atau kondisi untuk bertemu untuk produk baru atau diubah, dengan mempertimbang kan dari mungkin bertentangan kebutuhan dari berbagai stakeholder , seperti penerima atau pengguna.

Analisis Kebutuhan Didokumentasikan Ditindaklanjuti Diukur Diuji Diidentifikasi untuk peluang Didefinisikan

TAHAP ANALISIS KEBUTUHAN Tahap analisis kebutuhan mendefinisikan kebutuhan bisnis untuk sebuah sistem baru. Kunci utama dalam Analisis Kebutuhan adalah “WHAT” bukanlah “HOW” Analisis Kebutuhan menjawab pertanyaan: “What do the users need and want from a new system?”

TAHAP ANALISIS KEBUTUHAN Tahap ini dapat disebut sebagai Definition Phase or Logical Phase. (Tahap Definisi atau Tahap Logika) Kita dapat menghasilkan dokumen kebutuhan² sistem baru dan sistem yang dikembangkan dengan menggambar model sistem

TAHAP ANALISIS KEBUTUHAN Mendefinisikan Kebutuhan “Define Requirements” Menganalisis Kebutuhan Fungsional “Analyze Functional Requirements” Menelusuri dan Melengkapi Kebutuhan “Trace and Complete Requirements” Memprioritaskan Kebutuhan “Prioritize Requirements” Mengubah Perencanaan Proyek “Update The Project Plan”

Define Requirements (Mendefinisikan Kebutuhan) Ada 2 jenis Kebutuhan: Kebutuhan Fungsional Mendeskripsikan aktivitas² dan servis² yang harus dihasilkan oleh sistem Cth: input, output, proses, dan data store yang diperlukan untuk mencapai sasaran sistem. Kebutuhan Non-Fungsional adalah fitur² lain, karakteristik lain, dan kendala² yang memenuhi kebutuhan sistem Cth: Performance, budget, biaya, waktu, dokumentasi, kualitas manajemen, keamanan, dll.

Kebutuhan fungsional Menjelaskan apa yang harus dilakukan dengan mengidentifikasi tugas yang diperlukan, tindakan atau kegiatan yang harus dicapai. Fungsional analisis kebutuhan akan digunakan sebagai fungsi level atas untuk analisis fungsional. Pernyataan layanan yang harus diberikan sistem, bagaimana sistem harus bereaksi terhadap input tertentu, dan bagaimana sistem harus berlaku pada situasi-situasi tertentu.

Kebutuhan non-fungsional Kebutuhan- kebutuhan yang menentukan kriteria yang dapat digunakan untuk menilai sebuah sistem operasi, daripada perilaku spesifik. Merupakana batasan layanan atau fungsi yang diberikan sistem, dokumen ini mencakup batasan waktu, batasan pada proses Pengembangan standarisasi, dlsb

Define Requirements (Mendefinisikan Kebutuhan) <lanjutan…> Tahap ini akan mengidentifikasi semua jenis kebutuhan, baik fungsional maupun non-fungsional Sistem analis akan mengerjakan tugas pada tahapan ini dan mendokumentasikan hasilnya. Pembangun dan pendesain sistem tidak terlibat dalam tahap ini karena mereka akan memfokuskan kebutuhan hanya pada teknologi dan solusi teknis.

Analyze Functional Requirements (Mendefinisikan Kebutuhan) Ada 2 pendekatan mendokumentasikan kebutuhan² Fungsional dan Validasi, : System Modelling Prototyping Menjelaskan sistem dengan gambar² (cth: flowchart) yang mengekspresikan kebutuhan atau desain sistem. Sistem analis yang paling baik, dapat mengembangkan Logical System Model (Model Sistem Logis) untuk menghasilkan petunjuk tentang bagaimana sistem dapat diimplementasikan.

Analyze Functional Requiremen (Mendefinisikan Kebutuhan) <Lanjutan Logical System Models menggambarkan APAKAH sistem itu atau APA yang harus dilakukan sistem tersebut – bukan bagaimana sistem akan diimplementasikan— Secara teori, pada tahap ini, menggunakan Desain Logis dari sistem, tim proyek akan: Memisahkan bisnis dari solusi teknis Lebih menerima dan mempertimbangkan cara baru dan berbeda untuk meningkatkan proses bisnis Mempertimbangkan secara berbeda, alternatif solusi teknis

Analyze Functional Requirements (Mendefinisikan Kebutuhan) Prototyping Digunakan dalam analisis kebutuhan untuk menetapkan kebutuhan user interface (input dan output) Dengan prototyping, user dapat mengenali kebutuhan² mereka dengan melihat langsung ke prototipe nya. Dengan Prototyping, kebutuhan dianalisis untuk: accuracy, urgency, consistency, flexibility dan feasibility untuk memenuhi beberapa kriteria.

Trace and Complete Requirements (Menelusuri dan Melengkapi Kebutuhan) Pada tahap ini pemilik sistem dan user diberikan kesempatan final untuk memvalidasi kebutuhan. Pada tahap 1 (Define Requirements) kita menetapkan outline dari daftar² kebutuhan, maka tahap ini kita melakukan cek ulang untuk meyakinkan bahwa daftar kebutuhan tersebut telah didefinisikan dalam beberapa bentuk, baik model ataupun prototyping. Ketika menelusuri kebutuhan, dapat digunakan CASE tools untuk melihat apakah kebutuhan telah terpenuhi.

Trace and Complete Requirements (Menelusuri dan Melengkapi Kebutuhan) Tahap ini dilakukan oleh manajer proyek dan Analis sistem. Pemilik sistem berperan memastikan kelengkapan dari spesifikasi² kebutuhan yang sudah dibuat.

Prioritize Requirements (Menentukan Prioritas Kebutuhan) Jika proyek tidak sesuai dengan jadwal atau over budget, maka perlu dikenali kebutuhan² mana yang lebih penting dibandingkan dengan kebutuhan lainnya. Maka dilakukan penentuan prioritas Menentukan prioritas kebutuhan bisnis dapat dilakukan dengan teknik Timeboxing. Timeboxing adalah teknik yang menyampaikan informasi dari sistem secara fungsional dan kebutuhan². Tim pengembangan akan memilih sub² dari sistem yang akan memberikan nilai pengembalian kepada pemilik sistem dan user.

Prioritize Requirements (Menentukan Prioritas Kebutuhan) Prioritas dapat di klasifikasikan berdasarkan tingkat kepentingannya: A mandatory requirements adalah kebutuhan yang harus dipenuhi oleh sistem. Sistem akan tidak berguna tanpa kebutuhan ini. A desirable requirements adalah kebutuhan yang tidak esensial / tidak harus ada. Hanya sebagai pelengkap versi selanjutnya. Kebutuhan ini dapat dan harus di urutkan prioritasnya.