Presentation is loading. Please wait.

Presentation is loading. Please wait.

SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

Similar presentations


Presentation on theme: "SOFTWARE REQUIREMENTS SPECIFICATION (SRS)"— Presentation transcript:

1 SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

2 Outline Definition Who would use the document SRS Contents Good SRS
The benefits and goals Guidelines SRS Template

3 Overview We have to keep in mind that the goal is not to create great specifications but to create great products and great software. Can you create a great product without a great specification? Absolutely! Systems and software these days are so complex that to embark on the design before knowing what you are going to build is foolish and risky. Kita harus ingat bahwa tujuannya adalah bukan untuk menciptakan spesifikasi besar tetapi untuk menciptakan produk yang hebat dan perangkat lunak yang besar. Dapatkah Anda membuat produk hebat tanpa spesifikasi yang hebat? Absolutely! Sistem dan perangkat lunak dewasa ini begitu rumit sehingga untuk memulai desain sebelum mengetahui apa yang akan Anda untuk membangun adalah bodoh dan berisiko.

4 What is SRS? Definition An Software Requirements Specification is basically an organization's understanding (in writing) of a customer or potential client's system requirements and dependencies at a particular point in time (usually) prior to any actual design or development work. Sebuah SRS pada dasarnya merupakan pemahaman organisasi (secara tertulis) dari seorang pelanggan atau kebutuhan klien yang potensial dan ketergantungannya sebelum desain aktual atau pengembangan.

5 What is SRS? (cont’d) states in precise and explicit language those functions and capabilities a software system must provide, as well as states any required constraints by which the system must abide. functions as a blueprint for completing a project with as little cost growth as possible. menyatakan dalam bahasa yang tepat dan eksplisit fungsi-fungsi dan kemampuan sistem perangkat lunak harus dikembangkan, setara menyatakan kendala yang dibutuhkan oleh sistem yang harus dipatuhi. berfungsi sebagai cetak biru untuk menyelesaikan proyek dengan biaya sesedikit mungkin.

6 What is SRS (cont’d) Including:
Problem definition (what is the problem) Solution Statement (how to solve the problem) SRS contains functional and nonfunctional requirements only It doesn't offer design suggestions, possible solutions to technology or business issues, or any other information other than what the development team understands the customer's system requirements to be. SRS tidak menawarkan saran desain, kemungkinan solusi untuk masalah teknologi atau bisnis, atau informasi lain selain dari apa yang tim pengembang pahami kebutuhan sistem pelanggan untuk dikerjakan

7 Who would use? Customers
To define the software requirements [in fact, what actually they want/need] Suppliers To understand what customers want [then to give solutions] Inginkan/ butuhkan

8 What should the SRS address?
From the IEEE standard, the basic issues that the SRS writers shall address are the following: Functionality. What is the software supposed to do? External interfaces. How does the software interact with people, the system’s hardware, other hardware, and other software? Performance. What is the speed, availability, response time, recovery time of various software functions, so on Attributes. What are the portability, correctness, maintainability, security, so on.. Design constraints imposed on an implementation. Are there any required standards in effect, implementation language, policies for database integrity, resource limits, operating environment, so on.. Dari standar IEEE, isu-isu dasar bahwa penulis akan membahas SRS adalah sebagai berikut: Fungsionalitas. Apa yang harus dilakukan perangkat lunak? Eksternal interface. Bagaimana cara berinteraksi antara perangkat lunak dengan orang, sistem perangkat keras, perangkat keras lain, dan perangkat lunak lain? Kinerja. Berapa kecepatan, ketersediaan, waktu tanggap, waktu pemulihan dari berbagai fungsi perangkat lunak, dst Atribut. Apa portabilitas, ketepatan, kemampu-rawatan, keamanan, dst Kendala desain dikenakan pada implementasi Apakah ada standar yang dibutuhkan dalam efek, bahasa implementasi, kebijakan untuk database terintegritasi, batasan sumberdaya, lingkungan operasi, dst

9 What are the characteristics of a great SRS?
An SRS should be a) Correct b) Unambiguous c) Complete d) Consistent e) Ranked for importance and/or stability f) Verifiable g) Modifiable h) Traceable

