FACULTY OF COMPUTING AND INFORMATION MANAGEMENT

SYSTEM DESIGN SPECIFICATION DOCUMENT

GUIDE

1. Purpose and Scope

This section provides a brief description of the Systems Design Document’s purpose and
scope.

2. System Overview
This section describes the system in narrative form using non-technical terms. This is illustrated
using data flow diagrams which include level zero and level one data flow diagrams.

(a) Level 0 Data flow diagram (DFD)

DFD Level zero diagram (also known as context diagram) shows only a single process (representing
the entire system), and associated external entities.

Figure1: General form of Level 0 DFD diagram

(b) Level one Data Flow Diagram

Data flow level one reveals the general processes and data stores. Figure 2 shows an example of
DFD level one diagram

1
Figure 2: Level 1 DFD

All the figures should be explained

3. System Architecture
In this section, describe the system and/or subsystem(s) architecture for the project based on system
requirement specification document (SRS). Examples of components include: data resources,
users, interfaces, hardware, network etc. Figure 3 and 4, shows some of the components that can be
described in system architecture.

Figure3: Components found in a system architecture design

2
Figure4: Components found in a system architecture design

4. Software Design
A software module is the lowest level of design granularity in the system. Depending on the
software development approach, there may be one or more modules per system. This section
should provide enough detailed information about logic and data necessary to completely write
source code for all modules in the system. Include the following information to describe software
designs.

 Pseudo-code for each process in DFD level1:

 Flowchart that represents each pseudo-code
 Structured chart that shows the modular breakdown of the system.

Figure 3 shows an example of pseudo code and corresponding flow chart of a certain system

3
 Figure 3: A Pseudocode and corresponding flowchart

Figure 4 shows an example of structured organization diagram illustrates the breakdown of a

system to its lowest manageable levels. Each module is represented by a box, which contains the
module's name. The tree structure visualizes the relationships between modules.

Figure 4: Structured chart of payroll system

5. File and Database Design

Interact with the Database Administrator (DBA) when preparing this section. The section should
reveal the final design of all database management system (DBMS) files.
This section reveals the final design of the DBMS files and includes the following information,
 Refined logical model; provide normalized table layouts, entity relationship diagrams, and other
logical design information
 A physical description of the DBMS schemas, sub-schemas, records, sets, tables, storage page
sizes, etc.
 Access methods (such as indexed, via set, sequential, random access, sorted pointer array, etc.)
 Estimate of the DBMS file size or volume of data within the file, and data pages, including
overhead resulting from access methods and free space
 Definition of the update frequency of the database tables, views, files, areas, records, sets, and
data pages; estimate the number of transactions if the database is an online transaction-based
system

4
Additional information may add as required for the particular project. Provide a comprehensive
data dictionary that describes the basic organization of a database. Some of the descriptions include
a list of variables in the database as well as the assigned variable names and a description of each
type of variable (e.g. character, numeric, dates). It should also include the values accepted for each
variable, and any helpful comments such as important exclusions and skip patterns. The data
dictionary is used primarily for data analysis. Table 1shows an example of Data dictionary.

Variable Variable Variable type Variable Width Values/notes

name
Participant ID ID Numeric 3 001-900
number
Cluster number CLUSTER Numeric 2 1-30
Age in months AGE Numeric 2.1 6.0-59.9
Date of birth DOB dd/mm/yyyy 1-31/1-
12/1900-2011
Sex SEX Numeric 1 1 = male 2 =
female
Date of survey SURVEY dd/mm/yyyy 15/06/2004 –
20/08/2004
Hemoglobin HB Numeric 2.1 4.0 – 18.0
Urinary iodine UI Numeric 4.1 0.0 – 1000.0
Iodine levels in IODINE Numeric 2 0,7, 15, 30
salt based on
rapid test kit

Table 1: Data dictionary

6. Human-Machine Interface
This section provides the detailed design of the system and subsystem inputs and outputs relative
to the user/operator. Any additional information may be added to this section and may be
organized according to whatever structure best presents the operator input and output designs.
Depending on the particular nature of the project, it may be appropriate to repeat these sections at
both the subsystem and design module levels. Additional information may be added to the
subsections if the suggested lists are inadequate to describe the project inputs and outputs.

(a) System Input Interface Design

This section is a description of the input media used by the operator for providing information to
the system; show a mapping to the high-level data flows described in Section 1 .2.1, System
Overview. For example, data entry screens (e.g. webpage, form, etc) optical character readers,
bar scanners, etc. If appropriate, the input record types, file structures, and database structures
provided in Section 3, File and Database Design, may be referenced. Include data element
definitions, or refer to the data dictionary.

The section provides the layout of all input data screens or graphical user interfaces (GUTs) (for
example, windows). Provide a graphic representation of each interface. Define all data elements
associated with each screen or GUI, or reference the data dictionary.

5
 It also discusses the miscellaneous messages associated with operator inputs, including the
following:

 Copies of form(s) if the input data are keyed or scanned for data entry from printed forms
 Description of any access restrictions or security considerations
 Each transaction name, code, and definition, if the system is a transaction-based processing
system
(b) System Output Design

This section describes of the system output design relative to the user/operator. System outputs
include reports, data display screens and GUIs, query results, etc. The following should be
provided, if appropriate:

 Identification of codes and names for reports and data display screens
 Description of report and screen contents (provide a graphic representation of each layout and
define all data elements associated with the layout or reference the data dictionary)
 Description of the purpose of the output, including identification of the primary users

7. System Integrity Controls

Sensitive systems use information for which the loss, misuse, modification of, or unauthorized
access to that information could affect the conduct of State programs, or the privacy to which
individuals are entitled.

Developers of sensitive State systems are required to develop specifications for the following
minimum levels of control:

 Internal security to restrict access of critical data items to only those access types required
by users
 Audit procedures to meet control, reporting, and retention period requirements for
operational and management reports
 Application audit trails to dynamically audit retrieval access to designated critical data
 Standard Tables to be used or requested for validating data fields
 Verification processes for additions, deletions, or updates of critical data
Ability to identify all audit information by user identification, network terminal
identification, date, time, and data accessed or changed.

8. Project References
This section provides a bibliography of key project references and deliverables that have been
produced before this point. Examples: SRS, Proposals etc.

9. Glossary
Supply a glossary of all terms and abbreviations used in this document. If the glossary is several
pages in length, it may be included as an appendix.