The Environmental Model
“The stability of the internal medium is a primary condition for the freedom and independence of certain living bodies in relation to the environment surrounding them.”
-- Claude Bernard
Lecons sur les Phenomenes de la Vie Communs aux Animaux et aux Vegetaux, 1875-1879
IN THIS CHAPTER, YOU WILL LEARN:
- Why the system boundary is arbitrary but critical;
- How to draw a context diagram for a system;
- How to produce an event list for a system; and
- How to use the context diagram and event list to build the environmental model.
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 Chapter 20 and Chapter 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.
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.
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:
- The user’s desire to achieve a certain share of the market for the product or to increase it beyond its current level. This might be done by offering a new product or increased functionality in an existing product (e.g., increased functionality offered by automated teller systems and on-line home banking systems). Or the user might try to increase market share by offering a better, faster service to the marketplace (e.g., “All of our orders are shipped within 24 hours, and we have a sophisticated system that tracks your order so we can tell where it is at all times”).
- Legislation enacted by city, state, or federal government(s). The majority of such systems are reporting systems, for example, systems that report the employment (or unemployment) of workers based on age, sex, nationality, and so on. Or a new system might have to be built to accommodate changes in the tax laws.
- A desire by the user to minimize operational expenses for some area of his or her business. This was particularly common when large companies began computerizing in the 1960s and is true for many small businesses that are installing their first computer today. But most organizations that have had computers installed for ten years or more have already taken advantage of the obvious opportunities to reduce clerical overhead.
- A desire by the user to gain some strategic advantage for the product line or business area that he is operating. The user might attempt to do this by organizing and managing information about the marketplace so that he can produce goods in a more timely and economic fashion. A good example of this is the airline industry (as well as many other recently deregulated industries) where better information about market trends and customer preferences can lead to more efficient airline schedules and fares.
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.
TOOLS USED TO DEFINE THE ENVIRONMENT
The environmental model consists of three components:
- Statement of purpose
- Context diagram
- Event list
Each of these is discussed next.
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:
- Exactly what kind of information is provided to accounting, sales, and marketing by the book order system?
- How does the book order system determine whether a customer is credit worthy? Is this determined by the system itself or by means of advice from the accounting department?
- How does the system become aware that new books have been published and are now available for sale?
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:
- Is the book order system responsible for payroll activities? No; virtually anyone reading the material above would agree that payroll is outside the scope of the system and is probably included in the accounting system.
- Is the book order system responsible for sending invoices to customers who order books? Yes; the statement of purpose says so. One could imagine this to be a subject of some debate between the book order department and the accounting department. So, it is appropriate that it be mentioned in the statement of purpose.
- Is the book order system responsible for inventory control, that is, for determining when to reorder books that are about to become out of stock? No. The statement of purpose makes no such statement. It is highly conceivable that inventory control is one of the many other systems (or departments) that will make use of information about book orders, as produced by the book order system.
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.
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 Appendix F and Appendix G.
The context diagram highlights several important characteristics of the system:
- The people, organizations, or systems with which our system communicates. These are known as terminators.
- The data that our system receives from the outside world and that must be processed in some way.
- The data produced by our system and sent to the outside world.
- The data stores that are shared between our system and the terminators. These data stores are either created outside the system and used by our system or created by our system and used outside the system.
- The boundary between our system and the rest of the world.
Techniques for constructing the context diagram are discussed in Section 18.2.
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:
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.
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:
- A daily report of all book orders is required at 9:00 AM.
- Invoices must be generated at 3:00 PM.
- Management reports must be generated once an hour.
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.
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.
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:
- Initial data dictionary, defining external flows and stores
- Entity-relationship model of the external stores
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.
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.<ref>Such users may not be important in terms of the organizational hierarchy; they may be regarded as humble clerks, secretaries, or administrators. Nevertheless, the functions they perform may be vital, and it may be crucial to accurately model the inputs they receive from the external world and the outputs they send to the outside world. The reason that the systems analyst often forgets to talk to these people is very simple: a higher-level user (i.e., the boss) will tell the systems analyst who to talk to. “Don’t bother any of my people,” the boss will say to the analyst, “they’re all too busy -- that’s why we need the new system. I’ll tell you everything you need to know about the system.” As we discussed in Chapter 3, there may not be any diplomatic way of avoiding this; but it is crucial to check the environmental model carefully to ensure that nothing is missing.</ref>
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.
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).<ref>This is an unlikely scenario for a typical systems development project, but it is beginning to happen more and more often as people use dataflow diagrams and other modeling tools described in this book to build enterprise models. This may be done without any intention of computerizing the entire enterprise, but simply to understand what already exists — especially to understand the data that the organization needs to carry out its purpose. The subject of enterprise models is discussed in William Inmon’s Information Engineering for the Practitioner (Englewood Cliffs, N.J.: Prentice-Hall, 1987), and James Martin’s Strategic Data Base Modeling (Englewood Cliffs, N.J.: Prentice-Hall, 1985).</ref>
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).
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.
Three other points should be made about the terminators:
- Some terminators may have a large number of inputs and outputs. To avoid an unnecessarily cluttered diagram, it may be convenient to draw the terminator more than once, as shown in Figure 18.12(a). Note that the duplicated terminators are marked with an asterisk; an alternative convention is to represent the duplicated terminators with a diagonal cross-hatch, as shown in Figure 18.12(b).
- When the terminator is an individual person, it is generally preferable to indicate the role that the person is playing, rather than indicating the person's identity; thus, Figure 18.13(a) is preferred over Figure 18.13(b). There are two reasons for this: first, the person carrying out the role may change over time, and it is desirable that the context diagram remain stable and accurate even if there are personnel changes. And, second, an individual person may play several different roles in the system; rather than showing one terminator labeled “John Smith” with several unrelated incoming and outgoing flows, it is more meaningful to show the various roles that John Smith plays, each as a separate terminator.
- Because we are primarily interested in developing an essential model of the system, it is important to distinguish between sources and handlers when we draw terminators on the context diagram. A handler is a mechanism, device, or physical medium used to transport data into or out of the system. Because such handlers are often familiar and visible to users of the current implementation of a system, there is often a tendency to show the handler, rather than the true source of data. However, since the new system will generally have the option of changing the technology by which data are brought into and sent out of the system, the handler should not be shown. Thus, the context diagram shown in Figure 18.14(a) is preferred to the one shown in Figure 18.14(b).
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.
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).<ref>It’s not required that you use a dialogue flow, but it does make the context diagram more readable by packaging the associated input and output together so they are immediately visible to the reader. Also, using one arrow to show that the dialogue, as opposed to two separate arrows, creates a less cluttered context diagram. This is important on large systems, where there may be as many as a hundred or more different interactions with external terminators.</ref>
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.
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 be 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:
- Each input flow on the context diagram should be needed by the system to recognize that an event has occurred, or it should be needed by the system in order to produce a response to an event, or both.
- Each output flow should be a response to an event.
- Each nontemporal event on the event list should have input from which the system can detect that the event has occurred.
- Each event should either produce an immediate output as its response, or it should store data to be output later (as a response or part of a response to some other event), or it should cause the system to change its state (as indicated on a state-transition diagram).
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 Chapter 19 and Chapter 20.
QUESTIONS AND EXERCISES
- What are the three things that are defined by the essential model?
- What kind of events must be modeled in an essential model?
- How is the boundary between the system and the environment determined by the systems analyst?
- What is the likely consequence if the systems analyst chooses too small a scope for the project?
- What is the likely consequence if the systems analyst chooses too large a scope for the project?
- What factors should be taken into account when choosing the scope for a project?
- How does the user’s desire to achieve a certain share of the market affect the scope of a system?
- How does legislation enacted by various governmental bodies affect the scope of a system?
- How does the user’s desire to minimize (or reduce) operational expenses affect the scope of a system?
- How does the user’s desire to gain some strategic advantage against competition affect the scope of a project?
- Research Project: Investigate a project in your own organization. Which factor do you think was most influential in choosing the scope? Do you think the user, the systems analyst, and the project team were aware of this and were in agreement with it?
- In general, what do you think are likely to be the key factors for systems developed in the business environment of the next decade? For example, will minimization of operational expenses be more important than changes caused by government legislation?
- What are the three major components of the environmental model?
- Approximately how long should the statement of purpose document be?
- What five characteristics of a system does a context diagram show?
- What are the components of a context diagram?
- What is an event list?
- What are the three types of events that must be modeled in a context diagram?
- What is the relationship between flows and events on the context diagram?
- What is a temporal event?
- What additional components may be found in an environmental model besides the context diagram, the event list, and the statement of purpose?
- Why is it usually necessary to make many revisions and refinements to the environmental model?
- Why is it important to ensure that the environmental model is correct?
- What kind of name should be put inside the bubble of a context diagram?
- What is an enterprise model?
- How do terminators communicate with the system?
- Do terminators communicate with each other in a system model? Why or why not?
- Under what conditions would a terminator be drawn more than once on a context diagram? How would it be shown?
- If a terminator is an individual person, how should he or she be shown on the context diagram?
- How can the systems analyst be sure that he or she has identified all the terminators in the context diagram?
- What is a handler? What is the difference between a source and a handler?
- Why should sources rather than handlers be shown on a context diagram?
- What should the systems analyst do if the user insists on showing handlers on a context diagram?
- Under what conditions are flows shown on a DFD?
- Why should prompts and handshaking generally not be shown on a context diagram?
- What does the term net flow of data mean?
- Under what conditions does a terminator not initiate input into a system?
- Under what conditions does the system not initiate output to a terminator?
- Which should be developed first, the context diagram or the event list? Why?
- What four things should be checked to ensure that the environmental model is correct?
- What is wrong with the following context diagram?
- What is wrong with the following context diagram?
- What is wrong with the following context diagram?
- What is wrong with the following context diagram?