From SWEBOK v3
Perhaps the most common means of validation is by inspection or reviews of the requirements document(s). A group of reviewers is assigned a brief to look for errors, mistaken assumptions, lack of clarity, and deviation from standard practice. The composition of the group that conducts the review is important (at least one representative of the customer should be included for a customer-driven project, for example), and it may help to provide guidance on what to look for in the form of checklists.
Reviews may be constituted on completion of the system definition document, the system specification document, the software requirements specification document, the baseline specification for a new release, or at any other step in the process.
15288 6.4.3.3 c) 3)
"Feed back the analyzed requirements to applicable stakeholders for review". "Feedback helps ensure that the specified system requirements have been adequately captured and expressed. Confirmation is made that they are a necessary and sufficient response to stakeholder requirements and the Validation Process applied for the specific requirements."
"NOTE Explain and obtain agreement to the proposals to resolve conflicting, impractical and unrealisable stakeholder requirements." Get sign off.
15288 6.4.11
This is the description of the Validation Process mentioned above. It also describes the validation of the system / software that is done after design and implementation, which is what you will do in the Software Testing course. This validation is done based on the requirements so you want to keep that in mind when you write requirements.
29148 6.2.3.3 4) Establish with stakeholders that their requirements are expressed correctly.
NOTE This includes confirming that stakeholder requirements are comprehensible to originators and that the resolution of conflict in the requirements has not corrupted or compromised stakeholder intentions.
How to Conduct a Requirements Review bridging-the-gap