10 Correct "Correct and Ever Correcting."
Of course you want the specification to be correct. No one writes a specification that they know is incorrect. The discipline is keeping the specification up to date when you find things that are not correct. Benar dan membenarkan Tentu saja Anda ingin spesifikasi benar. Tidak seorang pun menulis sebuah spesifikasi yang mereka tahu tidak benar. Disiplin adalah menjaga spesifikasi up to date ketika Anda menemukan hal-hal yang tidak benar.

11 Unambiguous An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation. Spending time on this area prior to releasing the SRS can be a waste of time. But as you find ambiguities - fix them Hanya satu interpretasi Boros waktu

12 Complete means COMPLETE!!
A simple judge of this is that is should be all that is needed by the software designers to create the software. SRS defines precisely all the go-live situations that will be encountered and the system's capability to successfully address them. Semua kebutuhan Semua situasi go-live

13 Consistent The SRS should be consistent within itself and consistent to its reference documents. Contradiction is a big no no Example: If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in another.

14 Ranked for Importance Very often a new system has requirements that are really marketing wish lists. Some may not be achievable. It is useful provide this information in the SRS. Sangat sering sebuah sistem baru memiliki kebutuhan tentang daftar pemasaran yang benar-benar diinginkan. Beberapa mungkin tidak dapat dicapai. Hal ini berguna memberikan informasi ini di SRS.

15 Verifiable Don't put in requirements like - "It should provide the user a fast response." or "The system should never crash." It is much better if you provide a quantitative requirement like: "Every key stroke should provide a user response within 100 milliseconds." Jangan masukkan dalam persyaratan seperti - "Ini harus menyediakan pengguna respons yang cepat." atau "Sistem seharusnya tidak pernah crash." Adalah jauh lebih baik jika Anda memberikan persyaratan kuantitatif seperti: "Setiap kunci stroke harus memberikan tanggapan pengguna dalam 100 milidetik."

16 Modifiable The logical, hierarchical structure of the SRS should facilitate any necessary modifications Grouping related issues together and separating them from unrelated issues makes the SRS easier to modify. Logis, struktur hirarkis SRS harus memfasilitasi modifikasi yang diperlukan Pengelompokan isu-isu yang terkait bersama-sama dan memisahkan mereka dari masalah-masalah yang tidak terkait SRS membuat lebih mudah untuk memodifikasi.

17 Traceable In most organizations, it is sometimes useful to connect the requirements in the SRS to a higher level document. Each requirement in an SRS must be uniquely identified to a source. Dalam kebanyakan organisasi, kadang-kadang berguna untuk menghubungkan persyaratan di SRS ke dokumen tingkat lebih tinggi. Setiap persyaratan dalam SRS harus secara unik diidentifikasi ke suatu sumber

18 What are the benefits of a Great SRS?
Establish the basis for agreement between the customers and the suppliers on what the software product is to do. Reduce the development effort. Provide a basis for estimating costs and schedules. Provide a baseline for validation and verification. Facilitate transfer. Serve as a basis for enhancement. Menetapkan dasar kesepakatan antara pelanggan dan pemasok pada apa produk perangkat lunak adalah dengan melakukan. Mengurangi usaha pembangunan. Memberikan dasar untuk memperkirakan biaya dan jadwal. Memberikan dasar untuk validasi dan verifikasi. Memfasilitasi transfer. Sebagai dasar untuk perangkat tambahan.

19 Goals It provides feedback to the customer.
It decomposes the problem into component parts. It serves as an input to the design specification. It serves as a product validation check. Memberikan umpan balik kepada pelanggan. Itu masalah terurai menjadi bagian-bagian. Ini berfungsi sebagai input untuk desain spesifikasi. Ini berfungsi sebagai validasi produk cek.

20 Goals (cont’d) It provides feedback to the customer.
An SRS is the customer's assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. Memberikan umpan balik kepada pelanggan. Sebuah SRS adalah pelanggan jaminan bahwa organisasi pembangunan memahami isu-isu atau masalah yang harus dipecahkan dan perilaku perangkat lunak yang diperlukan untuk mengatasi masalah tersebut. Oleh karena itu, SRS harus ditulis dalam bahasa alami, dalam cara yang jelas juga dapat mencakup grafik, tabel, data flow diagram, tabel keputusan, dan sebagainya.

