REKAYASA PERANGKAT LUNAK (RPL) ANALISIS
KEBUTUHAN PERANGKAT LUNAK
REKAYASA PERANGKAT LUNAK (RPL) Analisis Kebutuhan Perangkat Lunak
Anonymous Customer “I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant . . . . .”
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
2/43
Communication
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
3/43
Pendahuluan Relevansi Perkuliahan : – Banyak terjadi kasus bahwa perangkat lunak yang sudah jadi tidak sesuai dengan apa yang dibutuhkan oleh customer – Dengan melakukan analisis kebutuhan perangkat lunak maka diharapkan PL dikembangkan berdasarkan apa-apa yang dibutuhkan oleh customer
Tujuan Instruksional Khusus : Mahasiswa akan dapat menjabarkan pengertian dan metode-metode analisis kebutuhan perangkat lunak
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
4/43
Agenda Pembahasan Pendahuluan Pengertian Analisis Kebutuhan dan Kebutuhan Urgensi dan Fungsi Analisis Kebutuhan Problem Proses Metode Alat Bantu dan Dokumentasi
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
5/43
Pengertian: S/W Req. Analysis (SRA) Aktifitas RPL yang menjembatani antara kebutuhan di tingkat sistem dan perancangan perangkat lunak (Roger S. Pressman) Proses yang digunakan untuk mendapatkan, menganalisis, dan memvalidasi kebutuhankebutuhan sistem (Ian Sommerville)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
6/43
Pengertian: Requirement Suatu kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk menyelesaikan permasalahan atau untuk mencapai sebuah tujuan (IEEE) Sebuah kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sebuah sistem…untuk memenuhi sebuah kontrak, standard, spesifikasi, atau dokumen2 formal lainnya (IEEE) Setiap fungsi, batasan, atau properti lainnya yang harus disediakan, dimiliki atau dipenuhi untuk mencapai kebutuhan dari sistem yang dimaksudkan oleh pengguna (R. J. Abbott) Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
Urgensi & Fungsi If you don’t analyze, it’s highly likely that you’ll build a very elegant software solution that solves the wrong problem. The result is wasted time and money, personal frustration, and unhappy customers (Roger S. Pressman) Kegunaan hasil analisis kebutuhan: – Untuk mencapai kesepakatan antara developer, customer dan pengguna akhir akan kebutuhan yang harus dipenuhi – Untuk menyediakan dasar yang akurat bagi perancangan perangkat lunak – Untuk menyediakan referensi bagi dilakukannya validasi PL Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
8/43
Problem Stakeholder (end-user, manajer, maintenance engineer, policy maker) tidak tahu persis apa yang sesungguhnya mereka inginkan 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 Bahan Kuliah RPL -Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
9/43
Proses Penggalian dan analisis kebutuhan (s/w req. elicitation and analysis) Spesifikasi kebutuhan (s/w req. specification) Validasi kebutuhan (s/w req. validation) Manajemen kebutuhan (s/w req. management)
Karakteristik operasional P/L
Interface P/L
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
Batasan P/L
10/43
Proses : 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) Via interview atau meeting communication
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
11/43
Proses : Elisitasi dan Analisis Tipe kebutuhan (D. T. Ross & K. F. Schoman) : – Fungsional
(functional) fungsi/kapabilitas yang harus mampu dijalankan oleh sistem – Non fungsional (non-functional) performance, reliability, security, availability, constraints, dll. – Inversi (inverse) apa-apa yang harus tidak boleh dilakukan sistem – Batasan perancangan & implementasi (design & implementation constraints)
12/43
Proses : Elisitasi dan Analisis Sumber-sumber kebutuhan : decision support system
unconstrained encounter video game corporate accounting system manufacturing control system
Type of application
enhancement to corporate accounting system flight control system for airliner
highly constrained Relatively low
missile guidance system
Approximate % of requirements gathered from people
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
Relatively high 13/43
Proses : Elisitasi dan Analisis Requirements definition
Requirements checking
Domain understanding
Prioritisation Requirements specification Conflict resolution
Requirements collection
Classification
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
14/43
Proses : Elisitasi dan Analisis (Contoh) Perangkat lunak harus mampu menyediakan sarana untuk menampilkan dan mengakses file-file yang dibuat oleh tool yang lain. (f) Pengguna harus dapat mencari buku/dokumen/literatur di perpustakaan dgn memasukkan sebuah kata kunci. (f) Sistem tidak boleh dioperasikan oleh pengguna yang tidak memiliki otoritas. (i) Sistem harus menyediakan GUI sehingga dapat digunakan secara mudah oleh pengguna yang belum berpengalaman. (n-f) Sistem harus bisa memanfaatkan database yang sudah ada. (d-c) Sistem harus diimplementasikan dgn bahasa Java. (i-c) Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
15/43
Proses : Spesifikasi Proses untuk menjelaskan kebutuhan P/L yang telah didefinisikan sebelumnya secara lebih detil dan tepat yang akan menjadi dasar bagi perancangan dan implementasi Definisi kebutuhan (req. definition) : 1.
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)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
16/43
Proses : Validasi (+ 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 Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
17/43
Proses : Validasi (+ Verifikasi) 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
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
18/43
Proses : Manajemen Kebutuhan Aktifitas untuk melakukan kontrol terhadap kebutuhan yang sedang maupun telah didefinisikan : – 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) Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
19/43
Metode : Pemodelan Bagian dari proses elisitasi/analisis dan spesifikasi kebutuhan Mengapa : – Memudahkan memahami dan menganalisis kebutuhan – Identifikasi potensi masalah lebih awal
Model yg baik : – – –
Mengurangi kompleksitas Memfasilitasi penjelasan dari permasalahan yg kompleks Tidak mahal dan mudah untuk modifikasi
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
20/43
Metode : Structured Analysis Pertama kali dipopulerkan oleh T. DeMarco (1979) Structured Analysis and System Specification Perluasan notasi untuk kebutuhan real-time systems oleh Hatley dan Pirbhai (1987) – SA/RT Strategies for Real-Time System Specification Processes
Data
Behavior
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
21/43
Metode : Structured Analysis Elemen-elemen :
Data Object Description Data Flow Diagram (DFD)
ER Diagram
Process Specification (PSPEC)
Data Dictionary
State Transition Diagram (STD)
Control Specification (CSPEC)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
22/43
Metode : Structured Analysis ER Diagram : – – – –
Entitas Modalitas : tingkat mandatory Kardinalitas : tingkat relasi Bentuk relasi Manufacturer
Builds
Car
Data Flow Diagram (DFD) : – – –
DFD level 0 : Context Diagram DFD level 1, dst. : breakdown detil, konsistensi Terminator, process, data flow, control flow, memory/storage, control bar
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
Metode : Structured Analysis Contoh Data/Control Context Diagram (DCD/CCD) object returned coins 0* Customer customer selection Vend product slug
coin return request
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
Customer
product
product available
24/43
Metode : Structured Analysis Contoh Data/Control Flow Diagram (DFD/CFD level 1) object
slug
coin return request
coins 1* Get customer payment
5* Dispense change
payment change due
sufficient payment
coin detected
3p Validate payment
price 2p Get product price price table
returned coins
valid selection
product product available
customer selection
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
6p Dispense product product dispensed valid selection product available products 25/43
Metode : Structured Analysis PSPEC – Validate payment (Process 3) Inputs
:
payment (data in) price (data in)
Outputs
:
change due (data out) sufficient payment (control out)
Body
:
IF payment >= price THEN change due = payment – price sufficient payment = TRUE ELSE change due = 0 sufficient payment = FALSE END IF Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
26/43
Metode : Structured Analysis Data/Control Flow Diagram (DFD/CFD level 2) : Dispense change coin return request product available
change due
5.1p Get change coin
returned coins
change coins
coins
payment coins
payment
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
27/43
Metode : Structured Analysis CSPEC – Dispense change : Process Activation Table
coin return request
product available
get change coin
get payment coin
TRUE TRUE 1 0 D/C FALSE 0 1
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
28/43
Metode : Structured Analysis State Transition Diagram (STD) initial accept new coin Waiting for a coin
payment returned accept new coin
coin detected
product dispensed accept new coin
coin return request return payment
Waiting for selection
Returning payment sufficient payment product available=FALSE dispense product return payment Dispensing product
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
29/43
Metode : Structured Analysis Data Dictionary Representasi Simbol : =
: composed of + : and {} : iterations of [….|…] : selection / or () : optional “ “ : literal * * : comment/description
Vend product (partly) : Name
Type
object
[coin | slug](product)
data
product
[ice cream | coffee | candy]
data
coins
0{[quarter | nickel | dime]}8
data
product available
[TRUE | FALSE]
control
[“YES” | “NO”] quarter
*25 cents US currency*
coin return request
[TRUE | FALSE]
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
control 30/43
Metode : Structured Analysis Beberapa panduan pemodelan : – Jumlah proses dalam satu diagram DFD : 4 + 2 – Maks. 4 level dekomposisi (DFD/CFD) – Dekomposisi fungsional (DFD) : fungsi-fungsi yang saling berhubungan dikelompokkan fungsi-fungsi yang tidak berhubungan dipisahkan setiap fungsi dispesifikasi hanya sekali – Data flow membawa informasi yg diperlukan oleh sebuah proses untuk transformasi, control flow membawa informasi yang harus diinterpretasikan untuk merubah perilaku sistem dan/ aktifasi proses – Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi – Context Diagram adalah level tertinggi dari Data/Control Flow Diagram – Penjenjangan CFD harus sesuai dengan DFD Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
31/43
Metode : Object Oriented Analysis Mulai populer akhir ’80an – ’90an (Booch, RumbaughOMT, Jacobson-OOSE, Coad+Yourdon, Wirfs-Brock) : – – – – – –
Elisitasi kebutuhan customer Identifikasi skenario / use-case (use-case diagram) Identifikasi klas berdasarkan kebutuhan customer Identifikasi atribut dan operasi setiap klas Definisi struktur klas (class diagram) Definisi model relasi antar klas (collaboration/sequence diagram) – Definisi
perpindahan status sistem (statechart diagram)
1996 : UML (Unified Modeling Language) – Grady Booch+James Rumbaugh+Ivar Jacobson Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
32/43
Object, Class – Apa Itu ? Objek (Object) : – Benda (tangible & intangible thing) – Contoh : Andi, Eko, Susi – dalam sistem akademik perkuliahan – Sebuah objek memiliki karakteristik : identity
(identitas), state (sekumpulan atribut) & behaviour (sekumpulan operasi)
Notasi :
Nama Objek Atribut2 Operasi2
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
33/43
Object, Class – Apa Itu ? Klas (Class) : – Gambaran umum (template, blue-print) yang menjelaskan sekumpulan objek yang memiliki kesamaan karakteristik (atribut dan operasi) – Merupakan cetakan dari objek – Digunakan untuk menginstansiasi objek yang memiliki identitas yang berbeda – Contoh : Klas Mahasiswa objek Andi, Eko, Susi – Klas Abstrak dan Konkret (abstract & concrete class) – Abstrak : tidak bisa diinstansiasi, sebagai interface (harus ada klas implementasinya) – Konkret : bisa diinstansiasi menjadi beberapa objek Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
34/43
Object, Class – Apa Itu ? Mahasiswa - NIM
Instansiasi : penciptaan objek
- Nama - Buat skripsi - Ujian
Mahasiswa : Andi Mahasiswa : Eko Mahasiswa : Susi Mahasiswa Mahasiswa Mahasiswa - NIM : 001
- NIM : 002 - NIM : 003 - Nama : Andi - Nama : Eko - Nama : Susi - Buat skripsi - Buat skripsi - Buat skripsi - Ujian - Ujian - Ujian
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
35/43
Metode : Object Oriented Analysis – UML Diagram utama : – – – –
Use-case diagram (statis) Class diagram (statis) Collaboration/sequence diagram (dinamis) Statechart diagram (dinamis)
Use-case diagram : – – – –
Menjelaskan perilaku sistem dari tampak luar Menyediakan fungsi-fungsi yg harus dipenuhi sistem Aktor (orang, sistem lain) dan use-case Setiap use-case dilengkapi dengan skenario (deskripsi)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
36/43
Metode : Object Oriented Analysis – UML Use-case diagram :
Ent er object
Customer
Select product
Get return coins
use-case Objective
Allow customer to select a certain product to dispense
Actors
Customer
Pre-condition
Coin detected and valid
Main flow
1. The customer selects a button product. 2. The system displays an entry prompt of number of product to order.
Alternative flows
1. If the selected product is not available, the system will display a message “Your selected product is not available”. 2. If the selected product is available but there isn’t enough number to order, the system will display a messange “The number isn’t enough, max. x”. X is the existing number of the product.
Post-condition
The selected product dispensed as the number needed
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
38/43
Metode : Object Oriented Analysis – UML Class diagram (‘is a’ - inheritance) : Product name : String description : String price : Currency getName() : String getDescription() : String getPrice() :
Currency setName(newName : String) setDescription(newDescription : String) setPrice(newPrice : Currency)
Candy weight : double t ast e : String
Coffee volume : double sugarContent : double type : String
Ice Cream weight : double milkContent : double
Metode : Object Oriented Analysis – UML Class diagram (‘part of’ - aggregation) : Products getP roduct(name : String) : Product isP roductAvailable(name : String) : boolean
0..* Product name : String description : St ring price : Currency getName() : String getDescript ion() : String getP rice() : Currency setName(newName : String) setDescript ion(newDescript ion : String) setP rice(newPrice : Currency)
: Customer
: SelectionScreen
: SelectionController
: Products
selectProduct( ) getValidSelection(String) isProductAvailable(String)
dispenseProduct(String, int)
: DispenserProduct
Alat Bantu + Dokumentasi : 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, dll. Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT
42/43
Alat Bantu + Dokumentasi : 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 Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto K.,ST.MT