A Case Study in Requirements Engineering in

Context of Agile

Vandana Gaikwad1* and Prasanna Joeg2

1,2
Computer Engineering Department,
Bharati Vidyapeeth Deemed University College of Engineering, Pune, 411043, India

Abstrak
Requirements Engineering (RE) in agile adalah proses evolusioner yang melibatkan keterlibatan
pelanggan aktif, perencanaan berkelanjutan, prioritas ulang kebutuhan dan validasi melalui
pengiriman produk tambahan. Makalah ini menjelaskan studi kasus dalam rekayasa persyaratan
dalam konteks tangkas. Secara khusus, studi ini menyelidiki tantangan dan praktik terbaik dalam
RE tangkas dan menunjukkan bagaimana RE tangkas terjadi di lima perusahaan produk
perangkat lunak. Lebih lanjut, makalah ini menjelaskan pendekatan baru untuk mempelajari
praktik RE tangkas berdasarkan perbedaan dalam model bisnis, di mana pelanggan akhir adalah
entitas bisnis versus konsumen.

Kata kunci: Agile; Persyaratan teknik; Cerita pengguna; Pemilik produk;

PENGANTAR
Requirements engineering (RE) dalam definisi yang paling sederhana adalah proses menentukan
harapan pengguna akhir dari bagaimana perangkat lunak harus berfungsi untuk mencapai tujuan
yang dimaksudkan bagi pengguna. Proses tersebut terdiri dari pengumpulan kebutuhan, analisis,
validasi dan manajemen [1]. RE dianggap sebagai salah satu fase paling kritis dalam proyek
perangkat lunak [2]. Rekayasa persyaratan yang diterapkan dengan buruk merupakan risiko
utama kegagalan proyek [3]. Selain itu, dalam konteks agile RE adalah proses berkelanjutan di
mana persyaratan akan berkembang selama iterasi tangkas, tidak seperti waterfall di mana RE
diselesaikan sebelum implementasi dan perubahan persyaratan dinegosiasikan dengan pelanggan
melalui proses manajemen perubahan. Beberapa penelitian lain [4] [5] [6] yang menyoroti
tantangan ET tradisional adalah: kurangnya keterlibatan pelanggan, persyaratan pelingkupan,
dokumentasi persyaratan, dan masalah komunikasi.
Namun, studi terbaru [7] [8] [9] menunjukkan bagaimana praktik RE yang gesit [10]:
keterlibatan pelanggan, perencanaan berkelanjutan, uji penerimaan, prioritas persyaratan,
pemodelan persyaratan, dan komunikasi tatap muka menyelesaikan tantangan ET tradisional.
Selain itu, tantangan [10] [13] yang ditimbulkan oleh praktik RE yang tangkas itu sendiri adalah:
dokumentasi minimal, ketidaktersediaan pelanggan, mengabaikan persyaratan non-fungsional,
verifikasi persyaratan yang tidak memadai, dan ketidakmampuan pelanggan. Namun, solusi di
seluruh tantangan ini dilaporkan dalam studi lain, seperti: cerita pengguna berorientasi '' tujuan
pengguna '' [9], pembuatan cerita pengiriman untuk menyertai cerita pengguna [14], pelanggan
pengganti [13] dan RE berulang [13 ].
Di sisi lain, studi terbaru [15] merekomendasikan lebih banyak penelitian empiris diperlukan
untuk lebih memahami bagaimana RE yang tangkas terjadi. Melalui studi kasus kami, kami telah
menjangkau praktisi perangkat lunak yang terlibat dalam proyek tangkas untuk memahami
bagaimana RE dipraktikkan dalam konteks gesit di mana persyaratan bersifat evolusioner dan
didorong oleh pengiriman berkelanjutan perangkat lunak yang berharga.
Selain itu, kami telah mengkategorikan studi ini ke dalam dua area berdasarkan model bisnis
perusahaan dengan mengeksplorasi bagaimana ET yang tangkas dipraktikkan, tantangan yang
dihadapi, dan praktik terbaik yang diperoleh.
Sisa makalah ini disusun sebagai berikut: bagian kedua memberikan metodologi tentang
bagaimana penelitian itu dilaksanakan dan bagian ketiga memberikan hasil studi kasus. Bagian
keempat membahas hasil dari sudut pandang yang berbeda, berdasarkan model bisnis
perusahaan. Akhirnya, bagian kelima memberikan kesimpulan.

