SOFTWARE

REQUIREMENTS

MUHAMMAD YUSUF
Teknik Informatika – Universitas Trunojoyo
Email : yusufxyz@gmail.com
Http://yusufxyz.wordpress.com
Dasar – Dasar Software
Requirements
 Definisi
 software requirement adalah sebuah properti
yang harus diperlihatkan /ditunjukkan oleh
software untuk menyelesaikan suatu
permasalahan yang ada di dunia nyata / bersifat
riil.
 merupakan kombinasi rumit dari kebutuhan
berbagai orang di bermacam – macam tingkat
organisasi dan lingkungan di mana perangkat
lunak akan dioperasikan.
 properti yang esensial dari semua software
requirement adalah harus mampu
diperiksa/diverifikasi.
 Product and Process requirement
 Kebutuhan produk adalah requirement
pada software untuk dikembangkan
(Contohnya “Software harus memeriksa
prasyarat mata kuliah yang diambil
mahasiswa”)
 Kebutuhan proses adalah batasan –
batasan dalam mengembangkan software.
Contohnya pilihan teknik verifikasi.
Process requirement juga bisa ditetapkan
oleh organisasi pengembang, pelanggan
atau pihak ketiga seperti badan regulator.
 Requirement fungsional dan
nonfungsional
 Requirements fungsional menjabarkan fungsi –
fungsi yang akan dilaksanakan software.
Contohnya memformat teks. Kadang – kadang
disebut juga sebagai kapabilitas.
 Requirements non-fungsional memberikan
batasan terhadap solusi yang akan dihasilkan.
Disebut juga sebagai quality requirement.
Requirement jenis ini masih bisa dibagi lagi
menjadi performance requirements,
maintainability requirements, safety
requirements, reliability requirements atau salah
satu software requirements lainnya.
 Emergent Properties

Beberapa requirement merupakan

perwakilan dari emergent properties yaitu
requirement yang tidak bisa ditangani oleh
satu komponen saja. Keberhasilan dalam
menanganinya juga bergantung pada
interoperasi dari berbagai komponen yang
ada. Emergent properties amat bergantung
pada arsitektur sistem.
 Quantifiable Requirements
Software requirement harus bisa dinyatakan
dengan jelas, tidak ambigu dan pada
beberapa bagiannya yang sesuai,
kuantitatif.
Contoh requirement yang memenuhi syarat:
Sebuah perangkat lunak dari suatu call
central harus meningkatkan throughput
sebanyak 20% dan sistemnya hanya
menghasilkan kesalahan fatal dengan
peluang kurang dari 1*10-8.
 System Requirements dan
Software Requirements
 Dalam topik ini sistem berarti kombinasi
dari elemen – elemen yang berinteraksi
untuk mencapai suatu tujuan yang
terdefinisikan. Ini termasuk hardware,
software, firmware, manusia, informasi,
tehnik, fasilitas, layanan dan berbagai
elemen pendukung lainnya
 System requirement adalah requirement
untuk sistem secara keseluruhan. Dalam
sebuah sistem yang mengandung
komponen software, software requirement
diperoleh dari system requirement.
Requirement Process
 Process Models
 Bukan kegiatan berawal – berakhir secara
diskrit tetapi dimulai dari awal suatu
proyek dan terus diperhalus selama siklus
hidup software.
 Mengidentifikasi software requirement
sebagai konfigurasi item – item dan
mengaturnya dengan praktik – praktik
manajemen konfigurasi software yang
sama dengan produk – produk lain dari
proses – proses siklus hidup software
tersebut.
 Perlu diadaptasikan sesuai dengan konteks
organisasi dan proyek.
 Process Actors
 Pengguna : kelompok yang kelak akan mengoperasikan
software.
 Pelanggan : Kelompok inilah yang akan memberlakukan
suatu software ke dalam suatu organisasi.
 Analis Pasar : Analis pasar diperlukan untuk mengetahui
