Bab 1 : Software Requirements

Bagian 1 : Dasar dasar software requirements

A.    Definisi Dan Kategori Kebutuhan Perangkat Lunak

1.           Definisi software requirements adalah Kumpulan kebutuhan dan harapan yang harus dipenuhi oleh suatu perangkat lunak agar dapat berfungsi sesuai dengan tujuan yang diinginkan. Kebutuhan ini mencakup apa saja yang harus dilakukan oleh system, bagaiman system tersebut bekerja, serta Batasan Batasan yang harus dipatuhi selama proses pengembangan. Software requirements menjadi dasar utama dalam perancangan, pengembangan, dan pengujian perangkat lunak sehingga hasil akhir yang dibuat sesuai dengan kebutuhan pengguna dan tujuan proyek.

2.           Perbedaan antara kebutuhan fungsional dan kebutuhan non-fungsional

Kategori Kebutuhan	Definisi	Contoh
Fungsional	Kebutuhan yang menjelaskan fungsi atau layanan utama yang harus disediakan oleh system serta bagaimana system merespons input dari pengguna. Kebutuhan ini berfokus pada apa yang dilakukan oleh perangkat lunak.	System dapat melakukan login pengguna, menampilkan data, menyimpan transaksi, dan mencetak laporan.
Non fungsional	Kebutuhan yang menjelaskan kualitas, Batasan, atau karakteristik system dalam menjalankan fungsinya. Kebutuhan ini berfokus pada bagaimana system bekerja.	sistem memiliki waktu respon kurang dari 3 detik, data pengguna terlindungi dengan enkripsi, dan aplikasi dapat diakses 24 jam.

 

3.     Contoh Kebutuhan Perangkat Lunak Berdasarkan Studi Kasus

a. Sistem Manajemen Perpustakaan Digital

Kebutuhan Fungsional:

1.     Sistem memungkinkan pengguna melakukan login sebagai anggota atau admin.

2.     Sistem dapat menampilkan katalog buku digital berdasarkan judul, penulis, atau kategori.

3.     Sistem memungkinkan pengguna meminjam dan mengembalikan buku secara digital.

4.     Sistem mencatat riwayat peminjaman setiap pengguna.

5.     Admin dapat menambah, mengubah, dan menghapus data buku.

Kebutuhan Non-Fungsional:

1.     Sistem harus dapat diakses selama 24 jam.

2.     Waktu respon pencarian buku maksimal 3 detik.

3.     Data pengguna harus terlindungi dengan sistem keamanan login.

4.     Sistem dapat diakses melalui berbagai perangkat (PC dan mobile).

5.     Antarmuka sistem mudah digunakan oleh pengguna umum.

b. Aplikasi Mobile Pemesanan Tiket

Kebutuhan Fungsional:

1.     Aplikasi memungkinkan pengguna melakukan registrasi dan login.

2.     Pengguna dapat mencari tiket berdasarkan tujuan dan tanggal keberangkatan.

3.     Aplikasi menampilkan detail jadwal dan harga tiket.

4.     Pengguna dapat melakukan pemesanan dan pembayaran tiket.

5.     Aplikasi mengirimkan e-tiket setelah transaksi berhasil.

Kebutuhan Non-Fungsional:

1.     Aplikasi memiliki tampilan yang responsif di berbagai ukuran layar.

2.     Sistem pembayaran harus aman dan terenkripsi.

3.     Aplikasi memiliki waktu respon cepat saat proses pemesanan.

4.     Aplikasi dapat berjalan pada sistem operasi Android.

5.     Aplikasi tetap stabil meskipun digunakan oleh banyak pengguna secara bersamaan.

B.    Teknik Elicitation Kebutuhan

1.     Tujuan Elicitation Kebutuhan Perangkat Lunak

Tujuan dari elicitation kebutuhan perangkat lunak adalah untuk mengidentifikasi, mengumpulkan, dan memahami kebutuhan pengguna serta pemangku kepentingan secara jelas dan lengkap. Proses ini bertujuan agar perangkat lunak yang dikembangkan benar-benar sesuai dengan kebutuhan pengguna, mengurangi kesalahan pemahaman, serta meminimalkan perubahan kebutuhan di tahap pengembangan selanjutnya.

2.     Teknik Elicitation Kebutuhan dan Contoh Penerapannya

