MODUL AJAR MATAKULIAH

INS 2006 ANALISIS SISTEM

PERTEMUAN 4-5 PENDEKATAN ANALISIS SISTEM DAN SYSTEM
REQUIREMENT SPESIFICATION

Abstract Sub-CPMK
Dalam pertemuan ini, akan dipelajari • Mahasiswa mengetahui apa itu System
metode-metode tradisional yang dapat Requirement Spesification
digunakan untuk melakukan penggalian • Mahasiswa mengetahui analisa
kebutuhan sistem, yang nantinya akan feasibilitas
dianalisis menjadi kebutuhan • Mahasiswa mengetahui metode
sistem/fungsionalitas dan non fungsionalitas penggalian informasi secara tradisional
sistem yang akan dikembangkan. • Mahasiswa memahami bagaimana
menggunakan SRS, mampu
menggunakan dan membuat dokumen
SRS
 Pendahuluan

Pada pertemuan ini, anda akan mempelajari tentang:

1. Pertemuan 4
1. Metode Tradisional dalam pengumpulan kebutuhan sistem
a. Wawancara
b. Observasi
c. Questioner
2. Analisis Feasibilitas Sistem
3. System Requirement Spesification

Tujuan Instruksi Umum

Memahami Pendekatan Tradisional, Memahami apa itu analisis feasibilitas dan

memahami dokumen SRS.

Tujuan Instruksi Khusus

1. Mahasiswa memahami dan mampu mengimplementasikan metode tradsional

dalam pengumpulan kebutuhan sistem.
2. Mahasiswa memahami bagaimana melakukan analisis feasibilitas sistem
3. Mahasiswa mengetahui bagaimana menggunakan dokumen SRS.
2. Pertemuan 5
a. Tugas 1
Tujuan Instruksi Umum
Mahasiswa mampu mengimplementasikan materi pada pertemuan sebelumnya dan
membangun dokumen kebutuhan sistem
Tujuan Instruksi Khusus
1. Mahasiswa mampu mengidentifikasi kebutuhan sistem baik itu fungsional
maupun fungsional berdasarkan tujuan sistem yang akan dibangun.
 2. Mahasiswa mampu mengidentifikasi fungsi-fungsi sistem yang akan membantu
pengguna mengatasi tujuan sistem yang dibangun.
3. Mahasiswa mampu menganalisa feasibilitas sistem yang dibangun

A. Pendekatan Tradisional

1) Wawancara

Wawancara adalah metode yang paling sering digunakan oleh analis sistem untuk
menemukan kebutuhan sistem. Dalam melakukan wawancara, seorang pewawancara harus
mengenali diri sendiri terlebih dahulu. Termasuk mengetahui kemungkinan bias, kemampuan,
pendidikan, emosi dan nilai etis yang dimiliki oleh si pewawancara (Kendall & Kendall, 2014).

Lima langkah dalam menyiapkan interview menurut kendall adalah :

1. Mengetahui latar belakang yang diwawancara: seorang pewawancara harus

mengetahui latar belakang dari yang akan diwawancara. Informasi ini bisa
didapatkan dari dokumen-dokumen yang diberikan oleh organisasi.
2. Menentukan tujuan wawancara: tentukan hal apa yang ingin didapatkan dari
wawancara yang dilakukan.
3. Menentukan siapa yang akan diwawancara: libatkan semua pihak yang
dipengaruhi oleh sistem yang akan dibangun.
4. Mempersiapkan orang yang akan diwawancara: Pastikan pihak yang diwawancarai
memiliki waktu untuk diwawancarai dan bersedia untuk diwawancarai.
Wawancara yang efektif berlangsung 45-satu jam, jika lebih dari satu jam, maka
akan mengganggu aktifitas dari yang diwawancara.
5. Memilih jenis pertanyaan dan struktur wawancara.

Ada dua jenis pertanyaan dalam melakukan wawancara yaitu pertanyaan terbuka dan
pertanyaan tertutup (Kendall & Kendall, 2014; Valacich & George, 2017).

1. Pertanyaan Terbuka
 Pertanyaan terbuka digunakan ketika pewawancara tidak mengetahui secara pasti apa
yang harus ditanyakan. Pertanyaan ini juga digunakan untuk menggali opini dari pihak yang
diwawancarai. Pada penggunaannya, seorang pewawancara harus memiliki kemampuan yang
baik dalam membuat sebuah pertanyaan lanjutan untuk mengkonfirmasi jawaban yang diberikan
oleh pihak yang diwawancarai. Selain itu, kemampuan untuk membaca gerak tubuh juga sangat
dibutuhkan karena ada informasi yang bisa didapatkan dari hal ini.

Pertanyaan terbuka memiliki beberapa kelebihan yaitu:

