SOFTWARE ENGINERRING

1. What is the difference between Verification and Validation? Also discuss, its
significance in Software testing with examples.
Ans:
Verification is the process of checking whether the software is being developed
correctly according to the design and requirements. It is a static process (no code
execution), involving reviews and inspections.
Validation is the process of checking whether the developed software meets the user’s
needs and performs the intended functions. It is a dynamic process (involves code
execution), done through testing.
Aspect Verification Validation

The process of evaluating The process of evaluating

whether the product is whether the right product
Definition is being built (meets user
being built correctly (as per
design and requirements). needs and expectations).

To ensure the software

To ensure the software fulfills intended use or
Purpose
conforms to specifications. requirements.

Process Static – done without Dynamic – involves

Type executing the program. executing the program.

Performed Testers, QA team, end-

Developers, QA team. users.
By

Functional testing, system

Methods Reviews, walkthroughs, testing, user acceptance
Used inspections, desk-checking. testing.

Done during development Done after verification and

Timing development.
phase.
Examples:
• Verification Example:
o Reviewing the Software Requirement Specification (SRS) document to ensure
all client requirements are listed correctly.
o Checking whether the design document aligns with coding standards.
• Validation Example:
o Testing the login functionality to ensure users can log in with correct
credentials and are denied with incorrect ones.
o Running an e-commerce website to confirm that items can be added to the cart
and purchased correctly.
 SOFTWARE ENGINERRING
2. Define and differentiate between Functional and Non-Functional requirements with
example. Mention the attributes of Functional and Non-functional requirements.
Ans: In software engineering, requirements are the foundation of a successful system.
They are broadly classified into Functional and Non-Functional Requirements, both of
which are crucial for system design, development, and testing.
Functional Requirements
Functional requirements specify what the system should do. These are the core
functionalities and features that the software must provide to fulfil the user’s needs.
They define system behaviour under specific conditions and guide developers on how
the system should operate in response to inputs.
Examples:
• The system shall allow users to register, log in, and reset passwords.
• The ATM shall dispense cash after verifying the PIN and account balance.
• The application shall generate monthly sales reports.
Non-Functional Requirements
Non-functional requirements define how the system should behave rather than
specific behaviors. These include the quality attributes of the system, such as
performance, security, usability, and reliability. They ensure that the software system
is efficient, scalable, and user-friendly.
Examples:
• The system should respond to user queries within 2 seconds.
• The website should be available 99.9% of the time.
• The application must support at least 1,000 concurrent users.
Non-Functional
Criteria Functional Requirements Requirements

Describes what the system Describes how the system

Definition should perform
should do

Defines specific system Defines system attributes or

Purpose quality characteristics
behaviour or functions

Business rules, transactions, Performance, usability,

Nature reliability, scalability
and system operations

Verified through functional Verified through non-

Testing functional testing (e.g., load,
testing (e.g., unit,
Approach stress, security testing)
integration, system testing)

System processes each order

Example User can place an order in under 3 seconds
 SOFTWARE ENGINERRING
Attributes of Functional Requirements
1. Clarity and Unambiguity – Should be clearly stated with no confusion.
2. Completeness – Covers all possible scenarios and features.
3. Consistency – Should not conflict with other requirements.

Attributes of Non-Functional Requirements

1. Performance – Response time, throughput, latency.
2. Reliability – System’s ability to operate without failure.
3. Usability – How easy and intuitive the system is for users.

3. Briefly explain each steps involved in developing the DFD model of a system.
Ans: A Data Flow Diagram (DFD) is a visual representation of how data flows through
a system. It shows how input is transformed into output through a series of processes,
data stores, and interactions with external entities. DFDs are very useful in
understanding how a system works and are often used during the analysis and design
phases of software development.
Here are the main steps involved in developing a DFD model:
1. Develop the Context Diagram (Level 0 DFD)
The first step in creating a DFD is to draw the context diagram, also known as Level 0
DFD.
This diagram represents the entire system as a single process or bubble, and shows all
the external entities that interact with it.
• The context diagram gives a high-level overview of the system.
• It includes arrows to show the flow of data between the system and the external
entities like users, organizations, or other systems.
• The name of the system is written inside the central process bubble (noun form), since
it represents the entire system.

2. Identify High-Level Functions for Level 1 DFD

