Requirement Engineering

cekidot...

2.1 Requirements Engineering

2.1.1    Definisi Requirements

Menurut Dorfman (1990) Sebuah requirement dalam konteks rekayasa perangkat lunak adalah sebuah kemampuan yang harus dimiliki dari suatu software. Kemampuan ini dapat ditujukan untuk memecahkan suatu permasalahan ataupun diperlukan untuk memenuhi ketentuan-ketentuan tertentu (seperti standar tertentu, keputusan manajemen, ataupun alasan-alasan politis).

Kumpulan dari berbagai requirement digunakan dalam berbagai aspek dalam pengembangan sebuah sistem. Dalam tahap perancangan, requirement digunakan untuk menentukan berbagai fitur yang akan ada di dalam sistem. Pada penghujung sebuah development effort, himpunan requirement ini digunakan untuk melakukan validation & verification untuk memastikan perangkat lunak yang telah dibuat memang sesuai dengan yang diinginkan. Bahkan selagi pengembangan berjalan, himpunan requirement ini terus dimodifikasi untuk menyesuaikannya dengan berbagai kebutuhan para stakeholder serta tenggat waktu dan dana yang tersedia.

Menurut Nuseibeh (2000) Secara luas, software systems requirements engineering (RE) adalah proses untuk menemukan suatu himpunan requirement yang tepat sehingga suatu perangkat lunak dapat memenuhi kegunaannya. Proses ini dilakukan dengan cara mengenali para stakeholder serta kebutuhan mereka serta mendokumentasikannya di dalam bentuk yang dapat digunakan untuk analisa, komunikasi, dan implementasi yang mengikutinya

Menurut Zave (1997) memberikan salah satu definisi yang paling jelas dari RE: Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.

2.2       Proses RE

Menurut Kotonya (1998) Terdapat lima aktivitas utama di dalam proses requirements engineering, yaitu :

·         Requirements elicitation

·         Requirements analysis and negotiation

·         Requirements documentation

·         Requirements validation

·         Requirements management and evolution

2.2.1    Requirements Elicitation

Menurut Pressman (2001) Pada tahap ini dikumpulkan berbagai requirement dari para stakeholder. Seorang pelanggan mempunyai masalah yang dapat ditangani oleh solusi berbasis komputer. Tantangan ini ditanggapi oleh seorang pengembang. Di sinilah komunikasi dimulai antara pelanggan, pengembang, dan calon pengguna dari sistem yang akan dibuat. Namun istilah elicitation agak diperdebatkan. Ada yang menganalogikannya dengan seperti yang dilakukan oleh para arkeolog ketika mengumpulkan runtuhan-runtuhan di situs purbakala.Ada yang memberikan istilah requirements capture karena dilakukan terutama dengan mengumpulkan fakta-fakta. Bahkan menyatakan bahwa requirement sebenarnya dibuat ketimbang didapatkan (elicitated). Walau yang terakhir ini nampaknya “lain sendiri”, argumen ini dapat diterima untuk pengembangan software yang sama sekali baru maupun untuk software-software permainan (games) yang terkadang permasalahan yang akan dipecahkan oleh game tersebut cenderung tidak berhubungan dengan solusinya ataupun sebenarnya masalah yang ada berasal dari bagian marketing2.

Sejalan dengan proses RE secara keseluruhan, tujuan dari requirements elicitation adalah :

·      Untuk mengetahui masalah apa saja yang perlu dipecahkan dan mengenali perbatasan-perbatasan sistem (system boundaries).

·         Untuk mengenali siapa saja para stakeholder.

·         Untuk mengenali tujuan dari sistem; yaitu sasaran-sararan yang harus dicapainya.

Beberapa jenis teknik pengumpulan requirement:

·    Traditional techniques merupakan berbagai cara pengumpulan data. Cara-cara ini termasuk kuesioner, survey, wawancara, serta analisis dari berbagai dokumentasi yang ada seperti struktur organisasi, petunjuk pelaksanaan (juklak) serta manual-manual dari sistem yang sudah ada.

·   Group elicitation techniques bertujuan untuk mengembangkan dan mendapatkan persetujuan stakeholder, sementara memanfaatkan dinamika kelompok untuk memperoleh pengertian yang lebih mendalam. Cara-cara ini termasuk brainstorming dan focus group, juga berbagai workshop RAD/JAD (workshop untuk membangun sebuah konsensus dengan menggunakan seorang fasilitator yang netral).

