Why Modeling Is an Essential Business Analysis Technique

Software systems can be enormously complex. The complexity increases when multiple software systems are interconnected or when the product also includes hardware components. One way people deal with complexity is through abstraction. Abstraction allows us to represent information at varying levels of detail, depending on how much information any particular audience needs—and can handle—at a some point in time.

Visual analysis models provide a powerful set of tools that let business analysts depict system information at various levels of abstraction. These models serve as an aid to understanding, as well as an aid to communicating. Alas, I fear that modeling is somewhat of a neglected practice. I believe modeling is an essential skill every BA should master. Here’s why.

A Brief History

In the 1970s Ed Yourdon, Tom DeMarco, Larry Constantine, and others pioneered the field of structured analysis and structured design. They invented and standardized a variety of diagrams to visually represent knowledge about problem domains, software systems, and programs. More than 30 years ago I took a Yourdon structured analysis and design course. Learning about the power of modeling transformed how I thought about software development early in my career.

Simple diagrams like flowcharts had already been around for years. I remember seeing the plastic template my father used to draw pictures when he worked as a systems analyst in the late 1960s. The early structured analysis models included the context diagram, data flow diagram, entity relationship diagram, and state transition diagram. Those are still useful and relevant with today’s systems; for instance, every system can benefit from a context diagram. Before long, dedicated software tools came along that made it easy to draw and modify diagrams using those standard notations.

The later Unified Modeling Language (UML) supplied numerous additional models that are useful for systems analysis. Still others were incorporated in the Requirements Modeling Language (RML) developed by Joy Beatty and Anthony Chen. We now have no shortage of useful diagrams that can represent a wide variety of systems information, including those listed in Table 1. How many of them do you know about? How many do you use?

Table 1. Some useful models for representing certain types of system information

The idea of being able to draw pictures to think about systems was a real eye-opener for me. I found the models helpful both for understanding the problem domain and exploring solution approaches. They’re also valuable communication tools, helping to bridge the gap between customers with needs, analysts who must understand the problem and conceive solutions, developers who build solutions, and testers who verify those solutions.

Some Important Modeling Lessons

Immediately after I took that class long ago, I began using visual modeling approaches on all of my projects. I learned an important lesson early on when I tried to find a single diagram that would depict all the important information about a system: there isn’t one. As requirements engineering guru Alan Davis pointed out, no single view of the requirements will show you everything you need to know about a system.

Each analysis model provides one view of the requirements, as do a written requirements list, tables, user stories, acceptance tests, prototypes, and myriad other ways to represent information. A business analyst might think of a part of her job to be “writing requirements.” which logically implies the use of natural language text. However, I prefer to phrase that task more generally as “representing requirements knowledge,” which encompasses all the different ways you might do this.

The early hope was that structured analysis models would obviate the need for detailed written requirements specifications. We all quickly learned that was not the case, an important insight. Analysis models represent information at a fairly high level of abstraction, although you can make the models as detailed as you wish. Even with layered and refined diagrams, though, a lot of necessary requirements detail still needs to be communicated in the form of text. For instance, nonfunctional requirements like quality attributes really must be specified using precise natural language. Diagrams don’t fully replace text, but they nicely supplement and complement written specifications.

Another important lesson I learned is that we should use existing, standard modeling notations whenever possible rather than inventing our own. We already have dozens of models to represent virtually anything you might wish to show about a system’s processes, data, states, interfaces, architecture, and so forth. All BAs should become familiar with the suite of available models so they can choose the right tool to depict whatever information they want to most effectively.

Models—like all requirements representation techniques—are communication aids. We can only communicate effectively if we all speak the same language and understand the notations. If you invent new symbols, arrow styles, or other conventions you find convenient, the people who read your diagrams might not understand what you’re trying to say. That only leads to confusion, not to effective communication.

The Benefits of Modeling

One big benefit of modeling was the ability to easily revise the diagrams as problem understanding and solution concepts evolved. Such iteration is a foundation of successful software engineering. It’s far faster and cheaper to iterate on high-level diagrams than on code. The models also lend themselves to progressive refinement of details, an efficient approach to requirements development. My strategy is to iterate—that is, to think—about the problem and its solution multiple times, and then write the code once.

