A.

Identitas Modul

IDENTITAS MODUL
Perguruan Tinggi : Politeknik Negeri Bengkalis Pertemuan ke : 7 dan 9
Jurusan/Program Studi : Teknik Informatika/ Rekayasa Modul ke :4
Perangkat Lunak
Kode Mata Kuliah : RPL16303 Jumlah Halaman :9
Nama Mata Kuliah : Rekayasa Kebutuhan Perangkat Mulai Berlaku : 2018
Lunak

B. Komponen Modul
1. Judul Modul

MODUL IV
TUJUAN DAN TAHAPAN DALAM ANALISIS KEBUTUHAN

2. Kompetensi Dasar
Agar mahasiswa mengetahui dan memahami penerapan analisis dan
spesifikasi kebutuhan

3. Pokok Bahasan dan Sub Pokok Bahasan

a. Penjelasan tujuan dan tahapan analisis kebutuhan
b. Prinsip-prinsip analisis kebutuhan
c. Gambaran luas tentang spesifikasi kebutuhan

4. Indikator Pencapaian
a. Mahasiswa mengerti tujuan analisiss perancangan perangkat lunak
b. Mahasiswa memahami tentang spesifikasi kebutuhan perangkat lunak

5. Referensi
1. Daniel Siahaan.2012. Analisa Kebutuhan Dalam Rekayasa Perangkat
Lunak, Andi, Yogyakarta
2. Sommerville, I, 2007. Software Engineering. 8th Edition: Addison-Wesley
 3. Roger S. Pressman, Ph.D. 2012. Rekayasa Perangkat Lunak Edisi 7 Buku
1, Andi, Yogyakarta
C. Materi Modul

ANALISIS KEBUTUHAN

4.1 Penjelasan tujuan dan tahapan analisis kebutuhan

4.1.1 Definisi
Analisis kebutuhan (requirements analysis) merupakan langkah awal untuk
menentukan gambaran perangkat yang akan dihasilkan ketika pengembang
melaksanakan sebuah proyek pembuatan perangkat lunak. Perangkat lunak yang
baik dan sesuai dengan kebutuhan pengguna sangat tergantung pada keberhasilan
dalam melakukan analisis kebutuhan. Untuk proyek-proyek perangkat lunak yang
besar, analisis kebutuhan dilaksanakan setelah aktivitas sistem information
engineering dan perencanaan proyek perangkat lunak
Analisis kebutuhan perangkat lunak dapat diartikan sebagai:
a. Proses mempelajari kebutuhan pemakai untuk mendapatkan definisi
kebutuhan sistem atau perangkat lunak [IEE93].
b. Proses untuk menetapkan fungsi dan unjuk kerja perangkat lunak,
menyatakan antarmuka perangkat lunak dengan elemen-elemen sistem lain,
dan menentukan kendala yang harus dihadapi oleh perangkat lunak [PRE01].
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang
baik, tetapi analisa kebutuhan yang tidak tepat menghasilkan perangkat lunak
yang tidak berguna. Mengetahui adanya kesalahan pada analisis kebutuhan pada
tahap awal memang jauh lebih baik dibandingkan jika mengetahui kesalahan
analisis kebutuhan ketika sudah memasuki penulisan kode atau pengujian, bahkan
hampir masuk dalam tahap penyelesaian merupakan kesalahan yang sangat fatal
karena biaya dan waktu yang diperlukan akan menjadi sia-sia.
Analisa kebutuhan adalah suatu proses untuk mendapatkan informasi, mode,
dan spesifikasi tentang perangkat lunak yang diinginkan klien/pengguna. Antara
klien dan pembuat perangkat lunak harus terlibat aktif dalam tahap ini. Informasi
dari klien akan menjadi acuan untuk melakukan desain perangkat lunak.
Analisis kebutuhan merupakan satu dari banyak aktivitas kritis pada proses
rekayasa kebutuhan perangkat lunak untuk memahami permasalahan dari sistem
yang berjalan dan solusi dari sistem yang akan dibuat (Yen et.al, 1998).
Ada tiga faktor yang harus dipenuhi untuk ketika melakukan analisis
kebutuhan yaitu :
a. Lengkap, yang artinya semua kebutuhan yang diharapkan oleh klien telah
didapatkan saat melakukan analisis
b. Detail, artinya berhasil mengumpulkan informasi secara rinci.
c. Benar, maksudnya adalah semua data yang didapatkan pada saat melakukan
anlisis harus benar, sesuai dengan apa yang dimaksudkan oleh klien, bukan
benar menurut apa yang dipikirkan oleh pihak analisis

4.1.2 Tujuan analisis kebutuhan