21 Goals (cont’d) It decomposes the problem into component parts.
The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. Itu masalah terurai menjadi bagian-bagian. Tindakan sederhana menuliskan persyaratan perangkat lunak dalam format yang dirancang dengan baik mengatur informasi, tempat-tempat perbatasan di sekitar masalah, membeku ide-ide, dan membantu memecah masalah menjadi bagian-bagian secara teratur.

22 Goals (cont’d) It serves as an input to the design specification.
As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. Ini berfungsi sebagai input untuk desain spesifikasi. Seperti disebutkan sebelumnya, SRS berfungsi sebagai dokumen induk ke dokumen berikutnya, seperti spesifikasi desain perangkat lunak dan pernyataan kerja. Oleh karena itu, SRS harus mengandung cukup rinci dalam persyaratan sistem fungsional sehingga solusi desain dapat dibuat.

23 Goals (cont’d) It serves as a product validation check.
The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification. Ini berfungsi sebagai validasi produk cek. The SRS juga berfungsi sebagai dokumen induk untuk pengujian dan validasi strategi yang akan diterapkan pada persyaratan untuk verifikasi.

24 Guidelines Spend time specifying and documenting well software that you plan to keep. Keep documentation to a minimum when the software will only be used for a short time or has a limited number of users. Have separate individuals write the specifications (not the individual who will write the code). The person to write the specification should have good communication skills. Luangkan waktu dengan baik menetapkan dan mendokumentasikan perangkat lunak yang Anda berencana untuk tetap. Simpanlah dokumentasi untuk minimum ketika perangkat lunak hanya akan digunakan untuk waktu yang singkat atau memiliki sejumlah pengguna terbatas. Individu yang terpisah menulis spesifikasi (bukan individu yang akan menulis kode). Orang untuk menulis spesifikasi harus memiliki keterampilan komunikasi yang baik.

25 Guidelines (cont’d) Pretty diagrams can help but often tables and charts are easier to maintain and can communicate the same requirements. Take your time with complicated requirements. Vagueness in those areas will come back to bite you later. Conversely, watch out for over-documenting those functions that are well understood by many people but for which you can create some great requirements. Pretty diagram dapat membantu tetapi sering tabel dan grafik lebih mudah untuk menjaga dan dapat berkomunikasi persyaratan yang sama. Luangkan waktu Anda dengan persyaratan yang rumit. Ketidakjelasan di daerah itu akan datang kembali untuk menggigit Anda nanti. Sebaliknya, hati-hati selama lebih-mendokumentasikan fungsi-fungsi yang dipahami oleh banyak orang namun Anda dapat membuat beberapa persyaratan yang hebat.

26 Guidelines (cont’d) Keep the SRS up to date as you make changes.
Approximately 20-25% of the project time should be allocated to requirements definition. Keep 5% of the project time for updating the requirements after the design has begun. Test the requirements document by using it as the basis for writing the test plan.  Jauhkan SRS up to date saat Anda membuat perubahan. Kira-kira 20-25% dari waktu proyek harus dialokasikan untuk persyaratan definisi. Jauhkan 5% dari proyek waktu untuk memperbarui persyaratan setelah desain telah dimulai. Uji persyaratan dokumen dengan menggunakannya sebagai dasar untuk menulis rencana tes.

27 Based on the IEEE Standard:
SRS Template Based on the IEEE Standard: IEEE STD (Guide to Software Requirements Specification) We make a little modification, the simplified one Berdasarkan Standar IEEE: IEEE STD (Panduan untuk Software Requirements Specification) Kami membuat sedikit modifikasi, yang disederhanakan satu

28 SRS Template 1. Introduction 1.1 Purpose 1.2 Document Conventions 1.3 Intended Audience and Reading Suggestions 1.4 Project Scope 1.5 References 2. Overall Description 2.1 Product Perspective 2.2 Product Features 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 3. System Features 3.1 System Feature System Feature 2 (and so on)

