System Design

System Design
 System design is the phase that bridges the gap
between problem domain and the existing system.
 This phase focuses on the solution domain, i.e. “how
the system could be implemented?”
 Software design transform user requirements into some
suitable solution, which helps the programmer in
software coding and implementation.
 Systems design is the process of defining the
architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements.
 It is the most crucial phase in the developments of a
system. The output of this process can directly be used
into implementation of programming languages.
 We can’t just throw the software for programmers
to start programming without any detailed plans.
 Design is highly creative stage in software
development where the designer plans:
– how the system or program should meet the
customer’s needs
– how to make system effective and efficient.
 In this phase, the complex activity of system
development is divided into several smaller sub-
activities, which coordinate with each other to
achieve the main objective of system development.
 Two stages of System design
– High-Level or Architectural Design
• In the preliminary or general design, the features and
main components of the new system are specified.
– Low-Level or Detailed Design
• At this stage, the design of the system becomes more
structured.
• Input, output, databases, forms, codification schemes
and processing specifications are drawn up in detail.
– At the highest level, an outline of the solution to
the problem is presented whereas at the lower
level the solution to the problem is presented in
detail.
 1. High Level Design
 High Level Design (HLD) is the overall system
design - covering the system architecture design.
 HLD explains the architecture that would be used
for developing a software product.
 It describes the relation between various modules
and functions of the system.
 Data flow, flow charts and data structures are
covered under HLD.
 Architectural design
 The architectural design emphasizes the design of
the structure, behavior and views of that system.
 A system architecture is the conceptual model that
defines the structure, behavior, and relationship
between various modules of system development
process
 The architecture diagram provides an overview of
an entire system, identifying the main components
that would be developed for the product and their
interfaces.
 It is composed of various components of a system,
the attributes (properties) of those components and
the relationship amongst them, that will work
together to implement the overall system
Example of Software architecture
Example of Web Application
Software architecture
 System architecture does the following
– It describes the structure and behavior of the
system.
– Provides an insight to all the interested
stakeholders
– Highlights early design decisions, which have
great impact on the software engineering activities
– Creates intellectual models of how the system is
organized into components and how these
components interact with each other.
– It defines the structure and relationship between
various modules of system development process.
 The architectural design is the highest abstract
version of the system.
 Data Flow Diagram
 DFD (Data Flow Diagram):
 DFD is a designing concept used to transform a
textual problem into pictorial or graphical form in a
hierarchical order.
 It describes how   data and information are
transformed in a system in a pictorial manner.
 A data flow diagram (DFD) maps out the flow of
information for any process or system.
 A DFD is often used as a preliminary step to create
an overview of the system without going into great
detail, which can later be elaborated. DFDs can also
be used for the visualization of data processing
 DFD uses symbols like rectangles, circles
and arrows, plus short text labels to show
data inputs, outputs, storage points and the
routes between each destination.
 DFD provides a complete description of:-
– What data are processed?
– How processing is done?
– What data are stored?
– Which stored data are used and
– Where the result flows?
 A  DFD models a system by using external
entities from which data flows to a process
which transform the data  and creates output
data flow which go to other processes or
external entities or data stores .  
 From data stores, stored data may also flow
to process as inputs.
 Example

 Here External entity 1 gives input data to

process1 after this processed data 1 is
stored in data store , now stored data  is
given to process 2 and finally processed
data 2  is consumed by External entity 2.
Symbols and Notations Used in DFDs
 External entity:
 an outside system that sends or receives data,
communicating with the system being
diagrammed.
 They are the sources and destinations of
information entering or leaving the system.
 They might be an outside organization or person,
a computer system or sub system.
 They are also known as terminators, sources and
sinks or actors.
 They are typically drawn
 on the edges of the diagram.
Symbols and Notations Used in DFDs
 Process:
– any process that changes the data, producing
an output.
– It might perform computations, or sort data
based on logic, or direct the data flow based on
business rules.
– A process can be decomposed to finer level of
details, for representing how data is being
processed within the process. 
– A short label is used to describe the process,
such as “Submit payment.”
 Symbols and Notations Used in DFDs
 Data store:
– A data store represents the storage of persistent
data required and/or produced by the process.
– files or repositories that hold information for later
use, such as a database table or a membership
form.
– Each data store receives a simple label, such as
“Orders.”
 Some examples of data stores: membership forms,
database table, etc.
 Data flow:
– the route that data takes between the external
entities, processes and data stores.
– It portrays the interface between the other
components and is shown with arrows, typically
labeled with a short data name, like “Billing
details.”
 A data flow represents the flow of information, with
its direction represented by an arrow head that
shows at the end(s) of flow connector. 
Example
 How to draw a DFD
 The purpose of a DFD is to show the scope and
boundaries of a system as a whole.
 It is usually beginning with a context diagram as
the level 0 of DFD diagram, a simple
representation of the whole system.
 Level 1 diagram decomposed from the major
functions of the system.
 Level 2 diagram when further analysis is required.
Progression to level 3, 4 and so on is possible but
anything beyond level 3 is not very common.
 The level of details for decomposing particular
function really depending on the complexity that
function
 Data Flow Diagram Levels
 Context Diagram
