Analisis Kebutuhan Rekayasa Perangkat Lunak poltektelkom

Politeknik Telkom Rekayasa Perangkat Lunak 50 Analisis Sistem Perangkat Lunak 1 Mempelajari dan memahami persoalan Pada tahap ini, seorang analis mempelajari masalah yang ada pada perangkat lunak yang dikembangkan, sehingga dapat ditentukan a siapa pemakai yang menggunakan perangkat lunak. b dimana perangkat lunak akan digunakan . c pekerjaan apa saja dari pemakai yang akan dibantu oleh perangkat lunak. d apa saja cakupan dari pekerjaan tersebut, dan bagaimana mekanisme pelaksanaannya. e apa yang menjadi kendala dilihat dari sisi teknologi yang digunakan atau dari sisi hukum dan standar. Cara yang digunakan oleh pengembang khususnya analis dalam memahami masalah perangkat lunak biasanya dilakukan a wawancara dengan pemakai b observasi atau pengamatan lapangan c kuesioner d mempelajari referensi atau dokumen-dokumen yang digunakan, seperti dokumen hasil analisa dan perancangan perangkat lunak. Hasil dari pemahaman masalah tersebut dapat digambarkan dengan model-model tertentu sesuai dengan jenis permasalahannya. Sebagai contoh jika masalah bisnis dapat digambarkan dengan flowmap atau bussiness use case untuk analisa berorientasi objek. Sedangkan untuk masalah matematika dapat digambarkan dengan graf. 2 Mengidentifikasi kebutuhan pemakai Pada tahap identifikasi kebutuhan pemakai user requirement in pada prakteknya menjadi satu pelaksanaannya dengan pemahaman masalah. Hanya saja substansi yang ditanyakan ada sedikit perbedaan, yaitu a fungsi apa yang diinginkan pada perangkat lunak. b data atau informasi apa saja yang akan diproses. c kelakuan sistem apa yang diharapkan. d antarmuka apa yang tersedia software interfaces, hardware interfaces, user interfaces, dan communication interfaces Untuk menangkap kebutuhan dari pemakai dengan baik,terutama kesamaan persepsi. seorang analis membutuhkan a komunikasi dan brainstorming yang intensif dengan pelanggan. b pembuatan prototype perangkat lunak atau screenshoot. c Data atau dokumen yang lengkap. Politeknik Telkom Rekayasa Perangkat Lunak Analisis Sistem Perangkat Lunak 51 3 Mendefinisikan kebutuhan perangkat lunak Saat melakukan pengidentifikasian kebutuhan pemakai, informasi yang diperoleh masih belum terstruktur. Biasanya pemakai akan mengungkapkan apa yang diinginkan dengan bahasa sehari-hari yang biasa mereka gunakan. Sebagi contoh, ungkapan kebutuhan pemakai dibagian akutansi. a saya ingin data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal. b Informasi neraca keuangan bisa saya lihat kapan saja. Kemudian pada tahap ini, kebutuhan pemakai yang belum terstruktur tersebut akan akan dianalisis, diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka dan unjuk kerja perangkat lunak. Sebagai contoh, kebutuhan “data yang dimasukkan oleh bagian penjualan bisa langsung dijurnal” setelah dianalisis, diklasifikasikan dan diterjemahkan, mungki akan menghasilkan pendefinisian kebutuhan sebagai berikut. a Kebutuhan fungsional - Entri dan rekam data transaksi penjualan. - Retrieve data transaksi penjualan untuk periode tertentu periode sesuai dengan inputan periode yang diinputkan pada keyboard. - Rekam data akumulasi transaksi penjualan periode tertentu ke jurnal umum berikut account pasangannya kas. b Kebutuhan antarmuka - Antarmuka pemakai untuk memasukkan dan merekam data penjualan. - Antarmuka pemakai untuk menyajikan dan menjurnal informasi transaksi penjualan pada periode tertentu. - Antarmuka untuk jaringan lokal yang menghubungkan perangkat lunak aplikasi dibagian penjualan dengan perangkat lunak aplikasi dibagian akutansi. c Kebutuhan unjuk kerja - proses jurnal hanya bisa dilakukan sekali setelah data transaksi penjualan direkam. - Adanya otoritas pemakaian perangkat lunak dan akses data sesuai dengan bagian pekerjaan masing-masing. Politeknik Telkom Rekayasa Perangkat Lunak 52 Analisis Sistem Perangkat Lunak Kemudian kebutuhan tersebut akan dimodelkan atau digambarkan dengan teknik analisis dan alat bantu tertentu. Sebagai contoh kebutuhan fungsional dapat dimodelkan dengan menggunakan - Data flow diagram,kamus data,dan spesifikasi proses jika menggunakan anlisis tertsruktur - Use case diagram dan skenario sistem jika menggunkan analisis berorientasi objek. Metode analisis terstruktur tersebut akan dibahas secara detail pada bab ini dan bab.16 untuk metode analisis berorentasi objek. 4 Membuat dokumen spesifikasi kebutuhan perangkat lunak SKPL Semua kebutuhan yang telah didefinisikan selanjutnya dibuat dokumentasinya yaitu Spesifikasi Kebutuhan Perangkat Lunak SKPL atau Software Requirement Specification SRS. Dokumen ini dibuat untuk menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunal, termasuk deskripsi lengkap semua antarmuka yang akan digunakan. Penjelasa rinci tentang SKPL ini akan dibahas pada sub bab 5.3. 5 Mengkaji ulang review kebutuhan Proses untuk mengkaji ulang validasi kebutuhan apakah SKPL sudah konsisten, lengkap, dan sesuai dengan yang diinginkan oleh pemakai. Proses ini bisa dilakukan lebih dari satu kali. Dan sering kali akan muncul kebuthan-kebutuhan baru dari pemakai. Oleh karena itu, diperlukannya negosiasi antara pengembang dengan pelanggan sesuai dengan prinsip “win win solution” sampai kebutuhan tersebut disetujui oleh kedua belah pihak. Sedangkan menurut Pressman [PRE01], analisis kebutuhan perangkat lunak dapat dibagi menjadi lima area pekerjaan, yaitu: a Pengenalan masalah b Evaluasi dan sistesis c Pemodelan d Spesifikasi e Tinjau ulang review Politeknik Telkom Rekayasa Perangkat Lunak Analisis Sistem Perangkat Lunak 53