After the context diagram, the next step is to draw Level 1 DFD, which breaks down
the main system into major processes.
• Each process performs a specific function and is represented as a bubble with a verb
phrase like "Issue Book", "Search Book", etc.
• We usually identify 3 to 7 high-level processes at this level to keep the diagram clean
and understandable.
• This step helps us understand how the system operates internally.

3. Identify Data Inputs and Outputs

Now, we need to show what data is coming into the processes and what data is going
out.
 SOFTWARE ENGINERRING
• Arrows are used to represent the flow of data, and each arrow is labeled clearly with
the name of the data it carries.
• This makes it easier to track how information is transformed within the system.
4. Add Data Stores
In this step, we include the internal databases or storage locations used by the system.
• These are shown using open-ended rectangles.
• They are connected to processes through data flow arrows.
• Data stores help in understanding where and how information is stored within the
system.

5. Decompose Processes into Lower-Level DFDs

If a process in Level 1 is complex, it can be broken down further into smaller sub-
processes in Level 2 or Level 3 DFDs.
• This process is called decomposition or exploding a bubble.
• It helps in detailing the internal workings of each high-level process.

6. Balance the DFD

It is very important that the inputs and outputs in the higher-level diagrams are
consistent with those in the lower levels.
• This is called balancing the DFD.
• It ensures that no data is lost or added unexpectedly when moving between levels.

7. Number the Bubbles

To keep the diagram organized and easy to reference, each process bubble is given a
unique number.
• The context diagram is usually numbered 0.
• Level 1 bubbles are numbered 0.1, 0.2, 0.3, and so on.
• Level 2 bubbles from process 0.1 would be numbered 0.1.1, 0.1.2, etc.

4. What is UML ? Explain the following in context to UML. A)Use Case Diagram
B)Sequence Diagram C)State Diagram D)Classes and Objects.

Ans: UML stands for Unified Modeling Language. It is a standardized modeling language
used to visualize, design, and document the components of a software system. UML helps
in representing both the structure and behavior of software systems using diagrams.

• UML is not a programming language; it is a visual language that helps developers,

analysts, and designers communicate ideas clearly.

• It is widely used in object-oriented software development.

 SOFTWARE ENGINERRING
A) Use Case Diagram

These diagrams show the interactions between actors (users or other systems) and the
system itself. They depict use cases, which are functionalities or features the system
provides. For example, in a library system, actors might be Librarian and Member, with
use cases like "Borrow Book" or "Return Book."Key Components:

• Actor: Any user or external system that interacts with the application.

• Use Case: A functionality provided by the system (shown as an oval).

Example: In an Online Shopping System:

• Actors: Customer, Admin

• Use Cases: Login, Browse Items, Place Order, Make Payment

B) Sequence Diagram

A Sequence Diagram show how objects interact in a particular sequence over time.
They focus on the order of messages exchanged between objects. For instance, when
a user logs in, the sequence might involve the user interface sending a request to the
authentication service, which then checks the database. Arrows represent messages,
and lifelines show the objects' existence during the interaction.

Key Components:

• Lifelines: Vertical dashed lines representing objects.

• Messages: Horizontal arrows showing communication between objects.

• Activation Bars: Thin rectangles showing when an object is active.

Example: In a Payment System:

• User sends payment → System verifies → Bank processes → System confirms

C) State Diagram

A State Diagram illustrate the different states an object can be in and the transitions
between those states triggered by events. For example, a traffic light system might
have states like Red, Yellow, Green, and transitions based on timers. It's useful for
modeling behavior that depends on an object's state.

Key Components:

• States: Conditions in which the object can exist.

• Transitions: Arrows showing movement from one state to another.

 SOFTWARE ENGINERRING
• Events: Triggers that cause the state change.

Example: For an Order object:

• States: Order Placed → Payment Received → Shipped → Delivered → Closed

D) Classes and Objects

In UML:

• A Class is a blueprint that defines the attributes and methods of a set of objects.

• An Object is an instance of a class.

Class Diagram is used to show the structure of the system by representing:

• Classes (as rectangles with 3 compartments: name, attributes, and methods)

• Relationships (like inheritance, association)

Example: Class: Student

• Attributes: name, roll_no, course

• Methods: register(), viewDetails()