BAB 4

INVESTIGASI KEBUTUHAN SISTEM

Oleh:
ARDHIKA PRASEDA AP
ORIEN RINDY ERIKA
PANDYA PANDITATWA

1117032009
1117032043
1117032044

MATA KULIAH :
REKAYASA PERANGKAT LUNAK 1
DOSEN : ARISTOTELES, S.Si., M.Si

JURUSAN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
UNIVERSITAS LAMPUNG
2014

KATA PENGANTAR

Puji syukur kehadirat Tuhan Yang Maha Esa yang telah melimpahkan rahmat dan k
arunianya kepada kami , sehingga kami dapat menyelesaikan makalah ini tepat pada
waktunya. Terdorong oleh rasa ingin tahu , kemauan , kerja sama dan kerja keras
, kami kerahkan seluruh upaya pada makalah ini. Semoga tulisan ini dapat memenuh
i kewajiban kami dalam tugas mata kuliah Rekayasa Perangkat Lunak.
Adapun harapan kami, semoga tulisan ini dapat menambah wawasan para pembaca meng
enai investigasi kebutuhan sistem, dengan maksud nantinya pembaca mampu untuk me
ngetahui kebutuhan sistem yang akan dibuat dan faktor-faktor dari kebutuhan sist
em tersebut. Meskipun makalah investigasi kebutuhan sistem ini telah selesai, na
mun terbatasnya kemampuan dan pengetahuan kami membuat makalah ini masih jauh da
ri kata sempurna. Seperti kata pepatah bahwa tak ada gading yang tak retak, begi
tu pula dengan laporan kami yang tidak dapat sempurna.
Oleh karena itu, kritik dan saran yang membangun sangat kami harapkan agar di la
in waktu dapat lebih baik lagi. Terlepas dari ketidaksempurnaan tersebut, kami
mengharapkan laporan ini dapat memberikan manfaat bagi seluruh pihak.

Hormat Kami,

Tim Penulis

DAFTAR ISI

Halaman
KATA PENGANTAR
DAFTAR ISI
DAFTAR TABEL
DAFTAR GAMBAR

i
ii
iv
v

I. PENDAHULUAN
1.1 Latar Belakang
1.2 Tujuan
2

II. PEMBAHASAN
2.1 Aktifitas Analisis 3
2.1.1 Pengumpulan Informasi
3
2.1.2 Menetapkan Kebutuhan Sistem
4
2.1.3 Kebutuhan Prioritas
4
2.1.4 Prototipe Untuk Kelayakan Penemuan
2.1.5 Hasil dan Evaluasi
4
2.1.6 Rekomendasi Ulasan dengan Manajemen
2.2 Kebutuhan Sistem

4
5

2.3 Model dan Permodelan

2.3.1 Tujuan Model
7
2.3.2 Tipe-Tipe Model 7

2.4 Stakeholder
Sumberdaya Kebutuhan Sistem 8
2.4.1 Pengguna Sebagai Stakeholder
9
2.4.2 Stakeholder Client (Klien Pemangku Kepentingan) 11
2.4.3 Technical Stakeholder (Teknisi Pemangku Kepentingan)
2.4.4 The Stakeholder for Rocky Mountain Outfitters
11
2.5 Teknik Pengumpulan Informasi
13
2.5.1 Tema Pertanyaan 13
2.5.2 Ulasan Laporan, Berkas dan Prosedur Deskripsi
2.5.3 Prilaku Wawancara dan Diskusi dengan Pengguna
2.5.4 Memperbaiki dan Dokumentasi Proses Bisnis 20
2.5.5 Membangun Prototipe
24
2.5.6 Mendistribusikan dan Mengumpulkan Pertanyaan
2.5.7 Sesi Kerjasama Prilaku Desain Aplikasi
25
2.5.8 Penelitian Solusi Vendor 27
2.6 Memvalidasi Kebutuhan
II. PEMBAHASAN
3.1 Kesimpulan

32

28

15
17
24

11

DAFTAR PUSTAKA 33

DAFTAR TABEL

Tabel
Halaman
1.
2.

Aktifitas Analisis dan Pertanyaan Kunci 5

Tema Pertanyaan 13

DAFTAR GAMBAR

Gambar
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.

Halaman
Fase Aktifitas Analisis
4
Stakeholder Pada Sistem Baru
9
Hubungan Pengumpulan Informasi dan Pembangunan Model
Formulir Pemesanan RMO 16
Contoh Ceklis Untuk Mempersiapkan Wawancara
17
Contoh Daftar Open-Item 19
Simbol Diagram Aktifitas
21
Model Alur Kerja Diagram Aktifitas 1
22
Model Alur Kerja Diagram Aktifitas 2
23
Fasilitas JAD 27

13

I. PENDAHULUAN

1. 1 Latar Belakang

Sistem analis merupakan seseorang profesional yang mengembangkan informasi dari

suatu sistem, atau yang dapat diartikan sebagai seseorang yang menggunakan tekni
k desain dan analisis untuk memecahkan masalah bisnis menggunakan teknologi info
rmasi. Didalam memecahkan suatu masalah diperlukan suatu kebutuhan-kebutuhan yan
g didapat dari investigasi.
Fase-fase analisis yang dibahas didalam makalah ini yaitu fase perencanaan proye
k, fase analisis aktivitas, fase design, fase implementasi dan fase pendukung. S
emua fase tersebut adalah penting dalam investigasi kebutuhan-kebutuhan sistem.
Didalam fase analisis aktivitas juga terdapat pertanyaan kunci yang dapat memban
tu pula untuk memahami detail dari fase tersebut.
Selain itu terdapat juga penjelasan tentang kebutuhan sistem yang terbagi menjad
i dua bagian yaitu kebutuhan fungsional dan kebutuhan non fungsional.
Memperlajari model-model yaitu model matematika, deskriptif dan grafis. Model-mo
del ini tentunya akan membantu memecahkan masalah. Mempelajari juga tentang stak
eholder atau pemangku kepentingan yang terdapat 3 bagian yaitu pengguna, klien d

an staf teknis.
Selain itu juga terdapat tiga tema utama informasi harus dikejar yaitu apakah pr
oses bisnis dan operasi?, Bagaimana proses bisnis dilakukan? Dan apakah persyar
atan informasi?. Terdapat juga 7 teknik mencari fakta seperti contohnya yaitu JA
D yang akan dibahas pada makalah ini. Serta masih banyak lagi materi-materi yang
akan dibahas untuk melakukan investigasi kebutuhan-kebutuhan sistem.
Dengan tulisan ini kami berharap pembaca dapat lebih mengerti dan dapat menerapk
annya dengan lebih baik tentang investigasi dari kebutuhan-kebutuhan sistem.

1.2 Tujuan

Adapun tujuan dari penulisan makalah ini adalah :

a.
b.
c.
em
d.
em
e.
f.
g.
h.

Mengetahui bagaimana fase perputaran sistem analisis

Mengetahui efek dari proses bisnis pada sistem
Mengetahui perbedaan antara fungsional dan non-fungsional kebutuhan sist
Mengetahui berbagai macam tipe pengguna dalam investigasi kebutuhan sist
Mengetahui informasi yang dibutuhkan untuk pengenbangan kebutuhan sistem
Menentukan kebutuhan sistem
Mengetahui apa saja yang diperlukan untuk validasi kebutuhan sistem
Memenuhi tugas rekayasa perangkat lunak 1

II. PEMBAHASAN

2.1 Aktifitas Analisis

Gambar 1. Fase Aktifitas Analisis
Semua pengembangan sistem dijelaskan dan di simulasikan sesuai dengan aktifitas
didalam analisis dan desain. Selayaknya metodologi pengembangan sistem yang berb
eda di rekomendasikan ke teknik yang berbeda untuk menyelesaikan aktifitas. Pada
sisi lain penciptaan model yang baru dapat menyelesaikan suatu aktivitas. Akan
tetapi setiap pertanyaan melibatkan jawaban yang sama. Selama analisis berlangsu
ng terdapat 6 aktifitas yang harus diselesaikan yaitu
2.1.1 Pengumpulan Informasi
Analisis melibatkan pengumpulan informasi dalam jumlah besar. Sistem analis juga
memperoleh informasi dari seseorang yang akan menggunakan sistem dengan cara me
wawancarai atau melihat mereka sedang bekerja. Informasi didapatkan dari dokumen
perencanaan dan pernyataan peraturan. Documen dari sistem yang pernah ada harus
dibaca dengan teliti. Pembelajaran sistem dengan hati-hati juga harus diterapka
n ketika akan membuat sistem baru.
Dalam memulai seorang analis berapa banyak yang telah mempelajari tentang pekerj
aan mereka. Dalam arti lain apakah seorang yang berkerja pada bidangnya telah me
nguasai bidang yang ditekuni tersebut atau dapat mendukung sepenuhnya pada bidan
g yang diinginkan. Seperti contoh jika berkerja di bank maka berpikirlah bahawa
dirimu adalah sorang pekerja bank. Seorang analis yang paling suskses akan sanga
t terlibat dalam inti organisasi bisnis. Seorang analis juga perlu dalam mengump
ulkan informasi secara teknis untuk mengindentifikasi dan memahami semua aktivit
as yang pernah dan akan datang dengan cara mengindentifikasi semua lokasi bekerj
a dan tatap muka dengan sistem lain didalam maupun diluar organisasi.
2.1.2 Menetapkan Kebutuhan Sistem
Berbagai jenis model diciptakan untuk membantu merekam dan
mengkomunikasikan apa yang dibutuhkan. Proses pemodelan adalah proses pembelajar
an bagi seorang analis. Sebagai model yang dikembangkan, Analis belajar lebih ba
nyak tentang sistem. Modeling berjalan secara terus menerus disisi lain informas
i telah terkumpul. dan analis terus mengkaji model sampai ke pengguna akhir untu
k memastikan bahwa setiap model secara lengkap dan benar.
Terdapat dua jenis model yang dikembangkan yaitu logical model yang mempertunjuk

