The intent of the rough sub-system design, as prepared in
the previous phases, is to construct a viable system solution
that will adequately satisfy information requirements. As good
as the rough design may be, it should only be considered
tentative. It is during Phase 3, Activity A, where final
decisions are made regarding the Sub-System Design. To clarify,
Phase 3 confirms the Sub-System Design only. Phase 4-II, which
follows Phase 3, is used to complete the design of the software.
WHAT IS SUB-SYSTEM DESIGN?
Sub-System Design is the decomposition of the sub-system
into procedures, both administrative and, where applicable,
computer. By itself, a sub-system represents a specific
business process that operates routinely in a unique time
frame. Its purpose is to access data and/or make it available
for the production of information. As such, it is a logical
construct that simply defines WHAT data is necessary and WHEN.
The objective of Sub-System Design is to determine the most
cost-effective approach for physically processing the data,
thereby defining WHO and HOW.
There is much more to designing a sub-system than just
computer processing. It includes defining the human/machine
interface which is too frequently glossed over by programmers.
Consequently, sub-systems cannot be effectively implemented.
As a matter of fact, systems will fail more for the lack of
administrative procedures, then for the availability of well
designed computer software.
To those people entrenched in programming, the sub-system
concept is somewhat nebulous. Instead of thinking in terms of
BUSINESS PROCESSES, they tend to think in terms of COMPUTER
PROCESSES. During Phase 3, Systems Engineering must concentrate
on the synchronization of both administrative and computer
processes.
During Phase 3, the Systems Engineer takes on the role of
Industrial Engineer. Prior to this phase, the sub-system was
defined in terms of its inputs, outputs, and files. Further,
the engineer must consider the sub-system's timing and the
anticipated transaction volume. This becomes the basis for
determining:
- The types of procedures required to perform the work.
- The dependencies between procedures (the work flow).
Sub-system design is a creative process. One sub-system
can be implemented many different ways. The challenge is to
implement the sub-system in the most efficient/cost-effective
means possible.
There are several things the sub-system designer can do
that will help in this creative process. Systems Engineering
should prepare a listing of the tentative procedural steps from
input to output, with files in-between. As part of this
process, Systems Engineering considers the various
organizational units that will be involved and, in turn,
isolates what processing steps will be performed in each unit.
After a listing of steps has been prepared, Systems
Engineering studies each in terms of a procedure and considers
whether each step is a separate procedure or should be combined
with others to form one procedure. In general, separate
procedures are required whenever there is a change in business
function or organizational area (Order Processing, Shipping,
Inventory, etc.).
Systems Engineering also gives careful consideration to
the timing requirements for each procedure. In Phase 2, the
Frequency, Response Time and Offset for the sub-system was
determined. Systems Engineering must now determine the Offset
and Response Time for all of the identified procedures, both
Administrative and Computer, in the sub-system. Frequency is
only applicable to the sub-system. The sum of the response
times for the individual procedures must be equal to the
required response time for the Sub-System. If this cannot be
achieved, then the practicality of the Sub-System timing
requirements must be reviewed.
The definition of procedures is an imaginative function.
Systems Engineering must be concerned with establishing
procedures that are clear, effective and will assure the
economical operation of the sub-system. During this activity,
Systems Engineering should carefully consider:
- The environment in which the system will operate
(e.g., location, equipment, working conditions, etc.).
- The personnel who will execute the procedure
e.g., level of education, skills required, attitudes,
human senses, etc.
- Required control points.
The one factor that cannot be overlooked is the human
being. Even bad systems can be made to operate with the
cooperation of all concerned. The converse is not true. A good
system will fail without cooperation and support from the people
who must implement the sub-system. One way Systems Engineering
can develop the design and also gain support is to discuss some
ideas with those users who will eventually execute the
procedures. If they participate, success will be more easily
attained.
FILE CONSIDERATIONS
Up until Phase 3, consideration was primarily given to the
design of "application logical" files. During this activity,
Systems Engineering considers physical files that will be needed
in the execution of the sub-system. This includes:
- Manual files where input and output documents will be
collected and stored.
- Computer input transaction files - to record input
transactions for computer processing.
- Computer output data files - to supplement output reports
and screens. For example, to extract data from a data base
in a particular format to suit a special application.
DELIVERABLES
The main by-product of this activity is the Sub-System
Flowchart which shows the processing sequence and the flow of
inputs, files and outputs throughout the procedures. Upon
completion, the flowchart becomes the basis for confirming the
Sub-System Concept Diagram.