“Spartan simplicity must be observed. Nothing will be done merely because it contributes to beauty, convenience, comfort, or prestige.”

— From the Office of the Chief Signal Officer, U.S. Army
May 29, 1945

1. How to choose the automation boundary for a system;
2. How to select input devices and output devices for the user;
3. How to design input formats and output formats;
4. How to design forms for the system;
5. How to develop coding schemes for system inputs;
6. How to identify manual support activities; and
7. How to describe the system’s operational constraints.

• The essential policy, or logic, of the functions that need to be performed.
• The essential content of the data that are stored by the system and that move through the system.
• The essential time-dependent behavior that the system must exhibit in order to deal with signals and interrupts from the external environment.

• End users typically have a powerful desktop PC, connected to an enterprise-wide network that gives them access to several different mainframes or “servers.” This raises a series of questions: Which parts of the essential model will be assigned to the PC (often referred to as a “client,” under the user’s control) and which to the mainframe/server? Which part of the data will be assigned to the PC/client and which part to the mainframe/server? What will be the format of input that the user provides to the PC? What additional support activities must be provided to ensure that the user does not inadvertently damage the data on the PC/client or the mainframe/server?
• End users have more and more opportunities today to write their own programs in visual development tools like Visual Basic and Microsoft Access on PCs, in addition to “macro” facilities in spreadsheet tools like Microsoft Excel. To the extent that they get involved in such implementation issues, they need to specify the formats of inputs and outputs to the system. More importantly, they may want to decide which parts of the system will be implemented using visual development tools accessible at their desktop PC and which parts will be implemented with conventional development tools under the control of the project team. [1]
• In many situations today, the user and systems analyst may decide to prototype portions of the system, using either a high-level programming language or an application generator package. The prototyping may be done because the user is unsure of the detailed policy that will eventually have to be written into process specifications in the essential model; but more often the prototyping activity is concerned with exploration and experimentation with input formats, on-line dialogues, and output formats for screens or reports.
• For many business applications, one option available to the user is the selection and purchase of a software package, that is, an existing software product that can be licensed or purchased from a vendor. In this case, the same kind of implementation issues are important to the user: Which parts of the essential functions will be implemented by the vendor-supplied package and which parts will have to be done by the user (or implemented by the user’s IT department as a separate system)? Which parts of the essential data will be maintained by the vendor-supplied package and which parts will have to be maintained by the user? What will be the form and sequence of inputs required by the vendor-supplied system and will this be acceptable? [2]

1. Allocation of the essential model to people versus machines.
2. Details of the human-machine interaction.
3. Additional manual activities that may be needed.
4. Operational constraints that the user wishes to impose on the system.

• The user may not care where the automation boundary is. This is unlikely to ever happen, but it is a theoretical possibility. Effectively, the user is saying to the implementation team, “You tell me whether it makes more sense for portions of the system to be manual or automated.” Aside from the fact that the user normally has strong feelings about this issue, the systems analyst is usually expected to produce (as a by-product of his or her work) a revised cost-benefit analysis for the entire project. This will usually require at least some preliminary decision as to which parts of the essential model will be automated and which will be manual.
• The user may opt for a fully automated system. This is a more common situation, particularly if the system you are developing is a replacement for an existing system and the system boundary is not changing. Thus, the manual activities carried out by the user may already be outside the system boundary — represented on the context diagram as the terminators with which the system communicates.
• The user may opt for a fully manual system. This is a rather uncommon option, particularly in this age of automation, because the systems analyst usually has a vested interest in computerizing as much as possible. However, it can happen in situations where the user’s express intention is not to computerize anything, but simply to reorganize the way activities are currently being carried out in an organization.

1. The choice of input and output devices (e.g., PC/workstations, touch-sensitive screens, wireless devices, OCR devices, etc., for input; and paper reports, computer displays, voice-response units, or flashing lights for output).
2. The format of all the inputs flowing from terminators into the system.
3. The format of all the outputs flowing from the system back out to the terminators.
4. The sequence and timing of inputs and outputs in an on-line system.

