Unit-2

Software Requirement Specification

Software Requirement Specification (SRS)

Format as the name suggests, is a complete specification and description of requirements of the software
that need to be fulfilled for the successful development of the software system. These requirements can be
functional as well as non-functional depending upon the type of requirement. The interaction between
different customers and contractors is done because it is necessary to fully understand the needs of
customers.

 Purpose of this Document – At first, main aim of why this document is necessary and what’s
purpose of document is explained and described.
 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.
 Overview – In this, description of product is explained. It’s simply summary or overall review of
product.

Requirements Engineering Process in Software Engineering

Requirements Engineering is the process of identifying, eliciting, analyzing, specifying, validating, and
managing the needs and expectations of stakeholders for a software system.

A systematic and strict approach to the definition, creation, and verification of requirements for a
software system is known as requirements engineering. To guarantee the effective creation of a software
product, the requirements engineering process entails several tasks that help in understanding, recording,
and managing the demands of stakeholders.

Requirements Elicitation

Requirements elicitation is the process of gathering and defining the requirements for a software system.
The goal of requirements elicitation is to ensure that the software development process is based on a clear
and comprehensive understanding of the customer’s needs and requirements.
The process of investigating and learning about a system’s requirements from users, clients, and other
stakeholders is known as requirements elicitation. Requirements elicitation in software engineering is
perhaps the most difficult, most error-prone, and most communication-intensive software development.

1. Requirement Elicitation can be successful only through an effective customer-developer

partnership. It is needed to know what the users require.
2. Requirements elicitation involves the identification, collection, analysis, and refinement of the
requirements for a software system.
3. Requirement Elicitation is a critical part of the software development life cycle and is typically
performed at the beginning of the project.
4. Requirements elicitation involves stakeholders from different areas of the organization, including
business owners, end-users, and technical experts.
5. The output of the requirements elicitation process is a set of clear, concise, and well-defined
requirements that serve as the basis for the design and development of the software system.
6. Requirements elicitation is difficult because just questioning users and customers about system
needs may not collect all relevant requirements, particularly for safety and dependability.
7. Interviews, surveys, user observation, workshops, brainstorming, use cases, role-playing, and
prototyping are all methods for eliciting requirements.

Feasibility Study

Feasibility Study in Software Engineering is a study to evaluate feasibility of proposed project or system.
Feasibility study is one of stage among important four stages of Software Project Management Process.
As name suggests feasibility study is the feasibility analysis or it is a measure of the software product in
terms of how much beneficial product development will be for the organization in a practical point of
view. Feasibility study is carried out based on many purposes to analyze whether software product will be
right in terms of development, implementation, contribution of project to the organization etc.

Types of Feasibility Study

The feasibility study mainly concentrates on below five mentioned areas. Among these Economic
Feasibility Study is most important part of the feasibility analysis and Legal Feasibility Study is less
considered feasibility analysis.

1. Technical Feasibility: In Technical Feasibility current resources both hardware software along
with required technology are analyzed/assessed to develop project. This technical feasibility
study gives report whether there exists correct required resources and technologies which will be
used for project development. Along with this, feasibility study also analyzes technical skills and
capabilities of technical team, existing technology can be used or not, maintenance and up-
gradation is easy or not for chosen technology etc.

2. Operational Feasibility: In Operational Feasibility degree of providing service to requirements

is analyzed along with how much easy product will be to operate and maintenance after
deployment. Along with this other operational scopes are determining usability of product,
Determining suggested solution by software development team is acceptable or not etc.
 3. Economic Feasibility: In Economic Feasibility study cost and benefit of the project is analyzed.
Means under this feasibility study a detail analysis is carried out what will be cost of the project
for development which includes all required cost for final development like hardware and
software resource required, design and development cost and operational cost and so on. After
that it is analyzed whether project will be beneficial in terms of finance for organization or not.

4. Legal Feasibility: In Legal Feasibility study project is analyzed in legality point of view. This
includes analyzing barriers of legal implementation of project, data protection acts or social
media laws, project certificate, license, copyright etc. Overall it can be said that Legal Feasibility
Study is study to know if proposed project conform legal and ethical requirements.

