2.1. Analysis Models

The elders of the tribe knew something had to be done. They reasoned that if everyone wrote programs in the same clear way, then everyone in the tribe would be able to understand, and thus modify, all the programs. With this in mind, the elders set out on a voyage of discovery. For many years, they traveled through lands of confusion until lo and behold! In a far-off land, they found understandable programs. The people of this land wrote programs using only two constructs—selection and repetition—to join their statements.*

*Many years later, the Italian explorers Böhm and Jacopini came across remnants of stone tablets inscribed with the two constructs. Their paper, published in 1966, was an immediate hit. See the Bibliography for a reference, and the Glossary (under “structured programming”) for a serious explanation.

The elders introduced the method to the tribe. They called it structured programming, and it was good. It improved the code of the tribe immeasurably, but it also led to a new problem. The tribe, now able to write understandable code, fearlessly tackled ever larger and more complex programs, but they couldn’t organize the larger programs they could now write. So the tribe asked the elders to undertake another voyage of discovery. This time, they brought back a revolutionary idea: functional hierarchies, made up of small modules with known interfaces. They called this structured design, and it was good.

The tribe produced elegant, well-designed, and maintainable systems. But the elders noticed another problem. Often, the elegant systems solved the wrong problem! The elders realized that what the tribe needed was a way to make sure they knew the exact requirements before designing a solution.

This time, the elders stayed home and studied the tribe’s behavior. They found that those of the tribe called users spoke a different dialect from those of the tribe called analysts. The only way, the elders reasoned, that the two could understand each other is if they had a common language. One more voyage of discovery and the elders returned with a set of graphic models belonging to neither the analysts nor the users. Now everyone could communicate effectively by building graphic models of their systems.

Those called analysts and those called users sat on the floor of the cave and together they drew their models in the sand. Soon, they made a major discovery: To build a model of the system, they had to understand the system. At the same time, they found that building the models helped them to understand the system. The models were successful—they made it much easier to gather the correct requirements. Now the tribe could always build the correct system.

Once they had solved the urgent problem of inventing a suitable systems analysis technique, the tribe moved forward. Next, they invented fire.

The Cavemen Build a Model

The elders wanted an explanation of the tribe’s hunting system. To show them, the users and analysts built a model, which is presented in Figure 2.1.1.

Figure 2.1.1: The cavemen’s hunting system. Each bubble represents an active process of the system. Arrows between the processes indicate the flow of information or material produced by each process.

If the construction engineer erects the building exactly as the working drawings show, the building will function correctly. Indeed, before construction can begin, the architect uses the working drawings to obtain approval and to demonstrate to the proper authorities that the building will be safe and meets code. The architect also uses the working drawings to demonstrate to the owner of the building that it will function as desired.

Because it represents a working system, the analysis model is also called a working model of the system. How do you know from studying the model that the system will work? You can tell from looking at the data that enter and leave each of the processes. Ask, “Is there enough data entering a process for it to produce its output data?”

For example, in Figure 2.1.1, the bubble HUNT WOOLLY MAMMOTHS receives the incoming data CLUBS and MOST LIKELY TRAILS. These data are sufficient for the cavemen to hunt for food. When the process of hunting is finished, the cavemen return with MAMMOTH SIGHTINGS and, if they were sufficiently agile, a CARCASS or two. In this case, we can say that the process has enough input to produce its output. In other words, it works.

When you can say the same thing for the other processes in the system, then you know you have a working model of a correctly functioning system and therefore the correct specification of the system. How else can this kind of model help in the task of systems development? To answer, let’s first look at how you understand systems.

Let’s leave the cavemen’s system for a moment and find an example in the twentieth century to illustrate. Suppose that you, a systems analyst, need to understand an automobile. Assume that you have only the most rudimentary knowledge of how a car works and that an expert is available to explain the car. Although cars are made of hundreds of individual components, initially you do not have to know anything about any of them.

