Software Requirement Spesification
SOFTWARE REQUIREMENT SPESIFICATION
1. Definisi
Software
Requirement Spesification (SRS) atau Spesifikasi Kebutuhan
Perangkat Lunak (SKPL) adalah gambaran yang komprehensif dari tujuan yang
dimaksud dan lingkungan untuk perangkat lunak yang sedang dikerjakan. SRS
sepenuhnya menggambarkan tentang apa yang perangkat lunak akan lakukan dan
bagaimana hal itu berjalan. SRS meminimalkan waktu dan upaya yang diperlukan
oleh pengembang untuk mencapai tujuan yang diinginkan dan juga meminimalkan
biaya pembangunan. Sebuah SRS yang baik mendefinisikan bagaimana aplikasi akan
berinteraksi dengan perangkat keras sistem (hardware),
program lain (other program) dan pengguna manusia (human user) dalam berbagai situasi di dunia nyata. Parameter seperti
kecepatan operasi, waktu respon, ketersediaan, portabilitas, pemeliharaan,
jejak, keamanan dan kecepatan pemulihan dari efek samping akan dievaluasi.
Metode mendefinisikan SRS dijelaskan oleh IEEE (Institute of Electrical and Electronic Engineer) spesifikasi
830-1998.
SRS
juga berfungsi sebagai cetak biru untuk menyelesaikan sebuah proyek dengan
pertumbuhan biaya sesedikit mungkin. SRS juga sering disebut “parent” dokumen karena semua management dokumen berikutnya seperti
spesifikasi deasin, laporan kerja, spesifikasi arsitektur perangkat lunak,
pengujian dan validasi rencana dan rencana dokumentasi terkait dengan itu sangat
penting untuk dicatat. SRS berisi persyaratan fungsional dan nonfungsional
saja, tidak menawarkan saran desain, solusi yang memungkinkan untuk tekhnologi
atau bisnis, atau informasi lain selain dari apa yang tim pengembang pahami
yang menjadi kebutuhan sistem pelanggan.
2.
Tujuan
Sebuah
rancangan yang baik, penulisan SRS yang baik harus dapat menyelesaikan empat
tujuan utama :
a. Memberikan
umpan balik kepada pelanggan. SRS adalah jaminan pelanggan bahwa organisasi
pengembang memahai isu – isu atau permasalahan yang harus diselesaikan dan
sifat perangkat lunak yang dibutuhkan
untuk mengatasi masalah tersebut. Oleh karena itu, SRS harus ditulis dalam
bahasa alamin secara jelas yang mungkin juga termasuk grafik, table, diagram aliran dta, grafik
keputusan dan sebagainya.
b. Masalah
terurai menjadi beberapa bagian. Tindakan sederhana seperti menuliskan
persyaratan perangkat lunak dalam format yang dirancang dengan baik mengatur
informasi, menempatakan batas disekitar masalah, mengukuhkan ide, dan membantu
memecah masalah menjadi bagian – bagian yang teratur.
c. Berfungsi
sebagai masukan untuk spesifikasi desain. Seperti disebutkan sebelumnya. SRS
berfungsi sebagai dokumen induk ke dokumen berikutnya seperti, spesifikasi
desain perangkat lunak dan laporan kerja. Oleh karena itu, SRS harus berisi
rincian yang memadai dalam persyaratan sistem fungsional sehingga solusi desain
dapat dibuat. Ini berfungsi sebagai cek validasi produk dan SRS juga.
d. Berfungsi
sebagai dokumen induk untuk pengujian dan validasi strategi yang akan
diterapkan pada persyaratan untuk verifikasi.
Spesifikasi persyaratan perangkat lunak biasanya
dikembangkan pada tahap pertama dari “Requirement
Development” yang merupakan taham pengembangan produk awal dimana informasi
dikumpulkan tentang persyaratan apa saja yang dibutuhkan dan tidak. Tahap
pengumpulan informasi ini dapat mencakup kunjungan lapangan, kuisioner, survei,
wawancara, dan mungkin juga return-on-investment
(ROI) analisis atau analisis kebutuhan dari pelanggan atau lingkungan bisnis
klien saat ini. Spesifikasi yang sebenarnya ditulis setelah persyaratan telah
dikumpulkan dan dianalisis.
3.
Jenis informasi Dalam SRS
Beberapa
organisasi (termasuk IEEE) telah mengidentifikasi sembilan topik yang harus
diperhatikn ketika merancang dan menulis SRS :
·
Interface
·
Kemampuan fungsional (Functional Capabilities)
·
Tingkat kinerja (Performance Levels)
·
Struktur data / Elemen (Data Structures / Element)
·
Keselamatan (Safety)
·
Keandalan (Reliability)
·
Keamanan / privasi (Security / Privacy)
·
Kualitas
(Quality)
·
Kendala dan keterbatasan (Constraints
and Limitations)
Tapi bagaimana topik umun ini diterjemahkan kedalam
dokumen SRS ? Secara khusus apakah dokumen SRS ini sudah mencakup? Bagaimana
caranya terstruktur? Dan bagaimana anda akan memulai ? Sebuah dokumen SRS
biasanya mencapuk empat bahan, seperti yang dibahas pada bagian berikut :
Ø Template
Ø Metode
untuk mengidentifikasi kebutuhan dan menghubungkan sumber
Ø Aturan
operasi bisnis
Ø Matriks
traceability
4.
Langkah SRS
Langkah
pertama dan terbesar untuk menulis spesifikasi persyaratan perangkat lunak
adalah memilih template yang dapat Anda
fine tune untuk kebutuhan organisasi
anda (jika anda belum mempunyai satupun). Tidak ada “standar spesifikasi template” untuk semua proyek di semua
industri karena kebutuhan individu yang mengisi SRS yang unik tidak hanya dari
perusahaan ke perusahaan, tetapi juga dari proyek ke proyek dalam satu perusahaan.
Kuncinya adalah untuk memilih template
atau spesifikasi yang ada untuk memulai dan kemudian disesuaikan dengan
kebutuhan Anda.
Dalam
merekomendasikan menggunakan template
yang ada, tidak menganjurkan hanya menyalin template
dari sumber yang tersedia dan menggunakannya sebagai milik Anda sendiri.
Sebagai gantinya lebih baik agar menggunakan template yang tersedia sebagai panduan untuk mengembangkan diri
sendiri.
Kerangka
dasar SRS. Contoh ini merupakan adaptasi dan perluasan dari standar IEEE
830-1988 :
1.
Introduction
1.1 Purpose
1.2 Document
Convention
1.3 Itended
Audience
1.4 Additional
Information
1.5 Contac
Information / SRS Team Members
1.6 References
2.
Overall Description
2.1 Product
perpective
2.2 Product
functions
2.3 User
classer and characteristics
2.4 Operating
environment
2.5 User
environment
2.6 Design
/ implementation constraints
2.7 Assumption
and dependencies
3.
External Interface Requirements
3.1 User
interface
3.2 Hardware
interface
3.3 Software
interface
3.4 Communication
protocol and interface
4.
System Features
4.1 System
features A
4.1.1
Description and priority
4.1.2
Action and result
4.1.3
Functional requirement
4.2 System
features B
5.
Other Nonfuctional Requirement
5.1 Performance
requirement
5.2 Safety
requirement
5.3 Security
requirement
5.4 Software
quality attributes
5.5 Project
documentation
5.6 User
documentation
6.
Other Requirements
Appendix
A : Terminology/Glossary/Definition list
Appendix
B : To be Deternimed
|
Menunjukan
struktur template dari SRS. Ini
dicetak ulang melalui izin dari penciptanya yaitu Ken Rigby.
1. Scope
( Ruang lingkup )
|
1.1 Indentifikasi
. Identifikasi sistem dan perangkat lunak dimana dokumen ini berlaku,
termasuk, sebagaimana berlaku, nomor identifikasi, judul, singkatan, nomor
versi, nomor rilis.
1.2 Gambaran
sistem. Negara tujuan dari sistem atau subsistem dimana dokumen ini berlaku.
1.3 Ikhtisar
Dokumen. Merangkum tujuan dan isi dari dokumen ini. Dokumen ini terdiri dari
6 bagian :
·
Cakupan
·
Dokumen acuan
·
Persyaratan
·
Ketentuan kualifikasi
·
Persyaratan ketertelusuran
·
Catatan
Menjelaskan pertimbangan keamanan atau
privasi yang terkait dengan penggunanya.
|
2. Refensensi
Dokumen
|
2.1 Dokumen
proyek Mengidentifikasi sistem management proyek ini.
2.2 Dokumen
lainya
2.3 Precedence
(hal yang mendahului)
2.4 Sumber
dokumen
|
3. Requirement
( Kebutuhan )
|
Bagian
ini dibagi ke dalam paragraf untuk menentukan kebutuhan dari Computer
Software Configuration Item ( CSCI ). Yaitu karakterisitik dari CSCI yang
merupakan kondisi untuk penerimaannya. Kebutuhan CSCI adalah kebutuhan
perangkat lunak yang dihasilkan untuk memenuhi kebutuhan sistem dialokasikan
pada CSCI ini. Kebutuhan masing – masing harus diberi sebuah proyek –
identifikasi unik untuk mendukung pengujian dan mampu menelusur dan harus
dinyatakan sedemikian rupa bahwa tes objektif dapat didefinisikan untuk itu.
3.1 Kebutuhan
Negara dan mode
3.2 Kebutuhan
kemampuan CSCI
3.3 Kebutuhan
interface eksternal CSCI
3.4 Kebutuhan
interface internal CSCI
3.5 Kebutuhan
data internal CSCI
3.6 Kebutuhan
adaptasi
3.7 Kebutuhan
keselamatan
3.8 Kebutuhan
keamanan dan privasi
3.9 Kebutuhan
lingkungan CSCI
3.10
Kebutuhan sumber daya
Komputer
3.11
Faktor kualitas software
3.12
Desain dan implementasi kendala
3.13
Kebutuhan personil
3.14
Kebutuhan pelatihan terkait
3.15
Kebutuhan logistik terkait
3.16
Kebutuhan lain
3.17
Kebutuhan packaging (kemasan)
3.18
Kebutuhan precendence dan
criticality
|
4. Qualification
Provision (Ketentuan kualifikasi )
|
To
be determined ( akan ditentukan )
|
5. Requirement
Tracebility (Kebutuhan ketertelusuran )
|
To
be determined ( akan ditentukan )
|
6. Notes
( Catatan)
|
Bagian
ini berisi informasi yang bersifat umum atau penjelasan yang mungkin akan
membantu, tapi tidak wajib.
6.1 Petunjuk
penggunaan
6.2 Definisi
yang digunakan dalam dokumen ini
6.3 Sisipkan
disini daftar abjad dari definisi dan sumber. Jika berbeda dari sumber –
sumber yang dideklarasikan maka ditetapkan dalam “Standar Dokumentasi”
6.4 Perubahan
dari edisi terdahulu. Akan “tidak berlaku” untuk awal masalah. Revisi harus
menidentifikasi metode yang digunakan untuk menidentifikasi perubahan dari
edisi sebelumnya.
|
5. Mengidentisikasi dan Menghubungkan Kebutuhan Dengan Sumber
Seperti
disebutkan sebelumnya, SRS berfungsi untuk menentukan kebutuhan fungsional dan
nonfungsional produk. Kebutuhan fungsional masing – masing memiliki asal
darimana mereka dating, baik itu use case
(yang digunakan dalam analisis sistem untuk mengidentifikasi,
mengklarifikasi dan mengatur kebutuhan sistem, dan terdiri dari satu set
kemungkinan urutan interaksi antara sistem dan pengguna dalam lingkungan
tertentu dan terkait dalam tujuan tertentu), peraturan pemerintah, standar industri,
atau kebutuhan bisnis. Dalam mengembangkan SRS, anda perlu mengidentifikasi
asal usulnya dan menghubungkan mereka dengan kubutuhan yang sesuai dengan
mereka. Seperti praktek tidak hanya membenarkan kebutuhan tetapi juga membantu
meyakinkan stakeholder proyek bahwa
persyaratan yang sembrono akan disingkirkan dari spesifikasi.
Untuk
menghubungkan kebutuhan dengan sumber –sumber, masing – masing kebutuhan
termasuk dalam SRS harus diberi label dengan identifier unik yang dapat tetap berlaku dari waktu ke waktu
sebagai kebutuhan yang ditambahkan, dihapus, atau diubah. Seperti sistem
pelabelan membantu mempertahankan perubahan. Integritas record juga sekaligus merangkap sebagai sistem identifikasi untuk
mengumpulkan metrik. Anda dapat mulai memisahkan daftar identifikasi kebutuhan
yang mengikat / menghubungkan nomor identifikasi kebutuhan (ID) dengan
deskripsi kebutuhan. Nantinya ID kebutuhan dan deskripsi menjadi bagian dari
SRS itu sendiri dan kemudian menjadi bagian dari kebutuhan matrix
ketertelusuran (Requirement Traceability
Matrix). Menetapkan aturan bisnis untuk kontingensi dan tanggung
jawab
Sebuah
SRS dengan kualitas terbaik harus mencangkup rencana untuk kentingensi
terencana dan tidak terencana, serta definisi yang jelas dari tanggung jawab
masing – masing pihak. Kontingensi harus dilaksanakan. Beberapa aturan bisnis
lebih mudah untuk bekerja disekitar daripada yang lain ketika plan B harus
dijalankan. Misalnya, jika pelanggan ingin mengubah beberapa kebutuhan yang
terkait dengan peraturan pemerintah, hail itu mungkin tidak etis dan / atau
legal untuk mengikuti “the spirit of law”.
Banyak aturan pemerintah sebagai aturan bisnis, cukup jangan mebiarkan adanya
kompromi atau “ruang gerak “. Seorang manager proyek mungkin bertanggung jawab
untuk memastikan bahwa peraturan pemerintah yang berkaitan dengan kebutuhan
proyek ini diikuti. Namun jika kontingensi membutuhkan, maka tanggung jawab
untuk kebutuhan mungkin bergeser dari manager proyek ke regulatory attourney
(pengacara pengawas). SRS harus mengantisipasi tindakan seperti sejauh yang
terjauh mungkin.
6.
Membentuk Matrix Kebutuhan Ketertelusuran
Aturan bisnis untuk kontingensi dan tanggung jawab
dapat didefinisikan secara eksplisit dalam matrix kebutuhan ketertelusuran / Requirement Treaceability Matrix (RTM),
atau yang terkandung dalam dokumen terpisah yang direferensikan dalam matriks
Fungsi RTM sebagai semacam “chain of
custody” dokumen untuk kebutuhan dan dapat mencangkup penunjuk ke
penghubung dari kebutuhan ke sumber, serta penunjuk ke aturan bisnis. Misalnya,
setiap kebutuhan yang diberikan harus ditelusuri kembali ke kebutuhan tertentu,
baik itu use case, bisnis penting,
standar industri yang diakui, atau peraturan pemerintah. Seperti disebutkan
sebelumnya, menghubungkan kebutuhan dengan sumber meminimalkan atau bahkan
menghilangkan adanya kebutuhan palsu atau sembrono yang tidak mempunyai pembenaran
apapun. RTM adalah catatan (record)
yang saling memahami, tapi juga membantu dalam tahap pengembangan.
7.
Hal Yang Harus Diketahui Dalam Menulis SRS
Bahasa
alami spesifikasi kebutuhan perangkat lunak harus sama persis tanpa ambiguitas,
dan tepat karena spesifikasi desain, laporan kerja dan dokumen proyek lainya
adalah apa yang mendorong pengembangan produk akhir. Bahwa produk akhir harus
diuji dan divalidasi terhadap desain dan kebutuhan asli. Spesifikasi bahasa
yang memungkinkan untuk interpretasi kebutuhan utama tidak akan menghasilkan
produk akhir yang memuaskan dan kemungkinan akan menyebabkan pembengkakan
biaya, jadwal diperpanjang dan melewatkan tenggang waktu penyerahan.
Bahasa
karakteristik kualitas dari SRS yaitu :
Karakteristik
kualitas SRS
|
Pengertian
/ penjelasan
|
Complete
Lengkap )
|
SRS
mendefinisikan persis semua situasi go-live yang akan dihadapi dan kemampuan
sistem untuk berhasil mengatasinya
|
Consistent
(Konsisten)
|
Fungsi
kemampuan SRS dan tingkat kerja yang kompatibel, dan fitur kualitas
diperlukan (keamanan, keandalan, dll) tidak meniadakan fungsi –fungsi
kemampuan tersebut. Misalnya, satu – satunya pemangkas lindung nilai listrik
yang aman adalah salah satu yang disimpan dalam kotak dan tidak terhubung ke
kabel listrik atau stopkontak
|
Accurate
(Tepat/Akurat)
|
SRS
mendefinisikan persis kemampuan sistem dalam lingkungan dunia nyata, serta
bagaimana interface dan berinteraksi dengan itu. Aspek kebutuhan adalah
bidang masalah yang signifikan bagi banyak SRS.
|
Modifiable
( Dapat dimodifikasi )
|
Logis,
struktur hirarki SRS harus memfasilitasi modifikasi yang diperlukan (
pengelompokan masalah terkait bersama –sama memisahkan mereka dari masalah
yang tidak terkait membuat SRS mudah untuk dimodifikasi ).
|
Ranked
( mempunyai peringkat )
|
Kebutuhan
individu SRS secara hirarkis diatur menurut stabilitas, keamanan, persepsi
kemudahan/kesulitan pelaksanaan, atau parameter lain yang membantu dalam
desain itu dan dokumen berikutnya
|
Testable
( Dapat diuji )
|
SRS
harus dinyatakan sedemikian rupa sehingga criteria penilaian yang jelas
(lulus/gagal atau ukuran kuantitatif) dapat diturunkan dari SRS itu sendiri
|
Traceable
( Dapat ditelusuri )
|
Setiap
kebutuhan dalam SRS harus dapat diidentifikasi secara unik ke sumber ( use
case, kebutuhan pemerintah, standar industri, dll).
|
Unambigous
(Tidak ambigu/jelas)
|
SRS
harus berisi kebutuhan pernyataan yang dapat diinterpretasikan dalam satu
cara. Ini adalah bidang lain yang menciptakan masalah yang signifikan untuk
pengembangan SRS karena penggunaan bahasa alami/natural
|
Valid
( valid//sah)
|
Sebuah
SRS yang valid adalah satu dimana semua pihak dan peserta proyek dapat
memahami, menganalisis, menerima, atau menyetujui itu. Ini adalah salah satu
alas an utama SRS ditulis menggunakan bahasa alami
|
Verifiable
( Dapat diverifikasi )
|
Sebuah
SRS yang dapat diverifikasi konsisten
dari satu tingkat abstraksi ke yang lain. Sebagian besar attribute
spesifikasi yang subjektif dan penilaian konklusif kualitas memerlukan kajian
teknis oleh para ahli domain. Menggunakan indikator kekuatan dan kelemahan
memberikan beberapa bukti bahwa lebih suka attribut atau tidak hadir
|
Categories:
0 komentar:
Posting Komentar