Answer.

Requirements testing is an important stage of manual testing because deficiencies here lead to costly mistakes in the future.

Background:

At the early stages of development, requirements for the product are documented (specifications, technical requirements). Improper or incomplete documentation gives rise to many problems during the implementation and testing phases.

Problem:

Requirements often turn out to be incomplete, ambiguous, or contradictory. This leads to misunderstandings and poor product implementation. Testers must identify such issues early on.

Solution:

Manual requirements testing includes:

Careful auditing of requirements for completeness, clarity, and consistency
Formulating clarifying questions to analysts and business clients
Documenting all assumed usage scenarios (positive/negative cases)
Applying requirement analysis techniques: consistency tables, traceability matrices, checklists for requirements

Key Features:

Identifying contradictions and "gaps" — detecting inconsistencies and situations not addressed in the requirements
Active communication with analysts and the team — clarifying details, explaining wordings
Formulating clear, testable requirements — requirements should be unambiguous, feasible, and measurable

Tricky Questions.

What does it mean for a requirement to be testable?

A testable requirement is one for which it can be definitively stated whether it has been met in the product or not. It should not contain abstractions, vague phrases, or unclear parameters.

Can requirements be considered of high quality if they are understood only by their authors?

No. High-quality requirements must be clearly understood by all team members (developers, testers, analysts, business stakeholders).

Is it the tester's responsibility to write or correct requirements?

No, the tester identifies issues and reports them to the responsible parties but should not rewrite requirements independently.

Common Mistakes and Anti-Patterns

Accepting requirements at face value without asking clarifying questions
Ignoring minor inconsistencies and assumptions
Failing to document identified "gaps" and contradictions, hoping that "developers will sort it out"

Real-Life Example

Negative Case

The tester received the requirements, did not check them for completeness and consistency, and overlooked ambiguous wordings. As a result, developers interpreted these requirements differently, leading to unconsidered scenarios that emerged only during the release.

Pros:

Time saved in the requirements writing stage

Cons:

Many revisions at later stages
High costs for bug fixing
Client dissatisfaction

Positive Case

During the familiarization stage with the requirements, the tester formulated questions for the business analyst, clarified contentious points, and helped add negative scenarios. This allowed avoiding many misunderstandings and significantly reduced the number of bugs in the release.