Software Engineering Notes 2023

SOFTWARE ENGINEERING

DR. TEJASHREE TEJPAL MOHAREKAR

MCA, NET, Ph. D
Assistant Professor
Shivaji University, Kolhapur

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 1

 Software Engineering Notes 2023

UNIT 2

Requirements Engineering and Design Concepts: Seven tasks of requirement engineering,

Eliciting Requirements, Types of requirement, fundamental problem in defining requirements,
SRS template. Translating the requirement model into the design model, software design
concepts abstraction, architecture, pattern, separation of concerns, modularity, information
hiding, functional independence-cohesion, coupling, refinement, aspects, refactoring.

WHAT ARE REQUIREMENT AND REQUIREMENT ENGINEERING?

There are two terms here, “Requirement” and “Requirements Engineering”. A requirement is
precisely defined as a condition or a capability that a user needs to solve a problem or achieve a
goal.

In other words, requirements are conditions or capabilities that must be met or possessed by a
system in order to satisfy a contract, standards, specifications, and other formal
documentation.

Requirements Engineering is defined as the process of defining, documenting, and maintaining

the requirements. The discipline includes all the techniques, methods, and procedures related
to the definition and management of users’ needs related to the system being studied.

All-in-all, Requirements Engineering is a set of activities that are concerned with identifying and
communicating the purpose of a system or software and the context in which it will be used.

Therefore, Requirements Engineering acts as a bridge between the real-world needs of the users,
customers, and other constituencies that are affected by software or system and the capabilities
and opportunities afforded by the software-intensive technologies.

REQUIREMENTS ENGINEERING?

Requirements engineering (RE) refers to the process of defining, documenting, and

maintaining requirements in the engineering design process. Requirement engineering provides

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 2

 Software Engineering Notes 2023

the appropriate mechanism to understand what the customer desires, analyzing the need, and
assessing feasibility, negotiating a reasonable solution, specifying the solution clearly, validating
the specifications and managing the requirements as they are transformed into a working system.

Thus, requirement engineering is the disciplined application of proven principles, methods, tools,
and notation to describe a proposed system's intended behavior and its associated constraints.

The software requirements are description of features and functionalities of the target system.
Requirements convey the expectations of users from the software product. The requirements can
be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.

Definition

1. The process to gather the software requirements from client, analyze and document them
is known as requirement engineering.
2. The process of defining, documentation, and maintenance of requirements in the design
process of engineering is called requirements engineering.

The goal of requirement engineering is to develop and maintain sophisticated and descriptive
‘System Requirements Specification’ document.

PROCESS OF REQUIREMENTS ENGINEERING

It is a process, which includes -

1. Feasibility Study

2. Requirement Elicitation and Analysis

3. Software Requirement Specification

4. Software Requirement Validation

5. Software Requirement Management

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 3

 Software Engineering Notes 2023

1. Feasibility Study:

The objective behind the feasibility study is to create the reasons for developing the software that
is acceptable to users, flexible to change and conformable to established standards.

Types of Feasibility:

1. Technical Feasibility -

Technical feasibility evaluates the current technologies, which are needed to accomplish
customer requirements within the time and budget.

2. Operational Feasibility -

Operational feasibility assesses the range in which the required software performs a series of
levels to solve business problems and customer requirements.

3. Economic Feasibility -

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 4

 Software Engineering Notes 2023

Economic feasibility decides whether the necessary software can generate financial profits
for an organization.

2. Requirement Elicitation and Analysis:

This is also known as the gathering of requirements. Here, requirements are identified with the
help of customers and existing systems processes, if available.

Analysis of requirements starts with requirement elicitation. The requirements are analyzed to
identify inconsistencies, defects, omission, etc. We describe requirements in terms of
relationships and also resolve conflicts if any.

Requirement elicitation process can be also depicted using the following diagram:

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 5

 Software Engineering Notes 2023

 Requirements gathering -

The developers discuss with the client and end users and know their expectations from the
software.

 Organizing Requirements -

