Of Requirements

Requirements.  I dislike them.  Mostly because they're usually either

1. so poorly done as to be useless for determining the work to be done and for testing, or
2. so tediously lengthy and detailed that nobody is inclined to use them.

That said, there are many times in life one has to do unpleasant things.  Sometimes requirements are required.

 Therefore, if we must use them, I suggest (read insist) on the following:

• Make your requirements SMART requirements.  That is:  Specific, Measurable, Attainable, Relevant, and (I augment the last one) Testable/Trackable.  In short, if they don't tell you what you need to do, and you can't test them - toss them...  you are wasting everybody's time.
• Have a few requirements as possible, but no fewer.  More requirements definitely does not imply better.  Unless you're dealing with contracts, the purpose is to define the work such that everyone understands, and to be able to later test the work to see if it meets expectations.  Any more than that and you're wasting everybody's time - particularly your own.
• You don't necessarily have to have all the requirements up front.  It's fine to go back and realize you need some adjustments/additions.  That said, be mindful of scope creep. 
• Remember your clients.  Who are your clients for requirements?  In my shop, there are two clients:  The developer (and general project team), and the testers.  Write requirements so that they can do their jobs.

One method I find exceptionally helpful in requirement writing is to use the words "Must, Should, and May" in a very structured manner, as per RFC 2119.  This may seem a bit excessive, but it really helps me control my thinking about what requirements are essential (MUST haves), what would be really nice to have (SHOULD), and what we can have (May - Optional).  It also helps to make the requirement statements clear to everyone - particularly the developers/implementers and testers of the future system.