an kebutuhan sistem dengan detail yang baik, tanpa melakukan satupun teknologi.
Satu lagi yaitu model fisik yaitu memperlihatkan bagaimana sistem itu di impleme
ntasikan dan model fisik akan menegeluarkan format yang detail yang tercantum di
dalamnya
Perbedaan antara logical model dan model fisik adalah konsep kunci yang terdapat
dalam sistem analis dan sistem desain. Secara umum sistem analis melibatkan mod
el logical dan sistem desain melibatkan model fisik.
2.1.3 Kebutuhan Prioritas
Kebutuhan
kebutuhan yang banyak, meyebabkan sulit untuk memilih mana yang tepat
dan baik untuk digunakan. Untuk itu para pengguna dan analis perlu bertanya pada
diri sendiri yang berfungsi benar-benar penting dan yang cukup penting tetapi t
idak mutlak diperlukan. Dengan sumberdaya yang terbatas dan analis harus selalu
siap untuk membenarkan lingkup dari pada sistem tersebut maka penting apa benarbenar diperlukan kecuali analis berhati-hati dalam mengevaluasi prioritas, persy
aratan sistem cenderung berkembang membuat lebih banyak sugesti. Fenomena ini ya
ng disebut juga scope creep.
2.1.4 Prototipe Untuk Kelayakan dan Penemuan
Pembentukan prototipe menjadi salah satu bagian yang berharga selama sistem anal
is. Tujuan primer dari membuat prototipe selama analisis adalah discovery protot
ype atau penemuan prototipe. Penemuan prototipe ini adalah untuk kelayakan da pe
ndekatan tertentu untuk kebutuhan bisnis. Didalam prototipe membantu pengguna un
tuk menemukan persyaratan atau kebutuhan diluar cara berpikir dan membuat mereka
berfikir secara kreatif.
2.1.5 Hasil dan Evaluasi Alternatif
Banyak alternatif yang digunakan untuk desain terakhir dan implementasi dari sis
tem. karena itu tetapkan secara teliti dan evaluasi segala kemungkinan. Ketika k
ebutuhan telah di prioritaskan analis bisa mendapatkan beberapa hasil alternatif
dengan mengeliminasi beberapa dari sedikitnya kebutuhan penting. Begitu banyak
alternatif yang ada dalam setiap proyek kelompok dan memilih alternatif yang pal
ing baik sangatlah susah karena harga dan keuntungan sangat sulit diukur.
2.1.6 Rekomendasi Ulasan Dengan Manajemen
Ulasan rekomendasi dengan manajemen biasanya telah selesai ketika semua aktifita
s telah terselesaikan. Manajemen harus menyimpan informasi dari proses sebagai l
aporan proyek dan proyek manager harus memberikan solusi dan memperoleh keputusa
n dari manajemen.
Aktifitas Analisis
Pertanyaan Kunci
Pengumpulan Informasi Apakah kita telah mempunyai semua informasi yang kita bu
tuhkan untuk menetapkan apa yang akan sistem kerjakan?
Menetapkan Kebutuhan Sistem
Apa yang kita butuhkan untuk sistem bekerja?
Kebutuhan Prioritas
Apa hal yang paling penting yang harus dikerjakan sistem
?
Prototipe Untuk Kelayakan dan Penemuan Sudah terbukti dengan adanya tekhnologi
yang diusulkan dapat mengerjakan apa yang kita butuhkan?
Sudahkah membuat prototipe untuk memastikan pengguna bahwa mengerti akan potensi
al pengerjaan dari sistem baru?
Hasil dan Evaluasi Alternatif Apakah jalan terbaik untuk membuat sistem?
Rekomendasi Ulasan Dengan Manajemen
Haruskah kita melanjutkan desain dan imp
lementasi dari sistem yang diusulkan?
Tabel .1 Aktifitas Analisis dan Pertanyaan Kunci

2.2 Kebutuhan Sistem

Kebutuhan sistem adalah semua kemampuan dan kendala yang ada pada sistem baru ya
ng harus dipertemukan. Secara umum kebutuhan sistem dibagi menjadi dua kategori
yaitu kebutuhan fungsional dan non-fungsional.
Kebutuhan fungsional adalah aktivitas dimana sistem harus menunjukan dan dapat d
ilakukan oleh sistem. kutuhan fungsional ini didasarkan pada prosedur dan peratu
ran didalam organisasi untuk menjalankan bisnis. Sebuah contoh mungkin,"Semua ka
ryawan baru harus mengisi formulir W-4 untuk memasukkan informasi tentang tangg
ungan mereka dalam sistem penggajian."
Kebutuhan Non-fungsional adalah karakteristik dari sistem selain aktifitas yang
harus dilakukan dan didukung. Berikut beberapa tipe dari kebutuhan non-fungsiona
l yaitu :
Kebutuhan Teknis yaitu menjelaskan karakteristik operasional yang ada hubunganny
a dengan lingkungan, hardware dan software dari suatu organisasi. Sebagai contoh
komputer client dan server dimana komputer client menggunakan sistem operasi wi
ndows dan komputer server menggunakan java akan tetapi keduanya saling berhubung
an.
Kebutuhan Kinerja yaitu menjelaskan karakteristik operasional yang berhubungan d
engan ukuran beban kerja waktu respon. Seperti contoh client portion sistem memb
utuhkan satu setengah detik didalam seluruh tampilan dan komponen server boleh
membutuhkan seratus client sesi dalam mendukungnya.
Kebutuhan Guna yaitu mendeskripsikan karakteristik operasional yang berhubungan
dengan pengguna seperti tatap muka pengguna, prosedur kerja, online help, dan do
kumentasi. Sebagai contoh web yang berdasarkan pada tampilan yaitu harus tertuj
u pada tataletak desain, pembuatan logo, pemilihan warna dan lain-lain.
Kebutuhan Andalan yaitu menjelaskan keteguhan suatu sistem yaitu seperti kemampu
an dalam penyelesaian pekerjaan, deteksi error dan lain-lain. Kebutuhan andalan
ini juga menjadi bagian dari kebutuhan Kinerja
Kebutuhan Keamanan yaitu menjelaskan akses pengguna untuk fungsi tertentu dan ko
ndisi dari akses yang diberikan. Seperti contoh yaitu akses sistem tententu bers
ifat terbatas untuk manager dalam level tertentu atau pegawai tertentu.

2.3 Model dan Permodelan

Dalam model terdapat dua pernyataan dimana beberapa model memunculkan masalah da
n penyelesaiaan yang berbeda ada pula suatu model memunculkan masalah dan penyel
esaian yang sama dengan demikian secara garis besar model mempunyai suatu tujua
n.
2.3.1 Tujuan Model
Beberapa pengembang memikirkan model sebagai dokumentasi yang diproduksi setelah
analisis dan desan dikerjakan. Namum, sebenarnya proses pembuatan model membant
u analis mengklarifikasi dan memperbaiki desain. Analis menimbulkan pernyataan s
ekaligus menciptakan model dan jawaban mereka sebagai permodelan pada proses yan
g berlanjut. Dalam hal ini proses pemodelan itu sendiri memberikan manfaat langs

ung kepada analis. Seorang analis menggunakan tekniknya untuk menciptakan model
yang berharga dalam dirinya sendiri bahkan jika analis tidak pernah menunjukan m
odel tertentu kepada orang lain. Jika ditunjukan itu pun adalan proses dari pemb
uatan model. Model bertujuan untuk mengintegrasikan aspek-aspek, model membantu
dalam pengingatan rincian pekerjaan sebelum terselesaikan, model menyediakan car
a menyimpan informasi untuk digunakan dalam bentuk yang mudah dipahami. Dukungan
dalam berkomunikasi juga adalah salah satu yang paling sering dijadikan alasan
untuk menciptakan model. Model juga memegang peranan penting dalam menjaga komun
ikasi antara anggota tim proyek dengan sistem pengguna. Tujuan lain dari dibuatn
ya model ini adalah memudahkan dalam memahami kemungkinan bahwa terdapat sistem
baru.
2.3.2

Tipe

Tipe Model

Model Matematika serangkaian formula yang menggambarkan aspek-aspek teknis dari