The developers prioritize and arrange the requirements in order of importance, urgency and
convenience.

 Negotiation & discussion -

If requirements are ambiguous or there are some conflicts in requirements of various

stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements
may then be prioritized and reasonably compromised.

The requirements come from various stakeholders. To remove the ambiguity and conflicts,
they are discussed for clarity and correctness. Unrealistic requirements are compromised
reasonably.

 Documentation -

All formal & informal, functional and non-functional requirements are documented and made
available for next phase processing.

Problems of Elicitation and Analysis

o Getting all, and only, the right people involved.

o Stakeholders often don't know what they want

o Stakeholders express requirements in their terms.

o Stakeholders may have conflicting requirements.

o Requirement change during the analysis process.

o Organizational and political factors may influence system requirements.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 6

 Software Engineering Notes 2023

3. Software Requirement Specification:

Software requirement specification is a kind of document which is created by a software analyst

after the requirements collected from the various sources - the requirement received by the
customer written in ordinary language. It is the job of the analyst to write the requirement in
technical language so that they can be understood and beneficial by the development team.

The models used at this stage include ER diagrams, data flow diagrams (DFDs), function
decomposition diagrams (FDDs), data dictionaries, etc.

o Data Flow Diagrams:

Data Flow Diagrams (DFDs) are used widely for modeling the requirements. DFD shows the
flow of data through a system. The system may be a company, an organization, a set of
procedures, a computer hardware system, a software system, or any combination of the
preceding. The DFD is also known as a data flow graph or bubble chart.

o Data Dictionaries:

Data Dictionaries are simply repositories to store information about all data items defined in
DFDs. At the requirements stage, the data dictionary should at least define customer data
items, to ensure that the customer and developers use the same definition and terminologies.

o Entity-Relationship Diagrams:

Another tool for requirement specification is the entity-relationship diagram, often called an
"E-R diagram." It is a detailed logical representation of the data for the organization and uses
three main constructs i.e. data entities, relationships, and their associated attributes.

4. Software Requirement Validation:

After requirement specifications developed, the requirements discussed in this document are
validated. The user might demand illegal, impossible solution or experts may misinterpret the
needs. Requirements can be the check against the following conditions -

o If they can practically implement

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 7

 Software Engineering Notes 2023

o If they are correct and as per the functionality and specially of software

o If there are any ambiguities

o If they are full

o If they can describe

Requirements Validation Techniques

o Requirements reviews/inspections: systematic manual analysis of the requirements.

o Prototyping: Using an executable model of the system to check requirements.

o Test-case generation: Developing tests for requirements to check testability.

o Automated consistency analysis: checking for the consistency of structured

requirements descriptions.

Software Requirement Management:

Requirement management is the process of managing changing requirements during the

requirements engineering process and system development. New requirements emerge during the
process as business needs a change, and a better understanding of the system is developed. The
priority of requirements from different viewpoints changes during development process. The
business and technical environment of the system changes during the development.

REQUIREMENT ELICITATION TECHNIQUES

Requirements Elicitation is the process to find out the requirements for an intended software
system by communicating with client, end users, system users and others who have a stake in the
software system development. There are various ways to discover requirements

Interviews

Interviews are strong medium to collect requirements. Organization may conduct several types
of interviews such as:

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 8

 Software Engineering Notes 2023

 Structured (closed) interviews, where every single information to gather is decided in

advance, they follow pattern and matter of discussion firmly.

 Non-structured (open) interviews, where information to gather is not decided in advance,

more flexible and less biased.

 Oral interviews

 Written interviews

 One-to-one interviews which are held between two persons across the table.

 Group interviews which are held between groups of participants. They help to uncover
any missing requirement as numerous people are involved.

Surveys

Organization may conduct surveys among various stakeholders by querying about their
expectation and requirements from the upcoming system.

Questionnaires

A document with pre-defined set of objective questions and respective options is handed over to
all stakeholders to answer, which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is not mentioned in the
questionnaire, the issue might be left unattended.

