Software Testing Requirement Analysis

43 %
57 %
Information about Software Testing Requirement Analysis

Published on January 19, 2018

Author: QA_IT


slide 1: Requirement Analysis slide 2: Agenda ● Understanding Requirements ● Types of Requirements ● Requirement - Good Characteristics ● WHY Requirements ● Reviewing and Analyzing Requirements ● Review and Baselining ● Benefits of Review and Analysis Process ● Requirements Traceability Copyright © by QA InfoTech. All rights reserved. slide 3: Understanding Requirements Requirements are used as inputs in the design stages of product development. Business requirements :- Describe in business terms what must be delivered or accomplished to provide value. Product requirements:- Describe the properties of a system or a product. Copyright © by QA InfoTech. All rights reserved. slide 4: Types of Requirements Functional requirements :- Describe the functionality to be executed by the system. Eg: Formatting some text or modulating a signal. Non-functional requirements :- Describe the characteristics of the system that the user cannot affect or immediately perceive. Also called as performance requirements or quality of service requirements’. Eg: Usability Availability Reliability Supportability and Maintainability. Copyright © by QA InfoTech. All rights reserved. slide 5: Requirement - Good Characteristics ● Unitary: The requirement addresses one and only one thing. ● Complete: The requirement is fully stated in one place with no missing information. ● Consistent: The requirement does not contradict any other requirement and is fully consistent with the authoritative external documentation. ● Non-Conjugated: The requirement is atomic i.e. it does not contain conjunctions. ● Traceable: The requirement meets all or part of a business’ need as stated by the stakeholders and as authoritatively documented. Copyright © by QA InfoTech. All rights reserved. slide 6: ● Current: The requirement has not been made obsolete by the passage of time. ● Feasible: The requirement can be implemented within the constraints of the project. ● Unambiguous: It is subject to one and only one interpretation. ● Mandatory: The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. ● Verifiable: The implementation of the requirement can be determined through one of four possible methods: inspection demonstration test or analysis. Copyright © by QA InfoTech. All rights reserved. slide 7: The WHY of Requirements Why Document Requirements ● Serves as a contract between the customer and the DEV/QA/SA/PM. ● Serves as a source of Use Cases Test Plans Test Cases. ● Serves to specify project goals and plan development cycles and increments. Why Review Requirements ● For ensuring compliance to all the aspects listed earlier as attributes of good requirements. Sample Requirement Documents / Types :- ● Requirement Documents can be in the form of Wireframes Flow Charts Detailed SRS Documents User Stories or can be in the form of Word documents Excel Spreadsheets PPTs Visio PDF HTMLs and many others Copyright © by QA InfoTech. All rights reserved. slide 8: Reviewing and Analyzing Requirements How do we analyze requirements ● By running the requirements through the following two standard activities while keeping in mind the attributes of good requirements. ● Requirements Review and Analysis involves two primary activities: ○ Validation ○ Verification Steps: 1. Read the requirement until you understand 2. Identify the actors involved and their operations 3. Identify the data flow and control transfer 4. Identify the functional point 5. Derive test conditions from the functional points 6. Identify the scenarios based on data flow control transfer actors and test conditions Copyright © by QA InfoTech. All rights reserved. slide 9: Review and Baselining The Formal Review Process is : 1. Identify and document any issues concerns or suggestions. 2. Capture these using a Standard Review form. 3. Send the Review form to the appropriate recipients QA Lead SA/BA or CFT. Baselining the Requirements : 1. All the Items of Review form get reviewed by the SA/BA and/or any other intended members of CFT as appropriate. 2. The Review form is updated with comments from the SA/BA and sent back to the QA Team. 3. This Review form keeps going back and forth till all the items get resolved and everyone is on the same page. 4. The Requirement document is updated to incorporate any necessary changes based on the discussions through Feedback form. 5. Base-lined version of the Requirement Document is generated. Copyright © by QA InfoTech. All rights reserved. slide 10: Benefits Benefits of Review Analysis Process: 1. Requirements gets reviewed and updated for any deviations from being an ideal requirement. 2. It helps ensure everyone involved in the project is on the same page right from the project’s inception. 3. Helps prevent implementation of any bad feature. 4. Helps prevent loss of time and effort later in the project life-cycle due to incorrect implementation that needs to be rolled-back or scrapped. 5. Serves as a blueprint and contract between all parties and as a point of reference for everyone involved in the project. 6. Any changes to the requirements at a later stage need to be approved through “Change Request” and that provides a cover to all the CFT members for variance in their deliverable schedules. Copyright © by QA InfoTech. All rights reserved. slide 11: Requirements Traceability Requirements Traceability Matrix: 1. Requirement Traceability refers to the mapping of requirements against Use Case and Test Case Documents. 2. Traceability makes it possible to trace each requirement to design and code that particular requirement and test cases to test its implementation. 3. Any changes to the requirements at a later stage ensures through the RTM that the appropriate UCs are updated as well. Benefits: ● Ensures that all requirements are implemented. ● Ensures that UCs and TCs are developed for all requirements. ● Helps in Impact analysis to determine the magnitude of a change in requirement on its corresponding UCs and TCs. Copyright © by QA InfoTech. All rights reserved. slide 12: Thank You

Add a comment

Related presentations