sistem dan mewakili aspek yang tepat dari sistem terbaik yang dapat diwakili den
gan menggunakan formula atau notasi matematika, seperti persamaan yang mewakili
kebutuhan jaringan. Model ini adalah contoh kebutuhan teknis. Selain itu rekayas
a aplikasi cenderung menggunakan algoritma matematika yang rumit. Notasi matemat
ika adalah cara yang paling tepat untuk mewakili kebutuhan fungsional ini , dan
juga cara paling alami bagi pengguna ilmiah dan rekayasa untuk mengekspresikan k
ebutuhan tersebut. seorang analis bekerja pada aplikasi ilmiah dan teknik lebih
baik menjadi nyaman dengan matematika. Tapi notasi matematika juga kadang-kadang
efisien untuk kebutuhan sederhana seperti bisnis sistem. Misalnya, dalam aplika
si penggajian , adalah wajar untuk model gaji kotor sebagai regular
membayar ditambah lembur. Titik pemesanan ulang persediaan , harga diskon untuk
produk , atau penyesuaian gaji untuk promosi mungkin dimodelkan dengan rumus sed
erhana.
Model Deskriptif tidak semua dapat didefiniskan melalui matematika seperti mengg
unakan metode ini seperti contohnya memo naratif, laopran atau daftar. Deskripsi
suatu narasi terkadang terbaik digunakan untuk merekam informasi. Selain itu da
ftar sederhana seperti daftar fitur, input, output, peristiwa atau pengguna.daft
ar ini merupakan bentuk model yang deskriptif atau naratif yang ringkas, spesifi
k dan berguna. Contoh terakhir dari model deskriptif adalah melibatkan menulis s
uatu proses atau prosedur yang tepat disebut dengan struktur inggris atau pseudo
code.
Model Grafis adalah model yang mungkin paling berguna diantara model-model yang
lainnya. Model grafis termasuk diagram dan representasi skematis dari beberapa a
spek sistem. Model grafis mudah untuk memahami hubungan yang kompleks yang terla
lu sulit untuk diikuti jika dijelaskan secara lisan . Ingat pepatah lama bahwa s
ebuah gambar bernilai seribu kata-kata. Tapi bagi sebagian besar pekerjaan anali
s, model grafis menggunakan simbol untuk mewakili hal-hal abstrak seperti agen e
ksternal, proses, data, benda , pesan dan koneksi. Model grafis utama yang digun
akan selama analisis sistem cenderung untuk mewakili aspek yang lebih abstrak da
ri suatu sistem, karena analisis ini berfokus cukup pada pertanyaan abstrak tent
ang persyaratan sistem tanpa menunjukkan rincian tentang bagaimana mereka akan d
iimplementasikan. Simbol-simbol yang ada pada model iniadalah terbatas yaitu lin
gkaran, persegi, persegi panjang, garis dan sebagainya. Jadi berhati-hatilah jik
a pertama kali belajar simbol masing-masing model.

2.4 Stakeholder

Sumberdaya Kebutuhan Sistem

Stakeholders adalah semua orang yang memiliki kepentingan dalam keberhasilan pel
aksanaan dari sistem. Umumnya, kita kategorikan stakeholder menjadi tiga kelompo
k :
1.
User (Pengguna) : mereka yang benar-benar menggunakan sistem setiap hari

2.
Klien : mereka yang membayar dan memiliki sistem
3.
Staf teknis : orang-orang yang harus memastikan bahwa sistem beroperasi
dalam lingkungan komputasi organisasi.
Di masa lalu , masalah telah muncul dengan sistem baru karena hanya beberapa sta
keholder dilibatkan dalam proyek dan sistem dibangun khusus untuk mereka. Tugas
pertama seorang analis adalah untuk mengidentifikasi setiap jenis pemangku kepen
tingan atau stakeholder yang memiliki minat dalam sistem baru . Tugas kedua adal
ah untuk memastikan bahwa orang-orang penting dari masing-masing kategori pemang
ku kepentingan proyek adalah sebagai pakar bisnis .

Gambar 2. Stakeholder Kepada Sistem Baru

2.4.1 Pengguna sebagai Stakeholder
Pengguna sistem dibagi menjadi dua dimensi yaitu dimensi horizontal dan dimensi
vertikal. Dengan horizontal, analis harus mencari aliran informasi seluruh depar
temen bisnis. Sebagai contoh, sistem persediaan baru dapat mempengaruhi penerima
an, penyimpanan, penjualan, dan manufaktur. Jadi, karyawan individu dari masingmasing departemen ini harus menggambarkan kebutuhan mereka. Departemen penjuala
n mungkin perlu menentukan kapan dan bagaimana untuk memperbarui jumlah persedi
aan atau untuk melakukan persediaan pada saat akan dijual tetapi sebelum dikirim
. Manufaktur mungkin membutuhkan informasi tertentu dari persediaan sistem untuk
membantu dalam penjadwalan produksi. Dari dimensi vertikal berarti informasi di
butuhkan dari staf administrasi, manajemen menengah dan senior eksekutif.masing
masing stakeholder memiliki pemikiran masing-masing yang akan dimasukan kedalam
desain. Bagian berikut menjelaskan karakteristik dari dimensi vertikal yang berp
engaruh juga pada dimensi horizontal.
1.

Pengguna Bisnis

adalah orang-orang yang menggunakan sistem untuk melakukan operasi sehari-hari d

ari organisasi. Kita sering menyebut transaksi operasi ini. Sebuah transaksi ada
lah bagian dari pekerjaan yang selesai dilakukan dalam sebuah organisasi , seper
ti "memasukkan perintah." Dalam Bab 1, Anda belajar bahwa proses transaksi siste
m menangani beberapa jenis operasi bisnis . Pengguna bisnis memberikan informasi
tentang operasi bisnis sehari-hari dan cara-cara dimana sistem harus mendukung.
2.

Pengguna Informasi

Seorang pengguna informasi adalah orang yang membutuhkan informasi terkini dari
sistem. orang tesebut mungkin pengguna operasional atau orang lain. Dalam bebera
pa kasus, bisnis mungkin ingin membuat informasi langsung tersedia bagi pelangga
n. Namun, pengguna informasi mungkin tidak diperbolehkan untuk memasukkan inform
asi pada transaksi bisnis, hanya untuk melihat sebuah informasi tertentu. Sebuah
informasi pengguna menyediakan analis dengan wawasan tentang jenis informasi ha
rus tersedia dalam jangka waktu harian, mingguan, bulanan, dan tahunan, dan deng
an format yang paling nyaman.
3.

Pengguna Manajemen

Manajer bertanggung jawab untuk melihat bahwa suatu perusahaan melakukan prosedu
r harian secara efisien dan efektif. Akibatnya, mereka membutuhkan statistik dan
ringkasan informasi dari sistem. Manajemen akan membantu seorang analis menjawa
b jenis pertanyaan berikut :
Jenis laporan apa yang harus dihasilkan sistem ?
Jenis kinerja statistik apa yang harus dipertahankan sistem ?

Jenis informasi apa yang harus dijaga sistem, dan transaksi yang harus mendukun
g sistem baru ?
Apakah kontrol dalam sistem memadai untuk mencegah kesalahan dan penipuan ?
Berapa banyak permintaan informasi akan dibuat dan seberapa sering ?
4.

Pengguna Eksekutif

Dalam puncak eksekutif dari sebuah organisasi tertarik pada isu-isu strategi, sa
mam baiknya dengan isu yang biasanya di deskripsikan. Mereka biasanya ingin info
rmasi dari sebuah sistem dan akan membandingkan kebaikan di pemanfaatan sumber d
aya. dan juga ingin sistem antar muka dengan sistem lain untuk menyediakan strat
egi informasi tentang tren dan arah dari industri bisnis.
5.

Pengguna Eksternal

Semakin banyak sistem saat ini memungkinkan entitas eksternal untuk memiliki aks
es langsung ke sistem. Pelanggan dapat mengakses sistem secara langsung melalui
internet. Pemasok mungkin memiliki akses ke sistem untuk memeriksa tingkat perse
diaan dan untuk memulai penagihan transaksi pengguna ini lebih sulit untuk mengi
dentifikasi dan akses karena mereka bukan anggota biasa dari organisasi. Namun,
saat ini mereka milik kelompok penting yang harus diperhatikan dalam pengembanga
n sistem.
2.4.2 Stakeholder Client
Meskipun tim proyek harus memenuhi kebutuhan pengolahan informasi dari pengguna,
itu juga harus memuaskan klien. Bab 3 mendefinisikan klien sebagai orang atau k
elompok yang menyediakan pendanaan untuk proyek tertentu. Dalam banyak kasus kli
en adalah kelompok yang sama seperti pengguna eksekutif.
Namun, klien juga dapat menjadi kelompok yang terpisah, seperti dewan kehormatan
atau eksekutif dalam perusahaan induk. Tim proyek meliputi klien dalam daftar s
takeholder (pemangku kepentingan) adalah penting, karena tim harus memberikan ul
asan status secara berkala kepada klien di seluruh pembangunan.
Klien atau perwakilan langsung pada panitia pengarah atau pengawasan juga biasan
ya menyetujui tahapan dari proyek dan pemberian dana.
2.4.3 Technical Stakeholder
Meskipun staf teknis bukanlah kelompok pengguna yang benar, kelompok ini mempeng
aruhi banyak persyaratan sistem .Staf teknis termasuk orang-orang yang membangun
dan memelihara lingkungan komputasi organisasi. Mereka memberikan bimbingan dib
erbagai bidang seperti bahasa pemrograman, platform komputer, dan peralatan lain
nya. Untuk beberapa proyek, tim proyek meliputi anggota staf teknis. Untuk proye
k-proyek lain , tenaga teknis yang tersedia sesuai kebutuhan.
2.4.4 The Stakeholder for Rocky Mountain Outfitters
Suatu bagian terpenting dari investigasi kebutuhan sistem adalah untuk menginden
tifikasi semua stakeholder atau pemangku kepentingan. Himpunan persyaratan tidak
lengkap jika pengguna, klien, entitas eksternal, atau staf teknik penting tidak
berkonsultasi dengan informasi yang dikumpulkan. Pada RMO pengguna sistem order
-processing yang baru termasuk perwakilan penjualan di dalam yang menerima perin
tah atas telepon, serta pegawai yang memproses pesan. Mereka semua memiliki pand
angan yang berbeda terhadap apa yang harus sistem lakukan terhadap mereka. Penju
al berbicara untuk mencari informasi dari pelanggan dan mengkonfirmasikan keters
ediaan serta pengiriman tanggal. Pemesan pesan berbicara tentang memindai inform
asi pesanan ke dalam sistem untuk menghilangkan proses mengetik. Para pekerja gu
dang yang menempatkan pengiriman, bersama-sama membutuhkan informasi tentang per
intah yang telah dikirim, perintah untuk dikirim ,dan kemabi memesan, serta laya
r operasional normal mereka yang memungkinkan mereka untuk menempatkan pesanan b

