1.7. Strategy: Focusing on the Essentials
Before You Reached Here ...
Those of you on the 
and 
Trails have built up your knowledge of Piccadilly by building a current physical model. Now you can take a more logical view of Piccadilly’s requirements. This chapter reviews your progress and discusses the strategy of essential requirements modeling.
Easiest and More Difficult: You’ll need to have read Chapter 2.3 A Variety of Viewpoints.
Most Difficult: This is a good place for a checkpoint. If you have any problem with this chapter, try taking a temporary detour to an easier trail.
Promenade: This chapter is not on your trail, but you may care to read the first bit. However, if you haven’t read Chapter 2.3 A Variety of Viewpoints, this chapter may not make much sense.
Your Strategy
As you know, building current physical models teaches you about the Project and about the system you are about to change. Your context diagram defines the boundaries of the Project; the boundary data flows tell you precisely where the domain of analysis begins and ends. They also show you all the data that the system needs to remember. Coming down one level, Diagram 0 partitions the context so that you have an overview of how the organization is currently constructed. This partitioning provides convenient slices of the system for you to study and model. For example, you should have built Diagram 3 Sales Department when you studied how Piccadilly sells its airtime. Details of the selling activity are now found in Diagram 3.5 Make Changes to Spots and in Diagram 3.1 Plan Campaign. Along with the models that you built yourself, Chapter 3.6 contains a lower-level current physical model for each of the other Piccadilly departments.
Your data model shows a different viewpoint. This model sees the system from the point of view of what it has to remember. You build data models to help you understand the system (if you know what a system remembers, you know what it does). The data model is the first step toward the essential model, since it largely ignores how data are stored and instead concentrates on what has to be stored. The data dictionary gives discipline to the specification by defining all the data used by the data flow diagrams and the data model.
You could continue to analyze Piccadilly from the current physical viewpoint, but please don’t. Modeling everything that happens in great detail would take far too long. Also, it’s not necessary. Your basic understanding of Piccadilly’s current business is enough to take a simpler, clearer, and less time-consuming view of the system.
Changing Your Viewpoint
The current physical system has served its purpose of helping you to get started. We suggest that you collect your models in a folder or clip them together and label the collection “Current Physical Viewpoint.” Keep them close at hand; they contain useful information, and you will need to refer to them.
The current physical viewpoint does not necessarily represent the system you wish to implement in the future. After all, technology changes, and you don’t want to be tied to obsolete equipment. To specify the future system, you will need to find its underlying policy—the logic behind the current activities. Why does the system do what it does? This is called the essential policy, part of the essential viewpoint.
The Essential Viewpoint
The essential viewpoint shows us the reason the system exists. To see the reason more clearly, ask, “What would this system look like if it operated independently of any implementation technology?” By stripping away all manifestations of the current implementation, you can see the underlying essential policy.
As you build the essential viewpoint, remember that it is an abstraction of the system. You have to disregard the implementation and extract only the essential policy. The essential viewpoint portrays a theoretical system; after all, it couldn’t exist in the real world without some kind of technology.
To build the most appropriate future system, you must not inadvertently reimplement any obsolete or inappropriate technology that happens to be part of the current way of doing business. (We will discuss this concept in Chapter 2.10 Essential Viewpoint.)
Your data model has already revealed some of the system’s essential policy when you looked at the essential data requirements. Instead of modeling how data are or will be stored, the data model simply defines logical groupings of business data required by the system. You will revisit the data model as you build models of the system’s essential process requirements.
Ski Patrol
You are about to go down some very steep slopes—the precipitous though exhilarating runs through essential modeling territory.
If you are not completely familiar with essential event-response modeling, we urge you to equip yourself for what lies ahead. That’s why the Ski Patrol refers you to Chapter 2.10 Essential Viewpoint, which explains why you want to take the essential view, and, following that, Chapter 2.11 Event-Response Models, which describes how to build models of the essential requirements.
Easiest and More Difficult: Go to Chapter 2.10 Essential Viewpoint for an explanation of the new viewpoint that you are about to use.
Most Difficult: Tighten your ski boots one notch and launch yourself into Chapter 1.8 Identifying Events.
Promenade: If you haven’t already read Chapter 2.3 A Variety of Viewpoints, as well as Chapters 2.4 Data Viewpoint and 2.5 Data Models, now is the time. Otherwise, the most appropriate place to pick up your trail is at Chapter 2.10 Essential Viewpoint.