UNIT 3 - Software Design Process – Software

Engineering
The design phase of software development deals with transforming the
customer requirements as described in the SRS documents into a form
implementable using a programming language. The software design
process can be divided into the following three levels or phases of design:
1. Interface Design
2. Architectural Design
3. Detailed Design

Elements of a System
1. Architecture: This is the conceptual model that defines the structure,
behavior, and views of a system. We can use flowcharts to represent
and illustrate the architecture.
2. Modules: These are components that handle one specific task in a
system. A combination of the modules makes up the system.
3. Components: This provides a particular function or group of related
functions. They are made up of modules.
4. Interfaces: This is the shared boundary across which the components
of a system exchange information and relate.
5. Data: This is the management of the information and data flow.
 Software Design Process

Interface Design
Interface design is the specification of the interaction between a system
and its environment. This phase proceeds at a high level of abstraction
with respect to the inner workings of the system i.e, during interface
design, the internal of the systems are completely ignored, and the
system is treated as a black box. Attention is focused on the dialogue
between the target system and the users, devices, and other systems with
which it interacts. The design problem statement produced during the
problem analysis step should identify the people, other systems, and
devices which are collectively called agents.
Interface design should include the following details:
1. Precise description of events in the environment, or messages from
agents to which the system must respond.
2. Precise description of the events or messages that the system must
produce.
3. Specification of the data, and the formats of the data coming into and
going out of the system.
4. Specification of the ordering and timing relationships between incoming
events or messages, and outgoing events or outputs.

Architectural Design:
Architectural design is the specification of the major components of a
system, their responsibilities, properties, interfaces, and the relationships
and interactions between them. In architectural design, the overall
structure of the system is chosen, but the internal details of major
components are ignored. Issues in architectural design includes:
1. Gross decomposition of the systems into major components.
2. Allocation of functional responsibilities to components.
3. Component Interfaces.
4. Component scaling and performance properties, resource consumption
properties, reliability properties, and so forth.
5. Communication and interaction between components.

The architectural design adds important details ignored during the

interface design. Design of the internals of the major components is
ignored until the last phase of the design.

Detailed Design:
Detailed design is the specification of the internal elements of all major
system components, their properties, relationships, processing, and often
their algorithms and the data structures. The detailed design may include:
1. Decomposition of major system components into program units.
2. Allocation of functional responsibilities to units.
3. User interfaces.
4. Unit states and state changes.
5. Data and control interaction between units.
6. Data packaging and implementation, including issues of scope and
visibility of program elements.
7. Algorithms and data structures.

Characteristics of Good Software – Software

Engineering:
What is a Good Software?
Software engineering is the process of designing, developing, and
maintaining software systems. Good software meets the needs of its
users, performs its intended functions reliably, and is easy to maintain.
1. There are several characteristics of good software that are commonly
recognized by software engineers, which are important to consider
when developing a software system.
2. These characteristics include functionality, usability, reliability,
performance, security, maintainability, reusability, scalability, and
testability.

Software Characteristics

Categories of Software Characteristics

1. Operational
In operational categories, the factors that decide the software
performance in operations. It can be measured on:
 Budget
 Usability
 Efficiency
 Correctness
 Functionality
 Dependability
 Security
 Safety
2. Transitional
When the software is moved from one platform to another, the factors
deciding the software quality:
 Portability
 Interoperability
 Reusability
 Adaptability
3. Maintenance
In this categories all factors are included that describes about how well a
software has the capabilities to maintain itself in the ever changing
environment:
 Modularity
 Maintainability
 Flexibility
 Scalability

Characterisitics of Good Software

1. Functionality: The software meets the requirements and
specifications that it was designed for, and it behaves as expected
when it is used in its intended environment.
2. Usability: The software is easy to use and understand, and it provides
a positive user experience.
3. Reliability: The software is free of defects and it performs consistently
and accurately under different conditions and scenarios.
4. Performance: The software runs efficiently and quickly, and it can
handle large amounts of data or traffic.
5. Security: The software is protected against unauthorized access and it
keeps the data and functions safe from malicious attacks.
6. Maintainability: The software is easy to change and update, and it is
well-documented, so that it can be understood and modified by other
developers.
7. Reusability: The software can be reused in other projects or
applications, and it is designed in a way that promotes code reuse.
8. Scalability: The software can handle an increasing workload and it
can be easily extended to meet the changing requirements.
9. Testability: The software is designed in a way that makes it easy to
test and validate, and it has a comprehensive test coverage.
By adhering to these characteristics, software engineers can develop
software that is functional, reliable, and maintainable, thus providing the
best experience to the end-users.

Coupling and Cohesion – Software

