One of the things stupid people do is this: Person A (aka Mr. stupid) writes a requirements document. He makes it super detailed and 50 pages long. He then throws it blindly over a wall (thud!) to person B and says “Do this.”

This is evil and dumb for the following reasons:

1. It guarantees resentment. Person B is being dictated to, which is less than fun (unless you’re a masochist). He is confined by person A’s (unnecessary) details. If ever person B has power over A, the negative energy will be returned.
2. It ensures poor quality work. Person B has no vested interest. The requirements are not his and he’s unlikely to feel positive about fulfilling them. I would not expect B to stay late, ever, to help fullfill requirements he didn’t beleive in.
3. It’s limiting. How does person A know that person B doesn’t have suggestions for making the requirements better? Or that his requirements aren’t completely insane and contradictory? He doesn’t.
4. It’s unecessarily territorial. Fighting over documents is absurd, since the document is not the product. Requirements, prototypes and wireframes should be fodder for collaborating on the best ideas, not for putting your pet ones in locked boxes.

Every time I hear about organizations that draft requirements in private, I choke. It’s a sure sign that creative thinking of any kind is seen as disruptive rather than constructive.

Requirements should be built in the open, with invitations to designers of all kinds to vet out requirements early on with rough prototypes and mock-ups to prove (or disprove) the assumptions made by the requirements. If quality requirements are the goal, there is every motivation to involve the people who will do the work in the their definition.

You want overlap of involvement in the production of any requirement (or document) between the creators and the users, as in this diagram. Ideas show flow freely between them. It should be a dance of analysis (business dude) and synthesis (designers/engineers).

You can replace the legend with any pairing of creators and consumers within a team and it still works. Programmers/Testers, Product managers/Program Managers, Designers/Engineers, etc.

You could argue that the lines should run in parallel for longer, with two or more people working as peers in the process until there is enough stability for a handoff. My point with the squiggly lines is that it fluctuates, but that it’s always clear who the primary driver is.

But the core of my point is overlap of involvement. Regardless of method (agile, waterfall, VP whim, utter chaos) you want to collaborate over important decisions, exploring alternatives and using cross-disciplinary perspective to draw the best thinking to the surface. There’s never a reason not to.