Task analysis

Team of engineers and developers may analyze the operation for which the new system is
required. If the client already has some software to perform certain operation, it is studied and
requirements of proposed system are collected.

Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a great
help to analyze general and specific requirements.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 9

 Software Engineering Notes 2023

Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for
further requirements analysis.

Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret the
features of intended software product. It helps giving better idea of requirements. If there is no
software installed at client’s end for developer’s reference and the client is not aware of its own
requirements, the developer creates a prototype based on initially mentioned requirements. The
prototype is shown to the client and the feedback is noted. The client feedback serves as an input
for requirement gathering.

Observation

Team of experts visit the client’s organization or workplace. They observe the actual working of
the existing installed systems. They observe the workflow at client’s end and how execution
problems are dealt. The team itself draws some conclusions which aid to form requirements
expected from the software.

SOFTWARE REQUIREMENTS CHARACTERISTICS

Gathering software requirements is the foundation of the entire software development project.
Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

 Clear

 Correct

 Consistent

 Coherent

 Comprehensible

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 10

 Software Engineering Notes 2023

 Modifiable

 Verifiable

 Prioritized

 Unambiguous

 Traceable

 Credible source

Advantages of Requirement Engineering

The advantages of using requirements engineering are:

 Helps ensure that the software being developed meets the needs and expectations of the
stakeholders

 Can help identify potential issues or problems early in the development process, allowing for
adjustments to be made before significant

 Helps ensure that the software is developed in a cost-effective and efficient manner

 Can improve communication and collaboration between the development team and
stakeholders

 Helps to ensure that the software system meets the needs of all stakeholders.

 Provides a clear and unambiguous description of the requirements, which helps to reduce
misunderstandings and errors.

 Helps to identify potential conflicts and contradictions in the requirements, which can be
resolved before the software development process begins.

 Helps to ensure that the software system is delivered on time, within budget, and to the
required quality standards.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 11

 Software Engineering Notes 2023

 Provides a solid foundation for the development process, which helps to reduce the risk of
failure.

Disadvantages of Requirement Engineering

 Can be time-consuming and costly, particularly if the requirements gathering process is not
well-managed

 Can be difficult to ensure that all stakeholders’ needs and expectations are taken into account

 Can be challenging to ensure that the requirements are clear, consistent, and complete

 Changes in requirements can lead to delays and increased costs in the development process.

 As a best practice, Requirements engineering should be flexible, adaptable, and should be

aligned with the overall project goals.

 It can be time-consuming and expensive, especially if the requirements are complex.

 It can be difficult to elicit requirements from stakeholders who have different needs and
priorities.

 Requirements may change over time, which can result in delays and additional costs.

 There may be conflicts between stakeholders, which can be difficult to resolve.

 It may be challenging to ensure that all stakeholders understand and agree on the
requirements.

CLASSIFICATION OR TYPES OF SOFTWARE REQUIREMENTS

Software requirements are a way to identify and clarify the why, what and how of a business's
application. When documented properly, software requirements form a roadmap that leads a
development team to build the right product quickly and with minimal costly rework. The actual
types of software requirements and documents an IT organization produces for a given project
depend on the audience and the maturity of the project. In fact, organizations often draft several
requirements documents, each to suit the specific needs of business leaders, project managers
and application developers.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 12

 Software Engineering Notes 2023

Let's start with a look at several different types of requirements in software engineering

Business requirements

Business needs drive many software projects. A business requirements document (BRD)
outlines measurable project goals for the business, users and other stakeholders. Business
analysts, leaders and other project sponsors create the BRD at the start of the project. This
document defines the why behind the build. For software development contractors, the BRD also
serves as the basis for more detailed document preparation with clients.

Organizations prepare a BRD as a foundation for subsequent, more detailed requirements

documents. Ensure that the BRD reflects a complete set of practical and measurable goals and
meets customer expectations.

Finally, the BRD should be a living document. Evaluate any future requirements, updates
or changes to the project against the BRD to ensure that the organization's goals are still met.

