Minggu 05 Spesifikasi Kebutuhan Perangkat Lunak (SKPL) or Software Requirement Specification (SRS)

Transkripsi

1 Minggu 05 Spesifikasi Kebutuhan Perangkat Lunak (SKPL) or Software Requirement Specification (SRS)

2 SKPL/SRS adalah dokumen resmi yang dikeluarkan oleh IEEE (IEEE Std ) mencakup seluruh kebutuhan dan spesifikasi rinci dari pembuatan sistem. Template yang akan digunakan adalah template dengan baseline GL01 SKPL/SRS sebagai alat untuk : Komunikasi antar customer, user, analis dan desainer. Mendukung aktifitas system testing Mengontrol evolusi dari sistem

3 Pelanggan Sistem / Customer Menspesifikasi kebutuhan dan membacanya untuk memeriksa apakah sudah memenuhi persyaratan. Mereka menspesifikasi perubahan atas kebutuhan tersebut. Manajer / PM Menggunakan dokumen kebutuhan untuk merencanakan penawaran atas sistem dan merencanakan proses pengembangan sistem. Perekayasa Sistem Menggunakan dokumen kebutuhan untuk memahami sistem apa yang dikembangkan. Perekayasa pengujian sistem Perekayasa pemeliharaan sistem Menggunakan dokumen kebutuhan untuk mengembangkan pengujian validasi bagi sistem. Menggunakan dokumen kebutuhan untuk membantu memahami sistem dan hubungan antara bagian-bagiannya.

4 Harus menspesifikasi perilaku sistem eksternal Harus menspesifikasi batasan-batasan implementasi Harus mudah direvisi Harus berfungsi sebagai alat bantu referensi bagi pemelihara sistem Harus mencatat perkiraan mengenai siklus hidup sistem Harus mencirikan tanggapan yang dapat diterima terhadap event-event yang tidak diinginkan

5 Correct Unambiguous Complete Verifiable Consistent Understandable by customer Modifiable Traced Traceable Design independent Annotated Concise Organized

6 Sebuah SRS adalah correct jika dan hanya jika setiap requirement yang terdapat di dalamnya merepresentasikan requirement yang dibutuhkan sistem untuk dibangun. Tidak ada cara untuk mengajarkan kualitas ini, karena kualitas ini tergantung total pada aplikasi. Jika software harus merespon pijitan tombol dalam 5 detik dan SRS menyatakan bahwa The software shall respond to all button presses within 10 seconds maka requirements incorrect. Diagram Venn User s Needs A B C SRS Requirements

7 Dokumen SRS unambiguous jika dan hanya jika semua requirement yang tertulis di dalamnya hanya mempunyai satu interpretasi. Contoh 1. Masalah Air Traffic Controller For up to 12 aircraft, the small display format shall be used. Otherwise, the large display format shall be used. Contoh 2. Masalah Nonfriendly Aircraft Aircraft that are nonfriendly and have an unknown mission or the potential to enter restricted airspace within 5 minutes shall raise an alert.

8 Dokumen SRS complete jika SRS mempunyai 4 kualitas: 1. Semua kemampuan software yang diharapkan termuat dalam SRS. User s Needs A B C SRS Requirements a. Completeness menyatakan bahwa daerah A mempunyai luas kosong/nol. Perhatikan bahwa jika SRS complete dan correct maka daerah A dan C adalah hampa dan dua lingkaran berhimpit. b. Completeness adalah karakteristik yang paling susah untuk didefinisikan atau dideteksi kesalahannya. Sebuah kesalahan sulit untuk dideteksi karena artinya ada sesuatu yang tidak tertulis dalam SRS; sulit untuk mencari sesuatu yang tidak kelihatan dengan mengamati yang kelihatan. c. Contoh: If party A calls party B and party B is idle, then party B s phone shall ring If party A calls party B and party B is idle, then party B s shall ring and no other phone shall ring

9 2. Definisi respon software terhadap semua input data termuat di dalam SRS. Buat spesifikasi respon untuk input valid dan invalid. Artinya, setiap input untuk sistem yang dijelaskan dalam SRS. SRS menspesifikasikan output yang sesuai dengannya. 3. Namun, output yang sesuai mungkin juga fungsi dari current state dari sistem. Contoh, dalam sistem telephone switching. 3. Semua halaman diberi nomor; semua gambar dan tabel diberi nomor, diberi nama, dan diacu; semua istilah dan unit pengukuran disediakan; dan semua material dan sections yang diacu tersedia. Ini completeness dari perspektif word processing. 4. Tidak ada section yang ditandai To Be Determined (TBD)

10 Dokumen SRS verifiable, jika dan hanya jika, setiap requirement yang disebutkan di dalamnya verifiable. Sebuah requirement verifiable, jika dan hanya jika, ada proses dengan biaya terbatas sehingga seseorang atau mesin dapat mengecek apakah software yang sedang dibuat memenuhi requirement atau tidak. Ada beberapa alasan mengapa requirement mungkin tidak verifiable. Pertama, ambiguity akan menyebabkan tidak verifiable. Contoh: The product shall have an easy-to-use human interface Kedua, penggunaan kata-kata yang tidak dapat diukur seperti usually atau often

