Requirement Analysis
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.
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.
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.
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.
●
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.
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.
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. 2. 3. 4. 5. 6.
Read the requirement until you understand Identify the actors involved and their operations Identify the data flow and control transfer Identify the functional point Derive test conditions from the functional points Identify the scenarios based on data flow, control transfer, actors and test conditions Copyright © by QA InfoTech. All rights reserved.
Review and Baselining The Formal Review Process is : 1. 2. 3.
Identify and document any issues, concerns or suggestions. Capture these using a Standard Review form. Send the Review form to the appropriate recipients (QA Lead, SA/BA or CFT).
Baselining the Requirements : 1. 2. 3. 4. 5.
All the Items of Review form get reviewed by the SA/BA and/or any other intended members of CFT (as appropriate). The Review form is updated with comments from the SA/BA and sent back to the QA Team. This Review form keeps going back and forth till all the items get resolved and everyone is on the same page. The Requirement document is updated to incorporate any necessary changes based on the discussions through Feedback form. Base-lined version of the Requirement Document is generated.
Copyright Š by QA InfoTech. All rights reserved.
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.
Requirements Traceability Requirements Traceability & Matrix: 1. 2. 3.
Requirement Traceability refers to the mapping of requirements against Use Case and Test Case Documents. Traceability makes it possible to trace each requirement to design and code that particular requirement and test cases to test its implementation. 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.
Thank You
info@qainfotech.com www.qainfotech.com