ersama-sama ke pengiriman dengan tagihan yang dicetak . John dan Liz Blankens se
bagai pemilik memiliki kepentingan khusus dalam laporan produk yang telah dipesa
n dan dikirim . Mereka tertarik menonton tren musiman dalam dan seluruh produk.
Dalam bisnis peralatan olahraga itu sangat penting untuk mendorong trendi barang
dengan cepat dan bergerak pada saat tren masa lalu. Pengembanga dari sistem duk
ungan pelanggan telah didanai sebagian dari internal kas. Dana juga telah dipero
leh. Namun, melalui jalur khusus kredit di
Bank. RMO biasanya memiliki kredit jangka pendek untuk kebutuhan musiman . Karen
a proyek CSS adalah modal bagus untuk investasi jangka panjang, John dan Liz mem
peroleh pemikiran yang berbeda dari pembiayaan itu. Petugas bank mereka sangat t
ertarik pada keberhasilan proyek, sehingga dalam kasus ini, tim proyek bahkan be
rtemu dengan staf bank untuk melihat format khusus keuangan untuk mendapatkan in
formasi yang digunakan untuk pertahanan sistem.
Akhirnya, karena sistem ini akan melibatkan internet sebagai teknologi baru dan
didistribusikan. Keterlibatan sistem dibutuhkan oleh staf teknis. Akibatnya, ban
yak pemangku kepentingan atau stakeholder akan memiliki masukan ke dalam jenisjenis informasi yang dapat diekstraksi dari sistem. mengilustrasikan, dari tingk
at atas struktur organisasi RMO, orang-orang yang akan
terlibat. Posisi jingga menunjukkan eksekutif dan manajer menengah yang akan dil
ibatkan sebagai stakeholder. Manajer proyek akan membangun daftar semua pengguna
yang perlu terlibat dalam definisi persyaratan. Bagan organisasi ini hanya awal
. Manajer departemen dan karyawan kunci lain juga akan ditambahkan. Bagaimana ti
m proyek mengidentifikasi stakeholder untuk dimasukkan dalam jadwal wawancara? M
erupakan pertanyaan yang sulit dimana proses dimulai dengan analisis lingkup yan
baru. Setelah mengidentifikasi ruang lingkup kelompok harus berhati-hati dengan
semua orang yang mungkin memerlukan informasi dari sistem dengan cara apapun. P
ada poin ini lebih baik salah dari pada melewatkan sumberdaya yang dibutuhkan. B
arbara Halifax mengirim memo John MacMurty untuk memperbarui kemajuan pengindent
ifikasi dari Stakeholder CSS dan rencana mendatangnya untuk mengumpulkan inform
asi.

2.5 Teknik Pengumpulan Informasi

Gambar 3. Hubungan Pengumpulan Informasi dan Pembangunan Model

Para analis mengembangkan model logis dari sistem baru karena mereka ingin mengu
mpulkan informasi. Tim proyek menciptakan model fisik (yaitu, bagaimana sistem a
kan dibangun) kemudian sebagai bagian dari
desain sistem. Analis fokus pada tema-tema tertentu dan menggunakan berbagai tek
nik untuk mengembangkan model logis dari sistem.
2.5.1 Tema Pertanyaan
Pertanyaan pertama yang sistem baru analis tanyakan adalah, "Jenis informasi apa
yang saya perlukan untuk dikumpulkan? Apa persyaratannya? " Pada dasarnya, Anda
ingin memperoleh informasi yang memungkinkan anda untuk membangun model logis d
ari sistem bisnis baru. Seperti ditunjukkan dalam Gambar 4-9, tiga
tema utama harus membimbing Anda ketika Anda meneruskan penyelidikan Anda.
TEMA
PERTANYAAN UNTUK PENGGUNA
Bisnis operasi dan proses apa saja?
Apa yang anda kerjakan?
Bagaimana seharusnya operasi bekerja? Bagaimana anda
melakukannya?
Tahap apa yang kamu ikuti?
Informasi apa yang dibutuhkan untuk memperlihatkan operasi?
Informasi apa ya

ng anda gunakan?
Tabel 2. Tema Pertanyaan
Apa Sajakah Proses Bisnis?
Pada bagian pertama pertanyaan-Apa yang Anda lakukan? Fokusnya adalah pada pemah
aman fungsi bisnis. Pertanyaan ini adalah langkah pertama untuk dapat berjalan.
Analis harus mendapatkan
daftar lengkap dari semua proses bisnis. Dalam kebanyakan kasus, pengguna member
ikan jawaban dalam hal sistem, sehingga analis harus hati-hati membedakan mana f
ungsi-fungsi yang mendasar-yang akan tetap ada dan yang mungkin dapat dihilangka
n untuk meningkatkan sistem. Misalnya, pegawai penjualan mungkin menunjukkan ba
hwa hal pertama yang mereka lakukan ketika pelanggan memesan pada saat itu juga
memeriksa sejarah kredit pelanggan. Dalam sistem baru, pegawai penjualan mungkin
tidak perlu untuk melakukan fungsi tersebut, sistem akan melakukan cek secara o
tomatis. Fungsi itu tetap menjadi kebutuhan sistem, tetapi metode melaksanakan f
ungsi bergerak dari pegawai ke sistem komputer.
Bagaimana Proses Bisnis Dilakukan?
Kedua pertanyaan-Bagaimana itu bisa dilakukan?
Memindahkan diskusi dari sistem saat ini ke sistem baru. Fokusnya adalah bagaima
na sistem baru harus mendukung fungsi tersebut bukan bagaimana melakukannya seka
rang. Dengan demikian, dua pertanyaan pertama berjalan beriringan untuk menemuka
n kebutuhan dan mulai untuk mendefinisikan persyaratan sistem dalam hal sistem b
aru. Para pengguna yang paling sering berbicara tentang sistem saat ini, tetapi
sangat penting bagi analis sistem untuk melampaui proses saat ini artinya untuk
melewati fase ini. Ia harus mampu membantu pengguna visualisasi pendekatan baru
dan lebih efisien untuk melakukan proses bisnis yang dimungkinkan oleh teknologi
baru.
Informasi Apa Apakah Diperlukan?
Pertanyaan Terakhir-Informasi apa yang dibutuhkan?
Menguraikan tentang pertanyaan kedua dengan mendefinisikan informasi yang spesif
ik bahwa sistem baru harus tersedia. Jawaban atas kedua dan pertanyaan ketiga me
mbentuk dasar untuk mendefinisikan persyaratan sistem. Salah satu kekurangan ana
lis sistem baru adalah bahwa mereka tidak mengidentifikasi semua yang diperlukan
oleh informasi. Dalam kedua pertanyaan ini dan yang sebelumnya, detail adalah s
emboyan. Seorang analis harus memahami detail seluk-beluk untuk mengembangkan so
lusi yang tepat. Dengan fokus pada tiga tema ini membantu seorang analis bertany
a cerdas, pertanyaan yang berarti dalam penyelidikan. Kemudian, saat Anda belaja
r tentang model, Anda akan dapat merumuskan pertanyaan tambahan bermakna dan rin
ci untuk dipertanyakan. Ketika Anda mengembangkan keterampilan dalam mengajukan
pertanyaan dan model bangunan, pemecahan masalah dan kemampuan analisis akan men
ingkat. Ingat, nilai Anda sebagai seorang analis sistem tidak dari tahu bagaiman
a membangun sebuah model tertentu atau bagaimana program dalam bahasa tertentu.
Nilai Anda dalam Anda kemampuan untuk menganalisa dan memecahkan masalah untuk i
nformasi bisnis dan mengumpulkan informasi yang benar.
Keterampilan fundamental itu adalah bagaimana anda efektif dan efisien dalam men
gidentifikasi dan menangkap aturan bisnis tersebut. Persyaratan yang efektif dan
lengkap, komprehensif, dan benar. Sebuah efisien analis adalah orang yang berge
rak pada proyek yang maju pesat dengan intrusi minimal pada waktu pengguna dan p
enggunaan sumber daya lainnya, namun memastikan bahwa informasi yang dikumpulkan
akan menghasilkan kelengkapan, spesifikasi persyaratan yang komprehensif, dan b
enar. Bagian berikutnya menyajikan berbagai metode pengumpulan informasi. Semua
metode ini telah terbukti efektif, meskipun beberapa lebih efisien daripada yang
lain. Dalam kebanyakan kasus, analis menggabungkan metode untuk meningkatkan ef
ektifitas dan efisiensi mereka dan memberikan pendekatan fakta yang komprehensif

. Metode yang paling banyak digunakan adalah sebagai berikut:

