Review & Summarize REKAYASA KEBUTUHAN PERANGKAT LUNAK
•
ABOERYZAL AHMED KOESYAIRY
/ 5212100071
•
IMAM AFANDI AHMAD
/ 5212100703
Review & summarize the s o f t w a r e r e q u i r e m e n t s p e c i f i c a t i o n (SRS) documentation standards. Apa itu Software requierement specification (SRS)?
Dalam mengembangkan suatu perangkat lunak, suatu developer harus melewati suatu tahap yang disebut dengan tahap rekayasa kebutuhan perangkat lunak. Dengan adanya tahapan ini diharapkan seorang atau tim developer dapat mengembangkan perangkat lunak yang sesuai dengan kebutuhan dan keinginan penggunanya. Tahapan ini merupakan tahapan yang krusial bagi para pengembang perangkat lunak karena kegagalan terbesar dalam pengembangan perangkat lunak dikarenakan gagalnya pengembang memahami kebutuhan pelanggan atau pengguna perangkat lunak tersebut. Dalam proses rekayasa kebutuhan perangkat lunak ini seorang atau tim developer melakukan banyak kegiatan seperti analisa kebutuhan pengguna, melakukan studi kelayakan hingga membuat dokumen hasil dari rekayasa kebutuhan perangkat lunak tersebut.
Pembuatan dokumen spesifikasi perangkat lunak dari rekayasa kebutuhan perangkat lunak biasa disebut Software Requirement Specifications (SRS). Software Requirement Specifications (SRS) adalah dokumen yang berisi tentang berbagai kebutuhan yang harus ada dan dipenuhi oleh perangkat lunak yang akan dikembangkan oleh seorang atau tim pengembang sesuai dengan kebutuhan dari calon pengguna perangkat lunak itu sendiri. Dokumen spesifikasi kebutuhan perangkat lunak ini dibuat dengan cara menganalisa dan menggali informasi dari penggunanya.
Untuk membuat dokumen spesfikasi perangkat lunak ini seorang atau tim pengembang perangkat lunak harus mengikuti standar-standar yang ada. salah satu standar spesifikasi kebutuhan perangkat lunak yang sangat baik digunakan adalah standar IEEE .
Bagaimana Software requirement specification berdasarkan IEEE?
SRS sendiri berhubungan dengan kontrak, pengguna, pemasok/sponsor, dan customer. Untuk mengembangkan SRS itu sendiri ada hal-hal yang harus diperhatikan. hal-hal tersebut antara lain :
Sifat SRS (Nature SRS)
SRS dapat dilakukan oleh beberapa kastemer, sponsor, ataupun pengguna. Namun tidak dapat dilakukan dengan banyak pengembang dalam suatu pengembangan perangkat lunak.
Lingkungan SRS
SRS harus benar dalam menspesifikasikan kebutuhan. Selain itu SRS sebaiknya tidak menjelaskan setiap pelaksanaan pengembangan, dan SRS tidak harus memaksakan suatu hal dalam perangkat lunak yang dapat menyebabkan kendala.
Karakteristik
Dokumen spesifikasi kebutuhan perangkat lunak yang baik menurut IEEE memiliki karakteristik-karakteristik seperti berikut ini :
1. 2. 3. 4. 5. 6. 7. 8.
Correct (benar) Unambiguous (tidak ambigu, tapi jelas) Complete (lengkap) Consistent (konsisten) Ranked for importance and/or stability (prioritas penting dan atau stabilitas) Verifiable (dapat diverifikasi) Modifiable (bisa dimodifikasi) Traceable (bisa dilacak)
Penyusunan SRS secara bersama-sama
Penyusunan SRS dapat disusun atau dibuat bersama-sama dengan kastemer,pengguna, maupun pemasok/sponsor. Hal ini jika dilakukan dapat mempermudah pengembang dalam penyusunan SRS.
Evolusi SRS
Hal ini dilakukan untuk memperbaiki dan memvalidkan SRS yang sedang dibuat.
Prototyping
Dengan membuat prototipe, pengembang dapat mempermudah pengguna dalam mengevaluasi maupun memvalidasi perangkat lunak yang sedang dikembangkan daripada hanya melihat dokumen SRS yagn berupa kata-kata saja.
Mencantumkan desain sistem di SRS
Dengan mencantumkan desain, pengguna akan lebih mengerti tentang komponenkomponen yang ada di perangkat lunak yang sedang dikembangkan. Penyusun SRS
harus jelas dalam membedakan kendala desain perangkat lunak yang sedang dikembangkannya.
Pencantuman persyaratan proyek di SRS
Persyaratan-persyaratan dalam proyek dipisahkan dari SRS. Persyaratan proyek merupakan pemahaman antara pelanggan dan pemasok tentang kontrak dan hal-hal yang berkaitan dengan produksi perangkat lunak seperti biaya, metode pengembangan, Jaminan Kualitas, prosedur validasi dan kriteria verifikasi dll.
Contoh template dokumen SRS standard
1.
Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Product Scope
1.5 References
2.
Overall Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
menggunakan kembali dari proyek lain, kecuali mereka sudah didokumentasikan di tempat lain (misalnya, dalam visi dan lingkup dokumen atau rencana proyek).>
3.
External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communications Interfaces
4.
System Features
4.1 System Feature 1
4.1.1 Description and Priority 4.1.2 Stimulus/Response Sequences 4.1.3 Functional Requirements REQ-1: REQ-2:
4.2 System Feature 2 (and so on)
5.
Other Nonfunctional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
5.5 Business Rules
6.
Other Requirements
Appendix A: Glossary Appendix B: Analysis Models Appendix C: To Be Determined List
