This effort involves the complete design of the subsystem to the point at which computer programs and subsystem personnel task descriptions may be written. All computer logic, data base organization, hardware/software specifications, and manual position descriptions are completely designed and documented.

Although parts of the manual and EDP subsystems design may be accomplished concurrently, much of the manual detailed design should precede the computer detailed design. This is true because it is generally possible to adapt the computer processing to any human need, while, for policy, practice, order of difficulty, or humanitarian reasons, it is often difficult to attempt to adapt human processing to computer needs.

Detailed design is the point at which the design of the subsystems may be staggered to provide a phased, development effort. This provides efficiency of personnel usage within the development organization, However, the detailed design of a total subsystem should be completed before a process or procedure within that subsystem should be completed before a process or procedure within that subsystem is committed to programming or human job synthesis. The Detailed Design team would normally be composed of program designers and procedure writers, supervised by system designers.

For medium and large systems, the distinction between Preliminary and Detailed Design is apparent, with several subsystems normally being developed from Detail Design in a staggered fashion over different time periods. For small systems, where there is no definition of subsystem, the distinction between Preliminary Design and Detailed Design becomes unclear and, in fact, unimportant. Likewise, the relative importance of some activities will vary considerably with the size and complexity of the system. In one case, there could be a very small system using an already existing file where data base design is relatively unimportant, while, in another, there could be large, complex systems and data bases requiring many man-years of design effort. In almost all cases, the activities indicated would be needed to some degree; those included in Detail Design are to:.

The specific documents produced as a result of these activities and retained in the Project File are:

Human procedures are a series of statements that establish a course of action to be followed consistently under the stated conditions (Procedures apply to individuals as do programs to computers.). They are instrumental in instructing personnel in their responsibilities and, by their systematic approach, can bring about improvements to methods, performance, and organization.

During this activity, human processes are expanded into step-by-step procedures. Each step in then described as clearly and directly as possible so that the procedure may serve as part of a job or task description of personnel, detailed enough for personnel to make a smooth transition to the new subsystem. Each step will be augmented by appropriate supporting information such as cautions and references to corrective procedures and exhibits. The narrative descriptions should be supported by a work flow. Specified in the narrative are the trigger mechanisms for the procedures and estimated time requirements. In addition, lists should be created of all document inputs, outputs, manual files and man/machine interfaces pertinent to that procedure.

Key points in the execution of this activity are:

Corrective procedures are also included with the objective of providing operating personnel with the appropriate procedures which will ensure reasonable operation of the system in the face of any emergency. these procedures will describe the trigger mechanism and the step-by-step details of manual corrections, including human error detection and recovery.

Several factors enter into development of corrective procedures, such as the significance of the particular failure, its effect on completion time, its expected frequency, and the additional cost of developing the procedure itself. On the basis of these factors, estimates are made of the support and maintenance requirements - the requisite skill and knowledge levels of maintenance personnel, facilities needed, central versus local maintenance, work aids required, etc. Finally, procedures are designed for the positions of support and maintenance.

After the various procedures have been established, they are carefully evaluated in terms of:

The evaluation of Procedural Practices cannot be thorough and exhaustive until worker performance using the practices can be assesses. This means that a training program may be developed and representative workers trained before the practices can be fully validated. However, a "walk through" evaluation of each procedure is essential and should be accomplished as early as practicable in the development effort. This type of evaluation will help to point out the inconsistencies and incompleteness in areas where more information is required to finalize the design work. Particular attention should be given to interface requirements between procedures in order to ensure an optimally designed work flow.

In this activity, the design of all manual operating forms is completed. These forms include all subsystem written communications except those which exist as computer interfaces. The characteristics and formats of such documents are governed by company policy, tradition, human engineering factors, in addition to the content requirements. Care should be exercised to ensure that the design of such forms optimizes the function to be performed.

Only forms specifically required to transmit or store required data should be considered. Many inefficiencies are often built into manual systems by the creation of a paper "jungle".

The key points to remember in the design of operating forms are:

In addition, the design of all computer interfaces to human procedures is completed. This area is especially difficult because the formats of data oriented towards humans and those of data easily digestible by computers are usually quite different. Traditionally, there has been a tendency to develop computer forms and force people to use them, rather than to develop human-engineered forms or displays and force computers to deal with them. Certainly in the development of man/machine interfaces, the primary consideration must be toward making the data easily understandable, easily retrievable, and highly reliable for human consumption. Usually, only the size is fixed with regard to computer I/O - 80 column cards, 132 print positions, or 1,000 video display positions.

Within this size constraints, the major considerations are human engineering factors and peripheral hardware characteristics; e.g., it is easier and quicker to punch column 1 of a card that column 80. The prime human engineering factors to consider are emphasis, legibility, alignment, spacing, contrast, and brevity.

The specific points to remember are:

This activity is an interaction between the manual and EDP designers until an agreed form and format for each interface is reached.

The design of the Physical Data Base consists of synthesizing the requirements of the Logical Data Base, specified hardware, data management software requirements and the user-processing requirements into an optimum, implementable whole. A considerable number of difficulties may be found within this activity. In the simplest case, the subsystem merely requires the use of an already existing and therefore, fully designed file. In the worst case, there is a requirement for a complex structured, integrated data base, supported by a sophisticated data management system, using data from a variety of sources. Of course, the normal situation falls somewhere in between.

During this activity, the required data base items are grouped into physical record formats. The logical data requirements are analyzed in terms of the processes using them and of those that are relative to each other. It may be the case that logical data requirement descriptions will differ drastically and, in turn, be unlike the physical data base records (records used to pass information between programs are likely to be less complicated). The record format could change as a result of hardware change, software requirements, physical handling, performance standards, conditional relationships, record overhead loading, audit trail requirements, accessing variations, file restoration needs, or file security requirements. All these should be analyzed and indicated in the physical design, giving special consideration to:

The subsystem data base may be the same as the system data base, or it may be a compatible subset.

A highly critical area is concerned with the software used; whether standard manufacturer-supplied file accessing methods are used, such as ISAM, or a more comprehensive data management system, such as IMS. In all cases, the software will strongly influence the physical implementation, either from the point of limiting the implementation, or by expanding the possibilities. Exactly how the selected software is to be used is very important; whether it is developed internally or is obtained from outside.

Also, during this activity, record types selected from existing systems are evaluated against the record formats prescribed for the new system data base, resulting in the design of the data base conversion system required.

It is possible that some portion of the required conversion logic will be produced by the designers of the new system, since the data base design and management techniques selected require the insertion of control type information which may not exist in existing records.

Any utility software used must be parameterized in order to accomplish the format conversion. The programs which have been designed to insert control information and construct data base records must be coded, and the overall logic assembled into an operational set of machine programs.

Some of the required data may not exist in a capturable form, and conversion methods and programs would be needed to exact the information from manual sources, or to generate it.