a. Pihak yang diwawancara akan merasa lebih rileks

b. Pewawancara jadi lebih mengenal pihak yang diwawancarai
c. Lebih mendetail
d. Bisa menemukan hal-hal baru yang mungkin tidak ditemukan pada saat
perencanaan
e. Wawancara menjadi lebih menarik
f. Lebih spontan
g. Memudahkan Pewawancara

Kekurangan pertanyaan Terbuka

a. Hasil wawancara akan sulit untuk disarikan, karena terlalu banyak detail yang tidak
perlu
b. Kemungkinan kehilangan kontrol dari sesi wawancara
c. Cerita menjadi terlalu panjang lebar
d. Pihak yang diwawancara akan mendapatkan impresi bahwa pewawancara tidak
tahu apa yang ingin ditanyakan.
2. Pertanyaan Tertutup

Pertanyaan tertutup digunakan jika pewawancara telah mengetahui pasti permasalahan

apa yang akan ditanayakan kepada pihak yang akan diwawancarai. Kelebihan utama dari jenis
pertanyaan ini adalah waktu yang diperlukan relatif singkat dibandingkan dengan wawancara
menggunakan pertanyaan terbuka. Jenis pertanyaan tertutup adalah: jawaban benar salah;
pilihan berganda; rating; dan perangkingan.

2) Observasi

Seringkali, pihak yang diwawancarai tidak mengetahui secara pasti mengenai sebuah
kegiatan tertentu bisa karena lupa atau memang tidak mampu menyampaikan dengan baik. Pada
saat permasalahan seperti ini muncul, maka metode observasi dapat digunakan untuk
melengkapi data yang diberikan pada saat wawancara atau sebelum wawancara dilakukan.
Observasi juga sangat baik ketika kebutuhan sistem berhubungan erat dengan perilaku pengguna
di kehidupan nyata. Sebagai contoh, ketika sebuah sistem lalu lintas dikembangkan, maka
seorang analis perlu terjun kelapangan untuk melakukan observasi pengguna jalan di titik
tertentu untuk mengetahui permasalahan dan alternative penyelesaian apa yang dibutuhkan.

3) Kuesioner

Kuesioner, merupakan salah satu cara yang dapat dilakukan ketika narasumber yang akan
diwawancara sulit ditemui atau sulit untuk mendapatkan waktu yang sesuai untuk dilakukan
wawancara. Kuesioner memiliki jenis pertanyaan yang sama dengan wawancara, yaitu terbuka
dan tertutup namun berbentuk teks dokumen. Kelebihan utama dari penggunaan kuesioner
adalah, data yang didapatkan bisa dikuantifikasikan untuk dianalisis menggunakan statistik.

Hal-hal yang harus dipertimbangkan ketika akan menggunakan kuesioner sebagai metode
pengumpulan data adalah (Kendall & Kendall, 2014):

a. Narasumber berada diberbagai tempat.

b. Banyak pihak yang terlibat
c. Studi yang dilakukan dalam bentuk eksploratori, dimana data hasil ini akan
digunakan dalam tahapan interview yang akan dilakukan.
 B. Analisis Feasibilitas

Analisis feasibilitas adalah hal pertama yang dilakukan ketika sebuah proyek berjalan.
Dalam Analisis Feasibilitas hal-hal yang menjadi pertimbangan adalah segi teknis, ekonomi,
hokum, operasional dan jadwal dari sebuah proyek (Stair & Reynolds, 2018).

1) Technical Feasibility (Feasibilitas Teknis)

Feasibilitas teknis terkait dengan kemampuan teknologi yang dimiliki pada saat ini.
Feasibilitas ini penting ketika sebuah organisasi ingin menggunakan sebuah teknologi tertentu
dalam organisasinya. Dari segi pengembang, feasibilitas teknis diperlukan untuk menjamin
bahwa proses pengembangan tidak terganggu atau bergantung pada teknologi tertentu.

2) Economic Feasibility (Feasibilitas Ekonomis)

Pada analisis ini, seorang pimpinan proyek dan analis sistem harus mempertimbangkan
apakah biaya pengembangan dan keuntungan yang didapatkan berimbang. Pertimbangan ini
harus melihat efek jangka panjang dari pengembangan. Seorang analis harus bisa memberikan
bahan pertimbangan kepada manajer proyek mengenai kecukupan dana yang dimiliki dan
fungsionalitas yang akan dikembangkan.

3) Legal Feasibility

Sistem yang dikembangkan harus disesuaikan dengan kebijakan yang berlaku di daerah
tertentu. Kebijakan ini bisa berbentuk undang-undang atau kebijakan lainnya dalam organisasi.

4) Operational Feasibility

