CHAPTER FOUR

SYSTEMS DESIGN
4.1. Detailed Systems Design
The Design Sequence
The detailed systems design phase of the SDLC follows a logical sequence of events: data model
the business process and design conceptual views, design the normalized database tables, design
the physical user views (output and input views), develop the process modules, specify the
system controls, and perform a system walkthrough.
An Iterative Approach typically, the design sequence listed above is not a purely linear process.
Inevitably, system requirements change during the detailed design phase, causing the designer to
revisit previous steps.
Data Model the Business Process and Design Conceptual Views- data modeling is the task of
formalizing the data requirements of the business process as a conceptual model. The primary
tool for data modeling is the entity relationship (ER) diagram. This technique is used to depict
the entities or data objects in the system. To do so, the ER diagram employs three basic symbols:
(1) entities are represented as rectangles. An entity is a resources, event or agent involved in the
business; (2) attributes are data that describe the characteristics or properties of entities. These
are represented by circle attached to entities; and (3) relationships among entities are depicted by
diamond symbols. The degree of association between two entities is represented by cardinality-
the number of records in one file that are linked to a single record in another file.
Conceptual user view
Each entity represented in ER diagram is a candidate for a user view. For example, in purchasing
process ER diagram inventory clerk, purchasing agent, receiving clerk, inventory, purchase
requisition, purchase order, receiving report and vendor are candidates for the user views.
However, some of the candidates are redundant and can be eliminated. For example, inventory
clerk, purchasing agent and receiving clerk are entities in both the purchase process and the
payroll process. Since data about these entities would normally be captured by the personnel
system, they can be eliminated as candidates for user views in this system. Eliminating the
redundant entities leaves us with viable entities as the following:

1
 Inventory Purchase
Records requisition

Purchase Vendor Receiving

order record report

The relevant data attributes associated with these entities should be determined by careful
analysis of user needs and may include both financial and nonfinancial data. A possible list of
data attribute is:
Inventory purchase Requisition Vendor
Part no. Purchase requisition number Vendor number
Description Inventory part number Vendor name
Quantity on hand Description Vendor address
Reorder point Order quantity Vendor tele no.
Expected purchase price Expected delivery date Terms of trade
Order quantity Vendor (number) Lead time
Purchase Requisition No. Order date
Purchase order number
Purchase Order Receiving Report
Purchase order number Receiving report number
Inventory part number Purchase order number
Description Inventory part number(s) received
Order quantity Condition code
Expected purchase price Quantity received
Vendor (number) Date received
Expected delivery date Carrier code
Order date Bill of lading number
Total cost of purchase Prepaid
Vendor name Collect
Vendor address Vendor name
Vendor tele. no. Vendor address

2
To the extent that the data requirements of all users have been properly specified in the data
model, the resulting data bases will support multiple user views.
Design Normalized Base Tables
The first step in the process is to assign a primary key to each of the candidate views derived
previously. Although several base tables may be required to support a single view, for the
moment each candidate view will be represented as a single non normalized table. Any
additional tables that are needed will be produced in the data normalization step. The following
are non-normalized tables with their primary keys.

Purchase-Req Inventory
PK PK
Table table
PR-Num Part-Num
P.O table
PK Vendor
PK
Rec-Rept P.O.-Num table
Ven-Num
Table PK
RR-Num

Determine Relationship among the Tables- the next step is to specify the relationships among
the tables. The following illustrates the relations among tables

Purchase-Req 1:1 Inventory

PK PK
Table table
PR-Num Part-Num

1:M 1:M M:M

P.O table
PK
Vendor
P.O.-Num PK table
1:1 Ven-Num

Rec.-Rept
Table PK
RR-Num

Relationship among tables