kebutuhan pasar.
 Regulator : Banyak bidang di mana aplikasi terkena
regulasi misalnya perbankan dan transportasi umum.
Karenanya software yang dioperasikan pada bidang –
bidang semacam ini harus sesuai dengan ketentuan dari
badan regulator yang berwenang.
 Perekayasa software : Kelompok ini memiliki hak yang
sah untuk mengambil keuntungan dari pengembangan
suatu software, termasuk menggunakan ulang beberapa
komponennya untuk produk lain.
 Process Quality and
Improvement

Membahas penilaian kualitas dan

peningkatan dari suatu requirement
process. Tujuannya adalah untuk
menekankan peran kunci requirement
process dari segi biaya dan masa berlaku
suatu produk software dan kepuasan
pelanggan.
Requirements Elicitation
 Sumber – Sumber Requirements
 Tujuan. Tujuan bisa memberi motivasi bagi
pembuatan software tetapi sayangnya sering
diformulasikan secara samar. Karenanya perlu
dinilai biaya dan nilainya secara jelas.
 Pengetahuan akan domain. Seseorang
perekayasa software harus mengetahui domain
dari aplikasi yang dikerjakannya.
 Pihak yang berkepentingan. Banyak software
yang tidak memuaskan karena terlalu condong
pada kepentingan pihak tertentu saja dan
mengorbankan pihak lain. Hendaknya dipahami
dan dicapai keseimbangan dari sudut pandang
tiap pihak.
 Sumber – Sumber Requirements
 Lingkungan operasional. Requirement
akan disusun dari lingkungan di mana
software akan bekerja. Misalnya batasan
timing untuk real – time software atau
kemampuan interoperasional
 Lingkungan organisasional. Seringkali
suatu software dibuat untuk menunjang
proses bisnis. Karenanya perlu
diperhatikan struktur, budaya kerja dan
situasi politik dari organisasi yang
bersangkutan.
 Elicitation Techniques
 Wawancara. Merupakan tehnik yang paling
tradisional. Perlu diketahui batasan dan tata
caranya.
 Skenario. Tehnik ini mampu memberikan konteks
untuk menyusun requirement bagi pengguna.
Memberikan kerangka kerja bagi perekayasa
software dengan membolehkan pertanyaan
seperti “Bagaimana jika…” atau “Bagaimana ini
dikerjakan”.
 Prototipe. Tehnik ini bisa memberi kejelasan pada
requirement yang masih kabur. Tehnik ini
bertindak mirip dengan skenario karena bisa
memberikan konteks di mana pengguna bisa
tahu informasi apa yang harus diberikan.
 Elicitation Techniques
 Pertemuan terfasilitasi. Tehnik ini baik untuk
menghimpun pandangan berbagai pihak yang
berkepentingan. Bisa pula timbul – saran atau ide
yang membantu. Selain itu juga bisa mengenali
konflik antar requirement. Tetapi pertemuan
sebaiknya menggunakan jasa seorang fasilitator
untuk mencegah / mengendalikan kemungkinan
dominasi pihak tertentu.
 Observasi. Tehnik ini relatif mahal tapi wajib
karena mungkin saja proses bisnis terlau
kompleks dan canggih untuk dijelaskan secara
lisan. Perekayasa software harus masuk ke dalam
lingkungan kerja pengguna dan mengamati
interaksi pengguna dengan software dan sesama
pengguna lain.
Requirement Analysis
 Klasifikasi Requirements
 Fungsional dan non fungsional
 Apakah suatu requirement didapat dari satu atau
lebih requirement yang berlevel lebih tinggi atau
merupakan emergent propety (sub bagian 1.4)
atau ditetapkan oleh pihak yang berkepentingan
atau sumber lain.
 Apakah requirement ada pada produk atau proses.
 Prioritas. Secara umum, semakin tinggi prioritas
suatu requirement semakin mendesak pula untuk
dipenuhi dalam produk akhir.
 Cakupan dari requirement. . Hal ini sangat
