KAJIAN DAN SPESIFIKASI PERANGKAT LUNAK

Di Susun Oleh :

Linda Liana – 41813120100

Dosen Pengampu :

Wahyu Hari Haji M.Kom

FAKULTAS ILMU KOMPUTER

PROGRAM STUDY SISTEM INFORMASI

UNIVERSITAS MERCU BUANA JAKARTA

2015

A. SPESIFIKASI PERANGKAT LUNAK

Spesifikasi menggambarkan kebutuhan atau persyaratan (requirement) apa saja yang

harus dipenuhi oleh sistem perangkat lunak dan menentukan batasan pada operasi serta

implementasinya. Ada dua jenis kebutuhan sistem, yaitu fungsional dan non fungsional.

Kebutuhan fungsional menetapkan layanan sistem yang harus disediakan. Kebutuhan non-

fungsional berkaitan dengan ketentuan yang harus dipenuhi semua layanan pada sistem,

menyangkut kinerja, kehematan, keamanan dan mutu informasi.

Kebutuhan pengguna akhir menetapkan data dan informasi apasaja yang perlu di

akses dari sistem. Kebutuhan pengguna harus ditulis dalam tabel bahasa alami atau diagram.

Persyaratan sistem dapat ditulis dalam bahasa alami terstruktur, PDL atau dalam bahasa

formal. Sedangkan dokumen persyaratan perangkat lunak adalah pernyataan yang disepakati

oleh pengguna dan pengembang, tentang persyaratan sistem yang dibangun.

Metode spesifikasi sama dengan pemecahan masalah. Pereka Perangkat Lunak yang

dipaksa bekerja dengan spesifikasi yang tidak lengkap, tidak konsisten, atau salah akan

mengalami frustasi atau keraguan. Akibatnya, kualitas , ketepatan waktu dan kelengkapan

perangkat lunak menjadi korban.

Spesifikasi perangkat lunak merupakan proses untuk menentukan pelayanan (servis)

apa yang dibutuhkan dan kendala-kendala pengoperasian sistem serta pengembangannya.

Berikut ini tahapannya:

1. Proses Rekayasa Kebutuhan

2. Studi Kelayakan

3. Analisis kebutuhan

4. Spesifikasi Kebutuhan

5. Validasi spesifikasi

1) Proses Rekayasa Kebutuhan

Apa yang menjadi kesuksesan dalam sebuah perangkat lunak?

Apa system yang cukup mampu memenuhi semua kebutuhan penggunanya?

Apa sistem yang cukup mampu memenuhi semua kebutuhan penggunanya?

Tinggat kepuasan penggunannya?

Rekayasa kebutuhan mencangkup beberapa proses mengenai fakta ini, proses

rekayasa kebutuhan adalah sekumpulan aktivitas-aktivitas yang terstruktur untuk diperoleh,

memvalidasi dan memelihara dokumen kebutuhan system (Thayer. 1997).

Pada umumnya tugas rekayasa digambarkan sebagai penciptaan dari solusi keaktivan

biaya untuk masalah kehidupan yang nyata dengan menerapkan pengetahuan keilmuan.

Rekayasa kebutuhan juga dapat digambarkan sebagai tugas untuk memenuhi aktivitas-

aktivitas pengembangan untuk masalah dunia nyata sehingga ketepatan dan keefektifan biaya

dari solusi dapat dianalis (Nuseibeh, 2000).

Dari sudut pandang pengembangan sistem perangkat lunak, dua aktivitas dapat

dikenali sebagai rekayasa kebutuhan dan rekayasa perangkat lunak. Rekayasa perangkat

lunak dapat digambarkan sebagai aktivitas yang terlibat dalam siklus hidup dari proses

pengembangan perangkat lunak, dengan rekayasa kebutuhan yang menjadi pusat aktivitas di

dalam siklus hidup.

Latar belakang kenapa rekayasa kebutuhan diperlukan adalah kenyataan bahwa

menemukan kebutuhan klien secara lengkap merupakan usaha yang tidak mudah dan mahal.

Dikatakan tidak mudah karena,

Klien tidak selalu mengetahui dengan pasti dan jelas mengenai apa yang diperlukan,

Kebutuhan yang diutarakan oleh klien tidak selalu sesuai dengan apa yang dimaksud,

Kebutuhan klien berubah-ubah di sepanjang kegiatan pembangunan perangkat lunak.

Hal tersebut menyebabkan biaya pembangunan perangkat lunak menjadi mahal