Tujuan dari analisis kebutuhan secara umum adalah memahami masalah yang
akan dibuat perangkat lunaknya secara menyeluruh (komprehensif),
mendefinisikan apa yang harus dikerjakan oleh perangkat lunak untuk memenuhi
keinginan pemakai.
Adapun tiga tujuan utama dari aktivitas analisis kebutuhan yang dapat di
formulasikan sebagai berikut:
a. Mengolah hasil elisitasi kebutuhan untuk menghasilkan dokumen spesifikasi
kebutuhan yang isi keseluruhannya seseuai dengan apa yang diinginkan
pengguna ( Liu and Yen, 1996).
b. Mengembangkan persyaratan kualitas yang memadai dan rinci, dimana para
manajer dapat membuat perkiraan proyek yang realistis dan staf teknis dapat
melanjutkan dengan perancangan, implementasi dan pengujian ( Wiegers,
2003).
c. Membangun pemahaman tentang karakteristik adalah ranah permasalahan
dan sekumpulan kebutuhan untuk menemukan solusi.
Ketiga tujuan dari proses analisis kebutuhan ini dapat dicapai oleh perekayasa
kebutuhan dengan melalui serangkaian tahapan-tahapan aktivitas.
4.1.3 Tahapan analisis kebutuhan
Analisis kebutuhan yang dilakukan terhadap perangkat lunak akan
menghasilkan spesifikasi perangkat lunak. Analisa kebutuhan ini terdiri dari lima
tahapan diantaranya:
d. Mempelajari dan memahami persoalan
e. Mengidentifikasi kebutuhan pemakai
f. Mendefinisikan kebutuhan perangkat lunak
g. Membuat dokumen spesifikasi kebutuhan
h. Mengkaji ulang (review) kebutuhan

4.1.4 Mempelajari dan memahami Masalah

Pada tahap ini, sebelum membuat perangkat lunak harus dipelajari terlebih
dahulu permasalahannya sehingga dapat ditentukan:

a) Siapa pemakai yang akan menggunakan perangkat lunak

b) Dimana perangkat lunak akan digunakan
c) Pekerjaan apa dari pemakai yang akan dibantu oleh perangkat lunak
d) Dari dan sampai mana cakupan pekerjaan tersebut, dan bagaimana
mekanisme pelaksanaannya
e) Apa yang menjadi kendala atau keterbatasannya dilihat dari sisi teknologi
yang akan digunakan atau dari sisi hukum dan standar
Cara yang digunakan untuk mengumpulkan informasi yang nantinya
dijadikan permasalahan dalam tahapan analisis kebutuhan diantaranya:

a. Wawancara dengan pemakai

b. Observasi atau pengamatan lapangan

c. Kuesioner
d. Mempelajari referensi atau dokumen-dokumen yang digunakan, seperti
dokumen hasil analisis dan perancangan sistem
Hasil pemahaman permasalahan tersebut selanjutnya digambarkan dalam
bentuk model-model tertentu sesuai dengan jenis masalahnya. Sebagai contoh,
untuk masalah bisnis dapat menggunakan flowmap atau business Use Case,
sementara untuk masalah matematika dapat mengunakan, misalnya graf.

4.1.5 Mengidentifikasi kebutuhan pemakai

Tahap identifikasi kebutuhan pemakai (user requirement) pada dasarnya
dilaksanakan bersamaan dengan pemahaman permasalahan. Cara yang digunakan
pun relatif sama. Pertanyaan yang biasa digunakan adalah:

a. Data atau informasi apa yang akan diproses

b. Fungsi apa yang diinginkan

c. Kelakuan sistem apa yang diharapkan

d. Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software

interfaces, dan communications interfaces)

Untuk dapat menangkap kebutuhan pemakai dengan baik dibutuhkan

kesamaan persepsi antara klien dengan pengembang dengan cara:

a. Komunikasi dan brainstorming yang intensif

b. Prototype perangkat lunak, atau screen snapshot
c. Data atau dokumen yang lengkap

4.1.6 Mendefinisikan Kebutuhan Perangkat Lunak

Saat mengidentifikasi kebutuhan klien, informasi yang diperoleh belum
terstruktur. Klien akan mengungkapkan apa yang dibutuhkannya dengan bahasa
sehari-hari yang biasa digunakan.
Pada tahap ini, kebutuhan klien yang belum terstruktur tersebut dianalisis,
diklasifikasikan, dan diterjemahkan menjadi kebutuhan fungsional, antarmuka,
dan unjuk kerja perangkat lunak.
Selanjutnya, kebutuhan tersebut diubah menjadi model atau gambar tertentu
dengan memanfaatkan teknik analisis dan alat bantu tertentu. Sebagai gambaran,
kebutuhan fungsional dapat dimodelkan dengan menggunakan:

a. Data Flow Diagram, kamus data, dan spesifikasi proses jika menggunakan
teknik terstruktur.
b. Diagram Use Case dan skenario sistem jika menggunakan pendekatan objek.

4.1.7 Membuat Dokumen Spesifikasi Kebutuhan