Laporan Ulasan yang ada, bentuk, dan deskripsi prosedur
Lakukan wawancara dan diskusi dengan pengguna
Amati dan proses bisnis dokumen
Membangun prototipe
Mendistribusikan dan mengumpulkan kuesioner
(JAD) sesi Melakukan desain aplikasi bersama
solusi vendor Penelitian.
2.5.2 Ulasan Laporan, Berkas dan Prosedur Deskripsi.
Langkah ini mungkin harus menjadi yang pertama dalam pencarian fakta. Ada dua su
mber informasi untuk prosedur dan berkas yang telah ada. Satu sumber eksternal u
ntuk organisasi dan pada perusahaan lain. Ini mungkin tidak mudah untuk mendapat
kan informasi dari perusahaan lain, tetapi mereka adalah sumber potensial dari i
nformasi penting. Kadang-kadang, jurnal dan majalah industri melaporkan temuan "
praktik terbaik" dalam studi atau pembelajaran. Tim proyek akan lalai dalam tuga
snya jika anggotanya tidak sesuai dengan informasi dari praktik terbaik. Dan jug
a, dengan batas-batas organisasi sistem penyeberangan lebih dan lebih, sumber ek
sternal merupakan sumber penting dari persyaratan sistem. Sumber kedua dari lapo
ran, formulir, dan prosedur adalah dokumen bisnis yang ada dan deskripsi prosedu
r dalam organisasi. Review internal ini melayani dua tujuan yaitu yang pertama a
dalah cara yang baik untuk mendapatkan pemahaman awal dari sebuah proses. Sering
kali pada sistem baru analis perlu belajar tentang industri atau aplikasi terten
tu yang mereka harus pelajari. Ulasan awal dokumentasi yang ada akan membawa mer
eka sampai dengan kecepatan yang cukup cepat.
Untuk memulai proses, para analis meminta pengguna untuk memberikan salinan form
ulir dan melaporkan apa yg sedang dipakai. Mereka juga meminta salinan prosedur
manual dan deskripsi kerja. Tinjauan bahan-bahan ini memberikan pemahaman tentan
g fungsi bisnis. Mereka juga membentuk berkas untuk pengembangan pertanyaan untu
k wawancara rinci. Cara kedua untuk menggunakan dokumen dan laporan adalah wawan
cara mereka sendiri. Berkas dan Laporan dapat berfungsi sebagai alat bantu visua
l untuk wawancara, dan sebagai dokumen kerja untuk diskusi. Diskusi dapat berpus
at pada penggunaan setiap berkas, bersifat objektif, distribusi, dan isi informa
sinya. Diskusi ini juga harus mencakup peristiwa bisnis yang spesifik yang memul
ai penggunaan berkas. Beberapa peristiwa bisnis yang berbeda mungkin memerlukan
bentuk yang sama, dan informasi yang spesifik tentang peristiwa dan proses bisni
s yang sangat penting. Ini juga selalu membantu untuk memiliki berkas yang telah
diisi dengan informasi nyata untuk memastikan bahwa analis memperoleh pemahaman
yang benar tentang kolom dan konten data. Meninjau dokumentasi dari prosedur ya
ng ada membantu mengidentifikasi aturan bisnis yang mungkin tidak muncul dalam w
awancara. Prosedur tertulis juga membantu mengungkapkan perbedaan dan redudansi
dalam proses bisnis. Namun, prosedur manual sering tidak diperbaharui, dan merek
a umumnya terdapat kesalahan. Untuk memastikan bahwa asumsi dan aturan bisnis ya
ng berasal dari dokumentasi yang ada sudah benar, analis harus meninjau mereka l
ewat pengguna.

Gambar 4. Formulir Pemesanan RMO

2.5.3 Prilaku Wawancara dan Diskusi Dengan Pengguna
Wawancara stakeholder (pemangku kepentingan) adalah cara yang jauh paling efekti
f untuk memahami fungsi bisnis dan aturan bisnis. Hal ini juga yang paling memak
an waktu dan pilihan sumber daya yang mahal. Dalam metode ini, sistem analis ber
temu dengan individu atau kelompok pengguna. Daftar pertanyaan rinci dipersiapka
n, dan diskusi terus berlanjut sampai semua persyaratan pengolahan dipahami dan
didokumentasikan oleh tim proyek. Jelas, proses ini mungkin memakan waktu lama,

sehingga biasanya membutuhkan beberapa sesi dengan masing-masing pengguna atau k

elompok pengguna. Untuk melakukan wawancara yang efektif, analis perlu mengatur
kedalam tiga bidang: mempersiapkan wawancara, melakukan wawancara, dan menindakl
anjuti wawancara. Gambar 5 adalah checklist sampel yang merangkum poin utama yan
g akan dibahas, hal ini berguna dalam mempersiapkan dan melakukan wawancara.

Gambar 5. Contoh Ceklis Untuk Mempersiapkan Wawancara

Persiapan Untuk Wawancara
Setiap wawancara yang baik selalu membutuhkan persiapan. Langkah pertama dan pal
ing penting dalam mempersiapkan untuk wawancara adalah untuk membangun tujuannya
. Langkah kedua adalah untuk menentukan pengguna harus terlibat dalam wawancara.
Seringkali bahwa keduanya dilakukan bersama-sama. Bahkan jika Anda tidak melaku
kan hal lain untuk mempersiapkan wawancara Anda, Anda harus setidaknya menyelesa
ikan dua langkah. Tujuan dan peserta menjalankan bahan lain dalam wawancara. Par
a peserta wawancara mencakup baik pengguna dan anggota proyek. Secara umum, seti
daknya dua anggota proyek yang terlibat dalam setiap wawancara. Dua anggota proy
ek saling membantu selama wawancara dan membandingkan catatan sesudahnya untuk m
emastikan akurasi. Jumlah pengguna bervariasi tergantung pada tujuan wawancara.
Pengguna sedikit umumnya terbaik ketika tujuan wawancara sempit atau bersifat fa
kta secara natural. Dalam kasus tersebut, mewawancarai lebih dari tiga pengguna
sekaligus cenderung menyebabkan diskusi yang tidak perlu panjang.
Langkah selanjutnya adalah mempersiapkan pertanyaan rinci yang akan digunakan da
lam wawancara. Tuliskan daftar pertanyaan yang spesifik dan catatan berdasarkan
bentuk atau laporan yang diterima sebelumnya. Biasanya Anda harus mempersiapkan
daftar pertanyaan yang konsisten dengan tujuan dari wawancara. Kedua pertanyaanpertanyaan terbuka dan pertanyaan tertutup. Pertanyaan seperti, "Bagaimana Anda
melakukan fungsi ini?" mendorong diskusi dan suatu penjelasan. Pertanyaan-tertut
up seperti, "Berapa banyak berkas yang kamu proses dalam sehari?" Digunakan untu
k mendapatkan fakta-fakta tertentu. Langkah terakhir adalah untuk membuat susuna
n wawancara akhir dan susunan untuk berkomunikasi dengan semua peserta. Sebuah w
aktu tertentu dan lokasi harus ditetapkan. Setiap peserta harus tahu tujuan dar
i pertemuan tersebut dan, bila perlu, harus memiliki kesempatan untuk melihat pe
rtanyaan atau bahan yang akan digunakan.
Melakukan Wawancara
Sistem analis baru biasanya cukup gugup dalam melakukan wawancara. Namun, di seb
agian kasus, pengguna sangat antusias tentang mendapatkan sistem yang lebih baik
untuk membantu mereka melakukan pekerjaan. Belajar sopan santun biasanya memast
ikan bahwa wawancara akan berjalan dengan baik. Berikut adalah beberapa panduan
dalam melakukan wawancara :
?
Berpakaian yang baik dan tepat. Tujuan dalam dressing adalah untuk komp
etensi proyek dan profesionalisme tanpa mengintimidasi pengguna.
?
Datanglah tepat waktu. Jika ada, menjadi sedikit lebih awal. Jika sesi i
ni di ruang konferensi, pastikan bahwa itu sudah diatur dengan tepat.
?
Batasi waktu wawancara. Baik persiapan dan wawancara itu sendiri mempeng
aruhi waktu diperlukan. Ketika Anda menetapkan tujuan dan mengembangkan pertanya
an, misalnya telah direncanakan selama sekitar satu jam setengah. Jika wawancara
akan membutuhkan waktu yang lebih banyak untuk menutupi pertanyaan, biasanya le
bih baik untuk memutuskan diskusi dan masuk ke jadwal sesi lain.

?
Carilah kondisi pengecualian dan kondisi kesalahan. Carilah kesempatan u
ntuk bertanya "bagaimana jika". "Bagaimana jika tidak datang? Bagaimana jika tan
da tangan hilang? Bagaimana jika saldo tidak benar? Bagaimana jika dua bentuk r
angka persis sama? " Inti dari analisis sistem yang baik adalah pemahaman semua
"bagaimana jika." Buatlah upaya sadar untuk mengidentifikasi semua kondisi penge
cualian dan meminta informasi tentang mereka. Lebih dari keterampilan lainnya, k
emampuan untuk berpikir tentang pengecualian akan memperkuat keterampilan menemu
kan aturan bisnis yang terperinci. Ini adalah keterampilan yang sulit untuk bela
jar dari buku teks, pengalaman akan mengasah keterampilan ini.
?
Menyelidiki untuk rincian. Selain mencari kondisi pengecualian, analis h
arus menyelidiki untuk memastikan pemahaman yang lengkap dari semua prosedur dan
aturan. Ini merupakan hal tersulit untuk mencari informasi yang cukup detail.
?
Mencatat. Ini adalah ide yang baik untuk mengambil catatan. Biasanya men
ggunakan tape recorder membuat pengguna gugup. Mencatat yang anda anggap penting
.
Menindaklanjuti Wawancara
Tindak lanjut adalah bagian penting dari setiap wawancara. Tugas pertama adalah
untuk menyerap, memahami, dan mendokumentasikan informasi yang diperoleh. Umumny
a, analis mendokumentasikan rincian wawancara dengan membangun model proses bisn
is dan menulis deskripsi persyaratan nonfunctional.
Gambar 6. Contoh Daftar Open-Item
2.5.4 Memperhatikan dan Dokumentasi Proses Bisnis
Selama wawancara, metode yang sangat berguna untuk mengumpulkan informasi adalah
mengamati pengguna langsung di lokasi dan mendokumentasikan proses yang diamat
i.
Mengamati
mengamati proses bisnis akan membantu Anda memahami fungsi bisnis. Namun, sambil
mengamati proses yang ada, Anda juga harus
mampu memvisualisasikan proses bisnis terkait pada sistem baru. Artinya, ketika
Anda mengamati proses bisnis saat ini untuk memahami kebutuhan bisnis fundamenta
l, Anda harus ingat bahwa proses bisnis dapat berubah menjadi efisien. Jangan te
rkunci bahwa hanya ada satu jalan untuk menunjukan suatu proses.
Anda dapat mengamati pekerjaan dalam beberapa cara, dari langkah-langkah dari ka
ntor atau pabrik untuk melakukan pekerjaannya sendiri. Menghabiskan beberapa jam
mengamati pengguna pada pekerjaan mereka membantu Anda memahami lebih rinci men
ggunakan sistem komputer dan melaksanakan fungsi bisnis. Seperti wawancara, bia
sanya lebih baik dua analisis langsung mengamati. Pengamatan sering membuat peng
guna gugup, sehingga Anda harus sesederhana mungkin. Menempatkan pengguna nyaman
dengan beberapa cara, seperti bekerja dengan pengguna atau mengamati beberapa p
engguna sekaligus. Akal sehat dan kepekaan terhadap kebutuhan dan perasaan pengg
una biasanya akan menghasilkan pengalaman yang positif.
Mendokumentasikan Alur Kerja Dengan Diagram Aktifitas
Ketika Anda mengumpulkan informasi tentang proses bisnis, terutama dengan mewawa
ncarai para pengguna dan
dengan mengamati proses, Anda perlu untuk mendokumentasikan hasil Anda. Salah sa
tu cara efektif untuk menangkap informasi ini adalah melalui penggunaan diagram
untuk menggambarkan alur kerja dari sistem baru, tetapi untuk sekarang, mari kit
a fokus pada bagaimana kita akan mendokumentasikan alur kerja bisnis saat ini.