Engineering
The purpose of the Design phase in the Software Development Life Cycle
is to produce a solution to a problem given in the SRS(Software
Requirement Specification) document. The output of the design phase is a
Software Design Document (SDD).
Coupling and Cohesion are two key concepts in software engineering that
are used to measure the quality of a software system’s design.
What is Coupling and Cohesion?
Coupling refers to the degree of interdependence between
software modules. High coupling means that modules are closely
connected and changes in one module may affect other modules.
Low coupling means that modules are independent, and changes
in one module have little impact on other modules.
If you’re interested in learning how to implement coupling and
cohesion effectively in your projects, the System Design
Course delves deeper into these principles, helping you craft
more maintainable and scalable code structures.
 Coupling

Cohesion refers to the degree to which elements within a module

work together to fulfill a single, well-defined purpose. High
cohesion means that elements are closely related and focused on
a single purpose, while low cohesion means that elements are
loosely related and serve multiple purposes.
 Cohesion

Both coupling and cohesion are important factors in determining

the maintainability, scalability, and reliability of a software
system. High coupling and low cohesion can make a system
difficult to change and test, while low coupling and high cohesion
make a system easier to maintain and improve.
Basically, design is a two-part iterative process. The first part is
Conceptual Design which tells the customer what the system will
do. Second is Technical Design which allows the system builders
to understand the actual hardware and software needed to solve
a customer’s problem.

Conceptual design of the system:

 Written in simple language i.e. customer understandable
language.
 Detailed explanation about system characteristics.
 Describes the functionality of the system.
 It is independent of implementation.
 Linked with requirement document.
Technical Design of the System:
 Hardware component and design.
 Functionality and hierarchy of software components.
 Software architecture
 Network architecture
 Data structure and flow of data.
 I/O component of the system.
 Shows interface.
Modularization is the process of dividing a software system into
multiple independent modules where each module works
independently. There are many advantages of Modularization in
software engineering. Some of these are given below:
 Easy to understand the system.
 System maintenance is easy.
 A module can be used many times as their requirements. No
need to write it again and again.
Types of Coupling
Coupling is the measure of the degree of interdependence
between the modules. A good software will have low coupling.

Types of Coupling

Following are the types of Coupling:

 Data Coupling: If the dependency between the modules is
based on the fact that they communicate by passing only data,
then the modules are said to be data coupled. In data coupling,
the components are independent of each other and
communicate through data. Module communications don’t
contain tramp data. Example-customer billing system.
 Stamp Coupling In stamp coupling, the complete data
structure is passed from one module to another module.
Therefore, it involves tramp data. It may be necessary due to
efficiency factors- this choice was made by the insightful
designer, not a lazy programmer.
 Control Coupling: If the modules communicate by passing
control information, then they are said to be control coupled. It
can be bad if parameters indicate completely different behavior
and good if parameters allow factoring and reuse of
functionality. Example- sort function that takes comparison
function as an argument.
 External Coupling: In external coupling, the modules depend
on other modules, external to the software being developed or
 to a particular type of hardware. Ex- protocol, external file,
device format, etc.
 Common Coupling: The modules have shared data such as
global data structures. The changes in global data mean
tracing back to all modules which access that data to evaluate
the effect of the change. So it has got disadvantages like
difficulty in reusing modules, reduced ability to control data
accesses, and reduced maintainability.
 Content Coupling: In a content coupling, one module can
modify the data of another module, or control flow is passed
from one module to the other module. This is the worst form of
coupling and should be avoided.
 Temporal Coupling: Temporal coupling occurs when two
modules depend on the timing or order of events, such as one
module needing to execute before another. This type of
coupling can result in design issues and difficulties in testing
and maintenance.
 Sequential Coupling: Sequential coupling occurs when the
output of one module is used as the input of another module,
creating a chain or sequence of dependencies. This type of
coupling can be difficult to maintain and modify.
 Communicational Coupling: Communicational coupling
occurs when two or more modules share a common
communication mechanism, such as a shared message queue
or database. This type of coupling can lead to performance
issues and difficulty in debugging.
 Functional Coupling: Functional coupling occurs when two
modules depend on each other’s functionality, such as one
module calling a function from another module. This type of
coupling can result in tightly-coupled code that is difficult to
modify and maintain.
 Data-Structured Coupling: Data-structured coupling occurs
when two or more modules share a common data structure,
such as a database table or data file. This type of coupling can
lead to difficulty in maintaining the integrity of the data
structure and can result in performance issues.
 Interaction Coupling: Interaction coupling occurs due to the
methods of a class invoking methods of other classes. Like with
functions, the worst form of coupling here is if methods directly
access internal parts of other methods. Coupling is lowest if
methods communicate directly through parameters.
 Component Coupling: Component coupling refers to the
interaction between two classes where a class has variables of
the other class. Three clear situations exist as to how this can
 happen. A class C can be component coupled with another
