LECTURE NOTES

Information Systems Analysis and Design

Week ke - 2

Investigating System Requirements

 LEARNING OUTCOMES

LO 2: Menerapkan teknik dan metode untuk mengumpulkan user requirement

Setelah membaca bab ini, mahasiswa diharapkan mampu:

1. Mengumpulkan informasi seputar kebutuhan pengguna

2. Menerapkan teknik-teknik yang dapat digunakan untuk mengetahui kebutuhan pengguna

OUTLINE MATERI :

1. Systems Analysis Activities

2. What Are the Requirements?

3. Stakeholders

4. Information-Gathering Techniques

5. Models and Modeling

6. Documenting Workflows with Activity Diagrams

Information Systems Analysis and Design

 ISI MATERI

Topik kali ini akan membahas perihal teknik-teknik yang bisa digunakan untuk menggali
atau memperoleh kebutuhan dari para calon pengguna sistem informasi yang akan dibangun.
Sebelum masuk ke dalam pembahasan perihal teknik-teknik di dalam penggalian kebutuhan, ada
baiknya memahami terlebih dahulu perihal apa yang dimaksud dengan requirement.
Requirement (atau kebutuhan) mengacu pada sebuah pernyataan yang menginformasikan perihal
apa yang harus bisa dilakukan oleh sistem atau perihal karakteristik apa yang harus dimiliki
olehnya. Selama kegiatan analisa, requirements ditulis dengan mengacu kepada sudut pandang
dari pebisnis. Mereka akan fokus pada kebutuhan dari bisnis yang harus diakomodir oleh sistem.
Oleh karena itu, kebutuhan ini juga disebut sebagai business requirements atau user
requirements. Lain halnya pada saat kegiatan design, business requirements akan berevolusi
menjadi kebutuhan yang lebih teknikal, perihal bagaimana nanti sistem akan diimplementasikan.

1. Systems Analysis Activities

Kegiatannya adalah sebagai berikut:
✓ Gather detailed information.
✓ Define requirements.
✓ Prioritize requirements.
✓ Develop user-interface dialogs.
✓ Evaluate requirements with users.

2. What Are the Requirements?

Requirement dapat diartikan sebagai berikut:
a. Sebuah pernyataan tentang apa yang harus dilakukan sistem atau karakteristik apa yang
harus dimilikinya.
b. Selama proses analisis, requirement ditulis dari perspektif pebisnis, dan mereka berfokus
pada "apa" yang dibutuhkan dari sistem. Karena mereka fokus pada kebutuhan pengguna
bisnis, mereka biasanya disebut requirement bisnis (dan terkadang requirement
pengguna).

Information Systems Analysis and Design

 c. Kemudian dalam desain, requirement bisnis berkembang menjadi lebih teknis, dan
menjelaskan bagaimana sistem akan diimplementasikan. Requirement dalam desain
ditulis dari perspektif pengembang, dan biasanya disebut requirement sistem.
d. Hal penting untuk diingat adalah bahwa requirement adalah pernyataan dari sistem yang
harus dilakukan, dan requirement akan berubah seiring waktu saat proyek bergerak dari
awal ke elaborasi ke konstruksi.

Requirement terbagi menjadi dua (2) jenis, yaitu functional dan nonfunctional requirements
(Gambar 1).

Gambar 1. Functional dan Non-Functional Requirement

Functional requirement mengacu kepada proses yang harus mampu diakomodir oleh
sistem, atau informasi apa saja yang harus dikelola oleh sistem. Sementara itu,
nonfunctional requirements mengacu kepada karakteristik yang melekat atau harus dimiliki
oleh sistem, seperti karakteristik terkait dengan performance dan usability.
nonfunctional requirements adalah karakteristik sistem selain aktivitas-aktivitas yang harus
dilakukan atau didukungnya. Tidak selalu mudah untuk membedakan fungsional dari
kebutuhan nonfungsional. Salah satu cara untuk melakukannya adalah dengan
menggunakan kerangka kerja untuk mengidentifikasi dan mengklasifikasikan requirement.
Berbagai kerangka kerja atau framework dikembangkan dari waktu ke waktu; yang paling
banyak digunakan saat ini disebut sebagai FURPS (lihat Gambar 2-3). FURPS adalah

