Topik 3 : Analisis

2.1 Definisi Analisis Kebutuhan

Analisis kebutuhan adalah proses menemukan permasalahan dan menghasilkan alternatif
pemecahan yang relevan.

Tujuan tahap analisis adalah untuk mengetahui kebutuhan customer berkaitan dengan sistem
perangkat lunak yang diinginkan. Pada tahap ini yang terlibat adalah tim spesifikasi/analisis dan
customer (meliputi end-user, manajer dan staf lain yang terlibat).

2.2 Metric (Ukuran) Analisis Kebutuhan

Metric analisis kebutuhan diperlukan untuk :

ƒ Mengukur apakah suatu kebutuhan didefinisikan dengan baik. Hal ini dapat dilihat
antara lain dari persentase spesifikasi kebutuhan yang ambigu dan derajat kelengkapan
kebutuhan yang didefinisikan
ƒ Mengukur apakah inspeksi terhadap pendefinsian kebutuhan dilakukan secara efektif

2.3 Lingkup Tahap Analisis

ƒ Mengidentifikasi customer (termasuk pengguna)
ƒ Mendefinisikan dan menspesifikasikan kebutuhan
ƒ Membangun model analisis
ƒ Mendefisikan spesifikasi rinci untuk dijadikan panduan dalam melakukan perancangan
ƒ Mendokumentasikan hasil analisis ke dalam dokumen SKPL (Spesifikasi Kebutuhan
Perangkat Lunak) dengan format standar (misal : IEEE, NASA, ITB, dll).
ƒ Melakukan pengkajian ulang secara formal

2.4 Pendefinisian dan Spesifikasi Kebutuhan

Definisi Kebutuhan adalah deskripsi fungsionalitas sistem yang berorientasi pada customer dan
batasan-batasan yang menyertai pengoperasian sistem tersebut [SOM00].

Penulisan Definisi Kebutuhan:

ƒ Menggunakan bahasa natural (english) Æ meskipun secara universal dimengerti, namun
tetap dimungkinkan muncul hal-hal berikut yang harus dihindari, antara lain :
o ketidakjelasan disebabkan dokumen yang dibuat sulit dibaca karena terlalu rinci
o pencampuradukan antara kebutuhan fungsional dan kebutuhan non fungsional
o beberapa kebutuhan diekspresikan dengan satu pernyataan
ƒ Menggunakan format standar (misal : IEEE)

Spesifikasi Kebutuhan adalah deskripsi rinci dan terukur dari fungsi-fungsi dan batasan-batasan
sistem yang telah didefinisikan [SOM00].

Penulisan Spesifikasi Kebutuhan :

ƒ Structured language specifications
o Bentuk terbatas dari bahasa natural (english) yang digunakan untuk
mengekspresikan kebutuhan
o Menghilangkan beberapa problem yang diakibatkan oleh ambiguitas dan
fleksibilitas
 o Sering didukung dengan penggunaan pendekatan berbasis form( Form-based
specifications)
o Form-based specifications, berisi :
• Definisi fungsi dan entitas
• Deskripsi input dan dari mana datangnya
• Deskripsi output dan siapa yang membutuhkannya
• Mengindikasikan entitas lain yang dibutuhkam
• Kondisi sebelum dan sesudah proses dilakukan (jika diperlukan)
• Efek samping dari proses jika ada
ƒ Notasi Grafis
ƒ Spesifikasi matematis

Jenis kebutuhan antara lain :

ƒ Kebutuhan Data
ƒ Kebutuhan Fungsional
ƒ Kebutuhan Non Fungsional
ƒ Kebutuhan Antarmuka

2.5 Pemodelan Analisis

Prinsip Pemodelan Analisis
ƒ Memodelkan domain data
ƒ Memodelkan Fungsi
ƒ Memodelkan perilaku sistem
ƒ Mempartisi model
ƒ Mulai dengan fokus pada esensi dari permasalahan

Memodelkan Domain Data

Memodelkan domain data terdiri dari :
ƒ Mendefinisikan objek data
ƒ Mendeskripsikan atribut data
ƒ Mendefinisikan keterhubungan data

Memodelkan Fungsi
Memodelkan fungsi terdiri dari :
ƒ Mengidentifikasi fungsi-fungsi yang mentransformasikan objek data
ƒ Mengidentifikasi bagaimana aliran data yang terdapat pada sistem
ƒ Mengidentifikasi entitas yang memproduksi data dan memanfaatkan informasi yang
dihasilkan sistem

Memodelkan Perilaku Sistem, meliputi :

ƒ Mengidentifikasi semua state yang dihasilkan sistem
ƒ Menspesifikasikan event yang menyebabkan perubahan dari satu state ke state yang lain

Mempartisi model, meliputi :

ƒ Melakukan perincian objek data
ƒ Menyusun hirarki fungsional
ƒ Merepresentasikan perilaku sistem pada tiap level
Pemodelan analisis berfungsi untuk memberikan gambaran lojik perangkat lunak, data yang
diperlukan dan model perilaku dari sistem perangkat lunak yang dikembangkan. Gambar 2. 9
memperlihatkan lingkup pemodelan analisis.