class C1, if C has an instance variable of type C1, or C has a
method whose parameter is of type C1,or if C has a method
which has a local variable of type C1. It should be clear that
whenever there is component coupling, there is likely to be
interaction coupling.
Types of Cohesion
Cohesion is a measure of the degree to which the elements of the
module are functionally related. It is the degree to which all
elements directed towards performing a single task are contained
in the component. Basically, cohesion is the internal glue that
keeps the module together. A good software design will have high
cohesion.

Types of Cohesion

Following are the types of Cohesion:

 Functional Cohesion: Every essential element for a single
computation is contained in the component. A functional
cohesion performs the task and functions. It is an ideal
situation.
 Sequential Cohesion: An element outputs some data that
becomes the input for other element, i.e., data flow between
the parts. It occurs naturally in functional programming
languages.
 Communicational Cohesion: Two elements operate on the
same input data or contribute towards the same output data.
 Example- update record in the database and send it to the
printer.
 Procedural Cohesion: Elements of procedural cohesion
ensure the order of execution. Actions are still weakly
connected and unlikely to be reusable. Ex- calculate student
GPA, print student record, calculate cumulative GPA, print
cumulative GPA.
 Temporal Cohesion: The elements are related by their timing
involved. A module connected with temporal cohesion all the
tasks must be executed in the same time span. This cohesion
contains the code for initializing all the parts of the system.
Lots of different activities occur, all at unit time.
 Logical Cohesion: The elements are logically related and not
functionally. Ex- A component reads inputs from tape, disk, and
network. All the code for these functions is in the same
component. Operations are related, but the functions are
significantly different.
 Coincidental Cohesion: The elements are not
related(unrelated). The elements have no conceptual
relationship other than location in source code. It is accidental
and the worst form of cohesion. Ex- print next line and reverse
the characters of a string in a single component.
 Procedural Cohesion: This type of cohesion occurs when
elements or tasks are grouped together in a module based on
their sequence of execution, such as a module that performs a
set of related procedures in a specific order. Procedural
cohesion can be found in structured programming languages.
 Communicational Cohesion: Communicational cohesion
occurs when elements or tasks are grouped together in a
module based on their interactions with each other, such as a
module that handles all interactions with a specific external
system or module. This type of cohesion can be found in
object-oriented programming languages.
 Temporal Cohesion: Temporal cohesion occurs when
elements or tasks are grouped together in a module based on
their timing or frequency of execution, such as a module that
handles all periodic or scheduled tasks in a system. Temporal
cohesion is commonly used in real-time and embedded
systems.
 Informational Cohesion: Informational cohesion occurs when
elements or tasks are grouped together in a module based on
their relationship to a specific data structure or object, such as
a module that operates on a specific data type or object.
 Informational cohesion is commonly used in object-oriented
programming.
 Functional Cohesion: This type of cohesion occurs when all
elements or tasks in a module contribute to a single well-
defined function or purpose, and there is little or no coupling
between the elements. Functional cohesion is considered the
most desirable type of cohesion as it leads to more
maintainable and reusable code.
 Layer Cohesion: Layer cohesion occurs when elements or
tasks in a module are grouped together based on their level of
abstraction or responsibility, such as a module that handles
only low-level hardware interactions or a module that handles
only high-level business logic. Layer cohesion is commonly
used in large-scale software systems to organize code into
manageable layers.

Advantages of low coupling

 Improved maintainability: Low coupling reduces the impact of
changes in one module on other modules, making it easier to
modify or replace individual components without affecting the
entire system.
 Enhanced modularity: Low coupling allows modules to be
developed and tested in isolation, improving the modularity
and reusability of code.
 Better scalability: Low coupling facilitates the addition of new
modules and the removal of existing ones, making it easier to
scale the system as needed.
Advantages of high cohesion
 Improved readability and understandability: High cohesion
results in clear, focused modules with a single, well-defined
purpose, making it easier for developers to understand the
code and make changes.
 Better error isolation: High cohesion reduces the likelihood that
a change in one part of a module will affect other parts, making
it easier to
 Improved reliability: High cohesion leads to modules that are
less prone to errors and that function more consistently,
 leading to an overall improvement in the reliability of the
system.
Disadvantages of high coupling
 Increased complexity: High coupling increases the
interdependence between modules, making the system more
complex and difficult to understand.
 Reduced flexibility: High coupling makes it more difficult to
modify or replace individual components without affecting the
entire system.
 Decreased modularity: High coupling makes it more difficult to
develop and test modules in isolation, reducing the modularity
and reusability of code.
Disadvantages of low cohesion
 Increased code duplication: Low cohesion can lead to the
duplication of code, as elements that belong together are split
into separate modules.
 Reduced functionality: Low cohesion can result in modules that
