Modul Final Project

Rekayasa Perangkat Lunak

2017
BAB I
Pendahuluan Proyek Rekayasa Perangkat Lunak

Pokok Bahasan:
Pendahuluan
Deskripsi Umum Perangkat Lunak
Langkah-langkah Pengembangan Perangkat Lunak
Pembentukan tim Proyek Pengembang

Tujuan Pembelajaran:
Memahami tugas Rekayasa Perangkat Lunak
Memahami tahap-tahap umum dalam proyek perangkat lunak
Memahami tugas dalam tim pengembang perangkat lunak

Dasar Teori

Perangkat lunak/software adalah program komputer beserta dengan berbagai

dokumentasi terkait seperti persyaratan/requirement, model desain dan manual
pengguna (user guide). Definisi resmi yang mengacu pada standard dari IEEE dan
ISO adalah sebagaimana terlihat dalam Gambar 1.1.

Sedangkan Rekayasa Perangkat Lunak atau Software Engineering adalah

suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai
dari tahap awal requirement capturing (analisa kebutuhan pengguna), specification
(menentukan spesifikasi dari kebutuhan pengguna), desain, coding, testing sampai
pemeliharaan sistem setelah digunakan. (Romi Satria Wahono berdasar pendapat
Ian Sommerville)
 Gambar 1.1 Definisi Software versi IEEE dan ISO

Software Process

Software process adalah satu set kegiatan/aktivitas yang tujuannya adalah

pengembangan atau evolusi perangkat lunak, seringkali disebut sebagai Siklus
Hidup Pengembangan Perangkat Lunak/Software Development Life Cycle (SDLC).
SDLC secara garis besar tampak dalam Gambar 2.

Gambar 2 Siklus Hidup Pengembangan Perangkat Lunak

Penjelasan dari masing-masing fase di atas adalah sebagai berikut

1. Planning/Perencanaan : Why build the system?

Mengidentifkasi nilai bisnis (business value), analisis kelayakan (feasibility
analysis) System Request/Proposal
2. Analysis: Who, what, when, where will the system be?
Pengumpulan kebutuhan pengguna (User Requirement Gathering) System
Specification
3. Design: How will the system work?
Desain arsitektur, desain antar muka, desain data, desain program System
Design
4. Implementation: System delivery
Konstruksi sistem, pengujian/testing, instalasi dan perawatan/ maintenance
New System

Planning

1. Mengidentifikasi nilai bisnis/business value

Biaya yang lebih rendah
Keuntungan yang lebih tinggi
2. Analisis Kelayakan
Kelayakan secara teknis
Kelayakan secara ekonomis
Kelayakan secara organisasi
3. Menyusun rencana kerja
4. Menyusun SDM yang terlibat dalam proyek (staff the project)

Analisis
1. Pengumpulan kebutuhan user dengan menjawab pertanyaan-pertanyaan
berikut:
Siapa yang akan menggunakan sistem?
Apa yang akan sistem lakukan?
Kapan itu digunakan?
2. Selidiki sistem saat ini
3. Mengidentifikasi perbaikan mungkin
4. Membangun konsep (Software) untuk sistem baru

Tugas Pendahuluan
Pada prinsipnya perangkat lunak dibuat dalam rangka menyelesaikan suatu masalah
praktis dalam kehidupan manusia.
1. Lakukan curah pendapat (brain storming) untuk sebanyak mungkin
memunculkan ide permasalahan/studi kasus yang akan dibuatkan solusi
perangkat lunaknya.
2. Dari masing-masing ide tersebut, buat draft tentang latar belakang dan
permasalahan dari diangkatnya ide tersebut sekaligus solusi dari perangkat
lunak yang akan dibuat.

Percobaan
Lakukan diskusi dengan sesama anggota tim untuk:
1. Menyusun daftar sekaligus prioritasnya dari ide yang berpotensi untuk
diangkat menjadi studi kasus.
2. Merumuskan detil latar belakang dan permasalahan dari masing-masing ide
tersebut sekaligus solusi yang dari perangkat lunak yang akan dibuat

