Unit-2

1. Requirements gathering

Requirements gathering are a crucial phase in the software development life cycle
(SDLC) and project management. It involves collecting, documenting, and
managing the requirements that define the features and functionalities of a system
or application. The success of a project often depends on the accuracy and
completeness of the gathered requirements in software.
Main Requirements Gathering Sub processes:
Requirements gathering are a critical phase in the software development
lifecycle, and it involves several sub processes to ensure a comprehensive
understanding of the project’s needs. The main sub processes include:
Stakeholder Identification:
 Objective: Identify all stakeholders who will be affected by the system,
directly or indirectly.
 Process: Conduct interviews, surveys, or workshops to determine the key
individuals or groups involved.
Stakeholder Analysis:
 Objective: Understand the needs, expectations, and influence of each
stakeholder.
 Process: Analyze stakeholder inputs to prioritize requirements and manage
conflicting interests.
Problem Definition:
 Objective: Clearly define the problems or opportunities that the software
system aims to address.
 Process: Engage stakeholders in discussions to uncover and articulate the core
problems or opportunities.
Requirements Extraction:
 Objective: Gather detailed requirements by interacting with stakeholders.
 Process: Employ techniques such as interviews, surveys, observations, or
brainstorming sessions to extract requirements.
Requirements Documentation:
 Objective: Document gathered requirements in a structured format.
 Process: Create requirements documents, use cases, user stories, or prototypes
to capture and communicate requirements effectively.
Validation and Verification:
 Objective: Ensure that gathered requirements are accurate, complete, and
consistent.
1
 Process: Conduct reviews, walkthroughs, or use validation tools to verify that
the requirements meet the defined criteria.
Processes of Requirements Gathering in Software Development:
There are 6 steps crucial for requirement gathering processes

Step 1- Assigning roles:

 The first step is to identify and engage with all relevant stakeholders.
Stakeholders can include end-users, clients, project managers, subject matter
experts, and anyone else who has a vested interest in the software project.
Understanding their perspectives is essential for capturing diverse
requirements.
Step 2- Define Project Scope:
 Clearly define the scope of the project by outlining its objectives, boundaries,
and limitations. This step helps in establishing a common understanding of
what the software is expected to achieve and what functionalities it should
include.
Step 3- Conduct Stakeholder Interviews:
 Schedule interviews with key stakeholders to gather information about their
needs, preferences, and expectations. Through open-ended questions and
discussions, aim to uncover both explicit and implicit requirements. These
interviews provide valuable insights that contribute to a more holistic
understanding of the project.
Step 4- Document Requirements:
 Systematically document the gathered requirements. This documentation can
take various forms, such as user stories, use cases, or formal specifications.
Clearly articulate functional requirements (what the system should do) and
non-functional requirements (qualities the system should have, such as
performance or security).
Step 5- Verify and Validate Requirements:
2
 Once the requirements are documented, it’s crucial to verify and validate
them. Verification ensures that the requirements align with the stakeholders’
intentions, while validation ensures that the documented requirements will
meet the project’s goals. This step often involves feedback loops and
discussions with stakeholders to refine and clarify requirements.
Step 6- Prioritize Requirements:
 Prioritize the requirements based on their importance to the project goals and
constraints. This step helps in creating a roadmap for development, guiding
the team on which features to prioritize. Prioritization is essential, especially
when resources and time are limited.
Requirement Gathering Techniques:
Effective requirement gathering is essential for the success of a software
development project. Various techniques are employed to collect, analyze, and
document requirements.

Here are some commonly used requirement gathering techniques:

1. Interviews:
 Conducting one-on-one or group interviews with stakeholders, including
end-users, clients, and subject matter experts. This allows for direct
interaction to gather detailed information about their needs, expectations,
and concerns.
2. Surveys and Questionnaires:
 Distributing surveys and questionnaires to a broad audience to collect
information on a larger scale. This technique is useful for gathering
feedback from a diverse set of stakeholders and can be particularly
effective in large projects.