User requirements

User requirements reflect the specific needs or expectations of the software's customers.
Organizations sometimes incorporate these requirements into a BRD, but an application that
poses extensive user functionality or complex UI issues might justify a separate document
specific to the needs of the intended user. User requirements much like user stories highlight the
ways in which customers interact with software.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 13

 Software Engineering Notes 2023

Software requirements

After the BRD outlines the business goals and benefits of a project, the team should devise a
software requirements specification (SRS) that identifies the specific features, functions,
nonfunctional requirements and requisite use cases for the software. Essentially, the SRS details
what the software will do, and it expands upon or translates the BRD into features and functions
that developers understand.

Software requirements typically break down into:

 functional requirements

 nonfunctional requirements

 domain requirements

Functional requirements.

Functional requirements are statements or goals used to define system behavior. Functional
requirements define what a software system must do or not do. They are typically expressed as
responses to inputs or conditions.

Functional requirements may detail specific types of data inputs such as names, addresses,
dimensions and distances. These requirements often include an array of calculations vital to the
software working correctly.

For example, in a hospital management system, a doctor should be able to retrieve the
information of his patients. Each high-level functional requirement may involve several
interactions or dialogues between the system and the outside world. In order to accurately
describe the functional requirements, all scenarios must be enumerated.

There are many ways of expressing functional requirements e.g., natural language, a structured
or formatted language with no rigorous syntax and formal specification language with proper
syntax. Functional Requirements in Software Engineering are also called Functional
Specification.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 14

 Software Engineering Notes 2023

Non-functional requirements (NFRs)

Nonfunctional requirements relate to software usability. Nonfunctional software requirements

define how the system must operate or perform. A system can meet its functional requirements
and fail to meet its nonfunctional requirements.

These are basically the quality constraints that the system must satisfy according to the project
contract. Nonfunctional requirements, not related to the system functionality, rather define how
the system should perform The priority or extent to which these factors are implemented varies
from one project to other. They are also called non-behavioral requirements. They basically deal
with issues like:

 Portability
 Security
 Maintainability
 Reliability

 Scalability
 Performance
 Reusability
 Flexibility

Domain requirements.

Domain requirements are expectations related to a particular type of software, purpose or

industry vertical. Domain requirements can be functional or nonfunctional. The common factor
for domain requirements is that they meet established standards or widely accepted feature sets
for that category of software project.

The basic functions that a system of a specific domain must necessarily exhibit come under this
category. For instance, in an academic software that maintains records of a school or college, the
functionality of being able to access the list of faculty and list of students of each grade is a
domain requirement. These requirements are therefore identified from that domain model and are
not user specific.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 15

 Software Engineering Notes 2023

Domain requirements typically arise in military, medical and financial industry sectors, among
others. Software can be functional and usable but not acceptable for production because it fails
to meet domain requirements.

FUNDAMENTAL PROBLEM IN DEFINING REQUIREMENTS

1. Understanding large and complex system requirements is difficult:

The word ‘large’ represents 2 aspects:

 (i) Large constraints in terms of security, etc. due to a large number of users.

 (ii) a Large number of functions to be implemented.

2. Undefined system boundaries:

There might be no defined set of implementation requirements. The customer may go on to

include several unrelated and unnecessary functions besides the important ones, resulting in
an extremely large implementation cost that may exceed the decided budget.

3. Customers/Stakeholders are not clear about their needs:

Sometimes, the customers themselves may be unsure about the exhaustive list of
functionalities they wish to see in the software. This might happen when they have a very
basic idea about their needs but haven’t planned much about the implementation part.

4. Conflicting requirements are there:

There is a possibility that two different stakeholders of the project express demands which
contradict each other’s implementation. Also, a single stakeholder might also sometimes
express two incompatible requirements.

5. Changing requirements is another issue:

