Lecture 2.pptx Advance Software Engineering
- 1. DISCOVER . LEARN . EMPOWER SOFTWARE REQUIREMENT University Institute of Engineering DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING Bachelor of Engineering (Computer Science & Engineering) Subject Name: Software Engineering Subject Code: 22CST-313 Prepared by: Er. Puneet Kaur(E6913)
- 2. 2 Topics covered • Software requirement Specification • SRS document • Functional and non functional requirement
- 3. 3 SOFTWARE REQUIREMENT SPECIFICATION • Main aim of requirements specification: • Systematically organize the requirements arrived during requirements analysis. • Document requirements properly. • The SRS document is useful in various contexts: • Statement of user needs • Contract document • Reference document • Definition for implementation
- 4. 4 SRS DOCUMENT • The SRS document is known as black-box specification: • The system is considered as a black box whose internal details are not known. • Only its visible external (i.e. input/output) behaviour is documented. • SRS document concentrates on: • What needs to be done • Carefully avoids the solution (“how to do”) aspects. • The SRS document serves as a contract • Between development team and the customer. • Should be carefully written
- 5. 5 SRS Document • 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 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.
- 6. 6 SRS Document • 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.
- 7. 7 SRS Document • 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 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.
- 8. 8 Qualities of SRS • Correctness of SRS should be checked : Since the whole testing phase is dependent on SRS, it is very important to check its correctness. There are some standards with which we can compare and verify. • Ambiguity should be avoided. Sometimes in SRS, some words have more than one meaning and this might confused testers making it difficult to get the exact reference. It is advisable to check for such ambiguous words and make the meaning clear for better understanding.
- 9. 9 Qualities of SRS • Requirements should be complete. When tester writes test cases, what exactly is required from the application, is the first thing which needs to be clear. For e.g. if application needs to send the specific data of some specific size then it should be clearly mentioned in SRS that how much data and what is the size limit to send. • Consistent requirements.The SRS should be consistent within itself and consistent to its reference documents. If you call an input “Start and Stop” in one place, don’t call it “Start/Stop” in another. This sets the standard and should be followed throughout the testing phase.
- 10. 10 Qualities of SRS • Verification of expected result: SRS should not have statements like “Work as expected”, it should be clearly stated that what is expected since different testers would have different thinking aspects and may draw different results from this statement. • Testing environment: some applications need specific conditions to test and also a particular environment for accurate result. SRS should have clear documentation on what type of environment is needed to set up.
- 11. 11 Qualities of SRS • Pre-conditions defined clearly: one of the most important part of test cases is pre-conditions. If they are not met properly then actual result will always be different expected result. Verify that in SRS, all the pre- conditions are mentioned clearly. • Requirements ID: these are the base of test case template. Based on requirement Ids, test case ids are written. Also, requirements ids make it easy to categorize modules so just by looking at them, tester will know which module to refer. SRS must have them such as id defines a particular module.
- 12. 12 Qualities of SRS • Security and Performance criteria: security is priority when a software is tested especially when it is built in such a way that it contains some crucial information when leaked can cause harm to business. • Assumption should be avoided: sometimes when requirement is not cleared to tester, he tends to make some assumptions related to it, which is not a right way to do testing as assumptions would go wrong and hence, test results may vary. • Deletion of irrelevant requirements: there are more than one team who work on SRS so it might be possible that some irrelevant requirements are included in SRS. Based on the understanding of the software, tester can find out which are these requirements and remove them to avoid confusions and reduce work load. • Freeze requirements: when an ambiguous or incomplete requirement is sent to client to analyze and team gets a reply, that requirement result will be updated in the next SRS version and client will freeze that requirement. Freezing here means that result will not change again until and unless some major addition or modification is introduced in the software.
- 13. 13 Properties of a good SRS document • Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and complete. Verbose and irrelevant descriptions decrease readability and also increase error possibilities. • Structured: It should be well-structured. A well-structured document is simple to understand and modify. In practice, the SRS document undergoes several revisions to cope up with the user requirements. Often, user requirements evolve over a period of time. Therefore, to make the modifications to the SRS document easy, it is vital to make the report well-structured.
- 14. 14 Properties of a good SRS document • Black-box view: It should only define what the system should do and refrain from stating how to do these. This means that the SRS document should define the external behavior of the system and not discuss the implementation issues. The SRS report should view the system to be developed as a black box and should define the externally visible behavior of the system. For this reason, the SRS report is also known as the black-box specification of a system.
- 15. 15 Properties of a good SRS document • Conceptual integrity: It should show conceptual integrity so that the reader can merely understand it. Response to undesired events: It should characterize acceptable responses to unwanted events. These are called system response to exceptional conditions. • Verifiable: All requirements of the system, as documented in the SRS document, should be correct. This means that it should be possible to decide whether or not requirements have been met in an implementation.
- 16. 16 FUNCTIONAL REQUIREMENTS • Functional requirements describe: • A set of high-level requirements • Each high-level requirement: • takes in some data from the user • outputs some data to the user • Each high-level requirement: • might consist of a set of identifiable functions • For each high-level requirement: • Every function is described in terms of: • Input data set • Output data set • Processing required to obtain the output data set from the input data set.
- 17. 17 NON FUNCTIONAL REQUIREMENTS • Characteristics of the system which can not be expressed as functions: • Maintainability, • Portability, • Usability, etc. • Non functional requirements include: • Reliability issues, • Performance issues: • Example: How fast the system can produce results • so that it does not overload another system to which it supplies data, etc. • Human-computer interface issues, • Interface with other external systems, • Security, maintainability, etc.
- 18. 18 REFERENCES Reference Books: 1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage. 2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press. 3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition. Text Books: 4. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson and Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman. 5. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.
- 19. THANK YOU