Pertemuan 3 Kebutuhan Perangkat Lunak

Pertemuan 3

KEBUTUHAN PERANGKAT 

LUNAK

  1. REKAYASA KEBUTUHAN

• Kebutuhan untuk suatu sistem adalah deskripsi tentang apa yang harus dilakukan oleh sistem berupa layanan yang diberikan dan kendala dalam operasinya.

• Kebutuhan ini mencerminkan kebutuhan pelanggan untuk sistem yang melayani tujuan tertentu seperti mengontrol perangkat, menempatkan pesanan, atau mencari informasi.

• Proses mencari tahu, menganalisis, mendokumentasikan serta memeriksa layanan dan kendala ini disebut Rekayasa Kebutuhan (Requirement Engineering).

                    •  Rekayasa Kebutuhan harus disesuaikan dengan kebutuhan proses, proyek, produk, dan                                                             orang-orang yang melakukan pekerjaan.

Jenis Kebutuhan:

1.       Kebutuhan pengguna adalah pernyataan, dalam bahasa alami ditambah diagram, dari layanan apa yang diharapkan sistem untuk diberikan kepada pengguna sistem dan kendala di mana ia harus beroperasi.

2.       Kebutuhan sistem adalah deskripsi yang lebih rinci tentang fungsi, layanan, dan kendala operasional sistem perangkat lunak. Dokumen Kebutuhan sistem (kadang-kadang disebut spesifikasi fungsional) harus mendefinisikan secara tepat apa yang akan diimplementasikan. Ini mungkin menjadi bagian dari kontrak antara pembeli sistem dan pengembang perangkat lunak.

Kegiatan pada Rekayasa Kebutuhan:

1.            Pengenalan Permasalahan (Inception)

2.            Pengenalan Lanjutan (Elicitation)

3.            Elaborasi (Elaboration)

             4.            Negosiasi

5.            Spesifikasi (Specification)

6.            Validasi (Validation)

7.            Manajemen Kebutuhan (Requirement Management)

A.    Pengenalan Permasalahan (Inception)

• Proyek PL dimulai ketika kebutuhan bisnis atau pasar atau layanan baru telah diidentifikasi atau ditemukan

• Menetapkan pemahaman dasar tentang masalah, siapa yang menginginkan solusi, sifat solusi, serta keefektifan komunikasi dan kolaborasi antara stakeholder dengan tim PL.

B.    Pengenalan Lanjutan (Elicitation)

•  Bagian penting dari elisitasi adalah untuk menetapkan tujuan bisnis.

                              •  Masalah yang sering dijumpai:

ü  Lingkup permasalahan: tentang batasan sistem tidak jelas atau rincian teknis yang membingungkan

ü  Permasalahan yang berkaitan dengan pemahaman

ü  Permasalahan yang berkaitan dengan kestabilan

Kegiatan pada tahap ini adalah:

1.      Kebutuhan penemuan

adalah proses pengumpulan informasi tentang sistem yang diperlukan dan sistem yang ada, filterisasi pengguna dan kebutuhan sistem.

Sumber informasi selama tahap penemuan kebutuhan termasuk dokumentasi, stakeholder, dan spesifikasi sistem.

2.      Klasifikasi Kebutuhan dan Organisasi

Kegiatan ini mengumpulkan kebutuhan yang tidak terstruktur dan kebutuhan kelompok yang bersifat koheren.

Cara pengelompokkan kebutuhan menggunakan model arsitektur sistem untuk mengidentifikasi sub-sistem dan untuk menghubungkan kebutuhan dengan masing- masing sub-sistem.

3.      Kebutuhan Prioritas dan Negosiasi

Kegiatan ini berkaitan dengan memprioritaskan kebutuhan dan menemukan cara penyelesaian konflik melalui negosiasi.

C.    Elaborasi (Elaboration)

• Elaborasi dilakukan dengan cara membuat dan penyempurnaan skenario pengguna yang menggambarkan bagaimana pengguna akhir (dan aktor lain) akan berinteraksi dengan sistem.                       

                                D.    Negosiasi

• Konflik yang terjadi antara pelanggan, pengguna dan stakeholder harus didamaikan dengan pendekatan yang bersifat iteratif untuk menentukan skala prioritas kebutuhan, menilai biaya-biaya dan risiko masing- masing.

        E.   
Spesifikasi (Specification)

• Spesifikasi kebutuhan adalah proses menuliskan kebutuhan pengguna dan kebutuhan sistem ke dalam dokumen kebutuhan.

• Spesifikasi dapat berupa dokumen tertulis, model grafis, model matematika formal, kumpulan skenario penggunaan sistem/PL, prototipe, atau kombinasi dari semuanya.

• Kebutuhan pengguna menggambarkan kebutuhan fungsional dan non-fungsional sehingga dapat dimengerti oleh pengguna sistem (perilaku eksternal dari sistem) yang tidak memiliki pengetahuan teknis.

