REKAYASA PERANGKAT LUNAK (RPL)
Analisis Kebutuhan
Perangkat Lunak
Anonymous Customer
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT2/43
“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 . . . . .”
Communication
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT3/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.MT4/43
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT5/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.MT6/43
Pengertian AnalisisKebutuhan dan Kebutuhan
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT7/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 kebutuhan-kebutuhan sistem (Ian Sommerville)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT8/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.MT9/43
Urgensi & FungsiIf 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.MT10/43
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT11/43
Problem
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT12/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.MT13/43
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT14/43
Tipe dari Requirement
• User requirements
• Persyaratan pengguna adalah pernyataan, biasanya dalam bahasa natural (mis. Bahasa Inggris, Indonesia, dsb.) dan dapat ditambahkan diagram, tentang layanan yang diharapkan untuk disediakan oleh sistem dantentang batasan operasi sistem tersebut
• System requirements• Persyaratan sistem menjelaskan fungsi-fungsi sistem, layanan-layanan sistem, dan
batasan operasional sistem secara rinci. Dokumen persyaratan sistem (kadang-kadang disebut dengan spesifikasi fungsional) seharusnya tepat dan teliti. Diasemestinya mendefinisikan secara pasti apa yang akan diimplementasikan. Diabisa menjadi bagian dari kontrak antara pembeli sistem dan pengembang sistem.
Software Requirements - adopted & adapted from I. Sommerville, 2004
Pembaca Requirements
Software Requirements - adopted & adapted from I. Sommerville, 2004
Definisi dan spesifikasi
Software Requirements - adopted & adapted from I. Sommerville, 2004
PROSES
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT18/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)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT19/43
Karakteristik operasional P/L Interface P/L Batasan P/L
Proses : Elisitasi dan Analisis (1)• 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.MT20/43
Proses : Elisitasi dan Analisis (1)• 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)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT21/43
Proses : Elisitasi dan Analisis (1)• Sumber-sumber kebutuhan :
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT22/43
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
Proses : Elisitasi dan Analisis (1)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT23/43
Domain
understanding
Requirements
checking
Requirements
collection
Classification
Prioritisation
Conflict
resolution
Requirements
definition
Requirements
specification
Kebutuhan fungsional
• Menjelaskan fungsionalitas atau layanan sistem
• Tergantung dari tipe software,user yang diharapkan dan tipe dari sistem dimana software akan digunakan
• Fungsional user requirement dapat berupa statement high level tapi fungsional sistem requirement harus dijabarkan layanan dari sistem tersebut secara detail
Software Requirements - adopted & adapted from I. Sommerville, 2004
The LIBSYS system ( user requirement)
• Sistem perpustakaan yang menyediakan interface ke beberapa database artikel pada perpustakaan lain.
• User dapat melakukan pencarian, download dan cetak artikel tersebut untuk belajar personal
Software Requirements - adopted & adapted from I. Sommerville, 2004
Contoh system functional requirements
• User harus bisa melakukan search pada beberapa kelompok database ataumemilih salah satu nya.
• Sistem harus menyediakan “appropriate viewers” untuk user ketikamembaca document pada media penyimpan document
• Setiap order harus dialokasikan sebuah Unique identifier ( ORDER_ID)dimana user akan mampu untuk mengkopi ke account mediapenyimpanan user
Software Requirements - adopted & adapted from I. Sommerville, 2004
Ketidak tepatan requirement
• Masalah muncul ketika kebutuhan tidak dijabarkan secara tepat
• Kebutuhan yang bersifat ambigu di interprestasikan berbeda antara pengembang dan pengguna
• Lihat kata pada slide 13 =‘appropriate viewers’• Keinginan user- Viewer untuk beberapa macam dokumen
• Interprestasi Developer – hanya menyediakan text viewer yang menunjukkan isi dari dokument
Software Requirements - adopted & adapted from I. Sommerville, 2004
Non-functional requirements
• Persyaratan non-fungsional adalah persyaratan yang tidak secara langsungterkait dengan fungsi-fungsi tertentu yang dimiliki oleh sistem.
• Persyaratan ini mendefinisikan properti dan batasan sistem, misalnyareliability, waktu respon, dan persyaratan kapasitas penyimpanan.
• Persyaratan proses juga dapat dispesifikasikan untuk mengharuskan sistemCASE, bahasa pemrograman, atau metode pengembangan tertentu.
• Persyaratan non-fungsional bisa lebih kritis daripada persyaratan fungsional. Sebagai contoh, persyaratan keselamatan (safety) tertentu pada sistemcontrol pesawat terbang. Jika persyaratan ini tidak dipenuhi, sistem tidakdapat atau tidak boleh digunakan.
Software Requirements - adopted & adapted from I. Sommerville, 2004
Klasifikasi Non-functional
• Product requirements• Requirement yang menspesifikasikan perilaku produk harus berjalan dengan
syarat tertentu e.g kecepatan exekusi, reliabily dsb
• Organisational requirements• Requirement yang memiliki konsekuensi terhadap aturan dan prosedur organsasi
.e.g SOP, implementasi , dsb
• External requirements• Requirement yang muncul karena faktor dari external sistem dan proses
pengembangannya e.g Sistem harus beroperasi sesuai hukum ,dsb
Software Requirements - adopted & adapted from I. Sommerville, 2004
Tipe Non-functional requirement
Software Requirements - adopted & adapted from I. Sommerville, 2004
Contoh Non-functional requirements
• Product requirement• Interface user pada LIBSYS harus dapat diimplemntasikan dengan HTML tanpa frames
atau java Applets
• Organisational requirement• Proses pengembangan sistem dan dokumen yang harus memenuhi
proses dan pengembangan yang didefiniskan pada SOP
• External requirement• Sistem harus tidak membuka seluruh informasi personal tentang customers selain nama
dan nomor referensi untuk operator sistem
Software Requirements - adopted & adapted from I. Sommerville, 2004
Goals dan requirements
• Non-functional requirement mungkin akan sangat sulit untukdinyatakan secara tepat dan requirement yang tidak tepat akan sangatsulit untuk di verifikasi
• Goal• Maksud dari user secara umum ex: kemudahan penggunaan
• Verifiable non-functional requirement• Pernyataan yang menggunakan pengukuran tertentu yang dapat di tes secara
obyektif
• Goals sangat membantu pengembang ketika user menyampaikanmaksud dari sistem user
Software Requirements - adopted & adapted from I. Sommerville, 2004
Contoh
• A system goal• Sistem harus mudah untuk digunakan dengan metode/penguna yang sudah
umum dan di organsiasikan sehingga kesalahan pengguna dapatdiminimalisasikan
• A verifiable non-functional requirement• Pengguna yang sudah umum harus mampu untuk menggunakan semua fungsi
sistem setelah menempu 2 jam pelatihan. Setelah pelatihan, jumlah rata-ratakesalahan yang dialami user harus tidak lebih dari 2 kesalahan per hari
Software Requirements - adopted & adapted from I. Sommerville, 2004
Pengukuran kebutuhan
Software Requirements - adopted & adapted from I. Sommerville, 2004
Proses : Elisitasi dan Analisis (Contoh)• 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 tidakmemiliki otoritas.
• Sistem harus menyediakan GUI sehingga dapat digunakansecara mudah oleh pengguna yang belum berpengalaman.
• Sistem harus bisa memanfaatkan database yang sudah ada.
• Sistem harus diimplementasikan dgn bahasa Java.
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT35/43
Proses : Spesifikasi (2)• 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. P/L 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)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT36/43
Proses : Validasi (+ Verifikasi) (3)• 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.MT37/43
Proses : Validasi (+ Verifikasi) (3)• 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.MT38/43
Proses : Manajemen Kebutuhan (4)• 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.MT39/43
Model
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT40/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
• Structured Analysis dan Object Oriented Analysis
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT41/43
Metode
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT42/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
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT43/43
Processes
Data Behavior
Metode : Structured Analysis• Elemen-elemen :
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT44/43
Data Dictionary
Data Flow Diagram
(DFD)
ER Diagram
State Transition Diagram
(STD)
Process Specification
(PSPEC)
Data Object Description
Control Specification
(CSPEC)
Metode : Structured Analysis• ER Diagram :
• Entitas• Modalitas : tingkat mandatory• Kardinalitas : tingkat relasi• Bentuk relasi
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT45/43
Manufacturer CarBuilds
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
Metode : Structured Analysis• Contoh Data/Control Context Diagram (DCD/CCD)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT46/43
Vend
productCustomer
returned coins
0*
Customer
product
object
customer
selection
slug
coin return
request product
available
Metode : Structured Analysis• Contoh Data/Control Flow Diagram (DFD/CFD level 1)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT47/43
1*
Get
customer
payment
2p
Get
product
price
3p
Validate
payment
4p
Get valid
selection
5*
Dispense
change
6p
Dispense
product
price table
coins
products
returned coins
product
object
customer
selection
slug
coin return
request
payment
price
valid selection
change due
valid selection
coin detectedsufficient
payment
product
dispensed
product
available
product
available
Metode : Structured Analysis• PSPEC – Validate payment (Process 3)
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT48/43
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
Metode : Structured Analysis• Data/Control Flow Diagram (DFD/CFD level 2) : Dispense change
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT49/43
5.1p
Get change
coin
coin return
request
5.2p
Get
payment
coin
product
availablechange due
coins
payment
payment coins
change coins returned coins
Metode : Object Oriented Analysis• Mulai populer akhir ’80an – ’90an (Booch, Rumbaugh-OMT,
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.MT54/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 :
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT55/43
Nama Objek
Atribut2
Operasi2
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.MT56/43
Object, Class – Apa Itu ?
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT57/43
Mahasiswa
- NIM
- Nama
- Buat skripsi
- Ujian
Mahasiswa
- NIM : 001
- Nama : Andi
- Buat skripsi
- Ujian
Mahasiswa : Andi
Mahasiswa
- NIM : 002
- Nama : Eko
- Buat skripsi
- Ujian
Mahasiswa : Eko
Mahasiswa
- NIM : 003
- Nama : Santi
- Buat skripsi
- Ujian
Mahasiswa : Susi
Instansiasi :
penciptaan objek
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.MT58/43
Metode : Object Oriented Analysis – UML• Use-case diagram :
Select product
Get return coins
Customer
Enter object
Metode : Object Oriented Analysis – UML
• Use-case scenario :
Flow of events for the Select product 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.MT60/43
Metode : Object Oriented Analysis – UML• Class diagram (‘is a’ - inheritance) :
Metode : Object Oriented Analysis – UML• Class diagram (‘part of’ - aggregation) :
Metode : Object Oriented Analysis – UML• Sequence diagram :
: Customer : SelectionScreen : SelectionController : Products :
DispenserProduct
selectProduct( )getValidSelection(String)
isProductAvailable(String)
dispenseProduct(String, int)
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.MT64/43
Alat Bantu + Dokumentasi : Dokumentasi• IEEE Standard+ (IRS/SRS):
Bahan Kuliah RPL - Analisis Kebutuhan PL / Tri Astoto
K.,ST.MT65/43
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
Challenge in Software engineering
Please Minimize this !