3
Place Foreign Keys in Tables-now that we have established, conceptually the relations between
tables, we must establish the linkages that form these relations. The links are achieved by placing
embedded keys for all the tables.
Fill the Data Base Tables with Attributes and Normalize- now that we have established the
general relationship among the tables, the attributes listed previously can be added to the table
structures. To eliminate the anomalies associated with non-normalized data, the normalization
objectives should be applied. Currently, not all the tables are in 3NF. The normalization
problems to be resolved are repeating groups of data and transitive dependencies. Specifically,
they are:
1. The attributes Part-Num, Description, Order Quantity, and Expected Price in the
Purchase order table are repeating groups. These data could exist once or many
times on each purchase order record, depending on the number of items on order
from a vendor.
2. The attributes Part-Num, Quantity Received, and Condition Code are repeating
groups in the Receiving Report table.
3. The Purchase Requisition, Purchase order, and Receiving Report tables contain
data that are not dependent on their primary keys.

4
 Inventory table
Pk PR-Num Desc QOH Reorder-point Order-Qnty Expected FK
price PR-Num

Purchase requisition table

PK Part-Num Desc. Order- Expected Ven-Num Expected Order FK
PR-Num Qnty price Del Date Date PO-Num

P.O. Table
PK Part Desc. Order Expected Ven- Expected Order Total Vendor vendor tel
PO.- Num Qnty price Num Del.Date order cost name address no
No

Rec-Rept Table
PK FK Part- Qnty Condition Carrier Date Vendor Vendor Freight Pre collect
RR- PO- Num Received code code received Name address Bill no. paid
Num Num
Vendor Table
PK Ven-num Vendor name Vendor address Tel-Num Terms Lead time

Vendor/invent table
PK Ven-Num PK Part-Num

Non-normalized tables for purchase system

The following tables’ presents the 3NF base tables that solve these problems. The normalization
process resulted in the creation of a new base table called Line Item. Each record in the table
represents an individual item on the receiving report. The table has a combined key comprising
RR-Num and Part-Num. Both keys are needed to uniquely identify each line item. The RR- Num
portion of the key provides the link to the Receiving Report table that contains general data about
the receipt. The Part-Num portion of the key is used to access the Inventory table to update the
QOH field from the Qnty Received field of the Line-Item record.

5
 Inventory table
PR-Num Desc QOH Reorder-point Order-Qnty Expected PR-Num
price

Purchase requisition table

PR-Num Part-Num Ven-Num PO-Num

P.O. Table
PO.No Part Expected Order Total
Num Del.Date order cost
Rec-Rept Table
RR- PO- Part- Carrier Date Freight Pre collect
Num Num Num code received Bill no. paid
Line Item table
RR-Num Part-Num Qnty Received Condition Code

Vendor Table
Ven-num Vendor name Vendor address Tel-Num Terms Lead time
Vendor/invent table
Ven-Num Part-Num

Normalized Tables
The normalized tables should be rich enough to support the data needs of all systems users.
The Data dictionary- provides the formal definition of the enterprise’s data. As such, it
facilitates data sharing and prevents data redundancy. System designers and end users use the
data dictionary to identify data available for new systems under development as well as existing
systems in the process of being changed. When the system’s data requirements are identified in
the data modeling step, the system designer can search the data dictionary to determine if the
needed data already exist in the organization. If so, it will not be necessary to perform the data
base table steps. If the required data do not already exist, they must be created, or acquired, and
their descriptions added to the data dictionary to keep it current.
Design Physical User Views
The physical views are the media for conveying and presenting data. These include output
reports, documents, and input screens.

Design Output Views. Output is the information produced by the system to support user tasks
and decisions. At the transaction processing level, output tends to be extremely detailed.
Revenue and expenditure cycle systems produce control reports for lower-level management and
operational documents to support daily activities. Conversion cycle systems produce reports for