berpengaruh pada arsitektur software dan desain
komponen.
 Stabilitas. Requirement kadang berubah dalam
suatu siklus hidup software bahkan mungkin dalam
proses pengembangannya.
 Conceptual Modelling
Pemodelan dari permaslahan riil adalah kunci dari
analisa software requirements.
Tujuannya untuk membantu memahami
permasalahan. Model konseptual terdiri dari model
entitas – entitas dari domain permasalahan yang
disusun untuk mewakili relasi riil dan
ketergantungan riil.
Ada beberapa model yang bisa dikembangkan.
Antara lain aliran data dan kontrol, model keadaan,
pelacakan even, interaksi pengguna, model obyek,
model data dan lain – lain.
 Conceptual Modelling
Faktor yang mempengaruhi pemilihan
pemodelan:
 Sifat dari permasalahan. Beberapa tipe software
menuntut agar aspek tertentu dianalisa secara
menyeluruh
 Keahlian perekayasa software. Lebih baik
menggunakan notasi atau metode permodelan
yang sudah familier.
 Process requierement dari pelanggan. Mungkin
pelangan ingin menetapkan notasi atau metode
pemodelan tertentu
 Ketersediaan metode dan alat. Meskipun cocok
namun jika tidak ditunjang dengan keahlian dan
alat yang baik, suatu notasi atau metode tidak
bisa dipakai.
 Desain Arsitektural dan Alokasi
Requirement
Desain arsitektural adalah suatu tahap di mana
requirement process dilakukan bersamaan dengan
desain sistem atau software. Karenanya sulit
memisahkan dua aktivitas tersebut.
Desain arsitektural sangat berhubungan dengan
pemodelan konseptual. Pemetaan domain entitas
dunia nyata menjadi komponen software tidak selalu
jelas, sehingga desain arsitektural dianggap sebagai
topik terpisah. Requirement untuk notasi dan metode
secara umum sama pada pemodelan konseptual dan
desain arsitektural.
 Negosiasi Requirement

Topik ini disebut juga sebagai “penyelesaian

konflik”. Topik ini membahas penanganan masalah
requirement di mana timbul konflik antara dua pihak
yang sama – sama berkepentingan, antara
requirement dengan sumber daya atau requirement
fungsional dan non fungsional. Dalam kebanyakan
kasus, keputusan yang diambil secara unilateral
bukanlah sikap bijaksana. Karenanya penting untuk
mencapai konsensus dengan pihak yang
berkepentingan.
Spesifikasi Requirement
 Spesifikasi Requirement
Pada kebanyakan profesi perekayasaan, istilah
spesifikasi merujuk pada kegiatan memberikan
nilai numerik atau batas pada tujuan produk
akhir.

Tetapi definisi ini tidak bisa dipakai pada

rekayasa perangkat lunak mengingat
banyaknya requirement yang ada dan
kompleksitas interaksinya.

Karenanya pada rekayasa perangkat lunak

istilah “spesifikasi requirement software”
mengacu pada pembuatan dokumen baik fisik
maupun elektronis.
Pada sistem yang kompleks, terutama
yang melibatkan banyak kompone non
software, ada 3 jenis dokumen yang
dibuat yaitu definisi sistem,
requirement sistem dan requirement
perangkat lunak.

Pada produk software yang sederhana

hanya satu dari 3 jenis dokumen itu yang
perlu dibuat.

Semua tiga jenis dokumen itu akan

dijelaskan di sini.
 5.1:
Dokumen Definisi Sistem
Dokumen ini menyimpan requirement sebuah
sistem.

Dokumen ini mendaftar semua requirement

beserta keterangan latar belakang tujuan
keseluruhan sebuah sistem, lingkungan yang
menjadi sasaran dan pernyataan batasan, asumsi
dan requirement non-fungsional.

Mungkin juga di dalamnya terdapat model