Laporan Resmi
Dari hasil diskusi yang dilakukan, susun laporan resmi berupa kumpulan ide studi
kasus beserta detil :
1. Judul Aplikasi
2. Latar belakang
3. Permasalahan
4. Solusi
BAB 2
STUDI KELAYAKAN PERANGKAT LUNAK

Pokok Bahasan:
Memilih studi kasus proyek perangkat lunak
Analisis kelayakan studi kasus yang dipilih

Tujuan Pembelajaran:
Mampu mendefinisikan studi kasus dari permasalahan dunia nyata
Mampu melakukan analisis kelayakan dari studi kasus yang dipilih

Dasar Teori

Studi kelayakan merupakan suatu kebutuhan tentang ketersediaan dan persediaan

akan keunggulan dan kelemahan suatu sistem. Studi kelayakan dilakukan dengan
survey yang menghasilkan dokumen-dokumen kebutuhan. Berdasarkan dokumen
kebutuhan dan studi kelayakan, dapat disusun persyaratan perangkat lunak Studi
kelayakan berguna untuk memastikan bahwa solusi yang diusulkan tersebut benar-
benar dapat dicapai dengan sumber daya dan dengan memperhatikan kendala yang
terdapat pada perusahaan serta dampak terhadap lingkungan sekeliling Analis
sistem melaksanakan penyelidikan awal terhadap masalah dan peluang bisnis yang
disajikan dalam usulan proyek pengembangan sistem. Tugas-tugas yang tercakup
dalam studi kelayakan meliputi:
Penentuan masalah dan peluang yang dituju sistem
Pembentukan sasaran sistem baru secara keseluruhan
Pengidentifikasian para pemakai sistem
Pembentukan lingkup sistem
Sistem analis juga melakukan tugas-tugas seperti berikut:
Pengusulan perangkat lunak dan perangkat keras untuk sistem baru
Pembuatan analisis untuk membuat atau membeli aplikasi
Pembuatan analisis biaya/manfaat
Pengkajian terhadap risiko proyek
Pemberian rekomendasi untuk meneruskan atau menghentikan proyek

Contoh Studi Kelayakan

Pembuatan mesin absensi menggunakan RF ID mempunyai kelebihan
Transaksi absensi pegawai menjadi otomatis tersimpan di database tanpa
prosedur yang rumit.
Penempatan counter absensi tidak harus terpusat
Menghindari kesalahan ketik saat update data karena, data absensi tidak
diisi manual tetapi bersifat otomatis
Penghematan waktu dan tenaga di bagian kepegawaian
Adapun kelemahannya adalah:
Biaya pengembangan cukup besar, karena harus menyediakan komputer
sebagai server database, program aplikasi dan beberapa mesin counter. Pada
mesin absensi biasa tidak diperlukan biaya tinggi.
Keamanan data perlu dipertimbangkan lebih jauh
Pertimbangkan mana yang lebih menguntungkan ?

Survey
Survey dapat dilakukan dengan wawancara, kuisioner, atau pengamatan untuk
mendapatkan gambaran lebih jelas mengenai sistem administrasi yang berlaku.
Hasil survey adalah :
model dan bentuk laporan yang diharapkan,
data-data apa yang sudah tersedia dan yang harus disediakan
Sistem konversi bila sudah ada perangkat lunak yang lama
Tujuan Studi Kelayakan
1. Memahami proses bisnis pada sistem yang lama
Flowchart dari sistem
Struktur Organisasi
Deskripsi Tugas dan Jabatan
Salinan laporan-laporan
Kode-kode yang dipakai didalam sistem
2. Menentukan kebutuhan pemakai sistem secara garis besar untuk dapat
mencapai sasaran sistem
Wawancara ke pemakai sistem
Observasi data
Pengambilan sampel
3. Menentukan permasalahan yang terjadi pada sistem yang lama yang
menyebabkan belum dapat mencapai sasarannya.

Hasil Studi Kelayakan harus bisa menjawab pertanyaan-pertanyaan :