3
3. Workshops:
 Organizing facilitated group sessions or workshops where stakeholders
come together to discuss and define requirements. Workshops encourage
collaboration, idea generation, and the resolution of conflicting viewpoints
in a structured environment.
4. Observation:
 Directly observing end-users in their work environment to understand their
workflows, pain points, and preferences. Observational techniques help in
uncovering implicit requirements that users might not explicitly state.
5. Prototyping:
 Creating mockups or prototypes of the software to provide stakeholders
with a tangible representation of the proposed system. Prototyping allows
for early visualization and feedback, helping to refine requirements based
on stakeholders’ reactions.
6. Use Cases and Scenarios:
 Developing use cases and scenarios to describe how the system will be
used in different situations. This technique helps in understanding the
interactions between users and the system, making it easier to identify and
document functional requirements.
7. Document Analysis:
 Reviewing existing documentation, such as business process manuals,
reports, and forms, to extract relevant information. This technique provides
insights into the current processes and helps identify areas for
improvement.
Benefits of Requirements Gathering:
The benefits of effective requirements gathering in software development
include:
 Cost Reduction: One of the primary benefits of effective requirements
gathering is cost reduction. When requirements are well-defined and
thoroughly understood at the beginning of a project, it minimizes the
likelihood of costly changes and rework later in the development process.
 Customer Satisfaction: Clear and accurate requirements gathering directly
contributes to customer satisfaction. When the end product aligns closely with
the expectations and needs of the stakeholders, it enhances user experience
and meets customer demands. This satisfaction is not only vital for the success
of the current project but also contributes to positive relationships between the
development team and clients, fostering trust and potential future
collaborations.
 Improved Communication: Requirements gathering serves as a
communication bridge between various stakeholders involved in a project,
4
 including developers, clients, users, and project managers. Miscommunication
is a common source of project failures and delays. By clearly documenting
and understanding requirements, the development team ensures that everyone
involved has a shared vision of the project objectives, functionalities, and
constraints.
 Efficient Resource Utilization: Thorough requirements gathering enables the
efficient allocation and utilization of resources. Resources, including time,
manpower, and technology, are finite and valuable. When requirements are
well-defined, project teams can allocate resources more accurately, avoiding
unnecessary expenditures or overcommitting resources to certain aspects of
the project.
 Enhanced Quality: Well-documented requirements serve as the foundation
for quality assurance throughout the development process. When the project
team has a clear understanding of what needs to be achieved, they can
establish quality standards and criteria from the outset. This clarity enables the
implementation of effective testing strategies, ensuring that each aspect of the
system is thoroughly evaluated against the specified requirements.
 Risk Management: Requirements gathering is a crucial component of
effective risk management. By identifying potential risks early in the project,
stakeholders can proactively address ambiguities, conflicting requirements,
and other challenges that could pose a threat to the project’s success.
 Accurate Planning: Accurate project planning is dependent on a clear
understanding of project requirements. When requirements are well-
documented, project managers can create realistic schedules, milestones, and
deliverables. This accurate planning is crucial for setting expectations,
managing stakeholder timelines, and ensuring that the project progresses
according to the established timeline.

2. Software Requirements Specifications

The production of the requirements stage of the software development process

is Software Requirements Specifications (SRS) (also called a requirements
document). This report lays a foundation for software engineering activities and is
constructing when entire requirements are elicited and analyzed. SRS is a formal
report, which acts as a representation of software that enables the customers to
review whether it (SRS) is according to their requirements. Also, it comprises user
requirements for a system as well as detailed specifications of the system
requirements.

5
The SRS is a specification for a specific software product, program, or set of
applications that perform particular functions in a specific environment. It serves
several goals depending on who is writing it. First, the SRS could be written by the
client of a system. Second, the SRS could be written by a developer of the system.
The two methods create entirely various situations and establish different purposes
for the document altogether. The first case, SRS, is used to define the needs and
expectation of the users. The second case, SRS, is written for various purposes and
serves as a contract document between customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated

