Every good test starts with a good understanding of the requirement. If you misunderstand what the system should do, even perfectly executed tests will check the wrong thing. In this lesson you will learn how professional testers analyse requirements, convert them into test scenarios, and use a Requirement Traceability Matrix (RTM) to prove that every requirement has been tested. These skills are used in the first phase of the STLC and are expected from day one in a QA job.
Where Requirements Come From
| Document | Written by | Contains |
|---|---|---|
| BRD (Business Requirement Document) | Business analyst, with the client | High-level business needs and goals |
| SRS / FRS (Software or Functional Requirement Specification) | Business analyst or system analyst | Detailed functional and non-functional requirements |
| User stories with acceptance criteria | Product owner (Agile) | Small features written as "As a ... I want ... so that ..." |
| Wireframes and design mock-ups | UX designers | Screen layouts, field names, navigation |
Requirements are usually classified as functional (what the system must do, such as "User can reset password via OTP") and non-functional (how well it must do it, such as "OTP must arrive within 30 seconds").
How to Analyse a Requirement
Read every requirement with a critical eye and check it against these qualities:
- Clear: it has only one possible interpretation.
- Complete: it covers normal, error and edge situations.
- Consistent: it does not contradict other requirements.
- Testable: you can write a pass or fail check for it.
- Feasible: it can realistically be built within constraints.
Ambiguous: "The search results page should load fast." Testable: "The search results page should load within 3 seconds for 95% of requests on a 4G connection with up to 5,000 concurrent users." Only the second version can be clearly passed or failed.
Raising queries
When something is unclear, do not assume. Record the question in a requirement query log (sometimes called a clarification log) and get a written answer from the business analyst or product owner.
| Query ID | Requirement | Question | Raised by | Answer | Status |
|---|---|---|---|---|---|
| Q-01 | REQ-04 Apply coupon | Can more than one coupon be applied to the same order? | Tester | No, only one coupon per order | Closed |
| Q-02 | REQ-04 Apply coupon | Is the coupon code case-sensitive? | Tester | Pending with product owner | Open |
| Q-03 | REQ-06 OTP login | How many times can the user tap "Resend OTP"? | Tester | Maximum 3 times in 10 minutes | Closed |
Test Scenarios
A test scenario is a one-line statement describing what to test: a functionality or situation that can be tested. It does not include detailed steps or data. One scenario usually leads to several detailed test cases, which you will learn to write in the next lesson.
| Aspect | Test scenario | Test case |
|---|---|---|
| Level of detail | High-level, one line | Detailed steps, data and expected results |
| Answers | What to test | How to test |
| Example | Verify login with valid mobile number and OTP | Step 1: open app; Step 2: enter 9876543210; Step 3: enter OTP 482913; Expected: home screen displayed |
Example: Scenarios for "Apply coupon" on an e-commerce app
Requirement REQ-04: "A user can apply one valid coupon on the cart page. The discount is shown before payment. Expired or invalid coupons show an error message."
- TS-01: Verify applying a valid coupon reduces the cart total correctly.
- TS-02: Verify an expired coupon shows the correct error message.
- TS-03: Verify an invalid coupon code shows the correct error message.
- TS-04: Verify a second coupon cannot be applied when one is already applied.
- TS-05: Verify removing an applied coupon restores the original total.
- TS-06: Verify coupon with minimum cart value is rejected when the cart is below that value.
- TS-07: Verify the discounted amount is the amount actually charged on the payment screen.
Start each scenario with "Verify" or "Check", cover positive, negative and edge situations, think about integration with other modules (cart, payment, order history), and include the end-user view, not only the screen in front of you.
Requirement Traceability Matrix (RTM)
An RTM is a document, usually a spreadsheet, that maps each requirement to its test scenarios, test cases, execution status and defects. It answers a question every manager asks before release: "Have we tested every requirement?"
Types of traceability
- Forward traceability: requirements to test cases. Ensures every requirement is covered.
- Backward traceability: test cases back to requirements. Ensures no test is written for something outside scope.
- Bi-directional traceability: both directions in one matrix. This is the most common in practice.
Sample RTM
| Req ID | Requirement | Scenario IDs | Test case IDs | Execution status | Defect IDs |
|---|---|---|---|---|---|
| REQ-04 | Apply coupon on cart | TS-01 to TS-07 | TC-031 to TC-048 | 16 Pass, 2 Fail | BUG-112, BUG-115 |
| REQ-05 | Pay via UPI | TS-08 to TS-12 | TC-049 to TC-066 | 18 Pass | None |
| REQ-06 | Login with OTP | TS-13 to TS-17 | TC-067 to TC-080 | Not started | None |
| REQ-07 | Download invoice | None | None | Not covered | None |
From this RTM a test lead can instantly see that REQ-07 has no test coverage, REQ-06 has not been executed, and REQ-04 has two open defects. Requirement coverage here is 3 out of 4 requirements, or 75%, which signals a gap to fix before sign-off.
Benefits of an RTM
- Ensures 100% requirement coverage and highlights gaps early.
- Shows the impact of a requirement change: you know exactly which test cases to update.
- Links defects to requirements, helping prioritise fixes.
- Provides evidence for audits, clients and release sign-off.
Small teams maintain the RTM in a spreadsheet. Larger teams use test management tools linked to Jira, where requirements or user stories are linked to test cases and bugs automatically, and coverage reports are generated with a click.
