Murang’a University of Technology
Innovation for Prosperity
Lecture 4
Design Specification in
SAD
System Design Phase.
• The System Design Phase is the process of
translating requirements into a blueprint for
building the system.
• This phase follows the requirements analysis
and is essential to ensure that the system meets
both functional and non-functional requirements.
• The System Design Phase is crucial as it
translates the gathered requirements into a
practical, implementable structure that guides
development and ensures alignment with
stakeholder needs.
3
System Design Phase.
Here are four key activities carried out during the System
Design Phase:
Architectural Design: Defines the overall system structure,
including how different components or modules interact. It
establishes the system's high-level design and how data flows
between the components.
Database Design: Involves designing the database schema,
defining data models, and setting up relationships between
data entities using tools like Entity-Relationship Diagrams
(ERDs).
User Interface (UI) Design: Specifies the layout and
interaction elements of the system, focusing on usability and
user experience. Prototypes or mockups are often created to
visualize how users will interact with the system.
Security Design: Ensures the system is protected against
threats by incorporating security mechanisms like4
System Design Phase.
Importance of the System Design Phase:
• Blueprint for Development: Provides clear
guidance to developers on how to build the
system.
• Ensures System Alignment: Confirms that
the design aligns with the requirements and
business goals.
• Foundation for Testing: Establishes the
criteria for validating and testing the system
against requirements.
• Enhances Maintainability: Good design
ensures the system can be easily maintained, 5
Program Flowcharts and
Pseudocodes
Program Flowcharts:
• Visual Representation: Use symbols and arrows
to graphically represent the flow of a program or
process.
• Purpose: Helps visualize the logical sequence of
steps in a process, making it easier to understand
the overall flow.
• Use: Commonly used during the design phase to
outline decision points, loops, and operations.
• Advantage: Easy to follow and understand,
particularly for non-technical stakeholders.
6
Program Flowcharts
7
Program Flowcharts
8
Program Flowcharts and
Pseudocodes
Pseudocode:
• Textual Representation: Uses structured, plain
language to describe the steps in an algorithm or
process.
• Purpose: Acts as an intermediary between
human language and programming code,
outlining logic in a readable format.
• Use: Often used by developers to translate
requirements into a basic version of code logic
before actual coding.
• Advantage: More flexible and detailed than
flowcharts, closer to actual code
9
Program Pseudocodes
10
Modes of Operation in Systems
Modes of Operation refer to the different states or ways in
which a system can operate, depending on its current input or
configuration.
Key Modes:
Normal Operation Mode: The system runs under standard
conditions without any anomalies or issues.
Maintenance Mode: Used when the system is undergoing
updates, repairs, or troubleshooting. Some functions may be
restricted in this mode.
Emergency Mode: Activated during system failures or critical
situations where the system operates with limited
functionality to prevent further damage.
Safe Mode: A protective operational mode where only basic
functionalities are available to avoid system failures or risks.
11
Modes of Operation in Systems
Importance:
System Reliability:
• Ensures that the system can continue functioning
even under unusual or adverse conditions.
Operational Flexibility:
• Allows for different modes to be triggered based
on specific needs or situations.
Error Management:
• Defines fallback procedures in case of system
errors or unexpected conditions.
12
Entity-Relationship Diagrams
13
Entity-Relationship Diagrams
• Drawing an ERD
• The first step is to list the entities
that you identified during the
systems analysis phase and to
consider the nature of the
relationships that link them
• Types of Relationships
• Three types of relationships can
exist between entities:
• One-to-one
• One-to-many
• Many-to-many
FIGURE 9-14 In an entity-relationship diagram, entities are
labeled with singular nouns and relationships are labeled
with verbs. The relationship is interpreted as a simple
English sentence.
14
Entity-Relationship Diagrams
(Cont.)
• A one-to-one relationship,
abbreviated 1:1, exists
when exactly one of the
second entity occurs for
each instance of the first
entity
• Figure 9-15 shows
examples of several 1:1
relationships
• A number 1 is placed
alongside each of the two
FIGURE 9-15 Examples of one-to-one (1:1) connecting lines to
relationships
indicate the 1:1
relationship
15
Entity-Relationship Diagrams
(Cont.)
• A one-to-many
relationship, abbreviated
1:M, exists when one
occurrence of the first
entity can relate to many
instances of the second
entity, but each instance
of the second entity can
associate with only one
instance of the first entity
FIGURE 9-16 Examples of one-to-many
(1:M) relationships
16
Entity-Relationship Diagrams
(Cont.)
• A many-to-many
relationship,
abbreviated M:N,
exists when one
instance of the first
entity can relate to
many instances of
the second entity,
and one instance of
the second entity
can relate to many
instances of the
first entity
FIGURE 9-17 Examples of many-to-many (M:N) relationships.
Notice that the event or transaction that links the two entities is
an associative entity with its own set of attributes and
characteristics
17
Entity-Relationship Diagrams
(Cont.)
FIGURE 9-18 An entity-relationship diagram for SALES REP,
CUSTOMER, ORDER, PRODUCT, and WAREHOUSE. Notice
that the ORDER and PRODUCT entities are joined by an
associative entity named ORDER LINE
18
Entity-Relationship Diagrams
(Cont.)
• Cardinality
• Describes the numeric
relationship between
two entities and shows
how instances of one
entity relate to instances
of another entity
• A common method of
cardinality notation is
called crow’s foot
notation because of the
shapes, which include
circles, bars, and symbols,
FIGURE 9-19 Crow’s foot notation is a
that indicate various possibilities common method of indicating cardinality.
The four examples show how you can use
various symbols to describe the
relationships between entities
19
Entity-Relationship Diagrams
(Cont.)
FIGURE 9-20 In the
first example of
cardinality notation,
one and only one
CUSTOMER can place
anywhere from zero to
many of the ORDER
entity.
In the second example,
one and only one
ORDER can include
one ITEM ORDERED
or many.
In the third example,
one and only one
EMPLOYEE can have
one SPOUSE or none.
In the fourth example,
one EMPLOYEE, or
many employees, or
none, can be assigned
to one PROJECT, or
many projects, or none
20
Entity-Relationship Diagrams
(Cont.)
FIGURE 9-21 An ERD for a library system
drawn with Visible Analyst. Notice
that crow’s foot notation has been used and
relationships are described in both
directions
21
Data Flow Diagrams
(DFDs)
A DFD gives an overview of what data a system processes, what
transformations are performed, what data are stored, what results
are produced and where they flow.
DFD is easy to understand and quite effective when the required
design is not clear and the user wants a notational language for
communication.
22
Types of DFDs
23
Example of a DFD
24
Example of a DFD
25
Levels of DFD
0-level DFD
It is also known as a context diagram. It’s designed to be an abstraction
view, showing the system as a single process with its relationship to
external entities. It represents the entire system as a single bubble with
input and output data indicated by incoming/outgoing arrows.
1-Level DFD
This level provides a more detailed view of the system by breaking down
the major processes identified in the level 0 DFD into sub-processes. Each
sub-process is depicted as a separate process on the level 1 DFD. The data
flows and data stores associated with each sub-process are also shown. In
1-level DFD, the context diagram is decomposed into multiple
bubbles/processes.
2-level DFD
This level provides an even more detailed view of the system by breaking
down the sub-processes identified in the level 1 DFD into further sub-
processes. Each sub-process is depicted as a separate process on the level
2 DFD. The data flows and data stores associated with each sub-process
are also shown.
26
Assignment on DFDs
https://www.geeksforgeeks.org/what-is-
dfddata-flow-diagram/
https://www.javatpoint.com/software-engine
ering-data-flow-diagrams
Check the above links on DFDs.
27
Decision Table
• It is useful in situations where the resulting actions depend on the
occurrence of one or several combinations of independent
conditions.
• It is a matrix containing row or columns for defining a problem and
the actions.
Components of a Decision Table
• Condition Stub − It is in the upper left quadrant which lists all
the condition to be checked.
• Action Stub − It is in the lower left quadrant which outlines all
the action to be carried out to meet such condition.
• Condition Entry − It is in upper right quadrant which provides
answers to questions asked in condition stub quadrant.
• Action Entry − It is in lower right quadrant which indicates the
appropriate action resulting from the answers to the conditions in
the condition entry quadrant.
28
Decision Table
29
Decision Tree
30
