1.

Requirements Engineering
Merancang dan membangun perangkat lunak komputer merupakan tantangan yang
menantang, kreatif, dan menyenangkan. Bahkan, membangun perangkat lunak begitu
menarik sehingga banyak pengembang perangkat lunak ingin segera terlibat tanpa
pemahaman yang jelas tentang apa yang diperlukan. Mereka berargumen bahwa hal-
hal akan menjadi jelas seiring dengan pembangunan, bahwa para pemangku
kepentingan proyek hanya akan dapat memahami kebutuhan setelah mengamati
iterasi awal perangkat lunak, bahwa segalanya berubah begitu cepat sehingga upaya
untuk memahami kebutuhan secara rinci adalah pemborosan waktu, bahwa inti dari
segalanya adalah menghasilkan program yang berfungsi dan segala yang lain menjadi
sekunder. Hal yang membuat argumen tersebut menarik adalah bahwa mereka
mengandung elemen-elemen kebenaran. Namun, setiap argumen tersebut memiliki
kekurangan dan dapat mengakibatkan proyek perangkat lunak gagal.

Rentang tugas dan teknik yang luas yang mengarah pada pemahaman kebutuhan
disebut rekayasa kebutuhan. Dari perspektif proses perangkat lunak, rekayasa
kebutuhan adalah tindakan utama dalam rekayasa perangkat lunak yang dimulai
selama aktivitas komunikasi dan berlanjut ke dalam aktivitas pemodelan. Ini harus
disesuaikan dengan kebutuhan dari proses, proyek, produk, dan orang-orang yang
melakukan pekerjaan.Orang lain mungkin menyarankan bahwa jembatan dimulai
dengan definisi sistem yang lebih luas, di mana perangkat lunak hanya merupakan
satu komponen dari domain sistem yang lebih besar. Tetapi terlepas dari titik awalnya,
perjalanan melintasi jembatan membawa Anda tinggi di atas proyek, memungkinkan
Anda untuk memeriksa konteks dari pekerjaan perangkat lunak yang akan dilakukan;
kebutuhan spesifik yang harus diatasi oleh desain dan konstruksi; prioritas yang
mengarahkan urutan penyelesaian pekerjaan; dan informasi, fungsi, serta perilaku
yang akan memiliki dampak yang signifikan pada desain yang dihasilkan. Ini
mencakup tujuh tugas yang berbeda: perintisan, pengungkapan, elaborasi, negosiasi,
spesifikasi, validasi, dan manajemen. Penting untuk dicatat bahwa beberapa dari
tugas-tugas ini terjadi secara bersamaan dan semuanya disesuaikan dengan kebutuhan
proyek.

1) Perintisan
Dalam beberapa kasus, percakapan informal sudah cukup untuk memicu
upaya rekayasa perangkat lunak yang besar. Tetapi secara umum, kebanyakan
proyek dimulai ketika sebuah kebutuhan bisnis diidentifikasi atau potensi
pasar atau layanan baru ditemukan. Para pemangku kepentingan dari
komunitas bisnis (misalnya, manajer bisnis, orang-orang pemasaran, manajer
produk) mendefinisikan alasan bisnis untuk ide tersebut, mencoba
mengidentifikasi luas dan kedalaman pasar, melakukan analisis kelayakan
kasar, dan mengidentifikasi deskripsi kerja dari cakupan proyek. Semua
informasi ini dapat berubah, tetapi sudah cukup untuk memicu diskusi dengan
organisasi rekayasa perangkat lunak. Pada perintisan proyek, Anda
membentuk pemahaman dasar tentang masalahnya, orang-orang yang
menginginkan solusi, sifat solusi yang diinginkan, dan efektivitas komunikasi
 dan kolaborasi awal antara pemangku kepentingan lainnya dan tim perangkat
lunak.
2) Pengungkapan
Pada pandangan pertama, ini tampak cukup sederhana—bertanya kepada
pelanggan, pengguna, dan orang lain mengenai tujuan sistem atau produk, apa
yang harus dicapai, bagaimana sistem atau produk tersebut memenuhi
kebutuhan bisnis, dan terakhir, bagaimana sistem atau produk tersebut
digunakan dalam kegiatan sehari-hari.
 Masalah cakupan
Batas sistem kurang jelas atau pelanggan/pengguna menentukan detail
teknis yang tidak perlu yang mungkin membingungkan, bukan
mengklarifikasi, tujuan keseluruhan sistem.
 Masalah pemahaman
Pelanggan/pengguna tidak sepenuhnya yakin dengan apa yang
dibutuhkan, memiliki pemahaman yang buruk tentang kemampuan dan
batasan lingkungan komputasi mereka, tidak memiliki pemahaman
penuh tentang domain masalah, kesulitan dalam berkomunikasi
kebutuhan kepada insinyur sistem, mengabaikan informasi yang
dianggap "jelas", menentukan persyaratan yang bertentangan dengan
kebutuhan pelanggan/pengguna lainnya, atau menentukan persyaratan
yang ambigu atau tidak dapat diuji.
 Masalah volatilitas