Semua kebutuhan yang telah didefinisikan selanjutnya dibuatkan

dokumentasinya, yaitu Spesifikasi Kebutuhan Perangkat Lunak (SKPL) atau
Software Requirements Specification (SRS). SKPL yang dibuat harus dapat
menyatakan secara lengkap apa yang dapat dilakukan oleh perangkat lunak,
termasuk deskripsi lengkap dari semua antarmuka yang digunakan. SKPL bisa
terdiri dari banyak dokumentasi yang saling melengkapi.

4.1.8 Mengkaji ulang (review) Kebutuhan

Proses untuk memeriksa (validasi) SKPL apakah sudah konsisten, lengkap,

dan sesuai dengan apa yang diinginkan pemakai dilakukan lebih dari satu kali.
Dan sering kali muncul kebutuhan-kebutuhan baru dari pemakai. Untuk itu,
diperlukan negosiasi antara pihak pengembang dengan pemakai sesuai prinsip
“win-win solution” sampai kebutuhan tersebut dapat disepakati kedua belah pihak.

4.2 Prinsip-Prinsip Analisis

Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi,
semua metode analisis dihubungkan oleh serangkaian prinsip operasional
(Pressman, 2008) berikut:
1. Unsur informasi dari suatu masalah harus di presentasikan dan di pahami.
2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus di definisikan.
3. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus
terwakilkan.
4. Model-model yang menggambarkan informasi, fungsi, dan tingkah laku
sistem harus di pecah-pecah ke dalam tingkat yang lebih rinci dalam bentuk
lapisan (hierarki).
5. Proses analisis di mulai dari informasi dasar menuju implementasi rinci.
Sebagai tambahan untuk prinsip analisis operasional menurut davis (1993)
mengusulkan serangkaian prinsip panduan untuk rekayasa kebutuhan:
1. Memahami masalah sebelum anda mulai menciptakan model analisis.
2. Mengembangkan prototype yang memungkinkan seorang pemakai
memahami bagaimana interaksi manusia dengan mesin terjadi.
3. Mencatat asal dan alasan untuk setiap kebutuhan.
4. Menggunakan pandangan kebutuhan berjenjang.
5. Memprioritaskan kebutuhan.
6. Berusaha mengurangi kerancuan.

4.3 Gambaran luas tentang spesifikasi kebutuhan

Spesifikasi Kebutuhan Perangkat Lunak (SKPL) adalah dokumen yang berisi
pernyataan lengkap dari apa yang harus dilakukan atau dipenuhi oleh perangkat
lunak, tanpa menjelaskan bagaimana hal tersebut dilaksanakan oleh perangkat
lunak. Selain itu, SKPL juga berisi deskripsi lengkap dari semua antarmuka yang
ada dalam perangkat lunak.
Tujuan dari dibuatnya SKPL [DAV93] :
a. Sarana komunikasi antara pelanggan, pemakai, analis, dan perancang
perangkat lunak.
b. Dasar untuk merencanakan dan melaksanakan pengujian sistem.
c. Acuan untuk melakukan perbaikan atau pengubahan perangkat lunak.

Manfaat atau kegunaan dokumen SKPL menurut Witarto [WIT04] dari IEEE
yaitu:
a) Memastikan kesamaan antara kebutuhan untuk pengembangan dengan
kebutuhan yang ditulis dalam dokumen.
b) Mendefinisikan kerangka kerja bersama untuk proses-proses pengembangan
perangkat lunak.
c) Memperjelas peran dan antarmuka bagi para pihak yang terlibat dalam
proses-proses pengembangan perangkat lunak.
d) Memperjelas jenis dan isi dari dokumen.
e) Mengenali tugas-tugas, tahapan-tahapan, baselines, aktivitas kaji ulang, dan
dokumentasinya.
f) Belajar dari pendekatan praktis yang diterapkan di dunia industri.
g) Menghilangkan jebakan-jebakan dan persoalan-persoalan seperti yang
dialami di masa lalu.

D. Rangkuman
a. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat
tergantung pada keberhasilan dalam melakukan analisis kebutuhan.
Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak
yang baik, tetapi analisa kebutuhan yang tidak tepat menghasilkan
perangkat lunak yang tidak berguna.
b. Tujuan dari analisis kebutuhan secara umum adalah memahami masalah
yang akan dibuat perangkat lunaknya secara menyeluruh.
c. Analisa kebutuhan ini terdiri dari lima tahapan diantaranya mempelajari
dan memahami persoalan, mengidentifikasi kebutuhan pemakai,
mendefinisikan kebutuhan perangkat lunak, membuat dokumen spesifikasi
kebutuhan, mengkaji ulang (review) kebutuhan.
d. Cara yang digunakan untuk mengumpulkan informasi yang nantinya
dijadikan permasalahan dalam tahapan analisis kebutuhan diantaranya
wawancara dengan pemakai,. observasi atau pengamatan lapangan,
kuesioner, mempelajari referensi atau dokumen-dokumen yang digunakan.
e. Spesifikasi Kebutuhan Perangkat Lunak (SKPL) adalah dokumen yang
berisi pernyataan lengkap dari apa yang harus dilakukan atau dipenuhi
oleh perangkat lunak

