Requerement Engineering for WEB Application

klo boleh curcol sedikit nich ane menulis ini disamping demi melaksanakan tugas Mata Kuliah Rekayasa WEB yang dosen pengampunya Pak wahyu (mas wahyu) ane menulis supaya bisa berbagi ilmu sedikit dan bisa memberi wawasan bagi yang membaca blog ane. :)

berikut penjelsan sedikit tentang Requerement Engineering for WEB Application. 

A.PENGANTAR

    Dalam pengembangan aplikasi web mempunyai persyaratan yang sangat penting, tetapi pada kenyataanya sering tidak dijelaskan kunci dari pengembangan aplikasi tersebut. Sehingga mengakibatkan kegagalan perencanaan proyek dan juga mengakibatkan arsitektur software yang tidak memadai. Sebernarnya rekayasa web juga ada kaitannya dengan prinsip-prinsip, metode untuk mengidentifikasi, mendeskripsikan, memvalidasi dan mengelola persyaratan dalam pengembangan sistem.

     Ada beberapa konsekuensi luas tentang pentingnya kebutuhan untuk pengembangan sistem yang sukses dan selama bertahun-tahun sebagai standar, pendekatan, model, deskripsi bahasa, dan alat-alat telah muncul. Berikut beberapa industri perangkat lunak masih berkutat dengan kesulitan besar ketika ada sebuah kebutuhan :

• Dalam sebuah penelitian yang dilakukan di antara 340 perusahaan di Austria pada tahun 1995, lebih dari dua pertiga dari perusahaan-perusahaan ini dianggap pengembangan dokumen kebutuhan sebagai masalah besar.
• Sebuah survei di antara lebih dari 8000 proyek yang dilakukan oleh Standish Group menunjukkan bahwa 30% dari semua proyek gagal sebelum penyelesaian dan 70% dari proyek yang tersisa tidak memenuhi.
• Menurut sebuah studi pada pengembangan aplikasi Web yang dilakukan oleh Konsorsium Cutter hanya 16% dari sistem sepenuhnya memenuhi kebutuhan dari kontraktor, sementara 53% dari sistem dikerahkan tidak memenuhi kemampuan yang diperlukan (Cutter Consortium 2000).

Meskipun ada konsekuensi umum tentang pentingnya nilai-nilai RE untuk memenuhi tujuan jadwal, anggaran, dan kualitas, sering ada masalah dalam adaptasi beton dan penggunaan proses yang tersedia, metode elisitasi, notasi, dan alat-alat. Pada prinsipnya RE bertujuan untuk pengembangan aplikasi Web dan mempelajari bagaimana metode RE yang ada dapat disesuaikan dengan spesifikasi proyek Web.

B. FUNDAMENTALS

    B.1 Darimana asalnya?

       Tujuan 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. Tujuan dan harapan stakeholder cukup beragam, seperti yang ditunjukkan oleh beberapa contoh:

1. Aplikasi Web akan tersedia secara online tanggal 1 September 2006
2. Aplikasi Web akan mendukung minimal 2500 pengguna bersamaan (kualitas obyektif pelanggan).
3. Semua data pelanggan harus aman dll.

       Sebuah persyaratan menggambarkan property yang harus dipenuhi atau jasa yang akan disediakan oleh sistem. Persyaratan tersebut adalah sebagai berikut:

1. suatu kondisi atau kemampuan yang dibutuhkan oleh pengguna untuk memecahkan masalah atau mencapai suatu tujuan.
2. kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh sistem atau komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau secara resmi dikenakan dokumen.
3. representasi terdokumentasi dari kondisi atau kemampuan.

      Persyaratan biasanya dikategorikan sebagai persyaratan fungsional, persyaratan non-fungsional Persyaratan fungsional menentukan kemampuan sistem dan layanan, sementara non-fungsional persyaratan yang diinginkan untuk menggambarkan tingkat kualitas “Seberapa aman?”, ” bagaimana penggunaanya?”, dll.

    B.2 Aktivitas Kebutuhan Rekayasa