·      Prototyping techniques membuat suatu implementasi parsial dari software yang akan dibangun untuk membantu para pengembang, pengguna, serta pelanggan untuk lebih mengerti berbagai requirement sistem. Digunakan untuk mendapatkan umpan-balik yang cepat dari para stakeholder, teknik ini juga dapat digabungkan dengan berbagai teknik yang lain, seperti misalnya digunakan di dalam sebuah acara group elicitation ataupun sebagai basis dari sebuah kuesioner.

·         Model-driven techniques menempatkan suatu model khusus dari jenis informasi yang akan dikumpulkan untuk digunakan sebagai pedoman proses elicitation. Termasuk di antaranya adalah goal based methods seperti KAOS dan juga cara-cara berbasis skenario seperti CREWS.

·         Cognitive techniques termasuk serangkaian cara yang semulanya dikembangkan untuk knowledge acquisistion untuk digunakan di knowledge-based systems. Teknik-teknik ini termasuk protocol analysis (di mana seorang ahli melakukan sebuah tugas sembari mengutarakan pikiran-pikirannya), laddering (menggunakan berbagai pemeriksaan untuk mendapatkan struktur dan isi dari pengetahuan stakeholder), card sorting (meminta para stakeholder untuk menysun kartu-kartu secara berkelompok, di mana setiap kartu tertera nama sebuah domain entity), dan repertory grids (membuat sebuah attribute matrix for entities di mana para stakeholder diminta untuk mengisi matriks tersebut).

·    Contextual techniques muncul pada tahun 1990-an sebagai sebuah pilihan di luar traditional maupun cognitive techniques. Termasuk di antaranya penggunaan teknik etnografis seperti pengamatan terhadap para peserta. Juga termasuk ethnomethodogy dan analisis percakapan, yang keduanya menggunakan analisis terinci untuk mengenali pola-pola dalam percakapan dan interaksi

Dalam aktivitas requirements elicitation, ada baiknya untuk mengkategorikan berbagai requirement yang ditemukan. Suatu requirement dapat diklasifikasi sebagai functional requirement, non-functional requirement, maupun constraints. Sedangkan mengatakan bahwa suatu requirement dapat diklasifikasikan menjadi very general requirements, functional requirements, implementation requirements, performance requirements, dan usability requirements.

Namun nyatanya klasifikasi (atau cara-cara pengkategorian lainnya) requirement ini tidak mutlak diperlukan; klasifikasi requirement ditujukan terutama untuk menuntun proses elicitation. Hal ini perlu diwaspadai karena gara-gara para anggota tim tidak dapat setuju akan klasifikasi dari sekumpulan requirement, maka development effort dari sebuah perusahaan Fortune 500 mengalami stagnasi. Terjebaknya mereka di dalam masalah semantik ini merupakan salah satu contoh dari analysis paralysis.

2.2.2    Requirements modeling and analysis

Menurut Bennett (2000) Sebuah model adalah perwakilan dari benda lain yang mempunyai rincian yang cukup untuk membantu penyelesaian tugas-tugas tertentu. Data modeling bertujuan untuk mendapatkan pengertian dari pemrosesan serta pengaturan informasi. Behavioral modeling memodelkan berbagai perilaku dari para stakeholder serta berbagai sistem lain yang berhubungan dengannya. Domain modeling menyediakan suatu bentuk abstrak dari dunia tempat beroperasinya sistem yang akan dibuat.

Model-model yang dihasilkan dalam tahap ini ditujukan untuk analisa terhadap berbagai requirement yang ada. Para stakeholder berunding untuk mendapatkan suatu himpunan requirement akhir yang akan digunakan untuk tahap pengembangan selanjutnya. Menurut setelah selesainya tahap idealnya ini akan berlaku:

·         Berbagai requirement dari masing-masing stakeholder tidak bertentangan.

·         Informasi di dalam semua requirement harus lengkap.

·         Berbagai requirement yang ada harus selaras dengan anggaran yang dimiliki.

Walaupun dengan adanya batasan-batasan tersebut, seluruh requirement sebaiknya mudah diubah ataupun disesuaikan.

2.2.3 Requirement Documentation

Menurut Kotonya (1998), dokumen ini sebaiknya:

·         Hanya menetapkan perilaku sistem sebagaimana terlihat dari luar

·         Menetapkan batasan-batasan (constraints) yang diberikan kepada implementasinya.

·         Mudah diubah.

·         Berguna sebagai alat referensi untuk pemeliharaan sistem.

·         Memuat gambaran akan siklus kehidupan sistem di masa yang akan datang.