29 SRS Template 4. External Interface Requirements 4.1 User Interfaces
4.2 Hardware Interfaces 4.3 Software Interfaces 4.4 Communications Interfaces 5. Other Nonfunctional Requirements 5.1 Performance Requirements 5.2 Safety Requirements 5.3 Security Requirements 5.4 Software Quality Attributes 6. Other Requirements Appendix A: Glossary Appendix B: Analysis Models Appendix C: Issues List

30 Our SRS Template Introduction Overall Description
Functional Requirement External Interface Requirements Other Requirements

31 Introduction 1.1 Purpose <Identify the product whose software requirements are specified in this document, including the revision or release number. Describe the scope of the product that is covered by this SRS, particularly if this SRS describes only part of the system or a single subsystem.> 1.2 Project Scope <Provide a short description of the software being specified and its purpose, including relevant benefits, objectives, and goals. Relate the software to corporate goals or business strategies. If a separate vision and scope document is available, refer to it rather than duplicating its contents here. An SRS that specifies the next release of an evolving product should contain its own scope statement as a subset of the long-term strategic product vision.> 1.3 References <List any other documents or Web addresses to which this SRS refers. These may include user interface style guides, contracts, standards, system requirements specifications, use case documents, or a vision and scope document. Provide enough information so that the reader could access a copy of each reference, including title, author, version number, date, and source or location.> Tujuan <Identifikasi produk perangkat lunak persyaratan yang ditetapkan dalam dokumen ini, termasuk revisi atau nomor rilis. Jelaskan ruang lingkup produk yang dicakup oleh SRS ini, terutama jika SRS ini hanya menjelaskan bagian dari sistem atau satu subsistem.> Lingkup Proyek 1,2 <Berikan penjelasan singkat tentang perangkat lunak yang ditentukan dan tujuannya, termasuk manfaat yang relevan, tujuan, dan tujuan. Menghubungkan perangkat lunak untuk tujuan perusahaan atau strategi bisnis. Jika terpisah lingkup visi dan dokumen ini tersedia, lihat dan bukan duplikasi isinya di sini. Sebuah SRS yang menentukan rilis berikutnya dari produk yang berkembang harus berisi pernyataan lingkup sendiri sebagai bagian dari jangka panjang visi produk strategis.> 1,3 Referensi <Daftar dokumen lain atau alamat Web yang mengacu SRS ini. Ini mungkin termasuk panduan gaya antarmuka pengguna, kontrak, standar, persyaratan sistem spesifikasi, kasus penggunaan dokumen, atau visi dan lingkup dokumen. Memberikan informasi yang cukup sehingga pembaca dapat mengakses salinan dari masing-masing referensi, termasuk judul, penulis, nomor versi, tanggal, dan sumber atau lokasi.>

32 Overall Description 2.1 Product Perspective <Describe the context and origin of the product being specified in this SRS. For example, state whether this product is a follow-on member of a product family, a replacement for certain existing systems, or a new, self-contained product. If the SRS defines a component of a larger system, relate the requirements of the larger system to the functionality of this software and identify interfaces between the two. A simple diagram that shows the major components of the overall system, subsystem interconnections, and external interfaces can be helpful. 2.2 Product Features <Summarize the major features the product contains or the significant functions that it performs or lets the user perform. Details will be provided in Section 3, so only a high level summary is needed here. Organize the functions to make them understandable to any reader of the SRS. A picture of the major groups of related requirements and how they relate, such as a top level data flow diagram or a class diagram, is often effective.> Produk Perspektif <Jelaskan konteks dan asal produk yang ditentukan dalam SRS ini. Sebagai contoh, negara apakah produk ini adalah lanjutan anggota keluarga produk, penggantian sistem yang ada tertentu, atau yang baru, produk yang mandiri. Jika SRS mendefinisikan sebuah komponen sistem yang lebih besar, berhubungan dengan persyaratan sistem yang lebih besar dengan fungsi software ini dan mengidentifikasi interface antara keduanya. Sebuah diagram sederhana yang menunjukkan komponen-komponen utama dari sistem keseluruhan, subsistem interkoneksi, dan antarmuka eksternal dapat membantu. 2,2 Fitur Produk <Ringkaskan fitur-fitur utama produk mengandung atau fungsi-fungsi penting yang melakukan atau membiarkan dilakukan pengguna. Rincian akan diberikan dalam Bagian 3, sehingga hanya ringkasan tingkat tinggi diperlukan di sini. Mengatur fungsi untuk membuat mereka dimengerti oleh setiap pembaca dari SRS. Sebuah gambar dari kelompok-kelompok utama berkaitan dengan persyaratan dan bagaimana mereka berhubungan, seperti tingkat atas data flow diagram atau class diagram, sering efektif.>

