Answer.

Checking, validating, and agreeing on requirements is a continuous process throughout the entire project. A systems analyst must ensure that the requirements are:

• Complete and non-contradictory
• Technically feasible and aligned with the business logic
• Clearly understood by all stakeholders

The validation process of requirements includes:

• Joint reviews with the business (workshops, demos, interviews)
• Agreement of requirements with architects and the development team
• Traceability of requirements to tasks, tests, and releases (traceability)
• Use of acceptance criteria, test cases
• Obtaining formal confirmation (signatures, comments, "approved" statuses)

Requirements can be clarified or supplemented at any stage of the product lifecycle; it is important to keep them up-to-date and to correct them in case of changes.

Trick Questions.

Should requirements not change after approval?

This is incorrect. Changes in business tasks or technical conditions may require continuous updates to the requirements.

Is validation of requirements sufficient only from the business side?

No. It is important to agree on the requirements from the technical side regarding feasibility and compliance with architectural constraints.

Are acceptance criteria only for user stories?

No. Acceptance criteria apply to all types of requirements to verify the correctness of their implementation.

Typical Mistakes and Anti-Patterns

• Lack of formal acceptance criteria ("it works unless there are errors")
• Ignoring feedback from the development team during requirements preparation
• Lack of feedback on implemented requirements (retrospectives, demos)

Real Life Example

Negative Case: The analyst sends requirements for approval only to the business without discussing them with the developers. Significant technological difficulties arise in the final implementation, and some requirements turn out to be impossible. Pros: Time savings on discussions — Cons: Much rework, time loss, project delays.

Positive Case: Requirements undergo review by both the business and the technical team, all comments are documented, acceptance criteria are created, and at the demo, the requirements are accepted by all parties. Pros: Minimum misunderstandings, confidence in feasibility — Cons: More time spent on preparation and agreement.