Spesifikasi Kebutuhan Requirements Engineering (IF 51XX) Daniel Siahaan

Isi Apa dan untuk apa Spesifikasi Kebutuhan Metode Spesifikasi Kebutuhan Standard terkait Spesifikasi Kebutuhan Kakas Bantu

Apakah Spesifikasi Kebutuhan Spesifikasi kebutuhan salah satu aktivitas yang dilakukan ketika merekayasa kebutuhan. Spesifikasi kebutuhan merupakan suatu proses memformalisasikan sekumpulan kebutuhan, baik fungsional maupun non-fungsional, dari suatu sistem yang hendak dibangun ke dalam suatu dokumen.

Fungsi Dokumen Spesifikasi Kebutuhan Feedback menyediakan umpan balik kepada konsumen, Decomposition memecah permasalahan dalam komponen yang lebih mudah dipecahkan, Input merupakan masukan untuk tahap spesifikasi rancangan, Validation and Verification melakukan pengecekan validasi produk. Contract digunakan sebagai dasar persetujuan antara konsumen dan supplier tentang hal-hal apa saja yang dapat ditangani oleh perangkat lunak yang akan dibangun. Budgeting and Scheduling digunakan sebagai dasar untuk perkiraan biaya dan jadwal. Knowledge Transfer memfasilitasi pergantian/peralihan. Dokumen spesifikasi memudahkan peralihan ke pengguna baru atau ke perangkat keras yang baru. Identify and Reduce Error/Mistake/Failure/Bug mengurangi usaha yang harus dikeluarkan dalam pembangunan perangkat lunak. mengharuskan konsumen untuk menyatakan semua kebutuhan dengan spesifik dan teliti sebelum tahapan perancangan mulai dilakukan. menemukan secara dini kesalahan, kesalahpahaman, dan ketidakkonsistenan sehingga lebih mudah untuk diperbaiki.

Fungsi Dokumen Spesifikasi Kebutuhan Feedback menyediakan umpan balik kepada konsumen, Decomposition memecah permasalahn dalam komponen yang lebih mudah dipecahkan, Input merupakan masukan untuk tahap spesifikasi rancangan, Validation melakukan pengecekan validasi produk. Dokumen spesifikasi dapat digunakan sebagai dasar persetujuan antara konsumen dan supplier tentang hal-hal apa saja yang dapat ditangani oleh perangkat lunak yang akan dibangun. Dokumen spesifikasi harus berisi deskripsi lengkap fungsi-fungsi dari perangkat lunak yang kemudian dapat membantu konsumen untuk menentukan apakah perangkat lunak telah sesuai dengan keinginannya. 2. Dokumen spesifikasi dapat mengurangi usaha yang harus dikeluarkan dalam pembangunan perangkat lunak. Pembuatan dokumen spesifikasi mengharuskan konsumen untuk menyatakan semua kebutuhan dengan spesifik dan teliti sebelum tahapan perancangan mulai dilakukan. Hal ini dilakukan untuk mencegah atau mengurangi kemungkinan pengulangan dalam tahapan perancangan, pengkodean, dan uji coba. Selain itu, dapat juga menemukan secara dini kesalahan, kesalahpahaman, dan ketidakkonsistenan sehingga lebih mudah untuk diperbaiki. 3. Dokumen spesifikasi dapat digunakan sebagai dasar untuk perkiraan biaya dan jadwal. 4. Dokumen spesifikasi dapat digunakan sebagai panduan untuk proses validasi dan verifikasi. Organisasi dapat membuat rencana validasi dan verifikasi yang lebih produktif jika mengacu pada dokumen spesifikasi yang baik. 5. Dokumen spesifikasi dapat memfasilitasi pergantian/peralihan. Dokumen spesifikasi memudahkan peralihan ke pengguna baru atau ke perangkat keras yang baru. 6. Dokumen spesifikasi dapat digunakan sebagai dasar untuk pengembangan lebih lanjut.

Langkah-langkah membuat dokumen spesifikasi : Menggunakan template SKPL, berikut hal-hal yang perlu dipertimbangkan: Penjelasan untuk fungsi dari entitas yang dispesifikasikan. Penjelasan masukan dan darimana masukan berasal Penjelasan luaran dan kemana luaran pergi Indikasi entiti luar yang mungkin digunakan Jika pendekatan fungsional digunakan, informasi tentang pre-condition harus didefinisikan dengan benar. Dan post kondisi juga harus dispesifikasikan setelah fungsi dipanggil.. Penjelasan tentang efek samping dari operasi (jika ada). Mengidentifikasi sumber dari kebutuhan perangkat lunak. Memberikan label yang unik untuk setiap kebutuhan. Merekam alur bisnis. Menspesifikasikan kualitas dari tiap atribut.

Metode Spesifikasi Kebutuhan Natural language, Structured natural language, Semi-formal language, Formal language. Pendekatan - Natural Language - Structured natural language Pendekatan ini bergantung pada pendefinisian bentuk atau template standar untuk menyatakan spesifikasi kebutuhan. - Semi-formal language Notasi ini merupakan sebuah bahasa grafikal yang dilengkapi dengan penjelasan teks. Notasi ini digunakan untuk mendefinisikan kebutuhan fungsional sistem. - Formal Method Pendekatan ini berdasarkan pada konsep matematika seperti finite-state machines. Spesifikasi ini bersifat tidak ambigu, namun sebagian besar konsumen tidak dapat mengerti.

