Sometimes I think I should simply have an automated link to Eric's blog because in most cases, whenever he writes something as he just did with Requirements, it ends up being something that everyone, including those in Project Management and software development, should read.
I especially like "The only way we ever know that a
feature absolutely must be in the product is when one of our Sales Guys calls
up and tells us that he already promised it."
Especially valuable is his explanation of what a spec should be, could be and usually really is.
Powered by ScribeFire.
Comments
A lot of hours were wasted on prototype/iterate cycles as I attempted to get the 'new feature' to look and feel like what the client (and my boss) wanted.
Today, (and to answer your question) I always use a requirements document. The document is non-technical and is usually drafted by business owners (not engineers). I find that forcing everyone (read: the business owners and managers) to think hard about a new feature up front can save engineers and quality staff many many hours of work. Even for small projects, a requirements document can be very handy.
I recommend creating a special page that lists each stakeholder with a space for a signature. The project will only get a green light once all stakeholders sign and date. Any change to the requirements after that point will require a special change request.