/

Pengembangam Perangkat Lunak

(CTI220)

MODUL 05
Pengumpulan Persyaratan Untuk Proyek Pengembangan Perangkat
Lunak

DISUSUN OLEH
Kundang K Juman, Ir. MMSI

UNIVERSITAS ESA UNGGUL

2020

1
Pengumpulan Persyaratan Untuk Proyek Pengembangan Perangkat Lunak

A. Kemampuan Akhir Yang Diharapkan

1. Setelah mempelajari Pengumpulan Persyaratan Untuk Proyek Pengembangan
Perangkat Lunak , diharapkan memahami persyaratan proyek pengembangan
perangkat lunak secara benar dan tepat.
2. Dapat meng-implementasi konsep yang telah dipelajari
B. Persyaratan Untuk Proyek Pengembangan Perangkat Lunak

Persyaratan Gathering adalah bagian fundamental dari setiap proyek pengembangan

perangkat lunak. Ini adalah hal-hal seperti "Pengguna ingin melakukan X. Bagaimana
ini bisa dicapai?" Akibatnya, Requirements Gathering adalah proses menghasilkan
daftar persyaratan (fungsional, sistem, teknis, dll.) Dari semua pemangku kepentingan
(pelanggan, pengguna, vendor, staf TI) yang akan digunakan sebagai dasar untuk
definisi formal dari apa proyeknya. Karena persyaratan menentukan proyek,
persyaratan yang ditulis dengan buruk dapat menyebabkan masalah selama
pengembangan dan, yang lebih serius, menyebabkan proyek gagal jika tujuannya
telah disalahpahami. Seperti kata pepatah, "gagal mempersiapkan, dan Anda bersiap
untuk gagal"

Pentingnya Pengumpulan Persyaratan

Pelanggan bisnis cenderung mengharapkan tim perangkat lunak untuk memberikan
solusi berdasarkan persyaratan yang tidak terucapkan, tidak lengkap atau tidak
diketahui, sementara tim perangkat lunak cenderung berasumsi bahwa pelanggan
bisnis akan mengomunikasikan dengan tepat apa yang mereka inginkan sesingkat
mungkin. Kedua ekspektasi tersebut jelas tidak realistis. Oleh karena itu, persyaratan
tersebut perlu ditangkap secara formal dalam satu dokumen yang dapat digunakan
sebagai referensi selama pengembangan perangkat lunak.

Dalam kasus di mana vendor potensial masih diciutkan, titik awal yang penting adalah
setidaknya mengumpulkan semua persyaratan utama untuk memungkinkan
penawaran ball-park.

2
Pengumpulan, pemrosesan, dan pengelolaan persyaratan yang baik penting karena
menetapkan target yang jelas untuk dituju oleh semua orang. Ini bisa menjadi
pekerjaan yang berat, tetapi tidak perlu menjadi tugas yang berat jika Anda dapat
mengingat beberapa poin penting.

Pengguna didahulukan
Pertama, ingat ini semua tentang pengguna. Cari tahu bagaimana pengguna
sebenarnya menyelesaikan tugas mereka dan bagaimana tepatnya mereka
menyelesaikan sesuatu - dan bagaimana mereka ingin menyelesaikan sesuatu. Apa
yang perlu mereka lakukan? Seberapa efisien kita dapat mewujudkannya? Dan
fleksibilitas macam apa yang mungkin dibutuhkan?

Persyaratan harus merinci bagaimana pengguna akan mencapai apa yang mereka
inginkan dengan menggunakan perangkat lunak yang sedang
dikembangkan. Kesadaran akan preferensi teknologi dan integrasi sistem yang ada
juga merupakan hal mendasar, karena dapat berdampak besar pada jalur
pengembangan dan selanjutnya berdampak pada kinerja dan efisiensi tugas
pengguna.

Alat yang berguna untuk Pengumpulan Persyaratan

Ada banyak alat yang dapat digunakan untuk membantu pengumpulan
kebutuhan. Misalnya, saat Anda berada dalam sesi pengumpulan persyaratan,
cobalah pemetaan pikiran untuk membantu mengatur percakapan dengan
menyelaraskan komentar, persyaratan, dan ide dengan cabang pemikiran utama
dalam percakapan.

Kembangkan diagram use case , termasuk semua langkah yang dibayangkan dalam
proses baru. Ini bisa berarti menggunakan model "As-Is" dan "To-Be", di mana Anda
membuat diagram langkah-langkah saat ini yang diperlukan (As-Is) dan kemudian
menambahkan "swim lane" (To-Be) yang menunjukkan solusi yang diopt

3
Ada baiknya menghabiskan waktu mendokumentasikan 'As-Is' untuk proses besar
atau kompleks sehingga seluruh tim dapat mengembangkan pemahaman bersama
tentang proses bisnis.

Model 'To-Be' menunjukkan bagaimana proses bisnis menjadi disesuaikan dengan

sistem baru yang ada (terkadang sangat membantu untuk melapisi As-Is dengan To-
Be untuk memahami perubahan).

Tempatkan diri Anda pada peran pengguna dan pikirkan tentang bagaimana mereka
beralih dari satu langkah ke langkah lainnya untuk mencapai tujuan mereka
menggunakan perangkat lunak dan ketergantungan apa yang mungkin terlibat
(seperti menanyakan database untuk pengenal unik). Perhatikan bahwa penting juga
untuk mengetahui apa yang tidak boleh dilakukan pengguna dengan perangkat lunak,
atau kemampuan yang seharusnya tidak terlihat oleh mereka!

Alat lain yang berguna adalah mengumpulkan cerita pengguna tentang bagaimana
mereka melakukan sesuatu. Jika cerita pengguna terlalu rumit, dapat dipecah menjadi
cerita yang lebih kecil dan didukung dengan diagram.

Seringkali pelingkupan proyek mungkin memerlukan diagram konteks untuk

menentukan batas sistem, lingkungan sekitarnya dan semua entitas yang

4
berinteraksi. Menjadi lengkap juga berarti teliti: mengetahui sistem dan cara kerjanya dalam
konteks yang diperlukan. Bagaimana itu akan berintegrasi dengan sistem lain? Bagaimana
database berkomunikasi? API apa yang akan dibutuhkan dan bagaimana mereka sudah
digunakan? Dengan membuat model visual dari solusi perangkat lunak, Anda akan
mendapatkan gagasan yang lebih baik tentang interaksi utama dan pemain di sistem Anda.

Jenis diagram lain yang dapat digunakan adalah ilustrasi top-down, yang disebut diagram
dekomposisi fungsional , yang berguna untuk memecah sistem menjadi potongan-potongan
besar.

Remember not to make assumptions or take anything for granted. Be as detailed as possible
and document every step needed to accomplish a task. Reiterate the key objectives during the
requirements gathering process to ensure everyone is happy. One way to do this is to use
SMART goals: Specific, Measurable, Agreed-upon, Realistic and Time-based.

Ask your stakeholders what they need and how your team can make their lives easier. Have
they encountered pitfalls on other projects and can it be worked into the current spec as
potential hazards? This is part diplomacy and part functional requirement gathering.

5
Finally, if you hit problems, then it’s better to have encountered them early on, during the
requirements gathering stage, rather than at some time further down the road, when it could
cost additional time and money to put right

Daftar. Pustaka. :

1.IEEE Standard for Developing Software Life Cycle Processes

2.Agile Software Development Methods: Review and Analysis, Pekka Abrahamsson,
3.OutiSalo,JussiRonkainenandJuhaniWarsta TheSoftwareDevelopmentLife

6
7