Downloaded 112 times
Uploaded byRam Paliwal
Srs (software requirement specification) in software engineering basics by ram k paliwal
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.
In this document
Powered by AI
Overview of software engineering and an introduction to Requirement Analysis and the need for SRS.
Definition of SRS, detailing functional and non-functional requirements, based on client agreement.
The necessity of SRS for defining software system interactions and the role of QA in testing.
Overview of essential characteristics: correctness, completeness, consistency, unambiguity, modifiability, verifiability, testability.
Explains correctness as covering all expectations, and completeness as ensuring full documentation.
Discusses ensuring no conflicts in SRS requirements and having clear, interpretable documentation.
Clarifies the need for adaptable SRS, the ability to measure requirements, and the ease of test case generation.
A list of resources and references for further reading on software requirements specification.
More Related Content
Similar to Srs (software requirement specification) in software engineering basics by ram k paliwal
Srs (software requirement specification) in software engineering basics by ram k paliwal
- 1. Software Engineering- Unit 1 REQUIREMENTANALYSIS 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 SoftwareRequirements 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 Needof 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 REQUIREMENTSPECIFICATION IN SOFTWARE ENGINEERING - UNIT 1 - BY RAM K PALIWAL 4
- 5. Software Requirement Specification Correctness Userreview 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 Requirementsin 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 SRSshould 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 SoftwareEngineering 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
- #3 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.
- #4 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.