When you change them, the person(s) who signed the original document should also agree with, if not re-sign, with the changes made.

Requirements are written for those who create the solution not for those who have the problem

The final target audience for the requirements is the technical team. While the users or stakeholders need to agree that the requirements completely and accurately solve the problem, the requirements are written for those who are actually going to build the solution.

The techincal document must match the delivered solution

Throughout the development process, there will be changes to the product. There will be trade-offs during systems analysis and design. There will be technical changes due to the build process. Testing may introduce changes. While the business analyst must evaluate all the changes in light of a valid solution to the problem, many changes will be acceptable or unavoidable. The business analyst’s obligation is to modify the requirements to reflect the changed vision of the product. The requirements state the solution to the business problem. The system delivered must do what the requirements say. The system delivered must solve the problem.

There is certainly a lot of discussion in the agile communities about the value of a formal set of requirements. There is no argument among the agilists about the value of a well maintained and documented code base. Business analysts derive the same benefit from documenting and maintaining complete requirements, as developers do from maintaining their code base.

Analyze, Analyze, Analyze

Your last name is “analyst” and everything you do is about analysis, from preparing decision papers for upper-level management to analyzing problem statements to determine what the real problem is. You do not accept anything as fact without analyzing to make sure it is fact. Your ability to analyze is what separates you from the requirements recorders.