2. Rekayasa persyaratan adalah proses yang
melibatkan semua kegiatan yang dibutuhkan untuk
membuat dan memelihara dokumen persyratan system.
Ada empat kegiatan proses rekayasa persyaratan
tingkat tinggi yang generic :
• studi kelayakan system,
• esilitasi dan analisis persyaratan,
• penspesifikasian persyaratan dan dokumentasinya
,
• validitasi

3. Elisitasi dan
Studi
analisis
kelayakan
persyaratan
Spesifikasi
persyaratan
Laporan Validasi
kelayakan persyaratan
Model
Sistem Persyaratan
user dan sistem
Hubungan
elisitasi, dokumentasi, dan Dokumen
pemeriksaan persyaratan persyaratan

4. Proses rekayasa persyaratan harus
dimulai dengan studi kelayakan. Input bagi
studi kelayakan adalah deskripsi garis
besar system dan bagaimana system akan
digunakan di dalam organisasi.
Hasil studi kelayakan berwujud laporan
yang merekomendasikan apakah kegiatan
tersebut layak diteruskan dengan rekayasa
persyaratan dan proses pengembangan
system.

5. Studi kelayakan merupakan studi
singkat dan terfokus yang bertujuan untuk
menjawab sejumlah pertanyaan berikut:
• Apakah system memberikan kontribusi bagi
tujuan organisasi secara keseluruhan?
• Apakah system dapat diimplementasikan
dengan menggunakan teknologi terbaru dan
dalam batasan biaya dan jadwal?
• Apakah system dapat diintegrasi dengan
system lain ynag sudah ada?

6. Melakukan studi kelayakan mencakup
penilaian informasi, pengumpulan
informasi, dan penulisan laporan.
Fase penilaian informasi
mengidentifikasi informasi yang
dibutuhkan untuk menjawab pertanyaan
yang diberikan.

7. • Bagaimana organisasi mengatasi masalah jika system ini tidak
diimplementasi?
• Apa masalah dengan proses pada saat ini dan bagaimana system
yang baru bias membantu meringankan masalah ini?
• Apa kontribusi langsung yang akan diberikan system bagi
tujuan bisnis?
• Dapatkah informasi ditransfer ke dan dari system organisasi?
• Apakah system membutuhkan teknologi yang sebelumnya tidak
dipakai pada organisasi?

8. Elisitasi dan analisis persyaratan
dapat melibatkan berbagai macam orang
dalam organisasi.
Istilah stakeholder dipakai untuk
menyebutkan orang-orang yang memiliki
pengaruh langsung atau tidak pada
persyaratan system.
Elisitasi dan analisis sistem
mempunyai Tiga Teknik yaitu, Elisitasi
berorientasi sudut pandang, skenario dan
etnografi.

9. Untuk sistem berukuran menengah atau
besar, biasanya terdapat beberapa end-
user dengan tipe berbeda. Banyak
stakeholder yang memiliki kepentingan
terhadap persyaratan sistem.

10. • Nasabah bank pada saat itu yang menerima jasa dari sistem
• Representatif dari bank lain yang memiliki perjanjian timbal
balik yang memungkinkan menggunakan ATM bersama
• Manajer cabang-cabang bank yang mendapatkan informasi
manajemen dari sistem
• Staf counter pada cabang-cabang bank yang terlibat dalam
pengoperasian sistem dari hari ke hari, menangani keluhan
nasabah, dll
• Administrator database yang bertanggung jawab terhadap
integrasi sistem dengan database nasabah bank

11. • Manajer keamanan bank yang harus menjamin
bahwa sistem tidak akan menimbulkan
kekacauan keamanan dalam bentuk apapun
• Departemen pemasaran bank yang mungkin
tertarik untuk menggunakan sistem sebagai
cara untuk pemasaran bank
• Perekayasa pemeliharaan perangkat keras dan
lunak yang bertanggung jawab untuk
memelihara sistem dan meng-upgrade perangkat
keras dan lunak.

12. Setiap metode memiliki gagasan yang
berbeda mengenai apa yang dimaksud
dengan “sudut pandang”. Suatu sudut
pandang dapat dianggap sebagai :
• Sumber atau tempat masuknya data.
• Kerangka kerja representasi.
• Penerima layanan.

13. • Sudut pandang bersifat eksternal terhadap
sistem sehingga merupakan cara yang natural
untuk membentuk struktur proses elisitasi
persyaratan.
• Relatif mudah untuk memutuskan apakah suatu
sudut pandang bersifat valid.
• Sudut pandang dan layanan merupakan cara
yang berguna dalam penstrukturan persyaratan
non-fungsional. Setiap layanan bisa memiliki
persyaratan non-fungsional yang berhubungan.

