In this article, Mr. Gunn covers the importance of having solid business requirements on which to build your application. He also discusses the consequences of not having business requirements.
Thorough, accurate, and well written business requirements are the foundation for software development projects. Many of those in the software development business would agree with this statement and would also agree they don't follow it. Sometimes there is project pressure to "start coding now". As if, that would get the project to market quicker. I have never quiet understood this concept. Without a solid foundation on which to build your project, as with building a house, sooner or later the house will crumble. The time taken to produce solid business requirements will save the project time and expense by reducing the time and cost of having to redo code that does not meet our users/clients business needs. Coding without having solid, detailed business requirements means the developers will, in all likelihood, have to spend time re-coding to fix missed requirements. QA will have to write new test cases, new builds will have to be released and more testing will take place. So you can pay me now (pay the business analyst) or pay me later (Developers, DBA, QA).
The task of producing thorough, accurate, and well written business requirements is the other aspect that is often under estimated. Having subject matter experts (SME) write business requirements is not the best approach. SME’s are not trained in writing business requirements. They know their business, but do not necessarily know how to write solid business requirements. For example, I had this exchange once while reviewing business requirement written by a SME:
Analyst: In this requirement you state that you always do this task.
Analyst: So there are no circumstances under which you don’t do this task.
SME: That is right... .well there is the rare exception that we don’t but it hardly ever happens...
If this requirement had been given, as it was written, to development and QA this is how it would have been coded and tested. During User Acceptance Testing (UAT), at the end of the project time-line, the users would have discovered this over-sight (at least we hope they would) and the project would now be behind schedule and additional person-hours (see also cost over-runs) would ensue to correct the over-sight.
In the end, having solid business requirements is the foundation for building a quality product. A quality product requires all project participants, during all phases of the project, to adhere to the constructs of Total Quality.