karena ada tambahan biaya dan tambahan waktu untuk perubahan yang dilakukan.

Daur hidup suatu perangkat (SLC) secara umum dapat diilustrasikan sebagai gambar

diatas, dimana ada 2 buah siklus kehidupan utama dari suatu perangkat lunak, yaitu daur

hidup pengembangan perangkat lunak (SDLC) dan daur hidup pengoperasian perangkat

lunak (SOLC), keduanya dihunbungkan oleh dua buah proses, yaitu proses studi kelayakan

dan proses peluncuran.

Pengembangan perangkat lunak pada dasarnya muncul karena adanya suatu

kebutuhan baru. Melalui studi kelayakan, kita dapat dibantu menentukan apakah kebutuhan

tersebut masih dapat dipenuhi oleh sistem perangkat lunak yang ada atau tidak. Jika

dipandang bahwa sistem yang sudah ada tidak dapat memenuhi kebutuhan baru tersebut,

maka kita akan memutusakan apa mau mengembangkan sistem perangkat lunak (baik sistem

lama atau baru). Studi kelayakan tetap dilakukan dalam pengembangan perangkat lunak

berskala besar maupun kecil.

Sistem yang baru yang akan dikembangkan bisa dibangun dari sistem lama, atau dari

sistem baru. Sering juga disebut lingkungan pengembangan (development enviornment).

Proses pertama yang dilakukan dengan penspesifikasian kebutuhan, hasil dari proses ini

adalah sebuah spesifikasi kebutuhan sistem yang dibutuhkan oleh pembuat. Spesifikasi ini

sering disebut sebagai rancangan bersifat high-end. Berdasarkan spesifikasi tersebut, pihak

pengembang akan membuat suatu rancangan yang bersifat lowend. Kemudian

diimplementasikan menjadi produk perangkat lunak oleh programmer. Melalui proses

pengujian produk ini diuji dan dipastikan kesesuaiannya dengan spesifikasi kebutuhan yang

telah ditetapkan dan ketetapan implementasinya. Produk yang berhasil melewati proses

pengujian kemudaian akan diluncurkan ke lingkungan operasioanl (operatioan environment).

Dalam daur pengoperasian , perangkat lunak yang telah selesai dibangun difungsikan

untuk kebutuhan operasiional sistem. Seringkali, terdapat ketidaksesuaian antara perangkat

lunak dengan kebutuhan di lapangan. Kesalahan ini terjadi pada beberapa kesalahan pada

daur hidup pengembangan dan akan diperbaiki.

Proses ini sering dipandang sebagai proses perawatan perangkat lunak. Tapi jika

kesalahan itu terjadi karena kebutuhan baru dalam organisasi maka perangkat lunak tersebut

dikaji ulang kelayakannya. Dan kembali pada daur hidup perangkat lunak tersebut.

Spesifikasi kebutuhan merupakan proses awal dari daur hidup pengembangan

perangkat lunak. Keluaran dari proses ini menentukan arah pengembangan perangkat lunak

selanjutnya. Tahap pekerjaan analisis kebutuhan perangkat lunak pada dasarnya terdiri dari

urutan aktivitas :

1. Menentukan kebutuhan (requirement)

Lebih banyak berhubungan dengan pemakai. Hasil belum terstruktur.

a. Data atau informasi apa yang akan diproses

b. Fungsi apa yang diinginkan

c. Kelakuan sistem apa yang diharapkan

d. Antarmuka apa yang tersedia (user interfaces, hardware interfaces, software

interface, dan communications interfaces)

2. Sintesis

Mengubah kebutuhan yang belum terstruktur menjadi model atau gambar dengan

memanfaatkan teknik dan metodeanalisis tertentu.

3. Membuat dokumen Software Requirements Spesification (SRS).

Sudah merupakan analisis yang lebih rinci, sebagai tahap awal perancangan.

2) Studi Kelayakan

Untuk semua sistem baru, proses rekayasa persyaratan harus dimulai studi kelayakan.

Input dari studi kelayakan adalah deskripsi garis besar sistem dan bagaimana sistem akan

digunakan di dalam organisasi. Hasil studi kelayakan berwujud laporan. Studi Kelayakan

memutuskan apakah sistem software yang akan dibuat sudah mencakup seluruh aspek

permasalahan. Melakukan studi kelayakan mencakup penilaian informasi, pengumpulan

informasi,dan penulisan laporan.

Melakukan studi untuk menguji apakah sistem:

Sudah sesuai dengan tujuan organisasi