5. Schedule Feasibility: In Schedule Feasibility Study mainly timelines/deadlines is analyzed for

proposed project which includes how much time teams will take to complete final project which
has a great impact on the organization as purpose of project may fail if it can’t be completed on
time.

6. Cultural and Political Feasibility: This section assesses how the software project will affect
the political environment and organizational culture. This analysis takes into account the
organization’s culture and how the suggested changes could be received there, as well as any
potential political obstacles or internal opposition to the project. It is essential that cultural and
political factors be taken into account in order to execute projects successfully.

7. Market Feasibility: This refers to evaluating the market’s willingness and ability to accept the
suggested software system. Analyzing the target market, understanding consumer wants and
assessing possible rivals are all part of this study. It assists in identifying whether the project is in
line with market expectations and whether there is a feasible market for the good or service being
offered.

8. Resource Feasibility: This method evaluates if the resources needed to complete the software
project successfully are adequate and readily available. Financial, technological and human
resources are all taken into account in this study. It guarantees that sufficient hardware, software,
trained labor and funding are available to complete the project successfully.

Requirement reviews in Software

Why are requirements needed before developing software ?

Requirements are mandatory in terms of software development. Requirements are the basics that take
forward the development procedure. Requirements enhance the existing project to a different level. The
software cannot progress without the participation of user input. User input like feedback and product
review comes as the major requirements in the development work.

What are requirement reviews ?

In short, Requirement review is the practice of scanning the software errors to make the industry user-
friendly for all.
Why is requirement review performed ?

Software in the current time is so Advanced that the act of requirement review holds greater importance
in software development. The pursuance of requirement reviews helps to have a clear peek into the space
of the software industry. The requirement reviews call attention to the only chance of finding quality
reviews. So keeping in mind that there are problems and solutions to everything, a requirement review
needs a good performance.

Importance of performing requirement review :

 The performance of requirement review helps to radiate the precise and correct data to the
consumers and users.
 It helps to have a quick tour of the Existing project to see whether or not it is going in the right
direction.
 It helps to provide practical instructions and helps make decisions accordingly.

What is Data Flow Diagram (DFD)?

DFD is the abbreviation for Data Flow Diagram. The flow of data in a system or process is represented by
a Data Flow Diagram (DFD). It also gives insight into the inputs and outputs of each entity and the
process itself. Data Flow Diagram (DFD) does not have a control flow and no loops or decision rules are
present. Specific operations, depending on the type of data, can be explained by a flowchart. It is a
graphical tool, useful for communicating with users, managers and other personnel. it is useful for
analyzing existing as well as proposed systems.

Types of Data Flow Diagram (DFD)

There are two types of Data Flow Diagram (DFD)

1. Logical Data Flow Diagram

2. Physical Data Flow Diagram

1. Logical Data Flow Diagram (DFD)

Logical data flow diagram mainly focuses on the system process. It illustrates how data flows in
the system. Logical Data Flow Diagram (DFD) mainly focuses on high level processes and data
flow without diving deep into technical implementation details. Logical DFD is used in various
organizations for the smooth running of system. Like in a Banking software system, it is used to
describe how data is moved from one entity to another.
 2. Physical Data Flow Diagram
Physical data flow diagram shows how the data flow is actually implemented in the system. In the
Physical Data Flow Diagram (DFD), we include additional details such as data storage, data
transmission, and specific technology or system components. Physical DFD is more specific and
close to implementation.

Characteristics of Data Flow Diagram (DFD)

 Graphical Representation: Data Flow Diagram (DFD) use different symbols and
notation to represent data flow within system. That simplify the complex model.
 Problem Analysis: Data Flow Diagram (DFDs) are very useful in understanding a
system and can be effectively used during analysis. Data Flow Diagram (DFDs) are quite
general and are not limited to problem analysis for software requirements specification.
 Abstraction: Data Flow Diagram (DFD) provides a abstraction to complex model i.e.
