APA ITU VERIFIKASI KEBUTUHAN ??

Verifikasi kebutuhan perangkat lunak adalah tahapan dari

rekayasa perangkat lunak untuk memastikan produk yang
dihasilkan dari aktivitas pengembangan sesuai dengan spesifikasi
yang ditentukan atau dalam istilahnya “doing the thing right”.
 MENURUT ABRAM AND MOORE, 2001
AKTIVITAS VERIFIKASI DAN VALIDASI MEMILIKI TUJUAN UNTUK
MEMASTIKAN:
1. Dokumen SKPL menjelaskan dengan benar keinginan terhadap kapabiiitas dan karakteristik
yang memuaskan bagi pemangku kepenringan.
2. SKPL diuraikan dengan benar sesuai dengan kebutuhan sistem, aturan bisnis, dan sumber-
sumber lain yang berkaitan.
3. Spesifikasi kebutuhan menyeluruh dan berkualitas tinggi.
4. Representasi kebutuhan sudah konsisten dan tidak adanya konflik antarspefikasi satu
dengan yang lainnya.
5. SKPL menyediakan informasi yang cukup, berkualitas dan dapat dipercaya.
 STANDAR IEEE 830-1998 (IEEE, 1998)
VERIFIKASI DAN VALIDASI DARI SPESIFIKASI KEBUTUHAN
DIHARUSKAN MEMILIKI KRITERIA ANTARA LAIN:

1. Tepat, spesifikasi kebutuhan dinyatakan benar apabila setiap pernyataan kebutuhan

dengan sistem bisa saling bertemu dan dapat direalisasikan.
2. Tidak rancu, spesifikasi kebutuhan tidak rancu jika dan hanya jika setiap pernyataan
kebutuhan hanya memiliki satu interpretasi.
3. Lengkap, semua spesifikasi kebutuhan sudah mencakup keseluruhan sistem yang
dibutuhkan oleh pemangku kepentingan.
4. Konsisten, tidak terdapat bagian ataupun sub bagian yang konflik antara satu dengan
lainnya.
 STANDAR IEEE 830-1998 (IEEE, 1998)
VERIFIKASI DAN VALIDASI DARI SPESIFIKASI KEBUTUHAN
DIHARUSKAN MEMILIKI KRITERIA ANTARA LAIN:

5. Diranking berdasarkan kepentingannya, Spesifikasi kebutuhan di Susun sesuai

dengan prioritas pentingnya tiap bagian di dalam sistem.
6. Dapat diverifikasi, hasil akhir dari pruduk dapat diukur sesuai dengan spesifikasi
kebutuhan.
7. Dapat dimodifikasi, spesifikasi kebutuhan dimungkinkan untuk dilakukan
perubahan.
8. Dapat dilacak, Spesifikasi dapat ditelusuri tiap bagiannya tahap demi tahap.
UNTUK MEMPERMUDAH MELAKUKAN PROSES VERIFIKASI DAN VALIDASI
TERSEBUT, ANDA DAPAT MENGGUNAKAN DAFTAR PERTANYAAN UNTUK
PENGECEKAN TERSTRUKTUR SEBAGAIMANA DITUNJUKKAN PADA TABEL 8.1.

ITEM VERIFIKASI

KETEPATAN - Apakah semua kasus penggunaan dapat direalisasikan melalui

sequence diagram?
- Apakah semua kebutuhan didalam SRS juga terdapat dalam
model analisis?
KERANCUAN - Apakah terdapat penggunaan susunan kata seperti
“mungkin”, memungkinkan”, “seharusnya”, “dapat”, “lebih
baik”, “beberapa”, “seringkali” atau kata lain yang tidak
mempunyai ukuran pasti.
- Apakah sudah menggunakan struktur standar Bahasa yang
baku.
KELENGKAPAN - Apakah semua referensi didefinisikan sepenuhnya?
- Apakah semua pengertian yang tidak umum
didefinisikan?
- Apakah semua kondisi dan hubungan keterikatan
spesifikasi kebutuhan fungsional terdapat di dalam
SRS?
KONSISTENSI - Apakah setiap atriut didefinisikan sekali saja?
- Apakah setiap metode didefinisikan sekali saja?
DAPAT - Apakah semua kuantitas spesifikasi dalam pengertian yang
DIVERIFIKASI
terukur?
DAPAT - Sudahkan semua struktur yang berulang dihilangkan?
DIMODIFIKASI
- Apakah struktur SRS sesuai dengan struktur model analisis?