METODOLOGI
Pada bagian ini, kami mendeskripsikan profil perusahaan, informasi responden, kuesioner yang
digunakan dalam studi kasus kami dan langkah-langkah yang dilakukan dalam penelitian kami.

A. Profil perusahaan
Untuk studi kasus ini, kami mengumpulkan data dari lima perusahaan produk perangkat lunak
dengan model bisnis yang berbeda. Perusahaan1 adalah perusahaan multinasional yang
menciptakan produk perangkat lunak penyimpanan cloud untuk bisnis. Company2 adalah
perusahaan produk dan layanan multinasional yang menyediakan program loyalitas bagi
pengguna rumah tangga dan bisnis kecil untuk meningkatkan keterlibatan. Company3 adalah
perusahaan produk perangkat lunak dengan pasar online yang memberikan rekomendasi yang
dipersonalisasi kepada jutaan pengguna langganannya. Company4 adalah perusahaan global
yang menyediakan platform analitik untuk entitas bisnis besar. Company5 adalah perusahaan e-
commerce yang menjual berbagai produk kosmetik kepada konsultan dan pengguna retail.
Dua dari perusahaan tersebut memiliki badan usaha sebagai pelanggan akhir mereka, yang
beroperasi hanya di ruang B2B. Dua dari perusahaan tersebut memiliki pengguna ritel sebagai
konsumen akhir, dengan model B2C. Salah satu perusahaan memiliki pengguna ritel dan usaha
kecil sebagai pelanggan.

B. Informasi Responden
Orang-orang yang menanggapi studi kasus memainkan peran berbeda di perusahaan, yaitu
pemilik produk, desainer UI, insinyur perangkat lunak, dan master Scrum. Mereka terlibat dalam
proses pengumpulan persyaratan dan membuat cerita pengguna di lingkungan yang gesit.
Mayoritas responden telah berlatih gesit selama lebih dari tujuh tahun. Tabel 1 di bawah ini
menunjukkan informasi responden, yaitu: jenis pelanggan, peran responden dalam organisasi dan
tahun pengalaman di Agile Scrum

Table 1: Summary of Respondents

Company Customer Respondent Year of
pseudonym role in EXP with
organization Agile
Scrum
Company1 Business entity Product Owner 6
Company2 End UI Designer 6
Consumers
Company3 Business entity Scrum Master 7
and end
Consumers
 Company4 Business entity Software 8
Engineer
Company5 End Product Owner 7
Consumers

C. Desain Kuisioner
Pertanyaan untuk studi kasus ini dirancang berdasarkan hasil dan temuan tinjauan pustaka
praktik RE tangkas [15] [16]. Tinjauan pustaka difokuskan terutama pada bidang-bidang ini -
keterlibatan pelanggan, komunikasi tatap muka, prioritas persyaratan, perencanaan berkelanjutan
dan pemodelan persyaratan. Penemuan ini memberikan pemahaman yang baik tentang
bagaimana RE tangkas sedang dipraktekkan di industri perangkat lunak.
Kami mempertimbangkan aspek-aspek berikut untuk mengajukan pertanyaan untuk studi kasus
ini.
Pertanyaan harus sederhana dan dipahami dengan jelas.
• Alur pertanyaan harus logis dan menarik.
• Harus ada kombinasi pertanyaan objektif dan subjektif.
• Istilah dan konsep yang digunakan dalam kuesioner harus familiar bagi industri

Kami mengikuti langkah-langkah berikut untuk menyelesaikan kuesioner:

1. Selesaikan lima pertanyaan penelitian utama

2. Selesaikan enam belas sub-pertanyaan di bawah pertanyaan penelitian utama
3. Pertanyaan ditinjau oleh beberapa praktisi yang gesit
4. Pertanyaan diperbarui sesuai komentar ulasan dan diselesaikan

Kuesioner untuk studi kasus disusun dalam dua bagian. Bagian 1 terdiri dari pertanyaan obyektif
seputar profil organisasi, ukuran, dan kematangan agile. Bagian 2 berfokus pada bagaimana
pengumpulan persyaratan dipraktikkan, diikuti oleh beberapa praktik terbaik yang digunakan dan
tantangan umum yang dihadapi seputar RE. Informasi ini dikumpulkan melalui enam belas
pertanyaan subjektif yang diringkas menjadi lima pertanyaan penelitian.
Tabel 2 menunjukkan kuesioner studi kasus yang disusun sesuai dengan pertanyaan penelitian.