lack a clear purpose and contain elements that don’t belong
together, reducing their functionality and making them harder
to maintain.
 Difficulty in understanding the module: Low cohesion can make
it harder for developers to understand the purpose and
behavior of a module, leading to errors and a lack of clarity.

Layered Technology in Software

Engineering:
Software engineering is a fully layered technology, to develop software we
need to go from one layer to another. All the layers are connected and
each layer demands the fulfillment of the previous layer.

Fig: The diagram shows the layers of software development

Just as software engineering requires progressing through interconnected

layers to build robust software, advancing your skills in software testing
also involves a step-by-step approach. To effectively move from basic
testing to more complex automation, consider exploring the Complete
Guide to Software Testing & Automation by GeeksforGeeks . This
course will help you build on each layer of your knowledge, ensuring you
master the intricacies of testing and automation to create reliable, high-
quality software.

Layered technology is divided into four parts:

1. A quality focus: It defines the continuous process improvement
principles of software. It provides integrity that means providing security to
the software so that data can be accessed by only an authorized person,
no outsider can access the data. It also focuses on maintainability and
usability.
2. Process: It is the foundation or base layer of software engineering. It is
key that binds all the layers together which enables the development of
software before the deadline or on time. Process defines a framework
that must be established for the effective delivery of software engineering
technology. The software process covers all the activities, actions, and
tasks required to be carried out for software development.

Process activities are listed below:-

 Communication: It is the first and foremost thing for the development
of software. Communication is necessary to know the actual demand of
the client.
 Planning: It basically means drawing a map for reduced the
complication of development.
 Modeling: In this process, a model is created according to the client
for better understanding.
 Construction: It includes the coding and testing of the problem.
 Deployment:- It includes the delivery of software to the client for
evaluation and feedback.
3. Method: During the process of software development the answers to all
“how-to-do” questions are given by method. It has the information of all
the tasks which includes communication, requirement analysis, design
modeling, program construction, testing, and support.
4. Tools: Software engineering tools provide a self-operating system for
processes and methods. Tools are integrated which means information
created by one tool can be used by another.
Function Oriented Design – Software
Engineering
The design process for software systems often has two levels. At the first
level, the focus is on deciding which modules are needed for the system
based on SRS (Software Requirement Specification) and how the
modules should be interconnected.
Function Oriented Design is an approach to software design where the
design is decomposed into a set of interacting units where each unit has a
clearly defined function.
Generic Procedure
Start with a high-level description of what the software/program does.
Refine each part of the description by specifying in greater detail the
functionality of each part. These points lead to a Top-Down Structure.

Problem in Top-Down Design Method

Mostly each module is used by at most one other module and that module
is called its Parent module.
Solution to the Problem
Designing of reusable module. It means modules use several modules to
do their required functions.
Function Oriented Design Strategies:

Function Oriented Design Strategies are as follows:

1. Data Flow Diagram (DFD): A data flow diagram (DFD) maps out the
flow of information for any process or system. It uses defined symbols
like rectangles, circles and arrows, plus short text labels, to show data
inputs, outputs, storage points and the routes between each
destination.
2. Data Dictionaries: Data dictionaries are simply repositories to store
information about all data items defined in DFDs. At the requirement
stage, data dictionaries contains data items. Data dictionaries include
Name of the item, Aliases (Other names for items), Description /
purpose, Related data items, Range of values, Data structure definition
/ form.
3. Structure Charts: Structure chart is the hierarchical representation of
system which partitions the system into black boxes (functionality is
known to users, but inner details are unknown). Components are read
from top to bottom and left to right. When a module calls another, it
views the called module as a black box, passing required parameters
and receiving results.
4. Pseudo Code: Pseudo Code is system description in short English like
phrases describing the function. It uses keyword and indentation.
Pseudocodes are used as replacement for flow charts. It decreases the
amount of documentation required.

Structure Charts in Function Oriented Design

For a function-oriented design, the design can be represented graphically
by structure charts. The structure of a program is made up of the modules
of that program together with the modules of that program together with
the interconnections between modules. The structure chart of a program
is a graphic representation of its structure.
1. In a structure chart a module is represented by a box with the module
name written in the box.
2. In general, procedural information is not represented in a structure
chart, and the focus is on representing the hierarchy of modules.
3. However, there are situations where the designer may wish to
communicate certain procedural information explicitly, like major loop
and decisions.
4. Such information can also be represented in a structure chart.
5. Modules in a system can be categorized into few classes as below:
6. Input module: There are some modules that obtain information from
their subordinates and then pass it to their superordinate.
7. Output module: Module which take information from their superordinate
and pass it on to its subordinates.
8. Transform module: Modules that exist solely for the sake of
transforming data into some other form.
9. Coordinate module: Modules whose primary concern is managing the
flow of data to and from different subordinates.
10. A structure chart is a nice representation for a design that uses
functional abstraction.