Apa yang dikerjakan oleh sistem lama?
Apa yang harus dihasilkan oleh sistem yang baru untuk mencapai
sasarannya ?
Apa permasalahan yang harus dipecahkan oleh sistem baru ?
Bagaimana hasil penilaian kelayakan teknis, ekonomi, hukum, operasi, dan
jadwal.
Hasil dari studi kelayakan akan menentukan proyek dilanjutkan atau dihentikan.
Hasil studi kelayakan akan didokumentasikan terpisah dan dilampirkanpada
dokumen spesifikasi system.
Berikut outline dokumen studi kelayakan

Ukuran Studi Kelayakan

Aspek Pertimbangan
Teknologi Apakah sistem dapat dikembangkan dan dioperasikan
dengan teknologi yang tersedia?
Ekonomi Apakah manfaat sistem lebih besar daripada biaya yang
dikeluarkan (termasuk untuk memenuhi kebutuhan
personil) ?
Non-ekonomi Apakah sistem yang diusulkan memiliki keuntungan yang
tak dapat diukur dengan uang
Organisasi atau Apakah sistem yang diusulkan bisa cocok dengan budaya
Operasional organisasi?
Apakah level keahlian yang digunakan dalam sistem baru
sesuai dengan pegawai yang akan mengoperasikannya?
Jadwal Mungkinkah menerapkan sistem tersebut sesuai dengan
jadwal yang telah ditetapkan ?
Kendala hukum, Apakah sistem yang diusulkan tidak bertentangan dengan
etika, dan yang lain etika atau hukum?
Apakah terdapat kendala-kendala yang berbahaya yang
dilanggar?
Tugas Pendahuluan:

Dari beberapa ide studi kasus dalam laporan resmi praktikum 1, lakukan analisis
studi kelayakan untuk masing-masing

Percobaan:

1. Lakukan diskusi dengan sesama anggota tim untuk

Memberikan rekomendasi mengenai solusi dari studi kasus yang dipilih.
Mendefinisikan pengaruh dari rekomendasi pada studi kasus
Mencari alternative alternative yang mungkin.
Analisa resiko, biaya dan keuntungan.
2. Konsultasikan dengan dosen hasil studi kelayakan yang sudah dilakukan untuk
menentukan 1 studi kasus yang feasible untuk dijadikan proyek perangkat
lunak.

Laporan Resmi:

Dari hasil diskusi yang dilakukan, susun laporan resmi berupa dokumen studi
kelayakan untuk studi kasus terpilih
BAB 3
PENDEFINISIAN PROYEK PERANGKAT LUNAK

Pokok Bahasan:

Dokumentasi dan Visualisasi Studi Kasus Proyek Perangkat Lunak

Tujuan Pembelajaran:

Mampu merancang skenario, memvisualisasikan sekaligus mendefinisikan

proyek perangkat lunak dari studi kasus yang dipilih

Dasar Teori

Skenario

Skenario adalah sebuah cerita yang mudah diakses atau sebuah narasi untuk
membuat sebuah aplikasi menjadi hidup
Fungsi penting dari cerita ini adalah untuk memungkinkan terjadinya diskusi
yang spesifik (terukur, relevan dan eksplisit) di antara pihak-pihak yang
berkepentingan.
Fungsi utama dari skenario adalah untuk membuat peluang atau masalah bisa
diakses dan dimengerti bagi semua pihak yang berkepentingan
Tujuan utama dari scenario adalah untuk mempelajari, mendefinisikan serta
menganalisa produk atau fitur baru dari proyek perangkat lunak yang akan
dibuat.

Contoh Skenario (target nasabah bank)

Suatu hari, Budi salah seorang eksekutif muda di surabaya, mendapat telepon
dari istrinya yang mengatakan bahwa tagihan telepon, air dan listrik bulan ini belum
tebayar, sedangkan uang belanja bulanan sudah habis.
 Budi baru menyadari dompetnya masih berisi uang kurang lebih Rp.150.000.