Dapat dikembangkan dengan teknologi terkini dan dana yang tersedia

Dapat diintegrasikan dengan sistem lain yang sudah digunakan

3) Implementasi Studi Kelayakan

Implementasi menurut kamus besar indonesia, diartikan sebagai pelaksanaan atau

penerapan, artinya yang dilaksanakan dan diterapkan adalah kurikulum yang telah dirancang

atau didesain untuk kemudian dijalankan sepenuhnya. Berbasiskan pada penilaian informasi

(apa yg dibutuhkan), pengumpulan informasi dan penulisan laporan

Pertanyaan ke personal di organisasi:

1. Apa yang akan terjadi apabila sistem tidak diimplementasikan?

2. Masalah proses apa yang ada ?

3. Apa yang dapat dibantu oleh sistem ?

4. Masalah apa yang akan muncul pada proses Integrasi ?

5. Adakah teknologi baru yang dibutuhkan? Skill yang dibutuhkan ?

6. Fasilitas apa yang harus didukung oleh sistem ?

4) Validasi Kebutuhan

Validasi adalah suatu tindakan pembuktian dengan cara yang sesuai dengan tiap

bahan proses, prosedur, kegiatan, sistem, perlengkapan atau mekanisme yang digunakan

dalam produksi dan pengawasan yang akan senantiasa mencapi hasil yang diinginkan.

Validasi dibutuhkan untuk memberikan kepastian bahwa rancangan dan dokumen dari

sistem yang akan diimplementasiakn telah sesuai dengan keinginan dan kebutuhan pemangku

kepentingan baik pemesan, pengguna maupun pihak pengembang. Tujuan dari validasi

kebutuhan adalah :

Bertujuan untuk meyakinkan bahwa kebutuhan yang sudah didefinisikan sesuai

dengan yang diinginkan pengguna

Menghindari Kesalahan pendefinisian kebutuhan karena akan menyebabkan

penambahan biaya yang besar

Memperbaiki definisi kebutuhan setelah software dikirim akan menyebabkan

peningkatan biaya hingga 100 kali.

Analisa kebutuhan merupakan langkah awal untuk menentukan perangkat lunak

seperti apa yang akan dihasilkan, ketika kita melaksanakan sebuah proyek pembuatan

perangkat lunak. Perangkat lunak yang baik dan sesuai dengan kebutuhan pengguna sangat

bergantung kepada keberhasilan dalam melakukan analisa kebutuhan. Tidak peduli

bagaimana hebatnya seseorang dalam menulis kode perangkat lunak, atau membuat antar

muka yang menawan, jika terjadi kesalahan dalam analisa kebutuhan, itu artinya perangkat

lunak yang dibuat menjadi tak berguna.

Analisa kebutuhan yang baik belum tentu menghasilkan perangkat lunak yang baik.

Tetapi analisa kebutuhan yang tidak tepat sudah pasti menghasilkan perangkat lunak yang

tidak berguna. Ini adalah sebuah pernyataan sederhana. Namun pernyataan ini tidaklah terlalu

jauh dari kesimpulan yang sebenarnya.

Adalah jauh lebih baik mengetahui ada kesalahan tentang analisa kebutuhan ketika

masih dalam tahap awal ini. Kurang hati-hati dan pelaksanaan yang tidak teliti, sehingga

mengakibatkan terjadinya kesalahan analisa kebutuhan sungguh menimbulkan banyak

kerugian. Kesalahan analisa kebutuhan yang diketahui ketika sudah memasuki penulisan

kode, atau pengujian, bahkan hampir pada tahap penyelesaian, adalah malapetaka besar bagi

sebuah kelompok pembuat perangkat lunak. Biaya dan waktu yang diperlukan menjadi

banyak yang tersia-sia.

Biaya yang diperlukan untuk memperbaiki sebuah kesalahan karena analisa

kebutuhan yang tidak benar, bisa menjadi dua puluh lima kali lipat, jika kesalahan tersebut

ditemukan pada tahap pengujian fungsi perangkat lunak

Ketika dalam tahap awal ini, sungguh diperlukan pelaksanaan analisa dengan hati-hati

dan sebaik-baiknya. Dengan diperolehnya kebutuhan yang jelas dan benar sesuai dengan apa

yang dimaksud oleh klien, menunjukkan langkah awal yang baik, yang akan membantu

ketika kita melanjutkan kepada tahap berikutnya dalam pembuatan perangkat lunak.

Dalam berbagai buku yang membahas tetang rekayasa perangkat lunak, analisa

