Stop writing requirements, start writing tests
After some interesting discussions I had at a customer the last few days about the use of workitems to track progress and capturing requirements, I started to reflect on what experiences I've had in projects. One of the classic problems has always been the requirements process. Are non-functional requirements any different than 'normal' requirements, how do you capture requirements and keep them up to date as the needs of your customer change over the course of the project? The classic way of handling requirements is of course the 'big' design up front. Especially in waterfall, everything is written down to such a level that an estimate can be given about the development cost (and hopefully also about testing cost) and any new insights by the customer happen as a change. After the project has finished of course. Expect one or more quite thick Word documents with hopefully some diagrams and start building this. When changes happen, the word documents should b...