What is the biggest mistake made when documenting requirements?
The biggest mistake is not having the right people in the room (or on the phone/skype) creating and reviewing requirements. It's very important to draw up a list of Stakeholders, and review the list at the beginning of each meeting to make sure that no one is left out. Better to cast your net far and wide, possibly including a few too many people (who will drop out of meetings if they don't feel they are making a contribution) rather than missing an important Stakeholder.
What is the difference between a functional and a non-functional requirement and why do I care?
A functional requirement is a requirement that you will experience using the system. For instance, you may have a requirement to view a specific report, or a requirement to data enter specific information using a web page. These are all functional requirements. Non-functional requirements are not related to your actually using the system. They could be requirements regarding overall solution costs and time frames. They could be technical requirements of one technology over another (browser based software, for example). Computer security, backup, recovery are typically documented as non-functional requirements. Why should you care? Functional and non-functional requirements are both important in considering your choice of software to purchase (or build).
What is the purpose of a Vendor Matrix?
A Vendor Matrix allows you to assess more than more one vendor's software offerings against your requirements. You can see which Vendor meets most or all of your needs. The Vendor Matrix provides a rational assessment of the strengths and weaknesses of each vendor's solution against your requirements. The matrix makes it very easy to spot which vendor is the best choice.
Is it mandatory to trace requirements throughout the life of the project?
It is not mandatory to trace requirements. However, if business users have gone through the effort of creating requirements, it would be helpful to know if the requirement was responded to in a vendor's RFP (Request for Proposal) response. If a vendor drops your requirement in their RFP response, and you decide to move ahead with that vendor, they may ask you for more money to implement the requirement later on because it wasn't included in their RFP response. Make sure, at the very least, that the vendor responds to ALL of your requirements in their RFP, and make sure your user acceptance test plan will test for every requirement to make sure no requirements were omitted in the delivered solution.