SOFTWARE ENGINEERING

MODULE – III
Software Requirements Specification: SRS Documents, their Characteristics and Organization.
Software Design: Classification, Software Design Approaches, Function Oriented Software
Design.
Structured Analysis: Data Flow Diagrams and Entity Relationship Model, Introduction to Object
Oriented Design.

Software Requirements Specification

A Software Requirements Specification (SRS) is a document that describes the nature of a project, software or
application. In simple words, an SRS document is a manual of a project provided it is prepared before you kick-
start a project/application. This document is also known by the names SRS report, SRS document or software
document. A software document is primarily prepared for a project, software, or any kind of application.

SRS DOCUMENT

An SRS document is,

 a detailed specification and description of software requirements that must be met for a software
system to be successfully developed.

 a formal report that serves as a representation of software, allowing consumers to determine whether
it meets their needs.

 a document that includes system user needs as well as thorough system requirements specifications.

Characteristics of A Good SRS

Since the SRS document is very crucial for software development, it is typically expected to be:

 Correct

User review is done to check that the requirements listed in the SRS are proper. SRS is correct if it meets all
of the system's requirements.

 Unambiguous

The SRS is considered unambiguous or precise if all requirements have only one interpretation. Some
methods for avoiding ambiguity incorporate the use of modeling approaches such as ER diagrams,
thorough reviews and buddy checks, and so on.

 Complete

P a g e 1 | 19
 SOFTWARE ENGINEERING
The SRS is complete if it has the following components:

1. All fundamental requirements (regardless of whether they are related to functionality, performance,
design, restrictions, characteristics, or external interfaces)

2. Definition of the software's reactions to all realizable input data classes in all possible scenario
categories.

3. Complete labeling and references to all figures, tables, and diagrams in the SRS, as well as definitions of
all terms and units of measurement.

 Consistent

The SRS is said to be consistent if no subset of the requirements has a conflict. There can be three kinds of
conflicts in an SRS:

1. The properties of real-world objects may clash. For example, One condition may require that a particular
value be less than 100, while another requires greater than 150.

2. A reasonable or temporal conflict may exist between the two indicated actions. For example,

o one requirement may need that the software adds A and B, while another may require that it
concatenates them.

o one condition may require that A always come after B, while another needs that A and B co-
occur.

3. Two or more requirements may define the same real-world object but refer to it differently. Consistency
is promoted by the use of uniform terminology and descriptions.

 Ranked for importance and/or stability

The SRS should be ranked for importance and stability. This can be done by associating an identifier to each
requirement, indicating its relevance or stability. In most cases, not all requirements are equally critical. For
example, some prerequisites, particularly for life-critical applications, may be required, while others may be
just desirable. To make these distinctions plain and explicit, each element should be identified. Another
method for ranking needs is to categorize elements as essential, conditional, or optional. Every requirement
is crucial; however, some are urgent and must be met before other criteria, while others may be delayed.

 Verifiable

We should be able to verify the specified requirements with a cost-effective approach to check whether the
final software meets those requirements. The requirements are verified with the help of software reviews.

 Modifiable/Adaptable

SRS should be made as adaptable as possible, with the ability to make changes to the system fast. In
addition, changes should be fully indexed and cross-referenced.

 Traceable

P a g e 2 | 19
 SOFTWARE ENGINEERING
The SRS is traceable if the origin of each requirement is clear and if it facilitates the referencing of each
condition in the future. Traceability is classified into two types:

o Backward Traceability: This is contingent on each need explicitly citing its source in previous
publications.

o Forward Traceability: This depends on each SRS element having a unique name or reference
number. When the software product enters the operation and maintenance phase, forward
traceability of the SRS becomes especially important. As the code and design documents are
changed, it is vital to determine the entire range of requirements that may be affected by those
changes.

 Design Independent

The final system should include the option of selecting from numerous design possibilities. More
particularly, no implementation details should be included in the SRS.

 Testable

An SRS document should be constructed so that it is simple to build test cases and test plans.

 Abstract to the Right Level

