BAB IV Rekayasa Kebutuhan

REKAYASA KEBUTUHAN

4.1  Rekayasa Kebutuhan

- Rekayasa Kebutuhan adalah bagian yang tidak terpisahkan dari kegiatan rekayasa perangkat lunak. Rekayasa kebutuhan mempunyai peran yang cukup penting, bahkan aku menentukan keberhasilan dari suatu proyek rekayasa perangkat lunak. 

4.2  Teori yang Mendukung Rekayasa Kebutuhan

Beberapa hukum dalam rekayasa kebutuhan sebagai berikut :

a. Hukum Glass (Robert Glass)

Kekurangan kebutuhan adalah sumber utama dari kegagalm proyek

 

b. Hukum Boehm Pertama

Kesalahan yang paling sering selama menentukan kebutuhan adalah kegiatan desain yang lebih mahal

c. Hukum Boehm Kedua

Prototyping secara signifikan mengurangi kebutuhan dan kesalahan desain, terutama untuk user interface

 

 

4.3  Kegiatan Rekayasa Kebutuhan

- Feasibility Study 

sebuah analisa dan evaluasi dari proyek yang diusulkan untuk menentukan apakah secara teksis layak, layak dalam perkiraan biaya dan menguntungkan.

 

- Feasibility Report

analisis yang mengevaluasi satu atau lebih langkah-langkah tindakan potensial dan merekomendasikan bagaimana organisasi tersebut harus dilanjutkan. Diperkirakan biaya, mengidentifikasi manfaat yang diharapkan memperkirakan berapa lama proyek akan mengambil dan menguraikan kesulitan potensial.

 

- Requirements  Elicitation and Analysis

pengumpulan persyaratan sistem pengguna, pelanggan dan stakeholder lainnya. meliputi wawancara, kuisioner, observasi pengguna.

 

- System Model

sistem model konseptual yang menggambarkan dan mewakili suatu sistem. Sebuah sistem terdiri dari beberapa pandangan seperti perencanaan, persyaratan, desain, implementasi, penyebaran, struktur, perilaku, input data, dan data tampilan output.

Dalam system model terdapat 2 pendekatan, yaitu

1. Pendekatan non-arsitektur

terstruktur Sistem Metode Analisis dan Desain (SSADM), memilih bagan struktur untuk deskripsi struktur dan data flow diagram (DFD) untuk deskripsi perilaku.

2. Pendekatan arsitektur

arsitektur sistem menggunakan Bahasa Arsitektur Deskripsi (ADL) baik struktur dan perilaku deskripsi.

 

- Requirements spesification 

akibat langsung dari analisis kebutuhan dan dapat merujuk.

 

- User Requirements

kebutuhan pengguna, menggambarkan apa yang pengguna lakukan dengan sistem, seperti kegiatan yang pengguna harus dapat melakukan apa. Persyaratan pengguna umumnya didokumentasikan dalam Dokumen Persyaratan Pengguna (URD) menggunakan teks narasi. Persyaratan pengguna umumnya ditanda tangani oleh pengguna dan digunakan sebagai masukan utama untuk menciptakan persyaratan sistem.

 

- System Requirements 

persyaratan sistem diklarifikasikan sebagai persyaratan baik fungsional maupun tambahan. 

*Persyaratan fungsional menentuka sesuatu yang pengguna perlu untuk melakukan pekerjaan mereka. contoh : sistem mungkin diperlukan untuk mencetak dan masuk perkiraan biaya.

*Persyaratan non-fungsional atau tambahan menentukan semua persyaratan yang tersisa tidak tercakup oleh persyaratan fungsional 

 

- Requirements Validation

kepastian bahwa suatu produk, layanan, atau sistem memenuhi kebutuhan pelanggan dan stakeholder lainnyadidentifikasi. Ini sering melibatkan penerimaan dan kesesuaian dengan pelanggan eksternal.

 

- Requirements Document

dokumen yang ditulis oleh sebuah perusahaan yang mendefinisikan sebuah produk yang mereka buatatau persyaratan untuk satu atau lebih fitur baru untuk produk yang sudah ada. Fungsinya sebagai pemasaran persyaratan dokumen juga, terutama jika produk tersebut rumit atau kecil.