Information Systems Analysis and Design

 akronim yang berarti fungsional, kegunaan, keandalan, kinerja, dan keamanan. F dalam
FURPS setara dengan fungsional requirement yang ditentukan sebelumnya. Kategori
URPS menggambarkan kebutuhan nonfungsional sebagai berikut:
▪ Usability requirements menggambarkan karakteristik operasional yang terkait
dengan pengguna, seperti antarmuka pengguna, prosedur kerja terkait, bantuan online,
dan dokumentasi. Misalnya, antarmuka pengguna untuk aplikasi smartphone harus
berperilaku serupa dengan aplikasi lain saat menanggapi gerakan seperti slide dua jari,
mencubit, dan memperluas. Requirement tambahan mungkin termasuk format menu,
skema warna, penggunaan logo organisasi, dan dukungan multibahasa.
▪ Usability requirements menggambarkan ketergantungan suatu sistem—bagaimana
sistem menunjukkan perilaku seperti terputusnya layanan dan pemrosesan yang salah
dan bagaimana sistem mendeteksi dan memulihkan diri dari masalah tersebut.
Usability requirements menggambarkan karakteristik operasional terkait untuk
mengukur beban kerja, seperti throughput dan waktu respons. Misalnya, klien dari
suatu sistem mungkin diminta untuk memiliki waktu 5 detik waktu respons untuk
semua penekanan tombol, dan server mungkin perlu mendukung 100 sesi klien secara
simultan (dengan waktu respons yang sama).
▪ Performance requirements menjelaskan bagaimana akses ke aplikasi dikendalikan
dan bagaimana data akan dilindungi selama penyimpanan dan transmisi. Misalnya,
aplikasi mungkin dilindungi dengan kata sandi, dienkripsi secara local, menyimpan
data dengan kunci 1024-bit, dan menggunakan HTTP aman untuk komunikasi antara
node klien dan server.

3. Stakeholders
Stakeholder adalah sumber informasi utama untuk requirement sistem. Stakeholder adalah
semua orang yang berkepentingan dengan keberhasilan implementasi sistem. Bergantung
pada sifat dan ruang lingkup sistem, dapat berupa kelompok kecil, atau kelompok besar
yang beragam. Misalnya, ketika menerapkan sistem akuntansi yang komprehensif untuk
perusahaan publik di Amerika Serikat, stakeholder adalah termasuk pemegang buku,
akuntan, manajer dan eksekutif, pelanggan, pemasok, auditor, investor, SEC, dan Internal
Layanan Pendapatan (IRS). Setiap kelompok stakeholder berinteraksi dengan sistem dengan

Information Systems Analysis and Design

cara yang berbeda, dan masing-masing memiliki perspektif unik tentang requirement sistem.
Sebelum mengumpulkan informasi rinci, analis mengidentifikasi setiap jenis stakeholder
yang memiliki kepentingan dalam sistem baru dan memastikan bahwa orang-orang kritis
dari masing-masing kategori stakeholder tersedia untuk melayani sebagai pakar bisnis.

Salah satu cara yang berguna untuk membantu mengidentifikasi semua stakeholder yang
berkepentingan adalah dengan mempertimbangkan dua dimensi yang membedakan mereka:
stakeholder internal versus stakeholder eksternal dan stakeholder operasional versus
stakeholder eksekutif (lihat Gambar 2). Stakeholder internal adalah mereka yang ada di
dalam organisasi yang berinteraksi dengan sistem atau memiliki kepentingan yang signifikan
dalam operasinya atau kesuksesan. Stakeholder eksternal adalah mereka yang berada di
luar pengaruh dan kendali organisasi—walaupun perbedaan ini juga bisa kabur, seperti
ketika mitra strategis organisasi (misalnya, pemasok dan perusahaan pelayaran) berinteraksi
langsung dengan sistem internal.

Gambar 2. Stakeholder sistem akuntansi yang komprehensif untuk perusahaan publik

Stakeholder operasional adalah mereka yang secara teratur berinteraksi dengan sistem
selama proses pekerjaan. Contohnya termasuk akuntan yang berinteraksi dengan sistem

