SOFTWARE REQUIREMENTS

Kajian
disusun dalam rangka memenuhi salah satu tugas mata kuliah Rekayasa Perangkat Lunak
Dosen pengampu : Dr. Asep Wahyudin, S. Kom., M.T.

Oleh :
SEKAR MADU KUSUMAWARDANI 2007703

PROGRAM STUDI ILMU KOMPUTER

FAKULTAS PENDIDIKAN MATEMATIKA DAN ILMU PENGETAHUAN ALAM
UNIVERSITAS PENDIDIKAN INDONESA
2022
 Software requirements membahas seputas elisitasi, analisis, spesifikasi, dan validasi dari
kebutuhan software sampai manajemennya selama siklus hidup eseluruhan software. Area
pengetahuan kebutuhan software berhubungan erat dengan area pengetahuan dari Software
Design, Software Testing, Software Maintenance, Software Configuration Management,
Software Engineering Management, Software Engineering Process, Software Engineering
Models and Methods, dan Software Quality.
1. Software Requirements Fundamentals
a. Definition of a Software Requirements
Software requirements adalah properti yang ditunjukkan oleh sesuatu untuk
menyelesaikan beberapa masalah yang ada di dunia nyata. Ini bertujuan untuk
mengotomatisasi bagian dari suatu pekerjaan untuk mendukung proses bisnis
organisasi, memperbaiki kekurangan software yang ada, atau mengontrol perangkat.
b. Product and Process Requirements
Software requirements adalah kebutuhan atau kendala pada software yang akan
dikembangkan. Software requirements process pada dasarnya adalah kendala pada
pengembangan software. Software requirements process dapat dikenakan langsung
oleh organisasi pengembangan, pelanggan, atau pihak ketiga.
c. Functional and Nonfunctional Requirements
Persyaratan fungsional menggambarkan fungsi yang akan dijalankan oleh software
yang terkadang dikenal sebagai kemampuan atau fitur. Sedangkan persyaratan non-
fungsional adalah persyaratan yang bertindak untuk membatasi solusi yang juga
dikenal sebagai persyaratan kualitas.
d. Emergent Properties
Beberapa persyaratan mewakili sifat perangkat lunak yang muncul, yaitu persyaratan
yang tidak dapat ditangani oleh satu komponen tetapi bergantung pada bagaimana
semua komponen perangkat lunak saling beroperasi.
e. Quantifiable Requirements
Persyaratan perangkat lunak harus dinyatakan sejelas dan sejelas mungkin, dan, jika
sesuai, secara kuantitatif. Penting untuk menghindari persyaratan yang tidak jelas dan
tidak dapat diverifikasi yang bergantung pada interpretasi mereka pada penilaian
subjektif.
f. System Requirements and Software Requirements
Persyaratan sistem adalah persyaratan untuk sistem secara keseluruhan. Dalam sistem
yang berisi komponen perangkat lunak, persyaratan perangkat lunak diturunkan dari
persyaratan sistem. Area pengetahuan ini mendefinisikan "persyaratan pengguna"
secara terbatas, sebagai persyaratan pelanggan sistem atau pengguna akhir.
Sedangkan persyaratan sistem mencakup persyaratan pengguna, persyaratan
pemangku kepentingan lain, dan persyaratan tanpa sumber manusia yang dapat
diidentifikasi.
2. Software Requirements Process
a. Process Models
Secara khusus berkaitan dengan bagaimana aktivitas elisitasi, analisis, spesifikasi,
dan validasi dikonfigurasi untuk berbagai jenis proyek dan kendala. Topiknya juga
mencakup kegiatan yang memberikan masukan ke dalam proses persyaratan, seperti
pemasaran dan studi kelayakan.
b. Process Actors
 Topik ini memperkenalkan peran orang-orang yang berpartisipasi dalam proses