Untuk meningkatkan readability, beberapa standar dokumentasi SRS telah dikembangkan. Namun, serangkaian standar dan template apabila berdiri sendiri tidak dapat digunakan sebagai cara yang mandraguna untuk memberi struktur bagi sekumpulan requirement; tetapi struktur yang digunakan haruslah dikembangkan sendiri-sendiri tergantung dari masalah yang sedang ditangani. Masalah standarisasi notasi dan pendokumentasian requirement membuat pendekatan sistematis terhadap RE menjadi sulit. Daftar praktis ciri-ciri yang dinginkan pada sebuah requirements document:

• Unambigous. Idealnya, hanya ada satu interpretasi terhadap sebuah requirements document.
• Complete. Semua aspek yang bersangkutan haruslah dijelaskan secara lengkap di dalam requirements document.
• Consistent. Tidak ada pernyataan yang bertentangan dalam requirement document.
• Verifiable. Setelah sebuah sistem diimplementasikan, sebaiknya dapat dipastikan bahwa sistem tersebut memenuhi requirement awal.
• Validatable. Suatu requirement sebaiknya dapat diperiksa oleh pelanggan untuk memastikan bahwa requirement tersebut memang memenuhi kebutuhannya.
• Modifiable. Perubahan sebaiknya mudah dilakukan dan efek dari perubahan ini terhadap bagian-bagian lain sebaiknya minimal.
• Understandable. Semua stakeholder sebaiknya dapat mengerti requirement seperti ditetapkan di dalam dokumen.
• Testable. Semua requirement sebaiknya cukup kuantitatif untuk digunakan sebagai titik tolak pengujian sistem.
• Traceable. Harus dimungkinkan adanya pengacuan (reference) antar berbagai bagian di dokumen requirement ataupun ke bagian-bagian lain dari proses pembuatan perangkat lunak.

2.2.4 Requirements Validation

Menurut Kotonya (1998) Dalam tahap ini, dokumen dari tahap sebelumnya diperiksa agar memenuhi kriteriakriteria sebagai berikut :

·         Lengkap.

·         Konsisten.

·         Tunduk pada keputusan-keputusan yang diambil pada tahap requirements analysis.

Apabila ada requirement yang tidak memenuhi kriteria-kriteria tersebut, mungkin ada baiknya bagi proses RE untuk kembali ke tahap-tahap sebelumnya. Beberapa contoh masalah requirement yang terungkap pada tahap validasi antara lain :

·         Kurang/tidak cocok dengan bakuan-bakuan kualitas.

·         Kata-kata yang digunakan kurang baik sehingga requirement menjadi ambigu.

·   Berbagai kesalahan yang terdapat pada model-model baik – model sistem ataupun model permasalahan yang hendak dipecahkan.

·         Pertentangan antar requirement yang tidak ditemukan pada tahap analisis.

2.2.5 Requirements management and evolution

Menurut Kotonya (1998) Sebuah software yang sukses pasti akan berevolusi mengikuti perubahan lingkungannya. Sebaliknya, software yang sudah tidak diperbaharui berarti telah ditinggalkan oleh para penggunanya. Dalam perjalanan evolusi sebuah software, requirement akan software tersebut akan bertambah, berubah, atau terkadang berkurang. Agar perubahan ini terkendali, perlu adanya aktivitas requirements management (RM). Proses elicitation, analysis, documentation, dan validation dalam RE berjalan secara berkesinambungan tanpa adanya batasan-batasan yang definitif. Fungsi lain dari requirements management adalah untuk memastikan agar berbagai aktivitas dalam proses RE ini berjalan dengan baik – agar iterasi demi iterasi dalam RE dilakukan secara terkendali dan (diharapkan) menuju suatu kemajuan. Maka dari itu requirements management digambarkan secara paralel dengan pengulangan dari aktivitas-aktivitas RE lainnya.

Dalam aktivitasnya mengendalikan perubahan requirement maupun mengendalikan proses RE itu sendiri, pada requirements management juga dilakukan penyusunan berbagai informasi traceability – yaitu keterhubungan antara berbagai artifak di dalam proses RE (termasuk perubahan requirement). Traceability itu sendiri merupakan konsep yang penting di dalam RE yang akan selanjutnya dibahas berikutnya.

2.3 Traceability

Menurut Jarke (1998) Traceability adalah cara untuk membentuk hubungan-hubungan antara manusia dan sistem dengan model-model di mana mereka dikelola. Kutipan berikut memberikah sebuah garis besar mengenai pentingnya traceability di dalam rancangan sistem secara keseluruhan: “Requirement tracing is emerging as an effective bridge that aligns system evolution with changing stakeholder needs. It also helps uncover unexpected problems and innovative opportunities, and lays the groundwork for corporate knowledge management.”

 

