It all started with the recent CIO article Fixing the Requirements Mess. A comment by Christopher Creel (halfway down the page) was then put on the Requirements Defined Message Board.
After reading Mr. Creel’s comments, and the other postings, I think people are missing the main problem with his argument.
The rationale for holding on to written requirements, especially for business applications, is a little baffling. The entire premise for requirements is that it costs less to perform a paper exercise than to build software that is terrible, but a little less terrible with each iteration.
I just don’t buy it. Not in the least little bit.
First, requirements give everyone a common framework to ensure business and developers agree on the end product. Building simulations and prototypes can only be useful if they save time for both the business and developers. I understand he says “with advances in application simulation software, prototyping technology, and modern software development tools, techniques, and technologies, many people would be shocked at how the economics really shake out these days,” but he gives no supporting numbers. Has anyone seen numbers for this? I haven’t.
Second, requirements give QA something to test against. Just because multiple iterations in a build environment may prove a program stable, it does not ensure it will meet all of the business needs.
Third, well-written requirements can provide the starting point for training aids and user manuals. Something every program is missing.
Fourth, and maybe most significant to me, is how he can say written requirements are not necessary “especially for business applications?” The implication here is one of the following: (a) existing documentation of the business rules is sufficient, (b) the business rules are so well known they do not need to be documented, or (c) the business rules are too complicated to write down.
Tackling these points one at a time…
(a) It is unlikely the current procedural documentation is completely up-to-date. How people do their work changes on a regular basis and I have never seen a company who could keep the documentation current with what the people are doing in their jobs. Further, in a department of 6-10 people, all with the same duties, it is easy to find the vast majority performing their tasks differently; where existing rules and procedures exist they typically leave too much room for interpretation. And significantly, the documentation for procedures is spread among too many documents in too many places for developers to grasp the big picture and all the details.
(b) ACK! This just isn’t so; common sense isn’t common and seldom do two different people understand the process in the same way. Counting on verbal history and common knowledge of the rules is a disaster waiting to happen.
(c) Unfortunately, I believe the belief that business rules are too complicated is the most common reason for this rationale, even if it more often whispered or unspoken than said aloud. It is my contention this reason, whether spoken or not, is the last reason why requirements should be abandoned. It hasn’t always been uncommon to find a business application being pushed as a means to discover the business rules, but I submit knowing the business rules and the exceptions should come before building a business application, or even its prototype. Knowing how to optimize your business should come before building an application. And knowing your business should always come before trusting someone else to solve your problems with a new software application.
Is it just me, or is he missing the boat?