The details should be explained explicitly if the SRS is written for the requirements phase. A feasibility study,
on the other hand, can employ fewer details. As a result, the level of abstraction varies depending on the
SRS's objective.

 Customer-friendly

An end user may not be an expert in software engineering. As a result, formal notations and symbols should
be avoided as far as possible and practicable. Instead, the language should be simple and straightforward.

Types of Requirements in SRS

 Functional Requirements

This section clearly explains the functioning of a software system, covering all possible behavior. All
functional requirements, which involve calculations, data processing, and so on, are listed according to their
priorities.

 Performance Requirements

This section explains how a software system should perform on certain performance parameters while
performing the required operations under specified conditions. It also describes the required time, memory,
maximum error rate, etc.

 Interface Requirements

P a g e 3 | 19
 SOFTWARE ENGINEERING
Software interfaces are fully described and discussed in this section, which means how software programs
communicate with one another or users in the form of any language, code, or message. Examples include
shared memory, data streams, and so on.

 Non-Functional Requirements

They describe the general properties of a system, also known as quality attributes. They include Security,
Safety, Portability, Reliability, Reusability, Application compatibility, Data integrity, Scalability, resource
requirements, and other quality attributes.

SRS Document Organization or Template

The following is a simple SRS template:

P a g e 4 | 19
 SOFTWARE ENGINEERING

Software Design

Software design is a method that converts user requirements into a suitable form for the programmer to
employ in software coding and implementation. It is concerned with converting the client's requirements as
defined in the Software Requirement Specification (SRS) document into a form that can be easily implemented
using a programming language. A good software designer needs to have knowledge of what software
engineering is.

The software design phase is the first step in the Software Development Life Cycle (SDLC) that shifts the focus
from the problem domain to the solution domain. In software design, the system is viewed as a collection of
components or modules with clearly defined behaviors and bounds.

Levels of Software Design

There are three levels of software design.

Architectural Design

A system's architecture can be defined as the system's overall structure and how that structure offers
conceptual integrity to the system. The architectural design characterizes the software as a system with
numerous interconnected components. The designers acquire an overview of the proposed solution domain at
this level.

High-level Design

P a g e 5 | 19
 SOFTWARE ENGINEERING
The high-level design deconstructs the architectural design's 'single entity-multiple component' notion into a
less abstract perspective of subsystems and modules, depicting their interaction with one another. High-level
design is concerned with how the system and its components can be implemented as modules. It recognizes
the modular structure of each subsystem, as well as their relationship and interaction with one another.

Detailed Design

After the high-level design is completed, the detailed design begins. Each module is extensively investigated at
this level of software design to establish the data structures and algorithms to be used. Finally, a module
specification document is used to document the stage's outcome. It defines the logical structure of each
module as well as its interfaces with other modules.

Software Design Strategies

The process of conceptualizing software requirements into actual software execution is known as software
design. The user needs are viewed as tasks in software design, and the best solution is sought after. A strategy
is laid out to determine the optimum design for achieving the required solution while the software is
conceptualized. The software design process can be viewed as a series of well-defined steps.

There are many strategies or techniques for performing system design.

Structured Design

Structured design is primarily about breaking problems down into several well-organised components. The
benefit of utilizing this design technique is that it simplifies difficulties. This allows for the minor pieces to be
problem-solved so they can fit into the larger image. The solution components are organized hierarchically.

Structured design is primarily based on the divide and conquer technique, in which a large problem is divided
into smaller ones, each of which is tackled independently until the larger problem is solved. Solution modules
are used to address the individual problems. The structured design stresses the importance of these modules'
organization to produce exact results. A good structured design has high cohesion and low coupling
arrangements.

Function Oriented Design

Function-oriented design is related to structured design in that it splits the entire system into subsystems
known as functions. The system is viewed as a map or top-down perspective of all the bundled functions.
However, when compared to structured design, there is more information travelling between the functions,
whilst the smaller functions promote abstraction. The software can also work on input rather than state thanks
to the function-oriented design.