Table 2: Case study questionnaire

Pertanyaan Sub Pertanyaan

Penelitian

RQ1: Entitas apa 1. Apakah Pemilik Produk sepenuhnya

yang terlibat dalam bertanggung jawab atas pengumpulan
proses persyaratan dari pelanggan? Jika tidak,
pengumpulan siapa yang berinteraksi dengan pelanggan?
persyaratan 2. Bagaimana mode dan frekuensi interaksi
proyek? dengan pelanggan selama pengumpulan
 persyaratan?

RQ2: Bagaimana 3. Bagaimana Anda berinteraksi dengan

komunikasi pelanggan Anda untuk mendiskusikan
pelanggan dikelola persyaratan (email, tatap muka, dll.)?
sebagai bagian dari 4. Apakah pelanggan memberikan definisi
proses rekayasa persyaratan yang akurat ATAU adakah
persyaratan? beberapa putaran diskusi yang diperlukan
untuk mendapatkan definisi persyaratan?
5. Apakah pertemuan tindak lanjut dengan
pelanggan dilakukan untuk memverifikasi
persyaratan dan memprioritaskannya
kembali?
6. Apakah pelanggan terlibat di seluruh
proyek melalui tinjauan Sprint atau hanya
selama proyek dimulai dan dirilis?
7. Jika ada banyak perwakilan pelanggan,
bagaimana Anda memprioritaskan dan
membangun konsensus di atas
persyaratan?

RQ3: Bagaimana Apa keterlibatan pelanggan untuk

Kisah Pengguna membantu pemilik produk mendefinisikan
didefinisikan? epos dan cerita pengguna?
9. Apakah persyaratan non-fungsional
ditangkap sebagai cerita pengguna
independen? Jika tidak, bagaimana cara
mereka ditangkap?
10. Setelah Anda menulis kriteria
penerimaan cerita, apakah Anda
mendiskusikannya dengan pelanggan?

RQ4: Apa 11. Tantangan apa yang Anda hadapi saat

tantangan umum pelanggan tidak memiliki pengetahuan
yang dihadapi tentang metode tangkas?
dalam proses 12. Tantangan apa yang Anda hadapi
rekayasa dalam memprioritaskan persyaratan dan
persyaratan? apakah mereka dinegosiasikan dengan
pelanggan?
13. Tantangan apa yang Anda hadapi saat
membuat cerita pengguna untuk tim
Scrum?
14. Tantangan apa yang Anda hadapi
dalam mendefinisikan interaksi pengguna
akhir dengan antarmuka perangkat lunak
(UX Design)?

RQ5: 15. Di mana dan bagaimana persyaratan

Bagaimana dikelola dan dilacak? Apakah catatan
persyaratan diskusi dengan pelanggan untuk keperluan
dikelola dan penyesuaian juga dilacak?
perubahan 16. Bagaimana Anda menangani
dilacak selama ketertelusuran persyaratan untuk melacak
siklus proyek? persyaratan di kemudian hari? Tantangan
apa yang Anda hadapi dalam proses ini?
D. PelaksanaanStudi Kasus
Kami menggunakan dua pendekatan dalam mengumpulkan informasi dari responden. Dalam
pendekatan pertama, kami melakukan wawancara tatap muka. Pada pendekatan kedua, ketika
pertemuan tatap muka tidak memungkinkan, kami meletakkan kuesioner dalam formulir web
yang dibuat menggunakan layanan pihak ketiga yang disebut Typeform dan mengirimkannya ke
responden untuk masukan secara offline. Tindak lanjut untuk memperjelas
tanggapan dilakukan melalui email atau melalui komunikasi telepon. Wawancara tatap muka
berlangsung sekitar 30 menit, selama waktu itu catatan tulisan tangan dibuat. Pertanyaan
wawancara disesuaikan dengan peran responden dan aliran topik. Kuesioner online
membutuhkan waktu sekitar 30 hingga 45 menit untuk diselesaikan

HASIL
Pada bagian ini, kami menyajikan analisis dari wawancara dalam bentuk pertanyaan dan jawaban
penelitian yang diterima dari responden.

A. RQ1: Entitas apa yang terlibat dalam proses pengumpulan persyaratan proyek?

Pemilik produk terutama mendorong pengumpulan persyaratan di semua perusahaan, meskipun

