What is the point of having requirements if the designs are not made according to them?
Where is the traceability between requirements and design? (I've never seen requirements called out in a design. Most times I don't think the developer even refers to them, only to the mental model in their head. It's a chore, not a useful process.)
When stakeholders read requirements and nod their approval, usually what they're saying is, "I tried to read this, but it confused me, and I don't know what this means. Now of course I'm not going to say that, because I'm not going to look stupid, but I hope you understood what I want." Or, "I didn't read this, because I don't want to, or I don't have time, but you seem intelligent to me, and I trust you know what you're doing." How could requirements be written so that users would actually read them? (The same could be said for a lot of documentation.) Is there any point to producing documentation that doesn't get read? (CYA doesn't count.)
Last weekend I completed ripping my Alan Parsons CD collection and started listening to it at work off my portable media player. While listening, I figured I might as well google Alan, maybe there would be some interesting historical stuff on the web.
As it turns out, Alan Parsons is still kicking and has a new album out! Even better, he's doing electronica now! I'll be receiving it shortly and will do a review.
This will be the first record without his long-time bandmates Ian Bairnson,
and Stuart Elliott. The new album will take Alan in a new direction and into the
world of electronica.
Artists appearing on this record include: Nortec Collective, The Crystal
Method, Shpongle, PJ Olsson, and Pink Floyd's David Gilmour.
Comments