Rekayasa dan Manajemen Kebutuhan · RMK - RE Process | Tri A. Kurniawan, S.T, M.T, Ph.D Contoh...

RE PROCESS

Rekayasa dan Manajemen

Kebutuhan

RMK - RE Process | Tri A. Kurniawan, S.T, M.T, Ph.D

Motivation – Catastrophe

2


Proses

Penggalian dan analisis kebutuhan (s/w req.

elicitation and analysis)

Spesifikasi kebutuhan (s/w req. specification)

Validasi & verifikasi kebutuhan (s/w req. validation

and verification)

Manajemen kebutuhan (s/w req. management)

3/24


Elisitasi dan analisis

Developer harus memahami domain

permasalahan

Developer dan stakeholder menggali domain

aplikasi, layanan-layanan sistem yang harus

disediakan, unjuk kerja sistem yang diperlukan,

batasan-batasan perangkat keras dan sejenisnya

Fokus pada A P A (WHAT) dan B U K A N

bagaimana (HOW)

Komunikasi adalah faktor penting

4


Diagram alir elisitasi dan analisis

Domain

understanding

Requirements

checking

Requirements

collection

Classification

Prioritisation

Conflict

resolution

Requirements

definition

Requirements

specification

5


Sumber-sumber elisitasi

Relatively

high

Relatively

low

Approximate % of requirements

gathered from people

Type of

application

highly

constrainedmissile guidance system

flight control system for airliner

enhancement to corporate accounting system

manufacturing control system

corporate accounting system

encounter video game

decision support system

unconstrained

6


Contoh hasil elisitasi dan analisis

Perangkat lunak harus mampu menyediakan sarana untuk menampilkan dan mengakses file-file yang dibuat oleh tool yang lain.

Pengguna harus dapat mencari buku/dokumen/literatur di perpustakaan dgn memasukkan sebuah kata kunci.

Sistem tidak boleh dioperasikan oleh pengguna yang tidak memiliki otoritas.

Sistem harus menyediakan GUI sehingga dapat digunakan secara mudah oleh pengguna yang belum berpengalaman.

Sistem harus bisa memanfaatkan database yang sudah ada.

Sistem harus diimplementasikan dgn bahasa Java.

7


Spesifikasi kebutuhan

Proses untuk menjelaskan kebutuhan PL yang telah didefinisikan sebelumnya secara lebih detil dan tepat yang akan menjadi dasar bagi perancangan dan implementasi

Definisi kebutuhan (req. definition) :1. PL harus mampu menyediakan sarana untuk menampilkan

dan mengakses file-file yang dibuat oleh tool yang lain. (SRS_PRJ_100)

Spesifikasi kebutuhan (req. specification) :1.1 Pengguna harus disediakan fasilitas untuk mendefinisikan

tipe file. (SRS_PRJ_101)

1.2 Setiap tipe file direpresentasikan dengan ikon tertentu pada layar pengguna. (SRS_PRJ_102)

8


Validasi dan verifikasi

Proses pengecekan untuk menjamin bahwa pernyataan kebutuhan yang telah didefinisikan dan dispesifikasikan adalah benar, akurat dan lengkap

Dilakukan bersama-sama antara kustomer dan developer

Sangat penting dilakukan karena kesalahan di dalam menentukan kebutuhan akan berdampak pada keseluruhan proses yang mengikutinya

Validasi : do we make the right product ….. ?

Verifikasi : do we make the product right ….. ?

Teknik :

– Review : Software Specification Review (SSR)

– Prototyping : executable model of the system/software

9


Parameter

Parameter validasi :

– Validity � does the system provide the functions which best support the customer’s needs ?

– Consistency � are there any requirements conflicts ?

– Comprehensibility � are all functions required by the customer included ?

Parameter verifikasi :

– Readability

– Testability

– Completeness

– Identifiability

– Ambiguity

10


Manajemen kebutuhan

Aktifitas untuk melakukan kontrol terhadap kebutuhan yang sedang maupun telah didefinisikan dan

dispesifikasikan :

– Identifikasi � bagaimana setiap kebutuhan dapat diidentifikasi dengan mudah (Cont. : SRS_PRJ_XXX, IRS_PRJ_XXX)

– Manajemen perubahan � bagaimana mekanisme untuk menangani perubahan kebutuhan yang terjadi

– Dokumentasi � SRS dan IRS sebagai deliverable, ECP, PCR

– Tracking � penelusuran informasi yang berhubungan dengan sebuah kebutuhan (sumber/asal, alokasi ke perancangan)

11


Problem

Stakeholder (end-user, manajer, maintenance engineer, policy maker) tidak tahu persis apa yang sesungguhnya

mereka butuhkan

Stakeholder menyatakan kebutuhannya dalam bahasa yang dipahami oleh mereka sendiri

Stakeholder yang berbeda mungkin memiliki kebutuhan

yang saling bertentangan

Kebutuhan mungkin berubah pada saat dilakukan analisis. Stakeholder baru yang bergabung mungkin

merubah dan lingkungan bisnis mengalami perubahan

Pertentangan antara unjuk kerja (performance) dan kemudahan (simplicity) dalam mencapai tujuan

12


Problem (1)

Customer

explanationDesigned by

Analyst

Project Leader

understanding

Coded by

Programmer

Described by

Bus. Consultant

Project

documentationOperation

installationCustomer cost Supports Customer really

needs

13


Dokumentasi

IEEE Standard+ (IRS/SRS):1. Introduction

1.1. Purpose of the requirements document

1.2. Scope of the product

1.3. Definition, acronyms and abbreviations

1.4. References

2. General Description

2.1. Product perspective

2.2. Product functions

2.3. User characteristics

2.4. General constraints

3. Specific Requirements

All functional and non-functional requirements, system models (eg. DFD/CFD, ERD,

STD, Use-Case, Class, Sequence, Statechart diagrams), performance, database

requirements, design constraints, security.

3. Qualification/Validation Requirements

4. Appendices/Bibliography

14


Alat bantu

Structured Analysis :

– Aplikasi pengolah model : Visio, dll.

– Aplikasi pengolah kata : MS Word, dll.

– CASE Tool : StP (Software through Picture), PSL/PSA

(Problem Statement Language/Problem Statement Anaylzer), ILeaf, SPMS, dll.

OO Analysis :

– Aplikasi pengolah model : Visio, dll.

– Aplikasi pengolah kata : MS Word, dll.

– CASE Tool : Rational RequisitePro, Rational Soda for Word, Rational Rose, ArgoUML, dll.

15


Penutup

RE memberikan landasan yang kuat bagi perancangan dan implementasi, yang tanpa itu maka produk PL yang dihasilkan berpotensi tinggi untuk tidak sesuai dengan kebutuhan customer

Proses di dalam RE mencakup elisitasi dan analisis, spesifikasi, validasi dan verifikasi, manajemen kebutuhan

Sebuah kebutuhan harus divalidasi dan diverifikasi sebelum digunakan sebagai dasar dalam perancangan

16

Rekayasa dan Manajemen Kebutuhan · RMK - RE Process | Tri A. Kurniawan, S.T, M.T, Ph.D Contoh...

Documents

Transcript of Rekayasa dan Manajemen Kebutuhan · RMK - RE Process | Tri A. Kurniawan, S.T, M.T, Ph.D Contoh...