Software Design in Software Engineering: Basic Concepts & Architectural Design
Once software requirements are clear, developers still cannot directly start writing random code. They first need a proper plan for how the system will be organised, how its major modules will communicate, how data will be handled and how individual components will work. This planning activity is called software design.
Software design is the process of converting software requirements into a technical plan or model that describes how the software will be organised and how its major components will work together.
In simple words, software design answers: “How should we build the software described in the requirements?”
Why Does Software Design Feel Difficult?
Students usually understand requirements because requirements tell us what the software should do. Design becomes confusing because there can be many different ways to build the same software.
For example, an online shopping application needs login, products, cart, payment and order management. These requirements are easy to list.
But now several new questions appear:
- Should all functions be inside one large module?
- Should login and payment be separate components?
- Where should product information be stored?
- How should the user interface communicate with business logic?
- How will the system interact with a payment service?
- What happens if one component changes?
Software design answers these questions before implementation becomes too complicated.
Software Design with a Simple Real-Life Example
The owner may say: “I need three bedrooms, one kitchen, two bathrooms and a study room.”
These are similar to requirements.
An architect then decides where each room will be placed, how rooms will connect, where doors and stairs will go and how the building will be structured.
That architectural plan is similar to software design.
Design = HOW
From Requirements to Software
Design therefore acts as an important bridge between requirements analysis and implementation.
Why is Software Design Important?
Controls Complexity
A large problem is divided into smaller understandable parts.
Guides Coding
Developers get a clearer technical direction before implementation begins.
Improves Maintainability
Well-separated components are easier to understand and modify.
Supports Testing
Clearly defined components and interfaces are easier to test.
Reduces Rework
Major design problems can be identified before large amounts of code are written.
Supports Quality
Important quality needs can be considered before implementation decisions become fixed.
Main Parts of a Software Design Model
A software design model can be understood through several connected design activities. The exact documentation style may change from project to project, but four major design areas are commonly studied in software engineering.
Data / Class Design
Defines important data structures, classes and how information will be represented.
Architectural Design
Defines major components or subsystems and their relationships.
Interface Design
Defines how users, components and external systems interact.
Component-Level Design
Defines the internal processing and detailed behaviour of individual components.
1. Data or Class Design
Data design focuses on the information required by the software and how that information should be represented.
Depending on the type of software, this may include:
- Data structures
- Classes
- Objects
- Database entities
- Relationships
- Files
- Data access rules
In a library system, important data may include Student, Book, Issue Record and Fine.
The design must decide how these concepts will be represented and related before the database and program structures are implemented.
2. Architectural Design
Architectural design defines the high-level structure of a software system.
It identifies major components or subsystems, the responsibilities of those parts and the important relationships or communication paths between them.
Architectural design decides how the major parts of software are organised and connected.
3. Interface Design
Interface design determines how different parts of the software communicate.
It may include:
- User interface
- Interfaces between software components
- Database interaction
- Application Programming Interfaces (APIs)
- Communication with external systems
An interface is not only the screen that the user sees.
Software components also have interfaces through which they communicate.
4. Component-Level Design
Component-level design describes the internal details of individual modules or components.
Here the designer may decide:
- Internal logic
- Methods or operations
- Data used by the component
- Algorithms
- Error handling
- Component interfaces
High-Level Design and Low-Level Design
In practical software development, you may hear the terms High-Level Design (HLD) and Low-Level Design (LLD).
| Basis | High-Level Design | Low-Level Design |
|---|---|---|
| Focus | Overall system structure | Detailed component implementation design |
| Shows | Major modules and relationships | Classes, methods, algorithms and internal logic |
| Detail | High-level | Detailed |
| Related Concept | Architectural design | Component-level design |
Basic Software Design Concepts
Good software design is based on several important concepts. These concepts help developers control complexity and create software that is easier to understand, test and maintain.
Focus on important features while hiding unnecessary detail.
Divide a large software system into smaller manageable modules.
Keep internal implementation details hidden from components that do not need them.
Start with a high-level solution and gradually add more detail.
Keep different responsibilities or problem areas separate where practical.
Design modules so each performs a focused job and has limited dependence on others.
Abstraction in Software Design
Abstraction means focusing on the important behaviour of something without immediately worrying about all internal details.
When we say: “Process Payment”, we are describing a high-level operation.
We do not immediately describe every API request, validation rule, database update and error condition.
Those details can be introduced later.
Abstraction helps designers understand large systems without becoming lost in implementation details too early.
Refinement
Refinement means moving from a general solution toward a more detailed design step by step.
Modularity
Modularity means dividing a software system into smaller modules or components, each responsible for a meaningful part of the system.
A modular system is usually easier to understand than one huge block of code containing every responsibility.
Benefits of Modularity
- Smaller units are easier to understand.
- Modules can be tested more independently.
- Changes can be localised.
- Different developers can work on different components.
- Reusable components may be easier to identify.
- Faults can sometimes be isolated more easily.
Information Hiding
Information hiding means that a module should expose only the information that other modules need and keep unnecessary internal details private.
A Payment component may expose an operation such as: processPayment().
Other modules do not need to know every internal step used to contact the payment provider, verify the response and record the transaction.
This reduces unnecessary dependency between components.
Separation of Concerns
Separation of concerns means dividing a system according to different responsibilities or problem areas.
For example, an application may separate:
- User interface logic
- Business rules
- Database access
- Authentication
- Logging
When unrelated responsibilities are mixed together, the design becomes harder to maintain.
Functional Independence
A good module should perform a focused task and should not depend unnecessarily on many other modules.
Functional independence is commonly discussed using two concepts:
Keep closely related responsibilities together inside a module.
Reduce unnecessary dependency between different modules.
What is Cohesion?
Cohesion describes how strongly the responsibilities inside one module are related to each other.
A highly cohesive module normally performs one focused responsibility.
A UserAuthentication module handles login-related authentication functions.
One module handles login, invoice printing, database backup, report generation and email marketing.
These responsibilities are not strongly related.
What is Coupling?
Coupling describes the level of dependency between software modules.
If one small change in Module A forces changes in many other modules, the design may be too tightly coupled.
Try to keep modules sufficiently independent while still allowing the communication required by the system.
Architectural Design in Software Engineering
Architectural design is one of the most important parts of software design because it defines the high-level organisation of the complete system.
A software architecture normally describes:
- Major components or subsystems
- Responsibilities of those components
- Connections between components
- Important data movement
- Major control relationships
- Interfaces between important parts
- Important architectural constraints
Architectural Design Example
Consider an online student portal.
Instead of writing all functionality in one program, the system can be separated into major architectural areas.
Pages, forms and user interaction
Student, result, attendance and fee rules
Controls interaction with stored data
Students, courses, attendance and results
This gives developers a high-level picture of how the system is organised before every class or function is designed.
What is an Architectural Style?
An architectural style describes a general way of organising software components and their interactions.
Different styles are suitable for different types of systems. There is no single architectural style that is automatically best for every project.
Common Software Architectural Styles
Layered Architecture
The system is organised into layers, where each layer has a specific responsibility.
Example: presentation → business logic → data access → database.
Client-Server Architecture
Client applications request services or resources from a server.
Common in web applications, network applications and database systems.
Repository / Data-Centred Architecture
Multiple components share or interact through a central data store.
Useful when shared data is the central part of the system.
Pipe-and-Filter Architecture
Data moves through a sequence of processing components. Each component transforms the data and passes it forward.
Model-View-Controller (MVC)
Separates data/model responsibilities, user-interface presentation and interaction/control logic.
Event-Driven Architecture
Components react to events such as user actions, messages or changes in system state.
Layered Architecture Explained
Layered architecture divides software into logical levels. A layer usually performs a particular group of responsibilities.
Advantages of Layered Architecture
- Easy to understand.
- Responsibilities are separated.
- Changes may remain within one layer.
- Testing can become easier.
- Common in business applications.
Limitations
- Too many layers can add unnecessary complexity.
- Performance may suffer if every request must pass through many layers.
- Poorly defined layer boundaries can still create tight coupling.
Client-Server Architecture
In client-server architecture, one or more clients request services from one or more servers.
When you open a web application in a browser, the browser acts as a client. It sends requests to a server, and the server processes those requests and sends responses back.
Repository or Data-Centred Architecture
In repository architecture, a central data store is an important part of the system. Multiple components access or update shared information through that repository.
Example
Consider a university management system.
Admission, examination, attendance and fee modules may all need access to common student information.
Pipe-and-Filter Architecture
Pipe-and-filter architecture breaks processing into a series of independent stages.
Output from one processing stage becomes input to the next stage.
This style is useful when data naturally passes through a sequence of transformations.
Model-View-Controller (MVC)
MVC separates an application into three broad responsibilities.
Model
Represents application data and important business-related state or logic.
View
Represents what is presented to the user.
Controller
Handles interaction or requests and coordinates between model and view responsibilities.
Event-Driven Architecture
In event-driven systems, components respond when important events occur.
- Order placed
- Payment completed
- File uploaded
- User registered
- Sensor value changed
Other parts of the system may listen for these events and perform appropriate actions.
Architectural Styles Comparison
| Style | Main Idea | Suitable Example | Main Strength |
|---|---|---|---|
| Layered | System divided into logical layers | Business application | Clear separation of responsibilities |
| Client-Server | Clients request services from server | Web application | Centralised service delivery |
| Repository | Shared central data store | Information management system | Shared data management |
| Pipe-and-Filter | Sequential data transformation | Data processing pipeline | Independent processing stages |
| MVC | Separates model, interface and control | Interactive application | Separation of concerns |
| Event-Driven | Components react to events | Notification or asynchronous system | Loose interaction through events |
How Do We Choose an Architecture?
Architecture should not be selected only because one style is popular.
The choice should consider project requirements and constraints.
Software Design Process Step by Step
Study the Requirements
Understand functional requirements, non-functional requirements, interfaces and important constraints from the SRS.
Identify Major Responsibilities
Find the important business or system responsibilities that need to be handled by the software.
Identify Major Components
Divide the system into meaningful modules, services, layers or subsystems.
Select the Architectural Approach
Choose or combine architectural styles that fit the project's requirements and constraints.
Design Data
Decide how important information, classes, records or database structures should be organised.
Define Interfaces
Clearly define how users, modules and external systems will communicate.
Refine Components
Add more detail to each component, including responsibilities, operations and internal behaviour.
Evaluate Design Quality
Check cohesion, coupling, maintainability, security, performance and other relevant quality needs.
Review the Design
Review the design before large-scale implementation starts and correct important weaknesses.
Characteristics of a Good Software Design
Correct
Design should support the stated software requirements.
Understandable
Developers should be able to understand major design decisions.
Modular
Responsibilities should be separated into meaningful components.
Maintainable
Future changes should not require unnecessary modifications everywhere.
Testable
Components and interfaces should support practical testing.
Traceable
Important design elements should be connected to relevant requirements.
Software Design vs Software Architecture
Software architecture is part of the broader software design activity, but both terms are not always used at exactly the same level.
| Basis | Software Architecture | Software Design |
|---|---|---|
| Focus | High-level system structure | Broader technical solution and detailed design |
| Concern | Major components and relationships | Architecture, interfaces, data and component details |
| Level | Mostly high-level | High-level to detailed |
| Example | Layered system architecture | Architecture plus class, interface and algorithm design |
SRS vs Software Design
| Basis | SRS | Software Design |
|---|---|---|
| Main Question | What must the software do? | How should the solution be organised? |
| Focus | Requirements | Technical solution |
| Created During | Requirements engineering | Design stage |
| Used By | Stakeholders, analysts, developers and testers | Architects, designers, developers and testers |
Software Design vs Coding
Design: Decide how the system should be structured.
Coding: Implement that structure using a programming language and development tools.
Coding without enough design may work for small experiments, but large systems quickly become difficult to understand when responsibilities and interfaces are not planned.
Architectural Design and Quality Attributes
Architecture strongly affects many non-functional requirements.
| Quality Attribute | Architectural Concern |
|---|---|
| Performance | Communication overhead, processing path and data access |
| Security | Trust boundaries, authentication and access separation |
| Maintainability | Module boundaries and dependency management |
| Scalability | Ability to support increasing load or data |
| Availability | Handling component or infrastructure failure |
| Testability | Clear components, interfaces and dependency control |
Software Architecture vs Design Pattern
An architectural style gives a high-level organisation for a system, while a design pattern usually provides a reusable solution idea for a recurring design problem at a more focused level.
Layered architecture may organise the complete application.
Inside one layer, developers may use suitable design patterns for specific object-design problems.
Common Software Design Mistakes
Mistake 1: Starting Coding Before Understanding Requirements
A technically good design cannot solve the wrong problem.
Mistake 2: One Huge Module
Putting every responsibility into one large component makes development, testing and maintenance difficult.
Mistake 3: Too Much Coupling
If every module depends directly on many other modules, one small change can affect the complete system.
Mistake 4: Very Low Cohesion
A module containing unrelated responsibilities becomes difficult to understand.
Mistake 5: Choosing Architecture Because It Is Popular
Architecture should fit project requirements instead of current fashion.
Mistake 6: Ignoring Non-Functional Requirements
Performance, security, maintainability and scalability can strongly influence design decisions.
Mistake 7: Overengineering
Adding unnecessary layers, patterns and components can make a simple problem unnecessarily complex.
Mistake 8: No Design Review
Important architecture problems become more expensive once large amounts of code depend on them.
Complete Example: Designing an Online Examination System
Suppose the SRS says an Online Examination System should support:
- Student login
- Exam scheduling
- Question delivery
- Answer submission
- Automatic result calculation
- Administrator management
We can now move from requirements to software design.
Step 1: Identify Major Modules
Step 2: Separate Layers
Student and administrator screens
Exam rules and application operations
Controlled access to stored records
Users, exams, questions, responses and results
Step 3: Define Interfaces
- Student interface
- Administrator interface
- Authentication interface
- Question service interface
- Result-generation interface
- Database interface
Step 4: Apply Modularity
Authentication should not also calculate results.
Result processing should not directly contain user-interface code.
Each component should have a clear responsibility.
Step 5: Check Quality Requirements
The team should evaluate questions such as:
- Can the architecture handle the expected number of students?
- What happens if a student loses connectivity?
- How are exam answers protected?
- Can important modules be tested separately?
- Can exam rules change without rewriting the complete system?
Advantages of Good Software Design
- Provides a clear development plan.
- Reduces unnecessary complexity.
- Makes large software easier to understand.
- Supports better maintainability.
- Improves testability.
- Helps isolate changes.
- Supports reuse where appropriate.
- Helps teams divide development work.
- Allows quality concerns to be considered early.
- Can reduce expensive redesign later.
Challenges and Limitations of Software Design
- Design requires time before coding starts.
- Requirements may change after design work begins.
- Overdesign can make simple systems unnecessarily complex.
- Poor assumptions can lead to unsuitable architecture.
- No design can predict every future requirement.
- Architectural trade-offs are often required.
What is an Architectural Trade-Off?
A trade-off occurs when improving one quality may affect another quality, cost or design goal.
Adding additional security checks may increase protection but can also add processing overhead.
Adding more abstraction may improve flexibility but may also make a small system harder to understand.
Good software design is therefore not about making every quality maximum. It is about making suitable decisions for the project's actual requirements.
Software Design Review Checklist
Exam-Oriented Definition of Software Design
Software design is the process of transforming software requirements into a technical representation that describes the architecture, components, interfaces, data and detailed structure required for implementation.
2 Marks: What is Architectural Design?
Architectural design is the high-level design activity that identifies major software components or subsystems and defines the relationships and interactions among them.
5 Marks: Explain Basic Software Design Concepts
Important software design concepts include:
- Abstraction: Focus on essential behaviour while hiding unnecessary detail.
- Modularity: Divide software into manageable modules.
- Information Hiding: Hide internal implementation details from unrelated components.
- Refinement: Develop the solution from high-level ideas to detailed design.
- Functional Independence: Aim for high cohesion and low coupling.
5 Marks: Explain Architectural Design
Architectural design defines the overall structure of a software system. It identifies major modules or components, their responsibilities, interfaces and relationships.
Common architectural styles include layered architecture, client-server architecture, repository architecture, pipe-and-filter architecture, MVC and event-driven architecture.
5 Marks: Explain Cohesion and Coupling
Cohesion refers to how strongly the responsibilities inside one module are related. A highly cohesive module performs a focused task.
Coupling refers to dependency between different modules. Excessive coupling makes changes difficult.
Therefore, good modular design generally aims for: high cohesion and low coupling.
10 Marks: Explain Software Design and Architectural Design
For a strong 10-mark answer, use this structure:
- Define software design.
- Explain why design is required.
- Explain design as a bridge between SRS and coding.
- Explain data/class design.
- Explain architectural design.
- Explain interface design.
- Explain component-level design.
- Explain abstraction and refinement.
- Explain modularity and information hiding.
- Explain cohesion and coupling.
- Describe important architectural styles.
- Draw one architectural diagram.
- Write advantages and conclusion.
Diagram You Can Draw in an Exam
This simple layered architecture diagram is useful when the question asks for an example of software architectural design.
Easy Memory Tricks
Requirements → Design
Abstraction – Modularity – Information Hiding – Refinement
High Cohesion + Low Coupling
Data – Architecture – Interface – Component
Quick Revision Notes
- Software design converts software requirements into a technical solution.
- Requirements mainly explain what the system should do.
- Design explains how the solution should be organised.
- Design acts as a bridge between requirement analysis and coding.
- Major design areas include data/class design, architectural design, interface design and component-level design.
- Architectural design describes major software components and their relationships.
- Abstraction hides unnecessary detail.
- Refinement moves from a high-level idea toward detailed design.
- Modularity divides software into smaller manageable parts.
- Information hiding keeps internal details private from unrelated modules.
- Separation of concerns keeps different responsibilities separate.
- Functional independence aims to reduce unnecessary module dependence.
- A good module should generally have high cohesion.
- Dependency between modules is called coupling.
- Good modular design generally aims for low coupling.
- Common architectural styles include layered, client-server, repository, pipe-and-filter, MVC and event-driven architecture.
- Architecture should be selected according to project requirements, not popularity.
- Software architecture strongly influences performance, security, scalability and maintainability.
- Good design should be understandable, modular, testable and maintainable.
- Overengineering can make a simple system unnecessarily complex.
Frequently Asked Questions
What is software design in software engineering?
Software design is the process of transforming software requirements into a technical model that describes the structure, components, interfaces, data and behaviour needed for implementation.
Why is software design important?
Software design reduces complexity, guides implementation, improves maintainability and helps teams consider important quality requirements before large amounts of code are written.
What are the main software design activities?
Commonly studied design activities include data or class design, architectural design, interface design and component-level design.
What is architectural design?
Architectural design defines the high-level structure of software by identifying major components or subsystems and their relationships.
What is abstraction in software design?
Abstraction means focusing on essential behaviour while temporarily hiding unnecessary implementation details.
What is modularity?
Modularity is the practice of dividing a software system into smaller, meaningful and manageable modules or components.
What is information hiding?
Information hiding means keeping the internal implementation details of a module private and exposing only what other modules need.
What is cohesion?
Cohesion describes how closely related the responsibilities within one software module are. High cohesion generally means the module has a focused purpose.
What is coupling?
Coupling describes dependency between software modules. Excessive coupling can make changes and testing more difficult.
What is the best relation between cohesion and coupling?
Good modular design generally aims for high cohesion within modules and low unnecessary coupling between modules.
What is layered architecture?
Layered architecture organises software into logical layers such as presentation, business logic, data access and data storage.
What is client-server architecture?
Client-server architecture is a structure where clients request services or resources from one or more servers.
What is pipe-and-filter architecture?
Pipe-and-filter architecture passes data through a sequence of independent processing stages, where each stage transforms the data.
What is MVC architecture?
Model-View-Controller separates application data or domain responsibilities, user-interface presentation and interaction or control responsibilities.
What is the difference between SRS and software design?
SRS mainly describes what the software must satisfy, while software design describes how the technical solution should be organised.
What is the difference between software architecture and software design?
Software architecture mainly focuses on the high-level structure and major components of a system, while software design also includes more detailed data, interface and component-level decisions.
Conclusion
Software design is the stage where software requirements start becoming a real technical solution. Instead of directly jumping from an SRS to code, developers first decide how the software should be organised.
A complete design may include data design, architectural design, interface design and detailed component design.
Concepts such as abstraction, modularity, information hiding, refinement and separation of concerns help designers control complexity. Cohesion and coupling help us judge whether modules have clear responsibilities and manageable dependencies.
Architectural design gives the complete system a high-level structure. Styles such as layered, client-server, repository, pipe-and-filter, MVC and event-driven architecture provide useful ways of organising different types of applications.
The most important point is that there is no architecture that is automatically perfect for every software project. The design should be selected according to requirements, constraints and quality needs.
Requirements = What?
Design = How?
Architecture = What are the major parts and how are they connected?
Good Modularity = High Cohesion + Low Coupling.