Object Oriented Design

This design approach differs from the other two in that it focuses on objects and classes. This technique is
centred on the system's objects and their attributes. Furthermore, the characteristics of all these objects'
attributes are encapsulated together, and the data involved is constrained so that polymorphism can be
enabled. Object-oriented design is centered on recognizing objects and categorizing them based on their
attributes. The class hierarchy is then established, and the relationships between these classes are defined.

P a g e 6 | 19
 SOFTWARE ENGINEERING

The object-oriented design technique is considered superior to the function-oriented design approach because
real-world entities may be easily incorporated in the computer world. This method also allows for the
implementation of several very basic object behaviors like as polymorphism, inheritance, abstraction, and
encapsulation.

Software Design Approaches

Top Down Approach

This design technique is entirely focused on first subdividing the system into subsystems and components.
Rather to constructing from the bottom up, the top-down approach conceptualizes the entire system first and
then divides it into multiple subsystems. These subsystems are then designed and separated into smaller
subsystems and sets of components that meet the larger system's requirements. Instead of defining these
subsystems as discrete entities, this method considers the entire system to be a single entity. When the system
is finally defined and divided based on its features, the subsystems are considered separate entities. The
components are then organised in a hierarchical framework until the system's lowest level is designed.

P a g e 7 | 19
 SOFTWARE ENGINEERING

Bottom-Up Approach

This system design technique prioritises the design of subsystems and the lowest-level components (even sub-
components). Higher-level subsystems and larger components can be produced more readily and efficiently if
these components are designed beforehand. This reduces the amount of time spent on recon and
troubleshooting. The process of assembling lower-level components into larger sets is repeated until the entire
system is composed of a single component. This design technique also makes generic solutions and low-level
implementations more reusable.

Structured Analysis

DATA FLOW DIAGRAM (DFD)

An Overview

A Data Flow Diagram (DFD) shows the flow of data through the components of any system. Using symbols like
rectangles, circles, and arrows, as well as brief text labels, it displays data inputs, outputs, storage locations,
and the routes between each destination. Data flow diagrams can range from straightforward, even hand-
drawn, process summaries to intricate, multi-level DFDs that go in-depth. They can be utilized to model a new
software system or to imitate an existing one. Like other diagrams, they can visually "convey" concepts that
are challenging to explain verbally. They can be understood by both technical and laymen easily.

Definition

A Data Flow Diagram (DFD) is a classic visual representation of a system's information flows. It can be manual,
automatic, or a hybrid of the two. It demonstrates how data enters and exits the system, what alters the data,
and where data is stored. A DFD's goal is to represent the breadth and bounds of a system as a whole. It can be
used as a method of communication between a system analyst and developers. The data flow diagram (DFD) is
also known as a data flow graph or bubble chart.

Components of Data Flow Diagrams

The Data Flow Diagram has four components:

Process

P a g e 8 | 19
 SOFTWARE ENGINEERING
In a system, input-to-output transformation occurs as a result of process function. A process sign might be
rectangular with rounded corners, oval, rectangle, or circle. The process is expressed in one word or phrase.

Data Flow

Data flow describes the transport of information between different elements of a system. The arrow symbol
represents data flow. The flow should be given a related name to determine the information being moved. Data
flow also symbolizes the movement of material as well as information. Material shifts are represented in
systems that are more than just instructive. A given flow should only transfer one sort of data. The flow can
also be bi-directional.

Warehouse

The information is saved in the warehouse for future use. The store's symbol is represented by two horizontal
lines. The warehouse is not limited to a data file; it may be anything from a folder containing documents to an
optical disc or a filing cabinet. The data warehouse can be examined regardless of how it is implemented. When
data flows from the warehouse, it is referred to as data reading; when data flows to the warehouse, it is referred
to as data input or data updation.

Terminator

The Terminator is an external entity that communicates with the system from outside the system. It can be
businesses such as banks, groups of individuals such as consumers, or distinct departments of the same firm
that are not part of the model system and are external entities.

