Requirements Engineering for Web Application

Setelah kemarin ngomongin istilah-istilah tentang Rekayasa Web, nah sekarang kita sampai ke pembahasan "Requirements Engineering for Web Application". Simak lagi yuuk. . .

Rekayasa Kebutuhan (RE) merupakan kegiatan yang sangat penting bagi keberhasilan rekayasa web. Adanya persyaratan tidak lengkap, ambigu, atau tidak benar dapat menimbulkan kesulitan berat dalam pembangunan, atau bahkan menyebabkan pembatalan proyek.

2.1 Pengenalan

Proses requirement (pencatatan kebutuhan) merupakan kunci dalam pengembanagan aplikasi web. Pengembagan aplikasi web memiliki persyaratan yang sangat penting, tetapi pada kenyataanya seringkali tidak dijelaskan kunci dari pengembangan aplikasi tersebut, sehingga berakibat pada kegagalan perencanaan proyek dan pada arsitektur software yang tidak memadai. Pada dasarnya rekayasa web juga berkaitan dengan prinsip-prinsip, metode untuk mengidentifikasi, mendeskripsikan, memvalidasi dan mengelola persyaratan dalam pengembangan sistem.

       Berikut adalah berbagai konsekuensi tentang pentingnya persyaratan untuk suksesnya pengembangan sistem dengan berbagai standar, pendekatan, model, bahasa deskripsi dan alat-alat yang telah bermunculan.

• Dalam sebuah penelitian yang dilakukan di antara 340 perusahaan di Austria pada tahun 1995, lebih dari dua per tiga perusahaan-perusahaan tersebut dianggap sebagai pengembangan dengan masalah besar dalam proses pengembangan mereka.
• Dari hasil survei menghasilkan lebih dari 8000 proyek yang dilakukan oleh Standish Group menunjukkan bahwa 30% dari semua proyek gagal dan 70% dari proyek tersebut tidak memenuhi harapan pelanggan.
• Menurut sebuah studi pada pengembangan aplikasi web yang dilakukan oleh para cutter konsorsium hanya 16% dari sistem sepenuhnya memenuhi persyaratan dari kontraktor, sementara 53% dari sistem tidak memenuhi syarat.

Meskipun ada konsekuen umum tentang pentingnya nilai-nilai rekayasa web untuk memenuhi jadwal, anggaran dan sasaran mutu, sering ada masalah dalam adaptasi dan penggunaan proses, metode elisitasi, notasi dan alat-alat terutama dalam pengembangan aplikasi web.

2.2 Fundamentals

2.2.1 Darimana asalnya persyaratan ?

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. penting stakeholder adalah pelanggan, pengguna, dan pengembang. Stakeholder Khas untuk aplikasi Web termasuk konten penulis, pakar domain, ahli kegunaan, atau profesional pemasaran. Tujuan dan harapan stakeholder cukup beragam, seperti yang ditunjukkan oleh beberapa contoh:

• Aplikasi Web akan tersedia secara online tanggal 1 September 2006
• Aplikasi Web akan mendukung minimal 2500 pengguna bersamaan (kualitas obyektif pelanggan).
• 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.

2.2.2 Aktivitas Kebutuhan Rekayasa

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

-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.  Dalam proses ini, komunikasi antara para pemangku kepentingan sangat penting, karena hanya keahlian mereka bersama, dapat menyebabkan solusi yang saling diterima.

-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 dan keterampilan dari para pembaca yang diharapkan.

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

-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. Mereka juga membantu dalam mengevaluasi dampak dari perubahan dengan mengelola saling ketergantungan di antara persyaratan, dan antara kebutuhan dan pembangunan lainnya.

2.3 Spesifikasi Teknik Rekayasa Web

Teknik Rekayasa Web berbeda dari RE untuk sistem software konvensional, perbedaan ini tampaknya diabaikan seperti yang 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. Namun, jika kita melihat lebih dekat di beberapa spesifik, perbedaan menjadi jelas. Subbagian berikut mengeksplorasi dengan menggunakan karakteristik aplikasi Web yang dibahas dalam Bab 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.

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

*Persyaratan dan Kendala

Persyaratan dan kendala seperti sifat dari platform penyebaran atau komunikasi protokol sering lebih mudah dalam menentukan sistem perangkat lunak konvensional daripada untuk aplikasi Web. Aplikasi web dan lingkungan mereka sangat dinamis, persyaratan dan kendala biasanya sulit untuk distabilkan.

*Dampak Sistem Legacy

Pengembangan aplikasi Web ditandai dengan integrasi komponen perangkat lunak seperti komersial off-the-shelf produk atau perangkat lunak open source. Komponen yang perlu diintegrasikan sangat mempengaruhi persyaratan dan gaya arsitektur dari sistem di masa depan.

 *Kualitas Tampilan

 

*Kualitas Konten

Meskipun merupakan aspek yang sangat penting dari aplikasi Web, banyak metode tradisional yang mengabaikan konten Web. Selain masalah teknologi perangkat lunak, pengembang harus mempertimbangkan isi, khususnya penciptaan dan pemeliharaan. 

2.4 Prinsip 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

2.5 Beradaptasi Metode RE untuk Pengembangan Aplikasi Web

Pada saat ini berbagai metode, pedoman, notasi, daftar periksa, dan alat-alat semuanya tersedia untuk kegiatan di RE. Namun, untuk meraih keberhasilan pengembang harus menghindari “satu ukuran cocok untuk semua”. Diperlukan adanya pendekatamemandu definisi pendekatan proyek-spesifik RE untuk rekayasa Web. Antara lain, pengembang harus memperjelas aspek-aspek berikut selama proses adaptasi:

  *jenis persyaratan penting untuk aplikasi Web

  *Bagaimana persyaratan untuk aplikasi Web dijelaskan dan didokumentasikan.

  *Haruskah penggunaan alat dipertimbangkan?

2.5.1 Persyaratan Jenis

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

2.5.2 Notasi

Sebagian besar notasi yang tersedia bertujuan untuk menentukan persyaratan dalam derajat yang berbeda dari detail dan formalitas. Risiko 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

Gambar 2-2 menguraikan suatu skenario pendek/singkat dari sudut pandang pelanggan :

User memeriksa produk yang dia letakkan pada keranjang belanja onlinenya. Memasukkan validasi sebagai user kemudian klik < lanjut>. Jika tidak ditemukan kesalahan, kemudian pesanan akan diterima dan sebuah konfirmasi e-mail akan dikirim kepada user tersebut

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

2.5.3 Tools yang Diperlukan 
         1. persyaratan elisitasi 
         2. persyaratan Validasi 
         3.persyaratan Manajemen

2.6 Pandangan

Berikut uraian secara singkat beberapa kecenderungan pengembangan aplikasi web:

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