Proses analisis untuk mengetahui apakah proses yang dilakukan sistem diterima atau
tidak oleh pengguna, dan seberapa besar fungsionalitas menjawab ekspektasi penggguna.
Analisis ini terkait juga dengan prilaku pengguna dalam organisasi. Ketika implemntasi apakah
akan terjadi resistansi atau tidak, apakah sesuai dengan nilai yang berlaku dalam organisasi,dsb.
 5) Schedule Feasibility

Sebuah proyek harus dilihat apakah bisa selesai tepat waktu dengan sumber daya yang
ada. Proses ini terkait dengan penyeimbangan antara sumber daya dan waktu yang dimiliki oleh
pengembang dalam proses pengembangan sistem.

C. System Requirement Specifications Document (SRS)

Dokumen SRS adalah dokumen yang digunakan oleh seorang analis untuk menuliskan
hasil-hasil temuan yang didapatkan pada saat proses perolehan kebutuhan sistem. Pada
dokumen ini terdapat beberapa sheet yang harus diisi. Sheet tersebut yaitu Problem Domain,
Solution Domain, Potential Domain, Requirement Revision, Need vs Feat, Priority Clasification,
Feasibility, dan Finalization. Setelah semua kebutuhan selesai, maka Langkah selanjutnya adalah
mengembangkan usecase dari fitur-fitur yang telah di finalisasi.

1) Problem Domain

Problem Domain, merupakan domain yang harus dianalisis pertama kali oleh seorang
analis. Dalam domain ini, akan diperlihatkan apa yang menjadi permasalahan yang akan
diselesaikan menggunakan sistem yang akan dikembangkan. Dalam problem domain ini,
biasanya dituliskan dengan format:

Pengguna kesulitan dalam….

Penggunaa dalam konteks ini bukan hanya pengguna dalam bentuk manusia, namun juga
bisa dalam bentuk sistem. Misalnya untuk kondisi pengembangan ulang sebuah sistem SIAKAD.
Maka problem domain dapat ditulisakan dalam bentuk seperti yang terlihat pada Tabel 1 berikut:

Setelah permasalahan yang akan diselesaikan didapatkan, maka Langkah selanjutnya

adalah Menyusun solution domain dari permasalahan yang telah berhasil dikumpulkan
 Table 1 Problem Domain

No. Req. Description

1 Sistem lain kesulitan dalam melakukan integrasi kedalam sistem SIAKAD
2 Pengguna kesulitan dalam mengolah nilai secara manual
3 Pengguna kesulitan melihat hasil pembelajaran yang dilakukan
4 Pengguna kesulitan dalam menjadwalkan perkuliahan

2) Solution Domain

Solution domain merupakan daftar dari kemungkinan yang dapat dilakukan sistem untuk
menyelesaikan problem domain yang telah ditemukan sebelumnya. Dalam solution domain,
analis harus mendapatkan daftar dari kebutuhan fungsional dan non-fungsional yang dibutuhkan
oleh sistem yang akan dikembangkan. Seperti yang telah dijelaskan sebelumnya, fungsional
domain ini akan berisi fungsionalitas dari sistem. Sebagai catatan, fungsionalitas sistem ini tidak
harus menjawab hanya satu permasalahan. Fungsionalitas dapat menjawab dua permasalahan
atau sebaliknya, satu permasalahan dijawab dengan beberapa fungsionalitas. Penulisan dari
fungsionalitas, adalah sebagai berikut:

Sistem mampu ….. atau Sistem dapat melakukan ….

Kebutuhan sistem lainnya yang harus dianalisis yaitu kebutuhan non-fungsional dari
sistem yang dikembangkan. Dalam dokumen SRS, terdapat beberapa hal yang harus di analisis
yaitu :

a. Usability

Kebutuhan terkait usability adalah kebutuhan yang terkait dengan siapa pengguna,
bagaimana pengguna akan menggunakan atau berinteraksi dengan sistem yang dikembangkan,
pengguna akan menggunakan sistem dalam lingkungan seperti apa, dan hal lainnya yang terkait
dengan pengguna dan lingkungan pengguna dalam menggunakan sistem.

b. Reliability

Kebutuhan terkait dengan reliability adalah kebutuhan sistem yang berkaitan dengan
seberapa bisa diandalkan sistem yang akan dikembangkan. Beberapa sistem harus memiliki
keandalan yang tinggi, dimana hampir tidak ada error yang dapat diterima, seperti sistem
perbankan. Kebutuhan ini nantinya akan sangat berkaitan dengan perangkat keras yang
dibutuhkan dalam implementasi sistem.