in the SRS. SRS is said to be perfect if it covers all the needs that are truly
expected from the system.

6
2. Completeness: The SRS is complete if, and only if, it includes the following
elements:

All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.

Definition of their responses of the software to all realizable classes of input data
in all available categories of situations.

Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in
the SRS:

 The specified characteristics of real-world objects may conflicts. For

example,
 (a) The format of an output report may be described in one requirement as
tabular but in another as textual.
 (b) One condition may state that all lights shall be green while another states
that all lights shall be blue.
 There may be a reasonable or temporal conflict between the two specified
actions. For example,
 (a) One requirement may determine that the program will add two inputs,
and another may determine that the program will multiply them.
 (b) One condition may state that "A" must always follow "B," while other
requires that "A and B" co-occurs.
 Two or more requirements may define the same real-world object but use
different terms for that object. For example, a program's request for user
input may be called a "prompt" in one requirement's and a "cue" in another.
The use of standard terminology and descriptions promotes consistency.

4. Unambiguousness: SRS is unambiguous when every fixed requirement has

only one interpretation. This suggests that each element is uniquely interpreted. In
case there is a method used with multiple definitions, the requirements report
should determine the implications in the SRS so that it is clear and simple to
understand.

7
5. Ranking for importance and stability: The SRS is ranked for importance and
stability if each requirement in it has an identifier to indicate either the significance
or stability of that particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable.
Each element should be identified to make these differences clear and explicit.
Another way to rank requirements is to distinguish classes of items as essential,
conditional, and optional.

6. Modifiability: SRS should be made as modifiable as likely and should be

capable of quickly obtain changes to the system to some extent. Modifications
should be perfectly indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified

with a cost-effective system to check whether the final software meets those
requirements. The requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is

clear and if it facilitates the referencing of each condition in future development or
enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly

referencing its source in earlier documents.

2. Forward Traceability: This depends upon each element in the SRS having a
unique name or reference number.

The forward traceability of the SRS is especially crucial when the software product
enters the operation and maintenance phase. As code and design document is
modified, it is necessary to be able to ascertain the complete set of requirements
that may be concerned by those modifications.

9. Design Independence: There should be an option to select from multiple design

alternatives for the final system. More specifically, the SRS should not contain any
implementation details.

10. Testability: An SRS should be written in such a method that it is simple to

generate test cases and test plans from the report.

8
11. Understandable by the customer: An end user may be an expert in his/her
explicit domain but might not be trained in computer science. Hence, the purpose
of formal notations and symbols should be avoided too as much extent as possible.
The language should be kept simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements
stage, the details should be explained explicitly. Whereas,for a feasibility study,
fewer analysis can be used. Hence, the level of abstraction modifies according to
the objective of the SRS.

The essential properties of a good SRS document are the following:

 Concise: The SRS report should be concise and at the same time,
unambiguous, consistent, and complete. Verbose and irrelevant descriptions
decrease readability and also increase error possibilities.
 Structured: It should be well-structured. A well-structured document is
simple to understand and modify. In practice, the SRS document undergoes
several revisions to cope up with the user requirements. Often, user
requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-
structured.
 Black-box view: It should only define what the system should do and
refrain from stating how to do these. This means that the SRS document
should define the external behavior of the system and not discuss the
implementation issues. The SRS report should view the system to be
developed as a black box and should define the externally visible behavior
of the system. For this reason, the SRS report is also known as the black-box
specification of a system.
 Conceptual integrity: It should show conceptual integrity so that the reader
can merely understand it. Response to undesired events: It should
characterize acceptable responses to unwanted events. These are called
system response to exceptional conditions.
 Verifiable: All requirements of the system, as documented in the SRS
document, should be correct. This means that it should be possible to decide
whether or not requirements have been met in an implementation.

9
3. Good Software Design:

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.

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

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

Characteristics 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 comprehensive test coverage.

