SI192401

SPESIFIKASI KEBUTUHAN
PERANGKAT LUNAK
Gita Mustika Rahmah, S.Kom., M.T
SPESIFIKASI PERANGKAT LUNAK
Tujuan:
 Menetapkan layanan apa yang dituntut dari sistem dan batasan
pada operasi pengembangan sistem

 Spesifikasi PL = rekayasa persyaratan

 Merupakan tahapan yang sangat kritis dari proses rekayasa
perangkat lunak
 Menghasilkan dokumen persyaratan yang merupakan
spesifikasi sistem
PROSES REKAYASA PERSYARATAN
STUDI KELAYAKAN
Input:
 Garis besar sistem

 Bagaimana sistem akan digunakan dalam organisasi

Output:
 Laporan rekomendasi apakah kegiatan tersebut layak diteruskan dengan
rekayasa persyaratan dan pengembangan sistem

Tujuan:
 Apakah sistem memberikan kontribusi bagi tujuan organisasi secara
keseluruhan
 Apakah sistem dapat diimplementasi dengan menggunakan teknologi terbaru
dalam batasan biaya dan jadwal
 Apakah sistem dapat diintegrasi dengan sistem lain yang sudah ada?
 STUDI KELAYAKAN
Cakupan:
 Penilaian informasi

Identifikasi informasi yang dibutuhkan atas tujuan yang telah ditetapkan

 Pengumpulan informasi

Informasi tentang:
a. Bagaimana organisasi mengatasi masalah jika sistem ini tidak
diimplementasi
b. Apa masalah dengan proses saat ini dan bagaimana sistem baru dapat
membantu meringankan masalah ini
c. Kontribusi langsung apa yang akan diberikan sistem bagi tujuan bisnis

d. Apa yang harus didukung oleh sistem, dan apa yang tidak perlu
 Penulisan laporan

Berisi rekomendasi apakah pengembangan sistem harus diteruskan

ELISITASI DAN ANALISIS PERSYARATAN
 Tahapan ini melibatkan berbagai macam orang dalam organisasi
(Stakeholder)

Kesulitan proses elisitasi dan analisis persyaratan:

 Stakeholder sering kali tidak mengetahui apa yang mereka inginkan
dari sistem komputer kecuali dalam hal-hal yang paling umum
 Stakeholder pada suatu sistem biasanya menyatakan persyaratan
dalam pemikiran mereka dan dengan pengetahuan implisit mengenai
pekerjaan mereka
 Beda stakeholder, beda pula persyaratannya

 Faktor-faktor politis dapat mempengaruhi persyaratan sistem

 Lingkungan ekonomi dan bisnis di mana analisis dilakukan bersifat

dinamis
ELISITASI DAN ANALISIS PERSYARATAN
Tiga teknik elisitasi dan analisis persyaratan

 Elisitasi
 Skenario

 etnografi
VALIDASI PERSYARATAN
Tipe pemeriksaan yang harus diterapkan pada saat proses validasi:
 Pemeriksaan validitas

Pemeriksaan yang dilakukan untuk mengidentifikasi fungsi tambahan

atau fungsi berbeda yang diinginkan

 Pemeriksaan konsistensi
Ada batasan-batasan yang saling bertentangan atau deskripsi yang
berbeda dari fungsi sistem yang sama

 Pemeriksaan kelengkapan
Dokumen persyaratan harus mencakup persyaratan yang
mendefinisikan semua fungsi dan batasan yang dimaksud oleh user
sistem
VALIDASI PERSYARATAN
 Pemeriksaan realisme
Pemeriksaan yang dilakukan untuk menjamin persyaratan dapat
diimplementasi yang memperhitungkan anggaran dan jadwal
pengembangan sistem

 Kemampuan dapat diverifikasi

Persyaratan sistem harus selalu dituliskan sedemikian rupa sehingga dapat
diverifikasi
VALIDASI PERSYARATAN
Teknik validasi persyaratan:
 Peninjauan persyaratan

 Pembuatan prototipe

 Pembuatan test-case

 Analisis konsistensi terotomasi

Aspek yang penting dari sistem engineering adalah merubah