• Computer “workstations.” There are various forms of this technology, but they all share common features: a keyboard, with or without a “mouse” or pointing device; a display screen, usually (but not always) supporting high-resolution color; and some degree of “local intelligence” that can be used for local editing and processing of input. In one form or another, this become one of the most common forms of input media since the mid-1980s, as the per-unit price of such devices has dropped from several thousand dollars to something below one thousand dollars. It is important to distinguish between dumb terminals that provide nothing more than a keyboard and screen; intelligent terminals that provide a variety of local editing features and a local storage capacity; and desktop computers, which have much more local storage and all the computational powers of a general-purpose computer. Intelligent terminals and desktop computers make it possible for the user to make changes and correct trivial errors instantly, rather than waiting for the delay of sending the input through telecommunication lines to the main computer; the local storage capability makes it possible for the user to enter a great deal of input even if the main computer system is not operational all the time.
• Telephone. For some applications, the Touch-Tone telephone can be an appropriate input medium [6] This is particularly advantageous for systems that must deal with the general public; as of the early part of the 21st century, only about half of the U.S. population has a home computer, and it may not be conveniently situated for the person who wants to use the system. By contrast, approximately 98% of the U.S. population has at least one phone in their home, and a growing number of families have multiple phones in the home, as well as multiple cell phones that can be used from any geographic location. Since the Touch-Tone telephone only provides numeric input, its applications are somewhat limited; it is convenient for situations where the user needs to provide such things as an account number, but would not be practical for situations requiring text entry [7].
• Voice input. Some systems may use the human voice as an input medium. Voice input technology today is capable of recognizing a vocabulary of a few thousand words for an individual user; it must be retrained for each new user. However, with a more limited vocabulary and a “smart” application (e.g., one that knows that valid input items consist of numeric digits, rather than arbitrary words), a voice-input system can handle a wide range of accents and dialects. The advantages of such an input medium are obvious; the potential disadvantages are (1) the cost of the device, especially if it has to be provided individually for each user (2) its potentially limited vocabulary, (3) and a somewhat slow response time. However, this is an area of technology that is improving rapidly, and it should be re-evaluated periodically by the systems analyst to see if it is practical and effective for a particular application.
• Optical readers and bar-code readers. Optical readers and bar-code readers can read information printed or encoded on various types of documents; this is particularly advantageous for applications like the checkout counter at a store, where the user needs to enter the product code and other relevant data about a purchase. To the extent that these devices can read data directly, it eliminates the need for the user to manually type the data on a terminal. Some optical readers can read ordinary typewritten documents, and a few can read handwritten documents. The major disadvantage of this type of input medium is its cost; another disadvantage is its error-prone tendency.
• Floppy disks. With the widespread proliferation of PCs in the office and home, floppy disks have become a popular form of input medium. Data are normally recorded on the floppy disk by off-line interaction with a personal computer (by off-line we mean that the activity is not connected to the information system under development). A typical floppy disk can store between one and two million bytes of data; this is not as much as a magnetic tape, but it is adequate for many medium-volume applications.
• Magnetic tape. Magnetic tape may be an appropriate form of input from other systems; it can also be an appropriate input medium if the user has a key-to-tape data entry device. The primary advantage of this approach, of course, is that a much larger volume of input data can be stored on a tape than on a card; the disadvantage is that the data cannot be easily manipulated once they are recorded on the tape. The punched card, on the other hand, is more primitive, but it does offer the user the flexibility of rearranging the cards or deleting some of them (by throwing them away) before submitting them to the system.
• Punched cards. Punched cards used to be the most common form of system input, but are seldom used today except on a few very large batch computer systems. One advantage of the punched card is that it can be used as a source document by the external user (e.g., think of the checks produced by some government systems; they are negotiable documents, but they are also used as direct input to a computer system). The major disadvantages of punched cards are their bulky size, limited data storage capacity, “one-time-only” usability, and susceptibility to operator errors.

