Software Requirement Spesification (SRS)

A. Pengertian Software Requirement Spesification

Secara sederhana, Software Requirement Specifications (SRS) adalah 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.

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.

IEEE membuat standar SRS agar dokumen penting itu tidak ambigu dan tentu saja komplit. Lengkap. Dengan standar itu, si penggguna dapat mencurahkan semua keinginannya terkait software tersebut dengan jelas dan akurat sehingga sang developer pun dapat memahami apa yang diinginkan pengguna dengan tepat. Bahkan, bagi perorangan, standar ini dapat membantunya dalam mengembangkan outline SRS yang baku khusus untuk perusahaannya, membantunya membuat dokumen SRS dengan format dan isi yang standar (minimal), serta membantunya mengembangkan rincian-rincian pendukung lainnya.

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 disain, 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.

Tujuan dasar dari Software Requirement Specification (SRS) adalah untuk menjembatani kesenjangan komunikasi antara klien dan pengembang, sehingga mereka memiliki visi bersama tentang perangkat lunak yang akan dibangun.

B. Tujuan SRS

Sebuah rancangan yang baik, penulisan SRS yang baik harus dapat menyelesaikan empat tujuan utama :

1.        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 data, grafik keputusan dan sebagainya.

2.        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.

3.        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.

4.        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, survey, 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.

C. Jenis Informasi yang Harus SRS Sertakan/Masukkan

Beberapa organisasi ( termasuk IEEE ) telah mengidentifikasi Sembilan topik yang harus diperhatikn ketika merancang dan menulis SRS :

1.        Interface

2.        Kemampuan fungsional ( Functional Capabilities )

3.        Tingkat kinerja ( Performance Levels )

4.        Struktur data / Elemen ( Data Structures / Element )

5.        Keselamatan ( Safety )

6.        Keandalan ( Reliability )

7.        Keamanan / privasi ( Security / Privacy )

8.        Kualitas  ( Quality )

9.        Kendala dan keterbatasan  ( Constraints and Limitations )

Sebuah dokumen SRS biasanya mencapuk empat bahan, seperti yang dibahas pada bagian berikut :

1.        Template

2.        Metode untuk mengidentifikasi kebutuhan dan menghubungkan sumber

3.        Aturan operasi bisnis

4.        Matriks traceability

D. Kerangka Dasar SRS

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

E. Struktur Template dari SRS

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: a.       Cakupan b.       Dokumen acuan c.        Persyaratan d.       Ketentuan kualifikasi e.        Persyaratan ketertelusuran f.        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.10Kebutuhan sumber daya komputer       3.11Faktor kualitas software       3.12Desain dan implementasi kendala       3.13Kebutuhan personil       3.14Kebutuhan pelatihan terkait       3.15Kebutuhan logistik terkait       3.16Kebutuhan lain       3.17Kebutuhan 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.

F. Karakteristik Mendasar dari Kualitas SRS

Tabel berikut menunjukan karakteristik mendasar dari kualitas SRS, yang awalnya dipresentasikan pada april 1998 Software Technology Conference presentation “Doing Requirements Right the Fisrt Time”. Dicetak ulang dengan izin dari Software Assurance Technology Center di NASA (http://www.gsfc.nasa.gov/) . karakteristik kualitas ini terkait erat dengan apa yang disebut sebagai “indikator kekuatan dan kelemahan” yang akan ditentukan selanjutnya.

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