kebutuhan user menjadi jelas, ringkas, dan dapat
diverifikasi.
REQUIREMENT (IEEE STANDARD)
1. Suatu kondisi atau kemampuan yang diperlukan oleh user
untuk memecahkan masalah atau mencapai tujuan
2. Suatu kondisi atau kemampuan yang harus dipenuhi atau
dimiliki oleh sistem atau komponen sistem untuk memenuhi
kontrak, standard, spesifikasi atau dokumen formal lain
3. Gambaran yang terdokumentasi dari kondisi atau kemampuan
yang disebut pada kondisi 1 dan 2 diatas
REQUIREMENT
Menurut sommerville [SOMM]
 Spesifikasi dari apa yang harus diimplementasikan, deskripsi
bagaimana sistem harusnya berkerja atau bagian-bagian yang
ada didalam sistem, bisa juga dijadikan batasan dalam proses
pengembangan sistem.
REQUIREMENT
Beberapa macam requirement:
 User Requirement

Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-

batasan perasionalnya. Pernyataan ini dapat dilengkapi dengan
gambar/diagram yang dapat dimengerti dengan mudah.
 System Requirement

Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang

ditulis secara detil. System requirement document sering disebut
functional specification (spesifikasi fungsional), harus menjelaskan
dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan
pembangun.
 Software Design Specification

Gambaran abstrak dari rancangan software yang menjadi dasar bagi

perancangan dan implementasi yang lebih detil.
REQUIREMENT
Secara umum, requirement dibagi menjadi 2 yaitu:

 Functional requirement
Menjelaskan tentang fungsional dari sistem

 Non-Functional requirement
Yang berperan untuk memberi batasan pada solusi atau biasa
disebut quality requirement
REQUIREMENT
Requirement biasanya ditulis dalam format (contoh dalam bahasa
inggris) :
 The System shall provide ……..

 The System shall be capable of ……..

 The System shall weigh ……..

 The Subsystem #1 shall provide ……..

REQUIREMENT
 Requirement yang tidak lengkap sangat mungkin terjadi karena team yang menulis
requirement terfokus pada bagian tertentu pada sistem

Untuk menghidari ketidak lengkapan requirement perlu diperhatikan detil-detil berikut

ini

 Functional . Reliability
 Performance . Maintainability

 Interface · Operability

 Environment · Safety

 Facility · Regulatory

 Transportation · Security

 Deployment · Privacy

 Training · Design constraints

 Personnel
SYSTEM REQUIREMENTS
SPECIFICATION DOCUMENT
 Dokumen System Requirements Spesification (SRS) atau
Spesifikasi Kebutuhan Perangkat Lunak (SKPL) merupakan
 dokumen yang menjelaskan tentang berbagai kebutuhan yang
harus dipenuhi oleh suatu software.
 Dokumen ini dibuat oleh developer (pembuat software) setelah
menggali informasi dari calon pemakai software.
 Pembuatannya pun seharusnya mengikuti standar yang ada dan
paling diakui oleh para praktisi rekayasa software di dunia.
SYSTEM REQUIREMENTS
SPECIFICATION DOCUMENT
SRS yang baik akan bermanfaat bagi customer, supplier, ataupun
perorangan, yaitu:
 Sebagai bentuk perjanjian antara customer dan supplier tentang
software apa yang akan dibuat
 Mengurangi beban dalam proses pengembangan software

 Sebagai bahan perkiraan biaya dan rencana penjadwalan

 Sebagai dasar validasi dan verifikasi software di ujung

penyelesaian proyek nantinya
SYSTEM REQUIREMENTS
SPECIFICATION DOCUMENT
 Memfasilitasi transfer, semisal software tersebut ingin
ditransfer ke pengguna atau mesin-mesin yang lain. Customer
pun merasa mudah jika ingin mentransfer software ke bagian-
bagian lain dalam organisasinya. Bahkan, jika terjadi
pergantian personil developer, proyek dapat mudah ditransfer
ke personil baru dengan memahami SRS ini.

 Mendasari perbaikan produk software di kemudian hari. Jadi,

kadang SRS boleh diperbaiki dengan alasan dan mekanisme
tertentu serta atas kesepakatan antara customer dan developer.
Thank You…. 