Anybody building a $300,000 house will not start the work without discussing the needs and desires with the construction contractor. Everyone understands that making a change mid-way during construction is very expensive. Is this understood for the construction of the software? Is the same principle applicable for software?
Sometimes I wonder how it would have been when no one understood the science behind the construction industry and how the requirements specified were translated into reality?
Did anyone understand the numbers and arrows in a building blue print? To explain a bigger and complicated plan, the blue print would have been accompanied by a miniature model. As the construction industry became popular, the general awareness about reading the plan and understanding the construction engineer's language became easier. Today, the building requirements are specified by the user in the most technical terms understood by the engineer (perhaps this made the construction engineer community feel nothing special about their job!!!). When the engineer produces the estimates and the type of work he is going to do, the user agrees and is able to visualize the end product. All the more, the user will be able to see it getting constructed physically!
In the software industry, the user does not have an understanding of the software task when it is being done and there is nothing visible for measuring the progress. It is a logical development activity. It cannot be seen or realized till it comes to a point where there is no flaw in it (after a stage where the development and testing are all over). To cater to this need and to foster customer satisfaction, there are different methodologies being developed and the software development process is also running with a 'science' behind the scenes. But for the user to understand this science and come to a level where they can specify the requirements in plain software terminology will take a while. But we are not that far from that (will the software engineers then lose the pride that they carry now?). Since there is a gap in the way requirements are specified and the way it can be interpreted by the development team, we are in a position to define the standards and clearly identify responsibility. The responsibility of setting the standards lies with the standards group and is doing its job well. It is in the hands of the development team to interpret the requirement in the same way as the business looks at it.
This is possible only if the development team replays what their interpretations are. This can be achieved through walkthroughs. In places where the walkthroughs are not possible, it is possible to send out a diagrammatic representation of the understanding of the business process helps. This is where the tools (thanks to Microsoft Visio and other visual modelling tools) come into play. These tools represent the business entities and other business process flow with a standardized set of symbols (this is the outcome of the job well done by the standards group). But the development team has done a great job that is gobbledygook for the business community.
The alternative is…
