3.1. Review: Start with the Context
The Context Diagram for Piccadilly Television
The context diagram that we derived from the description of Piccadilly Television is shown in Figure 3.1.1. Compare your diagram with it.
Figure 3.1.1: Our interpretation of the Piccadilly Television context diagram, which summarizes the scope of the Project. The names used for the terminators and data flows are, as much as possible, those used in the text.
The Case of the Missing Users
In some cases, we’ve interpreted something that was said in a user interview or statement, and consequently your names may vary from ours. As long as the intention is comparable, though, your answer is acceptable. Of course, when you’re doing real-world systems analysis, you’ll need more than just good intentions. You’ll need the users to help you out.
Only the users can confirm the factual substance of your models. The goal of analysis modeling is to have a close collaboration between the users and the analyst. Because you are working from a book and there are no users sitting with you at your desk, you have to compensate. For this Project, concentrate on the form of your answer and its intent. There are no users present, and so your interpretation of the substance is, within reason, as good as ours.
The Boundary of Your Project
Probably the hardest part of the exercise is determining precisely what is inside and what is outside the system. When you draw the context diagram of the system, you are determining exactly what you are going to study. For our solution, we looked for those things that Piccadilly controlled and that could be studied reasonably by an analyst. We also chose to study parts of the business that we thought we could affect if we devised some way to improve the process. We declined to study anything that was owned by other organizations or any part that we couldn’t influence or improve.
Interpreting the Business
You had a written description of the operations of Piccadilly as input to the problem. Like all pieces of natural language prose, it was ambiguous. When you drew the context diagram, you imposed an interpretation on it. Whether or not you made the right interpretation is now to be decided by you and your users. By showing the users your context diagram, you are saying, “This is where I think the project boundaries are. These are the data flows that are at the limits of the system’s responsibilities. Now let’s go through each of them to see if we all share the same understanding of the scope of this system.”
For example, the information communicated between the advertising agencies and Piccadilly sales executives may have been ambiguous as it was presented in the text. On the other hand, the context diagram states very clearly that the ADVERTISING AGENCIES send CAMPAIGN REQUIREMENTS, SELECTED SPOTS, SPOT UPGRADE REQUEST, and COPY TRANSMISSION INSTRUCTIONS to the Piccadilly system. This means that the system you are studying begins its responsibility when it receives these data flows. So you are declaring that you intend to study how the sales executives process these data. If you and the users do not intend to study this part of the system, you must remove these data flows from the diagram.
You proceed the same way for the data flows leaving the context. The data flow AGREED CAMPAIGN leaves the system and goes to the ADVERTISING AGENCIES. The diagram states that your analysis will study how that flow of information was created. However, the responsibility of the system ends once the data making up AGREED CAMPAIGN have been produced. What the agencies do with the data is outside the scope of your study.
The text mentions that the ADVERTISING AGENCIES communicate with film PRODUCTION COMPANIES. The agencies must be telling the production companies which commercials to make and where to send the commercial copy. Why doesn’t this communication show up in the context diagram? Consider the other data flows between these two terminators and your context. They all point to the fact that the commercial has already been made by the time Piccadilly hears about it. If your system were interested in the production of commercials, these boundary flows would be very different. So you must rule out any interest in the communication regarding the production of commercials. Your interest in the PRODUCTION COMPANIES is limited to the fact that they are the ones that send COMMERCIAL COPY RECORDING to the system. Your diagram states that you intend to study the processing that takes place after Piccadilly has received this data flow.
It’s the Message, Not the Medium
Did you include the data flow PREEMPTION WARNING in your diagram? You should have. Recall that the sales executive telephones the agency to warn his contact about a possible preemption. Even though the data are traveling by voice and telephone line, the information is still a data flow. You will have to find out what processing and data are used to create this warning.
Your context must include all of the interfaces between your project and the terminators, not just those interfaces in the form of documents or other tangible media.
Internal or External?
The terminator PICCADILLY MANAGEMENT receives REVENUE REPORTS and produces SALES TARGET INSTRUCTIONS. Our diagram says that you will study how the revenue reports are produced and how the sales target is used. By treating PICCADILLY MANAGEMENT as a terminator, you are stating that you will not study either what managers do with the revenue reports or how they set the sales target.
The context of your study is not defined by the terminators; it is defined by the data flowing to and from the terminators.
Although PICCADILLY MANAGEMENT appears as a terminator, that doesn’t exclude some of the processes within your study from being carried out by the same managers. For instance, you heard that managers are concerned with setting new rates so that a new RATECARD can be sent to the agencies. When you study the Project in detail, you’ll find that management is involved in one of the processes inside your context of study.
Your interpretation may well differ. Suppose, for example, you decided that your project will study the rules for setting the sales target and using the revenue reports. Then, both data flows, SALES TARGET INSTRUCTIONS and REVENUE REPORTS, would disappear from the context diagram. They would become data flows inside the system, and they would reappear when you studied the details of the project.
Which of the above interpretations is right? The answer is they both are. Almost all of the information you receive when analyzing a system can be understood in more than one way. This problem of multiple interpretations is the reason to build a context diagram. The context diagram totally eliminates the ambiguity because it can be interpreted in only one way. While this doesn’t make the diagram correct every time, it does mean that because the users can see your precise understanding of the system, they can either agree that you show it as they mean it, or disagree and ask you to change it. The point is that you make it possible to raise questions and to work toward a consensus.
No doubt there will be changes to the context as work on the system progresses. New requirements will be added to the system, while other requirements, previously thought indispensable, will be deleted. Many adjustments will result when you start to do the detailed analysis and everyone realizes just how much work is involved. The only real constant is that the context diagram will continue to display the precise boundaries of the system. How and where the boundaries are set is negotiated by you and the users.
Naming the Flows
Always try to name the data flows with the names the users know them by, since it makes your models much more recognizable to the users. However, sometimes you’ll find names with buried meanings. For instance, the first time we talked to the Piccadilly users, they referred to the “green book.” Since that is not too informative, we needed to clarify the meaning: “What do you mean by ‘green book’?” we asked. “What do you use it for? What data does it hold? Show us a green book.” The buried meaning turned out to be the data flow TELEVISION RATINGS REPORT. (The book, as we found out, wasn’t even green at all. At some time, the procedure changed and the ratings came in a yellow binder. This did not, however, cause people to change their terminology in the least.)
Try to use the same names as the users do, but make sure the names reflect the real business purpose of the data flow.
Were you tempted to abbreviate the names? Maybe you used C REQ instead of CAMPAIGN REQUIREMENTS. Don’t do it. Otherwise, you create your own buried meanings just as obscure as some of those the users have invented. Remember, your objective is to understand the business requirements so that you can raise relevant questions. You want to uncover misunderstandings before a lot of detailed work has been done. That means adapting to the language of the business you’re studying.
With a general description of the users’ business, you’ve turned it into an unambiguous statement of the Project’s context of study. You now have a well-defined starting point. Later, your detailed analysis may reveal things that change the context. However, the context diagram helps to keep the Project under control. Any change to the context means a change to the size of the Project. Each change can be measured for its impact on the Project, as we’ll discuss.
Ski Patrol
The Ski Patrol can help if you are having trouble with the Piccadilly Project, especially with the technical aspects of the model. If you are satisfied that your diagram conveys your intended meaning, that a user could understand it enough to question it, and that you can produce a reasonable context diagram for your next project, you have no need of the patrol. Proceed directly to the Trail Guide below.
If you have a technical problem with your model, read on. First, your model should have the same form as ours. There should be only one bubble, and about the same number of terminators as in ours. If not, we suggest you review the discussion in Chapter 2.2 Data Flow Diagrams about context diagrams. If your model shows several bubbles, you have already started to partition the system. While this is not necessarily wrong, our experience has shown that it always pays to have the context reasonably decided before breaking the system into its components. At this stage, you should be concentrating on the boundary data flows, instead of the functional areas.
We trust that you’ve not committed the crime of leaving any of your data flows unnamed. If any of the other data flow conventions gave you problems, again, return to Chapter 2.2 Data Flow Diagrams, work through the exercises, and study the sample answers. There will be more on data flow diagrams later in the book (Chapters 2.6 More on Data Flow Diagrams and 2.7 Leveled Data Flow Diagrams).
Trail Guide
Easiest: Go to Chapter 2.3 A Variety of Viewpoints for a discussion of the viewpoints used to build analysis models.
More Difficult: Go to Chapter 2.3 A Variety of Viewpoints. This trail assumes that you already know how to build models, so it focuses on the viewpoints that you use to build them.
Most Difficult: Go to Chapter 1.3 What About the Business Data? for more work on the Piccadilly Project.
Promenade: The Project chapters are not on your trail, but if you have found this interesting, you might consider switching trails. Otherwise, you can pick up your own trail in Chapter 2.1 Analysis Models.