konseptual yang didesain untuk memberikan
gambaran tentang konteks sistem, skenario
pemakaian dan entitas - entitas domain yang
penting, termasuk juga data, informasi dan aliran
kerja.
 5.2:
Spesifikasi Requirement Sistem.
Para pengembang dari sebuah sistem
berkomponen software dan non-software yang
cukup banyak, seringkali memisahkan deskripsi
dari requirement sistem dari deskripsi
requirement software.

Dengan cara ini, requirement sistem

dispesifikasikan, requirement software didapat
dari requirement sistem dan requirement untuk
komponen sosftware dispesifikasikan .

Karena merupakan bidang rekayasa sistem,

dokumen jenis ini tidak akan dibahas terperinci di
sini.
 5.3:
Spesifikasi Requirement Software
Dokumen jenis ini menjadi dasar untuk
sebuah perjanjian antara pelanggan dan
kontraktor atau penyuplai tentang apa
yang seharusnya dan tidak seharusnya
dikerjakan oleh produk software.

Untuk pembaca yang kurang paham hal –

hal yang sifanya teknis, dokumen jenis ini
juga didampingi oleh dokumen definisi
requirement software.
Dokumen ini memungkinkan penilaian
mendalam tentang requirement sebelum
desain dimulai sehingga mengurangi
keharusan desain ulang.

Dokumen ini juga memberikan dasar –

dasar realistis untuk memperkirakan
biaya, risiko dan jadwal produksi.
Requirements validation
 Requirements validation

Kebutuhan dokumen difokuskan pada prosedur

validasi dan verifikasi.

Kebutuhan akan validasi untuk meyakinkan

bahwa software engineer telah mengerti tentang
requirement yang diperlukan, dan juga sangat
penting untuk membuktikan bahwa requirements
document dapat disesuaikan dengan kebutuhan
standard suatu perusahaan, dan juga dapat
mudah dipahami, konsisten, dan lengkap.
 6.1:
Requirements Reviews
Arti umum validation adalah memeriksaan (inspection)
atau review (meninjau) requirements document.

Reviewer bertugas mencari error (look for errors), asumsi

yang salah (mistaken assumptions), hal-halyang kurang
jelas (lack of clarity), dan penyimpangan standar (deviation
from standard practice).

Hal ini sangat penting dan munkin membantu memberikan

petunjuk apa yang dicari dalam tabel checklists.

Review terdapat pada :

 penyelesaian dari system definition document
 system specification document
 software requirements specification document
 baseline specification for a new release
 atau pada langkah lain dalam suatu proses
 6.2:
Prototyping
Prototyping secara umum berarti untuk
melakukan validasi, interpretasi software
engineer mengenai software
requirements, sama seperti memperoleh
requirement baru.

Keuntungan dari prototype adalah akan

memudahkan software engineer
menginterpretasikan asumsinya dan juga
berguna untuk mengetahui kembali jika
terdapat kesalahan.
 6.3:
Model Validation
Merupakan suatu hal yang dibutuhkan untuk
mengesahkan kualitas suatu model yang sedang
dianalisis.

Sebagai contoh, dalam objek model sangat

berguna untuk melakukan static anlisis untuk
menguji bahwa jalur komunikasi antara objek itu
ada, dimana dalam daerah stakeholders, terjadi
pertukaran data.

Jika formal specification notations digunakan,

sangat memungkinkan untuk menggunakan
formal reasoning untuk membuktikan spesifikasi
properties.
 6.4:
Acceptance Tests
Property yang diperlukan dari sebuah software requirement
adalah bahwa sangat mungkin untuk mengesahkan produk yang
telah selesai dapat memenuhinya.

Requirements yang tidak dapat divalidasi merupakan hanya

sebuah ‘keinginan’.

Sebuah tugas yang penting adalah merencanakan bagaimana

menguji masing-masing requirement.

Dalam berbagai kasus, desain acceptance tests yang

melakukannya.

Mengidentifikasi dan mendesain acceptance tests mungkin sangat

sulit untuk non-functional requirement.