Pada hari ini dia harus menghadiri rapat dengan beberapa klien ditempat berbeda,
sehingga dia tidak sempat untuk antri mengambil uang ke bank, antri di loket PLN,
PDAM dan Telkom. Ketika menolehkan pandangan ke luar jendela kantor, dia
melihat ada mesin ATM Innova. Sebelum menuju mesin ATM tersebut, ia
mengirim sms ke mesin tersebut untuk memastikan apakah mesin bisa dioperasikan
atau sedang rusak. Tidak beberapa lama kemudian, ia mendapat balasan SMS dari
mesin tersebut yang menunjukkan bahwa mesin dalam kondisi OK dan bisa
digunakan.
Budi baru menyadari dompetnya masih berisi uang kurang lebih Rp.150.000.
Pada hari ini dia harus menghadiri rapat dengan beberapa klien ditempat berbeda,
sehingga dia tidak sempat untuk antri mengambil uang ke bank, antri di loket PLN,
PDAM dan Telkom. Ketika menolehkan pandangan ke luar jendela kantor, dia
melihat ada mesin ATM Innova. Sebelum menuju mesin ATM tersebut, ia
mengirim sms ke mesin tersebut untuk memastikan apakah mesin bisa dioperasikan
atau sedang rusak. Tidak beberapa lama kemudian, ia mendapat balasan SMS dari
mesin tersebut yang menunjukkan bahwa mesin dalam kondisi OK dan bisa
digunakan.
Setelah digunakan budi, dalam mesin ATM Innova hanya tersisa kas tunai
sebesar Rp.1.000.000 yang merupakan batasan minimal cadangan kas tunai dalam
mesin. Mesin tersebut mengirimkan SMS ke bagian maintenance dengan
memberikan informasi dan warning bahwa cadangan kas mesin tersebut harus
segera ditambah.

Dari Cerita Menjadi Rancangan

Metode skenario yang berbasis cerita atau narasi adalah cara yang sangat baik
untuk mendapatkan definisi produk perangkat lunak dengan cepat dalam suatu
diskusi faktual yang lebih konkret.
Skenario diposisikan dalam pandangan tujuan dan pandangan aplikasi
pelanggan yang hendaknya menggabungkan visi pasar yang jelas dengan suatu
realisasi pengetahuan (know how). Dan ceritanya diekspresikan seluruhnya dalam
istilah kosakata, ilustrasi, gambar dll yang umum bagi target dari cerita tsb.
 Pada awal pengembangan proyek, skenario biasanya ditujukan untuk para
pembuat keputusan sebagai salah satu kelas pemangku kepentingan yang dibuat
sesingkat dan sesederhana mungkin tetapi tepat pada permasalahan utama.
Cerita dalam skenario ditujukan untuk menangkap kasus penggunaan sistem
oleh pengguna dari sudut pandang fungsional, dan pastikan skenario dibuat
berdasarkan sudut pandang pelanggan, bukan dari sudut pandang pengembang.

Komponen Dalam Skenario

Seorang analis perlu memperhatikan aspek-aspek berikut ketika membuat sebuah

skenario (Alspaug dan Anto, 2008)

1. Tujuan. Setiap skenario memiliki suatu tujuan yang merupakan obyek yang
hendak dipelajari dan dieksplorasi oleh analis sistem.
2. Ruang Lingkup. Ruang lingkup dari suatu cerita harus ditentukan dengan
baik, untuk membantu memahami keseluruhan konteks dari sistem.
3. Sudut pandang pemangku kepentingan. Skenario biasanya ditulis
berdasarkan sudut pandang dari sejumlah pemangku kepentingan yang
dipilih secara hati-hati. Perhatikan bahwa skenario adalah cara untuk
berkomunikasi dengan pelanggan, manajer pemasaran dan ahli lain tentang
spesifikasi kebutuhan sistem.
4. Visualisasi. Dengan gambar kita bisa mengungkapkan lebih banyak
dibandingkan dengan kata-kata. Maka, jika diperlukan kita dapat
menambahkan ilustrasi gambar untuk memvisualisasikan suatu objek.
5. Singkat. Usahakan agar skenario dibangun dengan singkat dan sederhana,
tetapi mengena terhadap permasalahan yang menjadi kepedulian utama dari
pemangku kepentingan yang menjadi target dari skenario tsb.
6. Rekursif, dekomposisi dan penyempurnaan. Cerita yang dibangun dari
kejadian-kejadian penting yang menceritakan fungsionalitas dan manfaat
dari sistem. Kemudian didekomposisi ke dalam segmen lebih kecil untuk
memudahkan penanganan permasalahan dan analisis. Kemudian
disempurnakan berdasarkan umpan balik dari pelanggan maupun informasi
tambahan yang didapatkan dari aktivitas elisitasi.
Parameter Skenario Yang Baik