Secara tradisional ada empat jenis informasi traceability :

·         Forward-from traceability menghubungkan requirement ke rancangan komponen-komponen dan penerapannya serta memberikan tanggungjawab kepada komponen-komponen sistem tersebut untuk pencapaian requirementrequirement tertentu.

·         Backward-to traceability menghubungkan rancangan serta komponenkomponen penerapannya kembali kepada requirement untuk memungkinkan pengujian sistem terhadap pemenuhan requirement tersebut.

·         Forward-to traceability menghubungkan informasi domain beserta informasi lain yang bersangkutan yang mendahului rancangan sistem ke berbagai requirement. Traceability ini memungkinkan penaksiran pengaruh perubahan kebutuhan stakeholder maupun perubahan berbagai asumsi.

·         Backward-from traceability menghubungkan requirement ke sumber-sumbernya pada dokumen-dokumen ataupun orang-orang lain. Traceability ini memungkinkan diketahuinya struktur kontribusi yang mendasari berbagai requirement yang ada – yang sangat penting di dalam validasi requirement.

Dua jenis trace yang pertama sering disebut post-traceability sedangkan dua yang terakhir disebut pre-traceability. Seperti ditunjukkan di saat ini post-traceability cenderung lebih dimengerti ketimbang pre-traceability, walaupun pre-traceability mempunyai kemungkinan untuk menyediakan hubungan antara bisnis dengan IT3 yang saat ini sangat diperlukan.

Walaupun empat jenis trace tersebut sangat populer di dalam berbagai literatur, mereka bukanlah satu-satunya jenis traceability yang ada. Bahkan nampak bahwa untuk setiap proyek mungkin diperlukan jenis-jenis trace-nya sendiri sesuai dengan kebutuhan proyek tersebut; kemampuan ini disediakan di banyak alat bantu RE.

2.4 Requirements Patterns

Menurut Gamma (1995), telah ditunjukkan bahwa pattern dapat membawa pengaruh positif dalam bidang software engineering. Walau buku ini membahas design pattern – yang notabene adalah artifak dari solution space, semangat yang sama juga dapat diterapkan pada problem space. Dengan mengumpulkan serta mengkategorisasikan berbagai pengalaman kolektif dalam bidang RE, tentulah akan meningkatkan kualitas RE sebagai ilmu praktis.

Sebuah pattern adalah pemecahan yang telah ditemukan untuk suatu masalah yang umum. Praktis diresmikan oleh Gamma dkk. dalam [Gamm95], suatu pattern digambarkan sebagai kesatuan dari niatan, alias, motivasi, penggunaan, akibat, serta contoh penerapannya.

Berbagai keuntungan yang bisa didapatkan dengan mempelajari pattern menjadi pendorong riset ke arah RE patterns. Sedikit berbeda dengan design patterns, tujuan dari setiap RE pattern adalah untuk mengurangi ambiguitas yang dapat terjadi serta pada saat yang bersamaan memberikan kebebasan terhadap pemenuhan requirement tersebut.

Memang studi RE patterns masih ketinggalan ketimbang yang telah dilakukan di dalam solution space. Walaupun demikian, telah diberikan tiga pattern sebagai satu permulaan bagi sebuah katalog yang dapat menandingi. Ketiga pattern ini telah digunakan dengan sukses di dalam empat SRS yang berbeda di mana masing-masing menangani problem domain yang berbeda pula:

·         Specify (Locate) – menggambarkan bagaimana seorang (sebuah) aktor dapat menemukan suatu obyek di dalam aplikasi.

·         Present (Display) – menggambarkan data yang harus ditampilkan oleh aplikasi.

·          Prioritize (Sort) – untuk mengkomunikasikan bagaimana suatu aspek aplikasi didahulukan dari yang lain.

Ketiga pattern di atas terutama difokuskan untuk pembuatan berbagai requirement statement. Tetapi karena RE juga meliputi requirements management, maka diberikan dua pattern berikut untuk mengatasi berbagai tantangan politis di dalam RE:

·   Requirement As [a] Shield – ketika seseorang mengkritik pekerjaan yang dilakukan, untuk menunjukkan bahwa kritik yang dilontarkan tidak berhubungan dengan masalah yang sedang ditangani.

·     Requirement As [a] Stick – untuk meniadakan berbagai pendekatan atau strategi yang diusulkan namun tidak menguntungkan bagi organisasi; dengan mengevaluasi pendekatan-pendekatan dan strategi ini terhadap requirement yang telah diterima, kelemahan-kelemahannya akan cepat nampak.

2.5 Alat Bantu RE

