Unit 3: Requirement Analysis, Modelling and Design Principles

Requirements Engineering, Establishing the groundwork –

identifying stakeholders, recognizing multiple viewpoints,
Requirements Analysis-Overall Objectives and Philosophy, Analysis
rules of thumb, Domain analysis, Requirement Modelling
approaches, Scenario based modelling, Analysis Modelling -
Data-flow diagram; Design Concepts and Principles, Object oriented
design, Function oriented design, Interface design and Procedural
design.
Requirement Analysis
Requirements Analysis: The process of discovering stakeholder needs and
requirements for a system or software application.

Goals:

● Capture Stakeholder Needs: Identify what customers, users, and

other stakeholders need.
● Interpret and Represent Needs: Accurately capture, interpret, and
represent these needs.
● Transform into Requirements: Convert these needs into a set of
product requirements.
Characteristics of Well-Formed Requirements:

● Needed: Address actual needs.

● Unambiguous: Clear and precise.
● Complete: Cover all aspects of the need.
● Consistent: No contradictions among requirements.
● Correct: Reflect the true needs and constraints.
● Feasible: Practical and achievable.
● Verifiable: Can be tested or validated.

Validation: Ensure the requirements represent the intent of the original

needs and accurately reflect stakeholder expectations.
Requirements Analysis Process

1. Identifying Key Stakeholders and End-Users

2. Capturing Requirements
3. Categorizing Requirements
4. Interpreting and Recording Requirements
5. Sign Off
Identifying Key Stakeholders and End-Users

1. Key Stakeholders:
○ Major decision-makers
○ Project sponsors
○ Have final say on project decisions
2. End-Users:
○ Actual users of the product
○ Provide crucial feedback
○ Their needs impact project success
Capturing Requirements :The next step is capturing the requirements of the
project from the stakeholders and end-users.

● One-on-One Interviews:

Gather individual requirements from stakeholders and end-users.

● Group Interviews:

Understand collective requirements and prevent conflicts of interest.

● Use Cases:

Get a walkthrough of the product from the end-users' perspective.

● Prototypes:

Provide a sample of the final product for feedback from end-users and
stakeholders.
Categorizing Requirements: The requirements are of various types and it
is wise to categorize them accordingly to avoid any confusion.

1. Functional Requirements:
2. Non-Functional Requirements:
1. Functional Requirements:
○ Definition: Specify what the system should do; the actions or functions it must
perform.
○ Examples:
■ Login System: The system must allow users to log in with a username and
password.
■ Data Entry: Users must be able to enter and save customer information.
2. Non-Functional Requirements:
○ Definition: Specify how the system performs its functions; related to quality
attributes and constraints.
○ Examples:
■ Performance: The system should handle 500 transactions per second.
■ Security: The system must encrypt all sensitive data to protect user privacy.
■ Usability: The system interface should be user-friendly and require no more
than 3 clicks to complete a task.
Interpreting and Recording Requirements

1. Defining Requirements Precisely:Ensure requirements are clearly described,

detailed, and aligned with business objectives.
○ Document requirements with enough detail to avoid ambiguity and ensure they
meet business needs.
2. Prioritizing the Requirements:Rank requirements based on their importance and
impact.
○ Create a prioritized list to focus on the most critical requirements first.
3. Carrying Out an Impact Analysis: Analyze the effects of each requirement on the
project and other requirements.
○ Predict potential consequences and assess how changes may affect the system.
4. Resolving Conflicts:Address any conflicting requirements among stakeholders.
○ Organize meetings to discuss and resolve discrepancies to ensure a unified
approach.
Sign Off
The last step is getting signatures from your key stakeholders on the final decisions that

you have made on the project requirements.

 Requirement Modelling approaches
Requirement modeling is a crucial phase in software
engineering that involves defining and analyzing the
requirements of a system to ensure that it meets the needs
of stakeholders. Several approaches and techniques are
used in requirement modeling to capture, specify, and
validate requirements.
1. Structured Analysis
Structured Analysis is a traditional approach that emphasizes
breaking down complex systems into smaller, manageable
components. Key techniques include:
● Data Flow Diagrams (DFDs): Represent the flow of data
within a system and how it is processed. They include
processes, data stores, data flow, and external entities.
● Entity-Relationship Diagrams (ERDs): Illustrate the
data entities, relationships, and attributes within the
system.
DFD
Data Flow Diagrams (DFDs) are a structured analysis technique used in software engineering to represent
the flow of data within a system. They provide a visual depiction of how data moves through a system, the
processes that transform the data, and how the data is stored and managed. DFDs help in understanding and
documenting the system’s functionality and interactions.
Components of DFDs