DAPAT DILACAK - Apakah setiap kebutuhan dapat ditelusuri pada kasus

penggunaannya untuk direalisasikan?
 AKTIVITAS VERIFIKASI DAN VALIDASI
PERLU MANAJEMEN KERJA YANG MELIPUTI:

1. Perencanaan dan pemeliharaan kebutuhan.

2. Koordinasi dan interpretasi kemampuan dan kualitas usaha.
3. Memberikan catatan ketidak-sesuaian dengan segera kepada pengguna ataupun kelompok
pengembang.
4. Mengidentifikasi kemungkinan masalah dari awal.
5. Menyediakan evaluasi teknis dari kemampuan perangkat lunak dan kualitas pendukungnya.
 AKTIVITAS VERIFIKASI DAN VALIDASI
PERLU MANAJEMEN KERJA YANG MELIPUTI:
6. Menilai dampak keseluruhan yang diakibatkan apabila terdapat perubahan spesifikasi
kebutuhan.
7. Menentukan sasaran kualitas dan kemampuan produk.
8. Memberikan beragam antisipasi terhadap masalah dan bagaimana pemecahannya.
9. Dapat menggunakan pilihan perangkat lunak yang mampu untuk menganalisis dan
menguji secara efektif masalah-masalah pada sistem dan perangkat lunak.
10. Memilih tahapan dan teknik yang diaplikasikan untuk mengukur dan memprediksi kualitas
perangkat lunak.
FOKUS KEGIATAN DALAM TAHAPAN VERIFIKASI MELIPUTI:

Fokus kegiatan dalam tahapan verifikasi meliputi:

1. Mengawali dengan evaluasi terhadap dokumentasi konsep.
2. Memulai perancanaan pengujian.
3. Mengawali analisis penelusuran perangkat lunak.
4. Mengawali evaluasi kebutuhan.
5. Mengawali analisis antarmuka atau tampilan.
6. Evaluasi penggunaan ulang perangkat lunak.
 CAKUPAN YANG BERKAITAN DENGAN SKPL DI ANTARANYA ADALAH:

1. SKPL seharusnya dengan benar mendefinisikan semua kebutuhan perangkat lunak

dan tidak dimungkinkan adanya multi-interpretasi.
2. SKPL seharusnya tidak mendeskripsikan detail beberapa rancangan dan
implementasinya.
3. SKPL seharusnya tidak menambahkan hubungan-hubungan sistem dengan sistem di
luarnya.
SEBAGAI CONTOH UNTUK PENDEKATAN INSPEKSI TERHADAP
MODEL DATA DITUNJUKKAN PADA GAMBAR 8.1. GAMBAR
TERSEBUT MENUNJUKKAN DUA MODEL RELASI ENTITAS DATA
RELASIONAL.
 13 LANGKAH-LANGKAH TEKNIS YANG DAPAT DITEMPUH
UNTUK MELAKUKAN VERIFIKASI PERANGKAT LUNAK
SEBAGAI BERIKUT:

1. Analisis algoritma 6. Decision truth 11.Mutation analisys

table 12.Interface analisis
2. Back to back
testing 7. Consistency 13.Interface testing
analysis
3. Boundary value
8. Control flow
analysis
analysis
4. Database analysis 9. Coverage analysis
5. Data use analysis 10.Error seeding
 APA ITU VALIDASI ?
Validasi dibutuhkan untuk memberikan kepastian bahwa
rancangan dan dokumen dari sistem yang akan
diimplementasikan telah sesuai dengan keinginan dan kebutuhan
pemangku kepentingan baik pemesan, pengguna, maupun pihak
pengembang.
 VALIDASI UNTUK MEMBERIKAN KEPUASAN KEPADA
PEMANGKU KEPENTINGAN, YAITU:

1.Tepat 5.Dirangking berdasarkan

2.Lengkap tingkat kepentingan dan
stabilitas
3.Tidak rancu
6.Dapat dimodiiikasi
4.Konsisten
7.Dapat diverifikasi
8.Dapat dilacak
 APA ITU PENGECEKAN SPESIFIKASI