In the case of successive interviews or reviews from the customer, there is a possibility that
the customer expresses a change in the initial set of specified requirements. While it is easy
to accommodate some of the requirements, it is often difficult to deal with such changing
requirements.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 16

 Software Engineering Notes 2023

6. Partitioning the system suitably to reduce complexity:

The projects can sometimes be broken down into small modules or functionalities which are
then handled by separate teams. Often, more complex and large projects require more
partitioning. It needs to be ensured that the partitions are non-overlapping and independent of
each other.

7. Validating and Tracing requirements:

Cross-checking the listed requirements before starting the implementation part is very
important. Also, there should be forward as well as backward traceability. For eg, all the
entity names should be the same everywhere, i.e., there shouldn’t be a case where
‘STUDENT’ and ‘STUDENTS’ are used at separate places to refer to the same entity.

8. Identifying critical requirements:

Identifying the set of requirements that have to be implemented at any cost is very important.
The requirements should be prioritized so that crucial ones can be implemented first with the
highest priority.

9. Resolving the “to be determined” part of the requirements:

The TBD set of requirements include those requirements which are yet to be resolved in the
future. The number of such requirements should be kept as low as possible.

10. Proper documentation, proper meeting time, and budget constraints –

Ensuring proper documentation is an inherent challenge, especially in the case of changing

requirements. The time and budget constraints too need to be handled carefully and
systematically.

SOFTWARE REQUIREMENTS SPECIFICATIONS (SRS)

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

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 17

 Software Engineering Notes 2023

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.

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.

SRS TEMPLATE

Software Requirement Specification (SRS) Template as name suggests, is complete

specification and description of requirements of software that needs to be fulfilled for successful
development of software system. These requirements can be functional as well as non-functional
depending upon type of requirement. The interaction between different customers and contractor
is done because it's necessary to fully understand needs of customers.

Depending upon information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is needed to be done
to increase quality of product and to satisfy customer’s demand.

1. Introduction :

(i) Purpose of this Document – At first, main aim of why this document is necessary and
what’s purpose of document is explained and described.

(ii) Scope of this document – In this, overall working and main objective of document and
what value it will provide to customer is described and explained. It also includes a
description of development cost and time required.

(iii) Overview – In this, description of product is explained. It’s simply summary or overall
review of product.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 18

 Software Engineering Notes 2023

2. General description :

In this, general functions of product which includes objective of user, a user characteristic,
features, benefits, about why its importance is mentioned. It also describes features of user
community.

3. Functional Requirements :

In this, possible outcome of software system which includes effects due to operation of
program is fully explained. All functional requirements which may include calculations, data
processing, etc. are placed in a ranked order.

4. Interface Requirements :

In this, software interfaces which mean how software program communicates with each other
or users either in form of any language, code, or message are fully described and explained.
Examples can be shared memory, data streams, etc.

5. Performance Requirements :

In this, how a software system performs desired functions under specific condition is
explained. It also explains required time, required memory, maximum error rate, etc.

6. Design Constraints :

In this, constraints which simply means limitation or restriction are specified and explained
for design team. Examples may include use of a particular algorithm, hardware and software
limitations, etc.

7. Non-Functional Attributes :

In this, non-functional attributes are explained that are required by software system for better
performance. An example may include Security, Portability, Reliability, Reusability,
Application compatibility, Data integrity, Scalability capacity, etc.

8. Preliminary Schedule and Budget :

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 19

 Software Engineering Notes 2023

In this, initial version and budget of project plan are explained which include overall time
duration required and overall cost required for development of project.

9. Appendices :

In this, additional information like references from where information is gathered, definitions
of some specific terms, acronyms, abbreviations, etc. are given and explained.

Uses of SRS document:

1. Development team require it for developing product according to the need.

2. Test plans are generated by testing group based on the describe external behavior.

3. Maintenance and support staff need it to understand what the software product is supposed to
do.

4. Project manager base their plans and estimates of schedule, effort and resources on it.

5. customer rely on it to know that product they can expect.

6. As a contract between developer and customer.

7. in documentation purpose.

