Unit -2

Requirement Analysis
Software requirement analysis simply means complete study, analyzing, describing
software requirements so that requirements that are genuine and needed can be fulfilled
to solve problem. There are several activities involved in analyzing Software
requirements. Some of them are given below :

1. Problem Recognition :
The main aim of requirement analysis is to fully understand main objective of
requirement that includes why it is needed, does it add value to product, will it be
beneficial, does it increase quality of the project, does it will have any other effect. All
these points are fully recognized in problem recognition so that requirements that are
essential can be fulfilled to solve business problems.

2. Evaluation and Synthesis :

Evaluation means judgement about something whether it is worth or not and synthesis
means to create or form something. Here are some tasks are given that is important in
the evaluation and synthesis of software requirement :
 To define all functions of software that necessary.
 To define all data objects that are present externally and are easily observable.
 To evaluate that flow of data is worth or not.
 To fully understand overall behavior of system that means overall working of
system.
 To identify and discover constraints that are designed.
 To define and establish character of system interface to fully understand how
system interacts with two or more components or with one another.
3. Modeling :
After complete gathering of information from above tasks, functional and behavioral
models are established after checking function and behavior of system using a domain
model that also known as the conceptual model.

4. Specification :
The software requirement specification (SRS) which means to specify the requirement
whether it is functional or non-functional should be developed.

5. Review :
After developing the SRS, it must be reviewed to check whether it can be improved or
not and must be refined to make it better and increase the quality.
 Refers to the process of clearly defining the boundaries of a system, identifying its key
functions and components at a high level, assigning those components to specific physical
elements (like hardware or software modules), refining the details of each component, and
then thoroughly reviewing the entire analysis to ensure accuracy and completeness.

Breakdown of the key terms:

 Statement of system scope:
A clear description of what the system will do, including its functionalities, boundaries, and
what is explicitly not included within the system.
 Isolation of top-level processes and entities:
Identifying the major functions and data elements that the system needs to manage,
without going into excessive detail about sub-processes or specific data attributes.
 Allocation to physical elements:
Assigning these top-level processes and entities to specific physical components like
servers, databases, user interfaces, or software modules based on their functionality and
technical considerations.
 Refinement:
Further detailing and elaborating on the identified processes and entities, adding
necessary sub-functions, data attributes, and specific requirements for each element.
 Review:
A thorough evaluation of the requirements analysis document by relevant stakeholders to
identify potential inconsistencies, gaps, or ambiguities, ensuring the overall quality and
accuracy of the system design.
How this process is typically done:
1. 1. Identify system boundaries:
Define the scope of the system, outlining what features are included and what is
considered "outside" the system.
2. 2. Identify top-level processes and entities:
Analyze the system's primary functions and data elements needed to perform those
functions, creating a high-level overview.
3. 3. Allocate to physical elements:
Determine where each process or entity will reside within the system architecture,
assigning them to specific hardware or software components.
4. 4. Refine requirements:
Break down each top-level process into detailed sub-functions, define data attributes, and
specify the exact behavior and interactions needed for each component.

5. 5. Conduct reviews:
Hold meetings with stakeholders to review the requirements document, ensuring clarity,
consistency, and alignment with project goals.
Importance of this process:
 Clear understanding:
By clearly defining the system scope and breaking down complex functionalities, everyone
involved in the project has a common understanding of what needs to be built.
 Efficient design:
Proper allocation of processes and entities to physical elements helps optimize system
architecture and development efforts.
 Quality assurance:
A thorough review process helps identify potential issues early on, minimizing the risk of
errors or misunderstandings later in the development cycle.

Problem analysis

Problem analysis in software engineering is the process of understanding, defining,

and breaking down a problem to identify its root causes, requirements, and
constraints before designing a solution. It’s the critical first step in software
development, ensuring engineers address the right problem effectively.

Importance of Problem Analysis

Think of problem analysis as drafting a map before starting a journey. Without it,
engineers risk creating solutions that miss user needs, exceed budgets, or are
overly complex. Proper analysis ensures clarity, reduces errors, and saves time in
the long run
 Key Steps in Problem Analysis
Understand the Problem
 Gather Requirements: Identify what the stakeholders want the system to achieve.
This includes functional requirements (what the system does) and non-functional
requirements (performance, scalability, etc.).
 Identify Pain Points: What challenges or inefficiencies does the current system