Model data

Model Fungsional

Model Perilaku

Gambar 2.9 pemodelan analisis [PRE01]

Pemodelan analisis dimulai dengan :

ƒ Mendefinisikan pernyataan ruang lingkup sistem Ædapat diperoleh dari dokumen
kontrak, dokumen spesifikasi sitem atau dokumen lainnya dan himpunan use-case.
Pernyataan ini harus menguraikan fungsi-fungsi dasar yang harus dimiliki sistem, data
yang akan menjadi masukan dan keluaran, perilaku sistem, domain informasi dan
batasan-batasan secara singkat dan jelas.
ƒ Mendefinisikan objek-objek dan operasi Æ objek-objek dapat merepresentasikan entitas
luar yang memberikan input ke sistem atau yang menerima informasi dari sistem, aliran
data atau item data yang ditransformasikan oleh sistem dan penyimpanan data (data
store). Sedangkan operasi merepresentasikan proses-proses yang terdapat pada aplikasi.
ƒ Melakukan pemodelan data Æ pemodelan ini diperlukan untuk meminimalkan
kebergantungan objek data terhadap proses, memfokuskan pada pengekspolrasian
domain data, membuat suatu model yang memudahkan customer memahaminya dan
mengindikasikan keterhubungan antara suatu objek data dengan objek data lainnya.
Model ini direpresentasikan dengan Entity Relationship Diagram.
ƒ Melakukan pemodelan fungsi Æ pemodelan ini diperlukan untuk memperlihatkan proses-
proses yang dimiliki aplikasi dan bagaimana proses tersebut mentransformasikan data
menjadi informasi. Model ini untuk metode terstruktur direpresentasikan dengan Data
Flow Diagram
ƒ Melakukan pemodelan perilaku Æ pemodelan ini diperlukan untuk memperlihatkan
perubahan state yang ditunjukkan sistem atau aplikasi ketika terjadi event yang
dibangkitkan dari luar. Model ini direpresentasikan dengan State Transition Diagram
ƒ Mendefinisikan Spesifikasi Proses Æ masing-masing proses pada Data Flow Diagram
yang sudah tidak didekomposisi lagi dideskripsikan spesifikasinya.
ƒ Mendeskripsikan Kamus Data Æ kamus data diperlukan untuk mendeskripsikan isi atau
nilai dari data, baik data yang mengalir ke proses dan dari proses maupun data yang
terdapat pada data store.
Pemodelan Data

Notasi ERD Î Notasi ERD ditunjukkan gambar 2.10

One common form:

(0, m)
object relationship object
1 (1, 1) 2

attribute
Another common form:

object relationship object

1 2
(0, m) (1, 1)

Gambar 2.10 Notasi Entity Relationship Diagram [PRE01]

Catatan :
Untuk kasus di mana data yang terlibat dalam sistem tidak memerlukan penyimpanan (basis data)
atau jika objek-objek data tersebut tidak memiliki keterhubungan satu sama lain, maka ERD tidak
perlu digambarkan.

Pemodelan Fungsional

DFD digunakan untuk menggambarkan aliran data yang mengalir dalam sistem atau perangkat
lunak. DFD juga menggambarkan fungsi-fungsi yang dimiliki sistem atau perangkat lunak
tersebut. Notasi DFD dapat dilihat pada gambar 2.11

Eksternal eksternal

Proses/buble

Aliran data

data store

Gambar 2.11 Notasi Data Flow Diagram [PRE01]

Entitas eksternal/Terminator merepresentasikan suatu entitas yang memberikan informasi ke
sistem atau menerima informasi dari sistem. Entitas ekternal dapat berupa manusia, perangkat
lunak lain, perangkat keras, dan lain-lain.

Proses(buble) merepresentasikan suatu fungsi dari perangkat lunak. Suatu proses akan
mentransformasikan suatu informasi menjadi informasi lain.

Data store merepresentasikan suatu media yang berfungsi menyimpan data yang diperlukan oleh
satu proses atau lebih

Pembuatan DFD Æ terdiri dari diagram konteks dan DFD level selanjutnya.

Pembuatan diagram konteks dilakukan dengan tahapan berikut :

ƒ Menentukan entitas eksternal
ƒ Menentukan informasi yang mengakir dari entitas luar ke sistem dan sebaliknya
ƒ Menggambarkan diagram konteks

Diagram konteks merupakan diagram level pertama yang memperlihatkan sistem sebagai suatu
proses yang berinteraksi dengan lingkungannya. Ada pihak luar yang memasukkan informasi ke
dalam sistem dan ada yang menerima informasi dari sistem. Pihak luar bisa berupa sistem lain,
perangkat keras, orang atau organisasi. Gambar 2.12 memperlihatkan contoh diagram konteks.

Level 0 DFD Example

user processing
requested
request
video
digital signal
video monitor
processor
video NTSC
source video signal

Untuk membuat DFD lakukan langkah-langkah berikut :