4.2.3 Metode Analisis

Metode atau teknik untuk melakukan analisis kebutuhan perangkat lunak dapat dikelompokkan berdasarkan pendekatan yang diambil pada saat melakukan aktivitas tersebut. 1 Berorientasi Aliran Data Data Flow Oriented atau Functional Oriented Sudut pandang analisis pada pendekatan ini difokuskan pada aspek fungsional dan behavioral perilaku laku sistem. Pengembang harus mengetahui fungsi-fungsi atau proses-proses apa saja yang ada dalam sistem, data apa yang menjadi masukannya, dimana data tersebut disimpan, transformasi apa yang akan dilakukan terhadap data tersebut, dan apa yang menjadi hasil transformasinya. Selain itu, pengembang harus mengetahui keadaan state, perubahan transition, kondisi condition, dan aksi action dari sistem. Salah satu metode yang paling populer untuk pendekatan ini adalah Analisis Terstruktur Structured Analysis yang dikembangkan oleh Tom DeMarco [DEM76], Chris Gane dan Trish Sarson, dan Edwad Yourdon [YOU89]. Pada metode ini, hasil analisis dan perancangan dimodelkan dengan menggunakan beberapa perangkat pemodelan seperti: - Data Flow Diagram DFD dan Kamus Data data dictionary untuk menggambarkan fungsi-fungsi dari sistem system functions. - Entity-Relationship Diagram ERD untuk menggambarkan data yang disimpan data stored. - State Transition Diagram STD untuk menggambarkan perilaku sistem. - Structure Chart untuk menggambarkan struktur program. 2 Berorientasi Struktur Data Data Structured Oriented Analisis dengan pendekatan ini difokuskan pada struktur data, dimana struktur tersebut dapat dinyatakan secara hirarki dengan menggunakan konstruksi sequence, selection dan repetition. Beberapa metode berorientasi struktur data ini diantaranya adalah: Politeknik Telkom Rekayasa Perangkat Lunak 54 Analisis Sistem Perangkat Lunak a Data Structured System Development DSSD Diperkenalkan pertama kali oleh J.D. Warnier [1974] dan kemudian oleh Ken Orr [1977], sehingga sering disebut juga metode Warnier- Orr. Metode ini menggunakan perangkat entity diagram, assembly line diagram dan Warnier-Orr diagram untuk memodelkan hasil analisis dan perancangannya. b Jackson System Development JSD Dikembangkan oleh M.A. Jackson [1975] dengan menggunakan perangkat pemodelan yang disebut structure diagram dan system specification diagram. 3 Berorientasi Objek Object Oriented Berbeda dengan pendekatan-pendekatan sebelumnya, pendekatan berorientasi objek memandang sistem yang akan dikembangkan sebagai suatu kumpulan objek yang berkorespondensi dengan objek-objek dunia nyata. Pada pendekatan ini, informasi dan proses yang dipunyai oleh suatu objek “dienkapsulasi” dibungkus dalam satu kesatuan. Beberapa metode pengembangan sistem yang berorientasi objek ini diantaranya adalah: - Object Oriented Analysis OOA dan Object Oriented Design OOD dari Peter Coad dan Edward Yourdon 1990. - Object Modeling Technique OMT dari James Rumbaugh 1987. - Object Oriented Software Engineering OOSE.