33 Overall Description 2.3 User Classes and Characteristics <Identify the various user classes that you anticipate will use this product. User classes may be differentiated based on frequency of use, subset of product functions used, technical expertise, security or privilege levels, educational level, or experience. Describe the pertinent characteristics of each user class. Certain requirements may pertain only to certain user classes. Distinguish the favored user classes from those who are less important to satisfy.> 2.4 Operating Environment <Describe the environment in which the software will operate, including the hardware platform, operating system and versions, and any other software components or applications with which it must peacefully coexist.> 2.5 Design and Implementation Constraints <Describe any items or issues that will limit the options available to the developers. These might include: corporate or regulatory policies; hardware limitations (timing requirements, memory requirements); interfaces to other applications; specific technologies, tools, and databases to be used; parallel operations; language requirements; communications protocols; security considerations; design conventions or programming standards (for example, if the customer’s organization will be responsible for maintaining the delivered software).> Kelas Pengguna dan Karakteristik <Mengidentifikasi berbagai kelas pengguna mengantisipasi bahwa Anda akan menggunakan produk ini. Pengguna kelas dapat dibedakan berdasarkan frekuensi penggunaan, bagian dari fungsi produk yang digunakan, keahlian teknis, keamanan atau hak istimewa tingkat, tingkat pendidikan, atau pengalaman. Jelaskan karakteristik yang bersangkutan masing-masing kelas pengguna. Syarat tertentu dapat berhubungan hanya untuk kelas pengguna tertentu. Membedakan kelas-kelas pengguna yang disukai dari mereka yang kurang penting untuk memuaskan.> 2,4 Operating Environment <Describe Lingkungan di mana perangkat lunak akan operate, termasuk platform, perangkat keras sistem operasi dan versions, dan perangkat lunak lainnya komponen atau aplikasi yang harus damai coexist.> Desain dan Implementasi 2,5 Kendala <Jelaskan setiap item atau isu yang akan membatasi pilihan yang tersedia untuk para pengembang. Hal ini mencakup: peraturan perusahaan atau kebijakan; hardware keterbatasan (waktu persyaratan, persyaratan memori); antarmuka ke aplikasi lainnya; teknologi khusus, alat-alat, dan database yang akan digunakan; operasi paralel; persyaratan bahasa; komunikasi protokol pertimbangan keamanan; desain konvensi atau pemrograman standar (misalnya, jika organisasi pelanggan akan bertanggung jawab untuk menjaga perangkat lunak yang dikirimkan).>

34 Overall Description 2.6 User Documentation
<List the user documentation components (such as user manuals, on-line help, and tutorials) that will be delivered along with the software. Identify any known user documentation delivery formats or standards.> 2.7Assumptions and Dependencies <List any assumed factors (as opposed to known facts) that could affect the requirements stated in the SRS. These could include third-party or commercial components that you plan to use, issues around the development or operating environment, or constraints. The project could be affected if these assumptions are incorrect, are not shared, or change. Also identify any dependencies the project has on external factors, such as software components that you intend to reuse from another project, unless they are already documented elsewhere (for example, in the vision and scope document or the project plan).> Dokumentasi 2,6 Pengguna <Daftar komponen dokumentasi pengguna (seperti user manual, on-line membantu, dan tutorial) yang akan dikirimkan bersama dengan perangkat lunak. Mengidentifikasi dokumentasi pengguna yang diketahui format pengiriman atau standar.> 2.7Assumptions dan Dependensi <Daftar diasumsikan setiap faktor (sebagai lawan dari fakta yang diketahui) yang dapat mempengaruhi persyaratan yang tercantum dalam SRS. Ini dapat mencakup pihak ketiga atau komponen komersial yang Anda rencanakan untuk digunakan, isu-isu di sekitar lingkungan pengembangan atau operasi, atau kendala. Proyek dapat terpengaruh jika asumsi ini tidak benar, tidak dibagi, atau perubahan. Juga mengidentifikasi proyek dependensi memiliki faktor-faktor eksternal, seperti komponen perangkat lunak yang Anda berniat untuk memakai ulang dari proyek lain, kecuali jika mereka sudah didokumentasikan di tempat lain (misalnya, dalam visi dan lingkup dokumen atau rencana proyek).>