1. Processes:
○ Definition: Represent actions or transformations that process data.
○ Symbol: Usually depicted as circles or rounded rectangles.
○ Purpose: To show how inputs are converted into outputs.
2. Data Flows:
○ Definition: Indicate the movement of data between processes, data stores, and external entities.
○ Symbol: Arrows are used to show the direction of data flow.
○ Purpose: To illustrate how data is transferred and manipulated within the system.
3. Data Stores:
○ Definition: Represent repositories where data is stored within the system.
○ Symbol: Typically shown as open-ended rectangles or parallel lines.
○ Purpose: To depict where data is held for later retrieval and use.
4. External Entities:
○ Definition: Represent sources or destinations of data outside the system.
○ Symbol: Usually depicted as rectangles.
○ Purpose: To show interactions between the system and external actors (e.g., users, other
systems).
Levels of DFDs

1. Context Diagram (Level 0 DFD):

○ Description: Provides a high-level view of the system, showing the system as a
single process with its interactions with external entities.
○ Purpose: To give an overview of the system's boundaries and external
interfaces.
2. Level 1 DFD:
○ Description: Breaks down the main process from the context diagram into
sub-processes, detailing how data flows between these processes and data
stores.
○ Purpose: To show a more detailed view of the system’s major processes and
data interactions.
3. Level 2 DFD (and beyond):
○ Description: Further decomposes processes from Level 1 into more granular
processes, illustrating detailed data flows and interactions.
○ Purpose: To provide a comprehensive view of complex processes and their
interactions.
Creating a DFD

1. Identify the System Boundaries:

○ Determine what parts of the system will be included in the DFD and identify the external entities
that interact with it.
2. Define Processes:
○ Identify the major processes that transform data within the system. Each process should have a
clear, descriptive name.
3. Identify Data Flows:
○ Determine how data moves between processes, data stores, and external entities. Use arrows
to show the direction of data flow.
4. Define Data Stores:
○ Identify where data is stored within the system and how it is accessed by various processes.
5. Draw the Diagram:
○ Create the DFD using standard symbols and ensure that all components are clearly labeled and
interconnected.
ER Diagram
An Entity-Relationship (ER) Diagram is a graphical representation of entities and their
relationships in a database system. It’s a useful tool for designing and understanding the
data requirements of a system. For an Online Shopping System, an ER diagram helps to
map out how data entities like customers, orders, products, and inventory are related.

Key Components of ER Diagrams

1. Entities: Objects or concepts that can have data stored about them (e.g., Customer,
Product, Order).
2. Attributes: Properties or details of an entity (e.g., Customer Name, Product Price).
3. Relationships: Connections between entities that define how they interact with
each other (e.g., Customer places Order).
4. Primary Keys: Unique identifiers for entities (e.g., Customer ID, Product ID).
5. Foreign Keys: Attributes that create a link between entities (e.g., Product ID in
Order to reference Product).
2. Object-Oriented Analysis
Object-Oriented Analysis (OOA) focuses on modeling the
system based on objects, which are instances of classes that
encapsulate both data and behavior.
● Class Diagrams: Show the classes, attributes, methods,
and relationships among classes.
● Use Case Diagrams: Illustrate how users (actors) interact
with the system and the various use cases.
Online Shopping System Class Diagram
Use case Diagram

A use case is a methodology used in system analysis to identify, clarify and organize system
requirements. The use case is made up of a set of possible sequences of interactions
between systems and users in a particular environment and related to a particular goal.

use case contains three essential elements:

● The actor. The system user -- this can be a single person or a group of people

interacting with the process.

● The goal. The final successful outcome that completes the process.

● The system. The process and steps taken to reach the end goal, including the

necessary functional requirements and their anticipated behaviors.