tidak sepenuhnya bertanggung jawab. Desainer UX, pimpinan teknik, dan tim pemasaran
berkolaborasi dalam proses pengumpulan persyaratan. Interaksi dengan pelanggan sering terjadi
dengan sebagian besar interaksi terjadi melalui telekonferensi, wawancara, survei, masukan dari
dukungan pelanggan dan tim penjualan. Selama proyek berlangsung, pemilik produk terus
berinteraksi dengan pelanggan seiring dengan berkembangnya persyaratan dan memanggil
anggota tim Scrum jika diperlukan.

RQ2: Bagaimana komunikasi pelanggan dikelola sebagai bagian dari proses rekayasa
persyaratan?

Untuk mendiskusikan persyaratan, interaksi tatap muka dengan pelanggan tampaknya paling
berhasil bagi banyak responden. Untuk pelanggan jarak jauh, panggilan video melalui WebEx
lebih disukai. Untuk pengumpulan persyaratan tidak langsung, interaksi dengan pelanggan
melalui studi jarak jauh, survei. Pengumpulan persyaratan awal memerlukan beberapa putaran
diskusi dengan pelanggan dan biasanya tidak pernah selesai dalam diskusi awal. Jika ada banyak
pemangku kepentingan di sisi pelanggan, pembuatan prioritas dan konsensus atas persyaratan
terjadi setelah terlibat dengan pelanggan secara pribadi, menganalisis tren masukan, dan
kemudian membiarkan pemilik produk mengambil keputusan akhir tentang persyaratan. Selain
itu, interaksi pelanggan untuk sebagian besar perusahaan setelah pengumpulan persyaratan awal
dan tahap desain UX adalah selama rilis fitur di seluruh demo produk dan validasi pasca-rilis.

C. RQ3: Bagaimana cerita pengguna didefinisikan?

Setelah persyaratan awal diidentifikasi, pemilik produk membuat epos tingkat tinggi dan bekerja
dengan pimpinan teknisi untuk menentukan cerita pengguna dalam bentuk fitur. Peran pelanggan
dalam pembuatan dan ulasan cerita pengguna sangat terbatas untuk sebagian besar responden.
Kami bertanya kepada responden apakah kriteria penerimaan untuk epos dan cerita sedang
dibahas dengan pelanggan setelah definisi mereka. Sebagian besar responden menyebutkan
bahwa kriteria penerimaan biasanya tidak didiskusikan dengan pelanggan, tetapi setuju bahwa
hal itu akan berguna. Untuk kebutuhan non fungsional, tidak ada praktik standar yang diikuti
oleh responden. Beberapa responden menyebutkan bahwa persyaratan non-fungsional dibahas
dengan pelanggan dan didefinisikan sebagai cerita pengguna independen, sementara beberapa
responden menyebutkan bahwa persyaratan tersebut biasanya ditentukan oleh pemilik produk
dan ditujukan menjelang akhir siklus proyek.

D. RQ4: Apa tantangan umum yang dihadapi dalam proses rekayasa persyaratan?

Salah satu tantangan yang ditunjukkan oleh beberapa responden adalah kurangnya pengetahuan
pelanggan tentang metode pengembangan produk yang tangkas. Sebagian besar responden
menunjukkan bahwa meskipun metode agile adalah untuk pengembangan internal, pengetahuan
pelanggan tentang agile membantu mengelola ekspektasi tentang pengiriman tambahan dan
menetapkan ekspektasi untuk lebih terlibat dalam menyempurnakan persyaratan dan validasi
melalui demo produk pada penyelesaian fitur.
Tantangan lainnya adalah menegosiasikan prioritas persyaratan dengan pelanggan. Semua
responden menyebutkan bahwa pembuatan prioritas memang terjadi, tetapi mereka juga
menghadapi tantangan untuk menemukan keseimbangan antara tujuan bisnis dan pelanggan.
Pelanggan mungkin
telah memprioritaskan persyaratan besar, tetapi prioritasnya akan diturunkan jika tidak
menghasilkan pendapatan yang signifikan. Responden menyebutkan bahwa mereka
menggunakan model pengiriman bertahap dari agile untuk mengatasi tantangan ini, di mana
mereka menegosiasikan kembali prioritas persyaratan dan jadwal selama proyek, berdasarkan
parameter proyek (sumber daya, ruang lingkup, biaya) yang berlaku pada saat itu.
Selain itu, tantangan lain yang diidentifikasi oleh beberapa responden adalah peningkatan
cakupan pekerjaan setelah desain UX selesai, karena menghasilkan penemuan detail tambahan.
Perkiraan dan komitmen tanggal berdasarkan cakupan awal dalam skenario tersebut berantakan,
mengharuskan pemilik produk untuk menegosiasikan ulang jadwal pengiriman fitur dengan
pelanggan.
Responden juga ditanya tentang tantangan yang dihadapi dalam membuat cerita pengguna
selama pengumpulan persyaratan. Beberapa responden menyebutkan bahwa cerita pengguna
terlalu terperinci atau terlalu tinggi, berdasarkan gaya individu pemilik produk. Selain itu, karena
sifat persyaratan yang terus berkembang, desain UX terkadang tidak siap saat cerita diambil
untuk perawatan backlog, yang mengakibatkan ketergantungan atau hambatan selama sprint.

