IN THIS CHAPTER, YOU WILL LEARN:

For the systems analyst, the most difficult job in specifying a system is often that of determining what is part of that system and what is not. Whatever system you develop, no matter how ambitious, no matter how grandiose, it will be part of an even larger system. As we saw in Chapter 2, virtually all systems with which we have human experience are merely subsystems of even larger systems: even if our job were to “design the world,” we would have to recognize that the world is only a part of the solar system, which is part of a small, obscure galaxy, which is (ultimately) part of the universe.

Thus, the first major model that you must develop as a systems analyst is one that does nothing more than define the interfaces between the system and the rest of the universe, that is, the environment. For obvious reasons, this model is known as the environmental model. It models the outside of the system; the model of the inside of the system, known as the behavioral model, is discussed in Chapters 20 and 21.

In addition to determining what is inside the system and what is outside the system (which we accomplish by defining the boundary between the system and the environment), it is also critically important to define the interfaces between the system and the environment. We need to know what information comes into the system from the external environment, and we must know what information the system produces as an output to be delivered to the external environment.

Of course, inputs and outputs are not produced at random: no information system gobbles up all available data from the universe, nor does any realistic system spew output at random for consumption by the external environment. The systems we build are rational, purposeful systems; specifically, they produce outputs as a response to an event, or a stimulus, in the environment. Thus, another critical aspect of the environmental model is that of identifying the events occurring in the environment to which the system must respond. Not all events — after all, the environment, in its totality, generates an infinite number of events! We are only concerned with those events which (1) occur in the external environment, and (2) require a response from the system.

Note that the boundary between a system and its environment, as illustrated in Figure 18.1, is arbitrary. It may be made by management decree, or as the result of political negotiation, or simply by accident. And it is something that the systems analyst usually has some opportunity to influence.

Figure 18.1: The boundary between the system and the environment

Generally, the user will have a fairly good idea of the general boundary between the system and the environment. But, as illustrated in Figure 18.2, there is often a “gray area” that is open for negotiation, an area that the user (1) isn’t sure about, (2) hadn’t thought about, (3) had some preconceived ideas about which he or she is willing to rethink, or (4) all the above.

Thus, for example, the user may ask the systems analyst to develop an accounts receivable system. While this may represent a well-defined, firm boundary between the system (known as the A/R system) and the environment, the systems analyst should certainly consider the “gray area,” as illustrated by Figure 18.3, of accounts payable, inventory control, cash management, invoicing, and order entry as a somewhat larger scope.

Figure 18.2: The gray area between the system and the environment

If the systems analyst chooses too small a scope for a project, he is doomed to failure, for the user may have unwittingly identified the symptom of the problem (e.g., “our accounts receivable are out of control”) rather than the cause of the problem. And if the systems analyst, through overconfidence, naivete, or exuberance, chooses too large a scope for the project, he is doomed to failure, for he will be dealing with a vastly more complex political situation, and will be attempting to develop a system that is probably too large to develop under any circumstances. And he may be dealing with issues that the user doesn’t care about or which cannot be changed at all. Thus, it is important to spend sufficient time and to get sufficient user concurrence with the choice of an appropriate system boundary.

In a large system, a number of factors may be taken into account when the scope of the project is being chosen. Among the more important factors are these:

Figure 18.3: The gray area surrounding accounts receivable systems

The area inside the system boundary is sometimes referred to as the domain of change. By this, we mean simply that everything inside the system boundary is subject to change (e.g., reorganization and/or automation), while everything outside the boundary is to be left in its current form and not investigated by the systems analyst.

To see two examples of system boundaries, examine the case studies in Appendix F and Appendix G. In the case of the YOURDON Press Information System (Appendix F), the system boundary is somewhat larger than one might have expected: it includes invoicing and handling of cash receipts that would typically be part of the Accounting Department (and thus outside the system boundary). Similarly, the elevator controller in Appendix G has a boundary somewhat smaller than one might have wanted: a very different system could have been developed if the elevator control panels had been considered part of the system rather than part of the environment. In both cases, the choices were arbitrary.