E. Evaluasi

Jawablah Pertanyaan berikut ini

1. Apa yang dimaksud dengan analisis kebutuhan perangkat lunak?
2. Sebutkan dan jelaskan faktor-faktor yang harus dipenuhi ketika melakukan
analisis kebutuhan!
3. Tahapan apa saja yang harus dilalui untuk melakukan analisis kebutuhan?
4. Jelaskan bagaimana cara melakukan analisis kebutuhan seandainya anda
diharuskan membuat perangkat lunak pendaftaran online!

Tugas Lapangan
Lakukan pengumpulan data dengan pemangku kepentingan sesuai dengan
Project Tugas Besar yang akan di bangun. Proses pengumpulan bisa dilakukan
dengan menggunakan metode wawancara dan kuisioner.
Buatlah rangkuman hasil pengumpulan data, dan berikan deskripsi bagaimana
bentuk aplikasi yang ingin dihasilkan dan tambahkan referensi jika terdapat
aplikasi serupa yang sudah ada.
A. Identitas Modul

IDENTITAS MODUL
Perguruan Tinggi : Politeknik Negeri Bengkalis Pertemuan ke : 10 - 12
Jurusan/Program Studi : Teknik Informatika/ Rekayasa Modul ke :5
Perangkat Lunak
Kode Mata Kuliah : RPL16303 Jumlah Halaman :7
Nama Mata Kuliah : Rekayasa Kebutuhan Perangkat Mulai Berlaku : 2018
Lunak

B. Komponen Modul
1. Judul Modul

MODUL V
SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

2. Kompetensi Dasar
Agar mahasiswa mampu memahami spesifikasi yang dibutuhkan dalam
spesifikasi kebutuhan perangkat lunak

3. Pokok Bahasan dan Sub Pokok Bahasan

a. Metode pembuatan SKPL
b. Pembuatan SKPL yang baik
c. Template SKPL

4. Indikator Pencapaian
a. Mahasiswa memahami perancangan SRS/SKPL

5. Referensi
1. Daniel Siahaan.2012. Analisa Kebutuhan Dalam Rekayasa Perangkat
Lunak, Andi, Yogyakarta
2. Sommerville, I, 2007. Software Engineering. 8th Edition: Addison-Wesley
3. Roger S. Pressman, Ph.D. 2012. Rekayasa Perangkat Lunak Edisi 7 Buku
1, Andi, Yogyakarta
 C. Materi Modul

SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK

5.1 Metode Pembuatan SKPL

Secara umum SKPL harus mencantumkan semua kebutuhan yang harus
dipenuhi oleh perangkat lunak. Selain itu, SKPL juga harus dapat mendefinisikan
atribut-atribut perangkat lunak, seperti: keandalan (reliability), ketersediaan
(availability), keamanan (security), kemampuan untuk dapat dipelihara
(maintainability), dan portabilitas (portability).
Menurut [DAV93] SKPL tidak harus mencantumkan:
a) Kebutuhan-kebutuhan proyek, seperti jadwal, biaya, milestone, laporan-
laporan, dan sebagainya.
b) Rancangan perangkat lunak.
c) Rencana jaminan produk, seperti rencana validasi dan verifikasi atau rencana
pengujian.
Ada sembilan kelompok orang yang terlibat dalam pembuatan SKPL antar lain:
1) Pemakai
Kelompok orang yang akan mengoperasikan atau menggunakan produk dari
perangkat lunak yang dibuat
2) Pelanggan
Individu atau perusahaan yang menginginkan dan membiayai pembuatan
perangkat lunak.
3) Analis Sistem (System Engineer)
Kelompok orang yang biasanya melakukan kontak teknik pertama kali
dengan pelanggan. Bertugas menganalisis persoalan, mengenali dan
menuliskan kebutuhan.
4) Software Engineer
 Kelompok orang yang akan bekerja sama dengan System Engineer saat
mendefinisikan kebutuhan perangkat lunak, dan membuat deskripsi
perancangannya.
5) Pemrogram
Kelompok orang yang akan menerima spesifikasi perancangan perangkat
lunak, membuat modul-modul program, menguji, dan memeriksa modul.
6) Test Integration Group
Kelompok orang yang akan melakukan pengujian dan integrasi modul
program.

7) Maintenance Group
Memantau dan merawat performansi sistem perangkat lunak yang dibuat
selama pelaksanaan dan pada saat modifikasi muncul (80% dari pekerjaan).
8) Technical Support
Kelompok orang, konsultan atau orang yang mempunyai kepandaian lebih
tinggi, yang akan memberikan dukungan teknis kepada pengembang
perangkat lunak.

