Halaman 3

Huzooree et al., Jurnal Internasional Penelitian Lanjut dalam Ilmu Komputer dan Rekayasa Perangkat Lunak 5 (2),
Februari - 2015, hlm. 40-46
© 2015, IJARCSSE Semua Hak Dilindungi
Halaman | 42
4) Tidak ada praktik yang baik untuk dokumentasi. Harus ada beberapa proses hemat biaya hingga persyaratannya
dapat diperiksa baik melalui pengujian manual atau alat otomatis, sehingga memastikan persyaratannya sesuai
dengan spesifikasi yang ditentukan.
5) Validasi persyaratan yang tidak efektif . Persyaratan terkadang divalidasi oleh pemangku kepentingan yang salah pada klien
sisi karena tidak tersedianya pemangku kepentingan yang diperlukan. Implementasi persyaratan yang tidak valid ini
menyebabkan pengerjaan ulang
dalam jangka panjang.
AKU AKU AKU. METODOLOGI
A. Teknik Pengumpulan Data
Untuk tujuan penelitian ini, data pada empat fase rekayasa kebutuhan dikumpulkan melalui survei
dari enam organisasi proyek pengembangan perangkat lunak yang berlokasi di Mauritius untuk memberikan pandangan praktis
tentang
tantangan yang diidentifikasi selama tinjauan literatur. Analisis akar-penyebab sederhana dari tantangan yang dijumpai di
keempatnya
fase-fase rekayasa persyaratan mengungkapkan solusi-solusi kunci tentang bagaimana masalah-masalah ini dapat diatasi untuk
menjembatani kesenjangan
antara proses dan praktik ET.
B. Hipotesis Dinamis H 1 : Kesenjangan antara proses dan praktik rekayasa kebutuhan
Penelitian telah melibatkan banyak masalah dan tantangan yang ada di setiap proses rekayasa persyaratan. Ini
makalah menggunakan data survei dari organisasi untuk mengidentifikasi kesenjangan yang ada antara teori dan praktik.
IV. R ESULTS DAN D ISCUSSION
A. Persyaratan Penggusuran
Menurut hasil survei pada Gambar. 1, sebagian besar organisasi menghadapi masalah elisitasi persyaratan
termasuk sistem yang tidak jelas dengan informasi yang tidak relevan atau tidak lengkap, kebingungan di antara para pemangku
kepentingan dimana
pengguna tidak yakin akan kebutuhannya dan analis tidak memiliki pengetahuan domain. Selain itu, evolusi berkelanjutan sering
mengarah pada
berbagai eskalasi dan keluhan tentang kurangnya kemajuan. Masalah besar lain muncul ketika pemangku kepentingan utama
ditinggalkan
keterlibatan klien rendah. Semua masalah ini menghasilkan konsekuensi yang mahal dan sulit untuk diperbaiki, dan
pada akhirnya dapat merusak proyek.
Gambar. 1 Hasil survei untuk masalah elisitasi persyaratan
Solusi yang diajukan dari masalah elisitasi persyaratan dijelaskan pada Tabel I.
TABEL I SOLUSI YANG DIUSULKAN UNTUK PERSYARATAN ISU ELISITASI
Masalah
Solusi yang diajukan
1 Masalah ruang lingkup
Memiliki pengetahuan domain yang baik dan tujuan yang tepat dari sistem akan berkurang
masalah ruang lingkup.
2 Kebingungan pemangku kepentingan Memanfaatkan bahasa alami selama semua komunikasi akan membantu untuk
menghindari
kebingungan pemangku kepentingan. Selain itu, pengumpulan kebutuhan biji-bijian kasar dan biji-bijian halus
model dapat digunakan untuk memberi para pemangku kepentingan pandangan tingkat tinggi dan rendah
demikian.
3 Volatilitas persyaratan Sistem manajemen persyaratan akan menguntungkan dengan melacak semua
persyaratan berubah dan mempertahankan keterlacakan.
4 Identifikasi
dari
pemangku kepentingan
Pastikan pemangku kepentingan yang sama hadir dari awal hingga akhir ET
proses selama setiap fase di mana mereka diperlukan. Apalagi kolaborasi harus
dipastikan antara kedua belah pihak sebelum melakukan pertemuan apapun mengenai
persyaratan dan spesifikasi.

