REKAYASA PERANGKAT LUNAK (RPL) Analisis Kebutuhan Perangkat Lunak

Transkripsi

1 REKAYASA PERANGKAT LUNAK (RPL) Analisis Kebutuhan Perangkat Lunak

2 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 /43

3 Communication 3/43

4 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 4/43

5 5/43

6 Agenda Pembahasan Pendahuluan Pengertian Analisis Kebutuhan dan Kebutuhan Urgensi dan Fungsi Analisis Kebutuhan Problem Proses Metode Alat Bantu dan Dokumentasi 6/43

7 Pengertian Analisis Kebutuhan dan Kebutuhan 7/43

8 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) 8/43

9 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) 9/43

10 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 10/43

11 11/43

12 Problem 12/43

13 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 13/43

14 14/43

15 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 dan tentang batasan operasi sistem tersebut System requirements Persyaratan sistem menjelaskan fungsi-fungsi sistem, layanan-layanan sistem, dan batasan operasional sistem secara rinci. Dokumen persyaratan sistem (kadangkadang disebut dengan spesifikasi fungsional) seharusnya tepat dan teliti. Dia semestinya mendefinisikan secara pasti apa yang akan diimplementasikan. Dia bisa menjadi bagian dari kontrak antara pembeli sistem dan pengembang sistem. Software Requirements - adopted & adapted from I. Sommerville, 2004

16 Pembaca Requirements Software Requirements - adopted & adapted from I. Sommerville, 2004

17 Definisi dan spesifikasi Software Requirements - adopted & adapted from I. Sommerville, 2004

18 PROSES 18/43

19 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 Batasan P/L 19/43

20 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 20/43

21 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) 21/43

22 Proses : Elisitasi dan Analisis (1) Sumber-sumber kebutuhan : unconstrained decision support system encounter video game corporate accounting system Type of application manufacturing control system enhancement to corporate accounting system flight control system for airliner highly constrained missile guidance system Relatively low Approximate % of requirements gathered from people Relatively high 22/43

23 Proses : Elisitasi dan Analisis (1) Requirements checking Requirements definition Domain understanding Requirements collection Prioritisation Conflict resolution Requirements specification Classification 23/43

24 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

25 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

26 Contoh system functional requirements User harus bisa melakukan search pada beberapa kelompok database atau memilih salah satu nya. Sistem harus menyediakan appropriate viewers untuk user ketika membaca document pada media penyimpan document Setiap order harus dialokasikan sebuah Unique identifier ( ORDER_ID) dimana user akan mampu untuk mengkopi ke account media penyimpanan user Software Requirements - adopted & adapted from I. Sommerville, 2004

27 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

28 Non-functional requirements Persyaratan non-fungsional adalah persyaratan yang tidak secara langsung terkait dengan fungsi-fungsi tertentu yang dimiliki oleh sistem. Persyaratan ini mendefinisikan properti dan batasan sistem, misalnya reliability, waktu respon, dan persyaratan kapasitas penyimpanan. Persyaratan proses juga dapat dispesifikasikan untuk mengharuskan sistem CASE, bahasa pemrograman, atau metode pengembangan tertentu. Persyaratan non-fungsional bisa lebih kritis daripada persyaratan fungsional. Sebagai contoh, persyaratan keselamatan (safety) tertentu pada sistem control pesawat terbang. Jika persyaratan ini tidak dipenuhi, sistem tidak dapat atau tidak boleh digunakan. Software Requirements - adopted & adapted from I. Sommerville, 2004

29 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

30 Tipe Non-functional requirement Software Requirements - adopted & adapted from I. Sommerville, 2004

31 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

32 Goals dan requirements Non-functional requirement mungkin akan sangat sulit untuk dinyatakan secara tepat dan requirement yang tidak tepat akan sangat sulit 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 menyampaikan maksud dari sistem user Software Requirements - adopted & adapted from I. Sommerville, 2004

33 Contoh A system goal Sistem harus mudah untuk digunakan dengan metode/penguna yang sudah umum dan di organsiasikan sehingga kesalahan pengguna dapat diminimalisasikan 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-rata kesalahan yang dialami user harus tidak lebih dari 2 kesalahan per hari Software Requirements - adopted & adapted from I. Sommerville, 2004

34 Pengukuran kebutuhan Software Requirements - adopted & adapted from I. Sommerville, 2004

35 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 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. 35/43

36 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) 36/43

37 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 37/43

38 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 38/43

39 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) 39/43

40 Model 40/43

41 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 41/43

42 Metode 42/43

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 43/43

44 Metode : Structured Analysis Elemen-elemen : Data Object Description ER Diagram Process Specification (PSPEC) Data Flow Diagram (DFD) Data Dictionary State Transition Diagram (STD) Control Specification (CSPEC) 44/43

45 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 45/43

46 Metode : Structured Analysis Contoh Data/Control Context Diagram (DCD/CCD) object 0* returned coins Customer customer selection Vend product Customer slug product coin return request product available 46/43

47 Metode : Structured Analysis Contoh Data/Control Flow Diagram (DFD/CFD level 1) object coins coin return request slug coin detected price table 1* Get customer payment 2p Get product price payment sufficient payment price valid selection customer selection 3p Validate payment change due 4p Get valid selection product available 5* Dispense change valid selection product available 6p Dispense product returned coins products product product dispensed 47/43

48 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 48/43

49 Metode : Structured Analysis Data/Control Flow Diagram (DFD/CFD level 2) : Dispense change change due coin return request product available 5.1p Get change coin change coins returned coins coins payment 5.2p Get payment coin payment coins 49/43

50 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 54/43

51 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 55/43

52 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 56/43

53 Object, Class Apa Itu? Mahasiswa Instansiasi : penciptaan objek - NIM - Nama - Buat skripsi - Ujian Mahasiswa : Andi Mahasiswa - NIM : Nama : Andi - Buat skripsi - Ujian Mahasiswa : Eko Mahasiswa - NIM : Nama : Eko - Buat skripsi - Ujian Mahasiswa : Susi Mahasiswa - NIM : Nama : Santi - Buat skripsi - Ujian 57/43

54 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) 58/43

55 Metode : Object Oriented Analysis UML Use-case diagram : Enter object Customer Select product Get return coins

56 Metode : Object Oriented Analysis UML Use-case scenario : Flow of events for the Select product use-case Objective Actors Pre-condition Allow customer to select a certain product to dispense Customer 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 60/43

57 Metode : Object Oriented Analysis UML Class diagram ( is a - inheritance) :

58 Metode : Object Oriented Analysis UML Class diagram ( part of - aggregation) :

59 Metode : Object Oriented Analysis UML Sequence diagram : : Customer : SelectionScreen : SelectionController : Products : DispenserProduct selectproduct( ) getvalidselection(string) isproductavailable(string) dispenseproduct(string, int)

60 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. 64/43

61 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 65/43

62 Challenge in Software engineering

63 Please Minimize this!