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 teknik skenario yang berbasis di UML yang

mengidentifikasi para pelaku dalam interaksi 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 tes untuk persyaratan untuk memeriksa

testability.

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 sebagai pemahaman pelanggan sistem

berkembang selama pengembangan sistem. Proses desain 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 meliputi perencanaan dan

manajemen perubahan.