persyaratan. Proses ini pada dasarnya interdisipliner, dan spesialis persyaratan perlu
menengahi antara domain pemangku kepentingan dan rekayasa perangkat lunak.
Contohnya adalah pengguna, pelanggan, analisis pasar dan regulator
c. Process Support and Management
Bagian ini memperkenalkan sumber daya manajemen proyek yang dibutuhkan dan
dikonsumsi oleh proses persyaratan. Tujuan utamanya adalah untuk membuat
hubungan antara aktivitas proses dan masalah biaya, sumber daya manusia, pelatihan,
dan alat.
d. Process Quality and Improvement
Topik ini berkaitan dengan penilaian kualitas dan peningkatan proses persyaratan.
Tujuannya adalah untuk menekankan peran kunci yang dimainkan proses persyaratan
dalam hal biaya dan ketepatan waktu produk perangkat lunak dan kepuasan
pelanggan dengannya.
3. Software Requirements Elicitation
a. Requirements Sources
Persyaratan memiliki banyak sumber dalam perangkat lunak yang khas, dan sangat
penting bahwa semua sumber potensial diidentifikasi dan dievaluasi. Topik ini
dirancang untuk meningkatkan kesadaran akan berbagai sumber persyaratan
perangkat lunak dan kerangka kerja untuk mengelolanya.
b. Elicitation Techniques
Setelah sumber kebutuhan telah diidentifikasi, perekayasa perangkat lunak dapat
mulai memperoleh informasi kebutuhan dari mereka. Perhatikan bahwa persyaratan
jarang diperoleh yang sudah jadi. Sebaliknya, insinyur perangkat lunak memperoleh
informasi dari mana ia merumuskan persyaratan. Topik ini berkonsentrasi pada
teknik untuk membuat pemangku kepentingan manusia mengartikulasikan
persyaratan informasi yang relevan.
4. Software Requirements Analysis
Topik ini berkaitan dengan proses menganalisis persyaratan untuk mendeteksi dan
menyelesaikan konflik antara persyaratan, menemukan batas-batas perangkat lunak dan
bagaimana ia harus berinteraksi dengan lingkungan organisasi dan operasionalnya,
menguraikan persyaratan sistem untuk memperoleh persyaratan perangkat lunak.
a. Requirements Classification
Persyaratan dapat diklasifikasikan pada sejumlah dimensi, diantaranya :
- Fungsional atau non-fungsional
- Berasal dari satu atau lebih persyaratan tingkat tinggi atau properti
- Persyaratan ada pada produk atau proses
- Prioritas kebutuhan
- Ruang lingkup persyaratan
- Volatillitas/stabilitas
Klasifikasi lain dapat tergantung pada praktik normal organisasi dan penerapannya.
b. Conceptual Modeling
Pengembangan model masalah dunia nyata adalah kunci untuk analisis kebutuhan
perangkat lunak. Tujuannya adalah untuk membantu dalam memahami situasi di
mana masalah terjadi, serta menggambarkan solusi. Oleh karena itu, model
 konseptual terdiri dari model entitas dari domain masalah, dikonfigurasi untuk
mencerminkan hubungan dan ketergantungan dunia nyata. Beberapa jenis model
dapat dikembangkan termasuk diagram use case, model aliran data, model keadaan,
model berbasis tujuan, tindakan antar pengguna, model objek, model data, dan
banyak lainnya. Banyak dari notasi pemodelan ini merupakan bagian dari Unified
Modeling Language (UML). Pemilihan notasi pemodelan dilakukan berdasarkan sifat
masalah, keahlian software engineer, dan persyaratan proses pelanggan.
c. Architectural Design and Requirements
Desain arsitektural adalah titik di mana proses persyaratan tumpang tindih dengan
perangkat lunak atau desain sistem dan menggambarkan betapa tidak mungkinnya
memisahkan dua tugas dengan bersih.
d. Requirements Negotiation
Ini menyangkut penyelesaian masalah dengan persyaratan di mana konflik terjadi
antara dua pemangku kepentingan yang membutuhkan fitur yang saling tidak
kompatibel, antara persyaratan dan sumber daya, atau antara persyaratan fungsional
dan non-fungsional.
Prioritas persyaratan diperlukan, tidak hanya sebagai sarana untuk menyaring
persyaratan penting, tetapi juga untuk menyelesaikan konflik dan merencanakan
pengiriman bertahap, yang berarti membuat keputusan kompleks yang memerlukan
pengetahuan domain terperinci dan keterampilan estimasi yang baik. Namun,
seringkali sulit untuk mendapatkan informasi nyata yang dapat bertindak sebagai
dasar untuk keputusan tersebut. Selain itu, persyaratan sering bergantung satu sama
lain, dan prioritas bersifat relatif.
e. Formal Analysis
Topik ini juga terkait dengan Metode Formal di Area Pengetahuan Model dan
Metode Rekayasa Perangkat Lunak. Analisis formal telah berdampak pada beberapa
domain aplikasi, terutama yang memiliki sistem integritas tinggi. Ekspresi formal
persyaratan membutuhkan bahasa dengan semantik yang didefinisikan secara formal.
Penggunaan analisis formal untuk ekspresi persyaratan memiliki dua manfaat.
Pertama, memungkinkan persyaratan yang diungkapkan dalam bahasa ditentukan
secara tepat dan tidak ambigu, sehingga (pada prinsipnya) menghindari potensi salah
tafsir. Kedua, persyaratan dapat dipertimbangkan, memungkinkan properti yang
diinginkan dari perangkat lunak yang ditentukan untuk dibuktikan.
5. Software Requirements Specification
a. System Definition Document
Dokumen persyaratan pengguna atau dokumen konsep operasi ini mencatat
persyaratan sistem. Ini mendefinisikan persyaratan sistem tingkat tinggi dari
perspektif domain. Pembacanya mencakup perwakilan dari pengguna/pelanggan
sistem (pemasaran dapat memainkan peran ini untuk perangkat lunak yang
digerakkan oleh pasar), sehingga kontennya harus ditulis dalam istilah domain.
Dokumen tersebut mencantumkan persyaratan sistem bersama dengan informasi latar
belakang tentang tujuan keseluruhan untuk sistem, lingkungan targetnya, dan
pernyataan kendala, asumsi, dan persyaratan nonfungsional. Ini mungkin termasuk
model konseptual yang dirancang untuk menggambarkan konteks sistem, skenario
penggunaan, dan entitas domain utama, serta alur kerja.
b. System Requirements Specification
 Pengembang sistem dengan komponen perangkat lunak dan non-perangkat lunak