Information Systems Analysis and Design

 akuntansi atau penagihan, pengawas pabrik berinteraksi dengan sistem penjadwalan
produksi, pelanggan yang berinteraksi dengan etalase Internet, dan pasien yang berinteraksi
dengan situs web layanan kesehatan, halaman Facebook, atau umpan berita Twitter.

Stakeholder operasional adalah sumber utama informasi requirement, terutama karena

berkaitan dengan antarmuka pengguna dan fungsionalitas terkait. Stakeholder eksekutif
adalah mereka yang tidak berinteraksi langsung dengan sistem, tetapi menggunakan
informasi yang dihasilkan oleh sistem atau memiliki kepentingan finansial atau kepentingan
lain yang signifikan dalam sistem tersebut. Contohnya manajer senior organisasi dan dewan
direksi, badan pengatur, dan otoritas perpajakan.

4. Information-Gathering Techniques
Ada banyak cara agar informasi tentang requirement sistem didapatkan dan dikumpulkan
dengan baik. RMO sering menggunakan teknik pengumpulan informasi standar seperti
berikut ini:
a) Mewawancarai pengguna dan stakeholder
b) Mendistribusikan dan mengumpulkan kuesioner
c) Meninjau input, output, dan dokumentasi
d) Mengamati dan mendokumentasikan prosedur bisnis
e) Meneliti solusi vendor
f) Mengumpulkan komentar dan saran pengguna aktif

Semua metode tersebut terbukti efektif, meskipun beberapa diantaranya lebih efisien
daripada yang lain. Dalam kebanyakan kasus, analis menggabungkan metode untuk
meningkatkan efektivitas dan efisiensi mereka dan untuk memberikan pendekatan
pencarian fakta yang komprehensif.

a. Interview Users and Other Stakeholders

Mewawancarai pengguna dan stakeholder adalah cara yang efektif untuk memahami
fungsi bisnis dan aturan bisnis. Sayangnya, ini juga merupakan pilihan yang paling

Information Systems Analysis and Design

 memakan waktu dan sumber daya. Dalam metode ini, analis sistem melakukan
beberapa hal diantaranya adalah:
✓ Menyiapkan pertanyaan terperinci
✓ Bertemu dengan individu atau kelompok pengguna
✓ Mendiskusikan jawaban pertanyaan
✓ Mendokumentasikan jawaban
✓ Menindaklanjuti masing-masing prosesnya sesuai kebutuhan dalam pertemuan
atau wawancara mendatang

b. Mendistribusikan dan mengumpulkan kuesioner

Kuesioner memungkinkan analis untuk mengumpulkan informasi dari sejumlah besar
stakeholder. Bahkan jika para stakeholder tersebar luas secara geografis, mereka
masih dapat membantu menentukan requirement melalui kuesioner.

Kuesioner sering digunakan untuk memperoleh wawasan awal tentang kebutuhan

informasi stakeholder yang membantu untuk menentukan area mana yang
membutuhkan penelitian lebih lanjut dengan menggunakan metode lain.

Gambar 1 adalah contoh kuesioner yang menunjukkan tiga jenis pertanyaan. Bagian
pertama memiliki pertanyaan tertutup untuk menentukan informasi kuantitatif.
Bagian kedua terdiri dari pertanyaan opini di mana responden ditanyakan apakah
mereka setuju atau tidak setuju dengan pernyataan tersebut. Kedua jenis pertanyaan
tersebut berguna untuk tabulasi dan menentukan rata-rata kuantitatif. Bagian ketiga
meminta penjelasan tentang prosedur atau masalah. Pertanyaan seperti ini baik
sebagai penyelidikan awal untuk membantu mengarahkan kegiatan pencarian fakta
lebih lanjut.

Kuesioner tidak cocok untuk membantu mempelajari proses, alur kerja, atau teknik.
Pertanyaan terbuka seperti “Bagaimana kabarmu? Bagaimana proses ini?" paling baik
dijawab dengan menggunakan wawancara atau observasi. Meskipun kuesioner dapat
berisi sejumlah pertanyaan terbuka yang sangat terbatas, namun beberapa stakeholder
sering tidak mengembalikan kuesioner yang berisi banyak pertanyaan terbuka.