14. Metode VORD (Viewpoint Oriented
Requirments Definition / definisi
persyaratan berorientasi sudut pandang)
telah dirancang sebagai kerangka kerja
berorientasi layanan untuk elisitasi
dan analisis persyaratan .

15. Pemetaan
Identifikasi Strukturisasi Dokumentasi
sistem sudut
sudut pandang sudut pandang sudut pandang
pandang

16. • Identifikasi sudut pandang, yang mencakup pencarian sudut
pandang yang menerima layanan sistem dan pengidentifikasian
layanan-layanan khusus yang diberikan bagi setiap sudut
pandang.
• Penstrukturan sudut pandang, yang mencakup pengelompokkan
sudut pandang yang berhubungan menjadi suatu hierarki.
• Dokumentasi sudut pandang, yang mencakup penyempurnaan
deskripsi sudut pandang dan layanan yang teridentifikasi.
• Pemetaan sistem sudut pandang, yang mencakup
pengidentifikasian objek pada desain berorientasi objek
dengan menggunakan informasi layanan yang dicakup dalam
sudut pandang.

17. Skenario adalah deskripsi sesi
interaksi contoh. Skenario bisa sangat
berguna untuk menambahkan detail garis
besar deskripsi persyaratan.
Skenario dimulai dengan garis besar
interaksi dan pada saat
elisitasi, detil ditambahkan untuk
menyusun deskripsi yang lengkap
mengenai interaksi tersebut

18. o deskripsi status sistem pada awal skenario
o deskripsi aliran event yang normal pada skenario
o deskripsi mengenai apa yang bisa salah dan bagaimana
o penanganannya
o informasi mengenai kegiatan lain yang bisa berlangsung
pada saat yang sama
o deskripsi status sistem setelah berakhirnya skenario.

19. Skenario event digunakan paa
VORD untuk mendokumentasikan
prilaku sistem jika dihadapkan
pada event-event tertentu.

20. • Data yang diberikan dari sudut pandang atau diberikan
ke sudut pandang digambarkan dengan elips.
• Informasi kontrol masuk dan keluar ada di atas setiap
kotak.
• Data keluar dari kanan setiap kotak. Jika tidak
tertutup, ini berarti bahwa data tersebut bersifat
internal bagi sistem.
• Eksepsi digambarkan di dasar kotak. Jika ada beberapa
eksepsi yang mungkin, seluruhnya dimasukkan dalam satu
kotak.
• Nama event berikutnya yang diharapkan setelah skenario
selesai ditunjukkan pada kotak yang diarsir.

21. Ada kartu
Kartu valid
User OK
Kartu
Minta PIN
PIN Validasi
PIN
nomor
user Nomor
account
Pilih
account
layanan
Waktu habis
Kembalikan
PIN salah
kartu
Masukkan ketika kartu
Kartu invalid ulang PIN dimasukkan, diminta nomor
Kembalikan identifikasi pribadi (PIN)
kartu nasabah. Nasabah
PIN salah memasukkan kartunya beserta
Kartu curian PIN. Jika kartu tersebut valid
Kembalikan yang dapat diproses oleh
Tahan kartu kartu
mesin, kontrol berlanjut
ketahap berikutnya.

22. Use-case adalah teknik berdasarkan
skenario untuk elisitasi persyaratan.
Use case sekarang telah menjadi fitur
dasr notasi UML untuk mendeskripsikan
model sistem berorientasi objek.

23. Layanan
Penyimpanan
aktor pada proses ini direpresentasikan sebagai gambar orang dan
setiap kelas interaksi direpresentasikan sebagai elips nama

24. Layanan
Penyimpanan
User
Administrasi
perpustakaan
user
Staf
Layanan perpustakaan
katalog
Pemasok sekumpulan use-case merepresentasikan semua
interaksi yang akan direpresentasikan

25. Etnografi adalah teknik observasi
yang dapat dipakai untuk memahami
persyaratan sosial dan organisasional.
Nilai etnografi membantu menemukan
persyaratan sistem yang implisit yang
merefleksikan proses sebenarnya, bukan
proses formal, dimana orang orang
terlibat.

26. • Persyaratan yang berasal dari cara
orang bekerja yang sebenarnya dan
bukan cara yang ditentukan oleh
definisi proses.
• Persyaratan yang berasal dari kerja
sama dan kesadaran akan kegiatan
orang lain.

27. Analisis Pertemuan Etnografi
etnografik Debriefing terfokus
Evaluasi
prototipe
Pengembangan Pembuatan
sistem generik prototipe sistem