3. Unified Modeling Language (UML)
Unified Modeling Language (UML) is a standardized modeling
language used to specify, visualize, and document the artifacts of a
software system. UML includes various diagram types:
● Use Case Diagrams: Capture functional requirements from a
user’s perspective.
● Class Diagrams: Detail the structure of the system and its
classes.
● Sequence Diagrams: Model the interactions between objects
over time.
● Activity Diagrams: Represent workflows and the sequence of
activities.
Sequence Diagram - Online Shopping
Activity Diagram- Online
Activity Diagram - Online Shopping
4. Agile Requirement Modeling
In Agile methodologies, requirements are modeled in a more
iterative and incremental fashion. Includes:
● User Stories: Short, simple descriptions of a feature from
the end-user’s perspective. They are often written on index
cards or digital tools.
● Storyboards: Visual representations of user interactions
with the system, often used in conjunction with user
stories.
● Product Backlogs: A prioritized list of user stories and
requirements that evolves over time.
The requirements modeling action results in one or more of the following types of
models: Requirements Engineering
● Scenario-based models of requirements from the point of view of various
system “actors”
● Data models that depict the information domain for the problem
● Class-oriented models that represent object-oriented classes (attributes and
operations) and the manner in which classes collaborate to achieve system
requirements
● Flow-oriented models that represent the functional elements of the system
and how they transform data as it moves through the system
● Behavioral models that depict how the software behaves as a consequence of
external “events”
Overall Objectives and Philosophy
The requirements model must achieve three primary objectives:

1. Describe customer needs: Clearly explain what the customer wants from
the system.
2. Guide software design: Provide a solid foundation to create the software's
design.
3. Ensure requirements can be tested: Define requirements in a way that
allows for testing after the software is built.

The analysis model helps connect the overall system description (which includes
software, hardware, data, and people) to the software design. It shows how the
system functions at a high level and leads to a detailed design, including the
software architecture, user interface, and components.
 Analysis rules of thumb
Arlow and Neustadt suggest a number of worthwhile rules of thumb that should be
followed when creating the analysis model:
The model should focus on requirements that are visible within the problem or
business domain
Focus on key requirements: Concentrate on the main requirements of the
problem or business domain, and avoid getting stuck in details about how the
system will work.
Enhance understanding: Every part of the model should help in understanding
the system’s information, function, and behavior.
Postpone technical details: Don’t worry about infrastructure (like
databases) or technical details until the design phase.
Reduce dependencies: Avoid making too many connections between
classes and functions. If everything is too interconnected, simplify
the relationships.
Benefit all stakeholders: Ensure the model is useful for everyone
involved—business people, designers, and testers should all find
value in it.
Keep it simple: Use the simplest form of modeling. Don’t add extra
diagrams or complex symbols if they don’t add new information.
Domain Analysis
 Approach Focus Key Tools

Scenario-Based User interactions and Use Case Diagrams, Activity

goals Diagrams

Class-Based System objects and Class Diagrams

their relationships

Flow-Oriented Data flow and Data Flow Diagrams (DFDs),

transformations Flowcharts

Behavioral System reactions to Sequence Diagrams

external events

Data Modeling Structure and Entity-Relationship Diagrams

relationships of data (ERDs)

Object-Oriented Objects, their attributes, Unified Modeling Language

and behavior (UML) Diagrams
Firesmith describes domain analysis in the following way:
Software domain analysis involves finding, analyzing, and
defining common requirements within a specific application area.
These requirements are identified to be reused across multiple
projects in that domain.
Object-oriented domain analysis focuses on identifying
reusable components, such as objects, classes, and frameworks, in
a specific domain.
Domain analysis helps in identifying parts of the system that
can be used again, saving time and effort in future projects
within the same domain.
Software design
Software design is a process of planning and converting
software requirements into actionable steps to build a
software system. It involves applying certain principles to
organize and structure the components of the design. These
principles directly influence how the software functions and
its overall development process from the very start, helping
ensure that the software is both effective and efficient.
Principles Of Software Design :
1.No “Tunnel Vision”
Don't focus only on finishing the task but think about the broader
impact.
Example: If you’re designing an online shopping app, don’t just
focus on making the purchase button work. Also, think about user
experience, security, and future features like adding discounts.
2.Traceable to Analysis Model
The design should match what was decided in the requirement
analysis.
Example: If the analysis says the system needs a login page with
two-factor authentication, the design must include this feature.
3.Don’t “Reinvent the Wheel”
Use existing solutions instead of creating new ones
unnecessarily.
Example: If there’s already a well-tested library for handling
payments, use it instead of coding your own payment system.
4.Minimize Intellectual Distance
The design should closely relate to the real-world problem.
Example: If the problem is booking a flight, the design should
reflect the steps a real person would take, like choosing a date,
destination, and seat.
5.Uniformity and Integration
The design should be consistent, and all parts should work
together smoothly.
Example: If your app uses blue buttons for actions, don’t
suddenly switch to green buttons. All features (like booking and
cancelling) should work seamlessly together.
6.Accommodate Change
The design should allow easy changes when needed.
Example: If users want a dark mode option, the design should be
flexible enough to add this feature without major rewrites.
7.Degrade Gently
The software should handle errors gracefully without crashing.
Example: If a webpage fails to load, show a friendly error message
instead of a blank screen.
8.Assess Quality
The design should be checked for quality to ensure it meets
standards.
Example: Before finalizing a design, check if it’s easy to use, fast,
and meets all security requirements.
9.Review to Find Errors
Regular reviews should be done to catch mistakes.
Example: Before moving to coding, check the design with a team to
see if there are any flaws or missing pieces.
10.Design vs Coding
Designing is about planning how the software will work; coding is
writing the actual program.
Example: Before coding a calculator, design how the user will
interact with it, what buttons it will have, and how calculations will
be done. Then write the code based on that design.
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.
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.
1. Content Coupling (High Coupling)