E. RQ5: Bagaimana persyaratan dikelola dan perubahan dilacak selama siklus proyek?

Terkait pengelolaan dan penelusuran persyaratan dari pelanggan, semua responden

menggunakan JIRA, Confluence atau Rally. Meskipun persyaratan awal sedang
didokumentasikan, hanya beberapa responden yang melacak diskusi lanjutan tentang persyaratan
atau umpan balik yang diterima tentang persyaratan tersebut. Sebagian besar responden
menyebutkan bahwa ketertelusuran persyaratan sulit untuk dipertahankan karena dokumentasi
tidak selalu diperbarui dan cenderung menjadi usang karena persyaratan berkembang selama
proyek berlangsung. Alternatifnya adalah terus memperbarui kisah pengguna dan selaras dengan
perubahan persyaratan pelanggan.

DISKUSI
Berdasarkan tanggapan terhadap studi kasus dari praktisi industri perangkat lunak yang
diselidiki, praktik RE tangkas dapat dikategorikan menjadi dua kategori berdasarkan model
bisnis organisasi. Dalam kategori pertama, pelanggan akhir mewakili entitas bisnis lain (vendor,
mitra, dan / atau konsumen). Pada kategori kedua, konsumen akhir yang berinteraksi dengan
produk perangkat lunak (konsumen ritel online) mewakili konsumen akhir. Karena entitas
pelanggan akhir berbeda dalam kedua kasus tersebut, praktik RE yang tangkas juga terlihat
berbeda.
Di bagian ini, kami membahas bagaimana RE tangkas dipraktikkan, jenis tantangan yang
dihadapi dan praktik terbaik yang diikuti di dua kategori.

A. Praktik RE agile di mana pelanggan akhir mewakili entitas bisnis

1. Bagaimana RE dipraktikkan?
Dalam hal ini, pemilik produk terutama bertanggung jawab atas pengumpulan persyaratan dari
pelanggan, meskipun pimpinan teknis dan QA juga berpartisipasi dalam interaksi dengan
pelanggan (entitas bisnis). Frekuensi interaksi dengan pelanggan selama beberapa iterasi pertama
pengumpulan persyaratan dapat berkisar dari sekali dalam dua hingga tiga minggu.
Pertemuan awal dilakukan secara tatap muka, diikuti oleh WebEx atau telecon untuk diskusi
lanjutan. Metode komunikasi yang paling berhasil bagi sebagian besar responden adalah
konferensi video. Dalam kebanyakan kasus, satu atau dua putaran diskusi dengan pelanggan
sudah cukup untuk membuat definisi persyaratan yang akurat, tetapi terkadang beberapa putaran
tambahan diperlukan. Pertemuan tindak lanjut dengan pelanggan dilakukan untuk proyek dengan
kompleksitas tinggi, terutama untuk memverifikasi dan memprioritaskan ulang persyaratan.
Keterlibatan pelanggan diamati, selama proyek, dalam bentuk penyempurnaan persyaratan, demo
sprint, dan rilis fitur tambahan.
Jika ada beberapa pemangku kepentingan pelanggan yang terlibat, setiap pelanggan terlibat
secara individual atas dasar satu-ke-satu, dan prioritas persyaratan kemudian dilakukan,
berdasarkan pada kepentingan bisnis.

2. Pembuatan cerita pengguna

