Sftware Requirement ( PL) Arna Fariza 1 Rekayasa Perangkat Lunak Tujuan Memperkenalkan knsep persyaratan user dan sistem Menjelaskan persyaratan fungsinal dan nnfungsinal Menjelaskan bagaimana persyaratan PL dapat ditulis dalam dkumen persyaratan Rekayasa Perangkat Lunak 2 1
Materi fungsinal dan nn-fungsinal user sistem Spesifikasi antar muka Dkumen persyaratan PL Rekayasa Perangkat Lunak 3 Rekayasa Prses menetapkan layanan yang dibutuhkan knsumen terhadap sistem dan batasan perasi dan pengembangan. itu sendiri adalah diskripsi layanan sistem dan batasan yang dihasilkan selama prses rekayasa persyaratan. Rekayasa Perangkat Lunak 4 2
Apakah itu? Pernyataan abstrak level tinggi dari layanan atau batasan sistem ke dalam spesifikasi fungsinal matematis Tidak terelakkan bahwa persyaratan mempunyai dua fungsi merupakan dasar untuk penawaran kntrak sehingga harus terbuka untuk interpretasi merupakan dasar untuk kntrak itu sendiri sehingga harus didefinisikan secara detail Kedua pernyataan diatas disebut persyaratan Rekayasa Perangkat Lunak 5 Abstraksi (Davis) Jika sebuah perusahaan akan mengadakan kntrak untuk pryek pengembangan sftware besar, harus didefinisikan persyaratan yang cukup dimana slusi belum terdefinisi. harus ditulis sehingga beberapa kntraktr dapat menawarkan kntrak, penawaran, kemungkinan, secara berbeda dengan persyaratan rganisasi client. Bila kntrak sudah diserahkan, kntraktr harus menulis definisi sistem untuk client secara lebih detail sehingga client mengerti dan dapat mem-validasi sftware yang akan dikerjakan. Kedua dkumen ini disebut dkumen persyaratan untuk sistem Rekayasa Perangkat Lunak 6 3
Tipe-tipe User Lapran dalam bahasa natural plus diagram layanan yang tersedia dan batasan perasinal. Ditulis leh knsumen Sistem Dkumen terstruktur yang berisi diskripsi detail dari fungsi sistem, layanan dan batasan perasinal. Mendefinisikan apa yang harus dilaksanakan sehingga dapat menjadi bagian dari kntrak antara knsumen dan develper. Rekayasa Perangkat Lunak 7 Definisi dan Spesifikasi Definisi 1. 1. Sftware harus menyediakan ketentuan menampilkan dan mengakses file yang dibuat leh tl lain Spesifikasi 1.1 User diberikan fasilitas untuk mendefinisikan tipe file eksternal 1.2 Setiap tipe file eksternal mempunyai alat untuk dihubungkan yang dapat diaplikasikan ke file 1.3 Setiap tipe file eksternal direpresentasikan sebagai icn tertentu pada tampilan user 1.4 Fasilitas disediakan untuk icn yang merepresentasikan tipe file eksternal yang didefinisikan leh user 1.5 Jika user memilih icn untuk merepresentasikan file eksternal, efek pemilihan mengaplikasikan alat yang menghubungkan antara tipe file eksternal ke file yang direpresentasikan leh icn terpilih Rekayasa Perangkat Lunak 8 4
Pengguna user Manajer client End-user sistem Engineer client Manager kntraktr Arsitek sistem sistem End-user sistem Engineer client Arsitek sistem Develper sftware Spesifikasi desain sftware Engineer client (kemungkinan) Arsitek sistem Develper sftware Rekayasa Perangkat Lunak 9 Fungsinal dan nn-fungsinal fungsinal Pernyataan layanan sistem yang harus disediakan, bagaimana sistem bereaksi pada input tertentu dan bagaimana perilaku sistem pada situasi tertentu nn-fungsinal Batasan layanan atau fungsi yang ditawarkan sistem seperti batasan waktu, batasan pengembangan prses, standarisasi dll dmain yang datang dari dmain aplikasi sistem dan yang menyatakan karakteristik dari dmain tersebut Rekayasa Perangkat Lunak 10 5
Fungsinal Menggambarkan fungsinalitas atau layanan sistem Tergantung pada jenis PL, harapan user dan jenis sistem dimana PL digunakan Perysaratan fungsinal user merupakan pernyataan level tinggi dari apa yang seharusnya dilakukan sistem tetapi persyaratan fungsinal sistem harus menggambarkan layanan sistem secara rinci Rekayasa Perangkat Lunak 11 Cnth Kasus : System LIBSYS Sebuah sistem perpustakaan yang menyediakan antarmuka tunggal untuk sejumlah database dari artikel di perpustakaan yang berbeda. Pengguna dapat mencari, mengunduh dan mencetak artikel secara pribadi. 6
Cnth Peryaratan Fungsinal User seharusnya dapat melakukan pencarian melalui database atau subsetnya. Sistem menyediakan tampilan yang tepat bagi user untuk membaca dkumen dalam penyimpan dkumen. Setiap rder akan dialkasikan identifikasi unik (ORDER_ID) dimana pengguna dapat menyalin ke penyimpanan sekunder. Ketidaktepatan Peryaratan Permasalahan timbul jika persyaratan tidak ditetapkan dengan jelas yang sama mungkin diinterprestasikan dengan cara yang berbeda leh develper dan user Pertimbangkan Viewer yang tepat Keinginan user tampilan khusus untuk tipe dkumen yang berbeda Interpretasi develper menyediakan tampilan teks yang menunjukkan isi dkumen Rekayasa Perangkat Lunak 14 7
Knsistensi dan Kelengkapan Secara prinsip, persyaratan harus lengkap dan knsisten Lengkap Knsisten Harus mendiskripsikan semua fasilitas yang dibutuhkan Tidak terdapat knflik atau kntradiksi dalam mendiskripsikan fasilitas sistem Dalam prakteknya, tidak mungkin menghasilkan dkumen persyaratan yang lengkap dan knsisten Rekayasa Perangkat Lunak 15 Peryaratan Nn-fungsinal Mendifinisikan sifat sistem dan batasan sistem, seperti kehandalan, waktu respn, kebutuhan penyimpan. Batasan lain misalnya kapabilitas perangkat I/O, representasi sistem dll prses juga dapat ditentukan dari sistem CASE khusus, bahasa pemrgraman atau metde pengembangan nn-fungsinal mungkin lebih penting kritis daripada persyaratan fungsinal. Jika tidak terpenuhi, sistem menjadi tidak berguna Rekayasa Perangkat Lunak 16 8
Klasifikasi Nn-fungsinal Prduk persyaratan yang menetapkan bahwa prduk yang dikirim harus berjalan dengan cara tertentu, cnth kecepatan eksekusi, kehandalan dll Organisasi persyaratan sebagai akibat dari kebijakan rganisasi dan prsedur misalnya standar prses yang digunakan, persyaratan implementasi dll Eksternal persyaratan yang muncul dari faktr eksternal sistem dan prses pengembangan misalnya persyaratan antar perasi, persyaratan legistatif dll Rekayasa Perangkat Lunak 17 Tipe Nn-fungsinal nnfungsinal prduk rganisasi eksternal efisiensi kehandalan prtabilitas interperasi ethical kemampuan penggunaan penyerahan implementasi standar legislatif perfrmansi ruang privacy keselamatan Rekayasa Perangkat Lunak 18 9
Cnth Nn-fungsinal Prduk 8.1 User interface untuk LIBSYS harus diimplementasikan sebagai HTML sederhana tanpa frame atau Java applet. Organisasi 9.3.2 Prses pengembangan sistem dan penyerahan dkumen harus sesuai dengan prses dan penyerahan yang didefinisikan dalam XYZC-SP-STAN-95. Eksternal 7.6.5 Sistem seharusnya tidak mengungkapkan infrmasi pribadi apapun tentang knsumen selain nama dan nmr referensi ke peratr sistem. Rekayasa Perangkat Lunak 19 Dmain Berasal dari dmain aplikasi dan menggambarkan karakteristik sistem dan fitur yang mencerminkan dmain. Dmain persyaratan menjadi persyaratan fungsinal baru, batasan pada peryaratan yang ada atau mendefinisikan kmputasi tertentu. Jika persyaratan dmain tidak terpenuhi, sistem mungkin tidak dapat dijalankan. Rekayasa Perangkat Lunak 20 10
Dmain pada LIBSYS Harus ada user interface standar untuk semua database yang harus didasarkan pada standar Z39.50. Karena pembatasan hak cipta, beberapa dkumen harus dihapus segera setelah tiba. Tergantung persyaratan user, dkumen tersebut dapat dicetak secara lkal pada server sistem untuk dikirim secara manual ke user atau dilewatkan ke netwrk printer. Rekayasa Perangkat Lunak 21 Permasalahan Dmain Kemampuan untuk dimengerti dinyatakan dalam bahasa dmain aplikasi Hal ini sering tidak dipahami leh sftware engineer yang mengembangkan sistem Ketidaklengkapan Dmain khusus sudah mengerti area dengan baik sehingga mereka tidak berfikir untuk membuat persyaratan dmain secara eksplisit Rekayasa Perangkat Lunak 22 11
User Menjelaskan persyaratan fungsinal dan nnfungsinal sedemikian rupa sehingga dimengerti leh user yang tidak mempunyai pengetahuan teknis yang rinci. user didefinisikan menggunakan bahasa alami, tabel dan diagram yang dapat dipahami leh semua user. Rekayasa Perangkat Lunak 23 Permasalahan dengan Bahasa Alami Ketidakjelasan Sulit untuk presisi tanpa membuat dkumen yang sulit dibaca. yang membingungkan fungsinal dan nn-fungsinal cenderung dicampur aduk Penggabungan persyaratan Beberapa persyaratan yang berbeda dinyatakan bersama-sama Rekayasa Perangkat Lunak 24 12
LIBSYS 4.. 5 LIBSYS wajib menyediakan sistem akuntansi keuangan yang menyimpan catatan dari semua pembayaran yang dilakukan leh user sistem. Manajer sistem dapat mengknfigurasi sistem ini sehingga user biasa mungkin menerima ptngan harga Rekayasa Perangkat Lunak 25 Permasalahan database terdiri dari infrmasi baik knseptual maupun rinci Menjelaskan knsep sistem akuntansi keuangan yang akan dimasukkan dalam LIBSYS; Namun, juga mencakup hal detail mengenai knfigurasi sistem yang dapat dilakukan manajer dapat mengknfigurasi sistem ini - hal ini tidak diperlukan pada tingkat ini. Rekayasa Perangkat Lunak 26 13
Ketentuan Penulisan Menciptakan frmat standard dan menggunakannya untuk semua persyaratan. Menggunakan bahasa secara knsisten. Menggunakan penanda teks untuk identifikasi bagian penting dari persyaratan Hindari penggunakan jargn kmputer Rekayasa Perangkat Lunak 27 Sistem Spesifikasi fungsi sistem yang lebih rinci, layanan dan batasan persyaratan user Sebagai dasar merancang sistem Biasanya digunakan sebagai bagian dari kntrak sistem Rekayasa Perangkat Lunak 28 14
dan Desain Secara prinsip, persyaratan menyatakan apa yang seharusnya sistem lakukan dan desain menjelaskan bagaimana melakukannya Prakteknya, persyaratan dan desain dibedakan Arsitektur sistem dirancang untuk men-strukturkan persyaratan Sistem dapat berperasi dengan sistem lain yang menghasilkan persyaratan desain Penggunaan desain tertentu mungkin menjadi persyaratan dmain Rekayasa Perangkat Lunak 29 Permasalahan dengan Spesifikasi Bahasa Alami Kemenduaan Pembaca dan penulis persyaratan harus menginterpretasikan kata yang sama dg cara yang sama. Bahasa alami secara natural bersifat mendua sehingga hal ini sangat sulit Terlalu Fleksibel Hal yang sama mungkin dikatakan dengan beberapa cara yang berbeda dalam spesifikasi Tidak ada mdularitas Struktur bahasa alami tidak cukup untuk men-strukturkan persyaratan sistem Rekayasa Perangkat Lunak 30 15
Alternatif Spesifikasi dalam Bahasa Alami Ntasi Bahasa natural terstruktur Bahasa deskripsi desain Ntasi grafis Spesifikasi Matematis Deskripsi Pendekatan ini tergantung definisi bentuk standard atau template untuk menggambarkan spesifikasi persyaratan Pendekatan ini menggunakan bahasa seperti bahasa pemrgraman tetapi lebih banyak fitur abstrak untuk menentukan persyaratan dengan mendefinisikan mdel perasi dari sistem bahasa grafis, ditambahkan dengan text digunakan untuk mendefinisikan persyaratan fungsinal untuk sistem Cnthnya sebelumnya bahasa grafis SADT (Rss, 1977; Schman and Rss, 1977), saat ini digunakan deskripsi use case (Jacbsen, Christersn et al.,1993) Ada beberapa ntasi berbasis knsep matematis seperti mesin finite-state atau himpunan. Spesifikasi yang ganda dapat mengurangi argumen antara knsumen dan kntraktr tentang fungsinal sistem. Sebaliknya, sebagian besar knsumen tidak mengerti spesifikasi frmal dan enggan menerimanya sebagai kntrak sistem Rekayasa Perangkat Lunak 31 Spesifikasi dg Bahasa Terstruktur Kebebasan penulisan persyaratan dibatasi leh template standar untuk persyaratan. Semua persyaratan ditulis dengan cara yang standar. Terminlgi yang digunakan dalam deskripsi mungkin terbatas. Keuntungannya adalah bahwa sebagian besar ekspresi dari bahasa alami dipertahankan dengan penyeragaman pada spesifikasi. Rekayasa Perangkat Lunak 32 16
Spesifikasi Berbasis Frm Definisi fungsi atau entiti Menggambarkan input dan darimana berasal Menggambarkan utput dan dimana berjalan Mengindikasikan entiti lain yang diperlukan Kndisi sebelum dan sesudah (jika diperlukan) Efek lain (jika ada) dari fungsi Rekayasa Perangkat Lunak 33 Spesifikasi nde Berbasis Frm BCLIPSB/Wrkstatin/Tls/DB/3.5.1 Functin Tambah nde Deskripsi Menambah nde ke desain yang sudah ada. User memilih tipe nde dan psisi bila ditambahkan ke desain, nde menjadi pilihan saat ini. User memilih psisi nde dan memindahkan kursr ke area dimana nde ditambahkan Input Surce database Output Tujuan Pre-kndisi Tipe nde, psisi nde, identifier desain Tipe nde dan psisi nde diinputkan leh user, identifier desain dari Identifier desain Desain database. Desain membuat database menyelesaikan perasi Desain graph akar dari identifier desain input Desain terbuka dan ditampilkan pada layar user Pst-kndisi Desain tidak berubah terpisah dari tambahan nde tipe tertentu pada psisi yang diberikan Efek lain TIdak ada Rekayasa Perangkat Lunak 34 17
Diagram Sequence Menunjukkan urutan peristiwa yang terjadi selama beberapa user berinteraksi dengan sistem. Dibaca dari atas ke bawah untuk melihat urutan tindakan yang terjadi. Penarikan dari ATM Validasi Kartu; Menangani permintaan; Transaksi selesai. Diagram Sequence pada Penarikan ATM 18
Spesifikasi Antar Muka Sebagian besar sistem harus berperasi dengan sistem lain dan antar muka perasi harus ditentukan sebagai bagian persyaratan Tiga tipe antar muka Antar muka prsedural Struktur data yang dapat ditukar Representasi data Ntasi frmal adalah teknik efektif untuk spesifikasi antar muka Rekayasa Perangkat Lunak 37 Deskripsi Antar Muka PDL interface PrintServer { // defines an abstract printer server // requires: interface Printer, interface PrintDc // prvides: initialize, print, displayprintqueue, cancelprintjb, switchprinter vid initialize ( Printer p ) ; vid print ( Printer p, PrintDc d ) ; vid displayprintqueue ( Printer p ) ; vid cancelprintjb (Printer p, PrintDc d) ; vid switchprinter (Printer p1, Printer p2, PrintDc d) ; } //PrintServer Rekayasa Perangkat Lunak 38 19
Dkumen Dkumen persyaratan adalah pernyataan resmi dari apa yang dibutuhkan leh develper sistem Harus mencakup persyaratan pengguna dan spesifikasi persyaratan sistem. BUKAN dkumen desain. Sejauh mungkin, menentukan APA yang harus dikerjakan sistem daripada BAGAIMANA mengerjakannya Rekayasa Perangkat Lunak 39 Knsumen sistem Spesifikasi persyaratan dan membacanya untuk memeriksa apakah sesuai persyaratan knsumen. Knsumen menentukan perubahan persyaratan User dari dkumen persyaratan Manager Engineer sistem Menggunakan dkumen persyaratan untuk perencanaan sistem dan merencanakan prses pengembangan sistem Menggunakan persyaratan untuk mengerti sistem apa yang dikembangkan Engineer testing sistem Menggunakan persyaratan untuk mengembangkan tes validasi sistem Engineer maintenance sistem Menggunakan persyaratan untuk membantu mengerti sistem dan hubungan antar bagian Rekayasa Perangkat Lunak 40 20
Standard IEEE untuk Menentukan struktur umum untuk dkumen persyaratan yang harus ditulis untuk setiap sistem Pendahuluan Deskripsi Umum khusus Lampiran Indeks Rekayasa Perangkat Lunak 41 Struktur Dkumen Pendahuluan Daftar Istilah Definisi User Arsitektur Sistem Spesifikasi persyaratan sistem Mdel sistem Evlusi sistem Lampiran Indeks Rekayasa Perangkat Lunak 42 21
Key Pint menentukan apa yang seharusnya dilakukan sistem dan menentukan batasan perasi dan implementasi fungsinal menentukan layanan sistem yang harus disediakan nn-fungsinal membatasi pengembangan sistem atau pengembangan prses user adalah pernyataan level tinggi apa yang sistem harus kerjakan. user sebaiknya ditulis menggunakan bahasa alami, tabel dan diagram Rekayasa Perangkat Lunak 43 Key Pint sistem dimaksudkan untuk mengkmunikasikan fungsi yang harus disediakan sistem Dkumen persyaratan sftware adalah pernyataan persetujuan dari persyaratan sistem Standart IEEE digunakan untuk mendefinisikan persyaratan khusus lebih rinci sesuai standart. Rekayasa Perangkat Lunak 44 22