35 Functional Requirement
3.1 Data Flow Context Diagram Introduction Inputs Process Outputs Data Flow Diagram Level Introduction Inputs Process Outputs Data Flow Diagram Level DFD Level 2 Process x - Introduction - Inputs - Process - Outputs DFD Level 2 Proses y N Data Flow Diagram Level N ….

36 Functional Requirement
3.2 Process Specification Process Specification Process Input Algorithm / Formula Related data store Output Process Specification Process N …. 3.3 Data Dictionary Data Element Name Alias Where-used/how-used Content description Data Element N

37 External Interface Requirements
4.1 User Interfaces <Describe the logical characteristics of each interface between the software product and the users. This may include sample screen images, any GUI standards or product family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification. 4.2 Software Interfaces <Describe the connections between this product and other specific software components (name and version), including databases, operating systems, tools, libraries, and integrated commercial components. Identify the data items or messages coming into the system and going out and describe the purpose of each. Describe the services needed and the nature of communications. Refer to documents that describe detailed application programming interface protocols. Identify data that will be shared across software components. If the data sharing mechanism must be implemented in a specific way (for example, use of a global data area in a multitasking operating system), specify this as an implementation constraint.> 4,1 User Interfaces <Jelaskan karakteristik logis dari setiap antarmuka antara produk perangkat lunak dan pengguna. Ini mungkin termasuk gambar layar sampel, setiap GUI standar atau gaya keluarga produk panduan yang harus diikuti, tata letak layar kendala, dan fungsi tombol-tombol standar (misalnya, bantuan) yang akan muncul di setiap layar, keyboard, tampilan pesan kesalahan standar, dan sebagainya. Tentukan komponen-komponen perangkat lunak yang antarmuka pengguna diperlukan. Rincian desain antarmuka pengguna harus didokumentasikan dalam spesifikasi antarmuka pengguna yang terpisah. 4,2 Software Interfaces <Jelaskan hubungan antara produk dan komponen perangkat lunak khusus lainnya (nama dan versi), termasuk database, sistem operasi, peralatan, perpustakaan, dan terintegrasi komponen komersial. Mengidentifikasi item data atau pesan yang masuk ke sistem dan keluar dan menjelaskan tujuan dari masing-masing. Jelaskan layanan yang diperlukan dan sifat komunikasi. Mengacu pada dokumen-dokumen yang menjelaskan antarmuka pemrograman aplikasi rinci protokol. Mengidentifikasi data yang akan digunakan bersama seluruh komponen perangkat lunak. Jika mekanisme berbagi data harus dilaksanakan dengan cara tertentu (misalnya, penggunaan area data global dalam sebuah sistem operasi multitasking), tentukan ini sebagai kendala pelaksanaan.>

38 Other Requirements <Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.> <Menetapkan persyaratan lainnya yang tidak tercakup di tempat lain di SRS. Hal ini dapat meliputi persyaratan database, internasionalisasi persyaratan, persyaratan hukum, menggunakan kembali tujuan proyek, dan sebagainya. Menambahkan bagian-bagian baru yang berhubungan dengan proyek.>

39 Review Definition Who would use the document SRS Contents Good SRS
The benefits and goals Guidelines SRS Template


Download ppt "SOFTWARE REQUIREMENTS SPECIFICATION (SRS)"

Similar presentations


Ads by Google