Dalam menilai suatu skenario, kita sebagai analis harus dapat menentukan baik atau
tidaknya skenario dari sejumlah kriteria berikut:

1. Accessible dan Understandable. Fungsi utama dari skenario adalah untuk

membuat peluang atau kesempatan serta mengkomunikasikan
permasalahan dengan semua pemangku kepentingan. Maka skenario harus
bisa diakses dan dimengerti oleh semua pemangku kepentingan.
2. Important, Valuable, Appealing, Attractive. Peluang maupun
permasalahan (ide, produk, fungsi atau fitur) yang direpresentasikan harus
signifikan bagi target penggunanya. Peluang atau permasalahan tsb harus
memiliki nilai bagi penggunanya.
3. Critical, Challengenging. Tujuan dari skenario adalah belajar,
mendefinisikan dan menganalisa produk atau fitur baru. Feedback yang
diharapkan adalah membantu memperkaya pengetahuan akan ranah sistem.
4. Requent, No Exceptional Niche. Seorang analis sistem perlu
memfokuskan diri pada jalur utama, yaitu kasus yang sifatnya umum
berlaku. Gunakan kasus yang menggambarkan bahwa produk atau fitur
akan sering digunakan atau tidak lepas dari kehidupan sehari-hari target
penggunanya, misalnya untuk sistem ATM hindari cerita yang berkaitan
dengan perampokan atau musibah tornado, karena kesemuanya itu jarang
terjadi. Tetapi skenario lain untuk kasus khusus yang sifatnya eksepsional,
misalnya berkaitan dengan aspek keamanan, integritas data, reliabilitas dll.
5. Specific. Nilai dari sebuah skenario adalah kespesifikannya. Kebanyakan
deskripsi dari sistem bersifat sangat generik sehingga seringkali kurang
kuat, akan tetapi pada saat yang bersamaan sangat tidak spesifik. Suatu
cerita yang baik berpusat pada satu cerita tunggal, hanya pada satu kejadian
saja. Cerita yang baik harus sespesifik mungkin dalam berbagai hal.
Maksudnya adalah:

Individu-individu yang berperan dalam skenario sebaiknya memiliki

nama, umur dan atribut-atribut relevan lainnya,
 Waktu dan lokasi yang spesifik (jika memang relevan)
Konten yang spesifik (misalnya sedang mendengarkan selama 2 jam
lagu Ebiet G Ade) dsb.

Tugas Pendahuluan:

Dari hasil Studi Kelayakan Perangkat Lunak yang telah dilaksanakan, lakukan
Pendefinisian Proyek yang akan dibuatkan perangkat lunaknya.

1. Buatlah rancangan skenario dari perangkat lunak yang akan dibuat. Alur
skenario didasarkan kepada tahap sebelumnya
2. Buatlah visualisasi dari skenario tersebut dalam salah satu bentuk di bawah ini
- film
- animasi flash

Percobaan

Lakukan konsultasi dan revisi terhadap konten materi yang telah divisualisasikan

Laporan Resmi:

Dari hasil konsultasi dan revisi yang dilakukan, susun laporan resmi berupa
Visualisasi skenario Perangkat Lunak yang akan dijadikan sebagai sarana untuk
Request for Proposal
BAB 4
REQUEST FOR PROPOSAL

Pokok Bahasan:
Penawaran kontrak proyek sistem informasi
Kontrak dengan developer

Tujuan Pembelajaran:
Mampu menjabarkan dan menvisualisasikan permasalahan pada studi kasus