• Dokumen kebutuhan tidak boleh menyertakan rincian arsitektur atau desain sistem.

1). Spesifikasi Bahasa

• Bahasa alami telah digunakan untuk menulis kebutuhan PL sejak awal RPL yang bersifat ekspresif, intuitif, dan universal.

•                           Panduan sederhana:

1.   Buat format standar dan pastikan bahwa semua definisi kebutuhan mematuhi format tsb.

2.   Gunakan bahasa secara konsisten

3.   Gunakan penjelasan teks (tebal, miring, atau warna) untuk memilih bagian bagian penting dari kebutuhan.

4.   Jangan berasumsi bahwa pembaca memahami bahasa RPL, hindari penggunaan jargon, singkatan, dan akronim.

5.   Sebisa mungkin, harus mencoba mengaitkan alasan dengan setiap kebutuhan pengguna

                                                         2). Spesifikasi Struktur

•  Bahasa alami terstruktur adalah cara penulisan kebutuhan sistem dimana kebebasan dalam penulisan terbatas dan semua kebutuhan ditulis dengan cara standar.

•  Untuk menentukan kebutuhan fungsional, informasi berikut harus disertakan:

1.   Deskripsi fungsi atau entitas yang ditentukan.

2.   Penjelasan tentang input dan dari mana asalnya.

3.   Penjelasan tentang output dan kemana tujuannya.

4.   Informasi yang diperlukan untuk perhitungan atau entitas lain dalam sistem yang digunakan.

         5.   Penjelasan tentang tindakan yang harus diambil.

6.   Penjelasan tentang efek samping dari operasi (jika ada)

F.      Validasi (Validation)

• Validasi kebutuhan adalah proses pengecekan kebutuhan yang benar-benar menentukan sistem yang diinginkan oleh pelanggan.

                              • Validasi melakukan pemeriksaan untuk memastikan bahwa:

ü  Semua kebutuhan PL telah dinyatakan dengan jelas

ü  Inkonsistensi, kelalaian, dan kesalahan telah terdeteksi dan diperbaiki

ü  Produk kerja sesuai dengan standar yang ditetapkan untuk proses, proyek, dan produk.

1.       Pemeriksaan Validitas

Suatu sistem diperlukan untuk melakukan fungsi-fungsi tertentu dan dapat mengidentifikasi fungsi tambahan.

2.       Pemeriksaan Konsistensi

Kebutuhan dalam dokumen tidak boleh bertentangan. Artinya, tidak ada batasan yang bertentangan atau deskripsi yang berbeda dari fungsi sistem yang sama.

3.       Pemeriksaan Kelengkapan Dokumen

Kebutuhan yang mendefinisikan semua fungsi dan

batasan yang dimaksudkan oleh pengguna sistem.

Hal-hal yang perlu pemeriksaan:

4.       Pemeriksaan Realisme

Dengan menggunakan pengetahuan tentang teknologi yang ada, kebutuhan harus diperiksa untuk memastikan bahwa mereka benar-benar dapat diimplementasikan.

5.       Verifiability

Kebutuhan sistem harus selalu ditulis sehingga dapat diverifikasi, artinya menulis serangkaian tes yang dapat menunjukkan bahwa sistem yang dikirimkan memenuhi setiap kebutuhan yang ditentukan.

G.   
Manajemen Kebutuhan (Requirement Management)

•  Adalah serangkaian kegiatan yang membantu tim proyek untuk mengidentifikasi, mengontrol, dan melacak kebutuhan-kebutuhan dan melacak perubahan terhadap kebutuhan saat proyek berlangsung.

•  Ada beberapa alasan mengapa perubahan tidak dapat dihindari:

1.       Lingkungan bisnis dan teknis sistem selalu berubah

setelah instalasi.

2.       Pengguna sistem bukan orang yang sama.

3.       Sistem besar biasanya memiliki komunitas pengguna

yang beragam

1).      Kebutuhan Perencanaan Manajemen

Tahap perencanaan menetapkan tingkat detail manajemen kebutuhan yang diperlukan, dengan memutuskan:

                          1. Identifikasi Kebutuhan

Setiap kebutuhan harus diidentifikasi secara unik sehingga dapat direferensikan dengan kebutuhan lain dan digunakan dalam pelacakan.

                           2. Proses manajemen perubahan

Adalah serangkaian kegiatan yang menilai dampak dan biaya perubahan.

3. Kebijakan Pelacakan

Menentukan hubungan antara setiap kebutuhan, kebutuhan dengan desain sistem, dan pemeliharaan catatan-catatan.

4. Dukungan alat

Kebutuhan manajemen melibatkan pemrosesan

sejumlah besar informasi tentang kebutuhan.

Alat yang dapat digunakan berkisar dari sistem manajemen kebutuhan khusus untuk spreadsheet dan sistem basis data sederhana.

2).      Kebutuhan Manajemen Perubahan

