Tweet

I've been concentrating on requirements gathering, & discovering that developers generally know nothing about this phase of the project, & are a very poor substitute for a real business analyst or product specialist. In the process, I've looked at software for tracking as well as document templates to ensure that those making the request know just how tricky it all is & how much work is involved - management or sales-folk.

If you don't have the requirement 'right' - by that, I mean enough information to know that you've understood the person making the request as far as possible - then you can't in all good conscience start work on designing a solution. That time would not only be wasted, but give the false impression that things were progressing in the project when it hadn't even started.

Then I read about the infamous No-Brown-M&Ms requirement, http://www.snopes.com/music/artists/vanhalen.asp, & it got me thinking - I should do that. I should ensure that requirements, if they are complex enough to allow, hold an Easter egg, or some such nugget of ludicrousness as a marker to indicate that the document/requirement is actually being read & understood. How else do you achieve this without a canary clause? (For the too-modern, this refers to taking a canary into a coal mine because it will die from the effects of leaking gas far quicker than a human.)

So, paint me yellow & listen to my song.