Setelah iterasi pertama pengumpulan persyaratan selesai, pemilik produk bertanggung jawab
untuk membuat cerita pengguna. Selain persyaratan fungsional yang ditulis sebagai cerita
pengguna, persyaratan non-fungsional paling sering ditangkap sebagai cerita pengguna
independen oleh semua responden. Setelah product owner menentukan kriteria penerimaan
cerita, beberapa responden mengatakan bahwa mereka mendiskusikannya dengan pelanggan
sementara beberapa mengatakan bahwa praktik ini tidak perlu diikuti.

3. Tantangan yang dihadapi dalam RE

Kurangnya pengetahuan gesit pelanggan menghadirkan tantangan tertentu bagi tim gesit.
Sebagian besar responden merasa berguna untuk menjelaskan kepada pelanggan dalam
pertemuan awal bahwa interaksi selama proyek perlu sering dilakukan, yang melibatkan diskusi
rutin tentang persyaratan dan umpan balik tentang produk secara bertahap melalui demo produk.
Berkenaan dengan prioritas persyaratan, responden menghadapi tantangan untuk
memprioritaskan kembali persyaratan setelah berkomitmen untuk mengirimkannya kepada
pelanggan akhir. Prioritas ulang dapat terjadi jika tim teknik menemukan kerumitan atau kendala
teknologi yang membuat pengiriman tidak dapat dilakukan dalam jangka waktu yang ditentukan.

4. Praktik terbaik yang diikuti dalam RE

Beberapa praktik terbaik yang diikuti adalah -

Sebuah.
a. Menentukan tujuan bisnis sesuai dengan persyaratan, yang membantu tim Scrum untuk selalu
mengingat hasil yang diinginkan.
b. Keterampilan untuk berkomunikasi dengan pelanggan sangat penting dan itu salah satu
pemilik produk di perusahaan mereka berusaha untuk terus meningkatkannya.
c. Beberapa sesi umpan balik dengan pelanggan selama proses desain UX.
d. Dalam organisasi besar dengan sistem yang kompleks di mana analis bisnis (BA) terlibat
dalam rekayasa persyaratan, templat dengan masukan dan keluaran yang diperlukan dibuat oleh
BA. Mereka, dalam koordinasi dengan pemilik produk, bekerja dengan pelanggan untuk
menentukan persyaratan.

B. Praktik ET tangkas di mana pelanggan akhir adalah konsumen

1. Bagaimana RE dipraktikkan?
Perusahaan yang termasuk dalam kategori ini memiliki konsumen yang berinteraksi dengan
produk melalui situs web perusahaan. Di perusahaan ini, pemilik produk sepenuhnya
bertanggung jawab atas pengumpulan persyaratan dan penentuan arah produk. Selain itu, ini
adalah latihan kolaboratif dengan pimpinan teknik, tim UX, tim riset dan analitik, serta rekan
dari departemen lain. Interaksi langsung dengan konsumen akhir sangat terbatas. Poin data untuk
pengumpulan persyaratan dalam hal ini berasal dari survei, wawancara, formulir umpan balik
yang dihosting di situs web, cakupan promotor bersih (NPS), masukan dari dukungan pelanggan
dan tim analisis konsumen.
Untuk memverifikasi persyaratan dan kemudian memprioritaskannya, pemilik produk berkumpul
dengan tim Scrum dan pemangku kepentingan lainnya di perusahaan untuk sesi umpan balik
tentang fitur produk menggunakan tiruan kesetiaan tinggi dan prototipe interaktif. Keterlibatan
pelanggan akhir sepanjang siklus hidup proyek terutama setelah fitur dirilis ke pasar, di mana
umpan balik dari pelanggan akhir dicari secara tidak langsung melalui analitik data dan umpan
balik dukungan pelanggan.
Dalam model ini, penentuan prioritas persyaratan dilakukan oleh pemilik produk berdasarkan
masukan dari bisnis dan tim dukungan pelanggan yang memiliki gagasan yang baik tentang
kebutuhan pelanggan utama dan apa yang akan memberikan pengembalian investasi maksimum
untuk bisnis.

2. Pembuatan cerita pengguna