Halaman 4
Huzooree et al., Jurnal Internasional Penelitian Lanjut dalam Ilmu Komputer dan Rekayasa Perangkat Lunak 5 (2),
Februari - 2015, hlm. 40-46
© 2015, IJARCSSE Semua Hak Dilindungi
Halaman | 43
5 Kurangnya pemangku kepentingan
keterlibatan
Pertemuan rutin dengan kesepakatan dan keterlibatan manajemen puncak akan
memungkinkan para pemangku kepentingan untuk terlibat dan berpartisipasi dalam pertemuan tersebut. Mencoba
jadwal rapat jauh hari sebelumnya akan memastikan para pemangku kepentingan dialokasikan bersama
waktu yang tepat untuk rapat.
6 Tidak efektif
elisitasi persyaratan
Manajemen harus menghargai pentingnya teknik pengumpulan yang tepat
bahwa mereka dapat diintegrasikan dalam anggaran proyek. Tak satu pun dari organisasi itu
saat ini sedang melakukan pertemuan arsitektur, yang mengarah ke banyak celah dalam pengembangan
proses, sehingga tim persyaratan arsitektur yang baik akan membantu mengurangi
tingkat kerumitan seluruh sistem. Misalnya dengan membuat para pemangku kepentingan
mengisi kuesioner, arsitek akan dapat saling tukar menukar
Persyaratan.
B. Analisis Kebutuhan dan Negosiasi
Hasil survei pada Gambar. 2 menyoroti bahwa insinyur persyaratan memiliki waktu yang sangat sulit untuk memperluas dan
memahami
Persyaratan. Sangat sering, ada masalah konsep yang berbeda dengan persyaratan yang sama antara kontraktor dan
organisasi kontraktor dan insinyur kebutuhan harus menyelidiki lebih dalam untuk mengekstraksi visi klien yang sangat
memakan waktu. Karena tekanan tenggat waktu, insinyur persyaratan harus menganalisis persyaratan dengan cepat untuk
melanjutkan
dengan perkembangan dan akibatnya ada rencana risiko yang tidak lengkap atau tidak ada dalam organisasi. Selain itu, analisis
dan
negosiasi sering dipandang sebagai proses yang sulit karena kesenjangan komunikasi dan kekurangan keterampilan. Terkadang
ada celah
dalam hal pengetahuan domain, istilah teknis atau keterampilan negosiasi selama penyelesaian konflik. Seringkali klien juga
enggan memprioritaskan persyaratan karena mereka khawatir bahwa pengembang akan secara otomatis membatasi proyek ke
item prioritas tertinggi dan yang lainnya tidak akan pernah diterapkan.
2 Hasil survei untuk analisis kebutuhan dan masalah negosiasi
Solusi yang diusulkan dari analisis persyaratan dan masalah negosiasi dijelaskan pada Tabel II.
TABEL II SOLUSI YANG DIUSULKAN UNTUK ANALISIS PERSYARATAN DAN ISU NEGOSIASI
Masalah
Solusi yang diajukan
1 Persyaratan
penentuan prioritas
Manajemen harus memastikan bahwa persyaratan diselaraskan dengan persyaratan bisnis utama
dan tujuan dengan menggunakan skala prioritas untuk menentukan kategori prioritas yang jelas
mempromosikan klasifikasi yang konsisten.
2 Penilaian risiko Manajemen harus memastikan bahwa rencana risiko dibuat dan terus diperbarui untuk memberikan
strategi mitigasi untuk risiko yang diidentifikasi atau baru jika terjadi perubahan persyaratan.
3 Kekurangan keterampilan
Manajemen harus memastikan bahwa hanya insinyur kebutuhan yang terampil, berpengalaman dan terlatih
terlibat dalam proses pengumpulan persyaratan. Persyaratan tim insinyur bisa
terdiri dari orang-orang dengan beragam persepsi atau posisi yang berbeda sehingga mereka bisa lebih
strategis dan dinamis.
4 Komunikasi
masalah
Manajemen harus memberdayakan insinyur kebutuhan dengan pelatihan yang tepat dan efektif
keterampilan komunikasi, teknis, dan negosiasi untuk dapat menyelesaikan konflik di antara keduanya
berbagai pemangku kepentingan dengan pandangan berbeda dengan secara kritis menunjukkan kepada mereka kemungkinan
manfaat dan manfaatnya
pentingnya pilihan mereka.
5 Batasan waktu Beberapa insinyur kebutuhan harus memiliki sesi curah pendapat dalam interval reguler ke
memastikan pemahaman yang baik dan prioritas persyaratan dalam jangka waktu yang lebih pendek.

