Matakuliah

Proyek Pengembangan Sistem Informasi

Deskripsi Singkat Mata Kuliah
Kuliah Proyek Penembangan Sistem Informasi mengajarkan mahasiswa agar mampu
melakukan perencanaan dan melakukan analisis kebutuhan dan persyaratan,
mendefinisikan persyaratan sistem secara detail, mendisain Arsitekture Produk Sistem
Informasi, menyusun Dokumentasi Sistem, membangun sisten dengan pemrograman
yang sesuai dan disepakati/disetujui, melakukan pengujian system, menyusun
panduan penggunaan aplikasi dan menentukan strategi implementasi yang akan
digunakan
Materi Pembelajaran/Pokok Bahasan
Requierment Determination
Kemampuan Akhir yang Diharapkan
Mampu melakukan analisa persyaratan sistem, alur sistem usulan, penentuan platform
program dan SRS Memahami siklus pengembangan
Indikator
 Definisi Persyaratan
 Analisa Persyaratan Sistem
 Alur Sistem Usulan
 Penentuan Platform Program
 Software Requirement Specification (SRS)
Kriteria & Bentuk Penilaian
Mahasiswa mampu melakukan analisa persyaratan sistem, alur sistem usulan, penentuan
platform program dan SRS
 Requierment 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, and 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 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 dari
pendekatan OO adalah iterative. Selanjutnya akan dijelasakan apakah yang dimaksud dengan
requirement determination yang menjadi tahapan dari analisa sistem.
Requirement Determination
a. Tujuan dari requirement determination
Tujuan dari requirement determination adalah untuk merubah very hight level explanation of the
business requirement menjadi daftar yang lebih jelas dari requirement yang dapat digunakan sebagai
input untuk analysis (membuat , functional models, structural mod els, and behavioral models).
b. 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 adalah requirement adalah pernyataan apa yang harus dilakukan oleh
sistem dan selalu da 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.
 Gambar 1: Functinal Requirements
2. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral properties yang
harus dimiliki oleh sistem, seperti performance and usability. Nonfunctional requirement
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 dpat memahami apa yang harus dimiliki oleh sistem
final. Perhatikanlah Gambar 2 mengenai Nonfunctinal Requirements.

Gambar 2: Nonfunctinal Requirements

c. 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.

d. Determining Requirements
Didalam menentukanUntuk menentukan requirement diperlukan pemahaman business dan IT.
Hal ini bisa dianalogikan seperti membuat bangunan. Jika kita pemilik tumah, maka kita tahu apa yang
kita inginkan dari rumah kita, tetapi kita tidak akan dapat membuatrancangan 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.
e. Membuat Reqirement 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. Melakukan informasi untuk mengidentifikasi business requirement untuk sistem yang akan dibuat.
3. Menambahakan requirements kedalam requirement definition reportyang 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 ak hirnya 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 kebuatuhan business di dunia nyata dan bukan
didalam sistem yang sekarang dibuat maka dimasukkan kedalam requirement dimasa yang akan datang
dan diberi nomor prioritas yang lebih rendem. Pengelolaan requirement (dan cakupan dari sistem yang
akan dibuat) merupakan bagian yang paling berat dari pembuatan sistem.
f. 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
waterfamm 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 idea yang sudah ada menjadi bentuk yang lebih baik
sehingga. Idea 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.

g. 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 ya ng dibuat. Problem analysis dan Root Cause
Analysis adalah 2 cara BPA yang cukup ngetop :
1. Problem Analysis. Adalah cara langsung requirment analysis. Problem analysis artinya bertanya
kepada user dan managers untuk melakukan identifikasi problem dengan s istem 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
3. 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.

h. 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 :
a. Fragmentasi sub-process tidak baik.
b. 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.

i. 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
4. 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 :
a. business process dalam satu fungsi business
b. process yang menjangkau seluruh organisasi
c. process yang berinteraksi dengan seluruh customer dan organisasi.
4. RiskResiko 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