Sebuah alur kerja adalah urutan langkah-langkah pengolahan yang benar-benar mena
ngani satu transaksi bisnis atau permintaan pelanggan. Alur kerja mungkin sederh
ana atau kompleks. Alur kerja yang kompleks dapat terdiri dari puluhan atau ratu
san langkah-langkah pengolahan dan mungkin termasuk peserta dari berbagai
bagian dari sebuah organisasi.
Keuntungan dari diagram sederhana bahwa Anda dapat memvisualisasikan lebih baik,
Salah satu Manfaat utama menggunakan diagram dan model adalah menjadikan mekani
sme komunikasi yang kuat antara tim proyek dan pengguna. Tidak ada satu diagram
umumnya digunakan untuk memodelkan alur kerja. Diagram umum digunakan meliputi d
iagram alur, diagram aliran data, dan diagram aktivitas. Data flow diagram melak
ukan pekerjaan dengan baik menangkap aliran data dalam alur kerja, tetapi mereka
tidak dirancang untuk mewakili aliran kontrol.
Flowchart secara khusus dirancang untuk mewakili aliran kontrol antara langkah-l
angkah pengolahan, tetapi mereka tidak mewakili aliran data. Jadi, banyak analis
menggunakan jenis alur kerja diagram disebut diagram aktivitas. Sebuah diag
ram aktivitas hanyalah sebuah diagram alur kerja yang menggambarkan kegiatan be
rbagai pengguna (atau sistem). Diagram aktivitas adalah salah satu dari Unified
Modeling Language (UML) diagram yang berhubungan dengan pendekatan berorientasi
obyek, tetapi dapat digunakan dengan pendekatan pembangunan. Gambar 7 menunjukka
n simbol-simbol dasar yang digunakan dalam diagram aktivitas. Oval mewakili kegi
atan individu dalam sebuah alur kerja. Panah mewakili urutan antara kegiatan. Li
ngkaran hitam yang digunakan untuk menunjukkan awal dan akhir dari alur kerja. B
erlian adalah titik keputusan di mana aliran proses akan baik mengikuti satu jal
ur
atau jalan lain. Garis padat berat adalah tempat penghubung yang baik membagi j
alan menjadi beberapa jalur bersamaan atau mengkombinasikan jalan bersamaan. Swi
mlane tersebut merupakan
agen yang melakukan kegiatan. Karena dalam alur kerja bersifat umum untuk memili
ki yang berbeda agen (yaitu orang-orang) melakukan langkah-langkah yang berbeda
dari proses alur kerja, simbol swimlane membagi kegiatan alur kerja menjadi kelo
mpok-kelompok untuk menunjukan agen yang sedang bekerja.
Gambar 7. Simbol Diagram Aktifitas
Gambar 8 adalah diagram aktivitas sebenarnya untuk alur kerja. Alur kerja inimem
perlihatkan bahwa pelanggan membutuhkan pekerja. Jika itu adalah permintaan sede
rhana, penjual dapat memasukkan data dan membuat kutipan. Jika kompleks, penjual
meminta bantuan dari ahli teknis untuk menghasilkan kutipan.
Melihat Gambar 8, Anda dapat melihat bagaimana alur kerja berlangsung. Para pela
nggan inisiatif untuk langkah pertama dengan meminta penawaran. Penjual melakuka
n langkah berikutnya dalam alur kerja. Dia menuliskan rincian permintaan penawar
an dan kemudian memutuskan apakah dia bisa melakukannya sendiri atau
membutuhkan bantuan. Jika dia tidak butuh bantuan, penjual memasukkan informasi
ke dalam sistem komputer. Jika tenaga penjual perlu bantuan, ahli teknis melakuk
an langkah berikutnya.
Ahli meninjau permintaan penawaran untuk memastikan bahwa komponen yang diminta
dapat diintegrasikan ke dalam sistem komputer berfungsi. Kegiatan memeriksa perm
intaan tersebut cukup rumit,
dan Anda menginginkan anda bisa memecahnya menjadi langkah-langkah yang lebih ri
nci.
Untuk saat ini, mari kita tinggalkan diagram pada tingkat detail. Ahli kemudian
memasukkan informasi ke dalam sistem. Pada saat ini
sistem komputer menghasilkan kutipan rinci. Perhatikan bahwa tidak peduli jalan
mana yang diambil, mereka berdua menghasilkan kegiatan bersama ini. Akhirnya, u
lasan pelanggan dan
memutuskan apakah perlu perubahan atau diterima.

Gambar 8. Model Alur Kerja Diagram Aktifitas 1

Gambar 9 mengilustrasikan alur kerja yang lain. Diagram ini menunjukkan beberapa
konsep baru. Mari kita berasumsi bahwa pelanggan dari contoh sebelumnya memang
ingin melanjutkan dengan pesanan. Gambar 9 menunjukkan alur kerja yang diperluka
n untuk mendapatkan pesanan yang dijadwalkan untuk produksi. Penjual mengirimkan
catatan yang dicetak kepada pekerja mesin, yang sekarang telah menjadi perintah
. Ini contoh fakta bahwa dokumen sedang dikirim. Untuk menunjukkan bahwa dokumen
sedang berjalan, Anda menempatkan simbol dokumen pada akhir panah dan panah sek
arang menjadi saluran untuk transmisi dokumen, bukan hanya aliran kegiatan. Sete
lah teknik mengembangkan spesifikasi, dua kegiatan bersamaan terjadi: pembelian
bahan, dan produksi menulis program untuk mesin penggilingan otomatis. Kedua keg
iatan yang benar-benar independen dan dapat terjadi pada waktu yang sama.

Gambar 9. Model Alur Kerja Diagram Aktifitas 2

Berikut Panduan Sederhana dalam pembuatan diagram:
Gunakan simbol keputusan untuk mewakili baik / atau situasi-satu jalur atau jala
n lain, namun tidak keduanya.
Gunakan sinkronisasi bar untuk paralel jalan. Dimana Situasi kedua jalur yang di
ambil.
2.5.5 Membangun Prototipe
Prototip yang digunakan untuk menguji dan memvalidasi ide-ide, dan ada banyak na
ma untuk membedakan penggunaan ini: prototipe sekali pakai, prototipe penemuan,
prototipe desain, dan perkembangan prototipe. Seperti telah dijelaskan, prototip
e digunakan selama analisis untuk menguji kelayakan dan untuk membantu mengident
ifikasi persyaratan pengolahan. Prototipe ini mungkin dalam bentuk layar sederha
na atau laporan program. Selama desain, prototipe dapat dibangun untuk menguji b
erbagai desain dan antarmuka alternatif. Bahkan selama pelaksanaan, prototipe da
pat dibangun untuk menguji efektivitas dan efisiensi teknik pemrograman yang ber
beda. Prototyping adalah suatu alat yang kuat dimana akan sangat berguna dalam p
engembangan proyek sistem
Berikut ini adalah karakteristik dari prototipe yang efektif:
Operative . Umumnya, prototipe harus menjadi model kerja, dengan penekanan pada
bekerja . Sebuah awal yang sederhana untuk prototipe, yang disebut mock-up , ada
lah sebuah bentuk elektronik (seperti layar) yang menunjukkan antarmuka atau sis
tem terlihat tetapi tidak dapat melaksanakan suatu kegiatan. Kemudian, prototipe
yang sedang bekerja akan benar-benar melaksanakan dan menyediakan baik "tampila
n dan nuansa" karakteristik, tapi mungkin kurang beberapa fungsi.
Fokus . Untuk menguji konsep tertentu atau memverifikasi pendekatan, prototipe h
arus difokuskan pada satu tujuan. Kemampuan eksekusi asing yang bukan merupakan
bagian dari tujuan yang spesifik harus dikeluarkan. Meskipun mungkin untuk mengg
abungkan beberapa prototipe sederhana menjadi prototipe yang lebih besar.
Cepat . Pengembangan prototipe yang cepat memerlukan alat yang tepat dalam membu
at antarmuka dan perangkat lunak. Yang terpenting adalah pengembang antarmuka y
ang cepat menghasilkan prototipe diuji secara efisien.
2.5.6 Mendistribusikan dan Mengumpulkan Pertanyaan