Halaman 5
Huzooree et al., Jurnal Internasional Penelitian Lanjut dalam Ilmu Komputer dan Rekayasa Perangkat Lunak 5 (2),
Februari - 2015, hlm. 40-46
© 2015, IJARCSSE Semua Hak Dilindungi
Halaman | 44
6 Tidak jelas
Persyaratan
Harus dipastikan bahwa semua persyaratan yang dikumpulkan tidak ambigu dengan menghindari secara intrinsik
kata-kata subjektif dan ambigu. Tim yang baik dengan sudut pandang berbeda harus secara formal
memeriksa persyaratan untuk memastikan mereka lengkap, konsisten dan dapat diverifikasi. Mereka bisa
juga menggunakan meta-model untuk membuat persyaratan lebih nyata.
C. Spesifikasi Persyaratan
Seperti yang ditunjukkan pada Gambar. 3, semua organisasi sepakat bahwa tidak ada metode definisi persyaratan yang tepat sejak
itu
pemangku kepentingan masih menggunakan email untuk membagikan persyaratan yang diperbarui. Akibatnya, beberapa
organisasi berbagi di sana
adalah versi dokumen SRS yang ketinggalan zaman yang mengecualikan pembaruan. Akibatnya, ada persyaratan yang salah
karena mereka tidak ditinjau dengan benar sesuai dengan standar karena keterbatasan waktu. Ini akhirnya menghasilkan
pelacakan
masalah dan implementasi yang salah.
Gbr. 3 Hasil survei untuk masalah spesifikasi kebutuhan
Solusi yang diusulkan dari masalah spesifikasi kebutuhan dijelaskan pada Tabel III.
TABEL III SOLUSI YANG DIUSULKAN UNTUK ISU SPESIFIKASI PERSYARATAN
Masalah
Solusi yang diajukan
1 Persyaratan
definisi
Panduan dan prosedur yang tepat seperti kerangka Model Kemampuan Maturitas
Integrasi (CMMI) dapat membantu untuk mendefinisikan dan memelihara persyaratan. Memperkenalkan ulasan tentang
dokumen dalam organisasi akan membantu meminimalkan risiko kesalahan dan ambiguitas.
2 Persyaratan
pemeliharaan
Alat manajemen konfigurasi akan sangat membantu untuk menggambarkan standar dan
prosedur yang dapat digunakan untuk mengendalikan perubahan dalam dokumen spesifikasi persyaratan.
Selain itu, repositori pusat file dapat digunakan untuk mencegah masalah versi dan
memfasilitasi keterlacakan.
3 salah
Persyaratan
Dengan menegakkan standar yang tepat untuk membuat pengembang sadar akan pentingnya memiliki
dokumen yang tepat akan membuatnya lebih mudah untuk dikelola.
D. Validasi Persyaratan
Hasil survei pada Gambar. 4 menunjukkan bahwa organisasi masih menghadapi persyaratan yang tidak lengkap dan ambigu
pada tahap validasi karena teknik validasi tidak efektif dan kurangnya dokumentasi SRS yang tepat untuk melacak
perubahan yang terjadi dalam persyaratan. Akibatnya, masih ada persyaratan yang tidak konsisten dan pengujian persyaratan
menjadi sangat kompleks karena meningkatnya ambiguitas.
Gambar. 4 Hasil survei untuk masalah validasi persyaratan

