2.10. Essential Viewpoint

These systems go wrong because they were built to the wrong requirements. When the requirements are wrong, the implementors cannot fail to build the wrong system. In order to get it right, the analysts must find the real requirements. The real requirements are not merely a rehashed version of the current system, nor are they the educated guesses of the analysts about the system they’d like to see. The real requirements describe the business being done by the system without any bias toward any implementation. These are the essential requirements. Essential requirements are also known as “logical requirements” or “business policy requirements.”

Figure 2.10.1: Even software that appears to be completely new and different is usually a reimplementation of some existing system. Take word processing, for example. This seemingly recent phenomenon is really a computerized replacement of what typists have been doing with typewriters, scissors, and glue since the nineteenth century. The implementation may look different, but the basic requirements are the same.

For example, since VisiCalc was introduced in 1978 by Dan Bricklin and Robert Frankston, spreadsheets running on personal computers have spread at an almost plague-like rate. But the spreadsheet does not signify a new requirement. It only automates a task that accountants and business people have been doing with pencil, paper, and calculators for many years. The growth in popularity of automated spreadsheets has come about because they make the task inexpensive and accessible.

The point is we build systems for which there is a need. By and large, most of our software development is concerned with the reimplementation of some system that already exists in some other form. How do you construct a new system to replace the existing one?

It would be very convenient at this stage for a miracle to occur; and after a blinding flash of light, you’d find the old system replaced by a shiny new system that meets all of the requirements. The convenience of miracles is offset by their improbability.

Perhaps you could just rewrite the existing computer programs. This would give you the opportunity to exchange the old code for new, with the hope that the old bugs will be buried and no new ones brought to life. But a simple rewrite means that you would spend a lot of time implementing a system that carries along with it all of the old technology and idiosyncrasies. Rewriting does not guarantee that the new system will be more appropriate or that it will satisfy the users any more than the old one did.

Simply reimplementing a manual system on a computer means that the new system would be no more than a simulation of the manual processes, and that it would contain all the restrictions of manual technology. For example, some time ago, a government department was building a computer system to automate a manual one that had existed for many years. The users (they also had existed for many years) specified the system. The manual system contained a form that had to be filled out with the details of each client. The form was to be automated and subsequently become a screen in the computer system. The implementation of this screen carried a strange requirement. If the operator made a mistake while filling out the screen, the screen had to be cleared and filled out again. This may seem absurd when you consider the capabilities of moving cursors and replacing text on a screen, but consider what this screen was replacing. It replaced a form that clearly stated, “This form must be completed without erasure or alteration.” The computer system had obliged. It was a faithful reimplementation of the manual system.

What was wrong with the new system? It was not that the developers failed to take advantage of the available technology. They used computers and terminals that gave everybody convenient access to the data. But they did fail to find the true requirements. Instead of finding the requirements, they assumed the implementation was the requirement. Not so.

The essential requirements are independent of any implementation. They exist because of the meaning, or purpose, of the system. The essential requirements represent the fundamental business of the enterprise.

Systems are built to pay bills, invoice customers, control production, guide aircraft, and so on. Systems are not built to use snazzy new workstations, or to program the database, or to construct a local area network for the intellectual challenge. While these technologies may be used to implement systems, they are not the reasons for the system’s existence. (At least, we sincerely hope not.)

To find the essentials, imagine the system as if it had been implemented without any technology—no computers, no humans, no databases, no paper files, nothing. Then, imagine all the processes that are there to support the technology can be put aside for the moment; set aside the computer edits that check that the input data have been input correctly (if there are no computers, there is no reason to keypunch or to scan the data). There is no need for audits to unearth the mistakes made by the fallible humans (no humans, remember), or for backups of the databases to protect against disk failure, or for check numbers and duplicate reference numbers to repair a file that’s out of order. In fact, anything to do with the implementation of the system is gone.

The illustration in Figure 2.10.2 shows banking as it was a hundred years ago. Not many of you readers have firsthand memory of banking as it was then, but you are bound to have read about it or seen movies depicting the era. Now consider the twentieth-century equivalent (Figure 2.10.3):

Figure 2.10.2: Banking in the nineteenth century. Bankers wrote in their ledgers using quill pens. They wore frock coats and conducted their business with a hushed, genteel air.

The Bank of Scotland is prepared to make home banking available to anyone with a television set connected to the Prestel network. Prestel is an information exchange network that can display data on specially equipped television sets. Via the home banking terminal, a television set, and the Prestel adaptor, account holders can access the Bank of Scotland’s central computer and view their accounts, transfer money, pay bills, balance checkbooks, and do most of the other things related to a bank account.

Figure 2.10.3: Home banking from the Bank of Scotland. The keyboard is plugged into a Prestel-equipped television set. The bank customer uses the Prestel network to communicate with the bank’s computer.

