Requirement Determination

SDLC adalah proses pembuatan systems yang memindahkan keadaan sistem yang sekarang ke sistem yang
diharapkan. Output dari perencanaan adalah system request yang berisi penjelasan umum mengenai
sistem yang akan datang, cakupan project, dan menyediakan rencana kerja. Tahapan analisis mengolah
system request menjadi requirements definition, functional models, structural models, dan behavioral
models yang akan menjadi bagian dari system proposal. System proposal berisi project management
deliverables seperti feasibility analysis dan rencana kerja.

System proposal akan diserahkan kepada komite yang akan menilainya. Komite akan menentukan
apakah proposal akan diteruskan atau tidak. Walkthrough terhadap proposal dilakukan secara
terperinci, yang tujuannya adalh para pengguna, manajer, dan pengambil keputusan utama dapat
memahaminya secara jelas, dapat mengidentifikasi perbaikan, dan dapat membuat keputusan apakah
project harus dilanjutkan atau tidak. Jika disetujui, system proposal akan bergerak kedalam tahapan
design, dan requirements definition, functional models, structural models, and behavioral models akan
menjadi dasar/sebagai input didalam tahapan perancangan.

Garis antara perancangan dan analisis bersifat remang-remang. Karena deliverables yang dibuat pada saat
analysis merupakan tahap awal dari perancangan sistem yang baru. Banyak pengambilan keputusan yang
berhubungan dengan perancangan ditemukan pada saat analysis. Yang harus diingat adalah ada
sebagian kecil tahapan sudah dilakukan pada tahap ini.

Requirement determination adalah langkah yang paling kritis dari SDLC, karena element dasar dari
sistem harus ditentukan pada tahapan ini. Banyak penelitian yang menyebutkan bahwa kegagalan
terjadi karena penentuan requirements. Karena itu salah satu bagian dari pendekatan Objek Oriented
adalah iterative.
Tujuan dari requirement determination adalah untuk merubah business requirement yang
terdapat pada system request menjadi daftar yang lebih jelas dari requirement yang dapat
digunakan sebagai input untuk analysis (membuat functional models, structural models, and
behavioral models).

Pengertian Requirement
Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa yang
harus dimiliki:

1. Didalam tahapan analisis requirement ditulis dari sudut pandang business, atau apa yang
dilakukan oleh sistem. Fokusnya ada pada "WHAT". Fokusnya ada pada user needs,
sehingga biasanya disebut business requirements.

2. Selanjutnya didalam tahapan design, business requirement bergerak menjadi lebih teknis,
 dan akan menjelaskan bagaimana (HOW) sistem akan diimplementasikan. Requirement
pada saat design dilihat dari sudut pandang pembuat sistem (developer).

Yang harus diperhatikan bahwa pembatas antara analisis dan perancangan remang-remang.
Beberapa pihak menggunakan istilah tersebut secara bolak-balik. Yang harus diperhatikan,
requirement adalah pernyataan apa yang harus dilakukan oleh sistem dan selalu ada kemungkinan
untuk berubah. Secara umum requirement terbagi dua yaitu:

1. Functional requirement. Requirement ini berelasi langsung dengan dengan proses yang
harus dilakukan oleh sistem yang akan dibuat sehingga dapat menyediakan informasi
yang diperlukan. Functional requirement mengalir langsung kedalam tahapan analisis
selanjutnya, karena mendefinisikan fungsi-fungsi yang harus dimiliki oleh sistem.
Perhatikanlah Gambar 1 mengenai Functional Requirements

2. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral properties

yang harus dimiliki oleh sistem, seperti performance and usability. menjelaskan
bermacam-macam karakteristik sistem : operational, performance, secutiry, cultural and
political. Karakteristik tersebut tidak menjelaskan business process ataupun informasi
yang diperlukannya, tetapi sangat penting untuk dapat memahami apa yang harus dimiliki
oleh sistem final. Perhatikanlah Gambar 2 mengenai Nonfunctinal Requirements.

Gambar 1. Contoh Functional Requirement

 Gambar 2 Contoh Non Functional Requirement

Requirement Definition
Requirement definition report biasanya hanya disebut requirement definition adalah text report
yang berisi daftar functional dan nonfunctinal requirement dalam bentuk outline. Daftarnya
dibuat secara berurut dan diberi nomer supaya jelas, Sebagaimana digambarkan pada gambar 1 dan
gambar 2 requirement dibuat daftarnya. Selanjutnya dibuatkan prioritasnya. Tujuan terpenting
dari requirement determination adalah menentukan tahapan dari sistem. Kalau ada kebingunan,
dokumen bertindak sebagai alat klarifikasi.