Setelah persyaratan awal diidentifikasi dari beberapa saluran, pemilik produk membuat epos dan
bekerja dengan pimpinan teknik dan master Scrum untuk menentukan cerita pengguna. Ini
kemudian ditinjau dengan bisnis dan kepemimpinan dan diperkuat. Produk pemilik biasanya
menangkap persyaratan non-fungsional sebagai cerita pengguna independen dan mengikatnya ke
dalam epos fitur.
Sebagai bagian dari definisi studi pengguna, pemilik produk menulis kriteria penerimaan yang
terutama digunakan untuk tim pengembang / QA untuk fokus pada pengiriman. Sebagian besar
responden menyebutkan bahwa akan menjadi praktik yang baik jika mereka ditinjau melalui
pemasaran. Pemilik produk juga membuat peta jalan produk dan rilis fitur yang akan dirilis
secara bertahap.
Prioritas persyaratan dilakukan dengan menyeimbangkan pekerjaan pengembangan fitur baru
dengan peningkatan yang diperlukan untuk fitur yang dirilis sesuai masukan dari dukungan
pelanggan. Selain itu, persyaratan terus berkembang dan ditangkap sebagai cerita pengguna di
backlog produk.
3. Tantangan yang dihadapi dalam RE
Dalam model ini, salah satu tantangan utama yang dihadapi oleh pemilik produk menurut
responden adalah mendefinisikan interaksi pengguna akhir dengan antarmuka perangkat lunak
(UX Design), karena umpan balik dari pelanggan akhir bersifat tidak langsung dan tidak
langsung. Merupakan tantangan untuk terus meningkatkan pengalaman pengguna sambil
memastikan pengguna tidak bingung karena perubahan besar dalam interaksi pengguna dengan
aplikasi.
Tantangan lainnya adalah ketika antarmuka pengguna di seluruh fitur baru tidak sepenuhnya
ditentukan dan pengembangan dimulai di seluruh fitur tersebut, yang memperkenalkan overhead
pengembangan. Masalah umum yang disebutkan, adalah bahwa dokumen persyaratan menjadi
usang karena tidak diperbarui saat persyaratan muncul. Solusi yang digunakan adalah
menangkap persyaratan baru sebagai cerita pengguna dan memperbaruinya sesuai kebutuhan
selama proses perawatan backlog.

4. Praktik terbaik yang diikuti dalam RE

Beberapa praktik terbaik yang diikuti adalah -
Sebuah. Pengujian A / B (atau pengujian terpisah) dengan meluncurkan fungsionalitas ke
sekumpulan pengguna tertentu dan
b. Menggunakan analitik untuk mengumpulkan umpan balik.
c. Lab kegunaan untuk berbagi konsep produk dan mencari umpan balik dari anggota tim tentang
persyaratan.
d. Selain itu, persyaratan didokumentasikan bersama dengan wireframe dan alur kerja untuk
membantu insinyur memahami tujuan keseluruhan selama proyek berlangsung.

KESIMPULAN
Studi kasus kami menegaskan bahwa agar RE berhasil dalam proyek yang gesit, diperlukan pola
pikir kolaboratif antara pelanggan, pemilik produk, dan tim. Sepanjang studi kasus ini, kami
memahami bagaimana RE tangkas dipraktikkan di mana persyaratan selalu berkembang dan ada
pengiriman berkelanjutan perangkat lunak yang berharga. Studi tersebut juga menjelaskan
perbedaan dalam praktik ET dalam model B2B di mana pelanggan akhir adalah entitas bisnis,
versus model B2C di mana pelanggan akhir adalah konsumen. Studi kasus menyelidiki praktik
terbaik yang diadopsi oleh praktisi gesit serta tantangan yang dihadapi dalam praktik ET gesit.
Temuan ini dari studi kasus akan membantu praktisi ET yang gesit untuk meningkatkan praktik
ET mereka dan akan memberikan masukan yang berharga bagi pelaksana alat manajemen
persyaratan dalam menyempurnakan fungsionalitas manajemen persyaratan.
Studi empiris lebih lanjut diperlukan di area di mana praktisi ET yang gesit menghadapi
tantangan: keterlibatan pelanggan dalam menentukan cerita pengguna dan kriteria penerimaan,
mengelola prioritas ulang persyaratan dan keterlacakan persyaratan selama durasi proyek.
Sebagai bagian dari pekerjaan di masa depan, kami bermaksud untuk membuat alat manajemen
persyaratan tangkas yang akan menggabungkan temuan-temuan ini dan digunakan oleh
pelanggan, pemilik produk, dan tim Scrum untuk berkolaborasi dalam persyaratan. Alat ini juga
akan memberikan visibilitas pelanggan pada cerita pengguna, persyaratan non-fungsional
bersama dengan mekanisme umpan balik dan validasi.