How much has banking changed in the hundred years between the illustrations? Not much. Both of the implementations shown above satisfy the same essential requirements; they are both involved in the same banking business. If you had built an essential requirements model of a bank a hundred years ago and did the same today, you would see very little difference between the models. The banks still take deposits and lend depositors’ money. What has changed is the technology. The essential requirement to provide the customer with information about an account is satisfied by either a handwritten statement or a display on a home television screen.

The system that you are about to build should reflect its business policy. By building the essential model, you get a perfect understanding of the business. Then, by understanding the business, you can understand the implementation.

The most expensive component of today’s software is maintenance. Maintenance programmers seem to be constantly buried under a file of change requests from the users. Some requests are made because the business policy has changed, or sometimes because federal, state, or local governments have introduced new legislation that affects the business (essentially, it’s the same thing). Businesses and the laws they operate under are constantly being altered. However, if these were the only modifications you needed to make to the installed system, the maintenance burden would be relatively tolerable.

Apart from the above changes or alterations to the hardware or system software, all other maintenance changes are caused by the failure of the systems analysts to specify the right system. Either the analysts have specified the wrong system, or they have failed to discover all the requirements. Change requests in this case are really belated attempts to build the correct system.

When you are able to capture and implement the correct requirements in the first instance, the installed computer system accurately reflects the users’ business. In other words, the system does what the users really need it to do, and there is no need to correct the system through maintenance.

Figure 2.10.4: The data model represents the essential stored data for the system.

Stored data are considered essential only if there is a business reason for the system to remember the data. Nonessential data are eliminated from the data model because that data (such as foreign keys and pointers) exist only to support the storage technology. Nonessential data are not part of the essential system. Just as a process is not essential if it uses nonessential stored data, data cannot be essential if the data exist because of a nonessential process.

How do the essential stored data relate to the essential processing requirements? The most fundamental role of essential stored data is to provide the raw materials to the processes that manufacture the system’s information outputs. The essential purpose of the system is to provide data and services to the outside world. Most of the data that flow out of the system through the boundary data flows come from the system’s store of data, so we can say that the essential processes that provide the system’s outputs are utilizing essential stored data.

How are the data stored? By essential processes on the input side of the system. Any system must have essential processes that transform the input boundary data flows into essential stored data.

Most essential models follow the pattern that is illustrated in Figure 2.10.5.

Figure 2.10.5: Some essential processes store the essential data; others retrieve it. The essential data stores in the process model are actually the entities in the stored data model, shown below it.

Note how the data flows that enter the system from the outside world are stored (by processes 1 and 2), to be later retrieved by essential output processes (3 and 4). When such essential data flows are stored, you should break them into their entity components. The data flow model, therefore, shows each entity type as a store. Whenever a process accesses two or more stores (which are really stores of entities), then it establishes or uses a relationship between the entities. The data flow model in Figure 2.10.5 thus leads to the data model shown below it. This aspect of essential data and processes is covered in more detail in Chapter 2.11 Event-Response Models.

The current physical model, being a view of the existing implementation, includes (somehow) many of the essential requirements. Unfortunately, this model also includes many other things; some are concerned with the physical implementation of the essential requirements, and some are redundant, obsolete, or just plain wrong. So the task is to separate the wheat from the chaff: to find the essential requirements and discard everything else.

Figure 2.10.6: The current physical model must be run through a technology filter to remove the current implementation and thus reveal the essential requirements.

You can often build an essential requirements model without first having a complete current physical model. When you move on to Chapter 2.11 Event-Response Models, you will see examples of using the context diagram to determine the events, and from there, go directly to building the essential event-response models. (All of this terminology is explained in Chapter 2.11.) What this comes down to is that after building the context diagram, some or all of the work associated with the current physical model can be avoided.

Each project is different, so we cannot give you fixed rules as to how much current physical modeling is necessary. You must judge for yourself how much physical modeling is useful and how much is simply wasted effort. The two most important factors governing how much physical modeling you need to do are the accessibility and the certainty of the business policy.

If you have detailed knowledge yourself of the subject matter of the system, you should be able to establish the context and go straight to the essential viewpoint. If other people have the business knowledge but you have immediate access to them, again you can avoid physical modeling. However, if you do not have immediate access to people who know the business policy, or if the people are geographically distributed, or if the context or aim of the project is unclear, then you would be wise to start by building a context diagram, Diagram 0, and one or two lower-level diagrams, with a reasonably complete data dictionary.

We do recommend that you not build a complete physical model with all the processes broken down to the functionally primitive level because it has always proved to be uneconomical. The best way to decide if you have done enough current physical modeling is to try building the essential model. If you get stuck, you can always backtrack and do some more current physical modeling.