Recently my VCR quit working properly. I turned it on. Placed a video tape in it. Hit the PLAY button, and all I got was sound….no picture. I thought maybe the tape was bad. So I put a
commercially recorded tape, one I had purchased, in the machine. Same thing happened. Sound, but no picture. Although disappointed I was very confident that my father, a genius concerning things
electronic, would be able to fix this problem. I packed the VCR in my car and headed to the homestead for a weekend visit. My father diagnosed the problem right away. It was something to do with
the video amplifier circuit component. He said he could fix it if he could get a copy of the schematic wiring diagram for the VCR. He was not about to touch it without that information! Without the
specifications, he said, he’d cause more problems than solve in trying to locate the faulty parts. The electronic and mechanical components of a VCR are extremely sophisticated and very complex.
The specifications would save time and sanity in pin pointing and resolving the trouble.
How does this little story about my problems with a VCR have any connection with data modeling or application development? It’s very simple. Specifications! The thing about the thing.
Specifications are a set of diagrams and documents that describe why an application system was built, what it’s supposed to do, what it must know in order to do it, and how it does it.
Specification documentation is not an application itself. It doesn’t do anything. It contains the things one needs to know in order to understand an application.
Why do so few managers and system developers recognize the value of specification documentation? Our business application systems are just as sophisticated and complex as the inner workings of a
VCR. Yet how many of them have documented specifications – with data models, process models, state transition diagrams, activity flow diagrams, etc. that describe and provide organization to this
complexity? I suppose one could argue that program code itself is the specification. I’ve heard some of my colleagues say we don’t want programmer/analysts turning out documents – we want code!
Documents can’t do anything – code can. However there are typically many programs that constitute an application system. It is very difficult to see how they fit together into a finely tuned
“application” by just reading code. Graphical diagrams as simple as job flow charts or screen flow charts aid greatly in understanding a system, or troubleshooting a problem. Context sensitive
specifications, like diagrams and narratives about a particular function, give program code meaning when one does need to read it to fix a bug, or make a change. And program code alone can not
adequately describe the business reason why an application exists.
Business applications are not rigid machines like a VCR. A VCR is designed and built to perform a specific set of tasks. Business applications are more organic. They start out with a basic set of
functions, but they grow and evolve as business changes. This, to me, is all the more reason why specifications are desirable. How can we ensure that changing one part of a system won’t adversely
affect another part? The system specifications should lead the ways in assessing what modifications are necessary to satisfy changing business conditions, while keeping intact those parts that
ought to remain unaffected.
Specification documentation should no longer be viewed as a time consuming activity, resulting in a “nice to have” but unessential deliverable from a system development effort. Preparing adequate
documentation that describes the business application should be viewed as an integral component in the process of providing viable and maintainable business application systems. It supplies
valuable information in its own right. After all, the specification diagrams for my VCR cost $32.00 — and they don’t do anything.
