The purpose of this phase is to design procedures to implement the sub-systems in a cost effective manner. Several events occur during this phase:

• Procedures are designed with their appointed inputs, outputs and files.

• Inputs and outputs are finalized, complete with input transactions, messages, maps, and panels.

• Narrative is written to describe the processing logic and test criteria.

• The project estimates/schedules associated with the sub-system are reappraised.

• A formal review with user management is conducted to verify the phase findings.

There can be several Phase 3's executing in parallel or, depending on resource allocations and/or project priorities, some Phase 3's may be postponed or delayed.

The formal deliverable resulting from Phase 3 is a "Sub-System Design Manual" consisting of a description of the procedures, input/output definitions, along with an updated project estimate/schedule for the sub-system. This is reviewed with management who must decide whether to:

• Approve the sub-system for continuation.

• Request revisions to the phase findings.

• Discontinue the sub-system.

Following Phase 3, this branch of the ISEM project will branch further to multiple Phase 4's; Phase 4-I for Administrative Procedures and Phase 4-II if a Computer Procedure has been identified.

Processing and data dependencies must be explicitly defined before the sub-system can branch to "Administrative Procedure Design" (Phase 4-I) and "Software Engineering" (Phase 4-II). Failure to define such detail will result in processing inconsistencies later.

The successful implementation of a system depends upon the clearness and completeness of its procedures. Many systems are ineffective or have failed in operation due to the lack of procedures. Procedures can minimize the need for trained specialists in each department in order to insure correct performance of the system. System modifications can be implemented readily through procedure revisions. Many times in the past, systems have been implemented by "word of mouth" under the guise of quicker system start-up. This increase in speed was an illusion and the end result was an increase in expense and system errors due to incorrectly prepared data and poor communications between functions. More importantly, a poor start-up of a system can create a credibility gap with the user that may never be overcome, even after all problems have been corrected. Careful delineation of procedures during sub-system design will minimize these problems.  

TYPES OF PROCEDURES

Each sub-system consists of one or more Administrative Procedures and, at most, one Computer Procedure. It is quite possible for a sub-system to be implemented without a computer procedure; a manually implemented sub-system for example. However, a sub-system will always have at least one administrative procedure, even if it is nothing more than to initiate/schedule a computer procedure.

A separate procedure should be defined any time the "work flow" crosses an organizational boundary (such as between business functions). If the procedural "work flow" within any single part of the organization appears overly complex, the engineer may define multiple procedures without necessarily crossing an organizational boundary.

An Administrative Procedure deals specifically with the human being. The Computer Procedure deals with the internal processing of the computer.

Administrative Procedures

There are three types of Administrative Procedures:

1. Manual Procedure - where the human being must perform an operation without any machine assistance. This may consist of steps involving nothing more than the use of pencil and paper. Manual procedures include the preparation of data, balancing of reports, processing documents, distribution, review of information, etc.

2. Office Automation Procedure - is concerned with providing a set of human readable instructions to perform functions in conjunction with specific office equipment. Office Automation procedures include Word Processing, Data Entry, Facsimile Transfer, Electronic Mail, etc.

3. Computer Terminal Session - where work pertains to the direct interface between the human being and the computer. For example, Data Conversion/Entry (keying) would fall into this category. Also, an interactive session where the user responds to the computer to reference information via screens is another example. Another would be where the computer operator must submit a batch job.

Computer Procedures

These procedures consist of a series of computer programs, one or more, required for the computer to perform during the the sub-system. A Computer Procedure could be as simple as one program or could have several programs within it. It ultimately depends on the type of work required. The decision as to the number of programs required to implement the computer procedure is made during Phase 4-II "Software Engineering."

Standard Operating Procedures

ISEM does not cover standard operating procedures for computer operation (e.g., logon/logoff), data control, data transmission and conversion. These procedures can vary depending on equipment, systems, software and organization. However, ISEM does assume that these procedures exist. Therefore, during sub-system design, procedures are prepared only when the system requires an action that is non-standard. For example, batch balancing pertains specifically to a particular input and requires that a specific procedure be followed.  

TIMING CONSIDERATIONS

As the sub-system is decomposed into procedures, timing is refined to express when each procedure is executed within the sub-system and how fast it must be performed. The timing for the overall sub-system is expressed in terms of:

