Metode Dokumentasi - Rekayasa Kebutuhan

Requirement Engineering adalah aktivitas menginvestigasi dan mendeskripsikan ranah permasalahan dan kebutuhan-kebutuhan, serta merancang dan mendokumentasikan karakteristik suatu sistem solusi yang nantinya diharapkan dapat memenuhi kebutuhan pengguna.

Analisis

Analisis adalah proses mengklasifikasi informasi kebutuhan kedalam beberapa kategori, mengevaluasi kebutuhan untuk kualitas yang diinginkan, menampilkan kebutuhan dalam berbagai bentuk, memperoleh kebutuhan seceara mendetail dari high-level requirements, merancang prioritasnya, dan kegiatan-kegiatan lainnya yang berkaitan.

Spesifikasi

Spesifikasi adalah sebuah proses mendokumentasikan kebutuhan aplikasi perangkat lunak dalam bentuk yang terstruktur, mudah di bagikan dan mudah diatur. Juga, sebagai produk dalam proses tersebut.

Software Requirement Specification

Spesifikasi persyaratan perangkat lunak adalah kumpulan persyaratan fungsional dan non-fungsional untuk produk perangkat lunak. SRS sendiri meliputi :

1. Introduction :Tujuan, konvensi dokumen, batasan project, referensi 
2. Overall Description : Perspektif produk, kelas dan karakteristik pengguna, lingkungan operasi, kendala desain dan implementasi, asumsi dan dependensi 
3. System Features : Fitur sistem, deskripsi, kebutuhan fungsional, dan sebagainya 
4. Data Requirements : Model data logi, kamus data, laporan, akuisisi data, integritas, penyimpanan, dan pembuangan 
5. External Interface Requirements : Tampilan pengguna, tampilan perangkat lunak, tampilan perangkat keras, tampilan komunikasi 
6. Quality Attributes : Kegunaan, kinerja, keamanan, dan sebagainya 
7. Internationalization and Localization Requirements 
8. Other Requirements 
9. Appendix A : Glossary 
10. Appendix B : Analysis Models

Sebuah Kebutuhan yaang baik memiliki sifat :

• Komprehensif
• Benar
• Valid dan Aktual
• Dapat disetujui
• Penting
• Mudah dipahami
• Mudah ditelusuri
• Bernilai
• Dapat di implementasi
• Konsisten
• Dapat dibagi
• Dapat di test
• Tidak ambigu

Constructing Requirements

Requirements Template Chris Rupp & The SOPHISTs

Membangun Kebutuhan (Requirements) dapat menggunakan Requirement Template yang merupakan blueprint (kerangka kerja yang terperinci) yang menggambarkan struktur sintaksis kebutuhan.

Berikut adalah proses membangun kebutuhan berdasarkan Chris Rupp & The SOPHISTs

1. Menentukan proses mana yang akan menjadi kebutuhan

• Identifikasi fungsionalitas yang diinginkan
• Gunakan kata proses untuk mendeskripsikan prosesnya
• Kurangi jumlah kata proses menjadi kata yang lebih relevan untuk sistem

 2. Tentukan aktivitas sistem.

• Apakah sistem tidak bergantung pda sistem lainnya?
• Apakah proses tersebut adalah interaksi pengguna? 
• Apakah proses tersebut adalah sebuah kebutuhan antarmuka?

 3.  Menentukan tingkat kewajiban hukum

• Kebutuhan mana saja yang relevan terhadap hukum?
• Menggunakan kata kerja modal

Contoh : The system shall provides the receptionist with the ability to print (sistem harus memberikan resepsionis kemampuan untuk melakukan pencetakan)

 4. Perbaiki kebutuhannya

• Objek dan pelengkap mana yang hilang?
• Tambahkn objek dan pelengkap tersebut

Contoh : The system shall provides the receptionist with the ability to print a bill on the network printer (sistem harus memberikan resepsionis kemampuan untuk melakukan pencetakan tagihan pada network printer)

 5. Frasa Logikal dan Kondisi Temporal

• Dalam kondisi dan situasi apa agar kebutuhan tersebut bekerja?
• Taruh kondisi tersebut didepan kebutuhan

Contoh : If the option "Bill required" has been selected on the mobile device, the system shall provide the receptionist with the ability to print a bill on the network printer (Jika opsi "Tagihan diperlukan" telah dipilih pada perangkat seluler, sistem harus memberikan resepsionis kemampuan untuk melakukan pencetakan tagihan pada network printer)

  6. Gunakan SOPHIST-Rulebook untuk memastikan kelengkapan semantik.

• Terapkan aturan dan test pada SOPHIST set of Regulations
• Hindari informasi yang kurang lengkap
• Hindari pernyataan yang imajiner
• Hindari generalisasi yang keliru.