Halaman 6
Huzooree et al., Jurnal Internasional Penelitian Lanjut dalam Ilmu Komputer dan Rekayasa Perangkat Lunak 5 (2),
Februari - 2015, hlm. 40-46
© 2015, IJARCSSE Semua Hak Dilindungi
Halaman | 45
Solusi yang diajukan dari masalah validasi persyaratan dijelaskan pada Tabel IV.
TABEL IV SOLUSI YANG DIUSULKAN UNTUK ISU VALIDASI PERSYARATAN
Masalah
Solusi yang diajukan
1 Persyaratan tidak efektif
validasi
Manajemen yang lebih tinggi harus lebih menekankan pada masalah kritis ini untuk mengalokasikan
pemangku kepentingan yang sesuai untuk memvalidasi spesifikasi persyaratan.
2 Tidak ada latihan yang baik untuk
dokumentasi
Sangat penting untuk membuat dokumentasi untuk persyaratan yang efektif
manajemen untuk menangani persyaratan yang tidak stabil dan untuk mempertahankan persyaratan
keterlacakan untuk menghapus persyaratan yang ambigu dan tidak konsisten.
3 Hasil tes yang tidak dapat diverifikasi
Dengan memastikan bahwa ada beberapa proses hemat biaya hingga
persyaratan dapat diperiksa baik melalui pengujian manual atau alat otomatis
memastikan bahwa persyaratan sesuai dengan spesifikasi yang ditentukan.
Selain itu, pengalaman masa lalu dapat membantu menentukan dampak pada hal tertentu
komponen.
4 Persyaratan yang tidak konsisten Membuat dokumen ditinjau oleh orang yang berbeda dan membandingkan umpan balik
mereka
akan menemukan dan menghindari ketidakkonsistenan yang dapat menyebabkan konflik.
5 Tidak lengkap dan
persyaratan ambigu
Ulasan rekan, skenario, dan walk-through selama elisitasi persyaratan
proses akan membantu menyelesaikan banyak persyaratan yang tidak lengkap dan tidak jelas
dari awal sehingga memudahkan proses validasi.
V. C PENGECUALIAN DAN F UTURE W ORK
Rekayasa kebutuhan memainkan peran utama dalam pengembangan perangkat lunak karena secara langsung berbanding lurus
dengan perangkat lunak
kualitas, profitabilitas, dan kepuasan klien. Survei literatur menyoroti bahwa setiap proses ET wajib untuk dipastikan
pengembangan perangkat lunak yang sukses. Namun, persyaratan insinyur mengklaim bahwa RE sangat menantang dan
kompleks
tugas untuk mengumpulkan persyaratan yang tepat karena berbagai masalah yang berasal dari empat proses utama yang diuraikan
dalam ini
penelitian. Tujuan dari makalah ini adalah untuk menggambarkan bagaimana proses RE dilakukan di berbagai organisasi
mengidentifikasi masalah yang dihadapi dalam praktik. Hasil survei menyoroti kesenjangan besar antara teori dan praktik.
Masalah sebagian besar berasal dari masalah yang berkaitan dengan kebingungan ruang lingkup proyek, keterlibatan pemangku
kepentingan yang tidak memadai,
keterampilan komunikasi dan negosiasi, teknik yang tidak efektif, kendala waktu, dokumentasi yang tidak tepat, dan kurangnya
manajemen persyaratan, persyaratan yang tidak diprioritaskan, persyaratan yang ambigu dan tidak konsisten. Namun,
penyelesaiannya
masalah-masalah ini pada tahap tertentu diperlukan untuk pengembangan yang sukses dari penerapan persyaratan perangkat
lunak.
Jadi makalah ini telah mengusulkan berbagai solusi yang masuk akal untuk menjembatani kesenjangan antara proses RE dalam
teori dan praktik
untuk memastikan tingkat kualitas perangkat lunak, profitabilitas bisnis, dan kepuasan klien setinggi mungkin. Satu prinsip utama
makalah ini adalah untuk melibatkan manajemen yang lebih tinggi dan pemangku kepentingan utama dalam sebagian besar
keputusan untuk memastikan proses ET lebih
ahli. Sebagai pekerjaan masa depan, solusi yang diusulkan dapat diimplementasikan untuk memantau perubahan dalam proses
ET.
R EFERENSI
[1]
D. Pandey, U. Suman, dan A. Ramani, Model Proses Rekayasa Kebutuhan yang Efektif untuk Perangkat Lunak
Pengembangan dan Manajemen Persyaratan , dalam Kemajuan Teknologi Terkini dalam Komunikasi dan
Computing (ARTCom), Konferensi Internasional 2010 pada, 2010, hlm. 287–291.
[2]
J. Siddiqi, MC Shekaran, Rekayasa persyaratan: kebijaksanaan yang muncul , IEEE Software 13 (2) (1996) 15–
19.
[3]
H. Kaindl et al., Rekayasa Kebutuhan dan Alih Teknologi: Hambatan dan Insentif , Persyaratan
Eng., Vol. 7, tidak. 3, 2002, hlm. 113–223.
[4]
A. van Lamsweerde, R. Darimont, E. Letier, Mengelola Konflik dalam Rekayasa Persyaratan yang Digerakkan oleh Tujuan ,
Transaksi IEEE pada Rekayasa Perangkat Lunak, November 1998, 908-926.
[5]
G. Kotonya, I.Sommerville, Rekayasa kebutuhan dengan sudut pandang , BCS / IEE Software Engineering J., vol.
11, tidak. 1, 1996, hlm. 5–18.
[6]
M. Christel dan K. Kang, Masalah dalam Persyaratan Elicitation , Carnegie Mellon University, Pittsburgh September
1992.
[7]
J. Bhat, M. Gupta, dan SN Murthy, Mengatasi Tantangan Teknik Persyaratan: Pelajaran dari
Offshore Outsourcing , Perangkat Lunak IEEE, 2006, hlm. 3844.
[8]
JA McDermid , Analisis kebutuhan: masalah dan pendekatan STARTS , di: IEEE Colloquium on
Persyaratan Pengambilan dan Spesifikasi untuk Sistem Kritis (Intisari 138), IEEE, 1989, hlm. 4 / 1-4–4 / 4.
[9]
P.Rajagopal, R.Lee, Thomas Ahlswede, Chia-Chu Chiang, D. Karolak, Pendekatan Baru untuk Perangkat Lunak
Persyaratan Elicitation , Prosiding Konferensi Internasional IEEE ke-6 tentang Rekayasa Perangkat Lunak,
Intelegensi Buatan, Jaringan dan Komputasi Paralel / Terdistribusi, 2005.
[10]
S. Asghar dan M. Umar, Tantangan Rekayasa Kebutuhan dalam Pengembangan Aplikasi Perangkat Lunak dan
Pemilihan Komponen Pelanggan (COTS) , Jurnal Internasional Rekayasa Perangkat Lunak (IJSE),
vol. 1, tidak. 2, hal. 32, 2010.
[11]
K. Wiegers, Karl Wiegers, Menjelaskan 10 Persyaratan Perangkap yang Harus Dihindari , Pengujian dan Kualitas Perangkat
Lunak, Vol.
2, tidak. 1, 2000.