Menurut Kotonya (1998) Tipe alat bantu RE yang menjadi fokus proyek ini adalah alat bantu untuk requirements management. Alat bantu ini berguna untuk mengumpulkan system requirements di dalam sebuah tempat penyimpanan serta menyediakan berbagai fasilitas untuk mendapatkan informasi mengenai berbagai requirement tersebut. Sebuah alat bantu requirements management umumnya memiliki fasilitasfasilitas berikut:

·      Sebuah requirements browser sehingga para pembaca dapat mengambil suatu requirement yang spesifik dari database ataupun repository.

·  Sebuah query system sehingga para pengguna dapat mengambil berbagai requirement yang berhubungan.

· Sebuah requirements converter dan processor linker yang dapat mengubah berbagai requirement di dalam sebuah dokumen pengolah kata ke dalam bentuk basis data requirement dan dapat memelihara hubungan antara database dengan perwakilan bahasa alami dari requirement tersebut.

·     Sebuah change control system yang dapat memelihara informasi mengenai perubahan-perubahan requirement dan hubungan-hubungan dengan berbagai requirement yang terpengaruhi oleh perubahan tersebut.

2.6 Arsitektur Alat Bantu

Menurut Wiegers (1999) Secara tradisional, alat bantu RE menyimpan berbagai requirement di dalam bentuk database atau dokumen. Menurut [Wieg99], pendekatan berbasis dokumen untuk menyimpan requirement mempunyai beberapa keterbatasan:

·         Sulit untuk menjaga agar semua dokumen tetap tersinkronisasi dan terkini.

·  Mengkomunikasikan perubahan-perubahan kepada semua anggota tim yang terpengaruh merupakan sebuah proses manual.

·      Sulit untuk membuat hubungan-hubungan antara functional requirement dengan berbagai use case, rancangan, kode program, pengujian, dan berbagai tugas untuk menghasilkan artifak-artifak tersebut.

·         Tidak praktis untuk melacak status dari setiap requirement.

Selain masalah-masalah di atas, masalah umum yang terjadi dengan bahasa alami sudah umum diketahui. Sebuah pemecahan kepada masalah-masalah ini adalah dengan menyimpan berbagai requirement di dalam sebuah basis data multi-user serta mengendalikan akses kepadanya dengan alat bantu requirement management. Namun juga ada beberapa batasan dengan pendekatan ini :

·         Format file database seringkali proprietary dan tidak dapat dibaca oleh manusia.

·     Format file database tidak komplementer; apabila sebuah dokumen requirement disimpan di dalam suatu database menggunakan satu alat bantu maka tidaklah mungkin untuk menambah informasi dengan suatu alat bantu lain yang berbeda. Hal ini hanya mungkin dengan dokumen, di mana lebih banyak informasi dapat diberikan dengan menambahkan lebih banyak teks.

·        Karena sebenarnya tidak ada dokumen requirement, maka proses requirement yang ada sangat tergantung dengan alat bantu yang digunakan. Banyak alat bantu RE yang menggabungkan kedua pendekatan, baik yang berbasis dokumen maupun dengan database.

Sedangkan INCOSE [Jone95] memberikan empat jenis arsitektur alat bantu requirements management:

· Arsitektur A – document based. Arsitektur ini menggunakan komponen utama sebuah program spreadsheet (seperti QuattroProTM, Lotus 1-2-3TM, ExcelTM) atau word processor (seperti WordPerfectTM, AmiProTM, atau MS WordTM) dengan diberi fungsi-fungsi tambahan untuk melakukan RM dengan menggunakan fasilitas pemrograman yang diberikan oleh program paket tersebut (umumnya bahasa macro). Teks di dalam dokumen diberi tanda-tanda khusus yang menandakan teks tersebut sebagai sebuah requirement.

·    Arsitektur B – hybrid. Seperti pada Arsitektur A namun dengan tambahan validasi automatis dari berbagai requirement yang terdapat di dalam dokumen-dokumen. Alat-alat ini dapat menghasilkan sebuah daftar yang memuat berbagai requirement yang terlalaikan ataupun tidak perlu.

·   Arsitektur C – special-purpose-database-based. Alat-alat RM yang termasuk di dalam kategori ini menyimpan seluruh teks requirement di dalam sebuah basis data, namun program database yang digunakan adalah bagian dari program RM itu sendiri.

·   Arsitektur D – general-purpose-database-based. Alat bantu yang termasuk kategori ini menyimpan teks requirement menggunakan database yang terpisah. Program DBMS yang digunakan adalah suatu program – umumnya komersial tersendiri.