• Display terminal. On-line systems that use terminals as an input medium typically use terminals as an output medium, too. The advantage of the terminal is that it can display a substantial amount of information at a high rate; with modern terminals, combinations of text and graphics can be conveniently displayed. The major disadvantage of the terminal is that it does not represent hard-copy output; the output is transient and is lost when the next display is shown.
• Voice output. For some applications, voice output is a suitable output medium. This is true in applications where the telephone is used as an input medium (see above); the same telephone can be used to convey voice output to the user. Some terminals are also equipped with voice output devices, though this is somewhat rare. The main advantage of the voice output medium is that it can be used to convey fairly brief output messages in an environment (e.g., a manufacturing facility) where the user might not have the opportunity to read printed output.
• Plotter. A plotter is normally used to produce large, intricate diagrams and drawings (e.g., architectural drawings and blueprints). Drawings that would fit onto a normal-sized page of paper can usually be produced today by laser printers or dot-matrix printers, but plotters often produce output measuring two or three feet wide by several feet long. The disadvantage of this output medium is its cost, its physical bulkiness, and the length of time required to produce the output.
• Magnetic tape or disk. Obviously, just as magnetic tape and disk can be used for input, it can be used for output. This is normally practical only in cases where the output is going to be sent to other computer systems (i.e., where the system terminator is not a person, but a computer).
• COM. COM is an acronym for Computer Output Microform. COM output is normally reserved for archival output (e.g., voluminous reference material that would be too expensive and too bulky to be produced as normal printed reports). Examples of COM are rolls of microfilm (used, for example, by banks to keep copies of canceled checks) or microfiche cards.
• Printed output. By far the most common form of output on computer systems today is printed output. This can be produced on a variety of devices: dot matrix printers (often attached to the terminal used for input), high-speed line printers, high-speed laser printers, personal laser printers, personal daisy wheel printers, and so on. The principal advantage of printed output is that it is a permanent document, and it can be used in a variety of applications outside the system. The disadvantages of printed reports are their bulkiness, the likelihood that more information (or more copies of information) will be printed than is really needed, and the relatively slow speed with which the information is produced.
• Punched cards. Just as punched cards can serve as an input medium, they can serve as an output medium. As noted earlier, punched cards can be used as legal documents; as Marjorie Leeson points out [Leeson, 1981], punched cards can serve as a “turnaround document” (i.e., a document that is sent out of the system to an external terminator and that later becomes input to the system from the same terminator). But, in general, punched cards are bulky, and they cannot hold much information; hence they are not used for most information systems today.

• The essential model may have identified the data element CUSTOMER-LAST-NAME. As a matter of essential policy, there may be no limit to the length (number of characters) of this data element. After all, what’s wrong with a last name that happens to be 357 characters long? While it doesn’t happen often, some members of European nobility may wish to demonstrate their lineage by including the names of all their ancestral forebears in their last name. This is interesting and may be of some historical significance, but the user and the systems analyst may nonetheless agree to restrict CUSTOMER-LAST-NAME to 25 characters. Note, by the way, that this will require a change to the appropriate process specification(s) that deal with the inputting of CUSTOMER-LAST-NAME to ensure that it is valid according to this implementation constraint.
• In an order entry system, a CUSTOMER-ORDER might be defined in the following way: CUSTOMER-ORDER = NAME + ADDRESS + {ORDER-ITEM}. In the essential model, there might be no reason at all to limit the number of different items that a customer might purchase in one order. From the user’s implementation perspective, though, there might be several reasons: (1) as a manual support activity (discussed further in Section 21.3, the user might want the sales clerk to write the order on a preprinted form that only has room for, say, eight different items); (2) the user might be concerned that the sales clerk will make a mistake if he or she tries to deal with more than a limited number of items in each order; (3) the user might be concerned that spending an inordinate amount of time servicing one customer with his or her 597 different items might annoy other customers waiting to be serviced. And so on. Hence there might be a number of good reasons to put a user-defined implementation constraint on this data element.

• Your system should request inputs and produce outputs in a consistent fashion. This is particularly true for on-line systems where the user can enter one of several different transactions and/or receive one of several different displays. For example, suppose that your system asks the user for the date whenever a transaction is entered; it would be frustrating and confusing if one type of transaction requires the date in the form 12/23/2003 while another transaction requires the date in the form 2003/12/23. And it would be confusing if one part of the system required the user to specify the state as a two-character code (e.g., NY for New York), while another part of the system required the state to be spelled out. Similarly, if one part of the system requires the user to provide an area code when she or he enters a telephone number, then all parts of the system should require an area code when the telephone number is entered.
• Ask for information in a logical sequence. In many cases, this depends on the nature of the application and will require careful discussions with the user. For example, suppose you are developing an order entry system, and you want the user to specify the customer’s name; this means that you will have to specify the sequence in which you want the components of “customer name” entered. One logical sequence would be to ask the user to provide the information in the following sequence:
  
  title (Mr./Ms., etc.)
  
  first name
  
  middle initial
  
  last name

last name

first name

middle initial

title

middle initial

first name

title

last name

