The most common mistake is writing requirements in terms of the "how" rather than "what". A good requirement states what is needed, not how it should be done. If a requirement is written as a "what", then designers have maximum flexibility later on to use their creativity to generate several different ways to meet the requirement.
A second common mistake is to write requirements that are not verifiable or testable. A good way to double check whether a requirement is verifiable is to have our requirements reviewed by Quality Assurance staff. They will be happy to point out which requirements are not testable.
Business Analyst sometimes "feed" requirements to the Stakeholders. This results in the Business Analyst having high ownership in the requirements and the Stakeholders having low ownership. Sit back and let the Stakeholders do the talking and you do the listening. As a double check, have your Stakeholders prioritize their requirements afterwards. Stakeholders will prioritize requirements as "low priority" if they have low ownership.
The best way to write great requirements is to start writing them. Most analysts would agree that after years of writing requirements, there is always something to learn and ways to improve.
It could take as many as ten years to become a world class requirements champion, so start learning from your mistakes now!