Rules for Creating Data Flow Diagrams

 The entity's name should be simple and understandable without any additional explanation, like
comments.
 The processes should be numbered or organized into a list so they may be easily referred to.
 The DFD should be consistent across all DFD levels.
 A single DFD can have a maximum of nine processes and a minimum of three.

Levels of Data Flow Diagrams

In software engineering, DFDs (data flow diagrams) can be used to illustrate systems at various degrees of
abstraction. Higher-level DFDs are subdivided into lower-level DFDs containing additional information and
functional features. DFD levels are numbered 0, 1, 2, and higher.

0-Level DFD

It's also referred to as a context diagram. It is intended to be an abstract view, depicting the system as a single
process with external elements. It represents the complete system as a single bubble with incoming and
outgoing arrows indicating input and output data. Here's an example of a 0-level DFD.

P a g e 9 | 19
 SOFTWARE ENGINEERING

1-Level DFD

In 1-level DFD, the context diagram is broken down into many bubbles and processes. At this level, we highlight
the system's essential functions and divide the high-level process of 0-level DFD into subprocesses. Here's an
example of a 1-level DFD.

2-Level DFD

2-level DFD delves deeper into aspects of 1-level DFD. It can be used to design or record specific/necessary
details about how the system works. Here's an example of a 2-level DFD.

P a g e 10 | 19
 SOFTWARE ENGINEERING

Advantages of Data Flow Diagrams

 It assists us in comprehending the operation and limitations of a system.

 It is a graphical representation that aids in the visualization of information.
 Data Flow Diagrams are thorough diagrams of system components that are adequately explained.
 It is part of the system documentation file.
 Because they are simple to grasp, Data Flow Diagrams can be understood by both technical and non-
technical people.

Disadvantages of Data Flow Diagrams

 DFD can occasionally confuse programmers about the system.

 Data Flow Diagrams take a long time to construct, so analysts are frequently refused to work on them.

P a g e 11 | 19
 SOFTWARE ENGINEERING

ENTITY-RELATIONSHIP (ER) DIAGRAM / ENTITY-RELATIONSHIP (ER) MODEL

The ER diagram was proposed by Peter Chen in 1971 as a visual tool to represent the ER model. He wanted to
use the ER model as a conceptual modeling approach for Database Management System (DBMS). ER model is
a high-level data model used to represent a logical view of the system from a data perspective. Creating an ER
Model is considered a best practice before implementing the database because it makes it easier for the
developers to understand the database system. It develops a conceptual design for a database that provides a
very simple and straightforward view of the data.

ER model makes use of ER diagrams, which are the diagrams sketched to design a database. ER diagrams are
built on three basic concepts: entities, attributes, and relationships between them.

Let's consider the need to design a database for a school. In this database, a student is
an entity with attributes such as an address, name, id, age, grades, etc.

The address can be another entity with attributes like city, street name, pin code, etc and there will be a
relationship between them.

In the upcoming sections, we will see what is er model in DBMS and what are different components of an ER
diagram are.

P a g e 12 | 19
 SOFTWARE ENGINEERING

Components of ER Diagram

The ER diagram consists of three basic concepts:

 Entities
 Attributes
 Relationships

Entity
An entity is anything in the real world, such as an object, class, person, or place. Objects that physically exist
and are logically constructed in the real world are called entities. Each entity consists of several characteristics
or attributes that describe that entity. For example, if a person is an entity, its attributes or characteristics are
age, name, height, weight, occupation, address, hobbies, and so on. Read this article to learn more about Entity
in DBMS.

Entity set: is a group of entities of similar kinds. It can contain entities with attributes that share similar values.
It's collectively a group of entities of a similar type. For example, a car entity set, an animal entity set, a bank
account entity set, and so on.

Entity types: are the basic building blocks for describing the structure of data. It's a category of a
particular entity in an entity set. In summary, an Entity is an object of a Type Entity and the set of all entities is
called an entity set.

Entities are of two types:

P a g e 13 | 19
 SOFTWARE ENGINEERING