• Make it obvious to the user what kind of error he or she has committed and where it is. In many systems, the user provides a substantial amount of information to the system for each event or transaction. In an order entry system, for example, the user may specify the customer’s name, address, and phone number, as well as information about the items being ordered, the applicable discount, shipping instructions, and sales tax. All this information may be entered in a single computer screen, or “window,” before it is sent to the system; and, of course, the system may then determine that some or all of the input is erroneous. The important thing is to make sure that the user understands the kind of error that has been committed and where the error is located; it is not acceptable for the system to simply beep once and display the message BAD INPUT. Each error (assuming there is more than one) should be identified, either with a descriptive message or (in the case of an on-line system) by highlighting or color-coding the erroneous data. Depending on the nature of the system and the user’s level of sophistication, it may also be important to display an explanatory message; this is discussed in more detail in item 5.
• Distinguish between field edits and screen edits. In many cases, your system will be able to determine whether a data element provided by the user is correct or incorrect, without reference to any other data elements. For example, if the user enters a two-character code for a state, the system should be able to immediately determine whether the two characters represent one of the fifty states, or one of the Canadian provinces, and so on. But if the user were to enter a postal code as an individual data element, there is only a limited amount of field editing the system could do without additional inputs; we would need both the postal code and the state code to determine whether the postal code should be a five-digit (or nine-digit) zip code or a six-character Canadian postal code. The system could also compare the state code and zip code to see if the zip code is in the right range (e.g., if the state code is NY then the zip code should begin with the digit 1). The relationship between data elements may be obvious to the systems analyst; however, it may require intimate, detailed knowledge of the application that can only be obtained from the user.
• Make the editing and error-checking user dependent. As indicated above, it is usually a good idea for the system to display an explanatory message when an error is detected. But this is only true if the user is unable to determine, on his own, what he did wrong. If the user typed a three-digit zip code, for example, it would not be necessary for the system to display an elaborate message about the length of zip codes; however, it would be appropriate if the user typed a five-digit zip code and the system was expecting one of the new nine-digit zip codes. Note also that (a) some users are more expert than others and may become annoyed even more quickly if they have to look at long, turgid error messages, and (b) after repetitive use, even the novice user becomes expert at some parts of the system. So it is often important to make the error messages flexible and perhaps even changeable by the user; the easiest compromise is a combination of short error messages (which may consist of nothing more than highlighting the erroneous input and ringing a bell to get the user’s attention) and long error messages (with explanatory text and a reference to the appropriate part of the user’s training manual). See also item 7 for more on this concept.
• Provide a way for the user to (a) cancel part of a transaction and (b) cancel all of a transaction. It is unwise to assume that the user will always finish entering an entire transaction without getting interrupted. With a batch computer system, this is not an issue; the system typically does not see anything from the user until several individual transactions have been composed [9]. But for on-line systems, it is an important issue: the user may have entered a customer’s name and address before discovering that she was working with the wrong customer; she wants to be able to delete what she has typed and start over. Or the user may have finished entering most of the customer information and then happen to notice that she misspelled the customer’s first name; she wants to be able to go back to that data element and correct it without losing all the other information she has typed.
• Provide a convenient “help” mechanism. For virtually any kind of non-trivial system, it is essential to provide the user with a convenient mechanism for obtaining information about how to use the system — preferably without having to read through a 500-page user manual. In some cases, an on-line “help” facility will simply provide an explanation if the user commits an error; in other cases, it might be used to explain the details of various commands or transactions available to the user. There are numerous ways of implementing such a facility, and both you and the user should investigate several typical examples before making a decision. In many cases, the strategy will depend on the presumed level of experience and skill on the part of end-users, as well as the extent of training that may be available before the user begins entering data [10].
• Distinguish between menu-driven and command-driven systems; if appropriate, give the user a choice. A menu-driven system is one that presents the user with a list of alternative choices (or functions, or transactions, etc.); once he has chosen one, he may be given another submenu, which could lead to even lower-level sub-menus before the system finally carries out some action. A command-driven system, on the other hand, expects the user to provide a detailed (and often lengthy) command indicating what he wants the system to do for him. Menu-driven systems are considered more user friendly, since they display all the available choices for the user; hence the menu-driven approach is often considered preferable for new users or if the system has to interact with a wide variety of users with different backgrounds and skill levels. But the menu-driven system is considered tedious by the experienced user, for it often requires two or three separate interactions with the system (each with some time delay) before it finally knows what the user wants; the experienced user generally prefers a command-driven system, so that he can accomplish what he wants as quickly as possible.
• If your system is engaged in lengthy processing, display a message to the user so that he won’t think the system has crashed. If your system has to carry out extensive calculations or if it is likely to be delayed periodically because of voluminous inputs, it is important to display an appropriate message to the user; otherwise, he is likely to think that his terminal has “frozen” or “hung,” or that the computer has crashed, or that there has been a power failure. At the very least, your system should flash a message (e.g., SYSTEM WORKING - PLEASE WAIT) at regular intervals. Even better would be a series of messages — or a “thermometer”-syle progress indicator — telling the user how much of the work has been finished and approximately how much longer it will take to completion.
• Provide defaults for standard inputs. In many cases, the system can make a good guess about the likely value of an input provided by the user; by making it a default, it can save the user a considerable amount of time and typing activity. This approach is valid for all types of systems, but it is especially apparent with on-line systems, where the user may not be a professional typist. One example of a default value is the date: in many applications, the most likely date that the user will enter is today’s date. Or suppose that you are building an order entry system, and the user tells you that 95% of the customers live in the local area; then when you ask the user to provide the customer’s telephone number, the system should assume that the default area code is your local area code.
• Take advantage of color and sound, but don’t overdo it. Modern computer terminals have a variety of colors and sound effects; these can be quite useful for emphasizing different kinds of input or drawing the user’s attention to important aspects of the human interface. Thus, you might use the color green for all material displayed by the system, blue for all input data provided by the user, and red for all error messages. However, you should not get carried away: most users will get annoyed if their display screen looks like a Christmas tree. The same is true of sound effects; an occasional bell or beep is useful, but the user doesn’t want the input device to produce all the sound effects from a Star Wars movie.