Agar bisa divalidasi, pertama harus dianalisis pada poin dimana

dapat ditunjukkan secara kuantitatif.
Practical Considerations
 Practical Considerations
Tidak semua organisasi mempunyai kebiasaan
mendokumentasikan dan mengatur requirement.

Bagaimanapun, sebagai perusahaan yang

berkembang, pelanggan mereka bertumbuh, dan
produk mulai berkembang, mereka menemukan
bahwa mereka perlu untuk memulihkan
keperluan – keperluan yang mendukung fitur
produk agar dapat menaksir gangguan dari
perubahan tujuan.

Oleh sebab itu, requirements documentation dan

pengubahan management adalah kunci sukses
dari requirements process.
 7.1:
Iterative Nature of Requirements
Process
Kebanyakan proyek didesak oleh
lingkungannya, dan banyak perubahan,
atau revisi, dari software yang ada.

Sehingga, selalu tidak bisa dijalankan

untuk implementasi requirement process
sebagai sebuah linear, dan penanganan
lebih pada tim software development.
Pada beberapa proyek, hal ini bisa saja
menghasilkan/berdampak dalam
kebutuhan yang digariskan sebelum
semua propertinya benar-benar dipahami.

Point yang paling penting dalam mengerti

requirement engineering adalah proporsi
yang signifikan dari requirement yang
akan berubah.

Kadang- kadang dikarenakan error pada

analisa, tapi ini sering akibat perubahan
lingkungan yang tak dapat dihindarkan.
Contohnya, operasi pelanggan atau
lingkungan bisnis, atau pasar dimana
software harus dijual.
 7.2:
Change management
Change management adalah pusat untuk
mengatur requirement.

Topik ini menggambarkan peran dari

change management, prosedur yang
diperlukan, dan analisa yang seharusnya
digunakan untuk usulan pengubahan.

Ini telah memperkuat hubungan Software

Configuration Management Knowledge
Area.
 7.3:
Requirements Attributes
Requirement sebaiknya tidak hanya terdiri dari
perincian dari apa yang dibutuhkan, tapi juga dari
informasi tambahan yang mana membantu
mengatur dan menafsirkan requirement tersebut.

Mungkin juga memasukkan informasi tambahan

seperti kesimpulan dari masing- masing
requirement, sumber daya dari masing- masing
requirement, dan perubahan sejarah.

Requirement attribute yang paling penting adalah

sebuah pengenal yang mana memperbolehkan
requirement tersebut unik dan jelas.
 7.4:
Requirements Tracing
Requirements Tracing diperhatikan dengan
pemulihan sumber daya requirement dan
memprediksikan efek dari requirement.

Tracing adalah pokok untuk melakukan analisa

ketika requirement berubah.

Sebuah requirement sebaiknya dapat di- trace ke

belakang. Contoh, dari software requirement
kembali ke system requirement.
Sebaliknya, requirement sebaiknya dapat
di- trace ke depan. Contoh, dari system
requirement ke software requirement yang
telah diuraikan, dan ke kode modul yang
mengimplementasikannya.

Requirement Tracing untuk proyek yang

khusus akan membentuk DAG ( Directed
Acyclic Graph) yang kompleks dari
requirement.
 7.5:
Measuring Requirement
Sebagai sebuah bentuk yang praktis, biasanya digunakan
untuk mempunyai beberapa konsep ‘volume’ requirement
untuk produk software.

Jumlah ini digunakan dalam mengevaluasi ukuran pada

perubahan dalam requirement, dalam estimasi harga
development atau tugas maintenance, atau
menyerderhanakan penggunaan sebagai denominator pada
pengukur lain.

FSM ( Functional Size Measurement ) adalah sebuah teknik

untuk mengevaluasi ukuran badan dari fungsi requirement.
IEEE Std 14143.1 mendefinisikan konsep dari FSM.

Informasi tambahan ukuran dan standard akan ditemukan

di Software Engineering Process Knowledge Area.