Dalam tabel yang ada dalam SRRS, anda akan melihat beberapa istilah. Availability
merupakan kebutuhan terkait dengan bagaimana ketersediaan sistem yang dikembangkan,
apakah selalu ada selama 24 jam? Atau hanya pada saat tertentu. MTBF terkait dengan error
yang terjadi, berapa lama yang dibutuhkan untuk error yang terjadi. Sebagai contoh ketika sistem
error, berapa lama sebuah sistem error lagi karena suatu hal, atau ketika jaringan tidak bisa
diakses, berapa lama jaringan Kembali tidak bisa diakses setelah diperbaiki. Untuk menilai MTBF,
analis harus memiliki data terkait dengan sistem sejenis atau perangkat sejenis. Istilah berikutnya
adalah MTTR. MTTR adalah waktu yang dibutuhkan untuk memperbaiki sebuah error atau
kerusakan. Sebagai contoh, ketika jaringan rusak, berapa lama yang dibutuhkan agar jaringan
Kembali dapat diakses. Sedangkan akurasi berkaitan dengan seberapa tempered resistance
(tahan akan perubahan) data yang tersimpan dalam sistem, ataupun hal lain yang mungkin dapat
diubah dalam sistem.

c. Performance

Kebutuhan terkait dengan performa berkaitan dengan Waktu Respon (Respond Time),
seberapa besar data yang dapat melalui sistem (Throughput), kapasitas sistem terkait
penyimpanan dan hal lainnya (Capacity), dan seberapa lama sistem tahan untuk digunakan
hingga sama sekali tidak dapat digunakan (Degradation Modes)

d. Supportability

Kebutuhan terkait dengan seberapa mudah sistem untuk diperbaiki dan dikembangkan
Kembali jika dibutuhkan.

e. Design & Implementation Constraint

 Berkaitan dengan batasan-batasan yang ada dalam sistem. Seperti batasan platform,
database yang digunakan, bandwidth yang dibutuhkan, system requirement minimal yang
dibutuhkan untuk implementasi, dan batasan-batasan lainya.

Tabel 2 memperlihatkan contoh dari solution domain untuk sistem SIAKAD yang telah
dianalisis problem domainnya sebelumny.

Table 2 Solution Domain

Functional Requirement
Req. ID Req. Description
Req 001 Sistem dapat melakukan pengolahan nilai secara otomatis
Req 002 Sistem dapat mengautomasi penginputan nilai menggunakan file
Req 003 Sistem dapat memeriksa bentrok dalam penjadwalan
Req 004 Sistem dapat mengenerate jadwal perkuliahan secara otomatis
Non functional Requirement
Req. ID Req. Description
Usability (lingkungan operasional dan tipe user)
Sistem memiliki UI yang sederhana sehingga mudah digunakan oleh pengguna yang tidak
USReq 001
terlalu paham teknologi
USReq 002 Sistem memberikan text saran (pop-up help) untuk fungsi-fungsi yang ada dalam sistem
Sistem secara otomatis mendeteksi pengguna ketika masuk menggunakan SSO dalam
USReq 003
jaringan kampus
Reliability (Availability, MTBF, MTTR, akurasi)
RELReq 001 Sistem Memiliki MTBF Minimal 24 Jam
RELReq 002 MTTR sistem maksimal 15 menit
RELReq 003 Sistem hanya dapat diakses menggunakan jaringan kampus dan VPN kampus
Performance (Response time, throughput, capacity, degradation modes)
PERFReq 001 Proses data tidak boleh lebih dari 5 detik
PERFReq 002 Data yang dikirimkan melalui system maksimal 10MB
Supportability (kemudahan dimodifikasi untuk mengakomodasi pengembangan atau perbaikan)
SUPReq 001 Sistem dikembangkan secara modular
SUPReq 002 Database yang dikembangkan harus memberikan API yang baik
Design & Implementation Constraint (Batasan/ Prasyarat pada Rancangan & Pemrograman)
DICReq 001 Hanya web Based
DICReq 002 Minimal system windows/linux/mac dengan peramban terbaru
 3) Potential Problems

Potential problem adalah hasil analisis yang dilakukan oleh analis Ketika telah
mendapatkan daftar fungsionalitas dan non-fungsionalitas system. Tabel 3 memperlihatkan table
Potential Problems.

Pada Tabel 3, tedapat tambahin kolom yaitu kolom potential problems. Terdapat tiga
variable yang harus dilihat yaitu:

1. Ambiguity (A)

Ambigu adalah sebuah permasalahan yang muncul ketika sebuah kebutuhan system tidak
diutarakan dengan baik, sehingga bisa diartikan dengan berbagai cara. Sebagai contoh, dalam
non-functional requirements, dituliskan bahwa Sistem harus mudah digunakan. Ketika berbicara
mudah digunakan, maka akan sangat bergantung pada siapa penggunanya. Jika mudah
digunakan oleh A, maka belum tentu B dapat dengan mudah menggunakan system yang sama.
Oleh karena itu, dalam penulisan harus diperbaiki Kembali.

