Kebutuhan Non-Fungsional

[TM-02] Rekayasa Kebutuhan

Kebutuhan Fungsional
Mendeskripsikan layanan, fitur, atau fungsi
yang disediakan atau diberikan oleh sistem
bagi penggunanya.
Representasi goal dari pengguna ketika
hendak menggunakan sistem.

2
3
Kebutuhan Non-Fungsional (IEEE
definition)

kebutuhan non-fungsional di dalam rekayasa sistem,

sebuah kebutuhan PL yang menjelaskan bukan tentang apa yang
akan dilakukan PL, tetapi bagaimana PL akan mengerjakannya,
sebagai contoh:
- Kebutuhan performa PL
- Kebutuhan interface external PL
- Batasan rancangan
- Atribut kualitas PL.
Kebutuhan non-fungsional sulit untuk diujikan; sehingga
evaluasinya biasanya dilakukan secara sujektif.
kebutuhan non-fungsional umumnya dinyatakan secara
informal, sulit untuk diimplementasikan ketika proses
pembangunan PL dan perlu untuk dievaluasi sebelum diberikan ke
konsumer.

4
Kebutuhan Non-Fungsional
Mendeskripsikan sekumpulan batasan,
karakteristik, dan properti pada sistem, baik
dalam lingkungan pengembangan maupun
operasional.
Atribut kualitas yang harus dipenuhi oleh
sistem.
Beberapa fungsi/layanan yang muncul
kemudian seringkali merupakan aktualisasi
dari kebutuhan non-fungsional pada tahapan
implementasi.

5
Pendekatan product-oriented

6
Pendekatan product-oriented

7
Tipe Kebutuhan Non-fungsional
Faktor kualitas eksternal (ketertarikan
pelanggan)
Ketepatan (correctness).
Robustness.
Unjuk kerja (performance).
Ketersediaan dan kualitas antar muka (interface).
Keandalan (reliability).
Ketersediaan (availability ).

8
Tipe Kebutuhan Non-fungsional (2)
Faktor kualitas internal (ketertarikan
pengembang)
Kemudahan membaca/memahami struktur
perangkat lunak (readability).
Kemampuan untuk dilakukan pengujian
(testability).
Ketersediaan dan kualitas dokumentasi
(documentation).
Kemudahan pemeliharaan (maintainability).
Adaptasi terhadap lingkungan berbeda
(portability).

9
--- Portability ---
Derajat kemudahan dimana sebuah PL yang berjalan di
sebuah platform dapat dengan mudah diubah untuk
dijalankan di platform yang lain

Misal: dari Unix ke Windows

Sulit untuk diukur, dikarenakan sulitnya memprediksi

apa/bagaimanakan generasi platform yang akan datang

Dapat ditingkatkan dengan menggunakan bahasa, OS,

dan tool yang secara umum tersedia dan sudah
terstandardisasi
Misal: C/C++/C#/Java/J2EE/J2ME/.NET

10
 Studi Kasus: Automatic Teller
Machine (ATM)

11
Studi Kasus: ATM
Kebutuhan Fungsional Kebutuhan Non-Fungsional
Mengecek saldo Pengguna baru membutuhkan
waktu belajar maksimal 10 menit
untuk dapat menggunakan
fungsi-fungsi utama sistem,
Menarik uang Sistem harus tetap berfungsi
minimal 10 jam setelah pasokan
listrik dari PLN terhenti.
Mentransfer uang Waktu yang dibutuhkan untuk
kembali beroperasi setelah sistem
mati minimal 2 menit.
Melakukan pembayaran

12
ATM: Faktor Kualitas Eksternal
Kategori Kebutuhan
Correctnes Setiap jenis transaksi yang melibatkan operasi aritmatika
s harus diuji kebenarannya.
Robustnes Sistem harus dapat bertahan dalam kondisi getaran
s minimal 5 skala Richter.
Performan Sistem harus dapat melayani minimal 1.000.000
ce transaksi per hari.
Interface Menu tersedia dalam bahasa Indonesia dan Inggris.
Reliability Sistem harus tetap tersedia walaupun pasokan listrik
PLN terputus selama minimal 60 menit.
Availability Tingkat ketersediaan sistem minimal 98%.
Safety Rumah sistem haruslah dari bahan yang tidak
menghantarkan aliran listrik.
Security Sistem hanya bisa diakses menggunakan kartu yang
terautorisasi oleh pengguna yang terautentifikasi.

13
ATM: Faktor Kualitas Internal
Kategori Kebutuhan
Maintaina Sistem dapat dipantau dari titik jauh.
bility
Portability Sistem dibangun sebagai aplikasi web.

14
Pertanyaan?
Sebutkanlah beberapa hal yang mungkin
menjadi tujuan bisnis dari proyek pembuatan
ATM yang menjadi abstraksi solusinya.

15
Jawaban
1. Peningkatan kepuasan pelanggan dalam hal
melakukan transaksi perbankan selama 24
jam.
2. Pengurangan kasir.
3. Perluasan jaringan perbankan dengan cara
yang ekonomis.

16