DFD hides unnecessary implementation details and show only the flow of data and
processes within information system.
 Hierarchy: Data Flow Diagram (DFD) provides a hierarchy of a system. High- level
diagram i.e. 0-level diagram provides an overview of entire system while lower-level
diagram like 1-level DFD and beyond provides a detailed data flow of individual process.
 Data Flow: The primary objective of Data Flow Diagram (DFD) is to visualize the data
flow between external entity, processes and data store. Data Flow is represented by an
arrow Symbol.
 Ease of Understanding: Data Flow Diagram (DFD) can be easily understand by both
technical and non-technical stakeholders.
 Modularity: Modularity can be achieved using Data Flow Diagram (DFD) as it breaks
the complex system into smaller module or processes. This provides easily analysis and
design of a system.

Introduction of ER Model

 Gather the requirements (functional and data) by asking questions to the database users.
 Do a logical or conceptual design of the database. This is where ER model plays a role. It is the
most used graphical representation of the conceptual design of a database.
 Physical Database Design (Like indexing) and external design (like views)

Why Use ER Diagrams In DBMS?
  ER diagrams represent the E-R model in a database, making them easy to convert into relations
(tables).
 ER diagrams provide the purpose of real-world modeling of objects which makes them intently
useful.
 ER diagrams require no technical knowledge of the underlying DBMS used.
 It gives a standard solution for visualizing the data logically.

Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which consists of these
symbols:

 Rectangles: Rectangles represent Entities in the ER Model.

 Ellipses: Ellipses represent Attributes in the ER Model.
 Diamond: Diamonds represent Relationships among Entities.
 Lines: Lines represent attributes to entities and entity sets with other relationship types.
 Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
 Double Rectangle: Double Rectangle represents a Weak Entity.

Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.

What is Entity?
An Entity may be an object with a physical existence – a particular person, car, house, or employee – or it
may be an object with a conceptual existence – a company, a job, or a university course.

What is Entity Set?

An Entity is an object of Entity Type and a set of all entities is called an entity set. For Example, E1 is an
entity having Entity Type Student and the set of all students is called Entity Set. In ER diagram, Entity
Type is represented as:

We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram because entity is
row and column in the relation and ER Diagram is graphical representation of data.

Types of Entity
There are two types of entity:

1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other Entity
in the Schema. It has a primary key, that helps in identifying it uniquely, and it is represented by a
rectangle. These are called Strong Entity Types.

2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some entity
type exists for which key attributes can’t be defined. These are called Weak Entity types .

For Example, A company may store the information of dependents (Parents, Children, Spouse) of an
Employee.But the dependents can’t exist without the employee. So Dependent will be a Weak Entity
Type and Employee will be Identifying Entity type for Dependent,which means it is Strong EntityType .

A weak entity type is represented by a Double Rectangle. The participation of weak entity types is always
total. The relationship between the weak entity type and its identifying strong entity type is called
identifying relationship and it is represented by a double diamond.

What is Attributes?
Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB, Age,
Address, and Mobile_No are the attributes that define entity type Student. In ER diagram, the attribute is
represented by an oval.

Types of Attributes

1. Key Attribute
The attribute which uniquely identifies each entity in the entity set is called the key attribute. For
example, Roll_No will be unique for each student. In ER diagram, the key attribute is represented by an
oval with underlying lines.

2. Composite Attribute
An attribute composed of many other attributes is called a composite attribute. For example, the Address
attribute of the student Entity type consists of Street, City, State, and Country. In ER diagram, the
composite attribute is represented by an oval comprising of ovals.

3. Multivalued Attribute
An attribute consisting of more than one value for a given entity. For example, Phone_No (can be more
than one for a given student). In ER diagram, a multivalued attribute is represented by a double oval.

4. Derived Attribute
An attribute that can be derived from other attributes of the entity type is known as a derived attribute.
e.g.; Age (can be derived from DOB). In ER diagram, the derived attribute is represented by a dashed
oval.