• Frequency - how often the business cycle occurs.

• Offset - when it begins in the cycle.

• Response Time - the total amount of time allowed to deliver the information.

However, "Frequency" is not applicable for a single procedure, and "Offset" and "Response Time" take on new meaning:

• Offset - when the procedure is to begin within the time frame of the sub-system.

• Response Time - the speed by which the procedure must execute.

For additional information on "Methods of Processing," consult the Methodology Overview.  

ERGONOMICS

In a nutshell, ergonomics is concerned with adapting our physical work environment to suit the needs of the human being, not the other way around. The theory here is if we, as human beings, can easily adapt to our physical surroundings, the better we can accept and implement our work environment. This is a valid point which should be considered in any systems development undertaking, large or small. In reality, the concept is an old one as it was used by "Systems & Procedures" departments which predated the introduction of commercial computers in the workplace. But it was in the 1980's where the concept was reborn and renamed "ergonomics." This resulted in a movement where we reconsidered the design of everything from computer screens (the advent of the Graphical User Interface or "GUI"), keyboards, office furniture, etc.

Ergonomics is applied when we move from logical design to the consideration of the most suitable physical implementation. In "PRIDE"-ISEM, this occurs here in Phase 3 which is where we design the physical implementation of the business process, including the human/machine interface. It is here where we must consider the human being. A poorly designed and programmed system that can be easily used is far better than an elaborate system that alienates the users. Obviously, the objective of system developers is to produce a superior system that is easy for the users to implement and use.

In order to devise a suitable physical implementation, consideration must be given to the intelligence level of the humans who will implement the business process. To illustrate, I know of a popular electronics retailer who devised a totally new system for their service shops across the country. The idea was to give the store clerks easy access to reference products, parts and warranties. Prior to this, the service shops relied on massive printed catalogs which, although they were accurate, required considerable time to lookup components and warranties. The company wanted to expedite this process thereby improving customer satisfaction. As a result, they devised an elaborate system involving robust screens with computer graphics, and a mouse. True, the system could rapidly access data, but it tended to intimidate the clerks in the service centers (most did not have the inclination or temperament to use a computer). So much so, they refused to use it, opting instead to use their old catalogs. The new system quickly died a painful and expensive death. In this instance, the company failed to recognize the intelligence level of the clerks and their adaptability to new technology. Many such snafus can be found in the corporate world, all because developers failed to recognize the intelligence level of their targeted users.

In addition to the user's intelligence level, developers should take into consideration the human senses: hearing, seeing, touch, taste, smell. For example, what is the point of devising an elaborate color scheme for screens or forms if there is a possibility that someone may be color blind? Or to add audio responses to computer prompts if the person is either hard of hearing or the device is placed in a noisy environment? Systems are for people, not for the computer. If people cannot assimilate new technology or find it awkward to use, they will resist it wholeheartedly.

There are two basic requirements for making something ergonomically correct: It must be easy to learn and it must be easy to operate. The features required for learning a new tool or technique may or may not be the most appropriate for routine operations. For example, "menus" and "windows" are very easy for users to learn and understand initially since they can guide users through a process while sitting in front of a screen. However, in normal operation, the need to step through a number of menus to achieve a goal can be extremely frustrating and deemed a considerable waste of time by the user.

Ergonomics involves any equipment, furniture or supplies to be used in performing the work. Designing an office layout is just as important as the equipment used. Because systems affect the human senses, the Systems Engineer should consider such things as lighting, posture, sound, hand and eye movement, etc., all of which directly affects the workers.

Facade should not be confused with substance. Ergonomics is much more than being "on-line" to a computer with elaborate color graphics. It is a matter of determining and implementing the technology to suit the users. This requires a combination of skills in industrial engineering and industrial psychology. Industrial engineering provides for the synchronization of the work flow. Industrial psychology provides for the human element to be factored into the design while the system is being built, not added on later.

In terms of equipment, there are many tools for the user to operate such as monitors, keyboards, printers, scanners, microfilm/microfiche readers, multimedia equipment, computers, etc. There is often a tradeoff between a device's ease of use and its functionality. Quite often, the simpler the device is to use, the less capability it may have. The following is a partial list of devices commonly used:

1. Keyboards - System designers should be aware if the users are sufficiently proficient at using a keyboard for a particular use. Not all applications require massive typing, most just require short and simple keying. The keys themselves should be evaluated; do users prefer a flat touch panel, or the traditional keyboard with individual keys? Ultimately, it depends on the functions desired and who will operate it. Touch panels can be extremely efficient for simple operations. However, the traditional keyboard is more desirable for more complicated operations. Also, a key click response is desirable to acknowledge the key stroke.

2. Mouse, Joystick, and Pen based entry - these are effective devices for simple operations but are questionable for major production purposes (where they can actually become annoying). This is why programs are usually written to accommodate multiple input devices, such as for both a mouse and a keyboard. Perhaps the best application for these type of devices is in the area of graphics.

3. Optical Scanners - These are tools that are widely used in retail, inventory, shipping, and other routine tasks. However, there is little point to these devices if they are highly susceptible to error, requiring corrective keying. As easy as these tools are to use, it ultimately depends on the application to determine their practicality.

4. Voice Recognition - This is a field still in transition. Although it holds great promise for the future, there are currently only a few practical applications. Voice recognition systems are heavily dependent on voice tone and inflection. Speech must usually be very specific and precise, which is often difficult for people to adapt to.

5. Buttons and switches - In general, buttons and switches are very easy to use if properly labeled. However, like touch panels they have limited functions, sometimes serving a single purpose.

6. Manual Forms - Paper documents are one of the easiest forms of media for users to understand. This is because offices have operated with paper systems for years. However, forms can alienate users as easily as any other media if poorly designed. The emphasis of forms design should be on simplicity, not complexity. Fields must be self explanatory or must include some form of instructions. Screens are merely electronic analogues of paper forms. They have some advantages and disadvantages to manual forms. Systems Engineering should know the differences. Use company standards for designing forms. In general, use the following list as suggested guidelines. Many of these guidelines relate to screens as well as they do to manual forms and printouts.
   • Design the form to be easy to read and use. "Cluttered" forms that are difficult to read and use will alienate users and cause irritation.

   • Do not design the form to the edge of the paper. Leave a margin for printing. A ½" margin is good; ¾" is better.

   • "Zone" the form by the records and/or the people who will be using the form; e.g., shipping, accounting, inventory, sales, etc., and by the sequence by which it is completed.

   • Place the form name and number in a standard position, one that would be easy to read when paging through copies. Several companies use the upper-left hand corner as their standard.

   • For forms requiring typing or keying, determine the column alignment required for the machine to be used. Minimize as many keystrokes as possible when designing the form.

When using computer screens, there are several options available for design:

1. Menus - Because of their emphasis on simplicity, menus generally offer limited functions; e.g., maintain files and generate outputs. They can be designed several ways: by the output or input to be used; by the sub-system or process to be executed; by the person having to execute the process; or combinations of the above. But it should be noted that menus are tailored more for the user than they are for system functions. As a result, they may not be as efficient as other approaches.

2. Command Language - In contrast to menus is the command language approach which is aimed at greater functionality and speed. When complicated and diverse operations are required, a command language provides the greatest form of flexibility and efficiency. It allows the user to perform their duties in the fastest amount of time. As with any language though, it may be difficult for the user to learn. As such, there must be great care in the vocabulary selected. Cryptic commands may produce cryptic results. Data validation and "help" explanations are highly desirable features for a command language.

3. Graphical User Interface (GUI) - this is like having a combined form of Menus and Command Languages. This type of interface, which is normally provided on PC's, provides screen panels, windows and other conventions (action bars, pull-down-choices, checkboxes, push buttons, etc.) which the user will interact with to submit commands. The GUI provides the same type of structure and facilities as used with menus, yet provides the user with the freedom to perform different functions rapidly as under a command language.

INPUT/OUTPUT DEFINITIONS

When the procedural flow is established, Systems Engineering reviews and completes the definition of all inputs, outputs, files, records and data elements related to the sub-system. The illustrative input/output examples as prepared under Phase 2 are finalized for review. This includes the preparation of input transactions, panels, maps, messages, etc. associated with the inputs and outputs.

The technique of working backwards from outputs to inputs is a powerful concept. If an output is defined thoroughly, defining the required input is a simple task. When defining the output, the Systems Engineer must...

• Provide an example of how the output will physically appear. This will include live data values to show how the completed output will appear in practice. Ideally, the engineer should have multiple examples to express various conditions and uses of the output. Also, sample messages should be shown as required.