face?
 Define Scope: Clearly outline the boundaries of the problem to avoid scope creep.

Break Down the Problem

 Decompose into Components: Split the problem into smaller, manageable parts.
For instance, if building an e-commerce platform, divide it into modules like user
management, inventory, and payments.
 Prioritize Elements: Determine which parts are most critical to solve first.

Analyze Constraints
 Technical Constraints: Assess system requirements, such as hardware
limitations or platform dependencies.
 Budget and Time Constraints: Ensure the solution aligns with available
resources and deadlines.

Identify Root Causes

 Use Analytical Tools: Tools like fishbone diagrams or the "5 Whys" technique can
help trace back to the root cause of a problem.
 Distinguish Symptoms from Causes: For example, frequent crashes might be a
symptom, while the root cause is inadequate memory management.

Determine Goals and Success Criteria

 Set Clear Objectives: Define what a successful solution looks like. For example,
reducing query response time from 5 seconds to 1 second.
 Create Measurable Metrics: Identify key performance indicators (KPIs) to
measure success.
 Example: Problem Analysis in Action
Suppose you’re tasked with designing a ticket booking system for a train service:

1. Understand the Problem: Stakeholders need users to book tickets quickly while
avoiding double bookings.
2. Break Down the Problem:
o User authentication
o Ticket availability checks
o Payment integration
3. Analyze Constraints:
o Handle up to 10,000 users simultaneously.
o Ensure compliance with payment security standards.
4. Identify Root Causes: Double bookings occur due to race conditions in database
updates.
5. Set Goals: Implement a locking mechanism to eliminate race conditions and
reduce booking failures to less than 1%.

Benefits of Problem Analysis

 Reduces Misunderstandings: Ensures all stakeholders are aligned on what the
system should do.
 Improves Efficiency: Helps engineers focus on solving the right problems.
 Facilitates Better Design: Lays the foundation for a scalable, maintainable, and
user-friendly solution.

Process modelling with physical logical data

flow diagrams
Process modeling involves creating visual representations of business processes in order to
understand and improve them. Physical and logical data flow diagrams are two types of
diagrams used in process modeling.

Physical Data Flow Diagrams (PDFDs) are graphical representations of the movement of
data from its origin to its final destination. They depict the physical flow of information
between people, systems, and storage media. PDFDs show how data is transformed from one
format to another and how it is stored, retrieved, and transmitted.
Logical Data Flow Diagrams (LDPDs), on the other hand, depict the processing of data as
it moves through a system. They show the logic behind the processing of data, including the
transformations that take place, without emphasizing the physical aspect of the flow. LDFDs
are used to identify the inputs, processing, and outputs of a system.

Both physical and logical data flow diagrams are useful in process modeling because they
provide different perspectives on the flow of data in a system. PDFDs give a clear picture of
the physical path that data takes, while LDFDs show the logic behind the processing of the
data. By using both diagrams in conjunction, organizations can gain a complete
understanding of their business processes and identify areas for improvement.

Components of Data Flow Diagram:

Following are the components of the data flow diagram that are used to represent source,
destination, storage and flow of data.

Entities:
Entities include source and destination of the data. Entities are represented by rectangle with
their corresponding names.
 Process:
The tasks performed on the data is known as process. Process is represented by circle.
Somewhere round edge rectangles are also used to represent process.

 Data Storage:
Data storage includes the database of the system. It is represented by rectangle with both
smaller sides missing or in other words within two parallel lines.

 Data Flow:
The movement of data in the system is known as data flow. It is represented with the help of
arrow. The tail of the arrow is source and the head of the arrow is destination.

Importance of Data Flow Diagram:

Data flow diagram is a simple formalism to represent the flow of data in the system. It allows
a simple set of intuitive concepts and rules. It is an elegant technique that is useful to
represent the results of structured analysis of software problem as well as to represent the
flow of documents in an organization.

Data modeling is the process of creating a conceptual representation of data and the
relationships between data elements. Logical Entity Relationship Diagrams (ERDs) are a
type of data model that is used to depict the relationships between entities in a system.

An entity is an object or concept that exists within the system and has attributes, or
characteristics, that describe it. In a logical ERD, entities are represented by rectangles, and
the relationships between them are represented by lines connecting the entities.