18.1 TOOLS USED TO DEFINE THE ENVIRONMENT

The environmental model consists of three components:

Each of these is discussed next.

18.1.1 The Statement of Purpose

The first component of the environmental model is a brief, concise textual statement of the purpose of the system. It is intended for top management, user management, and others who are not directly involved in the development of the system.

An example of a typical statement of purpose is:

The purpose of the Ajax Book Processing System is to handle all of the details of customer orders for books, as well as shipping, invoicing, and back-billing of customers with overdue invoices. Information about book orders should be available for other systems, such as marketing, sales, and accounting.

The statement of purpose can be one, two, or several sentences long. However, it should not be more than a single paragraph, as it is not intended to give a comprehensive, detailed description of the system. Such an effort would be self-defeating: it is the purpose of the rest of the environmental model and the behavioral model to fill in all the details.

As a result, the statement of purpose will be deliberately vague about many details. In the Ajax example above, we might ask such questions as:

These detailed questions can only be answered by looking at the behavioral model, which we discuss in Chapters 19 and 20.

While the detailed behavioral questions are not answered by the statement of purpose document, it is generally sufficient to answer a series of high-level questions:

Many systems analysts also feel that the statement of purpose should summarize the tangible, quantifiable benefits that will be achieved by the new system; for example, “the purpose of the system is to reduce the amount of time required to process an order from three days to one day.” While this can be quite useful in small, highly focused projects, it is not easy to accomplish on larger projects. Instead, a separate cost-benefit analysis is usually required.

18.1.2 The Context Diagram

The next part of the environmental model begins to answer some of the questions raised by the statement of purpose. The context diagram is a special case of the dataflow diagram, in which a single bubble represents the entire system. A context diagram for the book order system is shown in Figure 18.4. Examples of context diagrams for two real systems are provided in Appendices F and G.

Figure 18.4: A context diagram

The context diagram highlights several important characteristics of the system:

Techniques for constructing the context diagram are discussed in Section 18.2.
.
18.1.3 The Event List

The event list is a narrative list of the “stimuli” that occur in the outside world and to which our system must respond. An event list for the book order system is shown in Figure 18.5:

Figure 18.5: An event list

Note that each event is labeled with either an F, a T, or a C. This is to show whether the event is a flow-oriented event, a temporal event, or a control event. A flow-oriented event is one associated with a dataflow; that is, the system becomes aware that the event has occurred when a piece of data (or possibly several pieces of data) has arrived. As you can imagine, this will correspond to a dataflow on the context diagram.

However, not every dataflow on the context diagram is necessarily a flow-oriented event. Consider, for example, the partial context diagram shown in Figure 18.6.

Figure 18.6: A partial context diagram

At first glance, one might be tempted to conclude that dataflows A, B, and C are all indicators of separate, discrete events. However, it may turn out that only dataflow A is associated with an event (e.g., the flow of data is initiated by the terminator). In order to process the event, it may turn out that the system explicitly asks other terminators for inputs along dataflow B and C pursuant to producing some system response.

Thus, there is not necessarily a one-to-one correspondence between dataflows on the context diagram and events in the event list. In general, each dataflow is either an event (or, more precisely, the indication that the event has occurred) or is required by the system in order to process an event.

In addition to flow-oriented events, a system may also have temporal events. As the name implies, temporal events are triggered by the arrival of a point in time. Thus, examples of temporal events might be the following:

Note that the temporal events are not triggered by incoming dataflows; one might imagine that the system has an internal clock with which it can determine the passage of time. However, keep in mind also that a temporal event may require the system to ask for inputs from one or more terminators. Thus, one or more dataflows may be associated with a temporal event, though the dataflows, themselves, do not represent the event itself.