yang substansial—pesawat modern, misalnya—sering memisahkan deskripsi
persyaratan sistem dari deskripsi persyaratan perangkat lunak. Dalam pandangan ini,
persyaratan sistem ditentukan, persyaratan perangkat lunak diturunkan dari
persyaratan sistem, dan kemudian persyaratan untuk komponen perangkat lunak
ditentukan. Sebenarnya, spesifikasi persyaratan sistem adalah aktivitas rekayasa
sistem dan berada di luar cakupan Panduan ini.
c. Software Requirements Specification
Spesifikasi persyaratan perangkat lunak menetapkan dasar untuk kesepakatan antara
pelanggan dan kontraktor atau pemasok tentang apa yang harus dilakukan produk
perangkat lunak serta apa yang tidak diharapkan untuk dilakukan.
Spesifikasi persyaratan perangkat lunak memungkinkan penilaian persyaratan yang
ketat sebelum desain dapat dimulai dan mengurangi desain ulang nanti. Ini juga harus
memberikan dasar yang realistis untuk memperkirakan biaya produk, risiko, dan
jadwal.
6. Software Requirements Validation
a. Requirements Reviews
Mungkin cara validasi yang paling umum adalah dengan inspeksi atau tinjauan
dokumen persyaratan. Sekelompok peninjau ditugaskan untuk mencari kesalahan,
asumsi yang salah, ketidakjelasan, dan penyimpangan dari praktik standar.
Komposisi kelompok yang melakukan tinjauan itu penting dan mungkin membantu
untuk memberikan panduan tentang apa yang harus dicari dalam bentuk daftar
periksa .
b. Prototyping
Prototyping umumnya merupakan sarana untuk memvalidasi interpretasi engineer
perangkat lunak tentang persyaratan perangkat lunak, serta untuk memunculkan
persyaratan baru. Seperti elisitasi, ada berbagai teknik pembuatan prototipe dan
sejumlah poin dalam proses di mana validasi prototipe mungkin sesuai. Keuntungan
dari prototipe adalah bahwa mereka dapat membuatnya lebih mudah untuk
menafsirkan asumsi engineer perangkat lunak dan, jika diperlukan, memberikan
umpan balik yang berguna tentang mengapa mereka salah.
c. Model Validation
Biasanya diperlukan untuk memvalidasi kualitas model yang dikembangkan selama
analisis. Misalnya, dalam model objek, berguna untuk melakukan analisis statis
untuk memverifikasi bahwa jalur komunikasi ada di antara objek yang, dalam
domain pemangku kepentingan, bertukar data. Jika notasi analisis formal digunakan,
adalah mungkin untuk menggunakan penalaran formal untuk membuktikan sifat
spesifikasi.
d. Acceptance Tests
Properti penting dari persyaratan perangkat lunak adalah memungkinkan untuk
memvalidasi bahwa produk jadi memenuhinya. Persyaratan yang tidak dapat
divalidasi sebenarnya hanyalah "keinginan". Oleh karena itu, tugas penting adalah
merencanakan cara memverifikasi setiap persyaratan. Dalam kebanyakan kasus,
merancang tes penerimaan melakukan ini untuk bagaimana pengguna akhir biasanya
melakukan bisnis menggunakan sistem.