Why it's important? Can you write any examples of those definitions?
When you specify a requirement, it's important that it meets certain qualities, such as cohesiveness (only address a single thing), complete (does not lack any information needed to fulfill the desired outcome), traceable (it is documented and can be tracked through design, implementation, and maintenance in both directions), up-to-date, feasible (it can actually be implemented), unambiguous (multiple people reading it will have the same idea of the desired outcome), and verifiable (it can be tested and easily seen whether the requirement is complete).
Defining success or failure criteria for a requirement allows it to be complete, traceable, feasible, unambiguous, and verifiable. How can you know if the requirement can be met now or in the future? How can you know when you have implemented the feature or aspect of the system? How can you point to specific modules at any level that implement the requirement, either in a representation of the design or the implementation?
This is somewhat related to the concept of "definition of done" in the agile community, as well.
Can anybody provide examples of good requirements specification?
You can find a lot of information about requirements, including examples, in Karl Wiegers' Software Requirements and More About Software Requirements: Thorny Issues and Practical Advice. In addition, Wiegers' site Process Impact provides a number of goodies, such as sample documents and templates.