Kebutuhan Dokumentasi

Pertemuan Minggu Kedua

Tim Pengajar:
Deddy Kusbianto
Elok Nur Hamdana
Apa persyaratannya?

• Spesifikasi apa yang harus diterapkan

• Didefinisikan pada tahap awal pengembangan sistem
• Termasuk:
• bagaimana sistem seharusnya berperilaku
• informasi domain aplikasi
• kendala pada operasi sistem
• spesifikasi properti sistem atau atribut.
Apa itu proses rekayasa persyaratan?

• Proses rekayasa persyaratan adalah serangkaian kegiatan

terstruktur yang diikuti untuk memperoleh, memvalidasi, dan
memelihara dokumen persyaratan sistem. Kegiatannya
meliputi:
• Perolehan persyaratan
• Analisis persyaratan dan negosiasi
• Dokumentasi persyaratan
• Validasi persyaratan
Persyaratan teknik perolehan

• Persyaratan sistem ditemukan melalui konsultasi dengan pemangku

kepentingan, dari dokumen sistem, pengetahuan domain
• Nama-nama lain adalah 'akuisisi persyaratan' atau 'penemuan kebutuhan ‘
• Wawancara
• Loop tertutup: pewawancara mencari jawaban untuk serangkaian
pertanyaan yang telah ditentukan sebelumnya
• Open loop: tidak ada agenda yang telah ditentukan dan diskusi
dilakukan secara terbuka.
Skenario
• Kisah tentang bagaimana sistem akan digunakan
• Pengguna akhir dan pemangku kepentingan lainnya merasa lebih
mudah untuk berhubungan dengan contoh-contoh kehidupan nyata
daripada deskripsi abstrak dari fungsi suatu sistem
• Mereka setidaknya harus mencakup:
• Deskripsi kondisi sistem sebelum memasuki skenario
• Alur peristiwa normal dalam skenario
• Pengecualian untuk aliran peristiwa normal
• Informasi tentang kegiatan lain yang mungkin terjadi pada saat
bersamaan
• Deskripsi keadaan sistem setelah skenario
Contoh skenario
Skenario pemesanan laporan dari perpustakaan:
• Catatan pengguna sistem
• Dokumen pengeluaran pesanan
• Nomor referensi dokumen yang dimasukkan
• Opsi pemilihan pengiriman
• Pengguna keluar.
• Pengecualian: jika nomor referensi salah, pengguna
ditawari untuk memasukkan referensi dokumen atau
meminta bantuan sistem.
Persyaratan Penggunaan Kembali
• Praktik yang baik untuk menggunakan kembali sebanyak mungkin
pengetahuan saat mengembangkan sistem baru
• Meskipun persyaratan untuk setiap sistem berbeda, ada beberapa
situasi di mana penggunaan kembali dimungkinkan:
• Di mana persyaratan berkaitan dengan penyediaan informasi
tentang domain aplikasi, mis. kendala pada sistem.
• Dimana persyaratannya berkaitan dengan gaya penyajian informasi,
seperti antarmuka pengguna dari keseluruhan sistem untuk suatu
organisasi.
• Dimana persyaratan mencerminkan kebijakan perusahaan seperti
persyaratan keamanan.
Prototyping
• Versi awal dari sistem yang tersedia di awal proses pengembangan
• Membantu memperoleh dan memvalidasi persyaratan sistem
• Prototipe 'membuang' yang digunakan untuk membantu memperoleh dan
menganalisis persyaratan sering disebut
• Sebaliknya, prototipe evolusioner dimaksudkan untuk memberikan sistem
yang bisa diterapkan dengan cepat kepada pelanggan
• Prototipe membantu menetapkan kelayakan dan kegunaan keseluruhan
sistem
• Satu-satunya cara efektif untuk mengembangkan antarmuka pengguna
sistem.
• Dimungkinkan untuk digunakan dalam pengujian sistem nanti dalam
proses validasi
Analisis persyaratan dan negosiasi

• Bertujuan menemukan masalah dengan persyaratan sistem dan mencapai

kesepakatan tentang perubahan untuk memuaskan semua pemangku
kepentingan sistem
• Persyaratan dianalisis secara rinci
• Para pemangku kepentingan yang berbeda bernegosiasi untuk
memutuskan persyaratan mana yang harus diterima
• Karena ada konflik yang tidak dapat dihindari antara persyaratan dari
sumber yang berbeda, informasi mungkin tidak lengkap atau mungkin tidak
sesuai dengan anggaran yang tersedia
Daftar periksa analisis
Daftar pertanyaan yang dapat digunakan analis untuk menilai
persyaratan. Beberapa item dalam daftar ini mungkin:
• Desain prematur
• Persyaratan gabungan
• Persyaratan yang tidak perlu
• Penggunaan perangkat lunak / perangkat keras non-standar
• Ambiguitas persyaratan
• Kesesuaian dengan aturan bisnis
• Persyaratan testabilitas
• Persyaratan realisme
Matriks interaksi
• Digunakan untuk menemukan interaksi antara persyaratan dan untuk menyoroti konflik
dan tumpang tindih persyaratan
• Jika kita tidak dapat berasumsi bahwa konflik tidak ada, kita harus berasumsi bahwa ada
potensi konflik
• Konflik yang tidak terdeteksi jauh lebih mahal untuk diselesaikan

Requirement R1 R2 R3 R4 R5 R6

R1 - - O - C C

R2 - - - - - -

R3 O - - O - O

R4 - - O - C C