1. Strong Entity – A strong entity is an entity type that has a key attribute. It doesn't depend on
other entities in the schema. A strong entity always has a primary key, and it is represented by a single
rectangle in the ER diagram.

Example – roll_number identifies each student of the organization uniquely and hence, we can say that
the student is a strong entity type.

2. Weak Entity – Weak entity type doesn’t have a key attribute and so we cannot uniquely identify them
by their attributes alone. Therefore, a foreign key must be used in combination with its attributes to
create a primary key. They are called Weak entity types because they can’t be identified on their own.
It relies on another powerful entity for its unique identity. A weak entity is represented by a double-
outlined rectangle in ER diagrams.

For example, the address can't be used to uniquely identify students as there can be many students from the
same locality. So, for this, we need an attribute of Strong Entity Type i.e 'student' to uniquely
identify entities of Address Entity Type.

The relationship between a weak entity type and a strong entity type is shown with a double-outlined diamond
instead of a single-outlined diamond. This representation can be seen in the image given below.

Each entity in the set of strong entities can be uniquely identified because it has a primary key, whereas
identifying each entity in a set of weak entities is not possible. After all, it has no primary key and it may contain
redundant entities.

Attribute
Attributes are the characteristics or properties which define the entity type. In ER diagram, the attribute is
represented by an oval.

For example, here id, Name, Age, and Mobile_No are the attributes that define the entity type Student.

There are five types of attributes:

1. Simple attribute: Attributes that cannot be further decomposed into sub-attributes are called simple
attributes. It's an atomic value and is also known as the key attribute. The simple attributes are
represented by an oval shape in ER diagrams with the attribute name underlined.

P a g e 14 | 19
 SOFTWARE ENGINEERING
For example, the roll number of a student, or the student's contact number are examples of simple
attributes.

As you can see from the above image, the attributes id is represented in the shape of an ellipse along
with having the attribute name underlined.

2. Composite attribute: An attribute that is composed of many other attributes and can be decomposed
into simple attributes is known as a composite attribute in DBMS. The composite attribute is
represented by an ellipse.

For example, a student's address can be divided into city, state, country, and pin code or a full name can
be divided into first name, middle name, and last name.

As we can see from the above images, the composite attribute is divided into multiple simpler
attributes.

3. Multivalued attribute: Multivalued attributes in DBMS are attributes that can have more than one value.
The double oval is used to represent a multivalued attribute.

For example, the mobile_number of a student is a multivalued attribute as one student can have more
than one mobile number.

P a g e 15 | 19
 SOFTWARE ENGINEERING

4. Derived attribute: Derived attributes in DBMS are the ones that can be derived from other attributes of
an entity type. The derived attributes are represented by a dashed oval symbol in the ER diagram.

For example, the age attribute can be derived from the date of birth (DOB) attribute. So, it's a derived
attribute.

The complete student (represented by the rectangle shape) entity type is shown by the below diagram
having different attributes, where address is the composite attribute, age is the derived attribute,
phone number is the multivalued attribute, and roll number is the key attribute.

Relationship
The concept of relationship is used to describe the relationship between different entities. This is denoted by
the diamond or a rhombus symbol. For example, the teacher entity type is related to the student entity type
and their relation is represented by the diamond shape.

There are four types of relationships:

1. One-to-One Relationships: When only one instance of an entity is associated with the relationship to
one instance of another entity, then it is known as one to one relationship. For example, let us assume
that a male can marry one female and a female can marry one male. Therefore the relation is one-to-
one.

P a g e 16 | 19
 SOFTWARE ENGINEERING
2. One-to-Many Relationships: If only one instance of the entity on the left side of the relationship is linked
to multiple instances of the entity on the right side, then this is considered a given one-to-many
relationship. For example, a Scientist can invent many inventions, but the invention is done by only a
specific scientist.

3. Many-to-One Relationships: If only one instance of the entity on the left side of the relationship is linked
to multiple instances of the entity on the right side, then this is considered a given one-to-many
relationship. For example, a Student enrolls for only one course, but a course can have many students.