Persyaratan berubah seiring waktu.
Untuk membantu mengatasi masalah-masalah ini, Anda harus
mendekati pengumpulan persyaratan secara terorganisir.

3) Elaborasi
Informasi yang diperoleh dari pelanggan selama perintisan dan pengungkapan
diperluas dan disempurnakan selama elaborasi. Elaborasi didorong oleh
penciptaan dan penyempurnaan skenario pengguna yang menjelaskan
bagaimana pengguna akhir (dan aktor lainnya) akan berinteraksi dengan
sistem. Setiap skenario pengguna dipilah untuk mengekstrak kelas analisis—
entitas domain bisnis yang terlihat oleh pengguna akhir. Atribut dari setiap
kelas analisis didefinisikan, dan layanan yang diperlukan oleh setiap kelas
diidentifikasi. Hubungan dan kolaborasi antar kelas diidentifikasi, dan
berbagai diagram tambahan diproduksi.

4) Negosiasi
Tidak jarang bagi pelanggan dan pengguna untuk meminta lebih dari yang
dapat dicapai, mengingat sumber daya bisnis yang terbatas. Juga relatif umum
bagi pelanggan atau pengguna yang berbeda untuk mengusulkan persyaratan
yang bertentangan, dengan alasan bahwa versi mereka "penting untuk
kebutuhan khusus kami." Kita harus mendamaikan konflik-konflik ini melalui
proses negosiasi. Pelanggan, pengguna, dan pemangku kepentingan lain
diminta untuk memberi peringkat pada persyaratan, lalu mendiskusikan
konflik dalam prioritasnya. Dengan menggunakan pendekatan iteratif yang
 memprioritaskan persyaratan, menilai biaya dan risikonya, serta menangani
konflik internal, persyaratan dieliminasi, digabungkan, dan/atau dimodifikasi
sehingga setiap pihak mencapai sebagian kepuasan.

5) Spesifikasi
Dalam konteks sistem berbasis komputer (dan perangkat lunak), istilah
spesifikasi memiliki arti yang berbeda bagi setiap orang. Sebuah spesifikasi
bisa berupa dokumen tertulis, serangkaian model grafis, model matematika
formal, kumpulan skenario penggunaan, sebuah prototipe, atau kombinasi dari
hal-hal tersebut.

6) Validasi
Produk kerja yang dihasilkan sebagai hasil dari rekayasa kebutuhan dievaluasi
untuk kualitasnya selama tahap validasi. Validasi kebutuhan memeriksa
spesifikasi untuk memastikan bahwa semua persyaratan perangkat lunak telah
dinyatakan secara jelas; bahwa inkonsistensi, kelalaian, dan kesalahan telah
terdeteksi dan diperbaiki; dan bahwa produk kerja sesuai dengan standar yang
ditetapkan untuk proses, proyek, dan produk tersebut.

7) Manajemen kebutuhan
Kebutuhan untuk sistem berbasis komputer dapat berubah, dan keinginan
untuk mengubah kebutuhan tetap ada sepanjang masa hidup sistem tersebut.
Manajemen kebutuhan adalah serangkaian kegiatan yang membantu tim
proyek mengidentifikasi, mengendalikan, dan melacak kebutuhan serta
perubahan pada kebutuhan kapan pun saat proyek berlangsung. Banyak dari
kegiatan ini identik dengan manajemen konfigurasi perangkat lunak.

2. Landasan Dasar
Dalam suasana yang ideal, para pemangku kepentingan dan insinyur perangkat lunak
bekerja bersama dalam tim yang sama. Dalam kasus seperti itu, rekayasa kebutuhan
hanya merupakan masalah berkomunikasi dengan kolega yang merupakan anggota
tim yang sudah dikenal dengan baik. Namun, kenyataannya seringkali jauh berbeda.

Pelanggan atau pengguna akhir mungkin berada di kota atau negara yang berbeda,
mungkin hanya memiliki gambaran samar tentang apa yang dibutuhkan, mungkin
memiliki pendapat yang bertentangan mengenai sistem yang akan dibangun, mungkin
memiliki pengetahuan teknis yang terbatas, dan mungkin memiliki waktu terbatas
untuk berinteraksi dengan insinyur kebutuhan. Tidak ada dari hal-hal ini yang
diinginkan, tetapi semuanya cukup umum, dan seringkali Anda terpaksa bekerja
dalam batasan yang diberlakukan oleh situasi ini.

Pada bagian-bagian berikutnya, saya akan membahas langkah-langkah yang