Dasar Teori:
Request for proposal (RFP) adalah suatu penawaran, yang biasanya melalui proses
tender, oleh suatu lembaga atau perusahaan yang tertarik dalam pengadaan barang
atau jasa, kepada pemasok potensial untuk mengajukan proposal bisnisnya. Hal ini
dilakukan pada awal siklus pengadaan, baik pada studi pendahuluan atau pada tahap
pengadaan. Proses RFP membawa struktur keputusan pengadaan dan dimaksudkan
untuk medefinisikan risiko dan manfaat dengan jelas di depan.
Pada dasarnya, RFP :
- Menginformasikan kepada supplier bahwa lembaga tersebut mencari
penawaran
terbaik
- Menginformasikan kebutuhan barang dan jasa apa yang diinginkan
perusahaan
- Menginformasikan kepada supplier bahwa proses seleksi berlangsung
secara
kompertitif
Dokumen dari suatu RFP berisi :
- Latar Belakang Perusahaan
- Deskripsi Proyek
- Kebutuhan Design
- Kebutuhan Teknis dan Infrastruktur
 - Kebutuhan Fungsional
- Estimasi Lama Proyek
- Asumsi dan Persetujuan

Tugas Pendahuluan:
1. Mempersiapkan presentasi berisi visualisasi proyek yang akan ditenderkan
2. Mempelajari template dokumen RFP

Percobaan:
1. Mempresentasikan RFP dari proyek yang akan ditenderkan.
2. Menyiapkan dokumen RFP.

Laporan Resmi:
Membuat dokumen RFP dari proyek yang ditenderkan menggunakan template
yang disediakan.
BAB 5
FORMAL TECHNICAL REVIEW

Pokok Bahasan:
Pembuatan proposal proyek perangkat lunak
Review Kontrak

Tujuan Pembelajaran:
Mampu membuat proposal penawaran proyek Perangkat Lunak
Mampu mempresentasikan proposal penawaran Perangkat Lunak

Dasar Teori
Perangkat lunak/software adalah program komputer beserta dengan berbagai
dokumentasi terkait seperti persyaratan/requirement, model desain dan manual
Develop a concept for new system

Tugas Pendahuluan
Dari penawaran kontrak proyek yang diberikan pelanggan, susunlah proposal
penawaran yang terdiri atas 2 bagian.
Bagian 1 :
- Latar belakang
- Tujuan dan Manfaat
- Permasalahan
- Batasan masalah
Bagian 2 :
- Deskripsi Sistem
- Skema umum sistem Fitur-fitur sistem dan deskripsinya
- Teknologi yang digunakan
- Rancangan (awal) antar muka
Percobaan
1. Presentasikan proposal penawaran Perangkat Lunak yang telah dibuat.
2. Lakukan diskusi dan review dengan pelanggan terhadap penawaran
Perangkat Lunak yang diberikan
3. Lakukan konsultasi dan review terhadap proposal penawaran

Laporan Resmi
Dari hasil presentasi, diskusi, konsultasi dan review yang dilakukan, susun laporan
resmi berupa proposal penawaran versi final yang terdiri atas 2 bagian, yaitu :
Bagian 1 :
- Latar belakang
- Tujuan dan Manfaat
- Permasalahan
- Batasan masalah
Bagian 2 :
- Deskripsi Sistem
- Skema umum sistem : Fitur-fitur sistem dan deskripsinya
- Teknologi yang digunakan
- Rancangan (awal) antar muka
BAB 6
REQUIREMENT ENGINEERING

Pokok Bahasan
Elisitasi Kebutuhan Perangkat Lunak
Spesifikasi Kebutuhan Perangkat Lunak
Verifikasi dan Validasi Kebutuhan Perangkat Lunak
Pembuatan dokumen Spesifikasi Kebutuhan Perangkat Lunak (SKPL)
Fuctional Requirement dan Non Functional Requirement

Tujuan Pembelajaran
Mampu melakukan proses Elisitasi Kebutuhan Perangkat Lunak
Mampu menyusun dokumen Spesifikasi Kebutuhan Perangkat Lunak
Mampu menyusun Fuctional Requierement dan Non Functional
Requirement