Control events could be considered a special case of a temporal event: an external stimulus that occurs at some unpredictable point in time. Unlike a normal temporal event, the control event is not associated with the regular passage of time, so the system cannot anticipate it by using an internal clock. And unlike a normal flow-oriented event, the control event does not make its presence known by the arrival of data. As shown in Figure 18.7, a control event is associated with a control flow on the context diagram.

Figure 18.7: A control flow associated with a control event

The control flow could be regarded as a binary dataflow: it is either on or off, and it can switch from one state to the other at any point in time, thereby signaling the system that it needs to take some immediate action. Business-oriented information systems typically have no control flows on their context diagrams; the YOURDON Press Information System described in Appendix F, for example, has none. But control flows are quite common in real-time systems; for an example of this, look at the context diagram for the elevator control system in Appendix G.

18.1.4 Additional Components of the Environmental Model

In most projects, the event list, context diagram, and statement of purpose are sufficient. However, two additional components may be useful, depending on the nature and complexity of the system:

Even a medium-sized system will typically have a few dozen incoming and outgoing dataflows; a large system may literally have hundreds. While these dataflows will eventually be defined in great detail in the behavioral model (discussed in Chapter 20), it may be useful to begin the construction of the data dictionary now. This can be important if the interfaces between the system and the various terminators are subject to change and negotiation; the earlier one begins formally defining those interfaces (by defining the composition and meaning of the stores), the earlier they can be finalized.

Similarly, an entity-relationship diagram can be constructed of the external stores (if there are any). This can help expose relationships between the stores that otherwise would not become evident until the behavioral model was being developed. By concentrating on these relationships at this early stage, we have a way of double-checking the interactions between the terminators (who typically include the end users of the system) and the system itself.

18.2 CONSTRUCTING THE ENVIRONMENTAL MODEL

The discussion above probably makes the environmental model seem rather simple and straightforward: after all, there is only one process, a few dataflows and terminators, a short narrative description of the system’ s purpose, and a list of events. While this is true, it often turns out that the environmental model requires a great deal of work; also, it is usually developed as a series of iterative refinements, with additional details being filled in and refined.

One important reason why so many refinements and revisions are usually necessary is that no one person usually understands the full scope of the system as it is initially being defined. If the project involves a new system that will replace an existing system, it is possible to talk to the users who are currently carrying out the system’s functions; in a sense, they have the perspective of people on the inside looking out, as illustrated by Figure 18.8. However, even in this case, the various individual inside users are generally familiar only with a portion of the system, and their various views sometimes conflict. Even worse, your initial interviews with the user community may omit one or two important users whose interactions with the terminators outside the system must be modeled [1].

Figure 18.8: The user’s view of the system

It is important to spend a great deal of time and energy on the environmental model, for it is often the focal point of a number of important meetings and presentations early in the life of a systems development project. Indeed, it is often the only part of the overall system model that many high-level users and managers (the ones with the money to continue funding the project and the power to cancel the project!) will ever see. After it has been constructed and approved, you will find it pinned to several walls and bulletin boards — so it is important that it be correct.

18.2.1 Constructing the Context Diagram

The context diagram, as we have seen, consists of terminators, dataflows and control flows, data stores, and a single process representing the entire system. We will discuss each in turn next.

The easiest part of the context diagram is the process; as we have seen, it consists of a single bubble. The name inside the process is typically the name of the entire system or an agreed-upon acronym for the system. Examples are shown in Figure 18.9(a) and (b).

Note that, in the extreme case, the new system may represent an entire organization; in this case, the process name would typically be that of the organization itself, as shown in Figure 18.9(c). [2]

The terminators, as we have seen, are represented by a rectangular box on the context diagram. Terminators communicate directly with the system through dataflows or control flows, as shown in Figure 18.10(a), or through external data stores, as shown in Figure 18.10(b).

Figure 18.9(a): A typical process name for a context diagram

Figure 18.9(b): Another typical process name

Figure 18.9(c): A process name representing an entire organization

Figure 18.10(a): Direct communication between terminator and system

