1. Persyaratan rekayasa.
persyaratan analisis yang sistematis juga dikenal sebagai rekayasa persyaratan. Analisis Persyaratan panjang juga dapat diterapkan secara khusus untuk analisis yang tepat, karena bertentangan dengan elisitasi atau dokumentasi persyaratan, misalnya. Rekayasa Kebutuhan dapat dibagi menjadi langkah-langkah kronologis diskrit :
1. Persyaratan elisitasi.
2. Persyaratan analisis dan negosiasi.
3. Persyaratan spesifikasi.
4. Sistem pemodelan.
5. Persyaratan validasi,.
6. Persyaratan manajemen.
Kebutuhan rekayasa menurut Laplante (2007) adalah "teknik sistem dan rekayasa perangkat lunak yang berkaitan dengan menentukan tujuan, fungsi, dan kendala sistem hardware dan software." Pada beberapa model siklus hidup, proses rekayasa kebutuhan dimulai dengan kegiatan studi kelayakan, yang mengarah ke laporan kelayakan. Jika studi kelayakan menunjukkan bahwa produk harus dikembangkan, maka analisis kebutuhan dapat dimulai. Jika analisis kebutuhan mendahului studi kelayakan, yang dapat mendorong pemikiran luar kotak, maka kelayakan harus ditentukan sebelum persyaratan yang diselesaikan.
2. Persyaratan topik analisis
2.1. Identifikasi Stakeholder
Stakeholder (SH) adalah orang atau organisasi yang memiliki kepentingan yang valid dalam sistem. Mereka mungkin akan terpengaruh olehnya baik secara langsung maupun tidak langsung. Penekanan utama baru pada 1990-an fokus pada identifikasi stakeholder. Hal ini semakin diakui bahwa para stakeholder tidak terbatas pada organisasi mempekerjakan analis. Pemangku kepentingan lain akan mencakup:
1. siapapun yang mengoperasikan sistem (operator normal dan pemeliharaan).
2. siapa saja yang manfaat dari sistem (penerima manfaat fungsional, politik, keuangan dan sosial).
3. siapapun yang terlibat dalam pembelian atau pengadaan sistem. Dalam sebuah organisasi produk massal-pasar, manajemen produk, pemasaran dan penjualan kadang bertindak sebagai pengganti konsumen (pasar massal pelanggan) untuk memandu pengembangan produk.
4. organisasi yang mengatur aspek-aspek dari sistem (keuangan, keselamatan, dan regulator lainnya).
5. orang atau organisasi yang menentang sistem (stakeholder negatif).
6. Perusahaan bertanggung jawab untuk sistem organisasi yang interface dengan sistem di bawah desain.
7. organisasi-organisasi yang mengintegrasikan secara horisontal dengan organisasi untuk siapa analis adalah merancang sistem.
2.2. Wawancara dengan Stakeholder.
Wawancara dengan Stakeholder adalah teknik umum yang digunakan dalam analisis kebutuhan. Meskipun mereka umumnya istimewa di alam dan difokuskan pada perspektif dan dirasakan kebutuhan stakeholder, sangat sering tanpa perusahaan besar atau konteks sistem, ini kekurangan perspektif memiliki keuntungan umum untuk mendapatkan pemahaman yang jauh lebih kaya dari proses unik stakeholder bisnis, keputusan-terkait aturan bisnis, dan kebutuhan yang dirasakan. Oleh karena teknik ini dapat berfungsi sebagai sarana untuk memperoleh pengetahuan yang sangat terfokus yang sering tidak ditimbulkan dalam Pengembangan Bersama sesi Persyaratan, di mana perhatian stakeholder terpaksa untuk menganggap konteks yang lebih lintas-fungsional. Selain itu, sifat di-orang dari wawancara menyediakan lingkungan yang lebih santai di mana garis pemikiran dapat dieksplorasi panjang lebar.
1.
2.
2.1.
2.2.
2.3. Persyaratan Bersama Pengembangan.
Persyaratan sering memiliki implikasi lintas fungsional yang tidak diketahui kepada para pemangku kepentingan individu dan sering tidak terjawab atau tidak lengkap ditetapkan selama wawancara dengan stakeholder. Ini implikasi lintas fungsional dapat diperoleh dengan melakukan sesi persyaratan bersama dalam lingkungan yang terkendali, yang difasilitasi oleh fasilitator terlatih, dimana stakeholder berpartisipasi dalam diskusi dengan kebutuhan menjabarkan, menganalisis dan mengungkap rincian implikasi lintas-fungsional. Seorang juru tulis khusus dan Business Analyst harus hadir untuk mendokumentasikan diskusi. Memanfaatkan keterampilan fasilitator terlatih untuk memandu diskusi membebaskan Analyst Usaha untuk dapat fokus pada proses definisi persyaratan.
1.
2.
2.1.
2.2.
2.3.
2.4. Daftar persyaratan Kontrak.
Salah satu cara tradisional persyaratan telah mendokumentasikan daftar kontrak kebutuhan. Dalam sistem yang kompleks seperti persyaratan daftar dapat berjalan ke ratusan halaman. Sebuah metafora yang sesuai akan menjadi daftar belanja sangat panjang. Daftar tersebut sangat luar banyak nikmat dalam analisis modern, karena mereka telah terbukti gagal spektakuler untuk mencapai tujuan mereka, tetapi mereka masih terlihat sampai hari ini.
1.
2.
2.1.
2.2.
2.3.
2.4.
2.4.1. Kekuatan dalam kontrak.
1. Menyediakan daftar persyaratan.
2. Menyediakan kontrak antara sponsor proyek (s) dan pengembang.
3. Untuk sistem besar dapat memberikan gambaran tingkat tinggi.
2.4.1.
2.4.2. Kelemahan dalam kontrak.
1. Daftar tersebut dapat berjalan ke ratusan halaman. Hal ini hampir mustahil untuk membaca dokumen tersebut secara keseluruhan dan memiliki pemahaman yang koheren dari sistem.
2. Persyaratan seperti daftar abstrak semua persyaratan dan sehingga ada sedikit konteks.
2.1. abstraksi ini membuat tidak mungkin untuk melihat bagaimana persyaratan cocok atau bekerja sama.
2.2. abstraksi ini membuat sulit untuk memprioritaskan persyaratan dengan benar, sedangkan daftar tidak membuat mudah untuk memprioritaskan setiap item individu, menghapus salah satu objek dari konteks dapat membuat kasus yang menggunakan seluruh atau kebutuhan bisnis tidak berguna.
2.3. abstraksi ini meningkatkan kemungkinan salah menafsirkan persyaratan, karena lebih banyak orang membacanya, jumlah (berbeda) interpretasi dari meningkatkan sistem dibayangkan.
2.4. abstraksi Ini berarti bahwa hal itu sangat sulit untuk memastikan bahwa Anda memiliki sebagian besar persyaratan. Seharusnya, dokumen-dokumen ini berbicara di umum, tetapi setan, sebagaimana yang mereka katakan, adalah dalam rincian.
3. Daftar ini menciptakan rasa palsu saling pengertian antara para pemangku kepentingan dan pengembang.
4. daftar kontrak gaya ini memberikan para pemangku kepentingan rasa aman palsu bahwa pengembang harus mencapai hal-hal tertentu. Namun, karena sifat dari daftar ini, mereka pasti kehilangan persyaratan penting yang diidentifikasi kemudian dalam proses. Pengembang dapat menggunakan persyaratan ini ditemukan melakukan negosiasi ulang persyaratan dan kondisi yang menguntungkan mereka.
5. Persyaratan daftar ini tidak membantu dalam desain sistem, karena mereka tidak meminjamkan diri ke aplikasi.
3. Prototipe.
Pada pertengahan 1980-an, prototyping dipandang sebagai solusi terbaik untuk masalah analisis kebutuhan. Aplikasi prototipe. Aplikasi prototipe memungkinkan pengguna untuk memvisualisasikan aplikasi yang belum dibangun. Prototip membantu pengguna mendapatkan gambaran tentang apa sistem akan terlihat seperti, dan mempermudah pengguna untuk membuat keputusan desain tanpa menunggu sistem yang akan dibangun. perbaikan utama dalam komunikasi antara pengguna dan pengembang yang sering terlihat dengan pengenalan prototipe. Awal pandangan aplikasi menyebabkan perubahan sedikit kemudian dan karenanya mengurangi biaya keseluruhan jauh. Namun, selama dekade berikutnya, sementara membuktikan teknik yang berguna, prototyping tidak menyelesaikan masalah persyaratan:
3.2. Manajer, begitu mereka melihat prototipe, mungkin sulit memahami bahwa desain selesai tidak akan diproduksi untukbeberapa waktu.
3.3. Desainer sering merasa dipaksa untuk menggunakan ditambal bersama-sama kode prototipe dalam sistem nyata, karena mereka takut 'membuang waktu' untuk mulai lagi.
3.4. Prototipe terutama membantu dengan keputusan desain dan desain user interface. Namun, mereka tidak bisa memberi tahu Anda apa persyaratan yang semula itu.
3.5. Desainer dan pengguna akhir dapat berfokus terlalu banyak pada desain user interface dan terlalu sedikit pada menghasilkan sistem yang melayani proses bisnis.
3.6. Prototipe bekerja dengan baik untuk antarmuka pengguna, tata letak layar dan aliran layar tetapi tidak begitu berguna untuk batch atau proses asinkron yang mungkin melibatkan pembaruan basis data kompleks dan / atau perhitungan.
Prototip dapat diagram rata (sering disebut sebagai wireframes) atau aplikasi bekerja menggunakan fungsi disintesis. Wireframes dibuat dalam berbagai dokumen desain grafis, dan sering menghapus semua warna dari desain (yaitu menggunakan palet warna abu-abu) dalam contoh di mana perangkat lunak akhir diharapkan memiliki desain grafis diterapkan untuk itu. Ini membantu untuk mencegah kebingungan tampilan visual akhir dan nuansa aplikasi.
4. Spesifikasi Persyaratan Perangkat Lunak.
Sebuah spesifikasi persyaratan perangkat lunak adalah deskripsi lengkap tentang perilaku sistem yang akan dikembangkan. Ini mencakup satu set kasus penggunaan yang menggambarkan seluruh interaksi bahwa pengguna akan memiliki dengan perangkat lunak. kasus Gunakan juga dikenal sebagai kebutuhan fungsional. Selain menggunakan kasus, SRS juga mengandung nonfunctional (atau tambahan) persyaratan. Kebutuhan non-fungsional adalah persyaratan yang menyebabkan hambatan pada desain atau pelaksanaan (seperti kinerja persyaratan, standar kualitas, atau kendala desain).
Fitur pendekatan untuk spesifikasi kebutuhan perangkat lunak dijelaskan oleh IEEE 830-1998. Standar ini menjelaskan struktur mungkin, isi diinginkan, dan kualitas dari sebuah spesifikasi kebutuhan perangkat lunak.
5. Jenis Persyaratan.
5.1. Kebutuhan Pelanggan.
Laporan fakta dan asumsi yang menentukan harapan sistem dalam hal tujuan misi, lingkungan, kendala, dan ukuran efektivitas dan kesesuaian (MOE / MOS). Pelanggan adalah mereka yang melakukan delapan fungsi utama dari rekayasa sistem, dengan penekanan khusus pada operator sebagai pelanggan kunci. Persyaratan operasional akan menentukan kebutuhan dasar dan, pada tingkat minimum, menjawab pertanyaan yang diajukan dalam daftar berikut:
5.1.1. Operasional distribusi atau penyebaran: Di mana sistem akan digunakan?
5.1.2. Misi profil atau skenario: Bagaimana sistem mencapai tujuan misinya?
5.1.3. Kinerja dan terkait parameter: Apa parameter sistem kritis untuk mencapai misi?
5.1.4. Pemanfaatan lingkungan: Bagaimana berbagai komponen sistem yang akan digunakan?
5.1.5. Persyaratan Efektivitas: Seberapa efektif atau efisien harus sistem dalam melakukan misinya?
5.1.6. Operasional siklus hidup: Berapa lama sistem tersebut akan digunakan oleh pengguna?
5.1.7. Lingkungan: Apa lingkungan sistem akan diharapkan untuk beroperasi secara efektif?
5.2. Persyaratan Arsitektur.
Persyaratan Arsitektur menjelaskan apa yang harus dilakukan dengan mengidentifikasi arsitektur sistem yang diperlukan dari suatu sistem.
5.3. Persyaratan Struktural.
Persyaratan Struktural menjelaskan apa yang harus dilakukan dengan mengidentifikasi struktur yang diperlukan dari suatu sistem.
3.
4.
5.
5.1.
5.2.
5.3.
5.4. Perilaku Persyaratan.
persyaratan Perilaku menjelaskan apa yang harus dilakukan dengan mengidentifikasi perilaku yang diperlukan dari suatu sistem.
5.5. Persyaratan Fungsional.
Kebutuhan fungsional menjelaskan apa yang harus dilakukan dengan mengidentifikasi tugas tindakan, diperlukan atau kegiatan yang harus dicapai. Fungsional syarat analisis akan digunakan sebagai fungsi toplevel untuk analisis fungsional.
5.6. Persyaratan non-fungsional.
Kebutuhan non-fungsional merupakan persyaratan yang menentukan kriteria yang dapat digunakan untuk menilai sebuah sistem operasi, daripada perilaku spesifik.
5.7. Persyaratan Kinerja.
Sejauh mana suatu misi atau fungsi harus dijalankan, biasanya diukur dari segi kuantitas, kualitas, ketepatan waktu pertanggungan, atau kesiapan. Selama analisis persyaratan, kinerja (seberapa baik apakah itu harus dilakukan) persyaratan akan interaktif dikembangkan di semua fungsi yang diidentifikasi berdasarkan faktor-faktor siklus hidup sistem, dan ditandai dalam hal tingkat kepastian dalam perkiraan mereka, tingkat kekritisan terhadap sistem sukses, dan hubungannya dengan persyaratan lainnya.
5.8. Persyaratan Desain.
"membangun untuk," kode "untuk," dan "beli untuk" persyaratan untuk produk dan "bagaimana melaksanakan" persyaratan untuk proses disajikan dalam paket data teknis dan pedoman teknis.
5.9. Berasal Persyaratan.
Persyaratan yang tersirat atau berubah dari kebutuhan tingkat yang lebih tinggi. Sebagai contoh, kebutuhan untuk jangka panjang maupun kecepatan tinggi dapat mengakibatkan persyaratan desain untuk berat badan rendah.
5.10. Alokasi Persyaratan.
Sebuah persyaratan yang ditetapkan dengan membagi atau mengalokasikan persyaratan tingkat tinggi ke tingkat yang lebih rendah persyaratan ganda. Contoh: Item 100-pon yang terdiri dari dua subsistem mungkin mengakibatkan persyaratan berat £ 70 dan 30 pound untuk dua item tingkat bawah.