Teknik Elicitation	Deskripsi Singkat	Contoh Penerapan
Wawancara	Teknik pengumpulan kebutuhan melalui tanya jawab langsung dengan stakeholder.	Developer mewawancarai pustakawan untuk mengetahui alur peminjaman buku.
Observasi	Teknik dengan mengamati langsung aktivitas pengguna dalam sistem yang berjalan.	Mengamati proses pembelian tiket di loket untuk memahami alur pemesanan.
Prototyping	Pembuatan contoh tampilan sistem untuk memperoleh umpan balik pengguna.	Membuat mockup aplikasi tiket dan meminta pengguna mencoba fitur pencarian.
Questionnaires	Pengumpulan kebutuhan melalui kuesioner yang dibagikan ke banyak pengguna.	Menyebarkan survei kepuasan pengguna aplikasi pemesanan tiket.
Workshop	Diskusi kelompok yang melibatkan berbagai stakeholder.	Workshop antara developer, admin, dan user untuk menentukan fitur utama sistem.

 

 

3.     Teknik Elicitation yang Paling Efektif untuk Proyek E-commerce

Teknik elicitation yang paling efektif untuk proyek e-commerce adalah prototyping. Hal ini karena pengguna dapat langsung melihat dan mencoba gambaran sistem yang akan dibangun, sehingga lebih mudah memberikan masukan terkait fitur, tampilan, dan alur transaksi. Prototyping juga membantu mengurangi kesalahpahaman antara pengguna dan pengembang serta mempercepat proses penyempurnaan kebutuhan sistem.

Bagian 2 : analisis dan Spesifikasi Kebutuhan Perangkat Lunak

A.    Analisis Kebutuhan

1.     Tujuan Utama Analisis Kebutuhan Perangkat Lunak

Tujuan utama analisis kebutuhan perangkat lunak adalah untuk memahami secara mendalam apa saja yang dibutuhkan oleh pengguna dan pihak terkait sebelum sistem dikembangkan. Melalui analisis kebutuhan, pengembang dapat menerjemahkan kebutuhan pengguna menjadi spesifikasi yang jelas, terstruktur, dan realistis. Proses ini juga membantu mengurangi kesalahan perancangan, mencegah perubahan kebutuhan yang terlalu sering, serta memastikan bahwa perangkat lunak yang dibangun benar-benar sesuai dengan tujuan dan konteks penggunaannya.

2.     Identifikasi Kebutuhan Berdasarkan Studi Kasus

Sistem E-learning Universitas

Kategori Kebutuhan	Kebutuhan
Fungsional	1. Sistem memungkinkan mahasiswa dan dosen melakukan login sesuai dengan peran masing-masing.
	2. Dosen dapat mengunggah materi perkuliahan dan tugas secara online.
	3. Mahasiswa dapat mengakses materi, mengumpulkan tugas, dan melihat nilai.
Non-Fungsional	1. Sistem harus dapat diakses kapan saja melalui jaringan internet.
	2. Sistem memiliki waktu respon yang cepat saat membuka materi atau mengumpulkan tugas.
	3. Data akademik pengguna harus tersimpan dengan aman dan terlindungi.

 

B.    Spesifikasi Kebutuhan

1.     Perbedaan Spesifikasi Kebutuhan Natural Language dan Model-Based Requirements

Spesifikasi kebutuhan dengan natural language ditulis menggunakan bahasa sehari-hari yang mudah dipahami oleh semua pihak, termasuk pengguna non-teknis. Pendekatan ini fleksibel dan sederhana, tetapi berpotensi menimbulkan ambiguitas karena perbedaan penafsiran.

Sementara itu, model-based requirements menggunakan model atau diagram seperti UML untuk menggambarkan kebutuhan sistem secara visual dan terstruktur. Pendekatan ini lebih jelas dan sistematis, namun membutuhkan pemahaman teknis yang lebih tinggi sehingga tidak selalu mudah dipahami oleh semua pengguna.

2.     Contoh Spesifikasi Kebutuhan Menggunakan Structured Natural Language

Studi Kasus: Aplikasi Mobile untuk Pemesanan Transportasi Online

Spesifikasi Kebutuhan 1

·       ID Kebutuhan: FR-01

·       Deskripsi Kebutuhan: Sistem harus memungkinkan pengguna melakukan registrasi dan login menggunakan nomor telepon atau email.

·       Kategori: Fungsional

·       Prioritas: Tinggi

·       Kriteria Penerimaan:

o   Pengguna dapat membuat akun baru dengan data yang valid

o   Pengguna berhasil masuk ke aplikasi setelah login

Spesifikasi Kebutuhan 2

·       ID Kebutuhan: FR-02

·       Deskripsi Kebutuhan: Sistem harus memungkinkan pengguna memesan layanan transportasi dengan menentukan lokasi penjemputan dan tujuan.

·       Kategori: Fungsional

·       Prioritas: Tinggi

·       Kriteria Penerimaan:

o   Sistem menampilkan peta lokasi penjemputan dan tujuan

o   Pesanan berhasil dikirim ke pengemudi

Spesifikasi Kebutuhan 3

·       ID Kebutuhan: FR-03

·       Deskripsi Kebutuhan: Sistem harus menampilkan estimasi biaya dan waktu perjalanan sebelum pemesanan dikonfirmasi.

·       Kategori: Fungsional

·       Prioritas: Sedang

·       Kriteria Penerimaan:

o   Estimasi biaya muncul sebelum tombol konfirmasi

o   Estimasi waktu perjalanan dapat dilihat pengguna

Spesifikasi Kebutuhan 4

·       ID Kebutuhan: NFR-01

·       Deskripsi Kebutuhan: Aplikasi harus memiliki waktu respon yang cepat saat digunakan.

·       Kategori: Non-Fungsional

·       Prioritas: Sedang

·       Kriteria Penerimaan:

o   Halaman utama terbuka dalam waktu kurang dari 3 detik

o   Proses pemesanan berjalan tanpa lag berlebihan

Spesifikasi Kebutuhan 5

·       ID Kebutuhan: NFR-02

·       Deskripsi Kebutuhan: Sistem harus menjaga keamanan data pribadi pengguna.

·       Kategori: Non-Fungsional

·       Prioritas: Tinggi

·       Kriteria Penerimaan:

o   Data pengguna tidak dapat diakses tanpa otorisasi

o   Proses login menggunakan autentikasi yang aman

3.     Diagram Sederhana Hubungan Kebutuhan Perangkat Lunak

(Use Case Diagram – Deskripsi Teks)

Aktor:

·       Pengguna

·       Pengemudi

Use Case Utama:

1.     Login / Registrasi

2.     Memesan Transportasi

3.     Melihat Estimasi Biaya dan Waktu

4.     Menerima Pesanan (Pengemudi)

5.     Menyelesaikan Perjalanan

Hubungan Use Case:

·       Pengguna → Login → Memesan Transportasi

·       Memesan Transportasi → Melihat Estimasi Biaya

·       Pengemudi → Menerima Pesanan → Menyelesaikan Perjalanan

Bagian 3: Validasi dan Manajemen Perubahan Kebutuhan

A.    Validasi Kebutuhan

1.     Pentingnya Validasi Kebutuhan Perangkat Lunak

Validasi kebutuhan perangkat lunak sangat penting untuk memastikan bahwa kebutuhan yang telah dikumpulkan dan dianalisis benar-benar sesuai dengan harapan pengguna dan tujuan sistem. Melalui proses validasi, pengembang dapat mendeteksi kesalahan, ketidaksesuaian, atau kebutuhan yang belum lengkap sejak tahap awal. Dengan demikian, risiko terjadinya kesalahan besar pada tahap implementasi dapat dikurangi, serta waktu dan biaya pengembangan dapat dikendalikan dengan lebih baik.

2.     Metode Validasi Kebutuhan dan Contoh Penerapannya

Metode Validasi	Deskripsi Singkat	Contoh Penerapan
Review Kebutuhan	Proses peninjauan kebutuhan bersama stakeholder untuk memastikan kejelasan dan kelengkapan.	Tim pengembang dan pengguna mengevaluasi dokumen kebutuhan sistem e-learning.
Prototyping	Validasi kebutuhan melalui model atau contoh sistem.	Pengguna mencoba tampilan awal aplikasi dan memberikan masukan.
Simulasi dan Eksekusi	Pengujian alur kebutuhan melalui skenario penggunaan.	Mensimulasikan proses pemesanan transportasi dari awal hingga akhir.

 

3.     Analisis Kemungkinan Kesalahan dalam Spesifikasi Kebutuhan dan Cara Mengatasinya

Kesalahan yang sering terjadi dalam spesifikasi kebutuhan antara lain kebutuhan yang ambigu, kebutuhan tidak lengkap, dan perbedaan pemahaman antara pengguna dan pengembang. Untuk mengatasinya, diperlukan komunikasi yang intensif dengan stakeholder, penggunaan bahasa yang jelas dan terstruktur, serta penerapan validasi secara berkala melalui review dan prototyping.

 

B.    Manajemen Perubahan Kebutuhan

1.   Terjadinya Perubahan Kebutuhan dalam Siklus Pengembangan Perangkat Lunak

Perubahan kebutuhan dapat terjadi karena berbagai faktor, seperti perubahan kebutuhan pengguna, perkembangan teknologi, kebijakan organisasi, atau hasil evaluasi selama proses pengembangan. Dalam siklus pengembangan perangkat lunak, perubahan ini merupakan hal yang wajar dan perlu dikelola dengan baik agar tidak mengganggu jadwal maupun kualitas sistem.

 

 