Structured Analysis
Structured Analysis is a development method that allows the analyst to
understand the system and its activities in a logical way.

It is a systematic approach, which uses graphical tools that analyze and

refine the objectives of an existing system and develop a new system
specification which can be easily understandable by user.

It has following attributes −

 It is graphic which specifies the presentation of application.

 It divides the processes so that it gives a clear picture of system flow.
 It is logical rather than physical i.e., the elements of system do not
depend on vendor or hardware.
 It is an approach that works from high-level overviews to lower-level
details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system
development. They are −

 Data Flow Diagrams

  Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudocode

Explore our latest online courses and learn new skills at your own pace.
Enroll and become a certified expert to boost your career.

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements

of system in a graphical form.

 It shows the flow of data between various functions of system and

specifies how the current system is implemented.
 It is an initial stage of design phase that functionally divides the
requirement specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user
and analyst or analyst and system designer.
 It 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.

Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not
clear and the user wants a notational language for communication. However,
it requires a large number of iterations for obtaining the most accurate and
complete solution.
The following table shows the symbols used in designing a DFD and their
significance −

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Types of DFD
DFDs are of two types: Physical DFD and Logical DFD. The following table lists
the points that differentiate a physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation dependent. It shows which It is implementation independent. It focuses only on

functions are performed. the flow of data between processes.

It provides low level details of hardware, software, It explains events of systems and data required by
files, and people. each event.

It depicts how the current system operates and It shows how business operates; not how the system
how a system will be implemented. can be implemented.

Context Diagram
A context diagram helps in understanding the entire system by one DFD
which gives the overview of a system. It starts with mentioning major
processes with little details and then goes onto giving more details of the
processes with the top-down approach.

The context diagram of mess management is shown below.

Data Dictionary

A data dictionary is a structured repository of data elements in the system. It

stores the descriptions of all DFD data elements that is, details and
definitions of data flows, data stores, data stored in data stores, and the
processes.

A data dictionary improves the communication between the analyst and the
user. It plays an important role in building a database. Most DBMSs have a
data dictionary as a standard feature. For example, refer the following table
−

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees

Decision trees are a method for defining complex relationships by describing

decisions and avoiding the problems in communication. A decision tree is a
diagram that shows alternative actions and conditions within horizontal tree
framework. Thus, it depicts which conditions to consider first, second, and so
on.

Decision trees depict the relationship of each condition and their permissible
actions. A square node indicates an action and a circle indicates a condition.
It forces analysts to consider the sequence of decisions and identifies the
actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format
to describe what other combinations of conditions you can take for testing. It
is a single representation of the relationships between conditions and actions.

For example, refer the following decision tree −

Decision Tables

Decision tables are a method of describing the complex logical relationship in

a precise manner which is easily understandable.

 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.

The entries in decision table are given by Decision Rules which define the
relationships between combinations of conditions and courses of action. In
rules section,

 Y shows the existence of a condition.

 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.

For example, refer the following table −

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

Purchase amount = Rs
- Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -
Give no discount - - X X

Structured English

Structure English is derived from structured programming language which

gives more understandable and precise description of process. It is based on
procedural logic that uses construction and imperative sentences designed to
perform operation for action.

 It is best used when sequences and loops in a program must be

considered and the problem needs sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of
sequential decision structures and iterations.

For example, see the following sequence of actions −

if customer pays advance

then
Give 5% Discount
else
if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if

Pseudocode

A pseudocode does not conform to any programming language and

expresses logic in plain English.

 It may specify the physical programming logic without actual coding

during and after the physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that
would suit your requirements −

 Use DFD at high or low level analysis for providing good system
documentations.
 Use data dictionary to simplify the structure for meeting the data
requirement of the system.
  Use structured English if there are many loops and actions are
complex.
 Use decision tables when there are a large number of conditions to
check and logic is complex.
 Use decision trees when sequencing of conditions is important and if
there are few conditions to be tested.

Structured Analysis and Structured Design

(SA/SD)

Structured Analysis and Structured Design (SA/SD) is a diagrammatic

