Analisis Kebutuhan PERANGKAT LUNAK

Apakah Kebutuhan itu? Susunan pernyataan abstrak level tinggi dari layanan atau batasan sistem ke dalam spesifikasi fungsional matematis Tidak terelakkan bahwa kebutuhan mempunyai dua fungsi o Merupakan dasar untuk penawaran kontrak sehingga harus terbuka untuk interpretasi o Merupakan dasar untuk kontrak itu sendiri sehingga harus didefinisikan dengan detail

Analisis kebutuhan dalam rekayasa perangkat lunak meliputi tugas-tugas yang masuk ke menentukan kebutuhan atau kondisi untuk bertemu pada 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 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 (1) 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 fungsional (2) Menggambarkan fungsionalitas atau layanan sistem Tergantung pada tipe software, harapan user dan tipe sistem dimana software digunakan Kebutuhan fungsional user merupakan pernyataan level tinggi dari apa yang seharusnya dilakukan sistem tetapi kebutuhan fungsional sistem menggambarkan layanan sistem secara detail

Contoh Kebutuhan Fungsional User dapat mencari semua kumpulan database inisial atau memilih subset dari database tersebut Sistem menyediakan tampilan yang tepat untuk user yang membaca dokumen dalam penyimpan dokumen Setiap pesanan dapat dialokasikan sebagai identifier yang unik (ORDER_ID) dimana user dapat meng-copy daerah penyimpan account permanen

Kebutuhan non-fungsional (1) 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

Kebutuhan Non-fungsional (2) Mendifinisikan properti sistem dan batasan sistem, seperti kehandalan, waktu respon, kebutuhan penyimpan. Batasan misalnya kapabilitas perangkat I/O, representasi sistem, dll Kebutuhan proses juga menetapkan penggunaan sistem CASE khusus, bahasa pemrograman atau metode pengembangan Kebutuhan non-fungsional lebih kritis daripada kebutuhan fungsional. Jika tidak dapat bertemu, sistem menjadi tidak berguna

Klasifikasi Non-fungsional Kebutuhan Produk o Kebutuhan yang menetapkan bahwa produk yang dikirim harus berjalan dengan cara tertentu, contoh kecepatan eksekusi, kehandalan dll Kebutuhan Organisasi o Kebutuhan sebagai akibat dari kebijakan organisasi dan prosedur misalnya standar proses yang digunakan, kebutuhan implementasi dll Kebutuhan Eksternal o Kebutuhan yang muncul dari faktor eksternal sistem dan proses pengembangan misalnya kebutuhan antar operasi, kebutuhan legistatif dll

Tipe Kebutuhan Non-fungsional

Contoh Kebutuhan Non-fungsional Kebutuhan Produk Dimungkinan untuk semua komunikasi yang diperlukan antara APSE dan user diekspresikan dalam karakter ada standarnya Kebutuhan Organisasi Proses pengembangan sistem dan penyerahan dokumen seharusnya sesuai dengan proses dan penyerahan Kebutuhan Eksternal Sistem seharusnya tidak tertutup untuk segala informasi personal tentang konsumen lepas dari nama dan nomor referensi ke operator sistem

Tujuan dan Kebutuhan Tujuan Kebutuhan Non-fungsional kemungkinan sangat sulit untuk ditetapkan dan kebutuhan yang tidak tepat sulit diverifikasi Tujuan o Tujuan umum dari user misalnya kemudahan penggunaan Kebutuhan non-fungsional yang dapat diverifikasi o Pernyataan menggunakan beberapa ukuran yang dapat dites secara obyektif Tujuan sangat membantu pengembangan sesuai penyampaian maksud user sistem

Contoh Tujuan Sistem Kebutuhan non-fungsional yang dapat diverifikasi o Sistem seharusnya mudah digunakan oleh pengguna dan diorganisasikan sehingga error user dapat diminimalkan Kebutuhan non-fungsional yang dapat diverifikasi o Pengguna seharusnya dapat menggunakan semua fungsi sistem setelah training selesai. Setelah training ini, jumlah rata-rata error yang dibuat oleh user yang berpengalaman tidak lebih dari 2 setiap hari

Ukuran Kebutuhan

Sistem kendaraan luar angkasa Interaksi Kebutuhan Konflik antara kebutuhan non-fungsional bersifat umum dalam sistem yang kompleks Sistem kendaraan luar angkasa o Untuk meminimalkan berat, jumlah chip yang terpisah pada sistem harus diminimalkan o Untuk meminimalkan konsumsi listrik, listrik chip lebih rendah harus digunakan o Sehingga, menggunakan chip listrik rendah berarti lebih banyak chip yang harus digunakan. Mana yang merupakan kebutuhan kritis?

Kebutuhan Domain Diperoleh dari domain aplikasi dan menggambar kan karakteristik sistem dan fitur yang merefleksi kan domain Berupa kebutuhan fungsional baru, batasan pada kebutuhan yang sudah ada atau mendefinisikan komputasi tertentu Jika kebutuhan domain tidak terpenuhi, sistem mungkin tidak dapat bekerja

Permasalahan Kebutuhan Domain Kemampuan untuk dimengerti o Kebutuhan dinyatakan dalam bahasa domain aplikasi o Biasanya tidak dimengerti oleh software engineer yang mengembangkan sistem Ketidaklengkapan o Domain spesialis mengerti area dengan baik sehingga mereka tidak berfikir untuk membuat kebutuhan domain secara eksplisit

Kebutuhan User Menjelaskan kebutuhan fungsional dan nonfungsional sehingga user yang tidak mempunyai pengetahuan teknis detail dapat mengerti sistem Kebutuhan user didefinisikan menggunakan bahasa natural, tabel dan diagram

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 (Analisis Kebutuhan Fungsional) ………….. 1 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 (Analisis Kebutuhan Fungsiomal) ……………2 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 (Analisis Kebutuhan Fungsional) ………….. 3 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) …. 1 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) …. 2 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) …..1 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) …….. 2 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.

5. Merubah Perencanaan Melanjutkan up-date rencana proyek sesuai dengan yang sudah dipelajari. Melakukan perubahan pada problems nya, kebutuhan² (requirements), dan solusi²nya. Pada perubahan proyek tahap ini, kita melengkapi rencana dengan solusi2 yang akan direkomendasikan.