2. In Complete (ICp)

Sebuah kebutuhan juga dapat memiliki permasalahan terkait dengan kelengkapan dari
kebutuhan system yang telah dikumpulkan. Contoh dari kebutuhan yang belum lengkap dapat
dilihat pada Tabel 3 Req 002. Pada kebutuhan tersebut, dituliskan system dapat mengautomasi
penginputan nilai menggunakan file. Kebutuhan system tersebut masih belum lengkap. Pada
table tersebut dapat dispesifikasikan Kembali tipe file seperti apa yang akan digunakan, sehingga
programmer dapat lebih mudah mentranslasikan kebutuhan yang disampaikan dalam hasil
analisis yang dihasilkan.

3. In Consistence (ICn)

Permasalahan berikutnya adalah kebutuhan Sistem yang saling bertolak belakang atau
tidak konsisten. Permasalahan ini muncul dikarenakan pada saat pencarian kebutuhan bisa ada
lebih dari stakeholder yang diwawancara. Contoh dari kebutuhan yang inconsistence adalah, Req
A: proses pengecekan harus dilakukan secara manual kemudian diupload kedalam system
sedangkan Req B: Proses pengecekan langsung dilakukan oleh system. Ketika terdapat kebutuhan
sistem yang saling bertolak belakang, maka analis harus mempertemukan semua stakeholder
untuk membahas hal tersebut, atau melihat ke dokumen lain yang mungkin dapat digunakan
sebagai dasar, misalnya dokumen kebijakan kantor.

Table 3 Potential Problems

Functional Requirement Potential Problems

Req. ID Req. Description A ICp ICn
Req 001 Sistem dapat melakukan pengolahan nilai secara otomatis
Req 002 Sistem dapat mengautomasi penginputan nilai menggunakan file V
Req 003 Sistem dapat memeriksa bentrok dalam penjadwalan
Req 004 Sistem dapat mengenerate jadwal perkuliahan secara otomatis
Non functional Requirement
Req. ID Req. Description
Usability (lingkungan operasional dan tipe user)
Sistem memiliki UI yang sederhana sehingga mudah digunakan oleh
USReq 001
pengguna yang tidak terlalu paham teknologi
Sistem memberikan text saran (pop-up help) untuk fungsi-fungsi yang V V
USReq 002
ada dalam sistem
Sistem secara otomatis mendeteksi pengguna ketika masuk
USReq 003
menggunakan SSO dalam jaringan kampus
Reliability (Availability, MTBF, MTTR, akurasi)
RELReq 001 Sistem Memiliki MTBF Minimal 24 Jam
RELReq 002 MTTR sistem maksimal 15 menit
Sistem hanya dapat diakses menggunakan jaringan kampus dan VPN
RELReq 003
kampus
Performance (Response time, throughput, capacity, degradation modes)
PERFReq 001 Proses data tidak boleh lebih dari 5 detik
PERFReq 002 Data yang dikirimkan melalui system maksimal 10MB
Supportability (kemudahan dimodifikasi untuk mengakomodasi pengembangan
atau perbaikan)
SUPReq 001 Sistem dikembangkan secara modular
SUPReq 002 Database yang dikembangkan harus memberikan API yang baik
Design & Implementation Constraint (Batasan/ Prasyarat pada Rancangan &
Pemrograman)
DICReq 001 Hanya web Based
DICReq 002 Minimal system windows/linux/mac dengan peramban terbaru
 4) Requirement Revision

Setelah permasalahan dalam requirement ditemukan, maka Langkah selanjutnya adalah

memperbaiki kebutuhan yang ada. Dari Tabel 3, dapat dilihat bahwa dari hasil analisis Req 002
masih belum lengkap, maka akan kita ubah dengan menambahkan tipe data yang dibutuhkan.
Sehingga Req 002 menjadi Sistem dapat mengautomasi penginputan nilai menggunakan file
dengan tipe CSV atau XLS.

5) Need Vs Feat

Dalam need dan feat, fungsionalitas dilihat Kembali untuk melihat, manakah kebutuhan
yang menjadi kebutuhan pengguna. Untuk melihat kesesuaian ini, analis harus membuat matriks
antara requirement/solution domain dan problem domain yang telah dikembangkan. Tabel 4
memperlihatkan matriks need vs feat. Seperti yang dapat dilihat pada table 4, tidak semua non-
funtional dapat dipetakan, hal ini diakrenakan, non-fungsional memang tidak secara langsung
berkaitan dengan kebutuhan pengguna, namun lebih ke kebutuhan proses dan sistem sendiri.