R5 C - - C - - O: OVERLAP
C: CONFLICT
R6 C - O C - -
Negosiasi dan Dokumentasi persyaratan
• Membahas konflik dan menemukan beberapa kompromi yang dapat dijalani oleh
semua pemangku kepentingan
• Rapat adalah cara paling efektif. Rapat harus dilakukan dalam tiga tahap:
• Tahap informasi, menjelaskan sifat masalah
• Tahap diskusi, di mana pemangku kepentingan mendiskusikan solusi yang memungkinkan
• Tahap penyelesaian, di mana tindakan mengenai persyaratan disepakati
• Ada banyak cara berbeda untuk menyusun dokumen persyaratan, tergantung
pada:
• Jenis sistem yang dikembangkan
• Tingkat detail termasuk
• Praktik organisasi
• Anggaran
• Susunan acara
Template Standar
• Memastikan bahwa semua informasi penting disertakan
• Sejumlah organisasi besar yang berbeda seperti Departemen
Pertahanan AS dan IEEE telah menetapkan standar untuk dokumen
persyaratan
• Mungkin yang paling dapat diterima dari standar-standar ini adalah
IEEE / ANSI 830-1993
• Standar mengenali perbedaan antara sistem, dan memungkinkan untuk
beberapa variasi dalam struktur.
• Ada daftar bagian yang stabil dan varian:
• Bagian yang stabil
• Bagian varian
IEEE/ANSI 830 - 1993
• Pengantar:
• Tujuan dari dokumen persyaratan
• Lingkup produk
• Definisi, akronim dan singkatan
• Referensi
• Tinjauan umum sisa dokumen
• Gambaran umum:
• Perspektif produk
• Fungsi produk
• Karakteristik pengguna
• Kendala umum
• Asumsi dan dependensi
• Persyaratan khusus
• Meliputi persyaratan fungsional,
non-fungsional, dan antarmuka.
Ini harus mencakup antarmuka
eksternal, fungsionalitas,
persyaratan kinerja, persyaratan
logis, kendala desain, atribut
sistem, dan karakteristik kualitas
• Lampiran
• Indeks
Templat yang didasarkan pada IEEE / ANSI 830 - 1993
• Kata pengantar
• pengantar
Definisi produk, penggunaan yang
diharapkan, dan tinjauan
fungsionalitasnya
• Glosarium
Definisi istilah teknis dan
singkatan yang digunakan
• Persyaratan pengguna umum
Persyaratan sistem dari perspektif
pengguna
• Sistem arsitektur
Tinjauan tingkat tinggi arsitektur
sistem yang diantisipasi,
menunjukkan distribusi fungsi di
seluruh modul sistem
• Spesifikasi perangkat keras
Bagian opsional untuk menetapkan perangkat keras
yang akan dikontrol oleh sistem perangkat lunak
• Spesifikasi perangkat lunak terperinci
Penjelasan terperinci tentang fungsionalitas sistem
yang diharapkan
• Persyaratan keandalan dan kinerja
Menjelaskan keandalan dan kinerja yang diharapkan.
• Lampiran untuk
• Spesifikasi antarmuka perangkat keras
• Komponen perangkat lunak
• Spesifikasi struktur data
• Model aliran data dari sistem perangkat lunak
• Model objek terperinci dari sistem perangkat lunak
• Indeks
Validasi persyaratan
• Output proses adalah sebagai berikut:
• Daftar masalah
• Solusi yang disepakati
• Teknik untuk validasi persyaratan:
Ulasan persyaratan: Melibatkan sekelompok orang yang membaca
dan menganalisis persyaratan
• Pemeriksaan pra-tinjauan: satu orang melakukan pemeriksaan
standar cepat untuk memastikan bahwa struktur dokumen
konsisten dengan standar yang ditetapkan
• Tinjau keanggotaan tim: Para pemangku kepentingan dari berbagai
disiplin ilmu harus dilibatkan
Aktor dalam proses rekayasa persyaratan
• Pakar domain: memberikan informasi tentang domain aplikasi dan masalah khusus
dalam domain tersebut yang harus diselesaikan
• Pengguna akhir sistem: akan menggunakan sistem setelah pengiriman
• Insinyur kebutuhan: memperoleh dan menetapkan persyaratan
• Insinyur perangkat lunak: bertanggung jawab untuk mengembangkan sistem
perangkat lunak
• Manajer proyek: merencanakan dan memperkirakan proyek pembuatan prototipe

Masalah umum dalam persyaratan penulisan

• Persyaratan ditulis dalam klausa kondisional kompleks yang membingungkan
• Terminologi digunakan dengan cara yang ceroboh dan tidak konsisten
• Penulis persyaratan berasumsi bahwa pembaca memiliki pengetahuan khusus
tentang domain sistem dan dapat meninggalkan beberapa informasi penting
Hal-hal yang harus diingat penulis
• Persyaratan dibaca lebih sering daripada yang tertulis. Investasikan lebih banyak
upaya untuk menulis dokumen yang mudah dibaca dan dipahami
• Pembaca persyaratan berasal dari beragam latar belakang. Jangan berasumsi bahwa
pembaca memiliki latar belakang dan pengetahuan yang sama dengan Anda
• Menulis dengan jelas dan singkat tidak mudah. Berikan waktu yang cukup untuk
penyusunan dan peninjauan

Pedoman
• Tetapkan templat standar untuk menggambarkan persyaratan
• Gunakan bahasa secara sederhana, singkat dan konsisten. Gunakan kalimat dan
paragraf pendek
• Gunakan diagram secara tepat untuk menyajikan ikhtisar dan hubungan antar entitas
• Tentukan persyaratan secara kuantitatif (jumlah pengguna, persyaratan waktu respons,
dll.)
TUGAS
Buat Dokumen Manual yang telah kalian siapkan pada pertemuan
sebelumnya sesuai templat yang didasarkan pada IEEE / ANSI 830 -
1993
Terimakasih

(Tim Pengajar):
Deddy Kusbianto
Elok Nur Hamdana