Determining Requirements
Di dalam menentukan requirement diperlukan pemahaman business dan IT. Hal ini bisa
dianalogikan seperti membuat bangunan. Jika kita pemilik rumah, maka kita tahu apa yang kita
inginkan dari rumah kita, tetapi kita tidak akan dapat membuat rancangan rumah. Demikan juga
dengan seorang ahli bangunan sipil atau arsitek tidak akan dapat menentukan bentuk bangunan
dengan baik meskipun memiliki kemampuan teknis untuk dapat menggambarkannya jika tidak
berkomunikasi dengan orang yang akan menggunakan bangunan tersebut. Karena pendekatan
terbaik adalah mempekerjakan ahli business dan IT bersama-sama untuk membuat analisa
sistem. Kadang kala pengguna tidak tahu secara tepat apa yang diinginkannya maka analis akan
membantunya dengan teknik/perangkat/notasi dan pemahaman yang dimilikinya. Teknik yang
populer untuk melakukan analisis adalah:

• Business process Automation.

• Business Process Improvement.

• Business Process Reengineering.

Ketiga teknik yang disebutkan di atas memiliki cara kerja yang sama yaitu :

• Membantu user untuk menjelaskan sistem dan proses yang sekarang (as-is).
• Identifikasi apa yang akan dirubah.
• Membuat konsep untuk sistem yang baru.

Membuat Requirement Definition

Requirement definition haruslah dibuat mutakhir karena akan digunakan untuk referensi dan
pemahaman sistem yang akan dibuat. Membuat Requirement Definition sifatnya itterative dan
berkesinambungan yang meliputi:

