Skip to main content

Requirements Rant

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.)

Comments

Popular posts from this blog

Map: Yushchenko vs. Yanukovych

This is a map of Yushchenko vs. Yanukovych, round 2.0. In the popular style of coloring candidates, it shows where each candidate's respective strengths are: generally, Yush in the west and Yanu in the east. (It's too small to see percentages; go to the above link for that.)

God and Computers Webcast

"In the fall of 1999, computer scientist Donald E. Knuth was invited to give six public lectures at MIT on the general subject of relations between faith and science. The lectures were broadcast live on the Internet and watched regularly by tens of thousands of people around the world, and they have remained popular many months after the event." Information about the lectures in book form can be found here .