Figure 18.10(b): Communication through an external store

Note that terminators do not communicate directly with one another; thus, the context diagram shown in Figure 18.11 is incorrect. Actually, terminators do communicate with one another, but since, by definition, the terminators are external to the system, the nature and content of any terminator-to-terminator interactions are irrelevant to the system. If, during your discussions with the users, you find that it is essential to know when, why, or how one terminator communicates with another, then the terminators are part of the system, and they should be buried within the process bubble of the context diagram.

Figure 18.11: An incorrect context diagram

Three other points should be made about the terminators:

As a compromise, particularly if the user insists, one can label a terminator to show both the true source and the handler that conveys data into or out of the system; this is illustrated in Figure 18.14(c).

The flows shown on the context diagram model data coming into the system and data transported out of the system, as well as control signals received by the system or generated by the system. Dataflows are included on the context diagram if they are needed to detect an event in the environment to which the system must respond, or if they are needed (as data) in order to produce a response. Dataflows may also appear on the context diagram to illustrate data that are being transported between terminators by the system. Finally, dataflows are shown on the context diagram when data are produced by the system to respond to an event.

As we have already noted, the context diagram of an essential model avoids (wherever possible) showing the implementation-oriented handlers that transport data into and out of the system. Furthermore, we want to avoid showing the implementation-oriented prompts and handshaking by which the system and the terminators tell each other that they are ready for input or output. Thus, we want to avoid drawing context diagrams like the one shown in Figure 18.15(a) because it incorporates implementation assumptions that may be drastically changed when the new system is implemented.

Figure 18.12(a): Duplicated terminators on the context diagram

Figure 18.12(b): An alternative way of showing duplicated terminators

Figure 18.13(a): A preferred way of showing a terminator

Figure 18.13(b): A less preferred way of showing a terminator

Figure 18.14(a): A terminator showing the true source of data

Figure 18.14(b): A terminator that acts as a handler

Figure 18.14(c): A terminator that combines both source and handler

Figure 18.15(a): A context diagram with unnecessary prompts

Instead, we should draw the context diagram on the assumption that inputs are caused by and initiated by the terminators, and that outputs are caused by and initiated by the system. By avoiding the extraneous prompts and implementation-oriented inputs and outputs, we model only the net flow of data.

However, there will be occasions when a terminator does not initiate input, because, even given perfect technology, the terminator does not know that the system requires its input. Similarly, there are occasions when the system does not initiate the generation of output, because it does not know that the terminator needs or wants the output. In both these cases, a prompt is an essential part of the system, and it must be shown on the context diagram; an example is shown in Figure 18.15(b). It is sometimes convenient to show the prompt and the corresponding input or output flow with a dialogue flow (a double-headed arrow), as shown in Figure 18.15(c). [3]

Figure 18.15(b): Dialogue flows to show essential prompts

Figure 18.15(c): An alternative way to show dialogue flows

18.2.2 Constructing the Event List

The event list, as we have seen, is a simple textual listing of the events in the environment to which the system must respond. When building the event list, make sure that you distinguish between an event and an event-related flow. For example, the following is probably not an event:

“Customer order is received by the system.”

Instead, this is probably the incoming dataflow by which the system becomes aware that the event has occurred. A more appropriate name for the event might be

“Customer places order.”

This may seem like an exercise in semantics, but it’s not. If we describe the event from the system’s point of view (i.e., from the inside looking out), we might mistakenly identify incoming flows that are not events on their own, but that are required to process some other event. Thus, we always want to describe the events from the environment’s point of view (i.e., from the outside looking in).