4.3 Spesifikasi Kebutuhan Perangkat Lunak SKPL

Spesifikasi Kebutuhan Perangkat Lunak atau Software Requirements Specification SRS adalah sebuah dokumen yang berisi pernyataan lengkap dari apa yang dapat dilakukan oleh perangkat lunak, tanpa menjelaskan bagaimana hal tersebut dikerjakan oleh perangkat lunak. Suatu SKPL harus mencantumkan tentang deskripsi lengkap dari semua antarmuka yang ada dalam sistem yang dapat menghubungkan sistem dengan lingkungannya, mencakup antarmuka untuk perangkat keras, perangkat lunak, komunikasi dan pemakai. SKPL bisa terdiri dari banyak dokumentasi yang saling melengkapi. Suatu SKPL harus dapat menguraikan definisi masalah, dan menguraikan masalah dengan tepat dengan cara yang tepat pula. Politeknik Telkom Rekayasa Perangkat Lunak Analisis Sistem Perangkat Lunak 55

4.3.1 Tujuan Pembuatan SKPL

Ada beberapa tujuan pembuatan SKPL, dan itu tergantung kepada siapa yang menulisnya. Pertama, SKPL dapat ditulis oleh pemakai potensial pelanggan dari sistem, dan kedua oleh pengembang sistem. Untuk kasus pertama, tujuan penulisan SKPL adalah untuk mendefinisikan keinginan yang biasanya dinyatakan dalam bentuk penjelasan umum. Untuk yang kedua, tujuan pembuatan SKPL adalah: - Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang perangkat lunak. - Dasar untuk merencanakan dan melaksanakan aktivitas pengujian sistem. - Acuan untuk melakukan perbaikan dan perubahan perangkat lunak. Sedangkan manfaat dan kegunaan SKPL menurut Witarto[WIT04] dari IEEE, adalah - Memastikan kesamaan antara kebutuhan untuk pengembangan dengan kebutuhan yang ditulis didalam dokumen. - Mendefinisikan kerangka kerja bersama untuk proses-proses pengembangan perangkat lunak. - Memperjelas peran dan antarmuka bagi para pihak yang terlibat dalam proses pengembangan perangkat lunak. - Memperjelas jenis dan isi dokumen. - Mengenali tugas, tahapan, baseline, aktivitas kaji ulang, dan dokumentasinya. - Belajar pendekatan praktis yang diterapkan didunia industri. - Menghilangkan persoalan-persoalan seperti yang pernah dialami masa lalu.

4.3.2 Syarat Pembentukan SKPL

Ada empat syarat yang harus diperhatikan saat pembentukan SKPL, yaitu: 1 Mudah diidentifikasi 2 Diuraikan dengan jelas, simple, sederhana, dan concise jelas, tidak ambiguous 3 Bisa divalidasi dan bisa dites test reliable, test accessable 4 Mampu untuk ditelusuri kembali tracebility