Kuesioner memiliki penggunaan yang terbatas dan spesifik dalam pengumpulan infor
masi. Manfaat dari kuesioner adalah memungkinkan tim proyek untuk mengumpulkan i
nformasi dari sejumlah besar pemangku kepentingan atau stake holder. Kuesioner
juga membantu untuk menjawab pertanyaan-pertanyaan kuantitatif seperti "bentuk
apa yang digunakan untuk memasukkan informasi pelanggan baru?" dan, "Rata-rata,
bagaimana lama waktu yang diperlukan untuk memasukkan satu urutan standar?"
Seberapa pentingkah untuk dapat mengakses riwayat pembelian pelanggan? "adalah s
ering disebut pertanyaan-tertutup , karena mereka mengarahkan orang yang menjawa
b pertanyaan untuk memberikan respon langsung pada pertanyaan itu. Diidentifika
si sebelumnya pertanyaan, seperti "Bagaimana Anda melakukan proses ini?", Adalah
jawaban terbaik dengan menggunakan wawancara atau observasi. Pertanyaan yang me
ndorong diskusi dan elaborasi disebut pertanyaan - pertanyaan terbuka .
2.5.7 Sesi Kerjasama Prilaku Desain Aplikasi
Desain aplikasi bersama (JAD) adalah teknik yang digunakan untuk mempercepat pen
yelidikan kebutuhan sistem. Wawancara dan diskusi pendekatan normal membutuhkan
banyak waktu. Para analis pertama kali bertemu dengan pengguna, kemudian mendoku
mentasikan diskusi dengan menulis catatan dan model bangunan, kemudian meninjau
dan merevisi model. Masalah yang belum terselesaikan ditempatkan pada sebuah daf
tar dan mungkin memerlukan beberapa pertemuan tambahan dan ulasan untuk diselesa
ikan. Proses ini dapat memperpanjang dari beberapa minggu ke bulan, tergantung p
ada ukuran sistem dan ketersediaan sumber daya pengguna dan proyek tim.
Faktor penting dalam suksesnya sesi JAD adalah memiliki semua stakeholder pentin
g hadir dan tersedia untuk berkontribusi dan membuat keputusan. Para peserta yan
g sebenarnya bervariasi tergantung pada tujuan dari sesi JAD tertentu. Berikut o
rang dan kelompok mungkin terlibat:
The JAD Leader Session .
Salah satu anggota yang lebih penting dari kelompok, sesipemimpin berpengalaman
atau dilatih dalam memahami dinamika kelompok dan dalam memfasilitasi diskusi k
elompok.
Pengguna
Sebelumnya, bab ini mengidentifikasi berbagai kelas pengguna. Hal ini penting un
tuk memiliki semua pengguna sesuai dalam sesi JAD.
Staf Teknis .
Seorang wakil dari staf dukungan teknis juga harus hadir dalam sesi JAD. Selalu
ada pertanyaan dan keputusan tentang masalah teknis yang perlu dijawab.

Anggota Tim Proyek .

sistem analis dan ahli pengguna dari tim proyek harus terlibat dalam sesi JAD. P
ara anggota membantu dalam diskusi, mengklarifikasi poin, mengontrol tingkat det
ail yang diperlukan, membangun model, mendokumentasikan hasil, dan umumnya melih
at
bahwa persyaratan sistem didefinisikan untuk tingkat yang diperlukan detail.
Sesi JAD biasanya dilakukan di ruangan khusus dengan fasilitas yang mendukung. P
ertama, karena prosesnya begitu kuat, sangat penting untuk berada jauh dari gang
guan sehari-hari. Disisi lain, biasanya membantu untuk memiliki akses ke eksekut
if dan staf teknis yang tidak terlibat dalam pertemuan-pertemuan tetapi yang mun
gkin diundang dari waktu ke waktu untuk menyelesaikan kebijakan atau keputusan t
eknis. Sumber daya di ruang sesi JAD harus mencakup overhead proyektor, hitam at
au putih

papan, flip chart, dan ruang kerja yang memadai bagi peserta. Sesi JAD adalah se
si kerja, dan semua perlengkapan pekerjaan yang diperlukan harus disediakan.
Baru-baru ini, sesi JAD telah mengambil keuntungan dari dukungan elektronik untu
k meningkatkan efisiensi mereka. Analisis dan dokumentasi dapat ditingkatkan jik
a peserta memiliki laptop komputer yang terhubung dalam jaringan. Kemudian sebag
ai kebutuhan didokumentasikan dengan narasi deskripsi atau model, atau bahkan be
berapa prototipe penemuan sederhana yang dibangun, mereka dapat dibuat tersedia
untuk semua orang.
Group Support System (GSSS) , yang juga berjalan di jaringan komputer, memungkin
kan semua peserta untuk menulis komentar (anonim, jika diinginkan) dalam chat ro
om. Pendekatan ini membantu peserta yang mungkin malu dalam diskusi kelompok unt
uk menjadi lebih aktif dan berkontribusi pada keputusan kelompok. GSSS juga memu
ngkinkan tim untuk menyimpan persyaratan akhir yang dibuat. sebagai keputusan. B
iasanya sesi JAD dilakukan dengan semua orang di ruangan yang sama. Namun, GSSS
pada jaringan yang lebih luas memberikan kesempatan untuk pertemuan virtual deng
an peserta di lokasi geografis. Gambar 10 menunjukkan contoh ruang konferensi de
ngan dukungan elektronik. Sebuah ruangan mungkin tersedia di perusahaan-perusaha
an besar yang memiliki proyek-proyek pembangunan yang lebih sering berlangsung.
Ruang yang ditunjukkan pada Gambar 10 memiliki ruang kerja yang tersedia untuk m
engembangkan diagram Model dan prototipe selama sesi JAD. Ruangan ini bahkan bis
a menjadi cukup canggih Dengan dukungan komputer untuk pekerjaan kolaboratif (CS
CW). Perangkat lunak pada komputer untuk memfasilitasi komentar dan diskusi. Den
gan perangkat lunak CSCW, eksekutif tertentu bahkan bisa berpartisipasi dari lok
asi terpencil, jika perlu.

Gambar 10. Fasilitas JAD

2.5.8 Penelitian Solusi Vendor
Banyak masalah dan peluang bahwa perusahaan ingin alamat dengan sistem informasi
terbaru yang telah diselesaikan oleh perusahaan lain. Dalam banyak kasus, konsu
ltasi perusahaan memiliki pengalaman dengan masalah yang sama, dan kadang-kadang
perusahaan-perusahaan perangkat lunak sudah mempunyai solusi yang dikemas untuk
kebutuhan bisnis tertentu. Direktori seperti Sumber Data dan juga ribuan daftar
hardware, software, konsultasi, dan solusi masuk akal untuk mempelajari dan mem
anfaatkan pengetahuan yang sudah ada.
Ada tiga kontribusi positif dan satu bahaya dalam mengeksplorasi solusi yang ada
. Pertama, meneliti solusi alternatif yang akan membantu pengguna menghasilkan i
de-ide baru dalam melakukan fungsi bisnis mereka. Melihat bagaimana orang lain m
emecahkan masalah, dan menerapkan gagasan bahwa dengan budaya dan struktur organ
isasi yang ada, akan sering memberikan solusi alternatif untuk kebutuhan bisnis.
Kedua, beberapa solusi ini sangat baik dan canggih. Tanpa penelitian ini, tim pe
ngembangan dapat membuat sistem yang sudah usang bahkan sebelum dirancang.
Ketiga, lebih murah dan kurang berisiko untuk membeli solusi daripada membangunn
ya. Jika solusi memenuhi kebutuhan perusahaan dan dapat dibeli, maka itu biasany
a lebih aman, lebih cepat, dan lebih murah dalam pengirimiman.
Kesulitan pertama dalam meneliti vendor adalah mencari solusi yang dibutuhkan ol
eh bisnis. Banyak perangkat lunak dan perangkat keras perusahaan besar, seperti
Oracle, IBM, Microsoft, dan Computer Associates, memiliki sistem solusi khusus.
Ada juga direktori sistem solusi perangkat lunak, perangkat keras, dan perusahaa
n pengembang. Sumber data adalah salah satu yang paling baik. Terkadang direkto
ri ini dapat ditemukan di perpustakaan-perpustakaan teknis perusahaan, perpustak
aan kota, atau perpustakaan universitas terdekat.