diperlukan untuk menyiapkan dasar pemahaman mengenai kebutuhan perangkat lunak
—untuk memulai proyek dengan cara yang akan menjaga proyek bergerak maju
menuju solusi yang berhasil.
a) Mengidentifikasi Pemangku Kepentingan
Pada awal perintisan, Anda sebaiknya membuat daftar orang-orang yang akan
memberikan masukan saat kebutuhan diungkapkan (Bagian 5.3). Daftar awal
ini akan bertambah karena pemangku kepentingan dihubungi karena setiap
pemangku kepentingan akan ditanyai.
b) Mengenali Sudut Pandang yang Beragam
Karena ada banyak pemangku kepentingan yang berbeda, kebutuhan sistem
akan dieksplorasi dari berbagai sudut pandang. Sebagai contoh, kelompok
pemasaran tertarik pada fungsi dan fitur yang akan menarik pasar potensial,
membuat sistem baru mudah untuk dijual. Manajer bisnis tertarik pada
rangkaian fitur yang dapat dibangun dalam anggaran dan siap untuk
memenuhi jendela pasar yang ditentukan. Pengguna akhir mungkin
menginginkan fitur yang familiar bagi mereka dan mudah untuk dipelajari dan
digunakan. Insinyur perangkat lunak mungkin memperhatikan fungsi yang
tidak terlihat oleh pemangku kepentingan non-teknis tetapi memungkinkan
infrastruktur yang mendukung fungsi dan fitur yang lebih dapat dipasarkan.
Insinyur dukungan mungkin fokus pada kemudahan pemeliharaan perangkat
lunak.
c) Bergerak Menuju Kolaborasi
Jika ada lima pemangku kepentingan yang terlibat dalam proyek perangkat
lunak, Anda mungkin memiliki lima (atau lebih) pendapat yang berbeda
tentang rangkaian kebutuhan yang tepat. Sepanjang bab-bab sebelumnya, saya
telah mencatat bahwa pelanggan (dan pemangku kepentingan lainnya) harus
berkolaborasi di antara mereka sendiri (menghindari pertempuran kepentingan
yang tidak penting) dan dengan praktisi rekayasa perangkat lunak jika ingin
menghasilkan sistem yang berhasil. Tugas seorang insinyur kebutuhan adalah
mengidentifikasi area kesamaan (yaitu, kebutuhan di mana semua pemangku
kepentingan setuju) dan area konflik atau inkonsistensi (yaitu, kebutuhan yang
diinginkan oleh satu pemangku kepentingan tetapi bertentangan dengan
kebutuhan pemangku kepentingan lainnya). Tentu saja, kategori terakhirlah
yang menimbulkan tantangan.

d) Bertanya pada Pertanyaan Awal

Pertanyaan yang diajukan pada awal proyek sebaiknya "bebas konteks".
Serangkaian pertanyaan bebas konteks pertama difokuskan pada pelanggan
dan pemangku kepentingan lainnya, tujuan proyek secara keseluruhan, dan
manfaatnya. Misalnya, Anda dapat bertanya:
• Siapa yang menginisiasi permintaan untuk pekerjaan ini?
• Siapa yang akan menggunakan solusi ini?
• Apa manfaat ekonomi dari solusi yang berhasil?
• Adakah sumber lain untuk solusi yang Anda butuhkan?

Pertanyaan-pertanyaan ini membantu mengidentifikasi semua pemangku

kepentingan yang akan memiliki minat dalam perangkat lunak yang akan
dibangun.
Serangkaian pertanyaan selanjutnya memungkinkan Anda untuk memperoleh
pemahaman yang lebih baik tentang masalah dan memungkinkan pelanggan
untuk mengungkapkan persepsi mereka tentang solusi:
 Bagaimana Anda menggambarkan hasil "baik" yang akan dihasilkan
oleh solusi yang berhasil?
 Masalah apa yang akan diatasi oleh solusi ini?
 Bisakah Anda menunjukkan kepada saya (atau menjelaskan)
lingkungan bisnis di mana solusi ini akan digunakan?
 Apakah ada masalah kinerja khusus atau kendala yang akan
memengaruhi pendekatan terhadap solusi?
Serangkaian pertanyaan terakhir berfokus pada efektivitas dari aktivitas
komunikasi itu sendiri. Gause dan Weinberg [Gau89] menyebutnya sebagai
"meta-pertanyaan" dan mengusulkan daftar berikut (yang disingkat):
 Apakah Anda orang yang tepat untuk menjawab pertanyaan-pertanyaan
ini? Apakah jawaban Anda "resmi"?
 Apakah pertanyaan-pertanyaan saya relevan dengan masalah yang
Anda hadapi?
 Apakah saya terlalu banyak bertanya?
 Apakah ada orang lain yang bisa memberikan informasi tambahan?
 Apakah seharusnya saya menanyakan hal lain kepada Anda?
Pertanyaan-pertanyaan ini (dan lainnya) akan membantu "memecah kebekuan"
dan memulai komunikasi yang sangat penting untuk pengungkapan yang
berhasil. Namun, format pertanyaan dan jawaban dalam rapat bukanlah
pendekatan yang secara luar biasa berhasil.