6
scheduling production, managing inventory, and cost management. These systems also produce
documents for controlling the manufacturing process.
The general ledger/financial reporting systems (GL/FRS) and the management reporting system
produce output that is more summarized. The intended users of these systems are management,
stockholders, and other interested parties outside the firm. The GL/ FRS is a nondiscretionary
reporting system that produces formal reports required by law. These include financial
statements, tax returns, and other reports demanded by regulatory agencies. The output
requirements of the GL/ FRS tend to be predictable and stable over time and between
organizations.
The management reporting system (MRS) serves the need of internal management users. MRS
applications may be stand-alone systems or they may be integrated in the revenue, conversion,
and expenditure cycles to produce output that contains both financial and nonfinancial
information. The MRS produces problem-specific reports that vary considerably between
business entities.
Output Attributes- regardless of their physical form, whether operational documents, financial
statements, or discretionary reports, output views should possess the following attributes:
relevance, summarization, exceptions orientation, timeliness, accuracy, completeness, and
conciseness.
Output Reporting Techniques- while recognizing the differences in cognitive styles exist
among managers, systems designers must determine the output type and format most useful to
the user. Some managers prefer output that presents information in tables and matrices. Others
prefer information that is visually oriented in the form of graphs and charts. The issue of whether
the output should be hard copy (paper) or electronic must also be addressed.
The query and report-generating features of modern data base management systems permit the
manager to quickly create standard and customized output reports. Custom reports can present
information in different formats including text, matrices, tables, and graphs.
DESIGN INPUT VEIWS- data input views are used to capture the relevant facts about the
resources, events, and agents involved in business process transactions. Input divides into two
classes: hard-copy input and electronic input.

7
Design Hard –Copy Input. Businesses today still make extensive use of paper input documents.
In designing hard copy documents, the system designer must keep in mind several aspects of the
physical business process. Several of these are discusses below.
Handling- How will the document be handled? Will it be on the floor around grease and oil?
How many hands must it go through? Is it likely to get folded, creased, or torn? Input forms are
part of the audit trail and must be preserved in legible form. If they are to be subjected to
physical abuse, they must be of high-quality paper.
Storage- How long will the form be stored? What is the storage environment? Length of storage
time and environmental conditions will influence the appearance of the form. Data entered onto
poor-quality paper may fade under extreme condition. Again, this may have audit trail
implications. A related consideration is the need to protect the form against erasures.
Numbers of Copies- Source documents are often created in multiple copies to trigger multiple
activities simultaneously and provide a basis for reconciliation. For example, the system may
require that individual copies of sales orders go to the warehouse, the shipping department,
billing, and accounts receivable. Manifold forma are often used in such cases. A manifold form
produces several carbon copies from a single writing. The copies are normally color-coded to
facilitate distribution to the correct users.
Form size- The average number of facts captured for each transaction affects the size of the
form. For example, if the average number of items received from the supplier for each purchase
is 20, the receiving report should be long enough to record them all. Otherwise, additional copies
will be needed, which will add to the clerical work, clog the system, and promote processing
errors.
Standard forms sizes are: full-size, 8½ by 11 inches, and half size, 8½ by 5½. Card form
standards are 8 by 10 inches and 8 by 5 inches. The use of nonstandard forms can cause handling
and storage problems and should be avoided.
Form Design- Clerical errors and omissions can cause serious processing problems. Input forms
must be designed to be easy to use and collect the data as efficiently and effectively as possible.
This requires that forms be logically organized and visually comfortable to the use. Two
techniques used in well-designed forms are zones and embedded instructions.
Zone- Zones are areas on the form that contain related data. Each zone should be constructed of
lines, captions, or boxes that guide the user’s eye to avoid errors and omissions.

8
Embedded Instructions- Embedded instructions are contained within the body of the form itself
rather than on a separate sheet. If is important to place instructions directly in the zone to which
they pertain. If an instruction pertains to the entire form, it should be placed at the top of the
form. Instruction should be brief and unambiguous. As an instructive technique, active voice is
stronger, more efficient (needing fewer words), and less ambiguous than passive voice. For
example, the first instruction below is written in passive voice. The second is in active voice.
1. This form should be complete in ink
2. Complete this form in ink
Notice the difference: the second sentence is stronger, short, and clearer than the first; it is an
instruction rather than a suggestion.
Design Electronic Input- Electronic input techniques fall into two basic types: input from
source documents and direct input. Input from source documents involves the collection of data
on paper forms that are then transcribed to electronic forms in a separate operation. Direct input
procedures capture data directly in electronic form, via terminals at the source of the transaction.
Input from source Documents- Firms use paper source documents for a number of reasons. Some
firms prefer to maintain a paper audit trail that goes back to the source of an economic event.
Some companies capture data onto paper documents because direct input procedures may be
inconvenient or impossible. Other firms achieve economies of scale by centralizing electronic
data collection from paper documents.
An important aspect of this approach is to design input screens that visually reflect the source
document. The captions and data fields should be arranged on the electronic form exactly as they
are on the source document. This minimizes eye movement between the source and the screen
and maximize throughput of work.
Direct Input- Direct data input requires that data collection technology be distributed to the
source of the transaction. A very common example of this is the point-of-sale terminal in a
department store.
An advantage of direct input is the reduction of input errors that plague downstream processing.
By collecting data once, at the source, clerical is reduced since the subsequent transcription step
associated with paper documents is eliminated. The more times a transaction is manually
transcribed, the greater the potential for error.

