Dokumen tersebut membahas tentang analisis kebutuhan perangkat lunak untuk sistem penjualan. Ia menjelaskan pentingnya memahami kebutuhan pengguna dan proses bisnis untuk mengembangkan perangkat lunak yang sesuai. Dokumen ini juga memberikan panduan untuk mengumpulkan, menganalisis, dan memodelkan kebutuhan secara sistematis.

1. PROSES BISNIS DAN
SOFTWARE REQUIREMENTS
ANIS R. AMNA

2. User Requirements dan Software
Requirements
User Requirements
 Fitur yang harus dimiliki sistem
 Contoh:
 Kasir menginputkan penjualan
 Kasir mencetak laporan penjualan
harian
Software Requirements
 Kemampuan yang harus dimiliki
sistem untuk menyediakan fitur yang
dibutuhkan user
 Contoh:
 Sistem mampu menyimpan data
penjualan yang diinputkan user
 Sistem mampu menampilkan data
penjualan harian, mingguan, dan
periodik sesuai permintaan user
 Sistem dapat mencetak laporan
penjualan harian

3. Mengapa Butuh Analisis Requirements
 Memastikan bahwa sistem yang dikembangkan sesuai kebutuhan user
 Memastikan bahwa organisasi dapat menyimpan datanya dengan aman
 Memastikan sistem dapat menyediakan fitur sesuai kebutuhan user
 Memastikan sistem yang dikembangkan dapat dipahami oleh pengguna sebagai
sarana untuk mendukung proses bisnis

4. Bagaimana Menghasilkan Analisis
Requirements yang Baik?
 Melakukan interview dengan user
 Memahami proses bisnis yang ada di dalam organisasi
 Mengkomunikasikan hasil survey dengan user

5. Yang harus dilakukan ketika Survey
 Persiapan
 Fokus pada kata-kata narasumber
 Gunakan fasilitatorKomunikasi face to face
 Take notes dan buat kesimpulan di akhir pertemuan
 Berkolaborasi
 Tetap fokus pada topik
 Jika ada yang tidak dipahami, gambarkan dan pastikan
 Apapun yang terjadi, baik setuju atau tidak, lanjutkan ke pertanyaan
berikutnya
 Negosiasi

6. Prinsip Perencanaan
 Tentukan scope
 Libatkan stakeholder pada aktivitas planning
 Pahamkan bahwa perencanaan merupakan proses iterative
 Estimasikan biaya, kebutuhan SDM, waktu yang diperlukan untuk
menyelesaikan project berdasarkan kondisi tim
 Pahami resiko yang kemungkinan muncul
 Realistis
 Tambahkan detil-detil penting secara bertahap
 Definisikan penilaian kualitas
 Deskripsikan bagaimana Anda akan mengakomodasi perubahan
 Selalu evaluasi proses

7. Manfaat Analisis Requirements yang Baik
 Meningkatkan akurasi dan produktivitas selama pengembangan software
 Mempermudah pemahaman terhadap struktur dan behavior software
 Memastikan proses desain sesuai kebutuhan user
 Memberikan peta pengembangan software yang jelas baik untuk user maupun developer
 Meningkatkan kualitas software dan pengujian perangkat lunak
 Pengujian dapat dilakukan dengan cepat
 Membantu penguji untuk memahami apa yang harus dilakukan sistem pada kondisi
tertentu untuk memenuhi kebutuhan user
 Mempermudah penguji untuk mengetes berbagai kondisi tergantung siapa pengguna
sistem
 Memberikan nilai tambah bagi organisasi
 Mempermudah organisasi untuk memahami bagaimana mekanisme penyimpanan data
intelektual mereka di dalam sistem yang kompleks
 Mempermudah proses pengembangan dan maintenance

8. Analisis Requirements berisi beberapa
hal
 Sudut pandang secara abstrak dari sisi user
 Sudut pandang struktural dari sisi software arsitekture
 Sudut pandang dinamis dari sisi pengembang

9. Syarat Analisis Requirements
 Benar
 Tidak ambigu
 Dapat diverifikasi
 Dapat dilacak
 Lengkap
 Konsisten
 Dapat dimodifikasi
 Detil

10. Karakteristik Kebutuhan yang Baik :
Tidak Ambigu
Contoh kalimat ambigu
 Sistem hanya dapat menyimpan
maksimal 5 data yang diinput pada
saat bersamaan dan data yang
paling awal diinput harus dapat
disimpan
 Sistem harus dapat mengirimkan
pesan terkait updating data barang
dari GDG ke penjualan
Contoh kalimat tidak ambigu
 Sistem dapat menyimpan maksimal
5 data pada saat bersamaan
 Sistem harus menyimpan data yang
diinputkan pada antrian paling
awal
 Sistem gudang melakukan update
data barang
 Sistem gudang mengirimkan
informasi update data barang ke
penjualan

11. Prinsip Pemodelan
 Tujuan utama adalah membuat software, bukan model
 Jangan memodelkan lebih dari kebutuhan
 Buat model yang mendukung perubahan teknologi/requirements
 Tuliskan dengan jelas tujuan pembuatan model
 Adaptasikan model yang dibuat dengan sistem yang dibangun
 Cukup bangun model yang berguna, bukan yang perfect
 Segera konsultasikan model yang dibuat untuk memastikan model dapat
dideploy

12. Analisis Kebutuhan Software
 Domain problem
 Fungsi software
 Perilaku software
 Dapat dimodelkan dalam bentuk hierarki/layer
 Informasi dasar  detail implementasi

13. Prinsip Analisis - Desain
 Analisis requirements  traceable ke desain  deploy
 Mempertimbangkan arsitektur sistem yang akan dibangun
 Desain data, desain proses dan fungsi
 Desain interface internal dan eksternal
 Desain GUI harus mudah dipahami user
 Component-level design  kebutuhan fungsional
 Komponen harus memiliki ketergantungan satu sama lain dan lingkungan luar
 Model harus mudah dipahami
 Proses design dibuat secara iterative

14. Prinsip Koding
 Sebelum memulai koding
 Pahami masalah
 Pilih bahasa pemrograman sesuai kebutuhan software dan lingkungan
 Pilih lingkungan pemrograman yang menyediakan tools yang dibutuhkan
 Buat sekumpulan unit test sebagai testing
 Saat mengkoding
 Pilih struktur data sesuai desain
 Buat logika sesimpel mungkin
 Gunakan nested loop untuk mempermudah testing
 Pilih nama variabel yang mudah dipahami
 Buat self-documenting
 Buat visual layout yang memudahkan pemahaman

15. Prinsip Testing
 Traceable sesuai kebutuhan customer
 Terencana
 Pareto principles
 Mulai dari komponen terkecil
 Memastikan logika sudah benar
 Testing ke semua modul
 Gunakan dokumentasi
 Track uncovered defect
 Lakukan test case untuk memastikan behavior sistem

16. Contoh Pemodelan – Robustness Diagram

17. Contoh Pemodelan – Sequential Diagram

18. Contoh Pemodelan - GUI