28. Validasi persyaratan berkenaan
dengan pengidentifikasian bahwa
persyaratan benar-benar mendefinisikan
system yang diinginkan pelaggan.
Validasi harus berhubungan dengan
draft dokumen persyaratan yang
lengkap, sementara analisis melibatkan
pekerjaan dengan persyaratan yang tidak
lengkap.

29. Peninjauan persyaratan biasanya
merupakan proses manual yang melibatkan
banyak pembaca.
Proses ini dapat diorganisir dalam
skala yang lebih besar dengan banyak
partisipan yang terlibat dala
pemeriksaan bagian-bagian yang berbeda
dari dokumen tersebut.

30. Manajemen persyaratan adalah proses
pemahaman dam pengendalian perubahan
pada persyaratan system.
Proses manajemen persyaratan
dilakukan bersama dengan proses
rekayasa persyaratan yang lainnya.

31. Pengembangan persyaratan perangkat kunak
terpisat pada kemampuan perangkat
lunak, tujuan bisnis,lainnya. Sementara
definisi persyaratan dikembangkan pemahaman
yang lebih baik akan kebutuhan user akan
dicapai.
Pemahaman ini akan member informasi
kembali ke user, yang menyebabkan persyaratan
diubah. Lingkungan system dan tujuan bisnis
hamper pasti berubah-ubah. Dengan demikian
persyaratan berubah-ubah pula untuk
merefleksikan hal ini.

32. Perecanaan merupakan tahap pertama yang
pentigpada proses manajemen persyaratan.
Manajemen persyaratan sangat mahal dan untuk
setiap,tahap perencanaan menetapkan tingkat
rincian manajemen persyaratan yang diperlukan

33. • Identifikasi persyaratan. Setiap persyaratan harus
diidentifikasi dengan unik sehingga dapat direferensi
silang dengan persyaratan lain agar dapat digunakan
pada penilaian apakah dapat ditelusuri atau tidak.
• Proses manajemen perubahan. Ini merupakan serangkaian
kegiatan yang menilai dampak dan biaya perubahan.
• Kebijakan agar dapat ditelusuri yang mendefinisikan
hubungan antara persyaratandengan persyaratan dan
antara persyaratan dengan desain system yang harus
dicatat, dan bagaimana catatan ini harus dijaga.
• Dukungan alat bantu CASE (CASE tool). Alat bantu yang
digunakan berkisar dari system manajemen persyaratan
spesialis sampai spreadsheet dan system data base
sederhana.

34. • Informasi kemampuan penelusuran. Dipakai untuk
menemukan stakeholder yang bersangktan sehingga mereka
dapat dikontak perihal perubahan tersebut.
• Inforrmasi penelusuran persyaratan. Dipakai untuk
menilai seberapa banyak persyaratan yang mungkin
terpengaruh oleh perubahan yang diusulkan beserta
jangkauan perubahan persyaratan yang merupakan
konsekuensinya,yang mungkin diperlukan.
• Informasi ke-mamputelusu-an (traceability) desain.
Dipakai untuk menilai dampak perubahan persyaratan yang
diusulkan pada desain dan implementasi system.

35. • Penyimpanan Persyaratan. Persyaratan harus
disimpan pada tempat penyimpanan data yang aman
dan terpelihara, yang dapat diakses oleh semua
orang yang terlibat pada proses rekayasa
persyaratan.
• Manajemen perubahan. Proses manajemen perubahan
disederhanakan jika tersedia pendukung alat
bantu yang aktif.
• Manajemen penelusuran. Tersedia beberapa alat
bantu yang menggunakan teknik pemrosesan bahasa
natural untuk membantu menemukan hubungan yang
mungkin di antara persyaratan-paersyaratan.

36. Manajemen perubahan persyaratan
harus diterapkan pada semua perubahan
yang diusulkan untuk
persyaratan.Keuntungan penggunaan prose
formal untuk manajemen perubahan adalah
bahwa semua usulan perubahan diperlukan
dengan cara yang terkendali.

37. • Analisis masalah dan spesifikasi perubahan. Pada tahap
ini,masalah atau usulan perubahan dianalisis untuk
memerikasa validitasnya.
• Analisis dan perhitungan biaya perubahan. Biaya
melakukan perubahan diestimasi dalam hal modifikasi
terhadap dokuman persyaratan dan jika bias, terhadap
desain system dan implementasi.
• Implementasi perubahan. Dokumen persyaratan dan jika
diperlukan system dan implementasi dimodifikasi.
Dokumen persyaratan harus diorganisir sehingga perubahan
dapat diakomodasi tanpa banyak penulisan.