Experiment No 3. Prepare broad SRS (Software Requirements Software) for the above selected project. Practical Significance. Relevant Program Outcomes

Transcription

1 Experiment No 3 Prepare broad SRS (Software Requirements Software) for the above selected project. I Practical Significance A software requirements specification (SRS) is a document that captures complete description about how the system is expected to perform. It is usually signed off at the end of requirements engineering phase. A good SRS defines the how Software System will interact with all internal modules, hardware, communication with other programs and human user interactions with wide range of real life scenarios. II Relevant Program Outcomes All POs are listed. III Relevant Course Outcomes Prepare software requirement specifications of project. IV Practical Learning Outcomes Detailed description of all aspects of the software to be built. V Practical Skills Learn software requirement specification document consistent of all necessary requirements required for project development. VI Relevant Affective domain related Outcomes a) Consistent requirements b) Verification of expected result c) Testing environment d) Security and Performance criteria e) Deletion of irrelevant requirements f) Freeze requirements VII Minimum Theoretical Background A software requirements specification (SRS) is a detailed description of a software system to be developed with its functional and non-functional requirements. The SRS is developed based the agreement between customer and contractors. It may include the use cases of how user is going to interact with software system. The software requirement specification document consistent of all necessary requirements required for project development. To develop the software system we should have clear understanding of Software system. To achieve this we need to continuous communication with customers to gather all requirements.

2 A good SRS defines the how Software System will interact with all internal modules, hardware, communication with other programs and human user interactions with wide range of real li fe scenarios. Using the Software requirements specification (SRS) document on QA lead, managers creates test plan. It is very important that testers must be cleared with every detail specified in this document in order to avoid faults in test cases and its expected results. VIII Resources required Sr No Instrument Specification Quantity Remarks 1 Computer System Any Desktop PC with attached HardDisk 10 No. Whichever is available IX Procedure 1. If your organization does not have a standard Software Requirements Specifications document template, create one now 2. Meet with the subject matter experts/clients to gather the requirements. 3. Define the functions of the software. 4. Create use cases for the major sub-processes. For example, if you're designing an order entry system, use cases would consist of creating a new order, modifying an existing order and a customer order search. 5. Define the user interface. 6. Define any other interfaces such as hardware interfaces or other software system interfaces. 7. Define the process flow. 8. Determine any specific business rules. 9. Define the performance specification. 10. Create any diagrams needed to illustrate the process flow or elaborate on key requirements. 11. Compile the SRS document and have all necessary parties review or sign i t. X Precautions 1. Change the requirement carefully. 2. Save changes if required under the guidance of teacher. XI Description Software requirements specification (SRS) is a document that is created when a detailed description of all aspects of the software to be built must be specified before the project is to

3 commence. It is important to note that a formal SRS is not always written. In fact, there are many instances in which effort expended on an SRS might be better spent in other software engineering activities. However, when software is to be developed by a third party, when a lack of specification would create severe business issues, or when a system is extremely complex or business critical, an SRS may be justified. Karl Wiegers has developed a worthwhile template that can serve as a guideline for those who must create a complete SRS. A topic outline follows: 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) 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 XII Practical related Questions 1. Explain the importance of SRS.. Ans:

4

5 2. Write down the SRS of Hotel Management System Ans:

6

7

8

9

10 List Of Student Team Members: Marks Obtained Signature Of Teacher Process Related(15) Product Related(10) Total (25)