Requirements Modeling : Scenario-Based Methods

Requirements Analysis (analisis kebutuhan)

 Requirements analysis
 menentukan karakteristik operasional perangkat lunak.
 menunjukkan antarmuka perangkat lunak dengan elemen sistem lainnya.
 menetapkan batasan yang harus dipenuhi oleh perangkat lunak.
 Requirements analysis memungkinkan pengembang perangkat lunak (sebagai analyst or modeler
dalam perannya) untuk:
 menguraikan persyaratan awal yang ditetapkan pada pengelolaan permintaan/kebutuhan
sebelumnya.
 membangun model yang menggambarkan skenario pengguna, aktivitas fungsional, problem
Classes dan relasinya, perilaku class dan sistem, dan aliran data saat ditransformasikan
Requirements Modeling
 Scenario-based => sistem dari sudut pandang pengguna
 Data => Menunjukkan bagaimana data ditansformasikan di dalam sistem.
 Class-oriented => Mendefinisikan objek, atribut dan relasi
 Flow-oriented => Menunjukkan bagaimana data ditransformasikan di dalam sistem.
 Behavioral => Menunjukkan dampak peristiwa pada status system
Sebuah jembatan terdiri dari : system description, analysis model, design model saling berkaitan
Rules of Thumb (aturan praktis)
 Model harus fokus pada kebutuhan yang nampak dalam suatu masalah atau domain bisnis.
Tingkat abstraksi harus relatif tinggi.
 Setiap elemen dari model analisis harus menambahkan pemahaman menyeluruh dari kebutuhan
perangkat lunak memberikan wawasan tentang domain informasi, fungsi, dan perilaku sistem.
 Tunda pertimbangan infrastruktur dan model non fungsional lainnya sampai dengan tahap disain.
 Minimalkan coupling di seluruh sistem.
 Pastikan bahwa model analisis memberikan nilai bagi semua pemangku kepentingan.
 Pertahankan model sesederhana mungkin Model harus fokus pada kebutuhan yang nampak
dalam suatu masalah atau domain bisnis. Tingkat abstraksi harus relatif tinggi.
 Settiap elemen dari model analisis harus menambahkan pemahaman menyeluruh dari kebutuhan
perangkat lunak memberikan wawasan tentang domain informasi, fungsi, dan perilaku sistem.
 Tunda pertimbangan infrastruktur dan model non fungsional lainnya sampai dengan tahap disain.
 Minimalkan coupling di seluruh sistem.
 Pastikan bahwa model analisis memberikan nilai bagi semua pemangku kepentingan.
 Pertahankan model sesederhana mungkin
Domain Analysis
Domain analisis perangkat lunak adalah identifikasi, analisis, dan spesifikasi persyaratan umum dari
domain aplikasi tertentu, biasanya untuk digunakan kembali pada beberapa proyek dalam domain
aplikasi tersebut.
Domain Analysis
 Tentukan domain yang akan diselidiki.
 Kumpulkan contoh aplikasi yang representatif di domain.
 Analisis setiap aplikasi dalam sampel.
 Kembangkan model analisis untuk objek
Scenario-Based Modeling
“[Kasus penggunaan] hanyalah bantuan untuk mendefinisikan apa yang ada di luar sistem (aktor) dan
apa yang harus dilakukan oleh sistem (kasus penggunaan).” Ivar Jacobson
Apa yang harus ditulis?
 Inception dan elicitation (permulaan & elisitasi) - memberi informasi yang Anda perlukan untuk
mulai membuat use case.
 Requirements gathering meetings, QFD, dan mekanisme requirements engineering lainnya
digunakan untuk
  mengidentifikasi stakeholders
 mendefinisikan ruang lingkup masalah
 tentukan tujuan operasional keseluruhan
 menetapkan prioritas
 garis besar semua persyaratan fungsional yang diketahui, dan
 menggambarkan hal-hal (objek) yang akan dimanipulasi oleh sistem.
 Untuk mulai mengembangkan sekelompok use case, buat daftar fungsi atau aktivitas yang
dilakukan oleh aktor tertentu
Berapa banyak yang harus ditulis?
 Saat pembicaraan lebih lanjut dengan para pemangku kepentingan berlangsung, tim pengumpul
kebutuhan mengembangkan use case untuk setiap fungsi yang dicatat.
 Secara umum, use case ditulis pertama dengan cara naratif informal.
 Jika lebih banyak formalitas diperlukan, use case yang sama ditulis ulang menggunakan format
terstruktur yang mirip dengan yang diusulkan.
Use-Cases (kasus penggunaan)
 skenario yang menggambarkan “thread of usage" untuk suatu sistem aktor mewakili peran yang
dimainkan orang atau perangkat sebagai fungsi sistem pengguna dapat memainkan sejumlah
peran berbeda untuk skenario yang diberikan.
 Aktor merepresentasikan peran yang dimainkan orang atau perangkat sebagai fungsi system
 Pengguna dapat memainkan sejumlah skenario yang diberikan.
Developing a Use-Case (menggambarkan kasus penggunaan)
 Apa tugas atau fungsi utama yang dilakukan oleh aktor?
 Sistem informasi apa yang akan diperoleh, diproduksi, atau diubah oleh aktor?
 Apakah aktor harus memberi tahu sistem tentang perubahan di lingkungan eksternal?
 Informasi apa yang diinginkan aktor dari sistem?
 Apakah aktor ingin diberi tahu tentang perubahan yang tidak terduga?
Reviewing a Use-Case
 Use-case ditulis pertama kali dalam bentuk naratif dan dipetakan ke templat jika formalitas
diperlukan
 Setiap skenario primer harus ditinjau dan disempurnakan untuk melihat apakah interaksi
alternatif dimungkinkan
 Bisakah aktor mengambil tindakan lain pada saat ini?
 Mungkinkah aktor akan mengalami kondisi kesalahan di beberapa titik? Jika ya, apa?
 Mungkinkah aktor akan menghadapi perilaku lain di beberapa titik? Jika ya, apa?
Exceptions (pengecualian)
 Menjelaskan situasi (kegagalan atau pilihan pengguna) yang menyebabkan sistem menunjukkan
perilaku yang tidak biasa
 Brainstorming harus digunakan untuk mendapatkan serangkaian pengecualian yang cukup
lengkap untuk setiap kasus penggunaan
 Apakah ada kasus di mana fungsi validasi terjadi untuk use case?
 Apakah ada kasus di mana fungsi pendukung (aktor) gagal merespons dengan tepat?
 Dapatkah kinerja sistem yang buruk menghasilkan tindakan penggunaan yang tidak terduga
atau tidak tepat?
 Menangani pengecualian mungkin membutuhkan pembuatan case use tambahan
Activity Diagram
Suplemen use case dengan menyediakan representasi grafis dari aliran interaksi dalam skenario
tertentu.
Swimlane Diagrams
Mengizinkan pemodel untuk mewakili aliran aktivitas yang dijelaskan oleh use-case dan pada saat
yang sama menunjukkan aktor mana (jika ada beberapa aktor yang terlibat dalam use-case tertentu)
atau kelas analisis memiliki tanggung jawab untuk tindakan yang dijelaskan oleh sebuah persegi
panjang aktivitas .