11
4. Cohesion and Coupling

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.

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.

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.

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

13
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

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

15
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

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

17
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.
Conclusion
In conclusion, it’s good for software to have low coupling and high cohesion.
Low coupling means the different parts of the software don’t rely too much on
each other, which makes it safer to make changes without causing unexpected
problems. High cohesion means each part of the software has a clear purpose and
sticks to it, making the code easier to work with and reuse. Following these
principles helps make software stronger, more adaptable, and easier to grow.

18
5. Software Design Approaches
A good system design is to organize the program modules in such a way that are
easy to develop and change. Structured design techniques help developers to deal
with the size and complexity of programs. Analysts create instructions for the
developers about how code should be written and how pieces of code should fit
together to form a program.
Software Engineering is the process of designing, building, testing, and
maintaining software. The goal of software engineering is to create software that
is reliable, efficient, and easy to maintain. System design is a critical component
of software engineering and involves making decisions about the architecture,
components, modules, interfaces, and data for a software system.
System Design Strategy refers to the approach that is taken to design a
software system. There are several strategies that can be used to design
software systems, including the following:
1. Top-Down Design: This strategy starts with a high-level view of the system
and gradually breaks it down into smaller, more manageable components.
2. Bottom-Up Design: This strategy starts with individual components and builds
the system up, piece by piece.
3. Iterative Design: This strategy involves designing and implementing the
system in stages, with each stage building on the results of the previous stage.
4. Incremental Design: This strategy involves designing and implementing a
small part of the system at a time, adding more functionality with each
iteration.
5. Agile Design: This strategy involves a flexible, iterative approach to design,
where requirements and design evolve through collaboration between self-
organizing and cross-functional teams.
The design of a system is essentially a blueprint or a plan for a solution for the
system. 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, the
specifications of these modules and how the modules should be interconnected.
The design of a system is correct if a system built precisely according to the
design satisfies the requirements of that system. The goal of the design process is
not simply to produce a design for the system. Instead, the goal is to find the best
possible design within the limitations imposed by the requirements and the
physical and social environment in which the system will operate.
19
The choice of system design strategy will depend on the particular requirements
of the software system, the size and complexity of the system, and the
development methodology being used. A well-designed system can simplify the
development process, improve the quality of the software, and make the software
easier to maintain.
Importance of System Design Strategy:
1. If any pre-existing code needs to be understood, organized, and pieced
together.
2. It is common for the project team to have to write some code and produce
original programs that support the application logic of the system.
There are many strategies or techniques for performing system design. They are:
Bottom-up approach:
The design starts with the lowest level components and subsystems. By using
these components, the next immediate higher-level components and subsystems
are created or composed. The process is continued till all the components and
subsystems are composed into a single component, which is considered as the
complete system. The amount of abstraction grows high as the design moves to
more high levels.
By using the basic information existing system, when a new system needs to be
created, the bottom-up strategy suits the purpose.

Advantages of Bottom-up approach:

 The economics can result when general solutions can be reused.
 It can be used to hide the low-level details of implementation and be merged
with the top-down technique.
20
Disadvantages of Bottom-up approach:
 It is not so closely related to the structure of the problem.
 High-quality bottom-up solutions are very hard to construct.
 It leads to the proliferation of ‘potentially useful’ functions rather than the
most appropriate ones.
Top-down approach:
Each system is divided into several subsystems and components. Each of the
subsystems is further divided into a set of subsystems and components. This
process of division facilitates forming a system hierarchy structure. The complete
software system is considered a single entity and in relation to the characteristics,
the system is split into sub-systems and components. The same is done with each
of the sub-systems.
This process is continued until the lowest level of the system is reached. The
design is started initially by defining the system as a whole and then keeps on
adding definitions of the subsystems and components. When all the definitions
are combined, it turns out to be a complete system.
For the solutions of the software that need to be developed from the ground level,
a top-down design best suits the purpose.

Advantages of Top-down approach:

 The main advantage of the top-down approach is that its strong focus on