Table 4 Need VS Feat

Functional Requirement Needs

Sistem Penggun Pengguna Pengguna
lain a kesulitan kesulitan
kesulitan kesulitan melihat hasil dalam
dalam dalam pembelajara menjadwalka
Req. ID Req. Description melakuka mengola n yang n perkuliahan
n integrasi h nilai dilakukan
kedalam secara
sistem manual
SIAKAD
Sistem dapat melakukan pengolahan
Req 001
nilai secara otomatis
Sistem dapat mengautomasi V V
Req 002
penginputan nilai menggunakan file
Sistem dapat memeriksa bentrok V
Req 003
dalam penjadwalan
Sistem dapat mengenerate jadwal V
Req 004
perkuliahan secara otomatis
Non functional Requirement
Req. ID Req. Description
Usability (lingkungan operasional dan tipe user)
USReq Sistem memiliki UI yang sederhana
001 sehingga mudah digunakan oleh
 pengguna yang tidak terlalu paham
teknologi
Sistem memberikan text saran (pop-up
USReq
help) untuk fungsi-fungsi yang ada
002
dalam sistem
Sistem secara otomatis mendeteksi
USReq
pengguna ketika masuk menggunakan
003
SSO dalam jaringan kampus
Reliability (Availability, MTBF, MTTR,
akurasi)
RELReq Sistem Memiliki MTBF Minimal 24
001 Jam
RELReq
MTTR sistem maksimal 15 menit
002
Sistem hanya dapat diakses
RELReq
menggunakan jaringan kampus dan
003
VPN kampus
Performance (Response time, throughput,
capacity, degradation modes)
PERFRe Proses data tidak boleh lebih dari 5
q 001 detik
PERFRe Data yang dikirimkan melalui system
q 002 maksimal 10MB
Supportability (kemudahan dimodifikasi untuk
mengakomodasi pengembangan atau
perbaikan)
SUPReq
Sistem dikembangkan secara modular
001
SUPReq Database yang dikembangkan harus V
002 memberikan API yang baik
Design & Implementation Constraint (Batasan/
Prasyarat pada Rancangan & Pemrograman)
DICReq
Hanya web Based
001
DICReq Minimal system windows/linux/mac
002 dengan peramban terbaru

6) Priority Classification

Tidak semua fungsionalitas harus dikembangkan dalam waktu yang bersamaan, terutama
Ketika kebutuhan sistem yang ditemukan sangat banyak atau cakupan sistem sangat besar,
misalnya Ketika sebuah pengembang mengembangkan aplikasi inti sebuah perusahaan, misalnya
aplikasi SIAKAD yang kita gunakan sebagai contoh kasus dalam pembahasan ini. Tabel 5
memperlihatkan contoh dari matriks priority classification.
 Table 5 Priroty Classification

Functional Requirement Priority

Req. ID Req. Description C I U

Req 001 Sistem dapat melakukan pengolahan nilai secara otomatis V

Sistem dapat mengautomasi penginputan nilai menggunakan
Req 002 V
file
Req 003 Sistem dapat memeriksa bentrok dalam penjadwalan V
Req 004 Sistem dapat mengenerate jadwal perkuliahan secara otomatis V
Non functional Requirement
Req. ID Req. Description
Usability (lingkungan operasional dan tipe user)
USReq Sistem memiliki UI yang sederhana sehingga mudah
V
001 digunakan oleh pengguna yang tidak terlalu paham teknologi
USReq Sistem memberikan text saran (pop-up help) untuk fungsi-
V
002 fungsi yang ada dalam sistem
USReq Sistem secara otomatis mendeteksi pengguna ketika masuk
V
003 menggunakan SSO dalam jaringan kampus
Reliability (Availability, MTBF, MTTR, akurasi)
RELReq
Sistem Memiliki MTBF Minimal 24 Jam V
001
RELReq
MTTR sistem maksimal 15 menit V
002
RELReq Sistem hanya dapat diakses menggunakan jaringan kampus
V
003 dan VPN kampus
Performance (Response time, throughput, capacity, degradation modes)
PERFReq
Proses data tidak boleh lebih dari 5 detik V
001
PERFReq
Data yang dikirimkan melalui system maksimal 10MB V
002
Supportability (kemudahan dimodifikasi untuk mengakomodasi
pengembangan atau perbaikan)
SUPReq
Sistem dikembangkan secara modular V
001
SUPReq Database yang dikembangkan harus memberikan API yang
V
002 baik
Design & Implementation Constraint (Batasan/ Prasyarat pada
Rancangan & Pemrograman)
DICReq
Hanya web Based V
001
DICReq
Minimal system windows/linux/mac dengan peramban terbaru V
002

