Remember that we've said, right at the beginning, that requirements have to be measurable, otherwise they are useless. Also, they need to be traceable and testable. From one diagram to another, we've seen how you can trace your requirements so you don't forget why you need such a complex option, and you don't feel tempted to replace it with an easier one, which would not suit the client.

One of the most common problems is called "requirements creep" - requirements that "creep" in, nobody knows why or from where, and they stick around, suffocating the options. This is why you need to keep track, in writing, of all the modifications made to all documents. Some requirements are legitimate, and were brought in later on, some were modified for good reasons, so you need to know, at all times, how to differentiate these from the statements that just came out of nowhere.

Another common trap is the so-called gold platting - more options, which bring very little value to the product, but increase the cost considerably. Some clients may be thrilled to have these options, but they won't miss them very much if they're not there - so you need to be careful about them.

A common sense rule says that you should be able to trace a requirement from the beginning to the finite product, in every stage. It's not enough for it to be present in the first and last stage, and it needs to occur in all the rest, to make sure it stayed consistent.

The functional criteria are easier to test, since you can see if the application fulfills the respective function or not. It's a bit trickier with the non-functional requirements, which is why you need to insist on making the measurable for the beginning. Instead of saying "the operation should be performed in the shortest possible period of time", define a time frame, in seconds, or minutes or whatever applies. Instead of saying "user-friendly" say "85% of second-grade children should be able to use the application". If you phrase it correctly from the beginning, you will have no problems testing it whenever necessary. Also, be realistic - don't ask for 100% success rate, particularly when you know that the system will have to perform the operation thousands of times per day. On the other hand, if you're dealing with maintenance for army rockets or with huge transactions involving the social health insurance budget for a large population, then you may want to aim for a success rate of 99%, or you'll be in trouble. Install as many additional safety systems are necessary, without putting too much strain on the application.

The security criteria are usually the most difficult to test and prove - it's fair to assume that, no matter how tight your security system is, somebody, given enough time and the appropriate knowledge, will find a way to cheat it. Again, defined your requirements realistically and make sure they are testable. Alternatively, provide additional upgrades whenever somebody reports a security breach - many developers do that.

Organize tests as often as possible, for the entire development duration - if a problem occurs, you want to identify it as soon as possible. Keep your original use cases readily available - they can be easily turned into test-case diagrams whenever necessary, at any phase.