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.)
Senator Kerry calls this a "tragic milestone," and the most catastrophic of the administration's mistakes made so far. Regardless of his mistakenly voting for the war at the time, he's right. For him to turn against the Iraq war is a flip-flop I would be happy with. Hopefully he has an exit strategy, even though he's not telling us about it at the moment.
This is why Bush must be defeated in November. I realize the economy is an important issue, but compared to 1000++ dead soldiers? Come on. Not to mention 7,000++ wounded, and the 11,000++ estimated by the Iraq Body Count . This is a slam dunk, as George Tenet would say.
Prediction: if Bush is [re]elected, the U.S. will engage in pre-emptive war against Iran and/or North Korea. Is that really what we want?
Comments