Halaman 7
Huzooree et al., Jurnal Internasional Penelitian Lanjut dalam Ilmu Komputer dan Rekayasa Perangkat Lunak 5 (2),
Februari - 2015, hlm. 40-46
© 2015, IJARCSSE Semua Hak Dilindungi
Halaman | 46
[12]
H. Sharp, GH Galal, dan A. Finkelstein, Identifikasi Pemangku Kepentingan dalam Proses Rekayasa Persyaratan ,
Proc 10 Int'l Workshop Database dan Aplikasi Sistem Pakar, IEEE CS Press, 1999, hlm. 387–391.
[13]
B. Curtis, H. Krasner dan N. Iscoe, Studi Lapangan Proses Desain Perangkat Lunak untuk Sistem Besar ,
Komunikasi ACM, 31 (11), 1988, hlm. 1268-1287.
[14]
Al-Rawas, A., S. Easterbrook, Masalah komunikasi dalam rekayasa persyaratan: Studi lapangan , 1
Konferensi Westminster tentang Kesadaran Profesional dalam Rekayasa Perangkat Lunak, London, Inggris, 1996.
[15]
S. Ahmad, Negosiasi dalam Persyaratan Elicitation dan Proses Analisis , Prosiding IEEE ke-19
Konferensi Australia tentang Rekayasa Perangkat Lunak, 2008, hlm. 683-689.
[16]
T. Eushiuan, Persyaratan dan Spesifikasi , 1999.
[17]
R. Rowen, Manajemen Proyek Perangkat Lunak di bawah Spesifikasi Tidak Lengkap dan Ambigu , IEEE Trans. Eng
Manajemen, vol. 37, tidak. 1, 1990, hlm. 10–21.
[18]
B. Nuseibeh dan S. Easterbrook, Rekayasa Kebutuhan: Peta Jalan , Masa Depan Rekayasa Perangkat Lunak,
Int'l Conf. 22. Perangkat Lunak Bahasa Indonesia, ACM Press, 2000, hlm. 3546.
[19]
I.ook, Menulis persyaratan yang baik , Proc. Dari Simposium Internasional Keempat dari NCOSE, 1994, Vol. 2.,
hlm. 197-203
[20]
B. Boehm, A. Egyed, WinWin Persyaratan Proses Negosiasi: Analisis Multi-Proyek , Prosiding
Konferensi Internasional ke-5 tentang Proses Perangkat Lunak, 1998
[21]
B.Palyagar dan F. Moisiadis, Memvalidasi Persyaratan Peningkatan Proses Rekayasa - Studi Kasus , IEEE
Visualisasi Rekayasa Persyaratan, 2006. REV '06. Lokakarya Internasional Pertama tentang Persyaratan
visualisasi teknik, Washington, DC, USA, 2006.