4. Many to Many Relationships: If multiple instances of the entity on the left are linked by relationships to
multiple instances of the entity on the right, this is considered a many-to-one-relationship means
relationship. For example, one employee can be assigned many projects, and one project can be
assigned by many employees.

Features of ER Diagram
The features of ER Diagram are as follows:

 ER Diagram: ER diagrams are the diagrams that are sketched out to design the database. They are
created based on three basic concepts: entities, attributes, and relationships between them. In ER
diagram we define the entities, their related attributes, and the relationships between them. This helps
in illustrating the logical structure of the databases.

 Database Design: The Entity-Relationship model helps the database designers to build the database in a
very simple and conceptual manner.

 Graphical Representation helps in Better Understanding: ER diagrams are very easy and simple to
understand and so the developers can easily use them to communicate with stakeholders.

 Easy to build: The ER model is very easy to build.

 The extended E-R features: Some of the additional features of ER model are specialization, upper and
lower-level entity sets, attribute inheritance, aggregation, and generalization.

 Integration of ER model: This model can be integrated into a common dominant relational model and is
widely used by database designers for communicating their ideas.

P a g e 17 | 19
 SOFTWARE ENGINEERING
 Simplicity and various applications of ER model: It provides a preview of how all the tables should connect,
and what fields are going to be on each table, which can be used as a blueprint for implementing data in
specific software applications.

INTRODUCTION TO OBJECT-ORIENTED SOFTWARE DESIGN CONCEPTS

Some software design concepts that assist a software engineer in creating the model of the system or software
product to be developed or built are discussed below:

Abstraction

One of the fundamental concepts of object-oriented programming (OOP) languages is an abstraction. Its
primary purpose is to deal with complexity by concealing internal details from the user. This allows the user to
build more complicated logic on top of the offered abstraction without having to understand or even consider
all the hidden complexity.

Modularity

Modularity refers to breaking a system or project into smaller sections to lessen the system's or project's
complexity. Similarly, modularity in design refers to the division of a system into smaller elements that can be
built independently and then used in multiple systems to execute different purposes. Sometimes to deal with
Monolithic software, which is difficult to grasp for software engineers, it is required to partition the software
into components known as modules. As a result, modularity in design has become a trend that is also essential.

Architecture

A system's software architecture represents the design decisions linked to the general structure and behavior
of the system. Architecture assists stakeholders in comprehending and analyzing how the system will attain
critical characteristics such as modifiability, availability, and security. It specifies how components of a
software system are constructed, as well as their relationships and communication. It acts as a software
application blueprint and a development foundation for the developer team.

Refinement

Refinement means removing any impurities and improving the quality of something. The software design
refinement idea is a process of building or presenting the software or system in a detailed manner, which implies
elaborating on a system or software. In addition, refinement is essential for identifying and correcting any
possible errors.

Design Patterns

A Software Design Pattern is a general, reusable solution to a commonly occurring problem within a given
context in software design. They are templates to solve common software engineering problems, representing
some of the finest practices experienced object-oriented software engineers utilize. A design pattern
systematically describes and explains a general design that handles a recurring design challenge in object-
oriented systems. It discusses the problem, the remedy, when to use it, and the repercussions. It also provides
implementation guidance and examples.

P a g e 18 | 19
 SOFTWARE ENGINEERING

Information/Data Hiding

Simply put, information hiding implies concealing information so that an unauthorized entity cannot access it.
In software design, information hiding is accomplished by creating modules in such a way that information
acquired or contained in one module is concealed and cannot be accessible by other modules.

Refactoring

Refactoring is the process of reorganizing code without affecting its original functionality. Refactoring aims to
improve internal code by making modest changes that do not affect the code's exterior behavior. Computer
programmers and software developers refactor code to improve the software's design, structure, and
implementation. As a result, Refactoring increases code readability while decreasing complications. Refactoring
can also assist software engineers in locating faults or vulnerabilities in their code.

---

P a g e 19 | 19