•                                       Kebutuhan manajemen perubahan harus diterapkan untuk semua perubahan yang diajukan pada kebutuhan sistem setelah dokumen kebutuhan disetujui.

•                                       Ada tiga tahapan utama untuk proses manajemen

perubahan:

1.            Analisis masalah dan spesifikasi perubahan

2.            Analisis dan biaya perubahan

3.            Perubahan implementasi

2.      
KEBUTUHAN FUNGSIONAL DAN NON-FUNGSIONAL

•                           Kebutuhan Fungsional adalah layanan yang harus disediakan sistem, bagaimana sistem harus bereaksi terhadap input tertentu, dan bagaimana sistem harus berperilaku dalam situasi tertentu.

•                           Kebutuhan non-fungsional adalah batasan pada layanan atau fungsi yang ditawarkan oleh sistem.

Termasuk:

ü  Kendala waktu

ü  Kendala pada proses pengembangan

ü  Kendala yang dikenakan oleh standar

A.                  Kebutuhan Fungsional

                                •  Kebutuhan fungsional menggambarkan apa yang harus

dilakukan oleh sistem.
•  Kebutuhan ini tergantung pada jenis PL yang dikembangkan, pengguna, dan pendekatan umum yang diambil oleh organisasi saat menulis kebutuhan.

                                •  Kebutuhan pengguna dijelaskan secara abstrak yang dapat dipahami oleh pengguna sistem, terutama untuk kebutuhan sistem yang lebih spesifik menggambarkan fungsi-fungsi sistem, input dan output, dan pengecualian secara rinci

  

                                •     Contoh: kebutuhan fungsional untuk sistem informasi

tentang pasien:

ü  User harus dapat mencari daftar janji untuk semua poliklinik sesuai dengan jadwal praktek dokter.

ü  Setiap hari, untuk setiap poliklinik mencatat daftar pasien yang telah melakukan pendaftaran hari itu.

ü  Setiap petugas yang menggunakan sistem harus diidentifikasi secara unik dengan nomor karyawan delapan digit miliknya.

B.   
Kebutuhan Non-Fungsional

• Kebutuhan non-fungsional adalah kebutuhan yang tidak secara langsung terkait dengan layanan spesifik yang disampaikan oleh sistem kepada penggunanya.

                                •  Berhubungan dengan sifat sistem yang muncul seperti keandalan, waktu respon, dll.

•  Dapat berupa kendala pada implementasi sistem seperti kemampuan perangkat I/O, representasi data yang digunakan dalam antarmuka dengan sistem lain.

                                •   Kebutuhan non-fungsional muncul melalui kebutuhan pengguna, karena keterbatasan anggaran, kebijakan organisasi, kebutuhan interoperabilitas dengan software/hardware, atau faktor eksternal seperti peraturan keselamatan atau undang-undang privasi.

Implementasi kebutuhan ini dapat disebarluaskan di

seluruh sistem, dengan alasan:

1.            Kebutuhan non-fungsional dapat mempengaruhi keseluruhan arsitektur sistem daripada komponen individu. Misalnya, untuk memastikan bahwa terpenuhinya kebutuhan kinerja harus mengatur sistem untuk meminimalkan komunikasi antar komponen.

2.            Kebutuhan non-fungsional tunggal, seperti kebutuhan keamanan, dapat menghasilkan sejumlah kebutuhan fungsional terkait yang menentukan layanan sistem baru yang diperlukan.

Karakteristik kebutuhan non-fungsional

1.      Kebutuhan produk

Kebutuhan ini menentukan atau membatasi perilaku perangkat lunak.

•         Kebutuhan kinerja tentang seberapa cepat sistem harus dijalankan dan berapa banyak memori yang dibutuhkan

•         Kebutuhan keandalan yang menetapkan tingkat

kegagalan yang dapat diterima

•         Kebutuhan keamanan

•         Kebutuhan kegunaan

2.      Kebutuhan Organisasi

Adalah kebutuhan sistem yang luas yang berasal dari kebijakan dan prosedur di organisasi pelanggan dan pengembang.

•         Kebutuhan operasional yang menentukan bagaimana sistem akan digunakan

•         Kebutuhan proses pengembangan yang menentukan bahasa pemrograman, lingkungan pengembangan atau proses standar yang akan digunakan

•         Kebutuhan lingkungan yang menentukan lingkungan

operasi sistem.

3.      Kebutuhan Eksternal

Mencakup semua kebutuhan yang berasal dari faktor eksternal ke sistem dan proses pengembangannya.

•         Kebutuhan peraturan yang mengatur apa yang harus dilakukan untuk sistem yang akan disetujui untuk digunakan oleh regulator, seperti bank sentral

•         Kebutuhan legislatif yang memastikan bahwa sistem beroperasi sesuai peraturan

•         Kebutuhan etis yang memastikan bahwa sistem akan diterima oleh pengguna dan masyarakat umum