• Provide a textual description of the output in terms of:

  • How headings and footers are created (including pagination).

  • How the body of the output is produced, including where the data is derived from (files), and any special processing logic associated with the output.

• Define pertinent processing messages associated with the output.

The Output Description is ultimately the driving force behind the design of the Input. From these specifications the Systems Engineering should be able to define the input in terms of:

• A full example.

• A textual description of the input including:

  Its business purpose (what outputs does it support).

  The physical media of the input and how it works.

• The transactions supported by the input. Each transaction should be fully defined, in terms of field entries and default parameters. If an input relates to an input transaction file, then this relationship should be explicitly defined.

• Processing messages associated with the input.

TEST CRITERIA

The input/output logic provides the basis for defining the TEST CRITERIA of the sub-system, and, as such should be posted to the sub-system narrative (descriptive text). By Phase 3, input transactions should be fully defined, including the entries to be validated, along with default values. From this, Systems Engineering can begin to establish testing criteria for use in Phase 7. Further, Systems Engineering should anticipate the volume of transactions that the sub-system will process on the average, as well as maximum volumes. This will be used to establish processing benchmarks.  

HOW THE RD IS USED

The Record Description serves a variety of purposes, the most obvious of which is to represent a storage record as used in a File (FD). However, there are other things it can represent:

1. Input Transactions

2. Screen Panels

3. Print Maps

4. Messages & Help Text

Messages and Help Text are actually conveyed through panels and maps and should be defined as such. Typical types of messages include Errors, Warnings, and Information Messages.

As RD's, transactions, panels and maps can be easily related to pertinent Inputs and Outputs. Further, RD-to-RD relationships can be established in the IRM for control purposes.

This approach to decomposing the physical aspects of screens and reports is very conducive for translation considerations. Translation files (FD's) can be defined and developed where the panels or maps can be physically stored. As required, the panels and maps can be extracted, translated, before being returned to the file.  

UPDATING THE PROJECT PLAN

Before proceeding with the management review of Phase 3, Project Management must reappraise the Project Plan, along with the Order-of-Magnitude estimate and schedule. By the end of Phase 3 Project Management should have a clearer understanding of the sub-system and should be able to determine if the project is proceeding as planned. If not, the plans, estimates, and schedules are updated accordingly.

The principal difference between updating the project plan in Phase 3 and Phase 2, is that the Phase 3 update is used FOR THIS SUB-SYSTEM ONLY, not for others in the system. Updates to other sub-systems will occur as the various Phase 3's are executed.  

PHASE 3 REVIEW

This represents the last major management review prior to branching out to Administrative Procedure Design (Phase 4-I) and Software Engineering (Phase 4-II). The final result of Phase 3 is a complete Sub-System Design Manual. Quality Assurance reviews this manual to assure adherence to standards. It is also reviewed with management as part of the last activity In Phase 3.

It is important to understand that in this review, User Management is not just approving the design of the sub-system. They are also committing that they understand the procedures and will be responsible for their implementation.

Activity C - Prepare Design Evaluation

Project Management reviews and revises as required the Project Plan along with the Order-of-Magnitude estimate and schedule for the remaining phases in the project pertaining to this sub-system only.

Project Management and Systems Engineering then assemble the deliverables resulting from the phase and packages them into a single phase review document which is evaluated by Quality Assurance prior to conducting the formal phase review with management.

Activity D - Phase 3 Review

Project Management conducts a formal review of the "Sub-System Design Manual" with User Management and Systems Engineering. This is the last major design review meeting for User Management. As in Phases 1 and 2, the user must decide to either: approve the report, at which time the project progresses to Phase 4; disapprove of the report and cancel this part of the project, or; have the report modified before continuing. Other functions participating in the review include Software Engineering and Data Base Administration.

The formal Phase 3 "Sub-System Design Manual" consists of:

• Phase Cover Page
• Sub-System Concept Diagram
• Sub-System Logic Narrative
• Test Criteria
• Sub-System Flowchart
• Procedure Logic Narrative
• Input Discussion & Examples
• Output Discussion & Examples
• Project Estimate/Schedule Recap
• Phase Review Checklist

Based on this report and subsequent review meeting, management may elect to revise parts of the report, discontinue the project, or approve it for continuation.