In the beginning, the most useful information your expert can give you is an explanation of how the major components of the car interact with the others to produce the desired result. This means, of course, that the major components are fairly large things such as the engine, transmission, suspension, and body. For the moment, you must accept that each component works as the expert says it works, and not be concerned with how it accomplishes its task.

Once you understand the complete system in terms of the interactions between the major components-the engine powers the wheels, the body rides on the suspension, and so on-then you can begin to investigate how each of the components at this level works. Again, you must accept an explanation of the interaction between subcomponents, and believe for the moment that the subcomponents all work. Ensure that you understand this level of detail before investigating the subcomponents.

Each of the subcomponents is in turn broken into its subcomponents, and this partitioning continues until you arrive at a level of detail such that any component is so understandable you don’t have any more questions. Its function is obvious, or it can be described without benefit of any further partitioning.

How far do you go with the partitioning of a system? With the automobile example, you can continue dividing and subdividing until the components are single pieces of metal, or until you get to the molecules of the alloy, or perhaps until you reach the fundamental particles that make up the atoms. The answer is that it depends on your purpose when you study a system.

In systems analysis, we use the convention of head-sized pieces: pieces of the system that comfortably fit inside an analyst’s head and are readily understood. In the automobile example, the engine of the car is larger than head-sized, whereas the carburetor is just about right. For information systems, head-sized pieces are those that can be satisfactorily specified in a page or less of text description. These descriptions are called mini specifications, and they are the topic of Chapter 2.12 Mini Specifications.

The alternative to a leveled, successively detailed approach to understanding systems is too awful to contemplate. Suppose that in trying to understand the car, you started at the nuts-and-bolts level or the sub-sub-subcomponent level. How many sub-sub-subcomponents are there? Too many to let you easily understand how a car works. By starting at this level, you’d be swamped with details to the point that you’d probably never understand the system. The advantage of a leveled approach is that you move into the details as you choose. When you are controlling the amount of detail, you are far more likely to succeed with your goal of understanding the entire system.

Now look back at the cavemen’s hunting system. Hunting was just part of their lives. If you were studying anthropology and wanted to understand the ways of the cave people, you’d not likely first study their recipe for the barbeque sauce they used on the woolly mammoth. Instead, you’d first look at a higher level to study all of their activities: hunting, gathering, painting the cave walls, clubbing other tribes, and so on. Then you would study each activity that you identified. You would produce the hunting system diagram for study at this level, and then you might go on to look at even lower-level details, such as how they made their tools, how they mixed the paint for the cave walls, and so on. Eventually, by progressively descending into more and more details, you would capture all the activities as well as the links between them. This method is called a top-down approach.

How do you tell if you have functional components? First, a component is functional if it can be easily and informatively named, and if the name makes sense in the context of the system. Second, if you can honestly name a component using a verb and an object, it is a function. For instance, a name like SELECT AMBUSH LOCATIONS indicates that the component has a single function. It can be recognized by the user, and described by the analyst. A name such as PROCESSES BEGINNING WITH “M” does not pass the test and indicates that the partitioning didn’t produce functional processes.

We can also tell a lot about the functionality of a process by inspecting its interfaces—the data flows that enter and leave it. These flows should carry as little data as possible, and thereby make narrow interfaces.

Functional components need less data than do nonfunctional ones. Imagine the data flows for the two processes mentioned above. The data for SELECT AMBUSH LOCATIONS are reasonable (Figure 2.1.2). However, in any modern system, a process called PROCESSES BEGINNING WITH “M” would have an absurdly large number of data flows and, as a result, be meaningless to users. While functional components make narrow interfaces (alternatively, narrow interfaces make functional components), both are easier to get if you find the right places to divide the system.

Figure 2.1.2: Part of a model showing the data for SELECT AMBUSH LOCATIONS.

The same is true in systems analysis. The natural joints in the system are along the narrowest interfaces, or where you find a narrow flow of data with two processes. If you try to divide the system by pulling apart functions, you’ll get messy interfaces. By partitioning where you find the data interface at its narrowest, you’ll deliver a model with functional components that are easy for the users to recognize.