Software Requirement Specifications (SRS):

A software requirements specification (SRS) is a document that

describes what the software will do and how it will be expected to
perform. It also describes the functionality the product needs to fulfill
the needs of all stakeholders (business, users).

Requirement Engineering Process

Requirement Engineering is the process used to understand what a

customer wants from a system or project and to make sure those needs
are clearly defined, documented, and managed throughout the
development. Here’s a simplified overview of the Requirement
Engineering Process:

Requirement Engineering Process

It is a four-step process, which includes -
1. Feasibility Study
2. Requirement Elicitation and Analysis
3. Software Requirement Specification
4. Software Requirement Validation
5. Software Requirement Management
 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 established standards.
Types of Feasibility:
1. Technical Feasibility - Technical feasibility is about checking if
we can use existing technology to meet the customer's needs
within the available 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 - Economic feasibility decides whether the
necessary software can generate financial profits for an
organization.
What it is: This step checks whether the project is possible and practical to do. It looks at the technical, financial, and
operational aspects.

Example: A company wants to build an e-commerce app. The feasibility study checks if they have the technology,
budget, and resources to make it work.
Requirement Elicitation and Analysis is about figuring out what the
customer needs and making sure those needs are clearly understood and
correct.
 Gathering Requirements: We talk to the customer and look at
current systems (if any) to find out what’s needed.
 Analyzing Requirements: After gathering the requirements, we
check them for any issues like contradictions or missing details.
We also make sure everything fits together well and resolve any
conflicts that come up.

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.
Software Requirement Specification (SRS) is a detailed document
that explains what a software system should do based on the
requirements collected from the customer. Here's how it works:
 Creating the Document: After gathering all the requirements
from the customer, a software analyst writes them down in a clear,
technical way. This makes it easier for the development team to
understand and use these requirements.
 Using Models: To make the requirements even clearer, the
analyst might use diagrams and models like:
o ER Diagrams: Show how data is organized.
o Data Flow Diagrams (DFDs): Illustrate how data moves
through the system.
 o Function Decomposition Diagrams (FDDs): Break down
the system’s functions into smaller parts.
o Data Dictionaries: List all the data elements and their
details.
Software Requirement Validation is about checking if the
requirements are correct and feasible after they’ve been written down.
Here’s what happens:
 Validation Check: We review the requirements to make sure
they’re realistic and possible. This helps us catch any mistakes or
misunderstandings.
 User Requests: We also ensure that the requirements match what
the user really wants and that they aren’t asking for something
impossible or unrealistic.
Requirements can be the check against the following conditions –
o If they can practically implement
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
In this step, the requirements are reviewed to ensure they are correct, complete, and feasible.

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 is about handling changes to
requirements throughout the project. Here’s how it works:
 Managing Changes: As the project progresses, new
requirements might come up, or existing ones might change
because of evolving business needs or a better understanding of
the system.
 Adjusting Priorities: The importance of different requirements
might shift during development, so we need to adjust our focus
accordingly.
 Adapting to Changes: The business environment or technology
may change, so we adapt the requirements to fit these changes.

Software Requirements are mainly divided into two types:

1. Functional Requirements:
o What They Are: These describe what the system should do.
They define specific actions or functions the system must
perform.
o Example: If you're building an email app, a functional
requirement might be that the system should allow users to
send and receive emails.
2. Non-functional Requirements:
o What They Are: These describe how the system should
perform or behave. They focus on criteria like performance,
reliability, and usability, rather than specific functions.
 o Example: For the email app, a non-functional requirement
might be that the app should be able to handle 1000 emails
per minute or should have a response time of under 2
seconds.

Information Modeling is the process of creating a visual

representation of how data and information are organized and used
within a system. It helps to understand and manage the structure and
relationships of data.

Data Flow Diagrams (DFDs) are visual tools used to map out how
information moves within a system. Here’s a simple breakdown:
 What They Are: DFDs are diagrams that illustrate how data
flows into, out of, and through a system.
 Purpose: They help show the system’s scope and boundaries by
depicting:
o Data Inputs and Outputs: Where data comes from and
where it goes.
o Processes: How the data is transformed or used within the
system.
o Storage: Where data is stored or kept.
 How They Help:
o Clarity: They provide a clear picture of the system’s
operations, making it easier to understand how data is
managed.
o Communication: DFDs act as a useful tool for explaining
system functions to team members, stakeholders, or anyone
involved in the project.
 o Design: They serve as a starting point for redesigning or
improving systems by showing how information is handled
and where changes may be needed.
 Forms: DFDs can be created manually, using software tools, or a
mix of both methods.
 Other Names: They are also known as data flow graphs or
bubble charts.

The following observations about DFDs are essential:

1. All names should be unique. This makes it easier to refer to
elements in the DFD.
2. Remember that DFD is not a flow chart. Arrows is a flow chart
that represents the order of events; arrows in DFD represents
flowing data. A DFD does not involve any order of events.
3. Suppress logical decisions. If we ever have the urge to draw a
diamond-shaped box in a DFD, suppress that urge! A diamond-
shaped box is used in flow charts to represents decision points
with multiple exists paths of which the only one is taken. This
implies an ordering of events, which makes no sense in a DFD.
4. Do not become bogged down with details. Defer error conditions
and error handling until the end of the analysis.
Standard symbols for DFDs are derived from the electric circuit
diagram analysis and are shown in fig:
Circle: A circle (bubble) shows a process that transforms data inputs
into data outputs.
Data Flow: A curved line shows the flow of data into or out of a
process or data store.
Data Store: A set of parallel lines shows a place for the collection of
data items. A data store indicates that the data is stored which can be
used at a later stage or by the other processes in a different order. The
data store can have an element or group of elements.
Source or Sink: Source or Sink is an external entity and acts as a
source of system inputs or sink of system outputs.
Levels in Data Flow Diagrams (DFD)
The DFD may be used to perform a system or software at any level of
abstraction. Infact, DFDs may be partitioned into levels that represent
increasing information flow and functional detail. Levels in DFD are
numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in
the data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-
level DFD.

0-level DFDM
It is also known as fundamental system model, or context diagram
represents the entire software requirement as a single bubble with input
and output data denoted by incoming and outgoing arrows. Then the
system is decomposed and described as a DFD with multiple bubbles.
Parts of the system represented by each of these bubbles are then
decomposed and documented as more and more detailed DFDs. This
process may be repeated at as many levels as necessary until the
program at hand is well understood. It is essential to preserve the
number of inputs and outputs between levels, this concept is called
leveling by DeMacro. Thus, if bubble "A" has two inputs x1 and x2 and
one output y, then the expanded DFD, that represents "A" should have
exactly two external inputs and one external output as shown in fig:

The Level-0 DFD, also called context diagram of the result

management system is shown in fig. As the bubbles are decomposed
into less and less abstract bubbles, the corresponding data flow may
also be needed to be decomposed.
1-level DFD
In 1-level DFD, a context diagram is decomposed into multiple
bubbles/processes. In this level, we highlight the main objectives of the
system and breakdown the high-level process of 0-level DFD into
subprocesses.
2-Level DFD
2-level DFD goes one process deeper into parts of 1-level DFD. It can
be used to project or record the specific/necessary detail about the
system's functioning.
Entity-Relationship Diagrams
ER-modeling is a data modeling method used in software engineering
to produce a conceptual data model of an information system.
Diagrams created using this ER-modeling method are called Entity-
Relationship Diagrams or ER diagrams or ERDs.
Purpose of ERD
o The database analyst gains a better understanding of the data to
be contained in the database through the step of constructing the
ERD.
o The ERD serves as a documentation tool.
o Finally, the ERD is used to connect the logical structure of the
database to users. In particular, the ERD effectively
communicates the logic of the database to users.
Components of an ER Diagrams
1. Entity
An entity can be a real-world object, either animate or inanimate, that
can be merely identifiable. An entity is denoted as a rectangle in an ER
diagram. For example, in a school database, students, teachers, classes,
and courses offered can be treated as entities. All these entities have
some attributes or properties that give them their identity.
Entity Set
An entity set is a collection of related types of entities. An entity set
may include entities with attribute sharing similar values. For example,
a Student set may contain all the students of a school; likewise, a
Teacher set may include all the teachers of a school from all faculties.
Entity set need not be disjoint.