1. Mengumpulkan informasi dengan teknik yang diperlukan (interviews, document analysis,

dan lain-lain

2. Mengolah informasi untuk mengidentifikasi business requirement untuk sistem yang

akan dibuat.

3. Menambahakan requirements ke dalam requirement definition report yang akan

digunakan untuk menentukan pekerjaan.

Untuk membuat requirement definition, project team harus menentukan jenis-jenis dari
functional dan nonfunctional requirement dari sistem yang akan dibuat. Penentuan requirements
tersebut menjadi bagian utama dari dokumen yang akan dibuat. Selanjutnya analis akan
menggunakan bermacam-macam teknik untuk menentukan requirement seperti interview dan
observation untuk untuk mengumpulkan informasi, dan membuat daftar business requirement
yang teridentifikasi dari informasi diatas. Dan akhirnya bersama-sama dengan dengan seluruh
tim dan user akan melakukan:

1. Verifikasi

2. Perubahan

3. Melengkapi

4. Menentukan prioritas dari requirement.

Process akan berkesinambungan, dan requirement akan berevolusi, jika requirement sudah
teridentifikasi dengan baik maka pekerjaan akan bergerak ke tahapan selanjutnya dari SDLC.
EVOLUTION OF REQUIREMENT harus secara hati-hati dikelola karena jika tidak akan ada
proliferasi requirment yang tak terkendali. Sehingga akan menyebabkan sistem tidak pernah
selesai dan selalu tumbuh diluar cakupan sistem. Ketika requirement mencerminkan kebutuhan
business di dunia nyata dan bukan didalam sistem yang sekarang dibuat maka dimasukkan ke
dalam requirement dimasa yang akan datang dan diberi nomor prioritas yang lebih rendah.
Pengelolaan requirement (dan cakupan dari sistem yang akan dibuat) merupakan bagian yang
paling berat dari pembuatan sistem.

Requirements Analysis Techniques.

Sebelum project team dapat menentukan requirement apa yang tepat untuk sistem yang akan
dibuat, mereka harus memiliki visi yang jelas sistem apa yang akan dibuat, dan tingkat
perubahan apa yang akan terjadi pada organisasi. Proses dasar analisis terbagi menjadi tiga
tahapan :

1. Mamahami sistem yang sekarang

2. Mengidentifikasi peningkatan

3. Membuat/mengumpulkan requirement untuk sistem yang akan dibuat.

Kadang-kadang langkah yang pertama dilewati jika tidak ada sistem yang ada atau hanya
dilakukan sepintas pada methodology seperti RAD dan Agile. Sedangkan pada metodologi
seperti waterfall dan pararel development menggunakan waktu yang cukup panjang untuk
menganalisa sistem yang sudah ada dan mengidentifikasi perbaikan yang mungkin dilakukan
sebelum mealukan requirement gathering. Sementara itu metodologi yang berfokus pada
peningkatan dan requirement system yang akan dibuat akan melakukan investigasi terhadap
sistem yang sekarang berjalan secara sepintas saja. Metodologi tersebut adalah :

1. Generasi baru RAD

2. Agile

3. OO methodologies

4. phased development

5. prototyping

6. throwaway prototyping

7. XP

Ada tiga tehnik yang digunakan sebagaimana disebutkan diatas yaitu Business process
Automation, Business Process Improvement, dan Business Process Reengineering. Ketiga tehnik
tersebut membantu analis melakukan analisa sehingga visi dari sistem dapat dikembangkan
dengan baik. Tehnik Requirement analysis yang disebutkan diatas akan digunakan bersama-sama
dengan requirement-gathering techniques yang meliputi:

1. Interviews

2. JAD Session

3. questionaires

4. document analysis

5. observation.

Requirement analysis techniques akan menentukan jenis informasi apa yang akan dikumpulkan
dan bagaimana analisanya. Kedua jenis tehnik tersebut bersifat komplementer. Pilihan tehniknya
akan menentukan bentuk perubahan yang akan terjadi di dalam organisasi :

1. BPA digunakan untuk menangani perubahan kecil yang berhubungan dengan otomasi
proses.

2. BPI digunakan untuk melakukan perbaikan proses untuk memperbaiki efektifitas dan
efisiensi kerja

3. BPR merubah bagaimana cara organisasi bekerja sehingga yang terjadi adalah
transformasi organisasi ke bentuk yang lebih baik.

Untuk menggerakkan pengguna menggunakan sistem yang baru analis harus memiliki
kemampuan berpikir kritis yang tingi. Kemampuan berpikir kritis adalah kemampuan untuk
memahami strengths dan weaknesses dan membentuk kembali ide yang sudah ada menjadi
bentuk yang lebih baik sehingga. Ide tersebut digunakan untuk memahami issues dan
mengembangkan business process yang baru. Kemampuan ini diperlukan untuk mempelajari:

1. Hasil dari requirements gathering

2. Identifikasi business requirement

3. Menterjemahkan requirements menjadi sistem yang baru.

Business Process Automation

BPA artinya tetap menggunakan cara bagaimana organisasi bekerja, tetapi menggunakan
teknologi komputasi untuk mengerjakan beberapa pekerjaan yang harus dilakukan. BPA dapat
membuat organisasi bekerja lebih effisien tetapi mempunya pengaruh yang lebih kecil
dibandingkan dengan ketiga tehnik tersebut diatas. BPA akan mempelajari sistem yang sedang
berjalan dengan seksama dan pada akhirnya akan memperbaiki system requirements yang dibuat.
Problem analysis dan Root Cause Analysis adalah 2 cara BPA yang cukup populer:

1. Problem Analysis. Adalah cara langsung requirement analysis. Problem analysis artinya
bertanya kepada user dan managers untuk melakukan identifikasi problem dengan sistem
yang sekarang sudah ada dan menjelaskan penyelesaian permasalahan yang terjadi
didalam sistem. Hampir semua pengguna sistem memiliki ide bagaimana perbaikan
dilakukan. Perbaikan proses dari problem analysis biasanya sedikit dan bersifat
incremental. Jenis pebaikan ini biasanya efektif untuk memperbaiki efisiensi sistem.
Tetapi basanya monetary benefits yang diperoleh tidak besar. Yang jelas adalah perbaikan
dari sistem yang sudah ada.

2. Root Cause Analys. Problem analysis bekerja berdasarkan asumsi yang bisa saja valid
atau tidak valid. Umumnya orang selalu membuat kesimpulan sebelum melakukan
pemikiran mengenai sebab dan akibat. Biasanya kesimpulan atau tindakan yang akan
dilakukan adalah mengobati gejala bukan akar permasalahannya. Didalam dunia nyata
permasalahn untuk perbaikan proses adalah dengan menggunakan root cause. Pemecahan
bisa jadi mengobati gejala, bisa juga akar permasalahan. , tetapi yang jelas tanpa analisa
yang mendalam akan sulit untuk memecahkan permasalahan dan menentukan mana yang
gejala dan mana yang akar permasalahan. Root cause analysis berfokus pada masalah
bukan pada pemecahan masalah.

Business Process Improvement

BPI artinya membuat perubahan moderat dari cara bagaimana organisasi beroperasi, dengan melihat
bagaimana organisasi beroperasi untuk memanfaatkan teknologi yang baru atau apa yang dilakukan oleh
kompetitor. Tujuan dati BPI adalah meningkatkan efisiensi (doing thighs right) dan meningkatkan
efektifitas (doing the right things). Focus BPI adalah meningkatkan business process, sehingga
mempelajari business process yang ada sangat diperlukan untuk perbaikan proses dan membuat sistem
requirement yang baru. BPI menggunakan Duration analysis, activity based-costing, dan information
benchmarking.

1. Duration Analysis memerlukan pembelajaran secara detail proses yang dilakukan didalam sistem
yang sekarang berjalan. Analisis dimulai dengan melihat waktu yang diperlukan secara rata-rata
 untuk melakukan business process guna menghasilkan output tertentu. Lalu menghitung waktu
yang diperlukan untuk menyelesaikan setiap pekerjaan/bagian proses didalam business sehari-hari.
Waktu yang diperlukan untuk mengerjakan suatu bagian pekerjaan kemudian ditotal.
Selanjutnya akan diketahui persentase dari pekerjaan tersebut secara keseluruhan. Dari
perbandingan akan dapat dicari permasalahannya dimana. Karena total dari masing-masing
subproses bisa jadi lebih kecil dari waktu yang diperlukan untuk menyelesaikan pekerjaan.
Permasalahan ini terjadi karena:
1. Fragmentasi sub-process tidak baik.
2. Process integration/parrarelization.

2. Activity-Based Costing sama dengan analisa biaya dari setiap sub aktifitas. Jika ternyata biaya
untuk menyelesaikan pekerjaan lebih besar dari biaya untuk melaksanakan seluruh sub proses
maka proses tidak dikelola dengan baik.
3. Informal Benchmarking. Benchmarking artinya membandingkan bagaimana organisasi lain
melakukan business process agar organisasi dapat bekerja dengan lebih baik. Benchmarking
tujuannya adalah agar dapat memperkenalkan idea bahwa karyawan dapat bekerja dengan lebih
baik dengan cara yang baru yang sebelumnya tidak pernah terbayangkan. Informal Benchmarking
adalah istilah dimana karyawan perusahaan berkunjung sebagai customer untuk perusahaan lain.
Misalkan membuat web site untuk universitas, maka team akan melihat web site
bermacam-macam universitas untuk membandingkan apa yang dilakukan.

Business Process Reengineering

Business Process Reenginering (BPR) artinya merubah cara bagaimana organisasi beroperasi,
yaitu merubah cara bagaimana menjalankan business dan membuat perubahan besar karena
danya ide dan teknologi yang baru. Adapun tehnik yang digunakan didalam BPR adalah :

1. Outcome Analysis yang berfocus pada pemahaman dari produk yang memberikan nilai
yang lebih baik kepada customer.

2. Technology Analysis yang tujuannya adalah untuk menerapkan bagaimana analis dan
manager untuk membuat list/daftar teknologi apa saja yang akan dibuat atau
dimanfaatkan, untuk selanjutnya menentukan apa yang akan diterapkan didalam business
process.

3. Activity Elimination. Activity elimination adalah menghilangkan aktifitas yang kurang

 produktif dan menggantikannya dengan aktifitas yang produktif.

Pemilihan Teknik yang Tepat

Untuk dapat melakukan pemilihan teknik atau mencampur teknik yang tepat perlu diperhatikan
strength dan weakness dari:

1. Potential Business Value. Nilai tambah yang dihasilkan oleh tehnik yang dipilih.

2. Project Cost. Biaya yang ditimbulkan dari tehnik yang dipilih.

3. Breadth of Analysis. Cakupan analisis yang apakah analisis meliputi :

1. business process dalam satu fungsi business

2. process yang menjangkau seluruh organisasi

3. process yang berinteraksi dengan seluruh customer dan organisasi.

4. Risk. Resiko kegagalan, yang diakibatkan oleh rancangan yang tidak baik, kebutuhan
yang tidak terpenuhi atau perubahan radikal yang tidak dapat ditangani oleh organisasi,
sehinga resikonya menjadi semakin besar.

Selanjutnya perhatikanlah matriks pemilihan tehnik pada gambar 3 mengenai Strategi dari
analisa proses bisnis.

Gambar 3 Karakteristik dari Stategi Analisa Proses.

Daftar Pustaka

Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992

Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified
Process, Course Technology, 2005

Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006

Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002