Characteristics of good SRS

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.

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.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 20

 Software Engineering Notes 2023

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

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.

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.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 21

 Software Engineering Notes 2023

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.

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.

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.

SOFTWARE DESIGN CONCEPTS

Once the requirements document for the software to be developed is available, the software
design phase begins. While the requirement specification activity deals entirely with the problem
domain, design is the first phase of transforming the problem into a solution. In the design phase,
the customer and business requirements and technical considerations all come together to
formulate a product or a system.

The design process comprises a set of principles, concepts and practices, which allow a software
engineer to model the system or product that is to be built. This model, known as design model,

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 22

 Software Engineering Notes 2023

is assessed for quality and reviewed before a code is generated and tests are conducted. The
design model provides details about software data structures, architecture, interfaces and
components which are required to implement the system. This chapter discusses the design
elements that are required to develop a software design model. It also discusses the design
patterns and various software design notations used to represent a software design.

Principles of Software Design

Some of the commonly followed design principles are as following.

Software design should correspond to the analysis model:

Often a design element corresponds to many requirements, therefore, we must know how the
design model satisfies all the requirements represented by the analysis model.

Choose the right programming paradigm:

A programming paradigm describes the structure of the software system. Depending on the
nature and type of application, different programming paradigms such as procedure oriented,
object-oriented, and prototyping paradigms can be used. The paradigm should be chosen keeping
constraints in mind such as time, availability of resources and nature of user’s requirements.

Software design should be uniform and integrated:

Software design is considered uniform and integrated, if the interfaces are properly defined
among the design components. For this, rules, format, and styles are established before the
design team starts designing the software.

Software design should be flexible:

Software design should be flexible enough to adapt changes easily. To achieve the flexibility, the
basic design concepts such as abstraction, refinement, and modularity should be applied
effectively.

Software design should ensure minimal conceptual (semantic) errors:

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 23

 Software Engineering Notes 2023

The design team must ensure that major conceptual errors of design such as ambiguousness and
inconsistency are addressed in advance before dealing with the syntactical errors present in the
design model.

Software design should be structured to degrade gently:

Software should be designed to handle unusual changes and circumstances, and if the need arises
for termination, it must do so in a proper manner so that functionality of the software is not
affected.

Software design should represent correspondence between the software and real-world
problem:

The software design should be structured in such a way that it always relates with the real-world
problem.

Software reuse:

Software engineers believe on the phrase: ‘do not reinvent the wheel’. Therefore, software
components should be designed in such a way that they can be effectively reused to increase the
productivity.

Designing for testability:

A common practice that has been followed is to keep the testing phase separate from the design
and implementation phases. That is, first the software is developed (designed and implemented)
and then handed over to the testers who subsequently determine whether the software is fit for
distribution and subsequent use by the customer. However, it has become apparent that the
process of separating testing is seriously flawed, as if any type of design or implementation
errors are found after implementation, then the entire or a substantial part of the software
requires to be redone. Thus, the test engineers should be involved from the initial stages. For
example, they should be involved with analysts to prepare tests for determining whether the user
requirements are being met.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 24

 Software Engineering Notes 2023

Prototyping:

Prototyping should be used when the requirements are not completely defined in the beginning.
The user interacts with the developer to expand and refine the requirements as the development
proceeds. Using prototyping, a quick ‘mock-up’ of the system can be developed. Prototyping
also helps in reducing risks of designing software that is not in accordance with the customer’s
requirements.

SOFTWARE DESIGN CONCEPTS

Every software process is characterized by basic concepts along with certain practices or
methods. Methods represent the manner through which the concepts are applied. As new
technology replaces older technology, many changes occur in the methods that are used to apply
the concepts for the development of software. However, the fundamental concepts underlining
the software design process remain the same, some of which are described here.

Abstraction

Abstraction refers to a powerful design tool, which allows software designers to consider
components at an abstract level, while neglecting the implementation details of the components.
The concept of abstraction can be used in two ways: as a process and as an entity. As
a process, it refers to a mechanism of hiding irrelevant details and representing only the essential
features of an item so that one can focus on important things at a time. As an entity, it refers to a
model or view of an item.