9) Staf dan Clerical Work

Kelompok orang yang bertugas mengetik, memasukkan data, dan membuat
dokumen.

5.2 Pembuatan SKPL yang baik

Menurut Alan M. Davis [DAV93], penulisan SKPL yang baik adalah yang
memenuhi kriteria-kriteria berikut:

1. Benar
Setiap kebutuhan yang dinyatakan dalam SKPL merepresentasikan kebutuhan
dari perangkat lunak yang akan dibangun.

2. Tidak bias (unambiguous)

Setiap kebutuhan yang dinyatakan dalam SKPL hanya memiliki satu arti atau
satu interpretasi.

3. Lengkap
SKPL dikatakan lengkap jika menyertakan:
 a. Semua kebutuhan yang harus dilakukan perangkat lunak.
b. Definisi dari bentuk tanggapan perangkat lunak terhadap semua kelas data
masukan dari berbagai situasi.
c. Identifikasi yang lengkap dari setiap halaman, gambar dan tabel,
penjelasan istilah-istilah yang digunakan, dan rujukan-rujukan.
d. Ttidak ada bagian yang dinyatakan dengan “akan didefinisikan kemudian”
(to be define).

4. Dapat diverifikasi
Setiap kebutuhan yang dinyatakan dalam SKPL dapat diperiksa dan diuji
kebenarannya.

5. Konsisten
Semua atau sebagian kebutuhan yang dinyatakan dalam SKPL tidak
bertentangan dokumen-dokumen lain yang disusun sebelumnya, seperti
dokumen spesifikasi kebutuhan sistem.

6. Dapat dipahami oleh pelanggan

Isi SKPL harus dapat dimengerti oleh pelanggan dan pemakai, walaupun ada
notasi-notasi formal yang digunakan didalamnya.

7. Dapat dimodifikasi
Struktur dan gaya penulisan SKPL memungkinkan untuk diubah dengan
mudah jika ada perubahan kebutuhan, tetapi tetap konsisten dan lengkap.

8. Dapat ditelusuri
SKPL dapat ditelusuri jika ditulis dalam bentuk yang dapat menjelaskan dari
mana asal kebutuhan dan kebutuhan bagaimana direalisasi.

9. Mempunyai keterangan (annotated)

Setiap kebutuhan diurutkan sesuai tingkat kepentingan atau kestabilannya, dan
diberikan keterangan apakah kebutuhan tersebut merupakan keharusan,
disarankan, atau optional.

10. Ringkas
Isi SKPL ditulis dengan kalimat-kalimat yang ringkas dan jelas.

11. Terorganisasi
 Penulisan kebutuhan diorganisasi dengan tata letak tertentu sehingga
memudahkan untuk mencarinya.

Hindari hal-hal berikut saat menulis SKPL:

a. memberikan penjelasan yang berlebih-lebihan dan berulang-ulang sehingga
menjadi tidak jelas.
b. menggunakan istilah secara tidak konsisten.
c. menyatakan keterukuran kebutuhan secara tidak jelas, misalnya dengan
menggunakan kata-kata: minimal, maksimal, optimial, cepat, user-friendly,
mudah, sederhana, normal, efisien, fleksibel, dan/atau, dan lain-lain, atau dan
sebagainya.
d. menuliskan “mimpi-mimpi”, yaitu hal-hal yang tidak akan dapat dilakukan
oleh perangkat lunak.

5.3 Template SKPL

Ada banyak tata letak atau format dokumen SKPL. Berikut adalah tata letak
SKPL yang sebagian besar diadopsi dari IEEE Std 830-1998:
a) SKPL untuk Pendekatan Aliran Data
Tabel 5.1 SKPL untuk pendekatan Aliran Data

1. PENDAHULUAN
1.1 Kegunaan
1.2 Ruang Lingkup
1.3 Definisi, Akronim, dan Singkatan
1.4 Referensi
1.5 Ikhtisar

2. DESKRIPSI UMUM
2.1 Perspektif Produk
2.2 Fungsi Produk
2.3 Karakteristik Pemakai
2.4 Batasan-batasan
2.5 Asumsi dan Ketergantungan

3. KEBUTUHAN RINCI
3.1 Kebutuhan Antarmuka Eksternal
3.1.1 Antarmuka Pemakai
3.1.2 Antarmuka Perangkat Keras
3.1.3 Antarmuka Perangkat Lunak
3.1.4 Antarmuka Komunikasi
3.2 Kebutuhan Fungsional
3.2.1 Deskripsi Kebutuhan Fungsional
3.2.2 Diagram Konteks
 3.2.3 Diagram Aliran Data
3.2.3.1 Diagram Aliran Data Proses 1
3.2.3.2 Diagram Aliran Data Proses 2
.
.
3.2.3.n Diagram Aliran Data Proses n