• Title, to distinguish this form from any other forms. The title is usually printed in large, bold letters at the top of the form so that the user knows that this is an “order form” or a “trouble report form.”
• Instructions, to tell the user how to fill out the required information on the form. General instructions are usually placed at the beginning of the form near the top; specific instructions are typically given next to, or beneath, each item of data that needs to be filled in.
• Body, the main part of the form, in which the data are entered. This may be organized in an open style, a boxed style, or a combination of both. The boxed style is typically used for information that is binary (e.g., “check this box if you want your name added to our mailing list for future product announcements”) or fixed-format (e.g., a telephone number or zip code). The open style is typically used for variable-length information such as a name or address.

• Forms bound into books (e.g., sales order books).
• Detachable multipart forms, with an original and multiple copies that can be separated (e.g., credit card charge forms).
• Continuous forms, either manually filled out or computer generated.
• Mailers: preprinted forms already inserted into an envelope, attached together as a continuous form. The computer can then print standard information such as a customer’s name and address and (through the judicious placement of carbon paper) it will be printed on both the envelope and the letter inside.

• Expandable — The code must provide space for additional entries that may be required.
• Precise — The code must identify the specific item.
• Concise — The code must be brief and yet adequately describe the item.
• Convenient — The code must be easy to encode and decode.
• Meaningful — The code must be useful to the people dealing with it. If possible, it should indicate some of the characteristics of the item.
• Operable — The code should be compatible with present and anticipated methods of data processing — manual or machine.

011-44-71-637-2182

check-digit = 0
FOR each digit in the numeric code
sum = digit multiplied by its position number
checkdigit = checkdigit + sum
END

DO WHILE there is more than one digit in check-digit
checkdigit = the sum of all the digits in check-digit
ENDDO

• Getting input into the system. If the input data are provided by computer terminals connected to the main computers via telecommunication lines, then it is possible for some or all of a transaction to be lost or scrambled. The same can happen with almost any other form of input; for example, one of a set of floppy disks might not be read into the system).
• Carrying out the computations. Once the input data get into the system, there is the remote possibility that the computer itself might malfunction, and the much larger (!) possibility that an error in the computer programs might produce an incorrect result. Computer hardware errors could occur within an individual CPU or in the interface between the various CPUs in the system configuration.
• Long-term data storage. Most systems retain data for long periods of time on magnetic disk, magnetic tape, floppy disk, and the like. It is possible for some (or all) of this data to be lost or destroyed because of computer hardware errors and/or computer software errors. The hardware errors could consist of problems in the storage device itself or problems in the connection between the CPU and the storage device. Software errors could occur either in the application programs developed by the project team or in vendor-supplied database management software.
• Getting output out of the system. The potential problems here are analogous to the problems of getting input into the system. In some cases, output must be transmitted via telecommunication lines, often to the same CRT display unit that is used for input. In other cases, output is produced on magnetic tape or on paper reports. In all cases, it is possible for output information to be lost or incorrectly altered as a result of hardware and/or software errors.