notation that is designed to help people understand the system. The basic
goal of SA/SD is to improve quality and reduce the risk of system failure. It
establishes concrete management specifications and documentation. It
focuses on the solidity, pliability, and maintainability of the system.
Structured Analysis and Structured Design (SA/SD) is a software
development method that was popular in the 1970s and 1980s. The
method is based on the principle of structured programming, which
emphasizes the importance of breaking down a software system into
smaller, more manageable components.
In SA/SD, the software development process is divided into two phases:
Structured Analysis and Structured Design. During the Structured
Analysis phase, the problem to be solved is analyzed and the
requirements are gathered. The Structured Design phase involves
designing the system to meet the requirements that were gathered in the
Structured Analysis phase.
Structured Analysis and Structured Design (SA/SD) is a traditional
software development methodology that was popular in the 1980s and
1990s. It involves a series of techniques for designing and developing
software systems in a structured and systematic way. Here are some key
concepts of SA/SD:
1. Functional Decomposition: SA/SD uses functional decomposition to
break down a complex system into smaller, more manageable
subsystems. This technique involves identifying the main functions of
the system and breaking them down into smaller functions that can be
implemented independently.
2. Data Flow Diagrams (DFDs): SA/SD uses DFDs to model the flow of
data through the system. DFDs are graphical representations of the
system that show how data moves between the system’s various
components.
3. Data Dictionary: A data dictionary is a central repository that contains
descriptions of all the data elements used in the system. It provides a
 clear and consistent definition of data elements, making it easier to
understand how the system works.
4. Structured Design: SA/SD uses structured design techniques to
develop the system’s architecture and components. It involves
identifying the major components of the system, designing the
interfaces between them, and specifying the data structures and
algorithms that will be used to implement the system.
5. Modular Programming: SA/SD uses modular programming techniques
to break down the system’s code into smaller, more manageable
modules. This makes it easier to develop, test, and maintain the
system.
Some advantages of SA/SD include its emphasis on structured design
and documentation, which can help improve the clarity and maintainability
of the system. However, SA/SD has some disadvantages, including its
rigidity and inflexibility, which can make it difficult to adapt to changing
business requirements or technological trends. Additionally, SA/SD may
not be well-suited for complex, dynamic systems, which may require more
agile development methodologies.
Structured analysis and design techniques are essential for developing
software that meets user requirements. Understanding these
methodologies can greatly enhance your system design
capabilities. Explore this System design course for comprehensive
insights into structured analysis and design.
The following are the steps involved in the SA/SD process:
1. Requirements gathering: The first step in the SA/SD process is to
gather requirements from stakeholders, including users, customers,
and business partners.
2. Structured Analysis: During the Structured Analysis phase, the
requirements are analyzed to identify the major components of the
system, the relationships between those components, and the data
flows within the system.
3. Data Modeling: During this phase, a data model is created to represent
the data used in the system and the relationships between data
elements.
4. Process Modeling: During this phase, the processes within the system
are modeled using flowcharts and data flow diagrams.
5. Input/Output Design: During this phase, the inputs and outputs of the
system are designed, including the user interface and reports.
6. Structured Design: During the Structured Design phase, the system is
designed to meet the requirements gathered in the Structured Analysis
phase. This may include selecting appropriate hardware and software
platforms, designing databases, and defining data structures.
7. Implementation and Testing: Once the design is complete, the system
is implemented and tested.
SA/SD has been largely replaced by more modern software development
methodologies, but its principles of structured analysis and design
continue to influence current software development practices. The method
is known for its focus on breaking down complex systems into smaller
components, which makes it easier to understand and manage the system
as a whole.
Basically, the approach of SA/SD is based on the Data Flow Diagram. It
is easy to understand SA/SD but it focuses on well-defined system
boundary whereas the JSD approach is too complex and does not have
any graphical representation.
SA/SD is combined known as SAD and it mainly focuses on the following
3 points:
1. System
2. Process
3. Technology
SA/SD involves 2 phases:
1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State
Transition diagram and ER diagram.
2. Design Phase: It uses Structure Chart and Pseudo Code.

1. Analysis Phase:
Analysis Phase involves data flow diagram, data dictionary, state
transition diagram, and entity-relationship diagram.
1. Data Flow Diagram:
In the data flow diagram, the model describes how the data flows
through the system. We can incorporate the Boolean operators and &
or link data flow when more than one data flow may be input or output
from a process.
For example, if we have to choose between two paths of a process we
can add an operator or and if two data flows are necessary for a
process we can add an operator. The input of the process “check-
order” needs the credit information and order information whereas the
output of the process would be a cash-order or a good-credit-order.

2. Data Dictionary:
The content that is not described in the DFD is described in the data
dictionary. It defines the data store and relevant meaning. A physical
data dictionary for data elements that flow between processes,
between entities, and between processes and entities may be included.
This would also include descriptions of data elements that flow external
to the data stores.
A logical data dictionary may also be included for each such data
element. All system names, whether they are names of entities, types,
 relations, attributes, or services, should be entered in the dictionary.

3. State Transition Diagram:

State transition diagram is similar to the dynamic model. It specifies
how much time the function will take to execute and data access
triggered by events. It also describes all of the states that an object can
have, the events under which an object changes state, the conditions
that must be fulfilled before the transition will occur and the activities
were undertaken during the life of an object.