Bahasa Alamiah (Natural Language) Bahasa lisan/tulisan Permasalahan Ambiguitas Over-flexibility Lack of modularization

Bahasa Alamiah Terstruktur (Structured Natural Language) Bahasa alamiah dengan struktur tertentu Digunakan dengan tujuan untuk mendeskripsikan masukan, luaran, dan kebutuhan fungsional sistem yang akan dibangun.

Karakter bahasa yang baik untuk spesifikasi (Vie, 2010) Karakteristik Keterangan Complete Spesifikasi kebutuhan harus dengan jelas mendefinisikan semua situasi yang mungkin dihadapi oleh sistem. Consistent Semua fungsi yang didefinisikan dalam spesifikasi kebutuhan harus cocok dan konsisten pada setiap tingkatan. Tidak diijinkan adanya fungsi yang didefinisikan spesifikasinya dengan informasi yang saling bertolak belakang. Accurate Spesifikasi kebutuhan harus dengan tepat didefinisikan untuk dapat menyelesaikan semua masalah yang mungkin dihadapi dalam lingkungan nyata. Termasuk bagaimana membuat sebuah tampilan dan alur interaksi yang tepat antara penguna dan sistem. Modifiable Struktur dan hirarki logic dari spesifikasi kebutuhan harus dapat memfasilitasi kemungkinan adanya modifikasi. Hal ini penting untuk mengantisipasi adanya modifikasi ketika pembuatan spesifikasi kebutuhan berjalan. Ranked Masing-masing kebutuhan dalam dokumen spesifikasi kebutuhan harus diurutkan berdasarkan hal-hal berikut: stabilitas, keamanan, tingkat kesulitan dalam implementasi dan parameter lain. Hal ini dibutuhkan untuk memudahkan urutan pembuatan fungsi pada fase perancangan.

Karakter bahasa yang baik untuk spesifikasi (Vie, 2010) Karakteristik Keterangan Testable Sebuah spesifikasi kebutuhan harus bisa diuji dengan pengukuran kuantitatif untuk memastikan tidak ada ambiguitas di dalamnya. Traceable Masing-masing fungsi dalam spesifikasi kebutuhan harus diberi identitas secara unik sehingga dapat dilacak alurnya. Unambiguous Spesifikasi kebutuhan harus menggunakan kalimat serta istilah yang memiliki arti sama. Tidak diijinkan adanya ambiguitas. Hal ini menjadi masalah utama dalam pembuatan dokumen spesifikasi kebutuhan yang menggunakan natural language. Valid Spesifikasi kebutuhan yang valid adalah sebuah dokumen dimana semua pihak yang berkepentingan dapat memahami, menganalisis, dan menerimanya. Inilah yang menjadi dasar mengapa banyak jenis dokumen spesifikasi kebutuhan perangkat lunak ditulis menggunakan natural language. Verifiable Spesifikasi kebutuhan yang terverifikasi adalah yang memiliki konsistensi pada setiap level abstraksinya.

Bahasa Semi Formal (Semi-Formal Language) Pendekatan yang menggunakan diagram untuk mendeskripsikan spesifikasi kebutuhan Notasi ini merupakan sebuah bahasa grafikal yang dilengkapi dengan penjelasan teks. Contoh: UML, SDL (Specificatio & Description Language), SCR (Software Cost Reduction), Petri-Net Permasalahan Harus memiliki pengetahuan tentang notasi yang digunakan Kurang fleksibel (sulit untuk non-fungsional)