Untuk menentukan, manakah fungsionalitas yang harus dikembangkan terlebih dahulu,

diperlukan sebuah matriks. Dalam matriks priority classification, terdapat beberapa istilah yang
digunakan, yaitu;
 1. Critical

Sebuah kebutuhan sistem disebut sebagai kebutuhan yang critical, jika kebutuhan
tersebut tidak ada dalam sistem, maka sistem tersebut tidak berjalan, tidak aman, atau tidak
dapat menyelesaikan permasalahan yang dialami oleh pengguna. Sebagai contoh dari sebuah
kebutuhan critical dari Sistem siakad adalah fungsionalitas KHS dan KRS. Tanpa dua fungsionalitas
ini, maka sistem tidak bisa berjalan semestinya.

2. Important

Sebuah kebutuhan sistem yang bersifat important adalah kebutuhan sistem dimana jika
kebutuhan tersebut tidak dikembangkan, sistem masih dapat berjalan, namun tidak berjalan
seperti semestinya. Sebagai contoh dalam sistem SIAKAD, fungsionalitas terkait dengan
penginputan mata kuliah, sistem SIAKAD masih dapat berjalan meskipun fungsionalitas ini tidak
dikembangkan diawal, dikarenakan, matakuliah masih dapat diinputkan kedalam sistem secara
langsung kedalam database. Hal ini dimungkinkan karena mata kuliah tidak berubah dalam waktu
singkat.

3. Useful.

Kebutuhan yang dikatan useful, adalah kebutuhan yang jika anda kembangkan pada saat
ini, akan memberikan nilai tambah bagi sistem yang anda kembangkan, namun jika tidak
dikembangkan pada saat ini maka sistem tidak akan kekurangan apapun. Dalam contoh SIAKAD,
kebutuhan terkait dengan penjadwalan. SIAKAD tetap akan berjalan dengan baik tanpa menu ini,
dikarenakan, sistem penjadwalan sangat sulit untuk dikembangkan.

7) Feasibility

Kebutuhan sistem terkait dengan feasibility merupakan yang selanjutnya harus

diperhatikan oleh seorang analis. Kebutuhan ini adalah salah satu yang sering kali dilupakan
Ketika analisis dilakukan. Sebuah kebutuhan fungsionalitas atau non-fungsionalitas yang
dikembangkan sebagus atau secanggih apapun itu, tidak akan bisa dikembangkan jika kebutuhan
terkait feasibilitas tidak dapat dipenuhi.
 Dalam menganalisis feasibilitas, yang harus diperhatikan adalah:

1. Technical

Variabel feasibilitas pertama yang harus diperhatikan adalah technical feasibility.

Technical feasibility adalah seberapa mungkin kebutuhan yang dikembangkan dapat dikerjakan
atau dikembangkan dengan keadaan teknis yang ada. Sebagai contoh SIAKAD, dalam contoh yang
diberikan dalam table 6. Salah satu non-fungsionalitas yang didapatkan adalah PERFReq 001 :
data diolah tidak lebih dari 5 detik. Untuk mendapatkan hal ini, diperlukan proses komputasi yang
cepat dari perangkat keras yang berspesifikasi tinggi. Jika klien anda belum memiliki perangkat
keras yang sesuai, maka secara teknis kebutuhan ini akan masuk kedalam kategori tidak mampu
dikembangkan dan harus disesuaikan Kembali.

2. Operator

Dibalik sistem, akan selalu ada pengguna yang akan menggunakan sistem. Dalam
pengembangan, kita harus memastikan siapa yang akan menggunakan sistem, apakah sistem
bisa digunakan oleh pengguna atau tidak. Selain pengguna, yang harus diperhatikan adalah
pengembang tim sendiri. Apakah tim pengembang memiliki kemampuan untuk mengembangkan
fungsionalitas tesebut?.

Sebagai contoh Ketika salah satu fungsionalitas pada table 5 Req 004: sistem dapat
menggenerate jadwal secara otomatis. Untuk mengembangkan hal ini dibutuhkan kemampuan
AI yang bagus, jika dalam tim pengembangan tidak terdapat pengembang yang memiliki
kemampuan AI, maka pengembangan tidak dapat dilakukan.

3. Economic

Hal yang paling sering dilupakan Ketika melihat feasibilitas adalah masalah pendanaan.
Semakin sulit sebuah kebutuhan untuk dipenuhi, maka pendanaan akan semakin sulit. Hal ini
juga harus dipastikan kepada klien apakah ada komitmen dari klien terkait dengan pendanaan.
Sebagai pengembang, kita harus menghitung pendanaan yang dibutuhkan. Penghitungan ini
akan dipelajari dalam matakuliah manajemen proyek TI.
 Selain melihat feasibilitas ini, ada hal lain yang harus diperhatikan Ketika melakukan