– A context diagram is a top level (also known as "Level
0") data flow diagram. It only contains one process node
("Process 0") that generalizes the function of the entire
system in relationship to external entities.

– It’s a basic overview of the whole system or process

being analyzed or modeled. showing the system as a
single high-level process, with its relationship to external
zero level DFD for university
routine management project.
 Description for zero level DFD
 Here detailed information regarding each student
and teacher  are given and in response every
student has got SIN(student identification num) or
Roll No. and for teacher it is TIN(teacher
identification num).
 Database Manager will perform all the data entry
job.
After giving routine generating command a routine
will be generated. 
Admin can view the every user , his performance
and get the result by giving the query.  
first level DFD of university
management:
 Description of 1st level: 
 every student , every teacher , evey class
room and every subject should be registerd
– Here  student_info datastore contain information
regarding student.
– Here  teacher_info datastore contain information
regarding teacher.
– Here  class_info datastore contain information
regarding class.
– Here subject_info datastore contain information
regarding subject
 second level DFD of university management:
 Description of second level DFD:
 class will be managed by  the process 
– Attendance Submit
– Lecture plan given by teacher.
– Student feedback given by teacher.
– Teacher feedback given by student.
   Here Data stores are:
–  Attendance
– Lecture-plan info
– Student feedback
– Teacher feedback.  
 Levels of DFD
 Progression to Levels 3, 4 and beyond is
possible, but going beyond Level 3 is uncommon.
 Doing so can create complexity that makes it
difficult to communicate, compare or model
effectively.
 Using DFD layers, the cascading levels can be
nested directly in the diagram, providing a cleaner
look with easy access to the deeper dive.
 By becoming sufficiently detailed in the DFD,
developers and designers can use it to write
pseudocode, which is a combination of English and
the coding language.  Pseudocode facilitates the
development of the actual code.
 DFD rules and tips
 Each process should have at least one input and
an output.
 Each data store should have at least one data flow
in and one data flow out.
 Data stored in a system must go through a
process.
 All processes in a DFD go to another process or a
data store.
 The necessary level of detail depends on the
scope of what you are trying to accomplish.
 It should be easily understood by a wide audience,
including stakeholders, business analysts, data
analysts and developers.
 2. Low Level Design
 The low-level design breaks the ‘single entity-
component’ of architectural design into less-
abstracted view of sub-systems and modules and
depicts their interaction with each other.
 Low-level design (LLD) is a component-level design
process that follows a step-by-step refinement
process.
 This process can be used for designing data
structures, source code and ultimately,
performance algorithms.
 The LLD phase is the stage where the actual
software components are designed.
 The goal of LLD is to
– give the internal logical design of the actual program
code.
– It describes the class diagrams with the methods
and relations between classes.
– It describes the modules so that the programmer can
directly code the program from the document.
– A good low-level design document makes the
program easy to develop. The code can then be
developed directly from the low-level design
document with minimal debugging and testing.
– Other advantages include lower cost and easier
maintenance.
 Modularity Design
 Modularity is achieved by dividing the software into
uniquely named and addressable components,
which are also known as modules. 
 A complex system (large program) is partitioned
into a set of discrete modules in such a way that
each module can be developed independent of
other modules.
 After developing the modules, they are integrated
together to meet the software requirements.
 Note that larger the number of modules a system is
divided into, greater will be the effort required to
integrate the modules.
 Modularizing a design helps to
– plan the development in a more effective manner,
– accommodate changes easily,
– conduct testing and debugging effectively and efficiently,
and
– conduct maintenance work without adversely affecting
the functioning of the software.
 Modularization
 Structured design uses an approach called
Modularization or decomposition to minimize the
complexity and to manage the problem by
subdividing it into smaller segments.
 The main focus while developing the design of the
system is the quality of the software design.
 A good quality software design is the one, which
minimizes the complexity and cost expenditure in
software development.
 The two important concepts related to the system
development that help in determining the
complexity of a system are coupling and
cohesion.
 Coupling
 Coupling is the measure of the independence of
components.
 It defines the degree of dependency of each
module of system development on the other.
 In practice, this means the stronger the coupling
between the modules in a system, the more
difficult it is to implement and maintain the system.
 Each module should have simple, clean interface
with other modules, and that the minimum number
of data elements should be shared between
modules.
 High Coupling
 These type of systems have interconnections with
program units dependent on each other. Changes
to one subsystem leads to high impact on the other
subsystem.
 Low Coupling
 These type of systems are made up of
components which are independent or almost
independent.
 A change in one subsystem does not affect any
other subsystem.
 Cohesion
 Cohesion is the measure of closeness of the
relationship between its components.
 It defines the amount of dependency of the
components of a module on one another.
 In practice, this means the systems designer must
ensure that −
– They do not split essential processes into fragmented
modules.
– They do not gather together unrelated processes
represented as processes on the DFD into meaningless
modules.
– The best modules are those that are functionally
cohesive. The worst modules are those that are
coincidentally cohesive.
 Detailed Level Design (DLD)
 Detailed design is also part of LLD which deals
with the implementation part of what is seen as a
system and its sub-systems.
 It is more detailed towards modules and their
implementations.
 As you go even further into the details, you are
looking at your algorithm, state transitions, logical
sequence, and how internal parts of the code work
together.
 It defines logical structure of each module and
their interfaces to communicate with other
modules.
 It is also used to design internals of the individual
modules i.e. data structures and algorithms of the
modules are designed and documented.
 DLD describes each and every module in an
elaborate manner so that the programmer can
directly code the program based on it.
 It further exposes the logical detailed design of
– each of these elements for programmers.
– functional logic of the module in pseudo code
– database tables with all elements including their
type and size
– all interface details with complete API references
(both requests and responses)
 Pseudocode
 Pseudocode is an informal high-level description of
the operating principle of a computer program or
algorithm.
 It uses the structural conventions of a normal
programming language, but is intended for human
reading rather than machine reading.
 Pseudocode typically omits details that are
essential for machine understanding of the
algorithm,
 It is a detailed yet readable description of what a
computer program or algorithm must do,
expressed in a formally-styled natural language
rather than in a programming language.
 Pseudocode is not actual programming language.
It is a simple way of writing programming code in
English.
 It uses short phrases to write code for programs
before you actually create it in a specific language.
 Once you know what the program is about and
how it will function, then you can use pseudocode
to create statements to achieve the required
results for your program.
 Pseudocode allow designers to express the design
in great detail and provides programmers a detailed
template for the next step of writing code in a
specific programming language.
 Catching errors at the pseudocode stage is less
costly than catching them later in the development
process.
 Once the pseudocode is accepted, it is rewritten
using the vocabulary and syntax of a programming
language.
 example
 So let’s say we want to express the following
algorithm: – Print out the numbers from 1 to 5
 Pseudocode
PROGRAM Print1to5: A = 1;
WHILE (A != 6)
DO Print A;
A = A + 1;
ENDWHILE;
END.
 pseudocode generally does not actually obey the
syntax rules of any particular language; there is no
systematic standard form, although any particular
writer will generally borrow style and syntax from
some conventional programming language.
 Why Pseudocode
 The purpose of using pseudocode is that it is
easier for people to understand than conventional
programming language code, and that it is an
efficient and environment-independent description
of the key principles of an algorithm.

Pseudocode omits programming level details and

so it makes things very easy to understand for
human being and implement it in any
programming language easily.
 The point of pseudocode is to design a program
that can be translated into any language.
 Examples of Pseudocode
 An example of pseudocode to create a
program to add 2 numbers together and
then display the result.
Start Program
Enter two numbers, A, B
Add the numbers together
Print Sum
End Program
 Physical design
 The physical design relates to the actual input and
output processes of the system.
 This is explained in terms of how data is input into a
system, how it is verified/authenticated, how it is
processed, and how it is displayed.
 In physical design, the following requirements
about the system are decided.
– Input requirement,
– Output requirements,
– Storage requirements,
– Processing requirements,
 Physical design, does not refer to the tangible physical
design of an information system. It would not concern
the actual layout of the tangible hardware,
 But involves input via a keyboard, processing within
the CPU, and output via a monitor, printer, etc.
 During physical design, the analyst team decides
– which programming languages the computer
instructions will be written in,
– which database systems and file structures will be
used for the data and
– which hardware platform, operating system and
network environment the system will run under.
 physical system design can be
into three sub-tasks
1. User Interface Design
– is concerned with how users add information to the
system and with how the system presents information
back to them.

2. Data Design
– is concerned with how the data is represented and
stored within the system.

3. Process Design
– is concerned with how data moves through the
system, and where it is validated, secured and/or
transformed as it flows into, through and out of the
system.
 1.System User Interface Design
 User interface is the front-end application view to
which user interacts in order to use the system.
 User can manipulate and control the software as
well as hardware by means of user interface.
 UI provides fundamental platform for human-
computer interaction.
 User Interface (UI) Design focuses on anticipating
what users might need to do and ensuring that the
interface has elements that are easy to access,
understand, and use to facilitate those actions. 
 UI can be graphical, text-based, audio-video
based, depending upon the underlying hardware
and software combination.
 Why User Interface design
– System users often judge a system by its
interface rather than its functionality
– A poorly designed interface can cause a user to
make catastrophic errors
– Poor user interface design is the reason why so
many software systems are never used
– Most users of business systems interact with
these systems through graphical interfaces
although, in some cases, legacy text-based
interfaces are still used
Best Practices for Designing an Interface
 Once you know about your user, make sure to
consider the following when designing your
interface:
– Keep the interface simple to use and attractive.
– Be consistent on all interfacing screens and use
common UI elements.
– Strategically use color and texture.
– Make sure that the system communicates what’s
happening
– The system should be responsive in short time
 User interface designs must not only be attractive
to potential users, but must also be functional and
created with users in mind.
 UI is broadly divided into two
categories
 Command Line Interface
 Graphical User Interface
 Command Line Interface (CLI)
 CLI provides a command prompt, the place where
the user types the command and feeds to the
system.
 The user needs to remember the syntax of
command and its use.
 CLI is first choice of many technical users and
programmers.
 A command is a text-based reference to set of
instructions, which are expected to be executed by
the system.
 CLI uses less amount of computer resource as
compared to GUI.
 CLI Elements
 A text-based command line interface can have the
following elements:
– Command Prompt - It is text-based notifier that is
mostly shows the context in which the user is
working. It is generated by the software system.
– Cursor - It is a small horizontal line or a vertical bar
of the height of line, to represent position of
character while typing. Cursor is mostly found in
blinking state. It moves as the user writes or deletes
something.
– Command - A command is an executable
instruction. It may have one or more parameters.
Output on command execution is shown inline on
the screen. When output is produced, command
prompt is displayed on the next line.
CLI Elements
 Graphical User Interface
 Graphical User Interface provides the user
graphical means to interact with the system.
 Typically, GUI is more resource consuming than
that of CLI. But with advancing technology, the
programmers and designers create complex GUI
designs that work with more efficiency, accuracy
and speed.
 GUI Elements
 GUI provides a set of components to interact with
software or hardware.
 A GUI system has following elements such as:
– Window - An area where contents of application are
displayed. A window may contain another window of the
same application, called child window.
– Tabs -  Tabbed Document Interface has come up to
open multiple documents in the same window.
– Menu - Menu is an array of standard commands,
grouped together and placed at a visible place (usually
top) inside the application window.
– Icon - An icon is small picture representing an
associated application.
– Cursor - Interacting devices such as mouse, touch pad,
digital pen are represented in GUI as cursors.
GUI Elements
 Application specific GUI components
 A GUI of an application contains one or more of the
listed GUI elements:
– Application Window - Most application windows uses
the constructs supplied by operating systems but many
use their own customer created windows to contain the
contents of application.
– Dialogue Box - It is a child
window that contains message
for the user and request for
some action to be taken.
For Example: Application
generate a dialogue to get
confirmation from user to
delete a file.
 Application specific GUI components
– Text-Box - Provides an area for user to type and enter
text-based data.
– Buttons - They imitate real life buttons and are used to
submit inputs to the software.
– Radio-button - Displays available options for selection.
Only one can be selected among all offered.
– Check-box - Functions similar to list-box.
When an option is selected
the box is marked as
checked. Multiple options
represented by check
boxes can be selected.
 – List-box - Provides list of available items for
selection. More than one item can be selected.

 Other impressive GUI components are:

– Sliders
– Combo-box
– Data-grid
– Drop-down list
User Interface Design Activities
 There are a number of activities performed for
designing user interface.
 The process of GUI design and implementation is
like SDLC. Any model can be used for GUI
implementation among Waterfall, Iterative or
Spiral Model.
 A model used for GUI design and development
should fulfill these GUI specific steps.
– GUI Requirement Gathering - The designers may like
to have list of all functional and non-functional
requirements of GUI.
– requirements gathering can be done by assembling a
list of the functionality required by the system to
accomplish the goals of the project and the potential
needs of the users.
 User Interface Design Activities
– User and Analysis - The designer studies who is going
to use the software GUI. The target audience matters as
the design details change according to the knowledge
and competency level of the user.
– Task Analysis - Designers have to analyze what task is
to be done by the software solution. Tasks can be
represented in hierarchical manner taking one major task
and dividing it further into smaller sub-tasks. Flow of
information among sub-tasks determines the flow of GUI
contents in the software.
 Typical questions involve:
– What would the user want the system to do?
– How would the system fit in with the user's normal
workflow or daily activities?
– GUI Design & implementation - Designers after having
information about requirements, tasks and user
environment, design the GUI and implements into code
and embed the GUI with working or dummy software in
the background. It is then self-tested by the developers.
– Information architecture design – development of the
process and/or information flow of the system (i.e. for
phone tree systems, this would be an option tree flowchart
and for web sites this would be a site flow that shows the
hierarchy of the pages).
– Prototyping – development of wireframes, either in the
form of paper prototypes or simple interactive screens.
These prototypes are stripped of all look & feel elements
and most content in order to concentrate on the interface.
 User Interface Design Activities
 Testing - GUI testing can be done in various ways.
Organization can have in-house inspection, direct
involvement of users and release of beta version are few of
them.
 Testing may include usability, compatibility, user acceptance
etc
 Usability testing – testing of the prototypes on an actual user
using a technique called think aloud protocol where you ask
the user to talk about their thoughts during the experience.
 User Acceptance - the designers need to understand the
reception of the design from the viewer’s standpoint, and
thus facilitates creating successful applications.
 The actual look and feel design of the final graphical user
interface (GUI). It may be based on the findings developed
during the user research, and refined to fix any usability
problems found through the results of testing
 Input Design
 In an information system, input is the raw data that
is processed to produce output.
 During the input design, the developers must
consider the input devices such as PC, MICR,
OMR, etc.
 Therefore, the quality of system input determines
the quality of system output.
 The objectives of input design are −
– To design data entry and input procedures
– To design source documents for data capture or
devise other data capture methods
– To design input data records, data entry
screens, user interface screens, etc.
Data Input Methods
 It is important to design appropriate data input
methods to prevent errors while entering data.
These methods depend on whether the data is
entered by customers in forms manually and later
entered by data entry operators, or data is directly
entered by users on the PCs.
 A system should prevent user from making
mistakes by −
– Clear form design by leaving enough space for writing
legibly.
– Clear instructions to fill form.
– Reducing key strokes.
– Immediate error feedback.
Some of the popular data input
methods are
 Batch input method (Offline data input
method)
 Online data input method
 Computer readable forms
 Interactive data input
 Well designed input forms and screens have
following properties −
– It should serve specific purpose effectively such
as storing, recording, and retrieving the
information.
– It ensures proper completion with accuracy.
– It should be easy to fill and straightforward.
– It should focus on user’s attention, consistency,
and simplicity.
 Output Design
 The design of output is the most important task of
any system.
 During output design, developers identify the type
of outputs needed, and consider the necessary
output controls and prototype report layouts.
 Objectives of Output Design
– To develop output design that serves the intended
purpose and eliminates the production of unwanted
output.
– To develop the output design that meets the end users
requirements.
– To form the output in appropriate format and direct it to
the right person.
 types of outputs
 External Outputs
– Manufacturers create and design external outputs for
printers.
– External outputs enable the system to leave the trigger
actions on the part of their recipients or confirm actions to
their recipients.
– Some of the external outputs are designed as turnaround
outputs, which are implemented as a form and re-enter
the system as an input.
 Internal outputs
– Internal outputs are present inside the system, and used
by end-users and managers.
– They support the management in decision making and
reporting
 Forms Design
 Both forms and reports are the product of input and
output design. The main difference is that forms
provide fields for data input but reports are purely
used for reading.
 For example, order forms, employment and credit
application, etc.
 During form designing, the designers should know −
– who will use them
– where would they be delivered
– the purpose of the form or report
 Objectives of Good Form Design
 A good form design is necessary to ensure
the following −
– To keep the screen simple by giving proper
sequence, information, and clear captions.
– To meet the intended purpose by using
appropriate forms.
– To ensure the completion of form with accuracy.
– To keep the forms attractive by using icons,
inverse video, or blinking cursors etc.
– To facilitate navigation.
 2. Data Design
 Data design is the process of producing a detailed data
model of a database.
 This data model contains all the needed logical and
physical design choices and physical storage
parameters needed to generate a design in a data
definition language, which can then be used to create
a database.
 A fully attributed data model contains detailed
attributes for each entity.
 The term database design could also be used to apply
to the overall process of designing, not just the base
data structures, but also the forms and queries used as
part of the overall database application within the
database management system
 The data design action translates data defined as
part of the analysis model into data structures at
the software component level and. When
necessary into a database architecture at the
application level.
 The data objects, attributes, and relationships
depicted in entity relationship diagrams and the
information stored in data dictionary provide a base
for data design activity.
 During the data design process, data types are
specified along with the integrity rules required for
the data.
 The process of doing database design generally
consists of a number of steps which will be carried
out by the database designer.
 Usually, the designer must:
– Determine the data to be stored in the database.
– Determine the relationships between the different
data elements.
– Superimpose a logical structure upon the data on
the basis of these relationships
 a. Determining data to be stored
 the data to be stored in the database must be
determined in cooperation with a person who does
have expertise in that domain, and who is aware of
what data must be stored within the system.
b. Determining data relationships
 a database designer must determine the
dependency within the data.
 Sometimes when data is changed you can be
changing other data that is not visible.
 c. Logically structuring data
 Arrange the data into a logical structure which can
then be mapped into the storage objects
supported by the database management system.
 In the case of relational databases the storage
objects are tables which store data in rows and
columns.
 In an Object database the storage objects
correspond directly to the objects used by the
Object-oriented programming language used to
write the applications that will manage and access
the data.
 The relationships may be defined as attributes of
the object classes involved or as methods that
operate on the object classes.
 ER diagram (entity-relationship model)
 Data designs also include ER (entity-relationship
model) diagrams.
 An ER diagram is a diagram that helps to design
databases in an efficient way.
 Attributes in ER diagrams are usually modeled as
an oval with the name of the attribute, linked to the
entity or relationship that contains the attribute.
Relational Database
Sample ER-Diagram
 3. Process Design
 Process Design helps determine the workflow,
equipment needs and implementation requirements
for a particular process.
 The Process Flow chart provides a visual
representation of the steps in a process.
 Flow charts are also referred to as Process
Mapping or Flow Diagrams.
 A flowchart is a picture of the separate steps of a
process in sequential order.
 Constructing a flow chart is often one of the first
activities of a process improvement effort,
 Flow Chart
 A flowchart is a type of diagram that
represents an algorithm, workflow or
process, showing the steps as boxes of
various kinds, and their order by connecting
them with arrows.
 The two most common types of boxes in a
flowchart are:
– a processing step, usually called activity, and
denoted as a rectangular box
– a decision, usually denoted as a diamond.
 Flowchart example
 High–Level Flowchart for an Order-Filling
Process

 Detailed Flowchart
 Commonly Used Symbols in Detailed
Flowcharts
 Process; denoted by rectangle. Usually, only one arrow
goes out of the box.
 Direction of flow from one step or decision to another.

 Decision based on a question. The question is written in

the diamond.
 More than one arrow goes out of the diamond, each one
showing the direction the process takes for a given
answer to the question.
 (Often the answers are “ yes” and “ no.”)
 Delay or wait

 Link to another page or another flowchart. The same

symbol on the other page indicates that the flow
continues there.

  Input or output

 Document
 Alternate symbols for start and end points
 When to Use a Flowchart
 To develop understanding of how a process
is done.
 To study a process for improvement.
 To communicate to others how a process is
done.
 When better communication is needed
between people involved with the same
process.
 To document a process.
 design principles
 Some of the commonly followed design
principles are as following.
– Software design should correspond to the
analysis model
– Choose the right programming paradigm:
such as procedure oriented, object-oriented, and
prototyping paradigms can be used.
– Software design should be uniform and
integrated: Software design should be
flexible: to adapt changes easily.
– Software design should ensure minimal
conceptual (semantic) errors:
 Outputs for System Design
 System design gives the following outputs −
– A data schema, often a relational schema.
– A function hierarchy diagram or web page map
that graphically describes the program structure.
– Actual or pseudocode for each module in the
program.
– A prototype for the proposed system.
 The final product of the design phase is the
physical system specifications, presented in a form,
such as diagrams or written report, ready to be
turned over to programmers and other system
builders for construction.