kebutuhan merupakan bab tersendiri yang selalu dibahas dengan baik. Banyak cara yang

diuraikan untuk menghasilkan analisa kebutuhan yang akurat, sehingga penulisan perangkat

lunak juga menjadi tepat. Yang menjadi hambatan utama di sini adalah ketika melakukan

analisa kebutuhan yang sesungguhnya di lapangan. Penerapan dari teori-teori yang ada

ternyata tidak bisa begitu saja dapat dilaksanakan. Banyak ditemui hal yang perlu diantisipasi

dengan cara-cara yang lebih tepat, dan baru diketahui ketika kita sudah berada dalam situasi

yang sesungguhnya dalam sebuah proyek pembuatan perangkat lunak.

Dengan tidak mengabaikan faktor teknis, sejumlah faktor non teknis menjadi kunci

dalam keberhasilan kita memperoleh analisa kebutuhan yang benar.

Prinsip Spesifikasi

Spesifikasi, tanpa mempedulikan mode dimana kita melakukannya, dapat dilihat sebagai

sebuah proses representasi. Persyaratan diwakilkan dengan suatu cara yg membawa ke arah

implementasi yang berhasil. Berikut ini sejumlah prinsip spesifikasi yang diadaptasi dari

kerja Blazer dan Goldman [BLA 86].

1. Memisahkan fungsional dari implementasi

2. Mengembangkan suatu model dari system yang diperlukan yg meliputi data dan

respon fungsional dari suatu system terhadap berbagai stimulus dari lingkungan.

3. Membangun konteks dimana PL beroperasi dengan menentukan cara dimana

komponen system yg lain berinteraksi dengan PL.

4. Menentukan lingkungan dimana system beroperasi dan menunjukan bagaimana “

sekumpulan agen yang sangat terjalin bereaksi terhadap stimulus dalam lingkungan.

5. Menciptakan sebuah model yg kognitif daripada model desain atau implementasi.

Model kognitif menggambarkan sebuah system sebagaimana dirasakan oleh

komunitas pemakainya.

6. Mengenali spesifikasi harus toleran terhadap ketidak lengkapan dan dapat di tambah.

7. Membangun muatan dan struktur spesifikasi dengan suatu cara yang akan

memungkinkan spesifikasi dapat ditambah agar dapat berubah.

Representasi

Kita mengetahui bahwa persyaratan Perangkat Lunak dapat ditentukan dalam

berbagai cara. Akan tetapi, bila persyaratan itu dimasukan pada kertas atau media presentasi

electronic, maka diperoleh panduan sederhana:

- Format dan muatan representasi harus relevan dengan masalah.

- Informasi yang di isikan kedalm spesifikasi harus disarangkan.

Spesifikasi Persyaratan Perangkat Lunak

Spesifikasi persyaratan Perangkat Lunak dibuat pada puncak tugas analisis. Fungsi

dan kinerja yang dialokasikan pada Perangkat Lunak sebagai bagian dari rekayasa system,

diperhalus dengan membangun sebuah diskripsi informasi lengkap, diskripsi tingkah laku dan

fungsional lengkap, indikasi persyaaratan kinerja dan batasan desain, kriteria validasi yang

sesuai, dan data lain yang berkenaan dengan persyaratan. The Nation Bureau of Standards,

IEE( standard no. 830- 1984) dan Departement Pertahanan AS mengusulkan format calon

untuk spesifikasi persyaratan perangkatan perangkat lunak. Berikut merupakan kerangka

kerja untuk spesifikasi.

a) Pendahuluan

- Refrensi system

- Deskripsi keseluruhan

- Batasan proyek PL

b) Deskripsi informsi

- Representasi isi informasi

- Representasi aliran informasi

- Aliran data

- Aliran kontrola

c) Deskripsi fungsional

- Pembagian fungsional

- Deskripsi fungsional

- Gambaran pemrosesan

- Retriksi / keterbatasan

- Persyaratan kinerja Batasan desain

- Diagram pendukung

- Diskripsi control

- Spesifikasi control

- Batasan desain

d) Diskripsi prilaku

- Peryataan system

- Event dan tindakan

e) Validasi dan Kriteria

- Batas kinerja

- Kelas- kelas pengujian

- Respon Perangkat Lunak

- Pertimbangan khusus

f) Bibliografi

g) Lampiran

B. KAJIAN SPESIFIKASI PERANGKAT LUNAK

Kajian dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh

pelanggan atau pengembang Perangkat Lunak. Karena spesifikasi membentuk dasar bagi

