Kebutuhan Rekayasa (RE) meliputi kegiatan yang sangat penting bagi keberhasilan rekayasa Web. Persyaratan tidak lengkap, ambigu, atau tidak benar dapat menyebabkan kesulitan berat dalam pembangunan, atau bahkan menyebabkan pembatalan proyek. RE berkaitan dengan prinsip-prinsip, metode, dan alat untuk memunculkan, menjelaskan, validasi, dan mengelola persyaratan. Dalam rekayasa Web RE harus mengatasi tantangan khusus seperti stakeholders tidak tersedia, persyaratan mudah menguap dan kendala, lingkungan operasional tak terduga, pengalaman dengan teknologi web, pentingnya aspek tertentu dari kualitas seperti kegunaan, atau kinerja. Oleh karena itu, ketika mengadopsi metode RE yang ada dalam rekayasa Web, prinsip penting yang harus disimpan dalam pikiran yaitu : keterlibatan stakeholder, berulang identifikasi persyaratan, kesadaran arsitektur sistem ketika mendefinisikan persyaratan, dan orientasi resiko konsekuen.
Pengenalan
RE berkaitan dengan prinsip-prinsip, metode, dan alat untuk mengidentifikasi, mendeskripsikan, memvalidasi, dan mengelola persyaratan dalam pengembangan sistem. Saat ini, metode RE banyak dan alat yang tersedia. Namun, pendekatan ini sering tidak diterapkan oleh para praktisi dan RE sering dilakukan dalam cara ad-hoc, khususnya di bidang teknik Web. Meskipun kompleksitas aplikasi web hari ini memerlukan pendekatan yang lebih sistematis, kematangan proses RE sering tidak cukup.
Pada tahun 1976 dalam artikel berjudul Persyaratan Software, Bell dan Thayer menekankan bahwa persyaratan tidak berubah secara otomatis, tetapi harus diidentifikasi dalam suatu kegiatan rekayasa.
Pada awal 1980-an, Boehm mempelajari biaya cacat dalam persyaratan dan menemukan bahwa penghapusan akhir dari cacat yang belum ditemukan adalah sampai 200 kali lebih mahal dari pada identifikasi awal dan koreksi. dan Dalam artikelnya Silver Bullet, Brooks menekankan bahwa iteratif pengumpulan dan penyempurnaan persyaratan yang yang paling penting fungsi seorang insinyur perangkat lunak untuk pelanggan.
Fundamentals
Tujuan individu dan harapan stakeholder adalah titik awal dari persyaratan proses elisitasi. Stakeholder adalah orang-orang atau organisasi yang memiliki pengaruh langsung atau tidak langsung pada persyaratan dalam pengembangan sistem (Kotonya dan Sommerville 1998). Yang terpenting stakeholder adalah pelanggan, pengguna, dan pengembang. Stakeholder Khas untuk aplikasi Web yaitu termasuk konten penulis, pakar domain, ahli kegunaan, atau profesional pemasaran. Tujuan dan harapan stakeholder sering cukup beragam, seperti yang ditunjukkan oleh beberapa contoh :
• Aplikasi Web akan tersedia secara online tanggal 1 September 2006 (kendala pelanggan).
• Aplikasi Web akan mendukung minimal 2500 pengguna bersamaan (kualitas obyektif pelanggan).
• Aplikasi Web akan tersedia secara online tanggal 1 September 2006 (kendala pelanggan).
• Aplikasi Web akan mendukung minimal 2500 pengguna bersamaan (kualitas obyektif pelanggan).
• J2EE harus digunakan sebagai platform pengembangan (teknologi harapan pengembang).
• Semua data pelanggan harus aman disampaikan (kualitas obyektif dari pengguna).
• User interface akan mendukung layout untuk kelompok pelanggan yang berbeda (tujuan kualitas customer).
• Seorang pengguna sewenang-wenang akan dapat menemukan produk yang diinginkan dalam waktu kurang dari tiga menit (kegunaan Tujuan pelanggan).
• Seorang pengguna akan dapat memilih ikon untuk menampilkan artikel termasuk dalam keranjang belanja setiap diberi waktu (kemampuan tujuan pengguna).
• Semua data pelanggan harus aman disampaikan (kualitas obyektif dari pengguna).
• User interface akan mendukung layout untuk kelompok pelanggan yang berbeda (tujuan kualitas customer).
• Seorang pengguna sewenang-wenang akan dapat menemukan produk yang diinginkan dalam waktu kurang dari tiga menit (kegunaan Tujuan pelanggan).
• Seorang pengguna akan dapat memilih ikon untuk menampilkan artikel termasuk dalam keranjang belanja setiap diberi waktu (kemampuan tujuan pengguna).
Kegiatan Kebutuhan Rekayasa
RE meliputi elisitasi, dokumentasi, verifikasi dan validasi, serta persyaratan manajemen seluruh proses pembangunan.
RE meliputi elisitasi, dokumentasi, verifikasi dan validasi, serta persyaratan manajemen seluruh proses pembangunan.
- Persyaratan elisitasi dan Negosiasi
Para peneliti telah menunjukkan bahwa "persyaratan tidak keluar untuk dikumpulkan dengan meminta hak pertanyaan "(Nuseibeh dan Easterbrook 2000). Sebaliknya, persyaratan adalah hasil belajar yang dan konsensus-proses pembangunan (Boehm et al 2001,. Lowe dan Eklund 2002). Dalam proses ini, komunikasi antara para pemangku kepentingan sangat penting, karena hanya keahlian mereka bersama dapat menyebabkan saling diterima solusi. Satu set macam metode dan alat kolaboratif yang tersedia untuk memfasilitasi komunikasi dan pertukaran pengetahuan di RE. Contoh termasuk teknik kreativitas, berbasis skenario metode, proses keputusan multikriteria, teknik fasilitasi, wawancara, atau analisis dokumen (Nuseibeh dan Easterbrook 2000).
- Persyaratan Dokumentasi
Jika stakeholder mencapai konsensus, kesepakatan mereka harus disempurnakan dan dijelaskan dalam persyaratan dokumen tingkat detail dan formalitas yang sesuai untuk proyek konteks. Pemilihan tingkat yang sesuai detail dan formalitas tergantung pada kedua risiko proyek diidentifikasi dan pengalaman serta keterampilan dari para pembaca yang diharapkan. Informal deskripsi seperti cerita pengguna, dan semi formal deskripsi seperti kasus penggunaan, terutama relevan dalam rekayasa web.
- Persyaratan Verifikasi dan Validasi
Persyaratan harus divalidasi dan diverifikasi. Ada beberapa metode konvensional untuk tujuan ini, seperti ulasan, inspeksi, atau prototyping (Halling et al. 2003). Dalam Rekayasa Web, keterbukaan Internet memfasilitasi bentuk-bentuk baru dari partisipasi pengguna langsung dalam validasi persyaratan, misalnya, melalui koleksi online dari umpan balik pengguna (Deshpande et al. 2002).
- Persyaratan Manajemen
Alih-alih menjadi stabil, persyaratan yang sering tunduk pada perubahan. Perubahan persyaratan dan kendala adalah karakteristik utama dari proyek Web. Metode dan alat untuk mendukung kebutuhan manajemen baik integrasi persyaratan baru dan perubahan dengan persyaratan yang ada. Mereka juga membantu dalam mengevaluasi dampak dari perubahan dengan mengelola saling ketergantungan di antara persyaratan, dan antara kebutuhan dan pembangunan lainnya artefak (traceability). Karena kesulitan manajemen persyaratan bahkan cukup sistem yang kompleks, alat-alat yang biasanya digunakan untuk mendukung tugas ini.
Para peneliti telah menunjukkan bahwa "persyaratan tidak keluar untuk dikumpulkan dengan meminta hak pertanyaan "(Nuseibeh dan Easterbrook 2000). Sebaliknya, persyaratan adalah hasil belajar yang dan konsensus-proses pembangunan (Boehm et al 2001,. Lowe dan Eklund 2002). Dalam proses ini, komunikasi antara para pemangku kepentingan sangat penting, karena hanya keahlian mereka bersama dapat menyebabkan saling diterima solusi. Satu set macam metode dan alat kolaboratif yang tersedia untuk memfasilitasi komunikasi dan pertukaran pengetahuan di RE. Contoh termasuk teknik kreativitas, berbasis skenario metode, proses keputusan multikriteria, teknik fasilitasi, wawancara, atau analisis dokumen (Nuseibeh dan Easterbrook 2000).
- Persyaratan Dokumentasi
Jika stakeholder mencapai konsensus, kesepakatan mereka harus disempurnakan dan dijelaskan dalam persyaratan dokumen tingkat detail dan formalitas yang sesuai untuk proyek konteks. Pemilihan tingkat yang sesuai detail dan formalitas tergantung pada kedua risiko proyek diidentifikasi dan pengalaman serta keterampilan dari para pembaca yang diharapkan. Informal deskripsi seperti cerita pengguna, dan semi formal deskripsi seperti kasus penggunaan, terutama relevan dalam rekayasa web.
- Persyaratan Verifikasi dan Validasi
Persyaratan harus divalidasi dan diverifikasi. Ada beberapa metode konvensional untuk tujuan ini, seperti ulasan, inspeksi, atau prototyping (Halling et al. 2003). Dalam Rekayasa Web, keterbukaan Internet memfasilitasi bentuk-bentuk baru dari partisipasi pengguna langsung dalam validasi persyaratan, misalnya, melalui koleksi online dari umpan balik pengguna (Deshpande et al. 2002).
- Persyaratan Manajemen
Alih-alih menjadi stabil, persyaratan yang sering tunduk pada perubahan. Perubahan persyaratan dan kendala adalah karakteristik utama dari proyek Web. Metode dan alat untuk mendukung kebutuhan manajemen baik integrasi persyaratan baru dan perubahan dengan persyaratan yang ada. Mereka juga membantu dalam mengevaluasi dampak dari perubahan dengan mengelola saling ketergantungan di antara persyaratan, dan antara kebutuhan dan pembangunan lainnya artefak (traceability). Karena kesulitan manajemen persyaratan bahkan cukup sistem yang kompleks, alat-alat yang biasanya digunakan untuk mendukung tugas ini.
RE Spesifik Teknik Web
RE untuk teknik Web berbeda dari RE untuk sistem software konvensional. Perbedaan tampaknya diabaikan oleh para peneliti di lapangan: "Meskipun ada banyak perbedaan antara pengembangan Web dan pengembangan perangkat lunak ada juga kesamaan di antara Persyaratan elisitasi (Deshpande et al. 2002). Namun, jika kita melihat lebih dekat di beberapa spesifik, perbedaan menjadi jelas. Itu sub bagian berikut mengeksplorasi tersebut dengan menggunakan karakteristik aplikasi Web dibahas dalam Bab 1 (Lowe 2003).
RE untuk teknik Web berbeda dari RE untuk sistem software konvensional. Perbedaan tampaknya diabaikan oleh para peneliti di lapangan: "Meskipun ada banyak perbedaan antara pengembangan Web dan pengembangan perangkat lunak ada juga kesamaan di antara Persyaratan elisitasi (Deshpande et al. 2002). Namun, jika kita melihat lebih dekat di beberapa spesifik, perbedaan menjadi jelas. Itu sub bagian berikut mengeksplorasi tersebut dengan menggunakan karakteristik aplikasi Web dibahas dalam Bab 1 (Lowe 2003).
- Multidisciplinarity
Pengembangan aplikasi Web memerlukan partisipasi dari para ahli dari berbagai disiplin. Contoh termasuk ahli multimedia, penulis konten, arsitek software, kegunaan ahli, spesialis database, atau ahli domain. Heterogenitas dan multidisciplinarity dari stakeholder membuatnya menantang untuk mencapai konsensus ketika mendefinisikan persyaratan. Masalah ini diperparah sebagai orang-orang dari berbagai disiplin ilmu memiliki bahasa mereka sendiri dan jargon yang perlu didamaikan.
- Ketidaktersediaan Stakeholder
Banyak pihak, seperti pengguna Web potensial, masih belum diketahui selama kegiatan RE. Proyek
manajemen perlu mencari perwakilan yang cocok yang dapat memberikan persyaratan yang realistis. Untuk Misalnya, sering ada spektrum yang luas dari pengguna mungkin dalam proyek Web dan menemukan wajar set perwakilan sulit.
- Persyaratan Volatilitas dan Kendala
Persyaratan dan kendala seperti sifat dari platform penyebaran atau komunikasi protokol sering lebih mudah untuk menentukan untuk sistem perangkat lunak konvensional daripada untuk Aplikasi Web.Aplikasi Web dan lingkungan mereka sangat dinamis dan persyaratan dan kendala biasanya sulit untuk menstabilkan. Contoh Sering perubahan inovasi teknologi tersebut sebagai pengenalan platform pengembangan baru dan standar, atau perangkat baru bagi pengguna akhir.
- Tak Terduga Operasional Lingkungan
Lingkungan operasional dari aplikasi Web juga sangat dinamis dan sulit diprediksi. Pengembang merasa sulit atau tidak mungkin untuk mengontrol faktor-faktor penting yang menentukan bagi userperceived kualitas Aplikasi Web. Misalnya, bandwidth perubahan mempengaruhi respon waktu aplikasi mobile, tetapi berada di luar lingkup tim pengembangan (Finkelstein dan Savigni 2001).
- Dampak Sistem Warisan
Pengembangan Aplikasi Web ditandai dengan integrasi perangkat lunak yang ada komponen seperti dari rak produk komersial atau perangkat lunak open source. Secara khusus, Pengembang web yang sering menghadapi tantangan untuk mengintegrasikan sistem warisan, misalnya ketika membuat sistem TI yang ada dari sebuah perusahaan dapat diakses melalui Web. Pengembang sering diminta untuk menggunakan komponen yang ada untuk alasan ekonomi. Komponen yang perlu diintegrasikan sangat mempengaruhi persyaratan dan gaya arsitektur dari sistem di masa depan. Dalam keadaan seperti pendekatan air terjun untuk mendapatkan arsitektur sistem dari persyaratan tidak akan berhasil, sebagai komponen yang ada, jasa, dan infrastruktur yang menentukan berbagai kemungkinan dan keterbatasan untuk pengembang. Ini berarti bahwa, ketika mengidentifikasi dan mendefinisikan persyaratan, pengembang web harus menyadari arsitektur sistem dan arsitektur kendala. Pendekatan iteratif seperti yang diusulkan dalam model Twin Peaks.
Pengembangan aplikasi Web memerlukan partisipasi dari para ahli dari berbagai disiplin. Contoh termasuk ahli multimedia, penulis konten, arsitek software, kegunaan ahli, spesialis database, atau ahli domain. Heterogenitas dan multidisciplinarity dari stakeholder membuatnya menantang untuk mencapai konsensus ketika mendefinisikan persyaratan. Masalah ini diperparah sebagai orang-orang dari berbagai disiplin ilmu memiliki bahasa mereka sendiri dan jargon yang perlu didamaikan.
- Ketidaktersediaan Stakeholder
Banyak pihak, seperti pengguna Web potensial, masih belum diketahui selama kegiatan RE. Proyek
manajemen perlu mencari perwakilan yang cocok yang dapat memberikan persyaratan yang realistis. Untuk Misalnya, sering ada spektrum yang luas dari pengguna mungkin dalam proyek Web dan menemukan wajar set perwakilan sulit.
- Persyaratan Volatilitas dan Kendala
Persyaratan dan kendala seperti sifat dari platform penyebaran atau komunikasi protokol sering lebih mudah untuk menentukan untuk sistem perangkat lunak konvensional daripada untuk Aplikasi Web.Aplikasi Web dan lingkungan mereka sangat dinamis dan persyaratan dan kendala biasanya sulit untuk menstabilkan. Contoh Sering perubahan inovasi teknologi tersebut sebagai pengenalan platform pengembangan baru dan standar, atau perangkat baru bagi pengguna akhir.
- Tak Terduga Operasional Lingkungan
Lingkungan operasional dari aplikasi Web juga sangat dinamis dan sulit diprediksi. Pengembang merasa sulit atau tidak mungkin untuk mengontrol faktor-faktor penting yang menentukan bagi userperceived kualitas Aplikasi Web. Misalnya, bandwidth perubahan mempengaruhi respon waktu aplikasi mobile, tetapi berada di luar lingkup tim pengembangan (Finkelstein dan Savigni 2001).
- Dampak Sistem Warisan
Pengembangan Aplikasi Web ditandai dengan integrasi perangkat lunak yang ada komponen seperti dari rak produk komersial atau perangkat lunak open source. Secara khusus, Pengembang web yang sering menghadapi tantangan untuk mengintegrasikan sistem warisan, misalnya ketika membuat sistem TI yang ada dari sebuah perusahaan dapat diakses melalui Web. Pengembang sering diminta untuk menggunakan komponen yang ada untuk alasan ekonomi. Komponen yang perlu diintegrasikan sangat mempengaruhi persyaratan dan gaya arsitektur dari sistem di masa depan. Dalam keadaan seperti pendekatan air terjun untuk mendapatkan arsitektur sistem dari persyaratan tidak akan berhasil, sebagai komponen yang ada, jasa, dan infrastruktur yang menentukan berbagai kemungkinan dan keterbatasan untuk pengembang. Ini berarti bahwa, ketika mengidentifikasi dan mendefinisikan persyaratan, pengembang web harus menyadari arsitektur sistem dan arsitektur kendala. Pendekatan iteratif seperti yang diusulkan dalam model Twin Peaks.
- Signifikansi dari Aspek Kualitas
Aspek kualitas yang menentukan bagi keberhasilan aplikasi Web. Contohnya termasuk kinerja dari aplikasi Web seperti keamanan dalam e-commerce, ketersediaan, atau kegunaan. Meskipun signifikansi dari aspek kualitas, pengembang harus berurusan dengan masalah bahwa spesifikasi yang tepat kualitas persyaratan seringkali sulit atau bahkan sia-sia sebelum sistem sebenarnya dibangun. Sebagai contoh, waktu respon dari aplikasi Web tergantung pada banyak faktor yang berada di luar kendali pengembangan tim. Pendekatan layak untuk mendefinisikan persyaratan mutu adalah untuk menentukan kriteria untuk tes penerimaan menunjukkan apakah atau tidak persyaratan telah dipenuhi.
- Kualitas User Interface
Kualitas dari user interface adalah aspek lain keberhasilan kritis Aplikasi Web. Ketika mengembangkan Aplikasi Web pengembang perlu menyadari fenomena IKIWISI (I Know It When I See It). Pengguna tidak akan dapat memahami dan mengevaluasi aplikasi Web oleh hanya melihat model abstrak dan spesifikasi, melainkan mereka perlu bereksperimen dengan itu. Sekarang sehingga sangat penting untuk melengkapi definisi dan deskripsi persyaratan dengan menambahkan prototipe skenario aplikasi.
Aspek kualitas yang menentukan bagi keberhasilan aplikasi Web. Contohnya termasuk kinerja dari aplikasi Web seperti keamanan dalam e-commerce, ketersediaan, atau kegunaan. Meskipun signifikansi dari aspek kualitas, pengembang harus berurusan dengan masalah bahwa spesifikasi yang tepat kualitas persyaratan seringkali sulit atau bahkan sia-sia sebelum sistem sebenarnya dibangun. Sebagai contoh, waktu respon dari aplikasi Web tergantung pada banyak faktor yang berada di luar kendali pengembangan tim. Pendekatan layak untuk mendefinisikan persyaratan mutu adalah untuk menentukan kriteria untuk tes penerimaan menunjukkan apakah atau tidak persyaratan telah dipenuhi.
- Kualitas User Interface
Kualitas dari user interface adalah aspek lain keberhasilan kritis Aplikasi Web. Ketika mengembangkan Aplikasi Web pengembang perlu menyadari fenomena IKIWISI (I Know It When I See It). Pengguna tidak akan dapat memahami dan mengevaluasi aplikasi Web oleh hanya melihat model abstrak dan spesifikasi, melainkan mereka perlu bereksperimen dengan itu. Sekarang sehingga sangat penting untuk melengkapi definisi dan deskripsi persyaratan dengan menambahkan prototipe skenario aplikasi.
- Kualitas Konten
Banyak RE metode tradisional mengabaikan konten Web, meskipun merupakan aspek yang sangat penting dari aplikasi Web. Selain masalah teknologi perangkat lunak, pengembang harus mempertimbangkan isi, khususnya penciptaan dan pemeliharaan. Dalam konteks RE, itu sangat penting untuk menentukan kualitas yang dibutuhkan dari konten. Karakteristik kualitas penting termasuk akurasi, objektivitas, kredibilitas, relevansi, aktualitas, kelengkapan, atau kejelasan. Sistem manajemen konten (CMS) pentingnya keuntungan dan memungkinkan mewakili konten ringkas dan konsisten dengan memisahkan konten dari tata letak, dan menawarkan mengedit konten alat.
Banyak RE metode tradisional mengabaikan konten Web, meskipun merupakan aspek yang sangat penting dari aplikasi Web. Selain masalah teknologi perangkat lunak, pengembang harus mempertimbangkan isi, khususnya penciptaan dan pemeliharaan. Dalam konteks RE, itu sangat penting untuk menentukan kualitas yang dibutuhkan dari konten. Karakteristik kualitas penting termasuk akurasi, objektivitas, kredibilitas, relevansi, aktualitas, kelengkapan, atau kejelasan. Sistem manajemen konten (CMS) pentingnya keuntungan dan memungkinkan mewakili konten ringkas dan konsisten dengan memisahkan konten dari tata letak, dan menawarkan mengedit konten alat.
- Kurangnya pengalaman pengembang
Banyak dari teknologi yang mendasari dalam aplikasi web masih cukup baru. pengalaman dengan
teknologi ini pengembangan alat, standar, bahasa, dll dapat menyebabkan perkiraan yang salah ketika menilai kelayakan dan biaya pelaksanaan persyaratan.
- Tanggal Perusahaan Pengiriman Proyek web Banyak desain untuk jadwal proyek, di mana semua kegiatan dan keputusan harus memenuhi deadline proyek tetap akhir.
Banyak dari teknologi yang mendasari dalam aplikasi web masih cukup baru. pengalaman dengan
teknologi ini pengembangan alat, standar, bahasa, dll dapat menyebabkan perkiraan yang salah ketika menilai kelayakan dan biaya pelaksanaan persyaratan.
- Tanggal Perusahaan Pengiriman Proyek web Banyak desain untuk jadwal proyek, di mana semua kegiatan dan keputusan harus memenuhi deadline proyek tetap akhir.
Prinsip RE Aplikasi Web
Karakteristik Bagian sebelumnya membahas aplikasi Web dan spesifik RE di Web rekayasa. Kami telah menunjukkan bahwa RE untuk aplikasi Web harus berurusan dengan risiko dan ketidakpastian
seperti volatilitas persyaratan dan kendala, pengalaman dari para pengembang, atau dampak dari
warisan solusi. Pendekatan risiko berorientasi adalah pilihan yang baik untuk menghadapi tantangan ini. Dalam hal ini Bagian kita menggambarkan prinsip-prinsip dasar untuk RE Aplikasi Web. Pengembang web harus menjaga prinsip-prinsip berikut ketika melakukan kegiatan RE :
seperti volatilitas persyaratan dan kendala, pengalaman dari para pengembang, atau dampak dari
warisan solusi. Pendekatan risiko berorientasi adalah pilihan yang baik untuk menghadapi tantangan ini. Dalam hal ini Bagian kita menggambarkan prinsip-prinsip dasar untuk RE Aplikasi Web. Pengembang web harus menjaga prinsip-prinsip berikut ketika melakukan kegiatan RE :
- Memahami Konteks Sistem
- Melibatkan Stakeholder
- Iteratif Definisi Persyaratan
- Fokus pada Arsitektur Sistem
- Resiko Orientasi
Beradaptasi Metode RE untuk Pengembangan Aplikasi Web
Pada saat ini berbagai metode, pedoman, notasi, daftar periksa, dan alat-alat yang tersedia untuk semua kegiatan di RE. Namun, dalam rangka untuk berhasil pengembang harus menghindari “satu ukuran cocok untuk semua” Pendekatan, dan RE metode akibatnya harus disesuaikan dengan spesifikasi teknik Web dan situasi dari proyek-proyek tertentu. memandu definisi pendekatan proyek-spesifik RE untuk rekayasa Web. Antara lain, pengembang harus memperjelas aspek-aspek berikut selama proses adaptasi :
- Yang jenis persyaratan penting untuk Aplikasi Web?
- Bagaimana persyaratan untuk Aplikasi Web dijelaskan dan didokumentasikan?
- Haruskah penggunaan alat dipertimbangkan?
Persyaratan Jenis
Kedua badan standardisasi dan organisasi komersial telah mengembangkan sejumlah besar taksonomi untuk mendefinisikan dan mengklasifikasikan berbagai jenis kebutuhan. Contohnya adalah Volere . Taksonomi Kebanyakan membedakan antara persyaratan fungsional dan non-fungsional. Persyaratan fungsional menggambarkan kemampuan sistem dan layanan , Non-fungsional menggambarkan sifat kemampuan dan tingkat yang diinginkan dari layanan . Berikut ini secara singkat membahas jenis kebutuhan sangat relevan di Web proyek-proyek pembangunan :
- Persyaratan Fungsional
- Isi Persyaratan
- Kualitas Persyaratan Meliputi : Fungsi, Keahlian, Usability, Efisiensi, Perawatan, portabilitas, Persyaratan Sistem Lingkungan, Persyaratan User Interface, Persyaratan evolusi dan Kendala Proyek.
Notasi
Sebagian besar notasi yang tersedia untuk menentukan persyaratan dalam derajat yang berbeda dari detail dan formalitas. Contoh termasuk cerita, spesifikasi diformat, atau spesifikasi formal. Resiko proyek yang diidentifikasi memberikan pengarahan dalam pemilihan tingkat yang cocok kualitas spesifikasi, yaitu, untuk menentukan berapa banyak RE cukup dalam proyek tertentu. Secara umum, pendekatan informal dan semi formal sangat cocok untuk Aplikasi Web.
Sejarah
Sejarah digunakan untuk menghasilkan pemahaman umum antara pelanggan dan pengembang. Sejarah pengguna diformulasikan oleh seorang pelanggan dalam bahasa dan istilah, dan menjelaskan masalah dan hal sistem yang harus dipecahkan.
Persaratan Terperinci
Spesifikasi sederhana dalam bahasa alami. Kebutuhan masing-masing memiliki unik identifier. Salah satu contoh yang baik adalah deskripsi item data sebagaimana ditentukan dalam IEEE/EIA-J-STD-016.
Spesifikasi Terformat
Spesifikasi diformat menggunakan sintaks akurat didefinisikan, tetapi memungkinkan bahasa alami deskripsi dalam bingkai ini. Contoh termasuk deskripsi kasus digunakan dalam Unified Modeling Language (UML) (Cockburn 2001), yang DRD-100 Persyaratan Bahasa Spesifikasi, MBASE tersebut SSRD Pedoman (Kitapci et al. 2003), atau Shell Volere (Robertson dan Robertson 1999).
Spesifikasi Formal
Spesifikasi resmi ditulis dalam bahasa yang menggunakan sintaks yang ditetapkan secara formal dan semantik. Contoh yang paling menonjol adalah "Z" (ISO/IEC13, 568:2002). Spesifikasi formal tidak digunakan untuk menentukan aplikasi Web, kecuali di daerah niche.
Kesesuaian
Membandingkan notasi yang berbeda berkaitan dengan atribut akurasi, mudah validasi, efektivitas biaya, kesesuaian untuk non-ahli, dan skalabilitas. Rendahnya untuk akurasi akan cukup untuk menentukan persyaratan Aplikasi Web dan validasi resmi biasanya tidak diperlukan.
Spesifikasi resmi ditulis dalam bahasa yang menggunakan sintaks yang ditetapkan secara formal dan semantik. Contoh yang paling menonjol adalah "Z" (ISO/IEC13, 568:2002). Spesifikasi formal tidak digunakan untuk menentukan aplikasi Web, kecuali di daerah niche.
Kesesuaian
Membandingkan notasi yang berbeda berkaitan dengan atribut akurasi, mudah validasi, efektivitas biaya, kesesuaian untuk non-ahli, dan skalabilitas. Rendahnya untuk akurasi akan cukup untuk menentukan persyaratan Aplikasi Web dan validasi resmi biasanya tidak diperlukan.
Tools
Tools menggunakan kegiatan RE dasar. RE alat ada yang tidak terbatas pada aplikasi Web, tetapi dapat disesuaikan dengan spesifikasi Web pengembangan aplikasi.
- Persyaratan elisitasi
- Persyaratan Validasi
- Persyaratan Manajemen
Outlook
Spesifik RE untuk aplikasi Web. Pengantar singkat RE dan analisis dampak pengembangan aplikasi Web pada RE. Perkembangan beberapa di RE untuk Aplikasi Web di bawah ini:
- Menghilangkan perbatasan antara pengembangan dan penggunaan sistem
- Lebih baik integrasi persyaratan dan arsitektur
- Alat baru untuk rekayasa persyaratan didistribusikan
- RE dalam sistem terbuka
0 comments:
Post a Comment