pengembangan. Yaitu risiko yang ditemui dalam pengembangan. Risiko bisa beresiko rendah,
yang artinya jika terjadi kegagalan pengembangan tidak akan mempengaruhi sistem. Risiko
Medium akan memberikan dampak meskipun tidak sampai menghentikan pengembangan.
Sedangkan risiko tinggi akan menghentikan proses pengembangan jika terjadi kegagalan dalam
pengembangan kebutuhan tersebut.

Table 6 Feasibility Matriks

Functional Requirement Feasibility Risk

Req. ID Req. Description T O E L M H

Req 001 Sistem dapat melakukan pengolahan nilai secara otomatis V V V V

Sistem dapat mengautomasi penginputan nilai menggunakan file
Req 002 V V V V
dalam bentuk CSV
Req 003 Sistem dapat memeriksa bentrok dalam penjadwalan V V V
Req 004 Sistem dapat mengenerate jadwal perkuliahan secara otomatis V V V
Non functional Requirement
Req. ID Req. Description
Usability (lingkungan operasional dan tipe user)
USReq Sistem memiliki UI yang sederhana sehingga mudah digunakan
V V V V
001 oleh pengguna yang tidak terlalu paham teknologi
USReq Sistem memberikan text saran (pop-up help) untuk fungsi-fungsi
V V V V
002 yang ada dalam sistem
USReq Sistem secara otomatis mendeteksi pengguna ketika masuk
V V V V
003 menggunakan SSO dalam jaringan kampus
Reliability (Availability, MTBF, MTTR, akurasi)
RELReq
Sistem Memiliki MTBF Minimal 24 Jam V V
001
RELReq
MTTR sistem maksimal 15 menit V V V
002
RELReq Sistem hanya dapat diakses menggunakan jaringan kampus dan
V
003 VPN kampus
Performance (Response time, throughput, capacity, degradation modes)
PERFReq
Proses data tidak boleh lebih dari 5 detik V
001
PERFReq
Data yang dikirimkan melalui system maksimal 10MB V V V V
002
Supportability (kemudahan dimodifikasi untuk mengakomodasi
pengembangan atau perbaikan)
SUPReq
Sistem dikembangkan secara modular V V V V
001
SUPReq
Database yang dikembangkan harus memberikan API yang baik V V V V
002
Design & Implementation Constraint (Batasan/ Prasyarat pada
Rancangan & Pemrograman)
 DICReq
Hanya web Based V V V V
001
DICReq
Minimal system windows/linux/mac dengan peramban terbaru V V V V
002

8) Finalization

Finalisasi merupakan tahap akhir dari pengembangan ini. Semua hasil analisis akan
dirangking berdasarkan prioritas dan feasibilitas dari kebutuhan yang dianalisis. Tabel 7
memberikan indicator perangkingan yang harus diperhatikan.

Table 7 indikator perangkingan

Legenda: Sorted, based on rank

1 All Feasible, Critical, Low Risk
2 All Feasible, Critical, Medium/High Risk
3 All Feasible, Important, Low Risk
4 All Feasible, Important, Medium/High Risk
5 All Feasible, Usefull, Low Risk
6 All Feasible, Usefull, Medium/High Risk
7 Critical but there is a not feasible requirements
8 Important but there is a not feasible requirements
9 Usefull but there is a not feasible requirements

Jika melihat hasil analisis yang dikerjakan pada contoh SIAKAD, maka fungsionalitas yang
harus dikembangkan terlebih dahulu yaitu: Req 001 dan Req 002 dikarenakan memenuhi
indicator no 3. Semua feasible, important dan low risk.

D. Rangkuman

Dalam melaksanakan proses analisis system, kita dapat menggunakan berbagai

pendekatan. Baik itu pendekatan tradisional yang telah dibahas pada modul sebelumnya,
maupun pendekatan kontemporer seperti JAD, Prototyping maupun Agile.

Dalam melakukan analisis ini, nantinya akan dihasilkan daftar kebutuhan system yang
akan dikembangkan. Daftar ini dapat dimanage menggunakan file SRS. Dari file SRS ini nantinya
akan didapatkan daftar kebutuhan yang harus dikembangkan dengan melihat kebutuhan
pengguna, feasibilitas dan seberapa pentingnya kebutuhan tersebut untuk dikembangkan.
 E. Daftar Pustaka

Kendall, K. E., & Kendall, J. E. (2014). System Analysis and Design (9th ed.). Pearson.

Stair, R. M., & Reynolds, G. W. (2018). Principles of Information systems. Cengage Learning.

Valacich, J. S., & George, J. F. (2017). Modern Systems Analysis and Design.