The relationships between entities in a logical ERD can be one-to-one, one-to-many, or

many-to-many. These relationships are depicted using arrows on the lines connecting the
entities. For example, a one-to-many relationship might be represented by an arrow pointing
from a “Department” entity to an “Employee” entity, indicating that one department can have
many employees, but each employee belongs to only one department.

Logical ERDs are useful for understanding the relationships between entities in a system,
and for communicating this understanding to others. They can also be used to design and
implement a database, as well as to validate the design and ensure that it meets the needs of
the business.

Overall, logical ERDs are an important tool in data modeling, as they help organizations
understand the relationships between data elements and design databases that are efficient
and meet their business needs.
O level DFD

1 level DFD
 ER (Entity Relationship) Diagram in
DBMS
 ER model stands for an Entity-Relationship model. It is a high-level data model. This model
is used to define the data elements and relationship for a specified system.
 It develops a conceptual design for the database. It also develops a very simple and easy to
design view of data.
 In ER modeling, the database structure is portrayed as a diagram called an entity-relationship
diagram.

For example, Suppose we design a school database. In this database, the student will be an
entity with attributes like address, name, id, age, etc. The address can be another entity with
attributes like city, street name, pin code, etc and there will be a relationship between them.
Component of ER Diagram

1. Entity:
An entity may be any object, class, person or place. In the ER diagram, an entity can be
represented as rectangles.

Consider an organization as an example- manager, product, employee, department etc. can be

taken as an entity.
a. Weak EntityPlay Video

An entity that depends on another entity called a weak entity. The weak entity doesn’t
contain any key attribute of its own. The weak entity is represented by a double rectangle.

2. Attribute
The attribute is used to describe the property of an entity. Eclipse is used to represent an
attribute.

For example, id, age, contact number, name, etc. can be attributes of a student.

a. Key Attribute

The key attribute is used to represent the main characteristics of an entity. It represents a
primary key. The key attribute is represented by an ellipse with the text underlined.
b. Composite Attribute

An attribute that composed of many other attributes is known as a composite attribute. The
composite attribute is represented by an ellipse, and those ellipses are connected with an
ellipse.

c. Multivalued Attribute

An attribute can have more than one value. These attributes are known as a multivalued
attribute. The double oval is used to represent multivalued attribute.

For example, a student can have more than one phone number.
d. Derived Attribute

An attribute that can be derived from other attribute is known as a derived attribute. It can be
represented by a dashed ellipse.

For example, A person’s age changes over time and can be derived from another attribute
like Date of birth.

3. Relationship
A relationship is used to describe the relation between entities. Diamond or rhombus is used
to represent the relationship.
Types of relationship are as follows:

a. One-to-One Relationship

When only one instance of an entity is associated with the relationship, then it is known as
one to one relationship.

For example, A female can marry to one male, and a male can marry to one female.

b. One-to-many relationship

When only one instance of the entity on the left, and more than one instance of an entity on
the right associates with the relationship then this is known as a one-to-many relationship.

For example, Scientist can invent many inventions, but the invention is done by the only
specific scientist.
c. Many-to-one relationship

When more than one instance of the entity on the left, and only one instance of an entity on
the right associates with the relationship then it is known as a many-to-one relationship.

For example, Student enrolls for only one course, but a course can have many students.

d. Many-to-many relationship

When more than one instance of the entity on the left, and more than one instance of an
entity on the right associates with the relationship then it is known as a many-to-many
relationship.

For example, Employee can assign by many projects and project can have many employees.

Design Objectives
In software engineering, design objectives refer to the
Essential goals and standards a design should meet to ensure
high-quality, efficient, and maintainable software. Some
Primary design objectives include:
1. Correctness: The design should meet all specified
requirements, addressing both functional and non-
functional needs.
2. Efficiency :Software should utilize resources effectively,
including CPU, memory, and storage.
3. Maintainability :The design should allow for easy
updates, bug fixes, and adaptability to future
requirements.
4. Usability :The end user should find the software
intuitive and easy to use.
5. Reusability: Components of the software should be
reusable in other systems, reducing duplication of effort.
6. Scalability :The design should allow the software to
grow or adapt as the user base or load increases.
7. Reliability:The software should consistently performe
expected without frequent crashes or errors.
8. Security:The design should protect the software from
unauthorized access and vulnerabilities.