RINGKASAN TENTANG SOFTWARE REQUIREMENT SPESIFICATION
Dibuat Oleh : Nandar Kurniawan
NIM : C1A 110021
Daftar Isi
Definisi …………………………………………………………………………………………………………… 4
Tujuan ……………………………………………………………………………………………………………. 4
Jenis informasi yang harus SRS sertakan/masukan………………………………………… 5
Mulai dengan SRS template …………………………………………………………………………… 5
Mengidentifikasi dan menghubungkan kebutuhan dengan suber………………… 8
Menetapkan aturan bisnis untuk kontingensi dan tanggung jawab………………. 9
Membentuk matriks kebutuhan ketertelusuran……………………………………………. 9
Yang harus diketahui tentang menulis SRS…………………………………………………….. 10
Kesimpulan…………………………………………………………………………………………………….. 11
Daftar Tabel
Tabel 1. Contoh kerangka dasar SRS……………………………………………………………………………. 6
Tabel 2. Contoh garis besar SRS yang lebih rinci………………………………………………………….. 7
Tabel 3. Contoh identifikasi kebutuhan dan menghubungkan ke sumber………………….. 9
Tabel 4. 10 bahasa karakteristik kualitas SRS………………………………………………………………. 10
SOFTWARE REQUIREMENT SPESIFICATION
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.
Tujuan
Sebuah rancangan yang baik, penulisan SRS yang baik harus dapat menyelesaikan empat tujuan utama :
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.
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.
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
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.
Jenis informasi yang harus SRS sertakan/masukan
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
Mulai dengan SRS template
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, saya tidak menganjurkan hanya menyalin template dari sumber yang tersedia dan menggunakan nya sebagai milik anda sendiri. Sebagai gantinya saya menyarankan agar anda menggunakan template yang tersedia sebagai panduan untuk mengembangkan diri sendiri.
Tabel 1 menunjukan kerangka dasar SRS. Contoh ini merupakan adaptasi dan perluasan dari standar IEEE 830-1988:
Introduction
Purpose
Document Convention
Itended Audience
Additional Information
Contac Information / SRS Team Members
References
Overall Description
Product perpective
Product functions
User classer and characteristics
Operating environment
User environment
Design / implementation constraints
Assumption and dependencies
External Interface Requirements
User interface
Hardware interface
Software interface
Communication protocol and interface
System Features
System features A
Description and priority
Action and result
Functional requirement
System features B
Other Nonfuctional Requirement
Performance requirement
Safety requirement
Security requirement
Software quality attributes
Project documentation
User documentation
Other Requirements
Appendix A : Terminology/Glossary/Definition list
Appendix B : To be Deternimed
Tabel 1. Contoh kerangka dasar SRS
Tabel 2 menunjukan lebih rinci garis besar SRS, menunjukan struktur template dari SRS. Ini dicetak ulang melalui izin dari penciptanya yaitu Ken Rigby.
Scope ( Ruang lingkup )
Indentifikasi . Identifikasi sistem dan perangkat lunak dimana dokumen ini berlaku, termasuk, sebagaimana berlaku, nomor identifikasi, judul, singkatan, nomor versi, nomor rilis.
Gambaran sistem. Negara tujuan dari sistem atau subsistem dimana dokumen ini berlaku.
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.
Refensensi Dokumen
Dokumen proyek. Mengidentifikasi sistem management proyek ini.
Dokumen lainya
Precedence ( hal yang mendahului )
Sumber dokumen
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.
Kebutuhan Negara dan mode
Kebutuhan kemampuan CSCI
Kebutuhan interface eksternal CSCI
Kebutuhan interface internal CSCI
Kebutuhan data internal CSCI
Kebutuhan adaptasi
Kebutuhan keselamatan
Kebutuhan keamanan dan privasi
Kebutuhan lingkungan CSCI
Kebutuhan sumber daya komputer
Faktor kualitas software
Desain dan implementasi kendala
Kebutuhan personil
Kebutuhan pelatihan terkait
Kebutuhan logistik terkait
Kebutuhan lain
Kebutuhan packaging (kemasan)
Kebutuhan precendence dan criticality
Qualification Provision (Ketentuan kualifikasi )
To be determined ( akan ditentukan )
Requirement Tracebility (Kebutuhan ketertelusuran )
To be determined ( akan ditentukan )
Notes ( Catatan)
Bagian ini berisi informasi yang bersifat umum atau penjelasan yang mungkin akan membantu, tapi tidak wajib.
Petunjuk penggunaan
Definisi yang digunakan dalam dokumen ini
Sisipkan disini daftar abjad dari definisi dan sumber. Jika berbeda dari sumber – sumber yang dideklarasikan maka ditetapkan dalam "Standar Dokumentasi"
Perubahan dari edisi terdahulu. Akan "tidak berlaku" untuk awal masalah. Revisi harus menidentifikasi metode yang digunakan untuk menidentifikasi perubahan dari edisi sebelumnya.
Tabel 2. Contoh garis besar SRS yang lebih rinci
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 menidentifikasi asal usulnya dan menhubungkan 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 metrics. 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). Tabel 3 menggambarkan bagaimana bahan – bahan SRS bekerja sama.
ID No.
Paragraph No.
Requirement
Bussiness Rule Source
17
5.1.4.1
Understand / Communicate using SMTP protocol
IEEE STD xx-xxxx
18
5.1.4.1
Understand / Communicate using POP protocol
IEEE STD xx-xxxx
19
5.1.4.1
Understand / Communicate using IMAP protocol
IEEE STD xx-xxxx
20
5.1.4.2
Open at same rate as OE
Use case Doc 4.5.4
Tabel 3. Tabel contoh ini mengidentifikasi kebutuhan dan menghubungkannya ke sumber-sumber
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.
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, seperti contoh pada Tabel 3. Praktek semacam ini tidak meninggalkan keraguan mengenai tanggung jawab dan tindakan dalam kondisi tertentu karena mereka terjadi selama fase pengenbangan produk.
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.
Sebagai desain perangkat lunak dan pengembangan lanjutan, elemen desain dankode aktual harus diikat kembali dengan kebutuhan yang mendefinisikan mereka. RTM diselesaikan sebagai kemajuan pengembangan ; itu tidak bisa diselesaikan terlebih dahulu ( lihat Tabel 3).
Yang harus diketahui tentang 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.
Tabel 4 menunjukan karakteristik mendasar dari kualita 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
Tabel 4. 10 bahasa karakteristik kualitas SRS
Kesimpulan
Menulis top quality SRS dimulai dengan definisi yang lengkap dari kebutuhan pelanggan. Ditambah dengan bahasa alamia yang menggabungkan indikator kualitas kekuatan dan kelemahan. Belum lagi adopsi yang baik dari template SRS, professional komunikasi teknis dengan baik, terlatih dalam pengumpulan kebutuhan, desain template, dan penggunaan bahasa alami berada dalam posisi terbaik untuk menciptakan dan menambah nilai dokumentasi proyek tersebut.
11
