TAHAP
ANALISIS
Berdasarkan hasil studi literature, maka ada
beberapa hal yang bisa disimpulkan. Proses pembuatan software secara umum ada 4
tahap yaitu perencanaan, analisis, perancangan, dan impelementasi.
Perencanaan terutama mengenai permintaan pembuatan
sistem dari stakeholder/bisnis yang membutuhkan. Lalu dibuat semacam timeline
dan juga budget untuk pembuatan sistem ini.
Setelah adanya perencanaan, maka dijalankan proses
analisis. Kegiatan utama dalam proses analisis ini adalah mendefinisikan dan
mengklarifikasikan kebutuhan-kebutuhan (requirements).
Kegiatan utama proses analisis :
- mendefinisikan sistem berjalan (the as-is
system)
- mengindentifikasikan kemajuan (improvement) jika
menggunakan sistem baru
- mendefinisikan kebutuhan-kebutuhan dari sistem
yang akan dibuat (the to-be system)
Pada metode SDLC tradisional, seperti waterfall
atau pararel, kegiatan proses analisis ini lebih dijalankan setiap tahapnya,
sedangkan di metode SDLC yang baru seperti RAD atau Agile, proses pendefinisian
sistem berjalan tidak dikerjakan secara maksimal, lebih terfokus pada sistem
baru yang akan dibuat. Keberhasilan dari proses analisis ini sangat terpengaruh
oleh kemampuan dari System Analyst yang melakukan analisis.
DEFINISI KEBUTUHAN
(REQUIREMENTS)
Requirements
determination (penentuan kebutuhan) dilakukan untuk mentransformasi
permintaan system dari pernyataan tingkat tinggi kebutuhan-kebutuhan bisnis
menjadi langkah terperinci, yaitu daftar yang tepat mengenai apa harus
disediakan oleh sistem baru sehingga meningkatkan nilai dari bisnis itu
sendiri. (Roth, p. 104)
Kebutuhan-kebutuhan ini secara sistematis akan
didukung, diklarifikasi dan dikonfirmasi dengan cara membuat use-case,
membangun process-model dan data-model yang kemudian akan digunakan pada tahap
perancangan selanjutnya.
Kebutuhan-kebutuhan sendiri ada 5 (lima) kategori
yaitu :
- Kebutuhan
bisnis (business requirements)
- Kebutuhan
pengguna (user requirements)
- Kebutuhan
fungsional sistem (functional requirements)
- Karakteristik
sistem yang dibutuhkan (nonfunctional requirements)
- Bagaimana
sistem dibangun (system requirements)
Dari 5 kategori diatas, untuk mendefinisikannya pun
dimulai dari kegiatan pertama yaitu kebutuhan bisnis, kebutuhan ini
didefiniskan biasanya sudah dari awal perencanaan. Ketika tahap perencanaan
ketika sistem diminta dibuat oleh bisnis, maka terdapat permintaan bisnis
terhadap sistem, dari situ akan diturunkan menjadi kebutuhan-kebutuhan bisnis.
Untuk mencapai kebutuhan-kebutuhan bisnis yang
diharapkan, maka ada tugas,pekerjaan,proses ataupun aktivitas yang dilakukan
oleh pengguna bisnis (business user). Karena pemikiran tersebut, maka jika
sistem bisa memenuhi kebutuhan user, maka kebutuhan bisnis ini akan terpenuhi
(Roth, p. 105).
Menurut Roth pada halaman 105 paragraf ke-2 kalimat
ke-2.
“A good starting place is to
concentrate on what the user actually needs to accomplish with the system in
order to fullfill user needed job or task. ... (end of paragrah)... By
understanding what the user needs to do in terms of tasks to perform, the
analyst can then determine ways in which the new system can support the user’s
needs.”
Lalu untuk mendenisikan kebutuhan user ini,
didefinisikanlah use-case. Dengan use-case maka sistem berjalan bisa
digambarkan dan juga bisa didefinisikan bagaimana sistem baru berjalan sesuai
dengan kebutuhan dari user. Setelah use-case didefinisikan dan kebutuhan user
ter-indenfitikasi, maka bisa dilihat kebutuhan fungsional dari sistem yang akan
dibuat.
Menurut Roth pada halaman 105 paragraf 3 kalimat 2,
“A functional requirement relates
directly to a process the system has to perform as a part of supporting a user
task, and/or information it needs to provide as the user is performing is
performing a task.”
Functional Requirements ini bisa dilihat dari dua sudut
pandang, object-orinted atau information-oriented. Functional Requirements ini
akan lebih didefinisikan secara rinci dengan menggunakan Process-Model. Process
Models digunakan untuk menjelaskan hubungan proses fungsi dengan pengguna
sistem, bagaiaman fungsi/proses berhubungan satu dengan lainnya, bagaimana data
di masukan dan dihasilkan oleh fungsi/proses, dan bagaimana fungsi/proses
dibuat dan mengguna data yang disimpan.
Process Model mengklarifikasi komponen S/W yang
dibutuhkan untuk memenuhi kebutuhan fungsional dimana kebutuhan fungsional ini
dimulai dengan mendefinisikan data yang harus di track agar tugas pengguna bisa
diselesaikan. Komponen data ini akan didefinisikan pada Data Model.
Kebutuhan pengguna dan kebutuhan fungsional akan
digunakan pada fase design/perancangan. Kebutuhan pada fase design yang dilihat
dari sudut pandang developer akan disebut sebagai System Requirements.
Sedangkan untuk Nonfunctional Requirements
contohnya sistem bisa diakses secara mobile. Nonfunctional Requirements
digunakan pada fase design ketika ingin memutuskan user interface, the h/w and
s/w, dan arsitektur sistem. Bidang2 yang termasuk nonfunctional : operational,
performance, security, and cultural and political.
Berdasarkan penelitian Standish Group alasan utama
proyek TI gagal adalah kurangnya partisipasi dari pegguna. Tapi di sisi yang
lain, pengguna bisnis mungkin tidak semuanya menyadari adanya
kesempatan-kesempatan yang bisa ditawarkan teknologi terbaru untuk
menyelesaikan kebutuhan bisnisnya. Makanya sangat perlu adanya sebuah kerjasama
tim antara pengembang dan juga stakeholder dari sistem yang akan dibangun.
Ada 5 teknik yang paling umum digunakan untuk mendapatkan dan
mendifinisikan kebutuhan-kebutuhan yaitu :
- Wawancara
- Sesi JAD (Joint Application Development)
- Kuesioner
- Analisis Dokumen
- Observasi
Kesimpulan
dari beberapa teknik di atas adalah pentingnya pemilihan orang untuk
dilakukan analisis, sangat tergantung dengan sumber daya manusia, baik dari sisi
system analyst, maupun dari perusahaan/stakeholder bisnis yang membutuhkan
sistem.
STRATEGI
ANALISIS KEBUTUHAN
Ada 9 strategi untuk melakukan analisis
kebutuhan :
- Analisis
Masalah
- Analisis
Penyembab Utama (Root Cause)
- Analisis
Durasi
Analisis ini
akan meneliti berapa lama waktu yang dibutuhkan ketika menjalankan sistem yang
berjalan. Pada analisis ini, seorang
analis harus mengkakulasi dan membandingkannya dengan praktikal terbaik (best
practice), apakah ada rentang waktu yang terlalu lama dengan yang diharapkan.
Jika ya maka akan butuh sekali perubahan besar dalam proses kerja di sistem
yang akan dibuat untuk mempercepat waktu penyelesaian sistem. Yang bisa
dikerjakan adalah pengintegrasian proses atau membuat proses menjadi pararel.
- Acitivity-Based
Costing
- Informal
Benchmarking
- Outcome
Analysis
- Technology
Analysis
- Activity
Elimination
Pada analisis
ini, manager dan system analyst akan bekerjasama meng-indentifikasikan
bagaimana organisasi dapat menghapus beberapa aktivitas bisnis, bagaimana
fungsi tersebut bisa berjalan tanpa aktivitas tersebut, dan apa resiko yang
mungkin muncul karenanya.
- Comparing
Analysis Strategies
USE-CASE DAN
DFD
DFD dibuat berdasarkan Use-Case yang sudah
di-indentifikasi dan didefinisikan. Sedangkan use-case adalah cara menggambarkan
user-requirements dari sistem yang akan dibuat. Karena menurut Roth, kunci dari
berhasilnya memenuhi kebutuhan bisnis adalah memenuhi kebutuhan pengguna dalam
menjalankan tugas-tugasnnya, karena sebagai pengembang diharapkan bisa membuat
sistem yang berguna dan bisa digunakan, oleh sebab itu perlu adanya analisis
dari user-requirements.
Namun menurut Roth juga, secara tradisional cara
mendapatkan kebutuhan adalah dengan menanyakan ke pengguna apa yang mereka mau
kerjakan dan dikerjakan oleh sistem yang baru. Hal ini sangat menantang bagi
pengguna karena :
- Pengguna
tidak tahu apa yang bisa ataupun yang tidak bisa dikerjakan oleh sistem.
Ketidak-mengertian user mengenai kemanjuan teknologi dan kapabilitas serta
limitasi dari sebuah sistem informasi
- Pengguna
juga akan kesulitan bagaimana caranya untuk mengubah bisnis proses yang sudah
berjalan.
- Banyak
pengguna mendeskripsikan hal-hal yang mereka mau pada sistem baru, bukan
kebutuhan yang dibutuhkan secara nyata pada sistem baru.
- Pengguna
mengalami kesulitan membaca process ataupun data-modelling yang dibuat oleh
system analyst.
Oleh karena hal-hal tersebut, konsep dari use-case
sendiri terlah ber-evolusi menjadi sebuah komponen penting ketika mementukan
kebutuhan-kebutuhan untuk sistem baru. Use case sangat berharga untuk aplikasi
sistem bisnis dan websites, use-case tidak berguna untuk batch processes,
aplikasi perhitungan intensif, atau
data-warehousing.
KESIMPULAN
SEMENTARA
Dari studi literature yang saya baca ini, saya
masih menangkap hal-hal sebagai berikut :
- User requirements masih diletakan pada tahapan
ke-2 dalam menentukan kebutuhan sesudah mendapatkan kebutuhan bisnis, karena
dianggap untuk memenuhi kebutuhan bisnis, semua aktivitas akan dikerjakan oleh
penggunanya. Jadi kebutuhan pengguna masih merupakan kunci dari penentuan
kebutuhan.
- Pada strategi analisis, sudah diberikan adanya
strategi analisis durasi, activity elimination, dan outcome analysis, jadi
secara strategi nya pun seharusnya sudah memperhatikan masalah meng-efesien-kan
proses kerja yang ada
- Pada proses peng-indentifikasian use-case juga
sudah ada dan disadari beberapa kelemahan dari cara tradisional mendapatkan
kebutuhan pengguna
- Sangat disadari bahwa jika kondisi seperti ini,
maka diperlukan keahlian dan kematangan dari seorang system analyst untuk
menentukan keberhasilan dari sebuah proyek IT dan juga semakin literate
pengguna bisnis terhadap teknologi informasi, maka semakin menentukan besarnya
keberhasilan. (Masih sangat tergantung dengan sumber daya manusia dalam analisisnya)
Hal-hal yang masih bisa dikritisi :
- Melakukan
perubahan pada metode analisis agar dapat mengeleminasi kelemahan pada pengguna
bisnis (business users) dalam proses penentapan kebutuhan ?
- Melakukan
modifikasi pada model use case ?
- Menambahkan
process requirements ?
- Melakukan
eksperimen mengapa dengan teori seperti ini tapi ternyata di lapangan tidak
bisa digunakan ?