Information Systems Analysis and Design

c. Meninjau input, output, dan dokumentasi
Ada dua sumber informasi tentang input, output, dan prosedur. Satu sumber berasal
dari luar organisasi—organisasi profesional di seluruh industri dan perusahaan lain.
Mungkin tidak mudah untuk mendapatkan informasi dari perusahaan lain, tetapi
mereka merupakan sumber informasi penting yang potensial. Terkadang, jurnal dan
majalah industri melaporkan temuan studi "praktik terbaik". Tim proyek akan lalai
dalam tugasnya jika anggotanya tidak terbiasa dengan informasi praktik terbaik.

Sumber input, output, dan prosedur kedua mencakup dokumen bisnis yang ada dan
deskripsi prosedur dalam organisasi. Tinjauan dokumen dan prosedur internal
memiliki dua tujuan. Pertama, ini adalah cara yang baik untuk mendapatkan
pemahaman awal tentang proses. Kedua, masukan yang ada, output, dan dokumen
dapat berfungsi sebagai alat bantu visual untuk wawancara dan sebagai dokumen
kerja untuk diskusi. Diskusi dapat fokus pada input atau output tertentu, tujuannya,
distribusinya, dan konten informasinya. Diskusi juga harus mencakup even bisnis
khusus penggunaan input atau output. Beberapa even bisnis yang berbeda mungkin
memerlukan formulir yang sama, dan informasi spesifik tentang acara dan bagaimana
proses bisnis sangat penting.

Meninjau dokumentasi prosedur yang ada membantu mengidentifikasi aturan bisnis

yang mungkin tidak muncul dalam wawancara. Menganalisis prosedur formal dalam
dokumentasi juga membantu mengungkapkan perbedaan dan redundansi dalam bisnis
proses. Namun, dokumen prosedur sering tidak diperbarui. Untuk memastikan bahwa
aturan asumsi dan bisnis yang berasal dari dokumentasi yang ada sudah benar.

d. Mengamati dan mendokumentasikan prosedur bisnis

Pengalaman langsung sangat berharga untuk memahami dengan tepat apa yang terjadi
di dalam proses bisnis. Lebih dari aktivitas lainnya, tindakan mengamati proses bisnis
akan membantu kita memahami fungsi bisnis. Namun, saat mengamati proses yang
ada, kita juga harus mampu memvisualisasikan proses bisnis terkait sistem baru.
Artinya, saat kita mengamati proses bisnis saat ini untuk memahami kebutuhan bisnis

Information Systems Analysis and Design

 yang mendasar, kita tidak boleh lupa bahwa proses bisa dan sering harus berubah
menjadi lebih efisien

5. Models and Modeling

Pemodelan adalah bagian penting dari analisis dan desain sistem. Analis membangun model
untuk menggambarkan requirement sistem dan menggunakan model tersebut untuk
berkomunikasi dengan pengguna dan desainer. Dengan mengembangkan model dan
meninjaunya dengan pengguna, analis menunjukkan pemahaman tentang kebutuhan
pengguna.

Jika pengguna melihat adanya sebuah kesalahan atau kelalaian, maka hal tersebut akan
dimasukkan ke dalam model dan kemudian akan menjadi dasar untuk kegiatan desain dan
implementasi selanjutnya. Gambar 3 merangkum alasan utama untuk membangun dan
menggunakan model.

Gambar 3. Alasan utama untuk membangun dan menggunakan model

Desainer membangun model tingkat tinggi dan terperinci untuk menggambarkan komponen
sistem dan interaksinya. Desain model berfungsi sebagai dasar untuk mengevaluasi alternatif
desain dan sebagai cara untuk mengkomunikasikan desain akhir kepada programmer,
vendor, dan lain-lain yang akan membangun dan merakit komponen-komponen untuk
membuat sistem akhir. Secara umum, model yang dibangun selama satu aktivitas SDLC
"dikonsumsi" selama aktivitas lain dilakukan.

Information Systems Analysis and Design

