In response to a recent discussion over at Yahoo on the requirements Engineering list, a question was posed as to why “just enough” was ever okay when creating a model. After all incomplete models or improper use of a modeling standard has to be bad… right? I believe there is another perspective on modeling to consider. That is, WHY a model is being created. I see 3 reasons for modeling;
In reverse order, Modeling for reference is the traditional goal. It is intended to read by someone (usually at some future point in time) new to, or somehow removed from the original development effort. The model needs to neither mislead nor have important gaps and must comply with the standards for that model type. After all the standards allow a reader to understand the model without the original context.
Modeling to understand is a more requirements gathering effort. The creator is the likely consumer and it is intended to be an aid, not a deliverable. Simple and well understood things need not be included instead the models tend toward fragments being analyzed instead of depictions of the whole. Think of them as quickly taken notes and relevant doodles done in your own handwriting using symbols likely to be meaningful only to yourself. As such models for understanding can be, but are not required to be good historical notes about how or why a decision was made. They are not intended to be good tools for later reference.
Last, modeling to communicate is done to share ideas or restate an understanding for validation. They are semi-structured whiteboard-like drawings which, once done communicating their point go quickly out-of-date. They tend to use symbols understood by the parties involved which may vary wildly from the official standards of the model type. It is far less important to be right than to be understood. However, should the model persist too long, or should someone from outside of the original discussion get their hands on it, clarity becomes the first causality.