Beginner-Friendly Topic
Take your time - it's perfectly normal to re-read this topic 2-3 times. Try the interactive code editor below to run code yourself. Use the Q&A section to check your understanding before moving on. You've got this! 🚀
Phase 1: Requirement Analysis
Requirement Analysis is the first and most impactful STLC phase - and the one most often skipped by immature QA teams. During this phase, QA engineers analyze business requirements and design documents to understand what will be tested, identify ambiguities that would cause defects, and establish the testing scope. The output of this phase shapes everything that follows. An hour invested here saves days of rework later.
Activities in Requirement Analysis
- Study the Software Requirements Specification (SRS): Read every requirement carefully. Note requirements that are vague, contradictory, or untestable. 'The system shall load quickly' is not testable - flag it for clarification ('load within 2 seconds under 1000 concurrent users' is testable)
- Identify testable vs non-testable requirements: Non-functional requirements like performance thresholds must be quantified. Functional requirements must have clear pass/fail conditions. Requirements without measurable expected outcomes cannot be tested
- Identify test types needed: Does this feature require security testing? Performance testing? Accessibility? Identify all testing dimensions from requirements, not just functional behavior
- Create a Requirements Traceability Matrix (RTM) skeleton: List all requirements and map them to test scenarios. This skeleton will be filled in as test cases are written in Phase 3
- Document clarification questions: Write all ambiguities as formal questions to business analysts or product owners. Get written answers - undocumented verbal clarifications cause defects
Entry and Exit Criteria - Phase 1
Entry criteria (conditions that must be true before Phase 1 begins): Approved requirements document or user stories available, business analyst or product owner available for clarification, QA is staffed and available. Exit criteria (conditions that must be true before moving to Phase 2): All requirements reviewed and ambiguities documented, testability confirmed for all requirements, RTM skeleton created, requirement review report delivered to stakeholders. The exit criteria gate prevents the team from moving to test planning while requirements are still unclear - which would mean planning tests for the wrong functionality.
Gate: all tests must pass. Coverage minimum 80%.
Tip
Tip
Practice Phase 1 Requirement Analysis in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Phase 1 Requirement Analysis from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Phase 1 Requirement Analysis is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- Requirement Analysis is the first and most impactful STLC phase - and the one most often skipped by immature QA teams.
- Study the Software Requirements Specification (SRS): Read every requirement carefully. Note requirements that are vague, contradictory, or untestable. 'The system shall load quickly' is not testable - flag it for clarification ('load within 2 seconds under 1000 concurrent users' is testable)
- Identify testable vs non-testable requirements: Non-functional requirements like performance thresholds must be quantified. Functional requirements must have clear pass/fail conditions. Requirements without measurable expected outcomes cannot be tested
- Identify test types needed: Does this feature require security testing? Performance testing? Accessibility? Identify all testing dimensions from requirements, not just functional behavior