2.     Contoh Situasi Perubahan Kebutuhan dan Strategi Mengatasinya

Situasi Perubahan Kebutuhan	Dampak	Strategi Mengatasi
Pengguna meminta fitur baru di tengah pengembangan	Jadwal pengembangan menjadi lebih lama	Melakukan analisis dampak dan menentukan prioritas fitur
Perubahan aturan keamanan data	Sistem perlu disesuaikan	Memperbarui spesifikasi dan melakukan penyesuaian desain
Perubahan platform yang digunakan	Penyesuaian teknis diperlukan	Evaluasi ulang arsitektur sistem

 

3.     Simulasi Proses Perubahan Kebutuhan

Penyebab Perubahan:
Perubahan terjadi karena pengguna menginginkan fitur pelacakan perjalanan secara real-time pada aplikasi transportasi online.

Evaluasi Dampak Perubahan:
Tim pengembang menganalisis pengaruh perubahan terhadap waktu pengembangan, biaya, serta kebutuhan teknis tambahan seperti integrasi GPS.

Langkah-Langkah Implementasi Perubahan:

1.     Mendokumentasikan perubahan kebutuhan secara resmi.

2.     Melakukan analisis dampak terhadap sistem yang sedang dikembangkan.

3.     Menyesuaikan desain dan spesifikasi kebutuhan.

4.     Mengimplementasikan perubahan dan melakukan pengujian ulang.

5.     Memvalidasi kembali hasil perubahan bersama pengguna.

 

 

Bagian 4 : Alat Bantu dalam Pengelolaan Kebutuhan Perangkat Lunak

1.     Identifikasi dan Penjelasan Alat Bantu

Tiga alat bantu yang umum digunakan dalam pengelolaan kebutuhan perangkat lunak adalah IBM DOORS, JIRA, dan Enterprise Architect.

·       IBM DOORS digunakan untuk mengelola kebutuhan secara terstruktur dan terdokumentasi dengan baik, terutama pada proyek berskala besar.

·       JIRA berfungsi sebagai alat manajemen proyek yang juga mendukung pencatatan dan pelacakan kebutuhan dalam bentuk issue atau backlog.

·       Enterprise Architect digunakan untuk memodelkan kebutuhan perangkat lunak dalam bentuk diagram dan dokumentasi berbasis UML.

2.     Perbandingan Alat Bantu Pengelolaan Kebutuhan

Nama Alat Bantu	Fitur Utama	Kelebihan	Kekurangan
IBM DOORS	Manajemen dan pelacakan kebutuhan	Cocok untuk proyek besar dan kompleks	Biaya lisensi mahal
JIRA	Pencatatan kebutuhan dan manajemen tugas	Mudah digunakan dan fleksibel	Tidak khusus untuk requirements
Enterprise Architect	Pemodelan UML dan dokumentasi	Visual dan terstruktur	Membutuhkan pemahaman teknis

 

3.     Alat Bantu yang Dipilih dan Alasan

Jika bekerja dalam tim pengembang perangkat lunak, alat bantu yang dipilih adalah JIRA. Alasannya karena JIRA mudah digunakan, mendukung kolaborasi tim, serta mampu mengelola perubahan kebutuhan secara dinamis melalui backlog dan sprint. Selain itu, JIRA cocok digunakan dalam metode pengembangan agile yang banyak diterapkan saat ini.

 

Kesimpulan dan Refleksi

1.     Kesimpulan

Berdasarkan pembahasan dalam lembar kerja ini, dapat disimpulkan bahwa pemahaman tentang software requirements merupakan faktor penting dalam keberhasilan pengembangan perangkat lunak. Analisis, spesifikasi, validasi, dan manajemen perubahan kebutuhan membantu memastikan sistem yang dibangun sesuai dengan kebutuhan pengguna serta mengurangi risiko kesalahan selama proses pengembangan.

2.     Refleksi Pribadi

Tantangan terbesar dalam memahami kebutuhan perangkat lunak adalah menyelaraskan kebutuhan pengguna dengan batasan teknis dan waktu pengembangan. Namun, dengan menerapkan teknik elicitation, validasi kebutuhan, dan penggunaan alat bantu yang tepat, tantangan tersebut dapat diminimalkan. Konsep yang dipelajari dapat diterapkan dalam proyek nyata untuk menghasilkan perangkat lunak yang lebih efektif dan sesuai kebutuhan pengguna.

Nama : Mutia ardelia rokhima

NIM : 240605110075