?
Analis kebutuhan dapat dicek dalam beberapa hal tanpa melakukan
konsultasi. Jika ditemukan adanya permasalahan ataupun kesalahan,
terdapat beberapa langkah yang memungkinkan di antaranya dengan cara
mengecek:
1. Permasalahan 4. Beberapa informasi salah namun sudah
2. Kesalahan pada beberapa informasi terwakili oleh informasi yang lainnya
penting 5. Dua bagian atau spesifikasi terjadi konflik
3. Beberapa informasi salah namun kurang
signifikan di dalam pekerjaan
 APA ITU PENGECEKAN KONTEN ?

Pengecekan spesifikasi kebutuhan adalah

pengecekan konten. Pengecekan konten pada
dasarnya memperhatikan apakah informasi dasar
yang diperlukan dalam sebuah dokumen
spesifikasi kebutuhan hadir
 DAFTAR KONTEN YANG DAPAT DICEK KETIKA
MEMVERIFIKASI KONTEN DARI SUATU DOKUMEN
SPESIFIKASI KEBUTUHAN:
Apakah dokumen mengandung konten atau informasi tentang:
- Pelanggan, sponsor dan latar belakang,
-Tujuan bisnis dan bukti pelacakanny,a
- Data kebutuhan (basis data, format masukan/keluaran, status komuni-kasi, dan
inisialisasi,
- Batasan dan antarmuka sistem,
- Kebutuhan level-ranah (kejadian-kejadian dan tugas-tugas),
- Kebutuhan level-produk (kejadian-kejadian dan fitur-fitur),
 (LANJUTAN):
- Kebutuhan level-rancangan (prototipe dan protokol komunikasi)
- Spesifikasi dari fungsi yang tidak sepele,
- Kasus-kasus ekstrem, kejadian khusus, dan kegagalan tugas,
- Kebutuhan kualitas (unjuk kerja, usability, keamanan, dll),
- Item yang dianggap sebagai produk dari proyek pengembangan perangkat lunak
(deliverable) yang akan diserahkan pengembang kepada pelanggan lain
(dokumentasi, pelatihan, dll),
- Glosarium (deiinisi dari terminologi, dan lain-lain).
 BERIKUT ADALAH STRUKTUR DARI KONTEN YANG
DIHARAPKAN ADA DALAM SUATU DOKUMEN SPESIFIKASI
KEBUTUHAN:
1. Pendahuluan 5. Perlakuan pada kasus yang
2. Tujuan sistem khusus
3. Kebutuhan data 6. Kebutuhan kualitas
4. Kebutuhan fungsional 7. Penyerahan lainnya
8. Daftar
 PENILAIAN RISIKO

Hal lain yang juga diperlukan dalam validasi adalah pengecekan

terhadap risiko. Risiko yang tinggi terhadap pelanggan menjadi
risiko yang rendah bagi pengembang dan begitu sebaliknya.
 LANGKAH YANG PERLU DITEMPUH UNTUK
MENGENALI RISIKO DAPAT DILAKUKAN DENGAN:
 Staf pelanggan perlu meninjau ulang spesifikasi.
spesifikasi dan merangking tiap  Developer dapat melakukan hal sama
kebutuhan sesuai risikonya masing- untuk merangking tingkat risiko yang
masing. Risiko yang seringkali ada adalah akan dihadapi. Risiko yang biasa terjadi
pelanggan tidak mendapatkan apa yang mereka tidak bisa memastikan kesesuaian
diinginkan sampai dia mendapatkan apa spesifikasi dengan pembiayaan proyek.
yang dispesifikasikan.
 Justifikasi dibuat untuk melihat sampai
 Dengan menggunakan cek konten, sejauh mana risiko yang mungkin
pelanggan dapat mengidentifikasi bagian- dihadapi.
bagian yang belum terdapat dalam
 TERDAPAT CARA SINGKAT UNTUK
MENANGGULANGI RISIKOYANG TIDAK DAPAT
DITOLERANSI , DI ANTARANYA:
Pilih model kebutuhan yang lain dengan risiko yang lebih rendah
Melakukan elisitasi lagi kebutuhan yang lebih tepat,
Mengisolasi risiko untuk mengurangi kegagalan jika kecelakaan terjadi.
Menjaga risiko di bawah pengawasan sehingga pengembang mampu
bertindak cepat jika kecelakaan ataupun kegagalan terjadi.
 APA ITU PENGUJIAN ?
Pengujian adalah cara terbaik untuk melakukan validasi
kebutuhan.
Sesuai dengan apa yang didapatkan pelanggan, apa yang
diharapkan, dan dapat direalisasikan. Pengujian dapat
menggunakan teknik-teknik elisitasi. Metode pengujian yang
dapat diterapkan adalah:
 Simulasi  Pilot
 Prototipe
 PERKAKAS BANTU
PERKAKAS BANTU SCR

Perkakas bantu SCR (Software Cost Reduction) (Heitmeyer

et.al., 1997) dirancang untuk melakukan proses spesifikasi,
verifikasi, dan validasi terhadap kebutuhan dengan
menggunakan metode formal. Perkakas bantu ini
memainkan peran penting dalam memastikan bahwa
sistem telah memenuhi properti kritis yang telah
ditetapkan
 FUNGSI DARI PERKAKAS BANTU SCR

1. Mendemonstrasikan well-formedness
2. Menemukan pelanggaran property
3. Memverifikasi properti yang kritis
4. Memvalidasi spesifikasi
5. Mengonstruksi kasus pengujian
6. Mendeteksi kesalahan dan kerentanan dalam program
 UNTUK MENDUKUNG HAL-HAL TERSEBUT, PERKAKAS
BANTU SCR DIPERLENGKAPI DENGAN FITUR-FITUR
SEBAGAI BERIKUT:
 Specificarion Editor:  Consistency Checker :
editor untuk membuat atau melakukan mengecek format dari
modifikasi spesifikasi kebutuhan. spesifikasi(misalnya : kesesuaian sintaks,
 Simulator : definisi pada spesifikasi kebutuhan).

untuk melakukan simulasi pada  Verifier :

spesifikasi. untuk menganalisis Spesifikasi
kebutuhan.
 PERKAKAS BANTU QUARS
Formal Method and Tool (FMT) Group memperkenalkan perkakas yang bernama Quality
Analyzer of Requirements Specifications (QuARS),(Lami, 2005), (Bucchiarone et al, 2008).
QuARS didasarkan pada model kualitas yang mengukur kemampuan untuk dapat diuji
(testability), kelengkapan (completeuess), kemampuan untuk dapat dimengerti (
understandability), dan konsistensi (consistency) dari spesifikasi kebutuhan perangkat lunak
yang ditulis dalam bahasa alamiah.
ARSITEKTUR SISTEM QUARS DAPAT DILIHAT PADA GAMBAR
8.2.
KOMPONENNYA ADALAH SEBAGAI BERIKUT:
1. Syntactical Parser sebelumnya (memanfaatkan hasil dari Syntax dan
Menggunakan aplikasi Minipar. Lexical Parser) dan menuliskannya ke dalam file log.
2. Lexical Parser 4. Dictionaries
Lexical Parser mengidentifikasi kata dan frasa tertentu Dictionaries adalah komponen pasif dari kakas ini.
yang muncul dalam setiap kalimat. Berisi terminologiterminologi yang dibutuhkan oleh
3. Indicators Detector komponen lainnya.
Indicators Detector merupakan komponen asli yang
mendeteksi indikator-indikator yang telah ditetapkan
 PERKAKAS BANTU REQSAC
ReqSAC (Requirements Specification Ambiguity Checker) (Hussain et.al., 2007)
merupakan perkakas bantu yang dirancang untuk penilaian secara otomatis pada
dokumen SKPL, untuk mendeteksi ada tidaknya kata-kata yang rancu pada dokumen
SKPL.
 PERKAKAS BANTU SMART DETECTOR

Muliawan dan Siahaan (2011) memperkenalkan suatu perkakas bantu pendeteksi

kerancuan. Perkakas bantu ini menganalisis spesifikasi kebutuhan perangkat lunak
berdasarkan aturan SMART (Specific, Measureable, Attainable, Relizable, and Trackable)
Requirements. Sistem ini memanfaatkan pemrosesan bahasa alamiah (Natural Language
Processing -NLP). Selain itu, Sistem ini dibantu oleh kamus Wordnet sebagai repositori
dari kata-kata yang tidak diinginkan.
 Arsitektur sistem analisis kerancuan dengan aturan SMART

PERNYATAAN WORDNET
KEBUTUHAN

PREPROCESSING HASIL :
123
MENGGUNAKAN
STANFORD POS
MODUL SMART AMBIGU ATAU
456 TIDAK AMBIGU
TAGGER

REPOSITORI
ATURAN
SMART