Meskipun perusahaan bersaing ketat pada penjualan dan pemasaran akhir, tidak bia
sa bagi mereka saling tukar organisasi untuk menambah ilmu pengetahuan tentang s
uatu industri.
Setelah daftar penyedia yang mungkin telah dikembangkan, langkah berikutnya adal
ah untuk penelitian rinci dari setiap solusi. Sangat mudah untuk mendapatkan pen
jualan dan pemasaran sastra, tetapi lebih sulit untuk mendapatkan spesifikasi si
stem.
Sumber daya yang berguna meliputi:
(1) spesifikasi teknis
(2) demo atau sistem trial
(3) referensi dari klien yang sudah ada, yang akan membiarkan Anda mengamati sis
tem mereka,
(4) kunjungan on-site
(5) printout dari layar dan laporan.
Langkah terakhir adalah untuk meninjau rincian informasi yang diterima. Tergantu
ng pada informasi diperoleh, dapat ditinjau sendiri oleh tim proyek atau dengan
pengguna.
2.6 Memvalidasi Kebutuhan
Anda telah belajar tentang teknik pengumpulan informasi dan cara-cara untuk memp
eroleh kebutuhan dari pengguna, Anda perlu memastikan bahwa informasi yang Anda
kumpulkan adalah benar. sistem analis berpikir mereka memahami apa yang penggu
na butuhkan tetapi gagal untuk menangkap beberapa kehalusan yang sangat penting
dalam proses bisnis. Dengan kata lain dalam memilih suatu keputusan harus didasa
ri oleh pemikiran yang matang sehingga hasilnya adalah benar dan tepat. Pengujia
n dan validasi sistem persyaratan yang harus dilakukan sedini mungkin.
Pada titik ini dalam kegiatan proyek Anda, Anda telah mengumpulkan informasi ten
tang pengguna persyaratan. Anda mungkin telah mengembangkan beberapa diagram alu
r kerja. Dalam bab berikutnya, Anda
akan belajar tentang membangun model untuk menjelaskan persyaratan sistem. Semua
elemen ini harus benar-benar teruji sebelum desain aktual dan pemrograman dimul
ai. Saat menulis program komputer, programmer harus memverifikasi keakuratan kod
e dengan melakukan berbagai tes. Pelaksana program pada komputer-dengan memasukk
an input data yang tepat dan
mengamati output program komputer. Jika analis tidak dapat menguji kebutuhan dal
am jalan ini maka harus menggunakan pendekatan yang berbeda.
Berbagai teknik dapat digunakan untuk memvalidasi informasi dari pengguna dan pe
rsyaratan yang dikembangkan dari informasi tersebut. Salah satu teknik yang kuat
, disebut penelusuran terstruktur ( Structured Walkthrough ) , berguna baik untu
k memvalidasi persyaratan terhadap kebutuhan pengguna serta memverifikasi konsis
tensi internal. Penelusuran terstruktur kadang-kadang hanya disebut walkthrough
(Penelusuran) , adalah ulasan dari investigasi penemuan dan model, dibangun ber
dasarkan temuan tersebut. Sebuah walkthrough adalah dianggap terstruktur karena
analis telah diformalkan proses peninjauan ke prosedur yang ditetapkan. Tujuan w
alkthrough terstruktur adalah untuk menemukan kesalahan dan masalah. Tujuannya a
dalah untuk memastikan bahwa model yang dibuat benar.
Untuk membantu memahami pendekatan yang lebih terstruktur, bagian ini meninjau a
pa, kapan, siapa, dan bagaimana dari penelusuran terstruktur.
Salah satu tanggung jawab utama dari manajer proyek, adalah untuk menjamin kuali
tas sistem akhir. Seringkali selama kesibukan dan tekanan dari
proyek, analis sistem akan berpikir, "Pekerjaan saya adalah baik. Tidak perlu di
tinjau. "namun proses tersebut tidak dapat dilewatkan karena konsekuensinya sang
at mahal. Tidak masuk akal untuk mengecualikan tugas-tugas khusus rencana proye
k dan prosedur untuk memastikan bahwa

persyaratan lengkap dan akurat. Kelalaian seperti ini akan selalu menimbulkan ma
salah dalam proyek selanjutnya. Penelusuran terstruktur dapat dilakukan untuk me
mvalidasi informasi yang dikumpulkan. Namun, harus melakukannya untuk memvalidas
i spesifikasi model.
Apa dan Kapan
Kunci untuk penulusuran terstruktur adalah satu atau lebih analisis atau model d
esain. Mereka membuat narasi untuk menggambarkan proses, diagram alur yang menun
jukkan alur kerja, atau mendokumentasikan diagram seluruh prosedur. Biasanya, l
ebih baik untuk melakukan beberapa penelusuran 3-6 halaman dokumentasi daripada
30 halaman secara rinci. Frekuensi dari penelusuran ini tidak sama pentingnya
dengan waktu penelusuran yang dijadwalkan setelah dokumen telah dibuat.
Siapa
Dua partai utama yang terlibat dalam penelusuran adalah orang-orang yang membutu
hkan ulasan pekerjaan mereka dan ulasan kelompok. Untuk validasi yaitu, memast
ikan bahwa sistem memenuhi semua
kebutuhan dari berbagai pemangku kepentingan yang sesuai, harus dilibatkan.
Bagaimana
Seperti dalam sebuah wawancara, penelusuran terstruktur membutuhkan persiapan, p
elaksanaan, dan tindak lanjut.
Persiapan
Analis yang karyanya sedang ditinjau, mempersiapkan materi untuk diperiksa. Sela
njutnya, ia mengidentifikasi peserta yang tepat dan memberikan mereka salinan ma
teri. Akhirnya, Jadwal waktu dan tempat analis untuk penelusuran dan memberitahu
semua peserta.
Eksekusi
Selama penelusuran, analis menyajikan materi poin demi poin. Jika itu adalah dia
gram atau flowchart, maka berjalan melalui aliran, dan menjelaskan setiap kompon
en. Salah satu teknik yang efektif
adalah untuk mendefinisikan kasus, uji sampel dan proses itu melalui aliran yang
telah didefinisikam.
Follow-Up
Tindak lanjut terdiri dari koreksi. Jika bahan terakhir memiliki kesalahan dan m
asalah yang besar, sebuah penelusuran tambahan mungkin diperlukan. Jika tidak, k
oreksi dibuat, dan proyek terus melanjutkan ke kegiatan berikutnya.
Gambar 4-19 adalah bentuk tinjauan sampel yang digunakan dalam salah satu sesi u
lasan di Rocky Gunung Outfitters untuk komisi dan aturan penjualan. Tidak menamp
ilkan beberapa lembar termasuk beberapa diagram alur prosedur. Materi terakhir
dalam hal ini adalah
hanya daftar aturan bisnis untuk tingkat komisi. Karena aturan bisnis komisi pen
jualan sangat penting, dan para manajer
membuat kebijakan keputusan tentang komisi, pilihan yang jelas untuk meninjau at
uran sebagaimana terungkap dalam diskusi dan sesi wawancara.
Dalam walkthrough terstruktur, memiliki tindakan nonpartisipan sebagai pustakawa
n

II. PENUTUP

3.1 Kesimpulan
Ada enam kegiatan utama analisis sistem:
Mengumpulkan informasi.
Mendefinisikan Kebutuhan sistem.
Prioritaskan persyaratan.
Prototype untuk kelayakan dan penemuan.
Menghasilkan dan mengevaluasi alternatif.
rekomendasi Ulasan dengan manajemen.
Umumnya kita membagi persyaratan sistem ke dalam dua kategori: kebutuhan fungsio
nal dan nonfungsional.
Persyaratan fungsional adalah mereka yang menjelaskan fungsi-fungsi bisnis dasar
bahwa sistem baru harus mendukung.
Persyaratan nonfungsional melibatkan tujuan dari sistem teknologi, performa, keg
unaan, kehandalan, dan keamanan.
Model berguna untuk menentukan persyaratan dan desain. Ada tiga jenis model dala
m investigasi ini yaitu:
Matematika
Deskriptif
Grafis
Untuk menemukan persyaratan, analis harus bekerja dengan berbagai pemangku kepen
tingan dalam sistem baru. Pemangku kepentingan atau stakeholder:
Pengguna, mereka yang benar-benar akan menggunakan sistem untuk pekerjaan sehari
-hari
Klien, mereka yang membayar dan yang akan memiliki sistem
Staf teknis, orang-orang yang harus memastikan bahwa sistem beroperasi dalam lin
gkungan komputasi organisasi.
Tiga tema utama informasi harus dikejar:
Apakah proses bisnis dan operasi?
Bagaimana proses bisnis dilakukan?
Apakah persyaratan informasi?
Analis menggunakan tujuh teknik utama untuk mengumpulkan informasi ini, dan sala
h satu teknik untuk memastikan kebenarannya.
Ketujuh teknik fakta adalah sebagai berikut:
Laporan Ulasan yang ada, bentuk, dan deskripsi prosedur.
Melakukan wawancara dan diskusi dengan pengguna.
Amati dan proses bisnis dokumen.

Membangun prototipe.
Mendistribusikan dan mengumpulkan kuesioner.
Melakukan sesi JAD.
solusi vendor Research.
Ide dasar dari prototipe adalah pada awalan, model kerja yang lebih besar, entit
as yang lebih kompleks. Tujuan utama dari prototipe adalah memiliki model kerja
yang akan menguji konsep atau memverifikasi pendekatan. Penemuan prototipe diban
gun untuk menetapkan kebutuhan tetapi biasanya tidak digunakan untuk pemrograman
final.
Desain aplikasi bersama adalah teknik yang digunakan untuk mempercepat penyelidi
kan kebutuhan sistem dengan mengadakan beberapa sesi maraton
dengan semua peserta yang kritis atau teliti. Hasil diskusi dalam persyaratan ak
an dimemberikan keputusan dengan bijaksana, tanpa penundaan wawancara
kelompok yang terpisah dan mencoba untuk menyatukan perbedaan. Ketika dilakukan
dengan benar, JAD adalah teknik yang kuat dan efektif.
Tinjauan teknik untuk memastikan analisis yang akurat dan lengkap disebut penelu
suran terstruktur. Ingat bahwa penelusuran terstruktur memiliki tjuan untuk meni
njau dan memperbaiki pekerjaan. Dan Ini bukan ulasan dari kinerja.

DAFTAR PUSTAKA

Satzinger, John W. Robert Jackson. and Stephen D. Burd. 2007. Systems analysis a
nd design in a changing world, Fourth Edition . Thomson Course Technology, Bosto
n,Massachusetts. Canada.
Satzinger, John W. Robert Jackson. and Stephen D. Burd. 2009. Systems analysis a
nd design in a changing world, Five Edition . Course Technology, Cengage Learnin
g, Boston, Massachusetts. Canada.