Dasar Teori
Requirements engineering adalah fase terdepan dari proses rekayasa perangkat
lunak, di mana software requirements (kebutuhan) dari user (pengguna) dan
customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Para pakar software
engineering sepakat bahwa requirements engineering adalah suatu pekerjaan yang
sangat penting. Fakta membuktikan bahwa kebanyakan kegagalan pengembangan
software disebabkan karena adaya ketidakkonsistenan (inconsistent),
ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari
requirements specification (spesifikasi kebutuhan). Banyak definisi yang
diungkapkan oleh para peneliti tentang requirements engineering. Satu definisi
yang cukup jelas dan diterima secara umum adalah yang diuraikan oleh Pamela
Zave [Zave-97]: Requirements engineering adalah cabang dari software
engineering yang mengurusi masalah yang berhubungan dengan: tujuan (dunia
nyata), fungsi, dan batasan-batasan pada sistem software. Termasuk hubungan
faktor-faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software,
proses evolusinya baik berhubungan dengan masalah waktu maupun dengan
software lain (dalam satu famili).
Studi di The Standish Group mencatat bahwa prosentase akumulatif kegagalan
sebuah proyek pengembangan software sebagian besar disebabkan oleh masalah
requirements dan spesifikasinya [Standish-94]. Untuk merangkum masalah yang
ingin dipecahkan dalam cabang ilmu requirements engineering, kebanyakan pakar
mengamini ungkapan Ed Yourdon dalam foreword yang ditulisnya untuk buku
Managing Software Requirements A Unified Approach karya Dean Leffingwell
[Leffingwell-00]. Ed Yourdon menggunakan istilah the rock problem (masalah
batu) sebagai diskusi dasar masalah yang selalu muncul dalam proses pengerjaan
proyek software.
Customer (pelanggan) yang datang kepada kita untuk mengerjakan sebuah proyek
pengembangan software, adalah ibarat seseorang yang mengatakan kepada kita,
Tolong buatkan saya batu. Ketika kita memberikan kepadanya sebuah batu, dia
akan melihatnya sebentar dan mengatakan kepada kita, Ya terima kasih, tapi
sebenarnya yang saya inginkan adalah sebuah batu kecil berwarna biru. Dan ketika
kita bawakan untuknya batu kecil berwarna biru, dia mengatakan bahwa yang
diinginkan adalah yang bentuknya bulat. Demikian seterusnya proses iterasi
(iteration) terjadi berulangkali sampai akhirnya kita dapatkan yang sebenarnya
diinginkan customer kita adalah batu pualam kecil berwarna biru.
Meskipun mungkin sebenarnya bukan tepat yang diinginkan, tapi paling tidak
paling dekat dengan yang diinginkan customer. Dan mungkin saja terjadi,
customer kita mengubah pikiran tentang requirements pada saat proses interaksi
dengan pengembang terjadi (dari iterasi pertama yang sekedar batu, sampai iterasi
terakhir yang menghasilkan batu pualam kecil berwarna biru).
Hasil dari fase requirements engineering terdokumentasi dalam SRS (software
requirements specificatio) atau SKPL (spesifikasi kebutuhan perangkat lunak).
SKPL berisi kesepakatan bersama tentang permasalahan yang ingin dipecahkan
antara pengembang dan customer, dan merupakan titik start menuju proses
berikutnya yaitu software design.
Sistemisasi proses negosiasi pengembang dan customer dalam requirements
engineering dibagi dalam 3 proses besar yaitu: elicitation, specification, validation
and verification. Formula ini kemudian juga dikenal dengan nama The Three
Dimensions of Requirements Engineering. Proses requirements engineering ini
dilakukan secara iterasi dengan mengakomodasi adanya feedback dari customer
(user). Selengkapnya adalah sebagai berikut :