3.2.4 Kamus Data

3.2.4.1 Tempat Penyimpanan Data
3.2.4.2 Aliran Data
3.2.5 Spesifikasi Proses
3.2.5.1 Proses 1
3.2.5.2 Proses 2
.
.
3.2.5.m Proses m
3.3 Kebutuhan Performansi
3.4 Kendala Perancangan
3.5 Atribut Sistem Perangkat Lunak
3.6 Kebutuhan Lain

b) SKPL untuk pendekatan Objek

Tabel 5.2 SKPL untuk pendekatan Objek

1. PENDAHULUAN
1.1 Kegunaan
1.2 Ruang Lingkup
1.3 Definisi, Akronim, dan Singkatan
1.4 Referensi
1.5 Ikhtisar

2. DESKRIPSI UMUM
2.1 Perspektif Produk
2.2 Fungsi Produk
2.3 Karakteristik Pemakai
2.4 Batasan-batasan
2.5 Asumsi dan Ketergantungan

3. KEBUTUHAN RINCI
3.1 Kebutuhan Antarmuka Eksternal
3.1.1 Antarmuka Pemakai
3.1.2 Antarmuka Perangkat Keras
3.1.3 Antarmuka Perangkat Lunak
3.1.4 Antarmuka Komunikasi
3.2 Kebutuhan Fungsional
3.2.1 Deskripsi Kebutuhan Fungsional
3.2.2 Diagram Use Case
3.2.3 Skenario
3.2.3.1 Skenario Use Case 1
3.2.3.2 Skenario Use Case 2
.
.
3.2.3.n Skenario Use Case n
3.3 Kebutuhan Performansi
 3.4 Kendala Perancangan
3.5 Atribut Sistem Perangkat Lunak
3.6 Kebutuhan Lain

D. Rangkuman
a. SKPL secara umum harus mencantumkan semua kebutuhan yang harus
dipenuhi oleh perangkat lunak. Selain itu, SKPL juga harus dapat
mendefinisikan atribut-atribut perangkat lunak, seperti: keandalan
(reliability), ketersediaan (availability), keamanan (security), kemampuan
untuk dapat dipelihara (maintainability), dan portabilitas (portability).
b. Kebutuhan perangkat lunak ditulis secara sistematis dalam suatu dokumen
yang disebut Spesifikasi Kebutuhan Perangkat Lunak (SKPL), sehingga dapat
dijadikan acuan oleh pemakai dan pengembang pada saat dan setelah
pelaksanaan pembuatan perangkat lunak. Oleh karena itu ada beberapa hal,
seperti atribut dan sistematika, yang harus diperhatikan untuk dapat
menuliskan SKPL yang baik.

E. Evaluasi
1. Buatlah dokumen SKPL untuk proyek yang pernah anda buat sebelumnya!
A. Identitas Modul

IDENTITAS MODUL
Perguruan Tinggi : Politeknik Negeri Bengkalis Pertemuan ke : 13 dan 14
Jurusan/Program Studi : Teknik Informatika/ Rekayasa Modul ke :6
Perangkat Lunak
Kode Mata Kuliah : RPL16303 Jumlah Halaman : 10
Nama Mata Kuliah : Rekayasa Kebutuhan Perangkat Mulai Berlaku : 2018
Lunak

B. Komponen Modul
1. Judul Modul

MODUL VI
VERIFIKASI DAN VALIDASI KEBUTUHAN

2. Kompetensi Dasar
Agar mahasiswa mengetahui dan memahami bagaimana memilih metode
dan melakukan verifikasi kebutuhan perangkat lunak yang sesuai.

3. Pokok Bahasan dan Sub Pokok Bahasan

a. Verifikasi
b. Validasi
c. Pengecekan validasi
d. Pengujian

4. Indikator Pencapaian
a. Mahasiswa mampu memilih metode verifikasi kebutuhan perangkat
lunak yang sesuai
b. Mahasiswa mampu melakukan verifikasi kebutuhan perangkat lunak

5. Referensi
1. Siahaan, D. (2012). Rekayasa Perangkat Lunak. Andi Offset,
Yogyakarta
 2. Sommerville, I. (2000). Software Engineering Edisi 6 jilid 1. Erlangga,
Jakarta

C. Materi Modul

VERIFIKASI KEBUTUHAN