9
Direct data collection uses intelligent forms for on-line editing that help the user complete the
form and make calculations automatically. The input screen is attached to a computer that
performs logical checks on the data being entered. This reduces input errors and improves the
efficiency of the data collection procedures. During data entry, the intelligent form will detect
transcription errors, such as illegal characters in a field, incorrect amounts, and invalid item
numbers. A beep can be used to draw attention to an error, an illegal action, or a screen message.
Thus, corrections to input can be made on the spot.
Given minimal input, an intelligent form can complete the input process automatically. For
example, a sales clerk need only enter into the terminal item numbers and quantities of products
sold. The system will automatically provide the descriptions, prices, price extensions, taxes, and
freight charges and calculate the grand total. Many time-consuming and error-prone activities are
eliminated through this technique. Modern relational data base packages have a screen painting
feature that allows the user to quickly and easily create intelligent input forms.
Data Entry Devices- A number of data entry devices are used to support direct electronic input.
These include point-of-sale terminals, magnetic ink character recognition devices, optical
character recognition devices, automatic teller machines, and voice recognition devices.
DESIGN THE SYSTEM PROCESS
Now that the data base tables and user views for the system have been designed, we are ready to
design the process component. This starts with the DFDs that were produced in the general
design phase. Depending on the extent of the activities performed in the general design phase,
the system may be specified at the context level or may be refined in lower-level DFDs. The first
task is to decompose the existing DFDs to a degree of detail that will serve as the basis for
creating structure diagrams. The structure diagrams will provide the blueprints for writing the
actual program modules.
DESIGN SYTEM CONTROL
The last step in the detailed design phase is the design of system control. This includes computer
processing controls, data base controls, manual controls over input to and output from the
system, as well as controls over the operational environment (for example, distributed data
processing controls). In practice, many controls that are specific to a type of a technology or
technique will, at this point, have already been designed, along with modules to which they
relate. This step in the design phase allows the design team to review, modify, and evaluate

10
controls with a system wide perspective that did not exist when each module was being designed
independently.
PERFORM A SYSTEM DESIGN WALKTHROUGH
After completing the detailed design, the development team usually performs a system design
walkthrough to ensure the design is free from conceptual errors that could become programmed
into the final system. Many firms have formal, structured walkthroughs conducted by a quality
assurance group. This is an independent group of programmers, analysts, users, and internal
auditors. The job of this group is to simulate the operation of the system to uncover errors,
omissions, and ambiguities in the design. Most system errors emanate from poor designs rather
than programming mistakes. Detecting and correcting errors in the design thus reduces costly
reprogramming later.
REVIEW SYSTEM DOCUMENTATION- The detailed design report documents and describes
the system to this point. This report includes:
 Designs of all screen outputs, reports and operational documents.
 Entity relationship diagrams describing the data relation in the system.
 Third normal form design for data base describing each table specifying all data
elements.
 An updated data dictionary describing each data element in the data base.
 Designs for all screen inputs and source documents for the system.
 Context diagrams for the overall system.
 Low-level data flow diagrams of specific system processes.
 Structure diagrams for the program modules in the system, including a pseudo code
description of each module.
These documents are scrutinized by the quality control group, and any errors detected are
recorded in a walkthrough report. Depending on the extent of the system errors, the quality
assurance group will make recommendation. The system design will be accepted without
modification, accepted subject to modification of minor error, or rejected because of material
errors. At this point, a decision is made either to return the system for additional design or to
proceed to the next phase- systems implementation.

11