Even if you do everything right in a development project, or you think you do, you can still miss the goal, because you haven't understood why you are doing things.

In one project, we struggled long and hard writing a Requirements Specification for the solution we were building. There were all sorts of problems, most of them people related, which slowed us down, sometimes to a grinding halt. Our partner in writing, our customer, didn't co-operate very well. When we asked how they wanted it, they couldn't tell us; when we suggested, it was all wrong. It was a frustrating experience.

But something had registered with our customer, because in the project that followed, they sat down and wrote a really comprehensive Requirements Specification for a CRM solution. They invested a lot of work in this task, and missed the purpose completely: they didn't communicate what they were doing. When they handed over the RS to their supplier (a different project in the same company), the project took a hard look at the document and rejected it. "We can't deliver this", they said. "It's a good Spec, but no one can deliver this. You can't find a company in the world that can deliver this."

The customer had completely missed why they were writing a Requirements Specification. For them, it was a one man task in front of a computer screen, and that person forgot completely to communicate with the project that was supposed to build the stuff. The Requirements Specification is just the result of a long process, involving co-operation and collaboration between a lot of stakeholders. The Spec can be viewed as a kind of receipt on this co-operation. If the Requirements Engineering process works well, you will have a good RS that will fill its purpose. If the process didn't work that well, you will see this also in the RS.

The authors of the RS can never shield themselves from the outside world. They need to communicate with all sorts of people, from Product Managers to Test Engineering. Some of these people you only need to involve once or twice (they can still be on the distribution list), other stakeholders you need to talk constantly to. You will also learn that if stakeholders A are going to get their requirements through, stakeholders B cannot. The best thing is often to have a meeting with all concerned, and let them put everything on the table; you probably need to help them with this. Sometimes they will discover that one or both of them have misunderstood something fundamental with their business model. It is moments like these that really makes it worth all the hard work.