6.1 Verifikasi
Verifikasi terhadap kebutuhan perangkat lunak adalah tahapan dari rekayasa
perangkat lunak untuk memastikan produk yang dihasilkan sesuai dengan
spesifikasi yang ditentukan atau dalam istilahnya “doing the thing right”.
Menurut (Abraham and Moore, 2001) aktivitas verifikasi dan validasi
memiliki tujuan untuk memastikan:
a. Dokumen SKPL menjelaskan dengan benar keinginan terhadap kemampuan
dan karakteristik yang memuaskan bagi pemangku kepentingan.
b. SKPL diuraikan dengan benar sesuai dengan kebutuhan sistem, aturan bisnis,
dan sumber-sumber lain yang berkaitan.
c. Spesifikasi kebutuhan menyeluruh dan berkualitas tinggi.
d. Representasi kebutuhan sudah konsisten dan tidak ada konflik antara
spefikasi satu dengan yang lainnya.
e. SKPL menyediakan informasi yang cukup, berkualitas dan dapat dipercaya.
Dengan mengacu pada standar IEEE 830-1998 (IEEE, 1998), verifikasi dan
validasi dari spesifikasi kebutuhan diharuskan memiliki kriteria antara lain:
a. Tepat, spesifikasi kebutuhan dinyatakan benar apabila setiap pernyataan
kebutuhan dengan sistem bisa saling bertemu dan dapat direalisasikan.
b. Tidak rancu, spesifikasi kebutuhan disebut tidak rancu jika dan hanya jika
setiap pernyataan kebutuhan hanya memiliki satu interpretasi.
c. Lengkap, semua spesifikasi kebutuhan sudah mencakup keseluruhan sistem
yang dibutuhkan oleh pemangku kepentingan.
d. Konsisten, tidak terdapat bagian atau sub bagian yang konflik antara satu
dengan lainnya.
e. Diranking berdasarkan kepentingannya, Spesifikasi kebutuhan di susun sesuai
dengan prioritas pentingnya tiap bagian di dalam sistem.
f. Dapat diverifikasi, hasil akhir dari produk dapat diukur sesuai dengan
spesifikasi kebutuhan.
g. Dapat dimodifikasi, spesifikasi kebutuhan dimungkinkan untuk dilakukan
perubahan.
h. Dapat dilacak, Spesifikasi dapat ditelusuri tiap bagiannya tahap demi
tahap.
Untuk mempermudah melakukan proses verifikasi dan validasi tersebut daftar
pertanyaan untuk pengecekan terstruktur dapat digunakan seperti pada tabel 6.1.
Tabel 6.1 Daftar pertanyaan untuk mempermudah proses verivikasi dan validasi
Sumber: Rekayasa Perangkat Lunak, Daniel Siahaan
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?
KONSISTEN - Apakah setiap atribut didefinisikan sekali saja?
- Apakah setiap metode didefinisikan sekali saja?
DAPAT DIVERIFIKASI - Apakah semua kuantitas spesifikasi dalam
pengertian yang terukur?
DAPAT DIMODIFIKASI - Sudahkan semua struktur yang berulang
dihilangkan?
- 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 :

a. Perencanaan dan pemeliharaan kebutuhan.
b. Koordinasi dan interpretasi kemampuan dan kualitas usaha.
c. Memberikan catatan ketidak-sesuaian dengan segera kepada pengguna
ataupun kelompok pengembang.
d. Mengidentifikasi kemungkinan masalah dari awal.
e. Menyediakan evaluasi teknis dari kemampuan perangkat lunak dan kualitas
pendukungnya
f. Menilai dampak keseluruhan yang diakibatkan apabila terdapat perubahan
spesifikasi kebutuhan.
g. Menentukan sasaran kualitas dan kemampuan produk.
h. Memberikan beragam antisipasi terhadap masalah dan bagaimana
pemecahannya.
i. Dapat menggunakan pilihan perangkat lunak yang mampu untuk
menganalisis dan menguji secara efektif masalah-masalah pada sistem dan
perangkat lunak.
j. Memilih tahapan dan teknik yang diaplikasikan untuk mengukur dan
memprediksi kualitas perangkat lunak.
Fokus kegiatan dalam tahapan verifikasi meliputi:
a. Mengawali dengan evaluasi terhadap dokumentasi konsep.
b. Memulai perancanaan pengujian.
c. Mengawali analisis penelusuran perangkat lunak.
d. Mengawali evaluasi kebutuhan.
e. Mengawali analisis antarmuka atau tampilan.
f. Evaluasi penggunaan ulang perangkat lunak.
Cakupan yang berkaitan dengan SKPL diantaranya adalah:
a. SKPL seharusnya dengan benar mendefinisikan semua kebutuhan perangkat
lunak dan tidak dimungkinkan adanya multi-interpretasi.
b. SKPL seharusnya tidak mendeskripsikan detail beberapa rancangan dan
implementasinya.
c. SKPL seharusnya tidak menambahkan hubungan-hubungan sistem dengan
sistem di luarnya.
Contoh pendekatan inspeksi terhadap model data
 Gambar 6.1 Dua Model Relasi Entitas Data Relasional.
Sumber: Rekayasa Perangkat Lunak, Daniel Siahaan

Langkah-langkah teknis yang dapat ditempuh untuk melakukan verifikasi