One module directly modifies or relies on the internal details of

another module.

Example: If a module directly changes the variables or behavior inside

another module. This is the highest and most undesirable type of
coupling because any change in one module can break the other.

2. Common Coupling

Multiple modules share the same global data.

Example: If several modules access and modify the same global

variable, like a shared configuration setting. Changes to the shared
data can create bugs across all the modules that use it.
3. External Coupling

Modules are dependent on external factors such as hardware, protocols, or

shared external resources.

Example: If two modules both depend on an external file or database

structure. If the external resource changes, both modules may need
updating.

4. Control Coupling
One module controls the behavior of another by passing control
information.

Example: If one module sends a flag or condition to another module to

decide what action to take (e.g., a function passes a mode parameter that
tells the other module how to behave). This reduces independence between
the modules.
5. Stamp Coupling (Data-Structured Coupling)

● Definition: One module passes a complex data structure (like an

object) to another module, and the receiving module only uses part of
it.
● Example: A function receives an entire user profile object when it
only needs the user’s name. This means the two modules are
unnecessarily connected through the entire data structure.

6. Data Coupling

● Definition: Modules communicate by passing only the necessary

data.
● Example: If one module sends only the relevant data (like a user ID)
to another module. This is considered good because the modules
share only what’s needed, reducing dependency.
7. Message Coupling (Low Coupling)

● Definition: Modules communicate by passing messages, and the

messages contain no information about the internal workings of the
other module.
● Example: Two modules communicate through an API or message
queue without knowing how the other works internally. This is one
of the best types of coupling because it maximizes independence.

8. No Coupling (Ideal)

● Definition: Modules are completely independent and do not interact

at all.
● Example: Two modules that perform entirely unrelated tasks and do
not rely on each other in any way.
Cohesion refers to how closely the elements within a single module
(or class) in a program are related to each other. Higher cohesion is
generally better because it means the module focuses on a specific
task, making it easier to maintain, understand, and reuse.
1. Functional Cohesion

● Definition: Every part of the module works together to achieve a

single, specific task.
● Example: In a shopping app, a function that calculates the total price
of items in the cart. The only focus here is to compute the total, so
everything in this module is related to that task.

2. Sequential Cohesion

● Definition: The output of one part of the module becomes the input
for another part, like a chain of operations.
● Example: A process that first checks if a user’s input is valid, and
then saves the data to the database. The two steps are connected: first
validation, then saving.
3. Communicational Cohesion

● Definition: All parts of the module operate on the same data.

● Example: In a user profile, a function that reads user details and
updates the profile. Both actions (reading and updating) are centered
on the same user data.

4. Procedural Cohesion

● Definition: The elements are grouped together because they follow a

specific order.
● Example: A process that logs in a user and then redirects them to
their homepage. The tasks must happen in a particular sequence: first,
login, then redirect.
5. Temporal Cohesion

● Definition: Tasks are grouped because they happen at the same time.
● Example: During an app’s startup, it may load settings, initialize preferences, and
open the main window. These tasks are unrelated but happen simultaneously when
the app starts.

6. Logical Cohesion

● Definition: Tasks are grouped because they are logically similar, even if they aren’t
directly related.
● Example: A function that handles different types of user input, such as mouse
clicks and keyboard typing. The tasks are grouped because they deal with input, but
they aren’t directly related.
7.Coincidental Cohesion (Low Cohesion)

● Definition: The tasks are grouped arbitrarily with no meaningful connection.