1. Requirements Elicitation
Adalah proses mengumpulkan dan memahami requirements dari user. Kadang
masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan
disiplin ilmu yang dimiliki). Customer adalah expert pada domain yang
softwarenya ingin dikembangkan (domain specialist), dilain pihak sang
pengembang (requirements analyst) adakalanya sama sekali buta terhadap
knowledge domain tersebut, meskipun tentu memahami dengan benar
bagaimana sebuah software harus dikembangkan. Gap knowledge domain
tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus
dan berulang (iterasi) antara pengembang dan customer. Proses interaksi
tersebut kemudian dimodelkan menjadi beberapa teknik dan metodologi
diantaranya adalah interviewing, brainstorming, prototyping, use case, dsb.
2. Requirements Specification
Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam
bentuk dokumen spesifikasi dokumen. Spesifikasi ini berisi tentang fitur dan
fungsi
 yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana
metode pengembangannya.
3. Requirements Validation and Verification
Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha:
Validation (validasi), yaitu proses untuk memastikan bahwa requirements
yang benar sudah ditulis.
Verification (verifikasi), yaitu proses untuk memastikan bahwa
requirements sudah ditulis dengan benar. Proses validasi dan verifikasi ini
melibatkan customer (user) sebagai pihak yang menilai dan memberi
feedback berhubungan dengan requirements.

Tipe Requirements
Kebutuhan (requirements) perangkat lunak seringkali diklasifikasikan ke dalam
dua kategori :
1. Functional Requirements
Merupakan pernyataan tentang sekumpulan layanan/fitur yang harus
tersedia dalam perangkat lunak
2. Non Functional Requirements
Terkait dengan kendala (constraint) dan kualitas dari perangkat lunak.
Kualitas perangkat lunak adalah sifat atau karakteristik dari sistem yang
stakeholders peduli dan karenanya akan mempengaruhi tingkat kepuasan
mereka dengan sistem

Tabel Ringkasan Kebutuhan Non Fungsional

SKPL-Id Keterangan

SKPL-NF001 Availability Ketersediaan Aplikasi

Untuk Dapat Diakses Oleh Pengguna.
SKPL-NF002 Reliability kehandalan aplikasi,
termasuk aspek teknis seperti
koneksi, kebutuhan hardware.
SKPL-NF003 Ergonomy Desain Aplikasi harus
disesuaikan dengan kenyamanan
pengguna.
SKPL-NF004 Portability Keberpindahan Aplikasi,
sehingga dapat diakses oleh berbagai
device.
SKPL-NF005 Memory Kebutuhan Aplikasi akan
media penyimpanan
SKPL-NF006 Response time Waktu Aplikasi untuk
merespon request dari user.
SKPL-NF007 Safety Keamanan data dari aplikasi,
serta penggunaan aplikasi.
SKPL-NF008 Security Keamanan aplikasi untuk
melindungi data di dalamnya.
SKPL-NF009 Bahasa komunikasi Media Bahasa
yang digunakan oleh aplikasi.

Tugas Pendahuluan
1. Temukan the real customer (pelanggan yang sesungguhnya) dari aplikasi
yang akan dibangun
2. Tentukan target-target yang hendak dicapai dalam proses requirements
engineering yang akan dilakukan
3. Kembangkan wawasan tentang aplikasi lain yang relevan dengan aplikasi
yang akan dibangun
4. Lakukan pendefinisian kebutuhan awal dari aplikasi yang akan dibangun,
yang akan dikembangkan melalui proses elisitasi

Percobaan
1. Lakukan proses elisitasi terhadap customer (pelanggan) untuk
mengumpulkan, memahami dan menetapkan kebutuhan dari pelanggan.
 2. Klasifikasikan daftar kebutuhan pelanggan ke dalam kategori functional
requirements dan non functional requirements
3. Berikan deskripsi dari masing-masing kebutuhan tersebut
4. Lakukan proses verifikasi dan validasi kepada pelanggan terhadap
spesifikasi kebutuhan yang telah disusun

Laporan Resmi
Dari hasil elisitasi dengan customer, susun laporan berbentuk tabulasi dengan
kolom-kolom sbb :
No
Nama
Kode
Deskripsi
Prioritas

Fungsional Requirement (pada aplikasi e-Futsal)