perangkat lunak
1) Analisis algoritma
2) Back to back testing
3) Boundary value analysis
4) Data base analysis
5) Data use analysis
6) Decision truth table
7) Consistency analysis
8) Control flow analysis
9) Coverage analysis
10) Error seeding
11) Mutation analisys
12) Interface analysis
13) Interface testing

6.2 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
1) Tepat
2) Lengkap
3) Tidak rancu
4) Konsisten
5) Dirangking berdasarkan tingkat kepentingan dan stabilitas
6) Dapat dimodiiikasi
7) Dapat diverifikasi
8) Dapat dilacak

6.3 Pengecekan validasi

6.3.1 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
2. Kesalahan pada beberapa informasi penting
3. Beberapa informasi salah namun kurang signifikan di dalam pekerjaan
4. Beberapa informasi salah namun sudah terwakili oleh informasi yang lainnya
5. Dua bagian atau spesifikasi terjadi konflik

6.3.2 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:
a. Pelanggan, sponsor dan latar belakang,
b. Tujuan bisnis dan bukti pelacakanny,a
c. Data kebutuhan (basis data, format masukan/keluaran, status komuni-kasi,
dan inisialisasi,
d. Batasan dan antarmuka sistem,
e. Kebutuhan level-ranah (kejadian-kejadian dan tugas-tugas),
f. Kebutuhan level-produk (kejadian-kejadian dan fitur-fitur),
g. Kebutuhan level-rancangan (prototipe dan protokol komunikasi)
h. Spesifikasi dari fungsi yang tidak sepele,
i. Kasus-kasus ekstrem, kejadian khusus, dan kegagalan tugas,
j. Kebutuhan kualitas (unjuk kerja, usability, keamanan, dll),
k. Item yang dianggap sebagai produk dari proyek pengembangan perangkat
lunak (deliverable) yang akan diserahkan pengembang kepada pelanggan lain
(dokumentasi, pelatihan, dll),
l. Glosarium (definisi dari terminologi, dan lain-lain).
Struktur dari konten yang diharapkan ada dalam suatu dokumen spesifikasi
kebutuhan:
a. Pendahuluan
b. Tujuan sistem
c. Kebutuhan data
d. Kebutuhan fungsional
e. Perlakuan pada kasus yang khusus
f. Kebutuhan kualitas
g. Penyerahan lainnya
h. Daftar

6.3.3 Penilaian Resiko

Hal lain yang juga diperlukan dalam validasi adalah pengecekan terhadap
resiko. Resiko yang tinggi terhadap pelanggan menjadi resiko yang rendah bagi
pengembang dan begitu sebaliknya.
Langkah yang perlu ditempuh untuk mengenali resiko
a. Staf pelanggan perlu meninjau ulang spesifikasi dan merangking tiap
kebutuhan sesuai resikonya masing-masing. Resiko yang seringkali ada
adalah pelanggan tidak mendapatkan apa yang diinginkan sampai dia
mendapatkan apa yang dispesifikasikan.
Dengan menggunakan cek konten, pelanggan dapat mengidentifikasi bagian-
bagian yang belum terdapat dalam spesifikasi.
b. Developer dapat melakukan hal sama untuk merangking tingkat resiko yang
akan dihadapi. Resiko yang biasa terjadi mereka tidak bisa memastikan
kesesuaian spesifikasi dengan pembiayaan proyek.
c. Justifikasi dibuat untuk melihat sampai sejauh mana resiko yang mungkin
dihadapi.
Terdapat cara singkat untuk menanggulangi resiko yang tidak dapat
ditoleransi
a. Pilih model kebutuhan yang lain dengan resiko yang lebih rendah
b. Melakukan elisitasi lagi kebutuhan yang lebih tepat,
c. Mengisolasi resiko untuk mengurangi kegagalan jika kecelakaan terjadi.
d. Menjaga resiko di bawah pengawasan sehingga pengembang mampu
bertindak cepat jika kecelakaan ataupun kegagalan terjadi

6.4 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:
a. Simulasi
b. Prototipe
c. Pilot

D. Rangkuman
Verifikasi kebutuhan perangkat lunak adalah tahapan dari rekayasa perangkat
lunak untuk memastikan produk yang dihasilkan sesuai dengan spesifikasi yang
ditentukan atau dalam istilahnya “doing the thing right” sedangkan 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.
 Verifikasi dan validasi dari spesifikasi kebutuhan diharuskan memiliki kriteria
seperti tepat, tidak rancu, lengkap, konsisten, di ranking berdasarkan kepentingan,
dapat diverifikasi, dapat dimodifikasi dan dapat dilacak

E. Evaluasi
1. Jelaskan mengenai verifikasi dan validasi kebutuhan perangkat lunak!
2. Fokus kegiatan pada tahapan verifikasi?
3. Sebutkan metode pengujian yang dapat diterapkan dalam verifikasi dan
validasi kebutuhan perangkat lunak!