Model adalah representasi atau abstraksi dari beberapa aspek sistem sedang dibangun. Ada
lusinan model berbeda yang dibuat oleh seorang analis atau desainer yang mungkin
dikembangkan dan digunakan (lihat Gambar 4).

Gambar 4. Beberapa analisis dan disain model

Analisis dan desain Model dapat dikelompokkan menjadi tiga jenis umum:
i. Model tekstual.
Analis menggunakan model tekstual seperti memo, laporan, narasi, dan daftar
untuk menggambarkan requirement yang rinci dan sulit untuk diwakili dengan cara
lain. Daftar acara dan deskripsi usecase adalah dua contoh model tekstual.
Deskripsi sering kali merupakan cara terbaik untuk merekam informasi yang
dikumpulkan pada awalnya didapatkan secara lisan dari stakeholder, seperti saat
wawancara.

Information Systems Analysis and Design

 ii. Model grafis.
Model grafis memudahkan untuk memahami hubungan kompleks yang sulit diikuti
ketika digambarkan sebagai daftar atau cerita. Ingat pepatah lama bahwa sebuah
gambar bernilai seribu kata. Dalam pengembangan sistem, model grafis yang
dibangun dengan hati-hati mungkin bernilai sejuta kata! Beberapa model grafis
sebenarnya terlihat mirip dengan bagian dunia nyata dari sistem, seperti desain
layar atau tata letak disain laporan. Namun, model grafis yang dikembangkan
selama kegiatan analisis biasanya mewakili hal-hal yang lebih abstrak, seperti agen
eksternal, proses, data, objek, pesan, dan koneksi.

iii. Model matematika.

Model matematika adalah satu atau lebih rumus yang menggambarkan aspek teknis
dari suatu sistem. Analis sering menggunakan model matematis untuk mewakili
requiremen fungsional untuk aplikasi ilmiah dan rekayasa dan kadang-kadang
menggunakannya untuk menggambarkan requirement sistem bisnis di bidang-
bidang seperti akuntansi dan pengendalian persediaan. Analis dan desainer
menggunakan model matematika untuk menggambarkan kebutuhan nonfungsional
dan parameter operasional seperti throughput jaringan atau database seperti waktu
respons permintaan.

6. Documenting Workflows with Activity Diagrams

Saat kita mengumpulkan informasi tentang proses bisnis, perlu didokumentasikan
hasil nya sebagai alur kerja. Alur kerja adalah urutan langkah kerja yang menyelesaikan
satu transaksi bisnis atau permintaan pelanggan. Alur kerja mungkin sederhana atau
kompleks. Alur kerja yang kompleks dapat terdiri dari lusinan atau ratusan langkah-langkah
pekerjaan dan mungkin termasuk bagian organisasi.
Salah satu cara efektif untuk menangkap informasi adalah dengan activity diagram
UML. Activity diagram menggambarkan berbagai aktivitas pengguna (atau sistem), orang
atau komponen yang menyelesaikan setiap aktivitas, dan aliran berurutan dari Aktivitas.
Gambar 5 menunjukkan simbol dasar yang digunakan dalam activity diagram.

Information Systems Analysis and Design

Gambar 5. Simbol activity diagram

Information Systems Analysis and Design

 KESIMPULAN

1. Requirement fungsional adalah Requirement yang menjelaskan fungsi bisnis dasar yang
harus didukung oleh sistem baru. Tujuan Requirement erkaitan dengan kegunaan,
keandalan, kinerja, dan keamanan sistem
2. Requirement terdiri dari functional requirement dan non-functional requirement
3. Stakeholder terdiri dari: (1) stakeholder internal, (2) stakeholder eksternal, (3)
stakeholderoperasional dan (4) stakeholder eksekutif.
4. Stakeholder termasuk pengguna internal dan eksternal dari sistem dan orang atau
organisasi lain yang memiliki kepentingan dalam sistem..

Information Systems Analysis and Design

 DAFTAR PUSTAKA

Satzinger, John W., Jackson, Robert B., Burd, Stephen D. (2016). System Analysis and Design
in a Changing World. 7th Edition. Cengage Learning, Boston USA. ISBN: 978-1-305-11720-4.
Part 1, Chapter 2-3

Information Systems Analysis and Design