desain dan aktivitas rekayasa selanjutnya, maka kajian harus dilakukan dengan hati- hati.

Kajian dilakukan pertama kali pada tingkat makroskopik.pada tingkat ini pengkaji akan

memastikan bahwa spesifikasi sudah lengkap, konsisten, dan, akurat.

Pertanyaan - pertanyaan berikut dapat di ajukan:

Apakah tujun dan sasaran yang diyatakan bagi perangkat lunak tetap konsisten

dengan tujuan dan sasaran system?

Apakah interface penting kesemua element system sudah digambarkan?

Apakah aliran informasi dan struktur didefinisikan dengan tepat bagi domain masalah

Apakah diagram jelas? apakah masing masing dapat berdiri sendiri tanpa teks

pendamping

Apakah fungsi mayor tetap ada pada ruang lingkup, dan sudah digambarkan dengan

lengkap dan tepat?

Apakah tingkah laku PL konsisten dengan informasi yang harus diproses dan fungsi

harus dilakukannya?

Apakah batasan desain realistis?

Apakah resiko teknologis pengembang sudah dipertimbangkan?

Apakah criteria validasi dinyatakan secara detail? apakah criteria tersebut kuat untuk

menggambarkan sebuah system yang berhasil.

Apakah ada inkonsistensi,penghilangan?

Apakah kontak dengan pelanggan sudah lengkap?

Apakah pemakai sudah mengkaji manual pemakai pemulaan atau prototype?

Bagaimana estimasi perencanaan mempengaruhi

Pengkaji dapat mengembangkan pertayaan diatas dengan :

Mencari konektor persuasive

Bila suatu daftar yang diberikan tidak lengkap, pastikan jenisnya sudah dipahami.

Pastikan jangkauan yg dinyatakan tidak berisi asumsi yang tidak dinyatakan.

Hati hatilah pada kata kerja yang kabur

Hati hati terhadap kata ganti yang ambiguitas. Cari pertanyaan yang

mengimplimentasikan kepastian. Bila kajian lengkap spesifikasi persyaratan Perangkat Lunak

diakhiri oleh pelanggan atau pengembang. Perubahan yang diminta setelah spesifikasi itu di

akhiri tidak akan dieleminasi, tetapi pelanggan harus mencatat bahwa masing – masing

perubahan setelah pengakhiran spesifikasi merupakan ekstensi dari ruang lingkup Perangkat

Lunak yang demikian dapat menambah biaya atau dapat memperpanjang jadwal proyek.

Bahkan dengan prosedur kajian terbaikpun, tetap ada sejumlah masalah spesifikasi.

Spesifikasi sulit di uji dalam berbagai cara yang berarti sehingga inkonsistensi dan

penghilangan dapat berlangsung tanpa terlihat.Selama kajian , perubahan terhadap terhadap

spesifikasi dapat disetujui. Sangat sulit untuk menili pengaruh global dari suatu perubahan ;

yaitu bagaimana suatu perubahan dalam suatu fungsi mempengaruhi persyaratan bagi fungsi-

fungsi yang lain.

Kesimpulan Analisis persyaratan adalah langkah teknis pertama pada proses rekayasa perangkat

lunak. Di sini pernyataan umum mengenai ruang lingkup perangkat lunak disaring ke dalam

sebuah spesifikasi konkrit yang menjadi dasar bagi aktivitas rekayasa perangkat lunak yang

mengikutinya. Analisis harus berfokus pada domain informasi, fungsional, dan tingkah laku

dari masalah. Untuk lebih memahami apa yang dibutuhkan, maka dibuatlah sebuah model;

masalah dibagi-bagi, dan representasi yang menggambarkan esensi persyaratan, dan

kemudian detail implementasi dikembangkan. Dalam beberapa kasus tidaklah mungkin untuk

secara lengkap menspesifikasi suatu masalah pada tahap awal. Prototyping menawarkan

sebuah pendekatan alternatif yang menghasilkan sebuah model perangkat lunak yang dapat

dieksekusi yang dari sana persyaratan disaring. Dibutuhkan peranti dan teknik khusus untuk

melakukan prototyping secara tepat.

Spesifikasi persyaratan perangkat lunak dikembangkan sebagai akibat dari analisis.

Kajian penting untuk memastikan bahwa pengembang dan pelanggan memiliki persepsi yang

sama mengenai sistem. Sayangnya, bahkan dengan metode yang terbaik sekalipun,

masalahnya adalah bahwa masalah tersebut terus berubah.