4. ER Diagram:
ER diagram specifies the relationship between data store. It is basically
used in database design. It basically describes the relationship
between different entities.
2. Design Phase:
Design Phase involves structure chart and pseudocode.
1. Structure Chart:
It is created by the data flow diagram. Structure Chart specifies how
DFS’s processes are grouped into tasks and allocated to the CPU. The
structured chart does not show the working and internal structure of the
processes or modules and does not show the relationship between
data or data flows. Similar to other SASD tools, it is time and cost-
independent and there is no error-checking technique associated with
this tool. The modules of a structured chart are arranged arbitrarily and
any process from a DFD can be chosen as the central transform
depending on the analysts’ own perception. The structured chart is
difficult to amend, verify, maintain, and check for completeness and
consistency.
2. Pseudo Code: It is the actual implementation of the system. It is an
informal way of programming that doesn’t require any specific
programming language or technology.
Advantages of Structured Analysis and Structured Design
(SA/SD):
1. Clarity and Simplicity: The SA/SD method emphasizes breaking down
complex systems into smaller, more manageable components, which
makes the system easier to understand and manage.
2. Better Communication: The SA/SD method provides a common
language and framework for communicating the design of a system,
which can improve communication between stakeholders and help
ensure that the system meets their needs and expectations.
3. Improved maintainability: The SA/SD method provides a clear,
organized structure for a system, which can make it easier to maintain
and update the system over time.
4. Better Testability: The SA/SD method provides a clear definition of the
inputs and outputs of a system, which makes it easier to test the
system and ensure that it meets its requirements.
Disadvantages of Structured Analysis and Structured Design
(SA/SD):
1. Time-Consuming: The SA/SD method can be time-consuming,
especially for large and complex systems, as it requires a significant
amount of documentation and analysis.
2. Inflexibility: Once a system has been designed using the SA/SD
method, it can be difficult to make changes to the design, as the
process is highly structured and documentation-intensive.
3. Limited Iteration: The SA/SD method is not well-suited for iterative
development, as it is designed to be completed in a single pass.

Structured Analysis and Structured Design (SA/SD) is a diagrammatic

notation that is designed to help people understand the system. The basic
goal of SA/SD is to improve quality and reduce the risk of system failure. It
establishes concrete management specifications and documentation. It
focuses on the solidity, pliability, and maintainability of the system.
Structured Analysis and Structured Design (SA/SD) is a software
development method that was popular in the 1970s and 1980s. The
method is based on the principle of structured programming, which
emphasizes the importance of breaking down a software system into
smaller, more manageable components.
In SA/SD, the software development process is divided into two phases:
Structured Analysis and Structured Design. During the Structured
Analysis phase, the problem to be solved is analyzed and the
requirements are gathered. The Structured Design phase involves
designing the system to meet the requirements that were gathered in the
Structured Analysis phase.
Structured Analysis and Structured Design (SA/SD) is a traditional
software development methodology that was popular in the 1980s and
1990s. It involves a series of techniques for designing and developing
software systems in a structured and systematic way. Here are some key
concepts of SA/SD:
1. Functional Decomposition: SA/SD uses functional decomposition to
break down a complex system into smaller, more manageable
subsystems. This technique involves identifying the main functions of
the system and breaking them down into smaller functions that can be
implemented independently.
2. Data Flow Diagrams (DFDs): SA/SD uses DFDs to model the flow of
data through the system. DFDs are graphical representations of the
 system that show how data moves between the system’s various
components.
3. Data Dictionary: A data dictionary is a central repository that contains
descriptions of all the data elements used in the system. It provides a
clear and consistent definition of data elements, making it easier to
understand how the system works.
4. Structured Design: SA/SD uses structured design techniques to
develop the system’s architecture and components. It involves
identifying the major components of the system, designing the
interfaces between them, and specifying the data structures and
algorithms that will be used to implement the system.
5. Modular Programming: SA/SD uses modular programming techniques
to break down the system’s code into smaller, more manageable
modules. This makes it easier to develop, test, and maintain the
system.

Some advantages of SA/SD include its emphasis on structured design

and documentation, which can help improve the clarity and maintainability
of the system. However, SA/SD has some disadvantages, including its
rigidity and inflexibility, which can make it difficult to adapt to changing
business requirements or technological trends. Additionally, SA/SD may
not be well-suited for complex, dynamic systems, which may require more
agile development methodologies.
Structured analysis and design techniques are essential for developing
software that meets user requirements. Understanding these
methodologies can greatly enhance your system design
capabilities. Explore this System design course for comprehensive
insights into structured analysis and design.

The following are the steps involved in the SA/SD process:

1. Requirements gathering: The first step in the SA/SD process is to
gather requirements from stakeholders, including users, customers,
and business partners.
2. Structured Analysis: During the Structured Analysis phase, the
requirements are analyzed to identify the major components of the
system, the relationships between those components, and the data
flows within the system.
3. Data Modeling: During this phase, a data model is created to represent
the data used in the system and the relationships between data
elements.
4. Process Modeling: During this phase, the processes within the system
are modeled using flowcharts and data flow diagrams.
5. Input/Output Design: During this phase, the inputs and outputs of the
system are designed, including the user interface and reports.
6. Structured Design: During the Structured Design phase, the system is
designed to meet the requirements gathered in the Structured Analysis
phase. This may include selecting appropriate hardware and software
platforms, designing databases, and defining data structures.
7. Implementation and Testing: Once the design is complete, the system
is implemented and tested.

SA/SD has been largely replaced by more modern software development

methodologies, but its principles of structured analysis and design
continue to influence current software development practices. The method
is known for its focus on breaking down complex systems into smaller
components, which makes it easier to understand and manage the system
as a whole.
Basically, the approach of SA/SD is based on the Data Flow Diagram. It
is easy to understand SA/SD but it focuses on well-defined system
boundary whereas the JSD approach is too complex and does not have
any graphical representation.

SA/SD is combined known as SAD and it mainly focuses on the following

3 points:
1. System
2. Process
3. Technology

SA/SD involves 2 phases:

1. Analysis Phase: It uses Data Flow Diagram, Data Dictionary, State
Transition diagram and ER diagram.
2. Design Phase: It uses Structure Chart and Pseudo Code.

1. Analysis Phase:
Analysis Phase involves data flow diagram, data dictionary, state
transition diagram, and entity-relationship diagram.
1. Data Flow Diagram:
In the data flow diagram, the model describes how the data flows
through the system. We can incorporate the Boolean operators and &
or link data flow when more than one data flow may be input or output
from a process.
For example, if we have to choose between two paths of a process we
can add an operator or and if two data flows are necessary for a
process we can add an operator. The input of the process “check-
order” needs the credit information and order information whereas the
output of the process would be a cash-order or a good-credit-order.

2. Data Dictionary:
 The content that is not described in the DFD is described in the data
dictionary. It defines the data store and relevant meaning. A physical
data dictionary for data elements that flow between processes,
between entities, and between processes and entities may be included.
This would also include descriptions of data elements that flow external
to the data stores.

A logical data dictionary may also be included for each such data
element. All system names, whether they are names of entities, types,
relations, attributes, or services, should be entered in the dictionary.

3. State Transition Diagram:

State transition diagram is similar to the dynamic model. It specifies
how much time the function will take to execute and data access
triggered by events. It also describes all of the states that an object can
have, the events under which an object changes state, the conditions
that must be fulfilled before the transition will occur and the activities
were undertaken during the life of an object.

4. ER Diagram:

ER diagram specifies the relationship between data store. It is basically

used in database design. It basically describes the relationship
between different entities.

DETAILED Design Phase:

Design Phase involves structure chart and pseudocode.

1. Structure Chart:
It is created by the data flow diagram. Structure Chart specifies how
DFS’s processes are grouped into tasks and allocated to the CPU. The
structured chart does not show the working and internal structure of the
processes or modules and does not show the relationship between
data or data flows. Similar to other SASD tools, it is time and cost-
independent and there is no error-checking technique associated with
this tool. The modules of a structured chart are arranged arbitrarily and
any process from a DFD can be chosen as the central transform
depending on the analysts’ own perception. The structured chart is
 difficult to amend, verify, maintain, and check for completeness and
consistency.
2. Pseudo Code: It is the actual implementation of the system. It is an
informal way of programming that doesn’t require any specific
programming language or technology.

Advantages of Structured Analysis and Structured Design

(SA/SD):
1. Clarity and Simplicity: The SA/SD method emphasizes breaking down
complex systems into smaller, more manageable components, which
makes the system easier to understand and manage.
2. Better Communication: The SA/SD method provides a common
language and framework for communicating the design of a system,
which can improve communication between stakeholders and help
ensure that the system meets their needs and expectations.
3. Improved maintainability: The SA/SD method provides a clear,
organized structure for a system, which can make it easier to maintain
and update the system over time.
4. Better Testability: The SA/SD method provides a clear definition of the
inputs and outputs of a system, which makes it easier to test the
system and ensure that it meets its requirements.

Disadvantages of Structured Analysis and Structured Design

(SA/SD):
1. Time-Consuming: The SA/SD method can be time-consuming,
especially for large and complex systems, as it requires a significant
amount of documentation and analysis.
2. Inflexibility: Once a system has been designed using the SA/SD
method, it can be difficult to make changes to the design, as the
process is highly structured and documentation-intensive.
3. Limited Iteration: The SA/SD method is not well-suited for iterative
development, as it is designed to be completed in a single pass.