11 Dokumen SRS konsisten jika dan hanya jika 1) Tidak ada requirement yang tertulis di dalamnya konflik dengan dokumen sebelumnya seperti system requirements specification or a statement of work 2) Tidak ada himpunan bagian dari requirement tertulis yang konflik

12 Ada empat tipe dari incompleteness: 1. Conflicting behavior: Dua bagian dari SRS menspesifikasi perbedaan stimulus untuk menghasilkan responsi tertentu atau menspesifikasi perbedaan respon untuk stimulus dan kondisi yang sama. Contoh 1 - The light shall be lit when and only when the button is pressed. - When the button is released, the light shall become lit TIDAK KONSISTEN! Contoh 2 - When the phone is lifted, a dial tone shall be generated. - When the phone is lifted, a ringing tone shall be generated. TIDAK KONSISTEN!

13 2. Conflicting terms: dua istilah digunakan dalam konteks yang berbeda dan mempunyai arti yang sama. Contohnya, istilah prompt untuk menggambarkan pesan yang ditampilkan oleh S/W untuk meminta pengguna memasukkan informasi. Ada juga cue. 3. Conflicting characteristics: Contoh: di satu tempat, SRS menyatakan bahwa all inputs to the software shall be via selection of an option in a displayed menu, dan di tempat lain, the user command language shall consist of the following typed commands 4. Temporal inconsistency: Dua bagian dari SRS bertentangan dalam karakteristik waktu. Contoh, SRS menyatakan system input A will occur only while system input B is occuring, dan di tempat lain dalam SRS menyatakan system input B may start 15 seconds after an occurrence of system input A

14 Dalam membuat SRS yang lebih tidak ambigu, lebih verifiable, complete, dan konsisten, kita mungkin menggunakan notasi formal sekali Sayang sekali notasi tersebut membuat bingung non computer specialist untuk memahami SRS Pembaca utama dari SRS adalah customer atau pengguna, yang cenderung jago dalam bidang aplikasi tetapi tidak sepenuhnya bisa dalam computer science.

15 SRS modifiable jika struktur dan gaya SRS sedemikian sehingga perubahan pada requirement dapat dibuat easily, completely, dan consistently. Modifiability artinya ada daftar isi, indeks, dan referensi jika memungkinkan. Contoh: Jika kita ingin merubah maksimum respond time of a dial tone in a telephone switching system from 5 detik ke 3 detik, kita akan mencari di indeks dengan kata dial tone

16 Salah satu teknik yang dapat digunakan untuk meningkatkan kemudahan membaca SRS adalah dengan mengulangi selected requirements in different locations in the document. Karakteristik ini disebut redundancy. Contoh: Ketika mendeskripsikan eksternal view dari local call, SRS menyatakan: Starting with an idle telephone, the user should lift the handset, the system shall respond with a dial tone, then the user should dial the seven digit phone number of the party the user is trying to reach Ketika mendeskripsikan eksternal view dari long distance call, SRS menyatakan: Starting with an idle telephone, the user should lift the handset, the system shall respond with a dial tone, then the user should dial a 1 followed by the ten digit phone number of the party the user is trying to reach

17 Sebuah dokumen SRS traced jika asal (origin) dari setiap requirements jelas (clear). Artinya, SRS mencakup acuan ke dokumen-dokumen pendukung awal, seperti dalam gambar di bawah. System level Requirements, white paper, etc S R S traceable Design Documents traced traceable

18 Contoh: SRS mencakup requirement The system shall respond to any occurrence of request X within 20 seconds. Sekarang software sudah dibangun dan ketika software diuji dalam final test, response time diukur secara konsisten pada 60 detik. Ada 2 cara untuk memperbaiki masalah ini 1) Desain ulang atau kode ulang software supaya lebih efisien 2) Ubah requirement dari 20 menjadi 60 detik

19 Dalam mendesain atau menguji komponen dari perangkat lunak, perlu diketahui bagi kita requirements mana saja yang sudah ada komponennya. Dalam pengujian sistem software, perlu diketahui bagi kita requirements mana saja yang sudah divalidasi oleh setiap tes Dokumen SRS traceable jika setiap requirement di dalam SRS dapat diacu Ada variasi teknik untuk melakukan ini: Beri nomor setiap paragraf secara hierarki Beri nomor setiap paragraf secara hierarki dan jangan memuat lebih dari satu requirement di dalam paragraf Beri nomor setiap requirement dgn nomor unik dalam kurung Gunakan aturan yang disepakati mengenai requirement, contohnya kata shall

20 Dokumen SRS design independent jika SRS tidak memakai arsitektur atau algoritma spesifik. Contohnya, SRS sebaiknya jangan menyebut The system shall be composed of the components X, Y, and Z.

21 Pemberian penjelasan requirement dalam SRS memberikan panduan untuk organisasi pengembangan software. Salah satu cara melakukan ini adalah dengan menambahkan ke setiap requirement dalam SRS, huruf E, D atau O dalam kurung untuk essential, desirable, atau optional

22 Diberikan dua SRS untuk sistem yang sama, masing-masing menunjukkan level yang sama dari kualitas-kualitas yang dijelaskan sebelumnya. SRS yang lebih singkat lebih baik

23 Sebuah SRS organized jika requirements yang termuat di dalamnya mudah untuk ditemukan (easy to locate)

24 THERE IS NO SUCH THING AS A PERFECT SRS!