Minggu 05
Spesifikasi Kebutuhan Perangkat Lunak (SKPL) or
SKPL/SRS adalah dokumen resmi yang dikeluarkan
oleh IEEE (IEEE Std 1223-1998) 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
• Menspesifikasi kebutuhan dan membacanya untuk memeriksa apakah sudah memenuhi persyaratan. Mereka menspesifikasi perubahan atas kebutuhan tersebut.
Pelanggan Sistem / Customer
• Menggunakan dokumen kebutuhan untuk merencanakan penawaran atas sistem dan merencanakan proses pengembangan sistem.
Manajer / PM
• Menggunakan dokumen kebutuhan untuk memahami sistem apa yang dikembangkan.
Perekayasa Sistem
• Menggunakan dokumen kebutuhan untuk mengembangkan pengujian validasi bagi sistem.
Perekayasa pengujian sistem
• Menggunakan dokumen kebutuhan untuk membantu memahami sistem dan hubungan antara bagian-bagiannya.
Perekayasa
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
Correct
Unambiguous
Complete
Verifiable
Consistent
Understandable by
customer
Modifiable
Traced
Traceable
Design independent
Annotated
Concise
Organized
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
A B C SRS Requirements User’s
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.”
Dokumen SRS complete jika SRS mempunyai 4 kualitas:
1.Semua kemampuan software yang diharapkan termuat dalam SRS.
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”
A B C SRS
Requirements User’s
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.
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
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
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.
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
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.
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”
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 …”
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
Design Documents
traced traceable
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
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
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.”
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
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
