rpl… · ppt file · web view · 2015-09-28rpl - rekayasa kebutuhan pl - konsep / tri a....
TRANSCRIPT
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 2/24
Tujuan perkuliahan
Memahami pengertian dan urgensi rekayasa kebutuhanMemahami proses rekayasa kebutuhanMemahami problem-problem dalam rekayasa kebutuhanMemahami dokumentasi kebutuhan PL dan alat bantu
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 3/24
Agenda
Pengertian kebutuhan dan rekayasa kebutuhanUrgensi dan fungsiProsesProblem-problemDokumentasi kebutuhan dan alat bantu
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 4/24
Motivation
“The hardest single part of building a system is deciding what to build”
[Brooks – 1987]
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 5/24
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 . . . . .”
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 7/24
Apa itu RE ?
RE – requirements engineering istilah lain dari requirements analysisEach software development process goes through the phase of REThe process of establishing the services that the customer requires from a system and the constraints under which it operates and is developed [Ian Sommerville]The broad spectrum of tasks and techniques that lead to an understanding of requirements [Roger S. Pressman]
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 8/24
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]
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 9/24
Kategori kebutuhan
Functional what a system does– Deskripsi proses, masukan dan keluaran
Non-functional constraint or quality of a system– Performance, availability, security, reliability,
implementation & design constraints, storage sizeUsability constraint to use– Acceptance criteria, end-user characteristics, system
environments
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 10/24
Level kebutuhan
Normal requirement kebutuhan yang harus dipenuhi dan dinyatakan secara eksplisit– Fungsionalitas sistem, unjuk kerja
Expected requirement kebutuhan yang tidak dinyatakan secara eksplisit tetapi menentukan kepuasan customer– Kemudahan interaksi dengan sistem, correctness
Exciting requirement kebutuhan yang melebihi dari kebutuhan normal untuk lebih memuaskan customer– Fungsionalitas tambahan sistem
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 11/24
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]
Fungsi RE:– Sebagai 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
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 12/24
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)
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 13/24
Elisitasi dan analisis
Developer harus memahami domain permasalahanDeveloper dan stakeholder menggali domain aplikasi, layanan-layanan sistem yang harus disediakan, unjuk kerja sistem yang diperlukan, batasan-batasan perangkat keras dan sejenisnyaFokus pada A P A (WHAT) dan B U K A N bagaimana (HOW)Komunikasi adalah faktor penting
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 14/24
Diagram alir elisitasi dan analisis
Domain understanding
Requirementschecking
Requirements collection
Classification
Prioritisation
Conflictresolution
Requirementsdefinition
Requirementsspecification
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 15/24
Sumber-sumber elisitasi
Relatively high
Relatively low
Approximate % of requirementsgathered from people
Type of application
highly constrained
missile 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
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 16/24
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.
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 17/24
Spesifikasi kebutuhan
Proses untuk menjelaskan kebutuhan PL yang telah didefinisikan sebelumnya secara lebih detil dan tepat yang akan menjadi dasar bagi perancangan dan implementasiDefinisi 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)
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 18/24
Validasi dan verifikasi
Proses pengecekan untuk menjamin bahwa pernyataan kebutuhan yang telah didefinisikan dan dispesifikasikan adalah benar, akurat dan lengkapDilakukan bersama-sama antara kustomer dan developerSangat penting dilakukan karena kesalahan di dalam menentukan kebutuhan akan berdampak pada keseluruhan proses yang mengikutinyaValidasi : 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
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 19/24
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
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 20/24
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)
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 21/24
Problem
Stakeholder (end-user, manajer, maintenance engineer, policy maker) tidak tahu persis apa yang sesungguhnya mereka butuhkanStakeholder menyatakan kebutuhannya dalam bahasa yang dipahami oleh mereka sendiriStakeholder yang berbeda mungkin memiliki kebutuhan yang saling bertentanganKebutuhan mungkin berubah pada saat dilakukan analisis. Stakeholder baru yang bergabung mungkin merubah dan lingkungan bisnis mengalami perubahanPertentangan antara unjuk kerja (performance) dan kemudahan (simplicity) dalam mencapai tujuan
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 22/24
Problem (1)
Customer explanation
Designed by AnalystProject Leader understanding
Coded by Programmer
Described byBus. Consultant
Project documentation
Operation installation
Customer cost Supports Customer really needs
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 23/24
Dokumentasi
IEEE Standard+ (IRS/SRS):1. Introduction
1.1. Purpose of the requirements document1.2. Scope of the product1.3. Definition, acronyms and abbreviations1.4. References
2. General Description2.1. Product perspective2.2. Product functions2.3. User characteristics2.4. General constraints
3. Specific RequirementsAll functional and non-functional requirements, system models (eg. DFD/CFD, ERD, STD, Use-Case, Class, Sequence, Statechart diagrams), performance, database requirements, design constraints, security.
4. Qualification/Validation Requirements5. Appendices/Bibliography
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D 24/55
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.
RPL - Rekayasa Kebutuhan PL - Konsep / Tri A. Kurniawan, S.T, M.T, Ph.D 25/24
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 customerProses di dalam RE mencakup elisitasi dan analisis, spesifikasi, validasi dan verifikasi, manajemen kebutuhanSebuah kebutuhan harus divalidasi dan diverifikasi sebelum digunakan sebagai dasar dalam perancangan