For example, in the requirements analysis phase, a solution to the problem is presented using the
language of problem environment and as we proceed through the software process, the
abstraction level reduces and at the lowest level, source code of the software is produced.

Architecture

Software architecture refers to the structure of the system, which is composed of various
components of a program/ system, the attributes (properties) of those components and the
relationship amongst them. The software architecture enables the software engineers to analyze

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 25

 Software Engineering Notes 2023

the software design efficiently. In addition, it also helps them in decision-making and handling
risks. The software architecture does the following.

 Provides an insight to all the interested stakeholders that enable them to communicate
with each other

 Highlights early design decisions, which have great impact on the software engineering
activities (like coding and testing) that follow the design phase

 Creates intellectual models of how the system is organized into components and how
these components interact with each other.

Patterns

A pattern provides a description of the solution to a recurring design problem of some specific
domain in such a way that the solution can be used again and again. The objective of each
pattern is to provide an insight to a designer who can determine the following.

 Whether the pattern can be reused

 Whether the pattern is applicable to the current project

 Whether the pattern can be used to develop a similar but functionally or structurally
different design pattern.

Modularity

Modularity is achieved by dividing the software into uniquely named and addressable
components, which are also known as modules. A complex system (large program) is partitioned
into a set of discrete modules in such a way that each module can be developed independent of
other modules. After developing the modules, they are integrated together to meet the software
requirements.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 26

 Software Engineering Notes 2023

Modularizing a design helps to plan the development in a more effective manner, accommodate
changes easily, conduct testing and debugging effectively and efficiently, and conduct
maintenance work without adversely affecting the functioning of the software.

Information Hiding

Modules should be specified and designed in such a way that the data structures and processing
details of one module are not accessible to other modules. They pass only that much information
to each other, which is required to accomplish the software functions. The way of hiding
unnecessary details is referred to as information hiding. IEEE defines information hiding as
‘the technique of encapsulating software design decisions in modules in such a way that the
module’s interfaces reveal as little as possible about the module’s inner workings; thus each
module is a ‘black box’ to the other modules in the system.

Stepwise Refinement

Stepwise refinement is a top-down design strategy used for decomposing a system from a high
level of abstraction into a more detailed level (lower level) of abstraction. At the highest level of
abstraction, function or information is defined conceptually without providing any information
about the internal workings of the function or internal structure of the data. As we proceed
towards the lower levels of abstraction, more and more details are available.

Software designers start the stepwise refinement process by creating a sequence of compositions
for the system being designed. Each composition is more detailed than the previous one and

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 27

 Software Engineering Notes 2023

contains more components and interactions. The earlier compositions represent the significant
interactions within the system, while the later compositions show in detail how these interactions
are achieved.

Refactoring

Refactoring is an important design activity that reduces the complexity of module design keeping
its behaviour or function unchanged. Refactoring can be defined as a process of modifying a
software system to improve the internal structure of design without changing its external
behavior. During the refactoring process, the existing design is checked for any type of flaws like
redundancy, poorly constructed algorithms and data structures, etc., in order to improve the
design. For example, a design model might yield a component which exhibits low cohesion (like
a component performs four functions that have a limited relationship with one another). Software
designers may decide to refactor the component into four different components, each exhibiting
high cohesion. This leads to easier integration, testing, and maintenance of the software
components

Functional Independence

The functional independence is the concept of separation and related to the concept of
modularity, abstraction and information hiding. The functional independence is accessed using
two criteria i.e Cohesion and coupling.

Cohesion: Cohesion is an extension of the information hiding concept. A cohesive module

performs a single task and it requires a small interaction with the other components in other parts
of the program.

Coupling: Coupling is an indication of interconnection between modules in a structure of

software.

Dr. Tejashree Tejpal Moharekar ( MCA, NET, Ph. D ) Page 28