2. Attributes
Entities are denoted utilizing their properties, known as attributes. All
attributes have values. For example, a student entity may have name,
class, and age as attributes.
There exists a domain or range of values that can be assigned to
attributes. For example, a student's name cannot be a numeric value. It
has to be alphabetic. A student's age cannot be negative, etc.
 Property/Attributes Property/Attributes

Entity

Property/Attributes Property/Attributes

There are four types of Attributes:

1. Key attribute
2. Composite attribute
3. Single-valued attribute
4. Multi-valued attribute
5. Derived attribute
1. Key attribute: Key is an attribute or collection of attributes that
uniquely identifies an entity among the entity set. For example, the
roll_number of a student makes him identifiable among students.
There are mainly three types of keys:
1. Super key: A set of attributes that collectively identifies an entity
in the entity set. Ex:-{Roll no,Email,Name}
2. Candidate key: A minimal super key is known as a candidate
key. An entity set may have more than one candidate key. Ex:-{Roll no,Email}
3. Primary key: A primary key is one of the candidate keys chosen
by the database designer to uniquely identify the entity set. Ex:-{Roll no}
2. Composite attribute: An attribute that is a combination of other
attributes is called a composite attribute. For example, In student entity,
the student address is a composite attribute as an address is composed
of other characteristics such as pin code, state, country.

3. Single-valued attribute: Single-valued attribute contain a single

value. For example, Social_Security_Number.
4. Multi-valued Attribute: If an attribute can have more than one
value, it is known as a multi-valued attribute. Multi-valued attributes
are depicted by the double ellipse. For example, a person can have more
than one phone number, email-address, etc.
5. Derived attribute: Derived attributes are the attribute that does not
exist in the physical database, but their values are derived from other
attributes present in the database. For example, age can be derived from
date_of_birth. In the ER diagram, Derived attributes are depicted by
the dashed ellipse.
3. Relationships
The association among entities is known as relationship. Relationships
are represented by the diamond-shaped box. For example, an employee
works_at a department, a student enrolls in a course. Here, Works_at
and Enrolls are called relationships.

Relationship set
A set of relationships of a similar type is known as a relationship set.
Like entities, a relationship too can have attributes. These attributes are
called descriptive attributes.
Degree of a relationship set
The number of participating entities in a relationship describes the
degree of the relationship. The three most common relationships in E-
R models are:
1. Unary (degree1)
2. Binary (degree2)
3. Ternary (degree3)
1. Unary relationship: This is also called recursive relationships. It is
a relationship between the instances of one entity type. For example,
one person is married to only one person.
2. Binary relationship: It is a relationship between the instances of
two entity types. For example, the Teacher teaches the subject.

3. Ternary relationship: It is a relationship amongst instances of three

entity types. In fig, the relationships "may have" provide the
association of three entities, i.e., TEACHER, STUDENT, and
SUBJECT. All three entities are many-to-many participants. There may
be one or many participants in a ternary relationship.
In general, "n" entities can be related by the same relationship and is
known as n-ary relationship.

Cardinality
Cardinality describes the number of entities in one entity set, which can
be associated with the number of entities of other sets via relationship
set.
Types of Cardinalities
1. One to One: One entity from entity set A can be contained with at
most one entity of entity set B and vice versa. Let us assume that each
student has only one student ID, and each student ID is assigned to only
one person. So, the relationship will be one to one.

Using Sets, it can be represented as:

2. One to many: When a single instance of an entity is associated with

more than one instances of another entity then it is called one to many
relationships. For example, a client can place many orders; a order
cannot be placed by many customers.
Using Sets, it can be represented as:

3. Many to One: More than one entity from entity set A can be
associated with at most one entity of entity set B, however an entity
from entity set B can be associated with more than one entity from
entity set A. For example - many students can study in a single college,
but a student cannot study in many colleges at the same time.

Using Sets, it can be represented as:

4. Many to Many: One entity from A can be associated with more than
one entity from B and vice-versa. For example, the student can be
assigned to many projects, and a project can be assigned to many
students.

Using Sets, it can be represented as:

Decision Table:
Decision Table-Based Testing is a method used to ensure that a
software application behaves correctly under various conditions. Here's
a simple breakdown:
Decision Table
It’s a tool used to visualize and test complex logic by showing all
possible combinations of conditions and their results.
The table displays different conditions (like True or False) and lists the
corresponding actions that should happen based on those conditions.