● Example: A module that prints a report and sends an email to a user. These
tasks are unrelated, and grouping them together would cause confusion.
Object oriented design,

Object-Oriented Design (OOD) is a method used in software

engineering to design a system by thinking in terms of "objects."
Objects represent entities in the real world or abstract concepts that
the system is modeling. Each object has its own data (attributes)
and behaviors (methods).
Key Concepts of Object-Oriented Design:

Classes and Objects:

○ Class: A blueprint for creating objects. It defines the attributes

(data) and behaviors (methods) that the objects created from it will
have.
○ Object: An instance of a class. It is a self-contained unit
containing data and methods that operate on that data.

Encapsulation:

○ Combining data and methods in a single unit (object), and

restricting access to some of the object’s components. This means
certain details are hidden from the outside world, and only specific
methods are exposed for interacting with the object.
Inheritance:

● A way to form new classes based on existing ones. The new class
(child) inherits attributes and behaviors from the parent class but can
also have additional features or override some behaviors.

Polymorphism:

● The ability for objects of different classes to be treated as objects of a

common superclass. It allows one interface to be used for a general
class of actions, making the system more flexible. Methods can
perform differently based on the object that calls them.
Abstraction:

● Hiding complex details and exposing only the necessary aspects of an

object. It focuses on what the object does rather than how it does it.
Benefits of Object-Oriented Design:
● Modularity: The system is broken down into smaller,
manageable objects.
● Reusability: Once an object is designed, it can be reused in
different parts of the program.
● Maintainability: Easier to maintain and update code since
objects are self-contained units.
● Scalability: As the program grows, it's easier to add new
features by creating new objects or extending existing ones.
Object-Oriented Design (OOD) in the context of online shopping.

Key Objects in an Online Shopping System:

1. Customer: Represents a user who is shopping online.

2. Product: Represents an item available for purchase.
3. Shopping Cart: Represents the items the customer intends to
buy.
4. Order: Represents the completed purchase.
Object-Oriented Design Concepts Applied:

● Encapsulation: Each class (like Customer, Product) has its own

properties and methods.
● Inheritance: For example, different types of products (like
Electronics, Clothing) could inherit from a base Product class.
● Polymorphism: A method like CalculateDiscount() could behave
differently based on the type of customer (e.g., regular or premium).
● Abstraction: Only relevant details are exposed, like adding items to a
cart, while complex details (like calculating taxes) are hidden.
Walkthrough of the Example:

1. Product Class: This is the base class for all products, with a Name and
Price. It has a method DisplayProductInfo() to show product details.
2. Electronics Class: This is a subclass of Product that adds a
WarrantyPeriod specific to electronics and overrides DisplayProductInfo()
to include warranty details.
3. Customer Class: Represents a customer with a ShoppingCart. The
customer can add products to their cart using the AddToCart() method.
4. ShoppingCart Class: Manages the list of products. It can add products,
calculate the total price, and display the contents of the cart.
5. Order Class: Represents a customer's completed order. The
ConfirmOrder() method finalizes the order and shows the cart contents.
Function oriented design,

Function-Oriented Design (FOD) is a software design approach

where the system is designed as a set of interacting functions or
procedures. Instead of modeling real-world entities as objects (like
in Object-Oriented Design), the focus is on functions that operate
on data, performing tasks to achieve the overall system's
objectives.
Key Features of Function-Oriented Design:

1. Focus on Functions: The system is built by defining functions that

perform specific tasks. These functions take inputs, process them, and
produce outputs.
2. Top-Down Design: The design process usually starts with a high-level
function (representing the system’s goal), which is broken down into
smaller, more manageable sub-functions.
3. Modularization: Functions are grouped into modules based on their
related functionality, promoting organization and reuse.
4. Data and Functions are Separate: Data is passed to functions for
processing, but functions and data are not encapsulated together like in
Object-Oriented Design.
5. Hierarchical Structure: The design creates a hierarchy where higher-level
functions depend on lower-level functions, making the system easier to
understand.
Steps in Function-Oriented Design:

1. Identify the Main Function: Identify the primary goal or function of

