Modeling Practice and Requirements


Models are useful in different settings in different ways. Models can test facts, ideas and understanding, simulate operation, and aid coordination between systems and people. In this column, Becky Winant lists six model patterns she has seen in practice in software development organizations, talking about where each is appropriate, and the strengths and weaknesses of each.

Last week, Joe (a client) expressed frustration about modeling practice disputes. "You hear people argue over requirements models, analysis models, executable models, architecture models, design models, and 'we don't need' models. Why can't they agree?" he asked. My years of working with people to build models made Joe's complaint familiar. Some build models to analyze a problem and some to plan software design. People choose different quantities of detail and quality criteria. Some projects might require models as documentation, while others don't.

Here are patterns of modeling practice I've seen and the conditions under which they're used

1. Artisan
Tool and core component developers usually are artisans. My friend, Doug, managed a group that built internal and external interfaces for all corporate products. Innovation and pride of craft drove the group. For one high-visibility project they eclipsed all expectations. Doug gleefully recalls how the executives came by the room peeking in to glimpse the magic of this group.

Artisan practice is model-less. An artisan needs only a mental concept. Products are directly crafted using personal skill and discussions with customers. The artisan might say, "the code is the requirement."

The hallmark of this pattern is personal craftsmanship. This is a strength and a weakness. When products remain small, with complexity and risks low, the individual craftsman shines. As products grow requiring expansion and maintenance to meet market demands, the artisan approach breaks down. Having no legacy or broad design for the product also means expensive and challenging revisions.

2. Improv
Irv, an IT manager for a banking group, hired me to create diagrams. "But, please," he urged me, "don't teach anyone to build models." The project involved three departments of a bank developing an integrated system to support international commercial accounts. Irv wanted to use design diagrams to bridge communication among the divisions and also to keep departmental boundaries clear. When I finished the diagrams and definitions, Irv said, "That's what I need! The operational detail we already know."

Improv modeling practice consists of diagrammatic sketches, not formal or technical models. System knowledge is ingrained in the culture and its systems. Diagrams align design concepts. Detail is expanded and explored with code. The whole motivation for this practice is communication; large systems take coordination to be successful. Improv modeling facilitates mutual agreement of purpose and success criteria but contains little elaboration of functional or technical detail.

Improv's forte is team synergy and communication. It succeeds because people know their market and systems well. This practice disintegrates when radical change forces rethinking requirements. At that point, modeling practice would need to extend beyond a tool for agreement into one that would expose what participants don't know-the gaps and anomalies in interpreting requirements.

3. Contract
My colleague, Linda, knew a contract practice where model walkthroughs only began after models were declared "done." Senior management approved the models, and while the full-color, oversized, plotted diagrams were displayed, no one suggested changes. Later the models were posted in the hallway outside the senior systems manager's office and covered in glass.

Contract modeling practice dictates detailed formal models. Automated tools shape model practice using fill-in templates and syntax checking. While they are detailed, contract models aren't required to pass tests for well-formed structure, only readability. Requirements often are literally a contract signed by all parties.

Contract practice thoroughness is good and bad. It increases good modeling sense and skill. In time, people build better and more useful models. The danger is wasting time producing useless models, if people only go through the motions. The practice fails when the cost of rebuilding unwieldy, poorly crafted models becomes intolerable.

About the author

Becky Winant's picture Becky Winant

Becky Winant ( has been mentor, teacher, and consultant on exploring requirements for more than twenty years. She also assists projects with team and process development and with system architecture and analysis modeling.

StickyMinds is one of the growing communities of the TechWell network.
