To do or not to do: If the requirements engineering payoff is so good, why aren' t more companies doing it?

The by an author’s name means that the author plans to be present at the panel session. RE researchers have noted time and again the difficulty of technology transfer, that of getting technology that RE research has developed and found useful to be used in industrial practice. The numerous panels we have had over the years on this subject are proof of the pervasiveness and permanence of this problem. One thing that keeps many software-development organizations from doing serious requirements engineering before beginning development is the perception that doing requirements engineering wastes time and delays getting on to the real work, designing and programming. Many a manager says, "I know that we should work out the requirements in detail, but we don’t have time. We have to get started on the programming because we have a short deadline to deliver the code!". He or she says this despite all the evidence out there that each day spent in thrashing out requirement details leads to a reduction of up to 10 days in development time because of the reduction in the errors programmed into the code and the resultant reduction in both programming time and testing time. A relevant quotation in this respect is that of Trevor Devon of fizer, "Weeks of coding can save hours of planning". When confronted with this evidence, the average manager relies on his or her gut feelings that says that if the beginning of coding is delayed by n days, then the completion of coding is delayed by more than n days. Therefore, it’s best to get started coding as soon as possible. Therefore, the first third of this panel is a series of 5- minute talks presenting anecdotal and case study evidence that upfront RE pays off big. When an author is not present, someone else presents his slides. 1. Daniel Berry: Overview of Theme