A strong argument for modeling is that representing knowledge in different ways allows you to compare those alternative views to look for gaps and disconnects. The multiple requirements views I mentioned earlier are complementary. They show you information in different ways, but the models all must agree. If you have only one view of the requirements, you must assume it is correct. However, if you create multiple views, using different thought processes—and possibly even different human brains—you can compare those representations to look for problems.

Figure 1 illustrates how use cases can serve as the source of information for detailed functional requirements, corresponding tests, and visual analysis models. Suppose you have a BA write the functional requirements the developers will implement from the use case and also have a tester write tests based on his understanding of the use case. Now you can map those tests against the functional requirements and look for conflicts.

Figure 1. Developing and comparing multiple requirements views from a common source of information.

You might find tests that have no corresponding requirement or requirements that can’t be “executed” with the tests that were written. You might discover conflicts between what a requirement says should happen under certain conditions and what the corresponding test says should happen. Such problems often arise from ambiguities and differing interpretations of written requirements. By creating these multiple views, you can detect such errors and quickly correct them early in the process, before anyone has written the code. This helps prevent more expensive rework later on.

Similarly, you can use tests to verify the correctness of visual analysis models. In fact, drawing the models is a powerful aid to system testing, as it provides a visual way to ensure that your test suite covers all the anticipated paths or conditions. (See Chapter 17 of Software Requirements, 3rd Edition for examples of how to test requirements with models.) Again, you can use these early tests to find and correct problems with the requirements understanding, leading to a more consistent and complete set of requirements to be implemented. That early testing effort isn’t wasted: the conceptual tests you develop from requirements can easily transform into specific test procedures later on.

These modeling techniques find valuable application beyond software projects too. I once worked as a BA with a team that was reengineering a company’s vital business process. We used sticky notes and drew lines on a whiteboard to show the new process steps and how they were interconnected. I interviewed the representative who owned each process step to learn what data he needed to perform that step and what data the step would produce.

Next, I drew a data flow diagram to show how those data elements would glue the various steps together, as well as an entity-relationship diagram to show the various data objects and their connections. After a bit of explanation, the team members had no difficulty understanding these simple diagrams and working with them. After all, the models mainly consist of just boxes, circles, and arrows of various kinds. They’re not hard to understand, even if they get large.

Start Modeling Now!

If you’re a business analyst, tune up your skills in the modeling arena and add a wide variety of models to your BA tool kit. Be prepared to explain the notations you use—and why you drew the pictures—to your peers and customers who aren’t familiar with them. You’re not going to get a diagram right the first time you sketch it out, so look for tools that make it easy to draw the models you find most helpful and to iterate on them. I’m confident you’ll find that visual modeling adds a valuable dimension to your BA practices.

One of my consulting clients objected when I suggested his team would benefit from modeling the requirements for their current project. “Our system is too complex to model,” he protested. But think about that for a moment.

By definition, a model is simpler than the thing it’s modeling. If you can’t handle the complexity of the model, how can you expect to handle the complexity of the problem? Visual models can certainly become complex and confusing for complex and confusing systems. But that very challenge is a good argument for doing the modeling, to get a handle on that complexity before it bogs you down during construction.

You don’t necessarily need to model the entire problem or solution space. Focus your modeling effort on the most complex, most poorly understood, or riskiest parts to make sure the project stakeholders have a clear, shared understanding of what you’re trying to build.

Business analysts sometimes push back against the idea of modeling. “I don’t have time!” they say. Certainly, you should only perform activities that add value to the project. Some activities add immediate value; others add value down the road. “Value” typically means saving time and money, both by working more efficiently and by building products with higher initial quality. All this helps to avoid the need for rework to fix errors and add missing capabilities later on.

Taking the time to model business processes and system requirements is an up-front investment that can pay off in multiple ways. It’s certainly worth thinking about whether creating models will save time either during development or post-delivery. If you decide it won’t, don’t do it! But as with so many aspects of software quality, it’s not a matter of “you can pay now or you can pay later.” It’s “you can pay now or you can pay a great deal more later.”

The old adage says, “A picture is worth a thousand words.” Software people know it’s actually a bit better than that: “A picture is worth 1024 words.” At least.

Karl Wiegers is Principal Consultant at Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of numerous books on software development, most recently Software Requirements, 3rd Edition (with Joy Beatty). He’s also the author of Successful Business Analysis Consulting: Strategies and Tips for Going It Alone, a memoir of life lessons, and a forensic mystery novel, The Reconstruction. You can reach him at ProcessImpact.com or KarlWiegers.com.