the system.
2. Break Down into Sub-functions: Decompose the main function into
smaller sub-functions or modules that perform specific tasks.
3. Define Inputs and Outputs: For each function, clearly define the
inputs it needs and the outputs it produces.
4. Design Flow of Data: Map how data flows between different
functions.
5. Modularize: Group related functions into modules to organize the
system.
Walkthrough of the Function-Oriented Design Example:
1. CreateProduct Function: This function creates a product as a
dictionary with key-value pairs for Name, Price, Type, and
optionally WarrantyPeriod.
2. AddToCart Function: This function adds a product to the
shopping cart (which is a list of dictionaries).
3. GetTotalPrice Function: This calculates the total price of the
items in the cart.
4. DisplayCart Function: Displays all items in the cart and the
total price.
5. ConfirmOrder Function: Finalizes the order and prints the
customer’s cart details.
Comparison with Object-Oriented Design (OOD):
● FOD focuses on actions (functions), while OOD focuses on
entities (objects) and their behaviors.
● In FOD, data is often passed between functions, while in
OOD, data and behaviors are bundled together within objects
(encapsulation).
● FOD is procedural and often better for simpler, task-oriented
systems, while OOD is better suited for complex, scalable
systems that represent real-world entities
Interface design

Interface design is concerned with how users interact with the

system. It deals with the structure, look, and behavior of user
interfaces (UIs) such as buttons, menus, forms, and other
components that users can interact with.
Key Concepts of Interface Design:

1. User Interface (UI): The visible part of the system that users interact with,
like graphical interfaces, command-line prompts, or mobile interfaces.
2. Usability: The ease with which users can learn and use the system. Good
usability means the interface is simple, intuitive, and easy to navigate.
3. Consistency: The interface should behave in a predictable and uniform
manner across different parts of the system (e.g., buttons and actions should
follow the same patterns).
4. Feedback: The system should give users feedback (e.g., loading spinners,
confirmation messages) to inform them that their actions were received and
processed.
5. Error Handling: The interface should guide users when they make mistakes
and provide meaningful error messages that explain what went wrong and
how to fix it.
Steps in Interface Design:

1. Identify the Users: Understand who will use the system and their
needs (novice users, expert users, etc.).
2. Define Tasks: Identify the tasks users need to perform using the
system.
3. Design Layout: Organize visual elements on the interface for optimal
user experience (menus, buttons, forms).
4. Create Prototypes: Develop low-fidelity or high-fidelity prototypes
to test and refine the design.
5. Conduct User Testing: Evaluate the interface with real users to
identify areas for improvement.
Good Interface Design Characteristics:
1. Simple and Clear: Minimal clutter, and important features are
easy to find.
2. Responsive: The UI adapts to different screen sizes (mobile,
desktop).
3. Accessible: Ensures the interface is usable by people with
disabilities (e.g., screen readers, keyboard navigation).
4. Aesthetic: A visually appealing design that enhances user
experience.
Procedural design.

Procedural design is focused on the logic and flow of functions or

procedures in a system. It is concerned with how to break down a
system's functionality into a series of step-by-step processes or
procedures. The primary focus is on how things are done,
emphasizing actions and operations that need to be performed.
Key Concepts of Procedural Design:

1. Functions or Procedures: In procedural design, the system is broken

down into individual functions or procedures that each perform a
specific task.
2. Modularity: The system is divided into smaller, reusable modules or
procedures that handle specific tasks. Each module can be
independently developed and tested.
3. Step-by-Step Logic: Procedures are designed with clear step-by-step
instructions that follow the system’s logic.
4. Data Flow: The movement of data through different functions and
how inputs are transformed into outputs.
5. Control Structures: The use of loops, conditionals (if-else), and
branching to control the flow of the program.
Steps in Procedural Design:

1. Identify Key Functions: Break down the system into a list of key
operations or functions that need to be performed.
2. Design Sub-Procedures: For each key function, define smaller
sub-procedures that handle specific tasks within that function.
3. Define Control Flow: Specify the order in which the procedures will
be executed, including loops, conditionals, and data flow between
procedures.
4. Develop Pseudocode: Write out the logic of each procedure in
pseudocode or flowcharts before implementation.
5. Refine and Optimize: Optimize the flow of the program to improve
efficiency, reduce redundancy, and ensure that the design is clean.
Characteristics of Procedural Design:

1. Linear Flow: The system follows a clear and defined sequence of

steps.
2. Structured Programming: Functions and sub-functions are organized
in a logical hierarchy, following best practices of structured
programming.
3. Easy to Understand: Each procedure is responsible for a specific
task, making the system easier to understand and maintain.
4. Reuse: Procedures or modules can be reused across different parts of
the system.
5. Flexibility: Changes in one procedure usually don't affect the rest of
the system, especially if modular design is used.