To determine the human information requirements of a decision analysis strategy, the systems analyst must first determine the users’ objectives, along with the organization’s objectives, using either a top-down approach or an object-oriented approach. The systems analyst must understand the principles of organizations and have a working knowledge of data-gathering techniques. The top-down approach is critical because all human decisions in the organization should be related, at least indirectly, to the broad objectives of the entire organization.
Process specifications—sometimes called minispecs, because they are a small portion of the total project specifications—are created for primitive processes on a data flow diagram as well as for some higher-level processes that explode to a child diagram. They also may be created for class methods in object-oriented design, and, in a more general sense, for the steps in a use case (as discussed in Chapters “Understanding and Modeling Organizational Systems” and 10). These specifications explain the decision-making logic and formulas that will transform process input data into output. Each derived element must have process logic to show how it is produced from the base elements or other previously created derived elements that are input to the primitive process.
The three goals of producing process specifications are as follows:
- To reduce the ambiguity of the process. This goal compels the analyst to learn details about how the process works. Any vague areas should be noted, written down, and consolidated for all process specifications. These observations form a basis and provide the questions for follow-up interviews with the user community.
- To obtain a precise description of what is accomplished, which is usually included in a packet of specifications for the programmer.
- To validate the system design. This goal includes ensuring that a process has all the input data flow necessary for producing the output. In addition, all input and output must be represented on the data flow diagram.
You will find many situations in which process specifications are not created. Sometimes the process is very simple or the computer code already exists. This eventuality would be noted in the process description, and no further design would be required. Categories of processes that generally do not require specifications are as follows:
- Processes that represent physical input or output, such as read and write. These processes usually require only simple logic.
- Processes that represent simple data validation, which is usually fairly easy to accomplish. The edit criteria are included in the data dictionary and incorporated into the computer source code. Process specifications may be produced for complex editing.
- Processes that use prewritten code. These processes are generally included in a system as procedures, methods, and functions or in class libraries (that are either purchased or available free on the Web).
These blocks are computer program code that is stored on the computer system. They usually perform a general system function, such as validating a date or a check digit. These general purpose subprograms are written and documented only once but form a series of building blocks that may be used in many systems throughout the organization. Thus, these subprograms appear as processes on many data flow diagrams (or as class methods discussed in Chapter 10).