• Redundant inputs and/or outputs. In the most extreme case, duplicate copies of inputs could be provided from two different sources (e.g., from two different users at different CRT displays). And the system could produce duplicate outputs (e.g., two different copies of an output report printed on different printers). This is an unusual approach, but may have to be considered for extremely sensitive applications.
• Redundant processor technology. Data maintained by the system could be stored, in duplicate, on two different disks or magnetic tapes. And the computations carried out by the system could be done, in duplicate, on two different CPUs. Indeed, even more redundancy may be required: while a second CPU or a second disk unit allows the system to continue if the first unit breaks down completely, it does not protect against subtle errors. What if CPU1 and CPU2 carry out the same calculation (e.g., the calculation of interest on a savings account or the computation of a missile trajectory for a flight to the moon) and produce different answers? Which CPU is correct? In the extreme case, then, we could even insist on triplicate processors and triplicate data storage, with majority voting logic to determine which two computers have the right answer. But what if all three computers disagree?
• Internal redundancy. A more common way to deal with faulty technology is to provide partial redundancy. For example, a bank teller who provides data about a deposit in an on-line banking system might be asked to provide both the account number and the name of the depositor. While the account number would normally be sufficient to identify the customer’s record in the system, there is always the possibility that the teller will enter it incorrectly, or that the account number might be altered because of a telecommunications error, or an error in the CRT terminal, or an error in the CPU. Alternatively, the system might require the bank teller to enter only the account number and might verify that it is correct by displaying the customer’s name after the record has been retrieved.
• Batch controls. This is an approach that was first introduced in second-generation batch computer systems, but it is still relevant in many of today’s systems. It requires that the user keep a count of the transactions that she or he inputs to the system, as well as a cumulative total of any important data items within those transactions; in a financial system, the obvious thing to count would be the dollar amount of each transaction. Meanwhile, the system maintains its own count as it receives transactions; periodically, the system and the user compare their counts to ensure that nothing has been lost or altered. The same approach can be used with outputs: the system can maintain its own count of the number of transactions it has outputted, and this can be compared with a manual count provided by the user.
• Sequence checks. Related to the concept of batch controls is the sequence check approach. The user can assign a sequence number or transaction number for each input, and the system can verify, as it processes those inputs, that they are all in sequence and that no transaction has been lost. Similarly, the system can attach a sequence number to each output it produces, and the user can manually verify that no outputs have been lost.

• Volumes of data. The user needs to specify volumes of input transactions and the required size of data stores. This is particularly important if there are any major variations in transaction volumes (e.g., during busy times of the day or busy seasons of the year). Thus, the user may say to you, “We normally process 2000 orders a day, but the volume jumps to 4000 orders per day during the month of December.” In addition, the user needs to estimate the increase of transaction rates and storage requirements over the estimated useful life of the system. Thus, the user might say, “The INVENTORY store needs to be able to handle on-hand balances of 4000 different parts now, and we expect that we’ll be dealing with about 6000 parts within the next five years.” In general, you can expect the amount of data stored by an information system to increase by approximately 10% per year [13].
• Response time to various inputs. This may be stated in absolute terms, but is more realistically stated as a probability: “90% of all transactions must have a response time of less than 2 seconds.” In some cases, this may be stated in terms of deadlines: “The XYZ report must be produced no later than 8:00 AM every morning,” or “all deposit transactions must be processed by midnight each night so that customers can determine their current balance from their home banking systems.”
• Political constraints on implementation choices. The user may, for rational or irrational reasons, specify the brand of hardware to be used (or the brand of hardware to be avoided), the programming language to be used (“It’s gotta be programmed in Java”), the vendor of telecommunication facilities that will be used, and so on. This is to be avoided wherever possible, but you should expect at least some pressures of this sort. Note that implementation constraints are more likely to be imposed by the organization’s IT department; that is, you’re likely to hear something like, “Well, this new system sounds fine, but of course it has to conform to the corporate computing standards; that means it has run on Microsoft Windows client machines, and the database has to be implemented with Oracle.”
• Environmental constraints. Temperature, humidity, electrical (RFI) interference, power consumption, limitations on weight, size or electrical emissions, vibration, pollution, noise, radiation, and other environmental constraints may be imposed by the user on the implementation team. Sometimes the user won’t mention this explicitly; he’ll just assume that the new system will operate satisfactorily within his normal environment (e.g., in an oil refinery, on a factory floor, or in an open office environment). Thus, it may be necessary for you to document the relevant features of the user’s environment for the benefit of the implementation team. Or you may wish to simply indicate in the user implementation model that the system must operate in the user’s environment, and let the implementation team figure out for themselves what that means
• Availability and reliability constraints. The user may specify mean time between failures (MTBF) and mean time to repair (MTTR) for the system. The required system reliability may also be expressed in terms of availability; for example, the user may say, “We can’t afford anything less than 99.5% uptime for this system.”
• Security constraints. The user may specify a variety of constraints intended to minimize unauthorized use of the system. This may include a provision for account numbers and passwords (so that individual users will have to identify themselves). It may also include mechanisms to prevent unauthorized access to confidential data; some users may be allowed to read records in various stores, while other users may be allowed to modify (or delete) existing data, and still others may be allowed to append new records. And the user may request mechanisms to prevent unauthorized users from carrying out certain functions in the system (e.g., not everyone should be able to run the payroll system). Various security measures may be imposed on data coming into the system and leaving the system; this could include, for example, encryption of data transmitted over telecommunication lines [14]. And, for security purposes, the system might be required to produce an audit trail: a complete listing of all the transactions entered into the system, all the outputs produced, and perhaps even a record of all the changes made to the system’s files.

