Untuk menggambarkan kegiatan rekayasa persyaratan pokok dan
hubungan mereka. Untuk memperkenalkan teknik untuk elisitasi persyaratan dan analisis. Untuk
menjelaskan
validasi
persyaratan
dan
peran
tinjauan
persyaratan. Untuk membahas peran persyaratan manajemen dalam mendukung
proses rekayasa persyaratan lain.
Studi kelayakan
Persyaratan elisitasi dan analisis Persyaratan validasi
Persyaratan manajemen
Proses yang digunakan untuk RE sangat bervariasi tergantung pada
domain aplikasi, orang yang terlibat dan organisasi mengembangkan persyaratan. Namun, ada sejumlah aktivitas generik umum untuk semua proses Persyaratan elisitasi; Persyaratan analisis; Persyaratan validasi; Persyaratan manajemen.
Sebuah studi kelayakan memutuskan apakah sistem yang diusulkan
adalah berharga. Sebuah studi difokuskan singkat yang memeriksa Jika sistem memberikan kontribusi kepada tujuan organisasi; Jika sistem tersebut dapat direkayasa dengan menggunakan
teknologi saat ini dan sesuai dengan anggaran; Jika sistem dapat diintegrasikan dengan sistem lain yang digunakan.
Berdasarkan penilaian informasi (apa yang diperlukan), pengumpulan
informasi dan penulisan laporan. Pertanyaan untuk orang-orang dalam organisasi a)
Bagaimana jika sistem tidak diimplementasikan?
b)
Apa masalah proses saat ini?
c)
Bagaimana bantuan sistem yang diusulkan?
d)
Apa yang akan menjadi masalah integrasi?
e)
Adalah teknologi baru yang dibutuhkan? Keterampilan apa?
f)
Fasilitas apa harus didukung oleh sistem yang diusulkan?
Kadang-kadang
disebut
elisitasi
persyaratan
atau
penemuan
persyaratan. Melibatkan staf teknis bekerja dengan pelanggan untuk mencari tahu
tentang domain aplikasi, layanan bahwa sistem harus menyediakan dan kendala operasional sistem. Mungkin melibatkan pengguna akhir, manajer, insinyur yang terlibat
dalam perawatan, ahli domain, serikat buruh, dll disebut stakeholder.
1)
Stakeholder tidak tahu apa yang mereka inginkan.
2)
Pemangku kepentingan menyatakan persyaratan dalam istilah mereka sendiri.
3)
Pemangku kepentingan yang berbeda mungkin memiliki kebutuhan yang saling bertentangan.
4)
Organisasi
dan
faktor-faktor
politik
dapat
mempengaruhi
persyaratan sistem. 5)
Persyaratan berubah selama proses analisis. Stakeholder baru mungkin muncul dan perubahan lingkungan bisnis.
Persyaratan penemuan Berinteraksi dengan pemangku kepentingan untuk menemukan kebutuhan
mereka. Persyaratan Domain juga ditemukan pada tahap ini. Persyaratan klasifikasi dan organisasi Groups persyaratan yang berkaitan dan mengatur mereka ke dalam cluster
yang koheren. Prioritas dan negosiasi Memprioritaskan persyaratan dan menyelesaikan konflik persyaratan.
Persyaratan dokumentasi Persyaratan didokumentasikan dan masukan ke putaran berikutnya spiral.
Proses pengumpulan informasi tentang sistem yang diusulkan
dan penyulingan ada dan kebutuhan pengguna dan sistem dari informasi ini. Sumber informasi termasuk dokumentasi, stakeholder sistem dan
spesifikasi sistem yang sama.
1)
Nasabah bank
2)
Perwakilan dari bank lain
3)
Manajer bank
4)
Counter staf
5)
Database administrator
6)
Keamanan manajer
7)
Pemasaran departemen
8)
Perangkat keras dan perangkat lunak insinyur pemeliharaan
9)
Perbankan regulator
Sudut pandang adalah cara penataan persyaratan untuk mewakili
perspektif pemangku kepentingan yang berbeda. Stakeholder dapat diklasifikasikan dalam sudut pandang yang berbeda. Analisis multi-perspektif ini penting karena tidak ada cara yang
benar untuk menganalisis persyaratan sistem.
Interactor sudut pandang
Orang atau sistem lain yang berinteraksi langsung dengan sistem. Dalam ATM, pelanggan dan database rekening adalah VP interactor.
Langsung sudut pandang
Stakeholders yang tidak menggunakan sistem sendiri, tetapi yang mempengaruhi persyaratan. Dalam ATM, manajemen dan staf keamanan
pandangan langsung.
Domain sudut pandang
Domain karakteristik dan kendala yang mempengaruhi persyaratan.
Dalam ATM, sebuah contoh akan standar untuk komunikasi antar-bank.
Mengidentifikasi sudut pandang menggunakan Penyedia dan penerima layanan sistem; Sistem yang berinteraksi langsung dengan sistem yang ditetapkan;
Peraturan dan standar; Sumber kebutuhan bisnis dan non-fungsional; Insinyur yang harus mengembangkan dan memelihara sistem; Pemasaran dan sudut pandang bisnis lainnya.
Dalam formal maupun informal wawancara, tim RE menempatkan
pertanyaan kepada para pemangku kepentingan tentang sistem yang mereka gunakan dan sistem untuk dikembangkan. Ada dua jenis wawancara Wawancara Tertutup di mana satu set pre-defined pertanyaan
dijawab. Buka wawancara dimana tidak ada agenda pra-pasti dan
berbagai isu yang dieksplorasi dengan para stakeholder.
Biasanya campuran tertutup dan terbuka wawancara. Wawancara yang baik untuk mendapatkan pemahaman menyeluruh
tentang apa stakeholder dilakukan dan bagaimana mereka bisa berinteraksi dengan sistem. Wawancara tidak baik untuk memahami persyaratan domain Persyaratan
insinyur tidak bisa memahami domain spesifik
terminologi; Beberapa pengetahuan domain adalah begitu akrab bahwa orang
merasa sulit untuk mengartikulasikan atau berpikir bahwa itu tidak
layak mengartikulasikan.
Pewawancara harus berpikiran terbuka, mau mendengarkan
stakeholders dan tidak boleh memiliki ide pra-dipahami tentang persyaratan. Mereka harus prompt yang diwawancarai dengan pertanyaan atau
proposal dan tidak boleh hanya mengharapkan mereka untuk menanggapi pertanyaan seperti 'apa yang Anda inginkan'.
Skenario adalah kehidupan nyata contoh bagaimana sistem dapat
digunakan. Mereka harus mencakup : Penjelasan mengenai situasi awal;
Penjelasan dari aliran normal peristiwa; Penjelasan tentang apa yang bisa salah; Informasi berbarengan kegiatan tentang lainnya; Penjelasan negara ketika skenario selesai.
Asumsi awal: Pengguna telah login ke sistem LIBSYS dan telah terletak jurnal yang berisi salinan artikel. Normal: Pengguna memilih pakaian yang akan disalin. Dia kemudian diminta oleh sistem baik untuk memberikan informasi pelanggan untuk jurnal atau untuk menunjukkan bagaimana mereka akan membayar untuk artikel ini. Metode pembayaran alternatif dengan kartu kredit atau dengan mengutip nomor rekening organisasi. Pengguna kemudian diminta untuk mengisi formulir hak cipta yang memelihara rincian transaksi dan mereka kemudian menyerahkan ini ke sistem LIBSYS. Bentuk hak cipta diperiksa dan, jika OK, versi PDF dari artikel di-download ke LIBSYS wilayah kerja pada komputer pengguna dan pengguna diberitahu bahwa tersedia. Pengguna diminta untuk memilih printer dan salinan dari artikel tersebut dicetak. Jika artikel telah ditandai sebagai 'cetak hanya' itu dihapus dari sistem pengguna setelah pengguna telah mengkonfirmasi bahwa pencetakan selesai.
Apa yang bisa salah: Pengguna dapat gagal mengisi formulir hak cipta benar. Dalam hal ini, formulir harus kembali disampaikan kepada pengguna untuk koreksi. Jika formulir dikirim kembali masih benar maka permintaan pengguna untuk artikel ini ditolak. Pembayaran dapat ditolak oleh sistem. Permintaan pengguna untuk artikel ini ditolak.
Download artikel mungkin gagal. Coba lagi sampai berhasil atau pengguna mengakhiri sesi. Mungkin tidak mungkin untuk mencetak artikel. Jika artikel tersebut tidak ditandai sebagai 'cetak hanya' maka diadakan di ruang kerja LIBSYS. Jika tidak, artikel dihapus dan
account pengguna dikreditkan dengan biaya artikel. Kegiatan lain: download Simultan barang lainnya. Sistem negara pada saat penyelesaian: User ini login. Artikel download telah dihapus dari LIBSYS ruang kerja jika sudah ditandai sebagai cetak saja.
Gunakan-kasus
mengidentifikasi
teknik
skenario
para
pelaku
yang dalam
berbasis
di
interaksi
UML
yang
dan
yang
menggambarkan interaksi itu sendiri. Satu set kasus penggunaan harus menjelaskan semua kemungkinan
interaksi dengan sistem. Sequence diagram dapat digunakan untuk menambahkan rincian untuk
menggunakan-kasus dengan menunjukkan urutan pengolahan acara dalam sistem.
Software sistem yang digunakan dalam konteks sosial dan organisasi.
Hal ini dapat mempengaruhi atau bahkan mendominasi persyaratan sistem. Sosial dan faktor-faktor organisasi tidak satu sudut pandang tetapi
pengaruh pada semua sudut pandang. Analis yang baik harus peka terhadap faktor-faktor namun saat ini tidak
ada cara sistematis untuk mengatasi analisis mereka.
Seorang ilmuwan sosial menghabiskan waktu yang cukup lama
mengamati dan menganalisis bagaimana orang benar-benar bekerja. Orang tidak perlu menjelaskan atau mengartikulasikan pekerjaan
mereka. Sosial dan faktor organisasi yang penting dapat diamati. Studi Etnografi telah menunjukkan bahwa pekerjaan biasanya lebih
kaya dan lebih kompleks daripada yang disarankan oleh model sistem sederhana.
• Dikembangkan dalam proyek mempelajari proses kontrol lalu lintas
udara. • Menggabungkan etnografi dengan prototyping
• Prototipe hasil pembangunan dalam pertanyaan yang belum terjawab
yang fokus analisis etnografi. • Masalah dengan etnografi adalah bahwa hal itu studi praktek-praktek
yang ada yang mungkin memiliki dasar historis yang tidak lagi relevan.
Persyaratan yang berasal dari cara orang-orang benar-
benar bekerja daripada cara saya yang definisi proses menunjukkan bahwa mereka harus bekerja. Persyaratan yang berasal dari kerjasama dan kesadaran
kegiatan orang lain.
Prihatin dengan menunjukkan bahwa persyaratan sistem
menentukan bahwa pelanggan benar-benar ingin. Biaya kesalahan Persyaratan yang tinggi sehingga validasi
sangat penting Memperbaiki kesalahan persyaratan setelah melahirkan
mungkin biaya hingga 100 kali biaya memperbaiki kesalahan implementasi.
1)
Validitas.
Apakah
sistem
menyediakan
fungsi
yang
paling
mendukung kebutuhan pelanggan? 2)
Konsistensi. Apakah ada konflik persyaratan?
3)
Kelengkapan. Apakah semua fungsi yang dibutuhkan oleh pelanggan disertakan?
4)
Realisme. Dapatkah persyaratan diterapkan diberikan anggaran yang tersedia dan teknologi
5)
Verifiability. Dapatkah persyaratan diperiksa?
Persyaratan tinjauan Sistematis manual analisis persyaratan. Prototyping Dengan menggunakan model eksekusi dari sistem untuk memeriksa
persyaratan. Dibahas di Bab 17. Uji kasus generasi Mengembangkan
testability.
tes
untuk
persyaratan
untuk
memeriksa
Tinjauan rutin harus dilakukan sementara definisi persyaratan sedang
dirumuskan. Kedua staf klien dan kontraktor harus dilibatkan dalam tinjauan. Tinjauan mungkin formal (dengan dokumen lengkap) atau informal.
Komunikasi yang baik antara pengembang, pelanggan dan pengguna dapat menyelesaikan masalah-masalah pada tahap awal.
Verifiability. Apakah persyaratan realistis diuji? Komprehensibilitas. Apakah persyaratan dengan benar dipahami? Ketertelusuran. Apakah asal persyaratan dinyatakan dengan jelas? Adaptasi. Persyaratan dapat berubah tanpa dampak besar pada
persyaratan lain?
1)
Persyaratan manajemen adalah proses pengelolaan perubahan kebutuhan selama proses rekayasa persyaratan dan pengembangan
sistem. 2)
Persyaratan yang pasti tidak lengkap dan tidak konsisten
Persyaratan baru muncul selama proses tersebut sebagai
kebutuhan bisnis perubahan dan pemahaman yang lebih baik dari sistem dikembangkan;
Sudut pandang yang berbeda memiliki kebutuhan yang berbeda
dan ini sering bertentangan.
o Prioritas kebutuhan dari perubahan sudut pandang yang berbeda
selama proses pembangunan. o Pelanggan Sistem dapat menentukan persyaratan dari perspektif bisnis
yang bertentangan dengan kebutuhan pengguna akhir. o Lingkungan
bisnis dan teknis dari perubahan sistem selama
perkembangannya.
a)
Enduring persyaratan. Persyaratan Stabil berasal dari kegiatan inti dari organisasi pelanggan. Misalnya rumah sakit akan selalu memiliki dokter, perawat, dll Mungkin berasal dari model domain
b)
Volatile
persyaratan.
Persyaratan
yang
berubah
selama
pembangunan atau ketika sistem sedang digunakan. Di rumah sakit, kebutuhan yang berasal dari kebijakan kesehatan
Jenis Kebutuhan
Deskripsi
Diubah persyaratan
Persyaratan yang berubah karena perubahan lingkungan di mana organisasi beroperasi. Sebagai contoh, dalam sistem rumah sakit, pendanaan perawatan pasien dapat berubah sehingga membutuhkan perlakuan yang berbeda informasi yang dikumpulkan.
Muncul persyaratan
Persyaratan
yang
muncul
berkembang
selama
sebagai
pengembangan
pemahaman sistem.
pelanggan
Proses
desain
sistem dapat
mengungkapkan persyaratan muncul baru. Konsekuensial persyaratan
Persyaratan
yang
dihasilkan
dari
pengenalan
sistem
komputer.
Memperkenalkan sistem komputer dapat mengubah proses organisasi dan
membuka cara-cara baru kerja yang menghasilkan persyaratan sistem baru Kompatibilitas persyaratan
Persyaratan yang bergantung pada sistem tertentu atau proses bisnis dalam sebuah organisasi. Seperti mengubah, persyaratan kompatibilitas pada sistem ditugaskan atau dikirim juga mungkin harus berevolusi.
Selama proses rekayasa persyaratan, Anda harus merencanakan: •
Persyaratan identifikasi Bagaimana kebutuhan secara individual diidentifikasi;
•
Sebuah proses perubahan manajemen Proses diikuti ketika menganalisis perubahan persyaratan;
•
Ketertelusuran kebijakan Jumlah informasi tentang hubungan persyaratan yang dipelihara;
•
KASUS alat dukungan Dukungan alat yang dibutuhkan untuk membantu mengelola perubahan
persyaratan;
Ketertelusuran berkaitan dengan hubungan antara kebutuhan, sumber-
sumber dan desain sistem Sumber ketertelusuran Link dari persyaratan untuk para stakeholder yang mengusulkan
persyaratan tersebut; Persyaratan ketertelusuran Link antara persyaratan tergantung; Desain ketertelusuran Link dari persyaratan untuk desain;
Persyaratan penyimpanan Persyaratan harus dikelola di sebuah toko, data yang aman dikelola. Manajemen perubahan Proses manajemen perubahan adalah proses alur kerja yang tahap
dapat didefinisikan dan informasi mengalir antara tahap ini sebagian otomatis. Ketertelusuran manajemen Pengambilan otomatis dari link antara persyaratan.
Harus berlaku untuk
semua perubahan yang diajukan dengan
kebutuhan. Pokok tahap Analisis masalah. Diskusikan masalah persyaratan dan mengusulkan
perubahan; Ubah analisis dan biaya. Menilai dampak perubahan persyaratan
lain; Perubahan implementasi. Modifikasi persyaratan dokumen dan
dokumen lain untuk mencerminkan perubahan.
Proses rekayasa persyaratan mencakup studi kelayakan, elisitasi
persyaratan dan analisis, spesifikasi kebutuhan dan persyaratan manajemen. Elisitasi Persyaratan dan analisis adalah berulang yang melibatkan
pengertian domain, persyaratan pengumpulan, klasifikasi, penataan, prioritas dan validasi. Sistem memiliki beberapa pemangku kepentingan dengan kebutuhan
yang berbeda.
Sosial dan faktor organisasi mempengaruhi persyaratan
sistem. Persyaratan validasi berkaitan dengan memeriksa validitas,
konsistensi, realisme kelengkapan, dan pemastian. Bisnis pasti menyebabkan perubahan kebutuhan berubah. Persyaratan
manajemen
manajemen perubahan.
meliputi
perencanaan
dan
