dani-idham: Proses Rekayasa Kebutuhan

Merupakan proses menemukan, memperbaiki, memodelkan dan menspesifikasikan.

Terdiri dari lima langkah pokok:

Identifikasi Masalah

Evaluasi dan sintesis

Pemodelan

Spesifikasi

Review

Lengkap: Mendeskripsikan semua fasilitas yang diinginkan

Konsisten: Tidak adanya konflik dan kontradiksi

Proses Rekayasa Kebutuhan

sudah sesuai dengan tujuan organisasi

dapat dikembangkan dengan teknologi terkini dan dana yang tersedia

dapat diintegrasikan dengan sistem lain yang sudah digunakan

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

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

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

Skenario kejadian dapat digunakan untuk menggambarkan bagaimana sistem merespon ke suatu kejadian tertentu seperti awal transaksi

VORD dapat berupa diagram untuk menggambarkan scenario kejadian

Data yang dikirim dan disediakan

Kontrol Informasi

Pengecualiaan Proses

Kejadian berikutnya

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

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)

Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai dengan yang diinginkan pengguna

Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan penambahan biaya yang besar

Memperbaiki definisi kebutuhan stelah software dikirim akan menyebabkan peningkatan biaya hingga 100 kali.

Validasi. Apakah sudah sesuai dengan yang diinginkan

Konsistensi. 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

Dalam menemukan Area permasalahan, perlu adanya komunikasi yang intensif dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi

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)

2. Kebutuhan Non-Fungsional

Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O, representasi sistem dll.

Domain Kebutuhan

Kebutuhan yang berasal dari domain aplikasi sistem dan merefleksikan karakteristik domain

Secara Prinsip, spesifikasi Kebutuhan harus:

Tipe Non-Fungsional

Studi kelayakan

Studi Kelayakan memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek permasalahan. Melakukan studi untuk menguji apakah sistem:

- 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.

Implementasi Studi Kelayakan

Proses analisis kebutuhan

Pemodelan Sistem

Dapat dilakukan dalam beberapa cara, seperti model structural, state machine, state chart, 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. Analisis Multi perspektif adalah penting jika tidak terdapat suatu cara yang benar untuk menganalisa kebutuhan sistem.

Contoh: Sistem ATM Bank

Sistem ATM dapat menyediakan pelayanan bank secara otomatis. Pelayanan tersebut mencakup: penarikan tunai, pengiriman pesan untuk permintaan layanan, pemensanan, dan transfer.

Autoteller viewpoint