1. The current status of the existing system (assuming there is one).
2. Problems (weaknesses, missing functions, etc.) that were identified in the current system during the initial survey or feasibility study.
3. Alternative solutions that were identified.
4. An overview of the essential model and user implementation model, with as much detail as management wants to see. Typically, the high-level DFD model is presented and the detailed components of the model are made available to management for their subsequent perusal.
5. Projected costs and benefits of the new system [15].
6. Cost, schedule, and resource (work hours) estimates for the remaining phases of the project.
7. Recommendations of the project team or the systems analyst.

1. Larry Constantine and Lucy A.D. Lockwood, Software for Use. Addison Wesley, 1999.
2. Bruce Tognazzini, Tog on Interface. Addison Wesley, 1992.
3. Thomas K. Landauer, The Trouble With Computers: Usefulness, Usability, and Productivity. Cambridge, MA: MIT Press, 1995.
4. Marjorie Leeson, Systems Analysis and Design. Chicago: Science Research Associates, 1981.
5. Tom Gilb and Gerald Weinberg, Humanized Input. Cambridge, Mass.: Winthrop Publishers, 1977.
6. James Martin, Design of Man-machine Dialogues. Englewood Cliffs, N.J.: Prentice-Hall, 1973.
7. Marvin Gore and John Stubbe, Elements of Systems Analysis, 3rd ed. Dubuque, Iowa: William C. Brown Co., 1983.
8. Data Processing Techniques: Coding Methods, Form GF20-8093. White Plains, N.Y.: IBM Technical Publications Department.

1. What are the three major things that the essential model of a system describes?
2. Why is the essential model usually not enough information for the systems designers and programmers to begin implementing the system?
3. What additional information needs to be added to the essential model?
4. What is a user implementation model? What are its major components?
5. What are the two major implementation issues that users generally have strong feelings about in an information systems project?
6. Give a definition of the automation boundary of a system. What other term or synonym could be used instead of automation boundary?
7. Why do users often have strong feelings about the format of inputs and outputs of an information system?
8. Give four examples of formatting issues (involving either inputs, outputs or both) that a user might want to specify as part of the user implementation model.
9. Give three examples of formatting issues associated with on-line systems that a user might want to specify as part of the user implementation model.
10. How has the introduction of personal computers affected the work that the systems analyst must do to develop the user implementation model?
11. Give three examples of questions that will need to be answered in the user implementation model if user-controlled PCs are part of the implementation of the system.
12. How does the introduction of fourth generation programming languages in many organizations affect the work that the systems analyst must do to develop the user implementation model?
13. How does the concept of prototyping affect the development of the user implementation model in a typical systems development project?
14. How does the possible purchase of a vendor-supplied software package affect the development of the user implementation model in a typical systems development project?
15. What mistake do many organizations make when developing an essential model in a situation where they expect to user a vendor-supplied software package?
16. What are the three extreme cases that might occur when the automation boundary is being determined for an information system?
17. Under what conditions is the user likely to have no strong feelings about the placement of the automation boundary in a systems development project? How likely do you think this is in a typical organization?
18. Under what conditions is the user likely to opt for a fully automated system when the automation boundary is being determined, with all functions carried out by computers and all data stored in a computerized form?
19. Under what conditions is the user likely to opt for a fully manual system when the automation boundary is being determined? How likely do you think this is?
20. How many alternative automation boundaries do you think the project team should explore with the users before finally settling on one? Give a justification for your answer.
21. From the systems analyst’s point of view, what is the simplest thing that could happen to processes and data that have been placed outside the automation boundary when the automation boundary has been determined?
22. What is the more likely thing that the systems analyst will have to do with manual processes and manual data after the automation boundary has been determined?
23. What are the three major issues that need to be addressed when defining the automation boundary in the user implementation model?
24. Where should the systems analyst document the details of most automation boundary issues that are discussed with the user?
25. Give two examples of implementation constraints on a data element that might be determined as part of the automation boundary.
26. How can the state-transition diagram be effectively used during the development of the user implementation model?
27. What kind of manual support activities might need to be specified during the development of the user implementation model?
28. What are the five major types of operational constraints on a system that usually need to be specified in the user implementation model?
29. Why is it important to specify in the user implementation model the volume of data that the system must handle?
30. Give three examples of political constraints that might be imposed on a system as part of the user implementation model.
31. Is your bank’s automated teller system a menu-driven system or a command-driven system? What are the advantages and disadvantages of the approach taken by the system?

