This activity requires the highest level of creativity and
imagination on the part of Systems Engineering. During previous
activities, Systems Engineering gained a detailed knowledge of
the current system, information requirements, and the data
elements needed to produce information. Consequently, Systems
Engineering is cognizant of timing requirements (Frequency,
Offset, and Response Time) and data dependencies (such as those
algorithms and formulas needed to produce generated and group
data). In general, the function of Systems Engineering, at this
point, is to systematize the collection, storage and processing
of data to produce the information specified in a timely manner.
Systems Engineering may consider several alternatives when
formulating the system solution:
- Re-use existing resources that are suitable for inclusion
in the application.
- Modify existing resources to accommodate the requirements.
- Create new resources.
- Select a commercial software package to implement resources.
- Design data interfaces between all of the above.
During this activity, Systems Engineering may consider and
propose multiple alternatives for User Management to evaluate
during the phase review. Ultimately, Systems Engineering must
recommend a preferred solution. This will become the basis for
"make versus buy" decisions in the next activity (G).
THE ROUGH DESIGN
Based on the Information Requirements and data
specifications, Systems Engineering begins the process of
creating a complete rough design of a system. The rough
design becomes the basis for considering the most appropriate
system solution. Even if a commercial software package is
the primary consideration, the rough design will become the
basis for evaluating the features of the product.
The creative energies of Systems Engineering are used to
devise a model of the ideal system suited to the information
needs of the user. Systems Engineering is supported by a
variety of other functions who will offer advise and suggestions
to assure a viable solution, including: Software
Engineering, Data Engineering, Data Base Administration, Data
Communications, DP Operations, User Management, and Enterprise
Engineering.
Preparation of the rough design takes on the appearance of
condensed versions of Phases 2, 3, and 4-II. The objective is
to design a system complete with sub-systems, procedures and
programs. The ISEM techniques of Chronological Decomposition
and flowcharting are extremely useful for formulating the
rough design. The steps include:
- DETERMINE OUTPUTS - Review the requirements
and determine the types of outputs needed to support them.
Remember, there is not necessarily a one-to-one relationship
between information requirements and outputs. One requirement
may result in many outputs; one output may satisfy many
requirements.
Each output is uniquely identified by number and name
and related to the appropriate information requirement
(IR/OD Relationship). The timing of the outputs are
defined as derived from the requirements. Also, the
"receiver" of the output is identified by functional
area (such as, Sales, Customer Service, Administration,
Manufacturing, etc.).
- SORT AND GROUP OUTPUTS by compatible time
frame and receivers. Each grouping will represent a basic
display/reporting sub-system and should be posted to a System
Flowchart.
Each display/reporting sub-system is uniquely identified
by number and name, along with its timing (as derived
from the outputs). Further, Systems Engineering determines
the "application logical" files (FD Objects) that will be
necessary to support the data requirements of the outputs
in each sub-system.
- DETERMINE INPUT REQUIREMENTS - the
"application logical" files supporting the outputs are sorted
and grouped based on the lowest required time frame. For
example, if one file satisfies a monthly sub-system and a daily
sub-system, then Daily is the lowest time frame that the file
must support. This will result in basic file maintenance
sub-systems where data is collected and stored in the lowest
required time frame.
Each file maintenance sub-system is uniquely identified
on the System Flowchart by number and name. The timing of
the sub-system is based on the lowest time frame required
to process the various files.
For each sub-system, Systems Engineering considers the data
"source" and determines what functional areas will need to
input data for the files. An input is defined for each user
source of data.
By this point, Systems Engineering should have a basic
system design.
- COMPLETE THE SYSTEM DESIGN - Systems
Engineering must analyze the basic design and consider merging
and separating sub-systems. This is be based on the
compatibility of:
Also, the engineer determines the need for input(s) in
each sub-system to process transactions.
The point is, the engineer must always consider the
practicality of the situation and devise an appropriate
solution.
The result of this step is a final system design as
graphically expressed by the System Flowchart.
- SUB-SYSTEM DESIGN - for each sub-system,
define the administrative procedures and, where applicable, a
computer procedure to implement the sub-system. This step
represents physical design. Consideration is given to the
physical files and equipment used to process the sub-system.
Assumptions about required computer hardware and software
begin to take shape here.
The result of this step is a Sub-System design as
graphically expressed by the Sub-System Flowchart.
- SOFTWARE DESIGN - for each computer procedure
identified, Software Engineering determines the number of
programs required to implement it. In addition, Software
Engineering determines the most suitable method for implementing
each program, including language, design technique and tool.
The result of this step is a Computer Procedure design
as graphically expressed by the Computer Procedure Flowchart.
The rough design will result in a complete model of the
system. It will reveal the need for sub-systems, procedures,
programs, inputs, outputs, and files. From the rough design,
Systems Engineering will consider:
- Which parts can be implemented using existing resources.
- Which parts can be implemented using existing resources that
will require modification.
- Which parts will require new design and development.
- Which parts can be implemented by a commercial software
package. The rough design actually becomes the
specifications for analyzing packages.
The primary purpose of the rough design is for comparative
analysis. It provides Systems Engineering with the ability to
consider alternative approaches. It also becomes the basis for
project planning in the next activity (G). This includes the
preparation of estimates, schedules, and cost/benefit analysis.
It is important to note that the design arrived at in this
activity is only a preliminary or rough design, not the final
design. As good as the design may or may not be, it should not
be considered the final product. It is the objective of the
remaining phases to finalize the design. Systems Engineering
must be cautious not to try to complete the entire system design
in Phase 1. Too much effort could be a waste of effort and
money if the User elects to discontinue the project.
After considering alternatives, Systems Engineering
determines a preferred solution.
WHATEVER SYSTEM SOLUTION IS SELECTED, SYSTEMS ENGINEERING
MUST BE ABLE TO DEMONSTRATE THAT THE SOLUTION IS WORKABLE
AND SATISFIES THE INFORMATION REQUIREMENTS.
If some information requirements were omitted or modified
to accommodate a design consideration, they should be
highlighted and explained in the Cost and Evaluation Summary.
DELIVERABLES
To express the proposed solution, Systems Engineering
prepares the following deliverables during this activity:
- System Concept Diagram - a free-form schematic
which expresses how the system will operate when implemented.
Systems Engineering should be as imaginative and as
expressive as possible when presenting the approach and
systems concepts. The diagram is analogous to an artist's
rendering as used in architecture. It attempts to bridge the
level of understanding between the Information Flow Diagram
and the System Flowchart. As a free-form graphic, it should
be prepared in terms familiar to the User. The graphic is
supported by the...
- System Logic Narrative - text narrative which
describes the System Concept Diagram and describes how the
system supports the business information requirements.
- Information Requirements/Outputs Matrix - a table
of columns and rows that demonstrates how all of the information
requirements in the project have been implemented by outputs.
- Requirements/Systems Matrix by Project - a table
that demonstrates how all of the information requirements in the
project have been implemented by the system resources
(systems, sub-systems, procedures, programs).
- Entity/System Matrix by Project - a table that
demonstrates how each each Functional Entity (FE) and
Organizational Entity (OE) will be affected by the various
parts of the system.
These deliverables are retained for inclusion in the final
phase deliverables.
In summary, this activity is one of the most creative in
ISEM. The approach selected here will carry forward throughout
the remainder of the project. Therefore, all of the parties
participating in the process must be convinced that the system
solution is viable for the company to implement.