In most cases, the easiest way to identify the relevant events for a system is to visualize the system in action: we examine each terminator and ask ourselves what effect the terminator’s actions can have on the system. This is usually done in concert with the system’s users, who may be playing the role(s) of the terminators themselves. However, we must be careful to distinguish between discrete events that have been accidentally “packaged” together as if they were a single event; this happens quite often with flow-oriented events. We must examine the candidate event and ask ourselves whether all instances of the event involve the same data; if data are present in some instances and absent in others, we may actually have two distinct events. For example, if we look closely at the event “customer places order,” we may find that some instances of the event include the data element “salesperson-ID” and others do not; and we may find that the system’s response is different if a salesperson is involved than if there is no salesperson. Thus, it might be more appropriate to have two separate events: “customer places order,” and “salesperson places customer order.”

Also, keep in mind that the event list must include not only normal interactions between the system and its terminators, but also failure mode situations as well. Since we are creating an essential model, we do not have to worry about failures of our system; but we do have to take into account possible failures or errors caused by the terminators. As Paul Ward and Stephen Mellor point out in Structured Development for Real-Time Systems (New York: YOURDON Press, 1985),

Since the terminators are by definition outside the bounds of the system-building effort represented by the model, the implementors cannot modify the terminator technology at will to improve its reliability. Instead, they must build responses to terminator problems into the essential model of the system. A useful approach to modeling responses to terminator problems is to build a list of “normal” events and then to ask, for each event, “Does the system need to respond if this event fails to occur as expected?”

For example, our event list for the Ajax Book Order System (Figure 18.5) included an event “Book reprint order arrives at warehouse.” But what if it does not arrive in a timely fashion (e.g., within a week of the date promised by the printer)? What should the system do? We probably need an additional system-initiated event to cause the system to follow up with the printer and see why there is a delay.

18.2.3 Which Comes First, the Context Diagram or the Event List?

You can begin with either the event list or the context diagram. It really doesn’t matter, as long as you eventually produce both components of the environmental model and check to see that they are consistent with each other.

You may also find yourself talking with people who are aware of all the things that come into the system and go out of the system; some users may be able to provide you with this information, or the maintenance programmers in charge of maintaining a current version of the system might be knowledgeable in this area. This will provide you with the pieces of the context diagram as a starting point. You can then discuss the transactions that the users send to the system and the responses they expect the system to make. This allows you to create the event list from the context diagram.

However, you may find yourself in a situation where the context diagram is not available. This is particularly common at the beginning of some systems development projects: it may not be easy to immediately identify the terminators and the various flows into and out of the system. In this case, it is often more practical to begin with an ERD diagram that shows the objects and relationships. Candidate events can then be found by looking for activities or operations that cause instances of a relationship to be created or deleted. Creation of the event list can then lead to the development of the context diagram; this is illustrated in Figure 18.16.

For example, suppose we had identified the objects CUSTOMER and BOOK in a publishing system; our user might also tell us that there is a relationship, “orders,” between CUSTOMER and BOOK. A likely event, then, would be an action that creates an instance of the orders relationship; another event would an action that deletes an instance of the relationship. This would lead us to identify “Customer orders book,” and “Customer cancels book order” as events in our event list. It should not require too much investigation to realize that “customer” is a terminator for the system (while “book” is not); we could then begin to draw the context diagram.

When we have finished both components of the environmental model, we should be able to confirm the following:

Figure 18.16: Creation of the context diagram from an ERD

18.3 SUMMARY

Building the environmental model is the first and most important part of building a complete model of user requirements for a new system. At this point, it may seem like an easy job; after all, the context diagram consists of only a single bubble, and the event list looks like a simple list of transactions. But on a large project, a great deal of work can be involved: the single bubble in the context diagram may be interacting with dozens of external terminators and may have over a hundred incoming and outgoing dataflows. And the event list is also a major effort on large systems; there can easily be over a hundred events that the system has to deal with, and they all need to be identified. Also, it may be difficult to come up with an agreed-upon simple statement of why the system is to exist.

Once you have built the environmental model, it should be carefully reviewed by all the key user representatives, as well as by the project team. Then you are ready to start building the behavioral model, the model of the inside of the system. This is discussed in Chapters 19 and 20.

QUESTIONS AND EXERCISES