Srs (software requirement specification) in software engineering basics by ram k paliwal
•Download as PPTX, PDF•
4 likes•3,101 views
The document discusses software requirement specification (SRS), which defines the necessary functional and non-functional requirements for a software system from the user's perspective. An SRS is developed through an agreement between the customer and contractors. It should have characteristics like correctness, completeness, consistency, unambiguity, modifiability, verifiability and testability. The SRS is used to guide software development and testing.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Srs (software requirement specification) in software engineering basics by ram k paliwal
Similar to Srs (software requirement specification) in software engineering basics by ram k paliwal (20)
More from Ram Paliwal
More from Ram Paliwal (20)
Recently uploaded
Recently uploaded (20)
Srs (software requirement specification) in software engineering basics by ram k paliwal
- 1. Software Engineering- Unit 1 REQUIREMENT ANALYSIS AND DESIGN AND SPECIFICATION IN SOFTWARE ENGINEERING 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 1
- 2. Software Requirements Specification Software Requirements Specification (SRS) is a set of the necessary features for the future product, which, combined, describe its operating principles from the regular user perspective. The 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. The software requirement specification document consistent of all necessary requirements required for project development. 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 2
- 3. Software Requirement Specification Need of SRS ◦ 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. ◦ Using the 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. ◦ The SRS is approved by product owner personally, the end solution won’t differ a bit from an initial concept a client expected to get. 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 3
- 4. Character- istics of SRS correctness completeness consistency Unambiguous –ness Modifiability Verifiability Testability 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 4
- 5. Software Requirement Specification Correctness User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it covers all the requirements that are actually expected from the system. Completeness Completeness of SRS indicates every sense of completion including the numbering of all the pages, resolving the to be determined parts to as much extent as possible as well as covering all the functional and non-functional requirements properly. 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 5
- 6. Software Requirement Specification Consistency Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. Examples of conflict include differences in terminologies used at separate places, logical conflicts like time period of report generation, etc. Unambiguousness An SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some of the ways to prevent unambiguousness include the use of modelling techniques like ER diagrams, proper reviews and buddy checks, etc. 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 6
- 7. Software Requirement Specification Modifiability SRS should be made as modifiable as possible and should be capable of easily accepting changes to the system to some extent. Modifications should be properly indexed and cross-referenced. Verifiability An SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which every requirement is met by the system. For example, a requirement stating that the system must be user-friendly is not verifiable and listing such requirements should be avoided. Testability An SRS should be written in such a way that it is easy to generate test cases and test plans from the document. 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 7
- 8. References: https://www.tutorialspoint.com/software_engineering/software_requirements.htm?source=po st_page--------------------------- 7th edition Software Engineering A Practitioners Approach by Roger S. Pressman https://www.tutorialspoint.com/business_analysis/business_analysis_requirement_gathering_t echniques https://www.geeksforgeeks.org/software-engineering-requirements-elicitation/ https://jelvix.com/blog/software-requirements-specification http://www.softwaretestingclass.com/software-requirement-specification-srs/ 8/31/2019 SOFTWARE REQUIREMENT SPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 8
Editor's Notes
- Understanding the requirements of a problem is among the most difficult tasks that face a software engineer. When you first think about it, developing a clear understanding of requirements doesn’t seem that hard. After all, doesn’t the customer know what is required? Shouldn’t the end users have a good understanding of the features and functions that will provide benefit? Surprisingly, in many instances the answer to these questions is “no.” And even if customers and end-users are explicit in their needs, those needs will change throughout the project.
- Designing and building computer software is challenging, creative, and just plain fun. In fact, building software is so compelling that many software developers want to jump right in before they have a clear understanding of what is needed. They argue that things will become clear as they build, that project stakeholders will be able to understand need only after examining early iterations of the software, that things change so rapidly that any attempt to understand requirements in detail is a waste of time, that the bottom line is producing a working program and all else is secondary. What makes these arguments seductive is that they contain elements of truth.1 But each is flawed and can lead to a failed software project.