π₯ Requirement Analysis Questions and Answers
Question 1:
What is Requirement Analysis in Software Testing?
Answer:
1. Requirement Analysis is the process of understanding what needs to be built and tested.
2. It helps QA align with business expectations and user needs.
3. It acts as a foundation for writing test cases and scenarios.
4. Without it, testing becomes guesswork instead of validation.
5. It ensures clarity before execution starts.
2. It helps QA align with business expectations and user needs.
3. It acts as a foundation for writing test cases and scenarios.
4. Without it, testing becomes guesswork instead of validation.
5. It ensures clarity before execution starts.
π Example: Understanding login rules before writing test cases.
π‘ Good testing starts with understanding, not execution.
Question 2:
What is the main goal of Requirement Analysis?
Answer:
1. To understand requirements clearly and completely.
2. To remove ambiguity and confusion.
3. To identify missing or unclear details.
4. To prepare accurate and meaningful test scenarios.
5. To reduce defects in later stages.
2. To remove ambiguity and confusion.
3. To identify missing or unclear details.
4. To prepare accurate and meaningful test scenarios.
5. To reduce defects in later stages.
π‘ Clarity today prevents defects tomorrow.
Question 3:
What happens if requirements are misunderstood?
Answer:
1. Incorrect functionality gets developed.
2. Test cases become invalid or incomplete.
3. Bugs increase in production.
4. Rework and delays occur.
5. User experience and trust get impacted.
2. Test cases become invalid or incomplete.
3. Bugs increase in production.
4. Rework and delays occur.
5. User experience and trust get impacted.
π Example: Wrong validation implemented due to unclear requirement.
π‘ A small misunderstanding can create big failures.
Question 4:
Why is Requirement Analysis important?
Answer:
1. It ensures correct understanding of system behavior.
2. It reduces defects and rework.
3. It improves communication between teams.
4. It helps design better test cases.
5. It builds a strong quality foundation.
2. It reduces defects and rework.
3. It improves communication between teams.
4. It helps design better test cases.
5. It builds a strong quality foundation.
π‘ Strong analysis = strong product.
Question 5:
Can testing start without proper requirements?
Answer:
1. Yes, but it becomes risky and unreliable.
2. Testing will depend on assumptions.
3. Coverage will be incomplete.
4. Critical bugs may be missed.
5. Overall product quality will suffer.
2. Testing will depend on assumptions.
3. Coverage will be incomplete.
4. Critical bugs may be missed.
5. Overall product quality will suffer.
π‘ Testing without requirements is blind testing.
Question 6:
What risks arise from poor Requirement Analysis?
Answer:
1. Missing important scenarios.
2. Incorrect system behavior.
3. High defect leakage to production.
4. Increased cost and time.
5. Poor user experience.
2. Incorrect system behavior.
3. High defect leakage to production.
4. Increased cost and time.
5. Poor user experience.
π‘ Poor analysis leads to expensive mistakes.
Question 7:
What are functional requirements? Give real examples
Answer:
1. Functional requirements define what the system should do.
2. They describe features and user interactions.
3. They are directly testable.
4. They define system behavior.
5. They are core to application functionality.
2. They describe features and user interactions.
3. They are directly testable.
4. They define system behavior.
5. They are core to application functionality.
π Example: User should be able to login using valid credentials.
π‘ Functional requirements define system behavior.
Question 8:
How do you validate functional requirements?
Answer:
1. Map requirements with test cases.
2. Execute positive and negative scenarios.
3. Validate expected vs actual results.
4. Check business logic accuracy.
5. Ensure complete coverage of flows.
2. Execute positive and negative scenarios.
3. Validate expected vs actual results.
4. Check business logic accuracy.
5. Ensure complete coverage of flows.
π‘ Validation ensures correctness, not assumptions.
Question 9:
What are non-functional requirements?
Answer:
1. They define how the system performs.
2. They include performance, security, usability.
3. They focus on system quality attributes.
4. They impact user experience.
5. They ensure system stability and reliability.
2. They include performance, security, usability.
3. They focus on system quality attributes.
4. They impact user experience.
5. They ensure system stability and reliability.
π Example: System should load within 2 seconds.
π‘ Non-functional defines experience, not just behavior.
Question10:
Difference between functional & non-functional requirements?
Answer:
Functional and Non-functional requirements are two fundamental parts of any system, but they serve completely different purposes.
Functional requirements define what the system should do, meaning the actual features and operations of the application.
Non-functional requirements define how the system should perform, meaning the quality, performance, and behavior of the system under different conditions.
Both are equally important β functional ensures the system works, while non-functional ensures the system works well.
Functional Requirements
1. Define what the system does
2. Focus on features and functionality
3. Directly related to user actions
4. Easier to test using test cases
5. Based on business logic
6. Example: Login, Signup, Payment
π These answer the question: βSystem kya karega?β
1. Define what the system does
2. Focus on features and functionality
3. Directly related to user actions
4. Easier to test using test cases
5. Based on business logic
6. Example: Login, Signup, Payment
π These answer the question: βSystem kya karega?β
Non-Functional Requirements
1. Define how the system performs
2. Focus on quality attributes
3. Include performance, security, usability
4. Harder to test (need tools/environment)
5. Based on system behavior and constraints
6. Example: Response time, load handling
π These answer the question: βSystem kaise perform karega?β
1. Define how the system performs
2. Focus on quality attributes
3. Include performance, security, usability
4. Harder to test (need tools/environment)
5. Based on system behavior and constraints
6. Example: Response time, load handling
π These answer the question: βSystem kaise perform karega?β
π Real Example:
Functional: User should be able to login with valid credentials.
Non-functional: Login should happen within 2 seconds and support 1000 users at the same time.
Functional: User should be able to login with valid credentials.
Non-functional: Login should happen within 2 seconds and support 1000 users at the same time.
π‘ Functional makes the system work, Non-functional makes it reliable, fast, and usable.
Question 11:
Which is harder to test, functional & non-functional requirements?
Answer:
1. Non-functional requirements are harder to test.
2. They require tools and environment setup.
3. They involve performance and scalability.
4. They are not always clearly defined.
5. They need deeper analysis compared to functional testing.
2. They require tools and environment setup.
3. They involve performance and scalability.
4. They are not always clearly defined.
5. They need deeper analysis compared to functional testing.
π Example: Testing login is easy (functional), but testing system under 1000 users load is complex.
π‘ Hard problems reveal real system strength.
Question 12:
Why do teams ignore non-functional requirements?
Answer:
1. Teams focus more on functionality.
2. Time constraints and deadlines.
3. Lack of tools or expertise.
4. Requirements are not clearly defined.
5. Impact is underestimated.
2. Time constraints and deadlines.
3. Lack of tools or expertise.
4. Requirements are not clearly defined.
5. Impact is underestimated.
π Example: System works fine, but crashes under high traffic because performance was ignored.
π‘ Ignored performance becomes production issue.
Question 13:
What is a requirement document?
Answer:
1. It is a document that defines system requirements.
2. It includes features, behavior, and constraints.
3. It acts as a reference for development and testing.
4. It ensures all stakeholders are aligned.
5. It guides the entire project lifecycle.
2. It includes features, behavior, and constraints.
3. It acts as a reference for development and testing.
4. It ensures all stakeholders are aligned.
5. It guides the entire project lifecycle.
π Example: Document describing login, signup, and payment flow.
π‘ Requirement document is the project blueprint.
Question 14:
Types of requirement documents?
Answer:
1. BRD (Business Requirement Document)
2. SRS (Software Requirement Specification)
3. Use Case Documents
4. User Stories
5. Functional Specification Documents
2. SRS (Software Requirement Specification)
3. Use Case Documents
4. User Stories
5. Functional Specification Documents
π Example: BRD explains business need, SRS explains system behavior.
π‘ Different documents serve different clarity levels.
Question 15:
Who prepares requirement documents?
Answer:
1. Business Analysts (BA) mainly prepare them.
2. Product Owners contribute requirements.
3. Stakeholders provide business needs.
4. Developers may add technical details.
5. QA reviews and validates them.
2. Product Owners contribute requirements.
3. Stakeholders provide business needs.
4. Developers may add technical details.
5. QA reviews and validates them.
π Example: BA writes SRS after discussing with client and stakeholders.
π‘ Requirement is a collaboration, not a single role.
Question 16:
What is SRS (Software Requirement Specification)?
Answer:
1. SRS is a detailed document of system requirements.
2. It defines functional and non-functional requirements.
3. It acts as a contract between business and development.
4. It guides development and testing.
5. It ensures clarity and completeness.
2. It defines functional and non-functional requirements.
3. It acts as a contract between business and development.
4. It guides development and testing.
5. It ensures clarity and completeness.
π Example: SRS defines login rules, validation, and performance expectations.
π‘ SRS converts business idea into technical clarity.
Question 17:
What should an ideal SRS include and Who writes SRS?
Answer:
1. Functional requirements.
2. Non-functional requirements.
3. System flow and use cases.
4. Constraints and assumptions.
5. It is written mainly by Business Analyst.
2. Non-functional requirements.
3. System flow and use cases.
4. Constraints and assumptions.
5. It is written mainly by Business Analyst.
π Example: SRS includes login flow, validations, performance, and security rules.
π‘ A good SRS leaves no room for confusion.
Question 18:
How do you review SRS?
Answer:
1. Check for clarity and completeness.
2. Identify missing scenarios.
3. Validate business logic.
4. Ask questions for ambiguity.
5. Ensure testability of requirements.
2. Identify missing scenarios.
3. Validate business logic.
4. Ask questions for ambiguity.
5. Ensure testability of requirements.
π Example: Asking βWhat happens on invalid input?β if not defined.
π‘ Good QA questions improve requirements.
Question 19:
What is BRD (Business Requirement Document)?
Answer:
1. BRD defines business needs and goals.
2. It focuses on what business wants.
3. It is high-level document.
4. It is written before SRS.
5. It helps understand business perspective.
2. It focuses on what business wants.
3. It is high-level document.
4. It is written before SRS.
5. It helps understand business perspective.
π Example: BRD explains why an e-commerce system is needed.
π‘ BRD defines βwhyβ, not βhowβ.
Question20:
Difference between BRD and SRS?
Answer:
BRD (Business Requirement Document) and SRS (Software Requirement Specification) are two critical documents in the software development lifecycle, but they serve very different purposes.
BRD focuses on the business perspective β it explains why the system is needed and what problem it will solve. It is written in a simple, non-technical language so that business stakeholders can understand it easily.
SRS, on the other hand, focuses on the system perspective β it explains how the system will work in detail. It translates business requirements into technical specifications that developers and testers can use.
In simple terms:
π BRD = What and Why
π SRS = How
BRD (Business Requirement Document)
1. Focuses on business needs and objectives
2. Written in simple, non-technical language
3. Created by Business Analyst after stakeholder discussions
4. Defines the purpose and goal of the system
5. High-level document β does not go into technical details
6. Used by stakeholders, clients, and management
7. Answers: Why system is needed?
π Example thinking: βWe need an online shopping platform to increase sales.β
1. Focuses on business needs and objectives
2. Written in simple, non-technical language
3. Created by Business Analyst after stakeholder discussions
4. Defines the purpose and goal of the system
5. High-level document β does not go into technical details
6. Used by stakeholders, clients, and management
7. Answers: Why system is needed?
π Example thinking: βWe need an online shopping platform to increase sales.β
SRS (Software Requirement Specification)
1. Focuses on system behavior and functionality
2. Written in detailed and structured format
3. Created by Business Analyst / System Analyst
4. Defines functional and non-functional requirements
5. Low-level detailed document
6. Used by developers, testers, and technical teams
7. Answers: How system will work?
π Example thinking: βUser can login, add items to cart, apply discount, and complete payment.β
1. Focuses on system behavior and functionality
2. Written in detailed and structured format
3. Created by Business Analyst / System Analyst
4. Defines functional and non-functional requirements
5. Low-level detailed document
6. Used by developers, testers, and technical teams
7. Answers: How system will work?
π Example thinking: βUser can login, add items to cart, apply discount, and complete payment.β
π Real Example:
BRD: βWe need an e-commerce system where users can buy products online.β
SRS: βUser can register, login, search products, add to cart, apply coupons, and make payment using different methods.β
BRD: βWe need an e-commerce system where users can buy products online.β
SRS: βUser can register, login, search products, add to cart, apply coupons, and make payment using different methods.β
π‘ BRD gives vision, SRS gives execution.
π‘ BRD is for business understanding, SRS is for system implementation.
Question 21:
Who writes BRD?
Answer:
1. Business Analyst (BA) primarily writes BRD.
2. Inputs are taken from stakeholders and clients.
3. Product Owner may contribute requirements.
4. BA ensures business goals are clearly defined.
5. It is reviewed by stakeholders before approval.
2. Inputs are taken from stakeholders and clients.
3. Product Owner may contribute requirements.
4. BA ensures business goals are clearly defined.
5. It is reviewed by stakeholders before approval.
π Example: BA collects client needs and writes BRD for an e-commerce system.
π‘ BRD is written by BA but driven by business needs.
Question 22:
What is a use case?
Answer:
1. A use case describes how a user interacts with the system.
2. It defines step-by-step user actions.
3. It focuses on real-world scenarios.
4. It helps understand system flow.
5. It is used for designing test scenarios.
2. It defines step-by-step user actions.
3. It focuses on real-world scenarios.
4. It helps understand system flow.
5. It is used for designing test scenarios.
π Example: User logs in β selects product β adds to cart β makes payment.
π‘ Use case = real user journey.
Question:
Difference between use case & test case?
Answer:
Use Case and Test Case are closely related, but they serve different purposes in the software development and testing process.
A Use Case describes how a user interacts with the system in a real-world scenario. It focuses on the flow of actions from the user’s perspective and helps in understanding how the system should behave.
A Test Case, on the other hand, is used to verify whether the system behaves correctly. It contains detailed steps, expected results, and conditions to validate the functionality.
In simple terms:
π Use Case = Understanding the flow
π Test Case = Validating the flow
Use Case
1. Describes user interaction with system
2. Focuses on real-world scenarios
3. High-level representation of flow
4. Used during requirement analysis
5. Helps understand system behavior
6. Does not contain expected results
π Answers: User kya karega?
Example thinking: User logs in β selects product β makes payment
1. Describes user interaction with system
2. Focuses on real-world scenarios
3. High-level representation of flow
4. Used during requirement analysis
5. Helps understand system behavior
6. Does not contain expected results
π Answers: User kya karega?
Example thinking: User logs in β selects product β makes payment
Test Case
1. Validates system functionality
2. Focuses on correctness and validation
3. Detailed step-by-step instructions
4. Used during testing phase
5. Includes expected results
6. Helps find defects
π Answers: System sahi kaam kar raha hai ya nahi?
Example thinking: Enter valid username β expect login success Enter wrong password β expect error message
1. Validates system functionality
2. Focuses on correctness and validation
3. Detailed step-by-step instructions
4. Used during testing phase
5. Includes expected results
6. Helps find defects
π Answers: System sahi kaam kar raha hai ya nahi?
Example thinking: Enter valid username β expect login success Enter wrong password β expect error message
π Real Example:
Use Case: User logs into system, searches product, adds to cart, and completes payment.
Test Cases:
– Login with valid credentials β success
– Login with invalid password β error
– Add product to cart β product added
– Payment with valid card β success
Use Case: User logs into system, searches product, adds to cart, and completes payment.
Test Cases:
– Login with valid credentials β success
– Login with invalid password β error
– Add product to cart β product added
– Payment with valid card β success
π‘ Use Case shows the journey, Test Case checks the correctness.
π‘ Use Case is story, Test Case is verification.
Question 24:
Can you derive test cases from use cases?
Answer:
1. Yes, test cases can be derived from use cases.
2. Each step in use case can become a test scenario.
3. Positive and negative cases can be created.
4. Edge cases can be added based on flow.
5. It ensures complete coverage.
2. Each step in use case can become a test scenario.
3. Positive and negative cases can be created.
4. Edge cases can be added based on flow.
5. It ensures complete coverage.
π Example: Use case login β test cases: valid login, invalid password, empty fields.
π‘ Use cases are the base for test cases.
Question 25:
What is a user story?
Answer:
1. A user story is a short description of a feature.
2. It is written from user perspective.
3. It follows format: As a user, I want toβ¦
4. It focuses on value delivery.
5. It is used in Agile projects.
2. It is written from user perspective.
3. It follows format: As a user, I want toβ¦
4. It focuses on value delivery.
5. It is used in Agile projects.
π Example: As a user, I want to login so that I can access my account.
π‘ User story = feature from user view.
Question 26:
What are acceptance criteria?
Answer:
1. Acceptance criteria define conditions to accept a feature.
2. They describe expected behavior.
3. They guide testing and validation.
4. They remove ambiguity.
5. They ensure feature completeness.
2. They describe expected behavior.
3. They guide testing and validation.
4. They remove ambiguity.
5. They ensure feature completeness.
π Example: User should login only with valid credentials.
π‘ Acceptance criteria define success conditions.
Question 27:
Who writes user stories?
Answer:
1. Product Owner usually writes user stories.
2. Business Analyst may assist.
3. Stakeholders provide input.
4. Team refines stories during discussions.
5. QA helps in validation and clarity.
2. Business Analyst may assist.
3. Stakeholders provide input.
4. Team refines stories during discussions.
5. QA helps in validation and clarity.
π Example: Product Owner writes story for login feature.
π‘ User stories are team collaboration.