Rekayasa web meliputi elisitasi, dokumentasi, verifikasi dan validasi, serta manajemen persyaratan seluruh proses pembangunan.

B.2.1 Persyaratan elisitasi dan Negosiasi

Para peneliti telah menunjukkan bahwa “persyaratan tidak keluar sana untuk dikumpulkan dengan meminta hak pertanyaan” Sebaliknya, persyaratan adalah hasil belajar yang berlandaskan atas proses pembangunan.

B.2.2 Persyaratan Dokumentasi

Jika stakeholder mencapai konsensus, kesepakatan mereka harus disempurnakan dan dijelaskan dalam persyaratan dokumen tingkat detail dan formalitas yang sesuai untuk proyek konteks.

B.2.3 Persyaratan Verifikasi dan Validasi

Persyaratan harus divalidasi Dan diverifikasi “Apakah kita menentukan hal-hal dengan benar . Ada beberapa metode konvensional untuk tujuan ini, seperti ulasan, inspeksi, atau prototyping. Dalam Rekayasa Web, keterbukaan Internet memfasilitasi bentuk-bentuk baru dari partisipasi pengguna langsung dalam validasi persyaratan, misalnya, melalui koleksi online dari umpan balik pengguna.

B.2.4 Persyaratan Manajement

Peralihan menjadi stabil, 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.

 

   B.3 Spesifikasi Teknik Rekayasa Web

Teknik Rekayasa Web berbeda dari RE untuk sistem software konvensional, perbedaan ini tampaknya diabaikan sebagaimana dikatakan oleh para peneliti di lapangan “Meskipun ada banyak perbedaan antara pengembangan Web dan pengembangan perangkat lunak  Ada Juga kesamaan di antara mereka. Ini termasuk Persyaratan elisitasi.

B.3.1 Multidisciplinarity

Pengembangan aplikasi Web memerlukan partisipasi dari para ahli. 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.

B.3.2 Ketidaktersediaan Stakeholder

Proyek manajemen perlu mencari perwakilan yang cocok yang dapat memberikan persyaratan yang realistis.  Misalnya, sering ada spektrum yang luas dari pengguna mungkin dalam proyek Web.

B.3.3 Persyaratan 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, 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.

B.3.4 Dampak Sistem Legacy

Pengembangan aplikasi Web ditandai dengan integrasi perangkat lunak yang ada komponen seperti komersial off-the-shelf produk 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.

B.3.5 Kualitas Konten

Banyak 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 .

       

     B.4 Prinsip RE Aplikasi Web

Karakteristik Bagian sebelumnya membahas aplikasi Web dan spesifik RE di rekayasa Web. 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:

• Memahami Konteks Sistem
• Melibatkan Stakeholder
• Iteratif Definisi Persyaratan
• Fokus pada Arsitektur Sistem
• Risiko Orientasi

      B.5 Beradaptasi Metode RE untuk Pengembangan Aplikasi Web

Pada saat ini banyak 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 di dokumentasikan
• Haruskah penggunaan alat dipertimbangkan?

B.5.1 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
• Kendala Proyek

B.5.2 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. Risiko proyek yang diidentifikasi memberikan pengarahan dalam pemilihan tingkat yang cocok kualitas spesifikasi, yaitu, untuk menentukan berapa banyak RE cukup dalam proyek tertentu.

Sejarah

• 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).

B.5.3 Tools

1. persyaratan elisitasi
2. persyaratan Validasi
3. persyaratan Manajemen

     B.6 Outlook

1. Menghilangkan perbatasan antara pengembangan dan penggunaan sistem
2. Lebih baik integrasi persyaratan dan arsitektur
3. alat Baru untuk rekayasa persyaratan didistribusikan
4. RE dalam sistem terbuka