Bahasa Formal (Formal Language) Pendekatan ini berdasarkan pada konsep matematika seperti finite-state machines. Contoh: Z, Larch, First-Order Language, VDM Permasalahan Spesifikasi ini bersifat tidak ambigu, namun sebagian besar konsumen tidak dapat mengerti Tidak fleksibel (tidak ditujukan untuk kebutuhan non-fungsional

4 Alasan Bahasa Formal Tidak Populer Kesuksesan rekayasa perangkat lunak Penggunaan metode yang lain dalam RPL seperti metode terstruktur (structured method), manajemen konfigurasi (configuration management), dan information hiding dalam proses perancangan dan pembuatan PL telah menghasilkan pengembangan kualitas PL yang lebih baik. Perubahan pasar Pada tahun 1980, kualitas PL dianggap sebagai masalah kunci dalam RPL. Isu kritis untuk beberapa kelas PL bukanlah kualitas perangkat lunak ,tetapi time to market. Keterbatasan jangkauan dari metode formal Metode formal tidak sesuai untuk menspesifikasikan antar muka pengguna dan interaksi pengguna. Keterbatasan pengukuran dari metode formal Metode formal tidak bisa mengukur dengan baik. Cocok untuk proyek berkaitan dengan sistem yang relatif kecil dan critical kernel. Untuk sistem skala besar dibutuhkan waktu dan usaha yang meningkat secara tidak proporsional

Spesifikasi dan Perancangan

Perbandingan Penggunaan Bahasa Formal (Hall, 1990). Tanpa FL Dengan FL

Pendekatan Bahasa Formal Sekuensial Konkuren Algebraic Larch (Guttag et.al., 1993) OBJ (Futatsugi et.al., 1985) Lotos (Bolognesi and Brinksma, 1987) Berbasis Model Z (Spivey, 1992) VDM (Jones, 1980) B (Wordsworth, 1996) CSP (Hoare, 1985) Petri Nets (Peterson, 1981) Pendekatan aljabar Sistem dispesifikasikan dalam bentuk operasi-operasi dan hubungan-hubungannya Spesifikasi Berbasis Model Sistem dispesifikasikan dalam bentuk state model yang dibangun menggunakan konstruksi matematika seperti himpunan dan urutan-urutan. Operasi didefinisikan dengan modifikasi terhadap state dari sistem.

Meyer’s Seven Sin (Meyer, 1985). Dosa Deskripsi Noise Keberadaan suatu elemen dalam spesifikasi yang mengandung informasi yang tidak relevan dari permasalahan. Silence Keberadaan suatu fitur dari permasalahan yang tidak dijelaskan oleh elemen apapun dalam dokumen spesifikasi. Overspecification Keberadaan suatu elemen dalam spesifikasi yang tidak berkorespondensi dengan fitur apapun dalam permasalahan tetapi kepada fitur dari solusi yang mungkin. Contradiction Keberadaan dua atau lebih elemen dalam spesifikasi yang mendefinisikan suatu fitur dalam sistem yang bertentangan satu dengan yang lain. Ambiguity Keberadaan suatu elemen dalam spesifikasi yang memungkinkan lebih dari satu interpretasi. Forward Reference Keberadaan suatu elemen dalam spesifikasi yang merujuk kepada fitur dari permasalahan yang didefinisikan kemudian dalam spesifikasi. Wishful thinking Keberadaaan suatu elemen dalam spesifikasi yang mendefinisikan fitur dari permasalahan yang tidak realisits untuk diimplementasikan.

Model Kualitas (Ambiguitas) Kebutuhan (Husain et al, 2007)

Standard Terkait Spesifikasi Kebutuhan IEEE Standard 830 (IEEE, 1998) ISO 9126 (ISO, 2008), dan Software Standards PSS-05-0 (ESA, 1991). Membedakan Spesifikasi Kebutuhan Pengguna (User Requirement Specification, URS) menjelaskan sekumpulan layanan yang dibutuhkan pengguna Spesifiksi Kebutuhan Perangkat Lunak (Software Requirement Specification, SRS) menjelaskan sekumpulan kebutuhan teknis yang diperlukan untuk menyediakan layanan-layanan yang dibutuhkan pengguna tersebut dan digunakan oleh pihak pengembang.

Aspek-Aspek Kualitas Kebutuhan Kemudahan pemeliharaan (maintainability), Kemudahan verifikasi (verifiability), Kelengkapan (completeness), Kebenaran (correctness), Konsistensi (consistency), Kejelasan (clarity), Kemudahan pelacakan (traceability), Kemudahan perubahan (modifiability), Kemudahan membaca (readability), dan Kemudahan penggunaan (ease of use).

Aspek-Aspek Kualitas Kebutuhan Permasalahan: Walaupun sudah banyak standar yang menyediakan definisi formal dari setiap karakteristik, akan tetapi jarang yang memberikan contoh atau panduan yang memadai untuk mengilustrasikan mana praktek penspesifikasian kebutuhan yang baik maupun yang kurang baik. Banyaknya aspek kualitas spesifikasi kebutuhan yang harus diingat oleh pengembang, terlebih lagi kelihatannya masing-masing memiliki tingkat kepentingan dan keperluan yang sepadan, menyebabkan sering kali terjadi ketimpangan. Ada aspek yang mendapat perhatian yang intensif, dan sebaliknya ada aspek yang terlupakan atau kurang mendapat perhatian.

IEEE 830-1998 Standard Hal-hal mendasar yang harus dimuat dalam SKPL: Fungsionalitas. Antar muka eksternal. Unjuk kerja Atribut. Batasan rancangan pada implementasi. SKPL Harus mendefinisikan semua kebutuhan perangkat lunak dengan benar. Tidak perlu mendeskripsikan rincian rancangan atau implementasi karena hal ini akan dideskripsikan pada tahapan perancangan. Tidak perlu menuliskan batasan tambahan perangkat lunak karena akan dispesifikasikan pada dokumen lain, misalnya rencana jaminan kualitas perangkat lunak.

IEEE 830-1998 Standard Karakteristik SKPL yang baik: Correct Unambiguous Complete Consistent Ranked for importance and/or stability Verifiable Modifiable Traceable

Rational Unified Process (RUP)

Rational Unified Process (RUP)

Kakas Bantu: QuaRS (Giuseppe 2005).

Kakas Bantu: ReqSAC (Husain et al, 2007)