1. [1] This illustrates the need for good communication between the users and the implementation team, as well as systems analysts. While the users might be quite interested in using fourth generation languages, the implementation team may need to investigate the performance of the language. Systems with large volumes of input and output may find that the fourth generation languages are too inefficient. We will discuss this further in Chapter 23.
2. [2] A very important assumption is being made here: the essential model should be developed first, before the vendor-supplied package is evaluated. Many organizations do just the opposite: they first evaluate the package and then try to derive a model of essential requirements from the features of the package.
3. [3] The user procedures for manual processes can be based on the process specification for those processes. Indeed, in the simplest case, the process specification is the user procedure; however, since the process specifications have been carefully written to avoid any unnecessary implementation bias, they may need to be expanded or rewritten to provide guidance to the users.
4. [4] Think for a moment about the kind of problems that can be encountered by simply putting a PC, workstation, or CRT terminal on the user’s desk. First, there may not be room for it: the user may need all the available workspace for other things that he or she is doing. Second, there may not be enough electrical outlets to plug in the terminal/PC, the printer, the modem, and the other paraphernalia. Third, the desk may be the proper height for reading and writing, but perhaps not for typing. Fourth, the surrounding office light may cause so much glare that it is hard to read the information on the computer display screen. Fifth, the noise caused by the user’s typing on the terminal may prove bothersome to other users in the same area.
5. [5] Note that we are discussing inputs provided by the user. Many systems (especially real-time systems) must deal with devices that provide input independent of any humans (e.g., radar units, data recorders, and satellite signals).
6. [6] Note that we are distinguishing here between the use of the telephone instrument (handset) and the telecommunications line. Many terminals are connected, via a modem, to a telephone line; but here we are talking about the telephone “handset” itself as an input medium.
7. [7] This situation is beginning to change, as telephones acquire more and more intelligence, and as they acquire small LCD display units of their own.
8. [8] Indeed, you might need to use artificial-intelligence tools as well in order to experiment with natural-language input, voice input, graphical output, and so on.
9. [9] But even with a batch system, the user may find that she has entered some data into the system by mistake. It will almost always be necessary to provide the user with a facility to undo or reverse anything that she has entered. But this should have been discovered during your interviews with the user, and it should already be evident in the DFD and process specifications for the system.
10. [10] For example, some systems may have a very homogeneous group of users, all of whom have similar educational backgrounds, and all of whom are provided extensive classroom training before they begin using the system. In other cases, the system may be intended for use by the general public — in which case, it must support different ages, different educational levels, and different levels of familiarity with computer technology.
11. [11] Leave at least half an inch of vertical space for each line of handwritten information on a form. Leave at least 1/3 inch and some multiple of 1/6 inch for each line of typewritten information on a form. Make sure that the typist does not have to realign the typewriter for each line of information.
12. [12] Some other alphabetic coding schemes appear to be just the opposite of mnemonic; these are the codes that are derived from one or more of the attributes of the data element. An example is the code that one finds on the mailing label for most magazines; this subscriber code usually consists of a portion of the subscriber’s last name, his or her street address, zip code, the subscription expiration date, and other details. As such, it is certainly not mnemonic: there is no way that anyone would remember a code that is often 20 or 30 characters in length. However, once the code is given to the computer system, the subscriber’s record can be retrieved very quickly, which may be very important for a subscriber data base of several million records. For more information about such derived codes, see IBM Form GF20-8093, Data Processing Techniques: Coding Methods.
13. [13] This estimate is based on a survey of approximately 500 U.S. computer installations, as documented by Lientz and Swanson in Software Maintenance Management (Reading, Mass.: Addison-Wesley, 1980).
14. [14] Computer security is a major subject in itself and is not discussed in any detail in this book. For more information, consult textbooks on computer security and computer crime; also, contact the Computer Security Institute.
15. [15] Cost-benefit calculations are discussed in Appendix C.