requirements helps to make a design responsive according to its requirements.
Disadvantages of Top-down approach:

21
 Project and system boundaries tend to be application specification-oriented.
Thus, it is more likely that the advantages of component reuse will be missed.
 The system is likely to miss, the benefits of a well-structured, simple
architecture.
 Hybrid Design:
It is a combination of both top-down and bottom-up design strategies. In this,
we can reuse the modules.
Advantages of using a System Design Strategy:
1. Improved quality: A well-designed system can improve the overall quality of
the software, as it provides a clear and organized structure for the software.
2. Ease of maintenance: A well-designed system can make it easier to maintain
and update the software, as the design provides a clear and organized structure
for the software.
3. Improved efficiency: A well-designed system can make the software more
efficient, as it provides a clear and organized structure for the software that
reduces the complexity of the code.
4. Better communication: A well-designed system can improve communication
between stakeholders, as it provides a clear and organized structure for the
software that makes it easier for stakeholders to understand and agree on the
design of the software.
5. Faster development: A well-designed system can speed up the development
process, as it provides a clear and organized structure for the software that
makes it easier for developers to understand the requirements and implement
the software.
Disadvantages of using a System Design Strategy:
1. Time-consuming: Designing a system 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, it can be difficult to make
changes to the design, as the process is often highly structured and
documentation-intensive.

22
6. Function Oriented Design
Function-oriented design is the result of focusing attention on the function of the
program. This is based on the stepwise refinement. Stepwise refinement is based
on the iterative procedural decomposition. Stepwise refinement is a top-down
strategy where a program is refined as a hierarchy of increasing levels of detail.
We start with a high-level description of what the program does. Then, in each
step, we take one part of our high-level description and refine it. Refinement is
actually a process of elaboration. The process should proceed from a highly
conceptual model to lower-level details. The refinement of each module is done
until we reach the statement level of our programming language.
Object Oriented Design:
Object-oriented design is the result of focusing attention not on the function
performed by the program, but instead on the data that are to be manipulated by
the program. Thus, it is orthogonal to function-oriented design. The object-
oriented design begins with an examination of real-world “things”. These things
have individual characteristics in terms of their attributes and behaviors.
Objects are independent entities that may readily be changed because all state and
representation information is held within the object itself. Objects may be
distributed and may execute sequentially or in parallel. Object-oriented
technology contains the following three keywords –

1. Objects: Software packages are designed and developed to correspond with

real-world entities that contain all the data and services to function as their
associated entity messages.
2. Communication: Communication mechanisms are established that provide
how objects work together.
3. Methods: Methods are services that objects perform to satisfy the functional
requirements of the problem domain. Objects request services of the other
objects through messages.

23
Difference between Function Oriented Design and Object Oriented Design
COMPARISON FUNCTION ORIENTED OBJECT ORIENTED
FACTORS DESIGN DESIGN

The basic abstractions are

The basic abstractions,
not the real world functions
which are given to the
Abstraction but are the data abstraction
user, are real world
where the real world
functions.
entities are represented.

Function are grouped

Functions are grouped together on the basis of the
Function together by which a higher data they operate since the
level function is obtained. classes are associated with
their methods.

carried out using

structured analysis and
execute Carried out using UML
structured design i.e, data
flow diagram

In this approach the state

In this approach the state
information is not
information is often
State represented in a centralized
represented in a
information memory but is implemented
centralized shared
or distributed among the
memory.
objects of the system.

Approach It is a top down approach. It is a bottom up approach.

Begins by considering the

Begins by identifying
Begins basis use case diagrams and the
objects and classes.
scenarios.

24
COMPARISON FUNCTION ORIENTED OBJECT ORIENTED
FACTORS DESIGN DESIGN

In function oriented design

We decompose in class
Decompose we decompose in
level.
function/procedure level.

This approach is mainly

This approach is mainly
used for evolving system
Use used for computation
which mimics a business or
sensitive application.
business case.

25