ƒ Definisikan secara naratif fungsi-fungsi yang dimiliki perangkat lunak
ƒ Gambarkan proses-proses yang mewakili fungsi yang telah
ƒ Gambarkan aliran data yang masuk dan keluar dari masing-masing proses
ƒ Periksa kelogisan dari masing-masing proses dan kekontinuan aliran data
ƒ Lakukan langkah seperti tersebut di atas untuk level berikutnya
 T h e D a ta F lo w H ie ra rc h y

a b
x P y le v e l 0

le v e l 1

a c p2
f
p1

p4 b
d 5
p3 e g

Gambar 2.13 Data Flow Diagram [PRE01]

Catatan untuk pemodelan data :

• Semua notasi harus diberi label dengan nama yang memiliki arti
ƒ DFD sebaiknya terdiri dari beberapa level untuk memperinci proses atau fungsi yang
dimiliki perangkat lunak
ƒ Setiap proses harus diberi label dengan kata kerja atau kata benda yang menunjukkan
fungsi.
ƒ DFD dimulai dengan menggambarkan diagram konteks (DFD level0)
ƒ Pada diagram konteks entitas eksternal harus digambarkan
ƒ Setiap anak panah (merepresentasikan aliran data) harus diberi label dengan kata benda
ƒ Tiap buble (proses) harus diperinci sampai tiap-tiap proses hanya mengerjakan suatu
fungsi tertentu
ƒ Kebanyakan sistem memerlukan 3 sampai 7 level DFD
ƒ Nama buble/proses harus terdiri dari kata benda atau kata kerja
ƒ Nama yang dipakai untuk buble , data store, data flow harus konsisten (identitas perlu)
ƒ Setiap level harus konsisten aliran datanya dengan level sebelumnya
ƒ Banyaknya buble yang disarankan pada setiap level tidak melebihi 7 buble
ƒ Dekomposisi berdasarkan kelompok data lebih disarankan (memudahkan aliran data ke
storage yang sama)
ƒ Nama proses yang umum hanya untuk buble yang masih akan didekomposisi
ƒ Nama proses spesifik (Add , Update, Delete, Calculate, Compare, Merge,….) pada case
tool harus disertai dengan Proses spesifikasi (PSPEC) yang jelas
ƒ Pada proses yang sudah tidak didekomposisi, nama proses dan nama data harus sudah
spesifik
ƒ Aliran ke storage harus melalui proses, tidak boleh langsung dari eksternal entity
 ƒ Aliran data yang tidak ada data storenya harus diteliti, apakah memang tidak
mencerminkan presisten entity (perlu disimpan dalam file atau tabel) yaitu kelak hanya
akan menjadi variabel dalam program

Pemodelan Perilaku
Pemodelan perilaku banyak diterapkan untuk sistem waktu nyata (real time system). Pemodelan
perilaku dilakukan dengan tahapan berikut :
ƒ Daftarkan seluruh state yang dimiliki sistem. Definisi state adalah himpunan keaadaan
yang dapat diamati di mana keadaan tersebut mencirikan perilaku sistem pada waktu
tertentu
ƒ Indikasikan bagaimana terjadinya transisi antar state atau indikasikan event yang terjadi
dan bagaimana aksi dari sistem terhadap adanya event tersebut. Definisi event adalah
kejadian yang menyebabkan sistem menunjukkan beberapa bentuk perilaku yang dapat
diprediksi. Contoh sebuah sistem yang memiliki mode manual dan otomatis, jika operator
menekan tombol otomatis maka mode akan beralih dari manual menjadi otomatis.
Tertekannya tombol otomatis tersebut merupakan contoh event. Sedangkan aksi
didefinisikan proses yang terjadi sebagai konsekuensi dari adanya transisi
ƒ Gambarkan state transition diagram (STD)

Notasi STD diperlihatkan pada gambar 2.14.

sta te

event causing transition

Action that occurs

new state

Gambar 2.14 Notasi State Transition Diagram [PRE01]

Pendefinisian Spesifikasi Proses

Spesifikasi proses dapat dinotasikan dengan :
ƒ Naratif
ƒ Pseudocode
ƒ Persamaan matematika (jika penyangkut formula perhitungan)
ƒ Flow chart
.
Kamus Data
Notasi untuk kamus data :

Notasi Arti

= terdiri dari

+ dan

[...|...] atau (either or)

{...}n pengulangan n kali dari ....

(....) data pilihan

...text... komentar

Contoh Kamus Data

Contoh kamus data diperlihatkan pada gambar 2.15.

integrated
telephone number office system output
phone
system

Build the requirements dictionary:

Name: telephone number

Aliases: phone number, number

Where/How read-phone-number (input)

used: display-phone-number (output)
analyze-long-distance-calls (input)

Description: telephone no. = [ local extension | outside no. | 0 ]

outside no. = 9 + [ service code | domestic no. ]
service code = [ 211 | 411 | 611 | 911 ]
domestic no. = ( ( 0 ) + area code ) + local number
area code = *three numeral designator*

Format: alphanumeric data